# 纠正两个常见的错误观念。端到端测试自动化是 简单而容易 还是 复杂而不可能 当前市场上各种端到端的测试工具层出不穷，工具市场很繁荣，但真正成功的项目实践却很少见。今天看到了一篇很有意思的文章，我愿称作者为**典型的 selenium 原教旨主义者**， 他的一些观点尽管看上去非常的 old school，不过总的来说是很有道理的，这里简单的分享一下他的观点。 他的这篇文章叫做 Correct two Common Misconceptions: End-to-End Test Automation is “Simple and Easy” or “Complex and Impossible”，翻译过来就是**纠正两个常见的错误观念。端到端测试自动化是 "简单而容易 "还是 "复杂而不可能"**, 原文的地址是https://zhiminzhan.medium.com/correct-two-common-misconceptions-end-to-end-test-automation-is-simple-and-easy-or-complex-and-ad559ade982a。 一切都开始于这样的一个观点: > 事实：大多数测试自动化的尝试都失败了 "根据我在这个领域 17 年的经验，我同意图片中描述的主要概念，即大多数测试自动化的努力往往是失败的。" - 作者 ### 端到端测试自动化是简单还是复杂？ 答案取决于你问谁。在过去的 30 年里，测试自动化供应商，如惠普，一直在推销 "记录/回放 "和 "对象识别工具 "的概念。尽管这些方法已经被证明是无效的，但一些供应商仍然坚持使用这些方法。 在一个典型的软件团队中，众多的软件工程师和经理可能认为 "测试自动化 "是一个简单的任务，尽管没有人见过测试自动化的成功实施（也就是说，团队完全依靠手工测试）。作为证据，许多招聘广告要求申请人有 "创建测试自动化框架 "的经验，这似乎很荒谬。 所以，端到端的测试自动化可能并不像许多人想象的那样简单和容易。 > "根据我的经验，优秀的开发人员不一定能成为优秀的测试人员，但优秀的测试人员（同时具有很强的设计能力）可以成为优秀的开发人员。这是一种心态和一种激情。...他们是黄金"。 > > - 谷歌副总裁帕特里克-科普兰，在一次采访中（2010 年） > "95%的时间，95%的测试工程师会写出糟糕的 GUI 自动化，只是因为它是一件非常难做的事情。 > > - 这篇来自微软测试大师 Alan Page 的采访（2015 年） > "测试比开发更难。如果你想有好的测试，你需要把你最好的人放在测试中"。 > > - Gerald Weinberg，在一个播客中（2018 年）。 考虑到事实和上述知名专家的引言，似乎完成端到端的测试自动化是一个无法克服的挑战。 我的答案是 **"它可以很简单，但往往是人为的错误使它变得不必要的困难。"** ### 许多人做出了明显的错误的决定 我见过错误的决定，往往不止一个，在失败的测试自动化尝试中。 - 😱 使用编译语言，如 Java/C#，作为脚本语言。 我们称之为 "测试脚本"，是有很好的理由的！请看这篇文章，"自动化测试脚本应采用脚本语言的语法，自然！" - 😱 使用 Gherkin，例如 Cucumber/SpecFlow，作为测试语法。 这大大增加了维护的工作量，但几乎没有任何价值。查看《为什么小黄瓜（Cucumber，SpecFlow...）在 UI 测试自动化中总是失败？ 😱 使用 JavaScript 作为端到端测试自动化的语言。 - JavaScript 是一种复杂的语言（主要用于前端开发），不适合测试自动化（如恼人的 await，node_modules，...）。我遇到的每个 JS 测试员都是假的，没有例外。 毫不奇怪，假的测试人员在几年的时间里循环使用 PhantomJS -> WebDriverIO -> Protractor -> TestCafe -> Pupetteer -> Cypress -> Playwright，结果都一样：失败。 请看 "为什么 JavaScript 不适合用于真正的网络测试自动化？" - 😱 使用一个错误的框架或工具. 一个典型的例子是 Cypress，一个有一长串限制的 "测试自动化框架"。这简直是疯了! 因为 Selenium WebDriver 是基于 W3C 标准的，并且被所有浏览器供应商所支持。此外，它已经被证明了。从 Cypress 测试自动化尝试失败的反馈中，我跟自己和解了，"原始 Selenium WebDriver 比 Cypress 容易得多（学习、使用、维护...，）"。 > "Facebook 每天发布两次，保持这种节奏是我们文化的核心。在这种发布速度下，用 Selenium 进行自动化测试对确保在发布前一切正常至关重要"。- DAMIEN SERENI，Facebook 的工程总监，在 Selenium 2013 会议上。 - 😱 测试自动化工具和脚本的风格是由一两个工程师的个人喜好选择的。 端到端测试自动化的受众是整个团队，包括业务分析师，手动测试人员，甚至是客户，他们不需要开发自动化测试，但他们应理解测试脚本并能自如地运行它们。 - 😱 在一个典型的 CI 服务器中运行端到端测试，例如 Jenkins 或 Bamboo。 CI 服务器是为执行单元或集成测试而建立的。端到端的 UI 测试更容易发生变化，需要更长的时间。你应该使用一个合适的持续测试服务器，如 Facebook 的 Sandcastle 或 BuildWise。 我可以列举更多，但大多数读者可能想知道，"够了，我们知道失败的原因。你有一个简单的解决方案吗？"。是的，我有。 ### 我的 "简单而正确 "的解决方案 自 2011 年以来，我一直在实施端到端的测试自动化，成功率为 100%，使用的是同一个公式。这个逻辑是如此简单和明显。 - 使用原始的 Selenium WebDriver 由 W3C 定义的网络技术基本没有变化，所以我使用原始的 Selenium WebDriver（W3C 标准）。 - 使用最好的、易学的、经过验证的脚本语言，Ruby。 对于那些想要一个完整的解决方案的人来说（向他们的经理吹彩虹屁）。 - 简单的测试自动化策略 你不需要花 1 分钟的时间。所有端到端的测试自动化都是一样的。只要使用我的 35 字功能测试自动化策略。 - 原始 Selenium WebDriver 作为网络测试自动化框架.是的，原始的，不要费心在它上面创建一个所谓的框架；Protractor（由 angular 团队）尝试过，但失败了。只要遵循可维护的自动化测试设计，并使用一个支持功能测试重构的好工具。 - 用简单的 RSpec 框架. 你可以在几分钟内学会，真的。另外，使用 Rspec 意味着测试脚本使用 Ruby，这是端到端测试自动化的最佳脚本语言。 - 开发你的测试脚本，对维护是友好的。 不要使用记录/回放或类似的，只是手工制作，这可以是简单和有趣的，在一个富有成效的测试 IDE 或编程编辑器。 如果你还没有使用 TestWise，可以去看看。 - 在一个真正的持续测试服务器中运行所有的端到端测试，每天如此.在自动化 E2E 软件测试中，不要以 "100%覆盖率 "为目标，这是不可能的，也没有必要。事实上，很少有软件项目能够维持一套 50 个端到端（通过 UI）的测试，即 AgileWay 持续测试分级的第二级。 如果你和你的团队发现维护工作具有挑战性，请接受现实（需要技能或应寻求辅导），但要保持所有现有测试的有效性。即使是一个小的工作自动化端到端套件，例如 20 个测试，只要它们是有效的，就能提供价值。 值得注意的是，与许多所谓的测试自动化解决方案不同，上述解决方案是免费的（因为在 100%的自由和没有/很少的钱），开放和面向未来的。 根据 "Hired's 2023 State of Software Engineers "报告，"Ruby on Rails 是最需要的技能"，而 Ruby 是第二位。因此，无论你是受雇于软件工程师还是测试自动化工程师，都没有正当理由不从今天开始学习 Ruby，这既是为了你正在进行的项目，也是为了你的个人职业发展。 ### 简单 ≠ 容易 在电影《中央情报局》中，当有人问起鲍勃（主角）的转变时，他说他只做了一件事：他去了健身房。"6 个小时。每一天。在过去的 20 年里。直线，"鲍勃说。经典的软件工程书籍《务实的程序员》传达了同样的概念。 > 一位参观英国伊顿学院的游客问园丁，他是如何把草坪弄得如此完美的。"这很简单，"他回答说，"你只是每天早上刷掉露水，每隔一天修剪一次，每周滚一次。" > "就这些吗？"游客问。"绝对是这样。"园丁回答。"这样做 500 年，你也会有一个漂亮的草坪。" 出自 The Pragmatic Programmer book 自动化的真正挑战是维护，而不是创建（~10%，努力程度）。如果一个团队发现测试的创建很复杂，很困难，那么持续的维护（每天多次运行整个端到端的套件）将是不可能的。 请看我的另一篇文章，如何实现真正的自动化回归测试？ ### 总结 所以，有些读者可能只是想直接回答这个问题，"端到端是简单还是复杂，容易还是困难？"。 我的简短回答是："简单，不一定难，可以迅速获得良好的效益"，如果以正确的方式进行。效益有多大？这取决于对保障的期望。 我的女儿在 12 岁的时候就可以轻松地开发和维护一套 20 个端到端的 Selenium 测试，即 "AgileWay 持续测试分级 "的第二级。是的，仅仅是几天的临时培训（因为她当时还是个初中生）。 她去年从大学毕业了。她现在的水平如何？根据我的评估，她的测试自动化能力是~75 个测试。这里，我总是指每个工作日维持运行整个套件的能力。 没有做过真正的测试自动化的人可能不会掌握这个概念。我可以告诉你她的测试自动化水平相当高，>99.5%。去年，在她在一家大型电信公司的第一个实习角色中。她开发了一套自动化测试（并每天运行），速度之快令公司震惊（她的同事以前没有见过）。所谓的 "最好的自动化工程师 "无法保持 20 个测试的有效性，所以这个家伙整个人都不好了。请看这个故事，一个 IT 毕业生对一个假的'高级测试自动化工程师'的挫折。 要达到我的水平（500 多个测试，如前所示），我的女儿还有很长的路要走（顺便说一下，她在 FAANG 担任软件开发工程师，而不是 QA 工程师，测试自动化是她自学的）。但是对于那些希望获得测试自动化价值的公司来说，例如执行少数几个关键的自动化测试作为回归测试，没有任何测试自动化经验的人可以在良好的指导下，在几天内迅速实现。即使是少量的测试，只要它们每天都在运行并且有效，就能提供良好的价值。请看我女儿的文章，在你上班的第一天就在 CT 服务器中设置、开发自动 UI 测试并运行它们，以及我的文章，如何在软件项目入职的第一天就开始测试自动化？ 但如果你的目标是 "早发布，多发布 "或 "每日生产发布"，即真正的敏捷由真正的测试自动化支持，并有数百个端到端测试的良好覆盖，这并不容易。捷径是向曾经做过的人学习（极其罕见）。 ### 再总结 上面基本上是对作者文章的翻译，总的看下来我觉得他的文风，内容以及观点其实挺有意思的 - 引经据典很多，看起来就很专业的样子 - 高清说说法就是挺自信的，低情商就是感觉有点像吹牛的样子 - 有点原教旨主义，比如 selenium 是最好的，ruby 是最好的，十年前这样说基本没啥问题，十年后，当然我内心里是完全同意他的看法的，其实自动化测试这些年来变化很多，我是乐于看到其他工具和解决方案带来的新变化的 - 我女儿如何如何，中年人标配了 - 他的观点大部分都是经得起推敲的，比如 selenium 最为主流，用脚本语言写用例比较简单，一些老练的选择可以让 ui 自动化变得更加容易等