纠正两个常见的错误观念。端到端测试自动化是 简单而容易 还是 复杂而不可能

当前市场上各种端到端的测试工具层出不穷，工具市场很繁荣，但真正成功的项目实践却很少见。今天看到了一篇很有意思的文章，我愿称作者为典型的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自动化变得更加容易等