缺乏执行用户端到端自动化测试的能力并不可耻，但欺骗肯定是不可接受的

作为一名软件工程师和测试自动化工程师，我认为有必要在我们的职称中强调 “工程师 “一词。根据广为接受的规范，工程涉及一种系统可靠的方法，旨在创造持久和长期的解决方案。例如，如果一座美轮美奂的大桥在落成三天后就倒塌了，那么负责设计这座大桥的 “土木工程师 “不仅会失去职业资格，还有可能面临监禁等法律后果。然而，软件行业对此类问题往往采取较为宽容的态度。因此，假冒自动测试人员的比例很高。

长期读者曾多次目睹我引用国际知名的敏捷和测试专家的观点，这些专家都传达了同样的信息：通过用户界面（UI）实现真正有价值的端到端测试自动化是一项极具挑战性的工作。成功者寥寥无几。

”根据我的经验，优秀的开发人员并不一定能成为优秀的测试人员，但优秀的测试人员（同时具备很强的设计能力）却能成为优秀的开发人员。这是一种心态和激情。……他们是金子。”—— Patrick Copeland，谷歌高级工程总监，在一次采访中（2010 年）

“95%的时间里，95%的测试工程师都会编写糟糕的图形用户界面自动化，因为这是一件很难正确完成的事情” ——《我们如何在微软测试软件》一书的作者、微软测试大师Alan Page（2015 年）接受采访时说。

“通过图形用户界面进行自动测试是直观的、诱人的，而且几乎总是错的！” —— Robert C. Martin，《敏捷宣言》的作者之一，在他的博客上（2009 年）

遗憾的是，许多软件专业人员由于自身的局限性，并没有意识到这一点。不少人认为”测试自动化就是记录-回放，很简单”。这种想法错得有多离谱？

“测试比开发更难。如果你想有好的测试，就必须让最好的人去做测试。”—软件界传奇人物杰 Gerald Weinberg，在一次播客中（2018 年）

在本文中，我将讲述一个故事，说明一个典型的假冒自动测试器暴露后的情况。

我遇到的 95% 以上的 E2E 测试自动化工程师都是假的

如果你目前正在进行端到端测试自动化，请不要生气。我还没见过你，所以你很可能就在那 5%（或者按照 Alan Page 的判断是 0.25%。与Alan相比，我的数字相当保守）。

这是Michael Feathers（著名敏捷专家，《有效处理遗留代码》一书的作者）在 2009 年讲述的一个故事：这种情况一再发生。我访问一个团队，询问他们的测试情况。然后，我问到自动化端到端测试，他们指了指角落里的一台机器。我们浏览他们的测试脚本集，并尝试运行它们。系统崩溃了几次，然后他们腼腆地笑着对我说 “我们试过了”。我说，”别担心，大家都试过了”。

上述情况我也见过很多次（不同的是我没有问，而是查看测试执行报告），情况没有任何变化。现在有一个问题，你是否同意”（Michael故事中的）团队在做虚假的自动化测试”？当然是。如果他们（团队成员）是诚实的，他们就会先说 “我们尝试过，但失败了”，而不是指出 “测试机器 “并尝试运行测试（失败了几次，赌运气？）然后才承认他们没有能力。

为什么会这样呢？是因为团队不好意思承认他们无法实现端到端测试自动化，他们撒谎了。在我看来，不做真正的自动化测试没什么可耻的，但撒谎却很可耻。

一个故事：测试自动化工程师应为自己的工作负责

原则上，每个人都会同意上述说法。然而，在测试自动化中，情况通常并非如此。让我用一个假设的（但典型合理的）故事来详细说明。

Toby 是一名高级测试自动化工程师（承包商），已经为项目工作了 5 个月。在站立期间，他报告说已经完成了许多用户故事的测试，Jira 也显示了这一点。新项目经理 Russ 加入了团队。

Russ 找到 Toby 说：”Toby，首席信息官一直在努力做到’早发布、勤发布’，端到端测试自动化在回归测试中发挥着重要作用。Toby点点头，”当然是这样”。Russ 说：”很好，我们的理解是一致的。现在，我打算进行全面的回归测试。这样我们就能知道多久能发布一次产品。当然，我们必须考虑到几轮回归测试，以重新测试错误修复。

Russ 继续说：”你是团队中唯一的测试自动化工程师。你能拿到你的自动化测试套件所涵盖的用户故事列表吗？我会告诉人工测试人员不要测试这些，因为你的自动化测试已经覆盖了这些内容。好的，只需给我发一份最近的测试报告即可”。

Toby不自信地回答：”好吧”。Russ 离开后，Toby 急忙打开了所谓的 CI/CD 管道中的测试执行。在 UI 测试自动化下，最近一次运行是在 3 个月前，超过 50% 的测试执行失败。

第二天，Toby来到 Russ 的办公桌前说：”自动测试在创建时运行正常。由于应用程序和测试数据发生了变化，一些自动测试失败了。我可能需要几周时间来纠正它们”。Russ 很不高兴，问道：”我以为维护自动测试套件是你工作的一部分。你不同意吗？应用程序总是会变的，我们在做敏捷，对吗？你能在三天内完成吗？从那以后，确保所有测试都得到良好维护”。

之后的第二天，Toby笑着来找 Russ。他说：”Russ，我找到了一个更好的测试自动化框架：Playwright，它解决了我们现有框架的问题和局限性：Cypress。我有信心在三个月内实现将 Cypress 迁移到 Playwright”。

Russ 对此不以为然：”据我所知，5 个月前是您建议用赛普拉斯来取代之前使用 TestCafe 的失败尝试。如果像你现在说的那样，赛普拉斯不好，那你当初为什么选择赛普拉斯？”Toby沉默不语。

Russ 继续说：”我们的应用程序只是一个标准的网络应用程序，从测试的角度来看，已经有 10 多年没有变化了。我曾见过一个真正的敏捷项目，其中原始的 Selenium WebDriver 测试套件实现了’每日生产发布’。那位测试自动化工程师在 Selenium 中实施了少量核心业务流程测试，并在第一天就在 CT 服务器中运行，然后每天都运行。”

Facebook 的测试金字塔，因为使用 WebDriver 进行端到端 UI 测试，所以称为 “WebDriver “层。查看 Youtube 上的 “Facebook 的持续集成 “视频。

Facebook每天发布两次，保持这种节奏是我们企业文化的核心。在这种发布节奏下，使用 Selenium 进行自动化测试对于确保发布前一切正常至关重要。—— Facebook 工程总监 DAMIEN SERENI 在 Selenium 2013 大会上的发言。

Toby说：”使用Cypress是我的失误，坦率地说，不只是我，许多其他测试人员都认为…”

Russ打断了他的话：”你们受雇是为了进行有用的测试，而不是做实验。你可以放弃Cypress，改用另一种语言。作为项目经理，我只想每天看到真正的端到端执行和测试结果。关于语言，作为一个旁观者，我不喜欢 JavaScript，原因很简单，据我所知，Cypress已经是连续第三次使用基于 JS 框架的测试自动化失败了，前两次是 Protractor 和 TestCafe。”

Toby说：”JavaScript 是最流行的…”Russ拦住Toby说：”我和我们的项目团队根本不在乎端到端脚本使用哪种语言，只要它能很好地工作，提供真正的价值。你昨天对我的请求说’是’，现在却提出了一个不同的框架。不管怎么说，三天后，我们的团队成员就会看到每天的 e2e 测试执行报告，而不管使用哪种框架或语言。重要的是：自动化端到端测试脚本可以作为最终用户每天验证功能，并在应用程序不断变化时保持有效。

三天后，Toby辞职了。在他的简历中，有这样一条记录：”在 X 公司使用Cypress成功实施了端到端测试自动化”。

项目的测试自动化之后发生了什么？Russ 很快聘请了一位充满热情的 IT 专业毕业生 Darcy，但她没有任何测试或自动化经验。他聘请了一位测试自动化教练（他之前提到过的测试自动化工程师）对Darcy进行培训。经过一天的培训，Darcy在教练的指导下开始将 Cypress 测试转换为原始的 Selenium WebDriver + RSpec。从第二天起，团队开始在 CT 服务器上看到 e2e 测试报告，发现了回归问题。

运行由 569 个原始 Selenium WebDriver + RSpec 测试组成的 WhenWise UI 回归套件。

在接下来的5个工作日内，所有Cypress测试（反正也不多）都在BA的帮助下（因为许多Cypress测试无效或无法完成）转换成了使用原始Selenium WebDriver + RSpec的更好版本，BA和手动测试人员都能轻松阅读和运行。每天至少两份自动化回归测试报告。当然，Darcy和教练必须对测试脚本进行必要的更新，因为最近的变更被签入并影响了自动化测试脚本。得益于可维护自动测试设计和良好的工具（如TestWise和BuildWise），维护工作得到了有效管理。

教练对Russ说：”Darcy学得很好，我不需要全职在这里。”他转向Darcy：”记住，每天至少运行一次整个测试套件。随着测试的不断增加，你会发现越来越难保持它们的有效性。如果你不能连续两天让所有测试都有效（PASS或有充分理由的失败），请让Russ联系我。”

这个虚构的故事融合了我的亲身经历，包括”辞职”部分和”Darcy在一天之内学会了做有用的测试”。

在这里，我想指出很多人都会忽略的一点：Russ，一位真正的敏捷经理的重要性。大多数普通项目经理虽然声称自己是敏捷项目经理，但却会容忍端到端测试自动化的造假行为。为什么呢？因为这很容易做到，因为它太常见了。一旦测试自动化成为现实，虽然听起来很美好，但却会带来未知数，也就是给某些人带来恐惧。了解端到端测试自动化重要性的优秀IT经理也很少见。

“一个团队一个梦想 “VS “改天换地”

你认为Toby的测试工作令人满意吗？当然不满意。他留下的”自动测试”有用吗？很值得怀疑。换句话说，托比是个假冒的测试自动化工程师，至少在那个项目上是这样。假自动化测试人员毁了测试自动化工程师的声誉。

有人会说：”说Toby是假冒的测试自动化工程师可能有点过分。在第一次测试指定的用户故事时，Toby可能发现了一些好的缺陷”。是的，这可能是真的。但是，人工测试人员完成这项工作的速度可能更快（而且更便宜，因为人工测试人员的工资通常更低）。请不要忘记，我们谈论的是对测试自动化工程师的期望。

工程：经过验证的可重复流程，经久耐用。

端到端测试自动化的真正威力在于回归测试，这意味着自动化测试可以每天频繁运行，尤其是在开发周期即将结束时。现在，如果有人告诉您（作为项目经理），创建的自动化测试只在当天运行。你会作何感想？

为什么Toby这样的人很常见？

与维护相比，创建端到端自动化测试非常简单。我的文章提到：”测试创建只占网络测试自动化工作的大约10%”。

公平地说，这主要不是Toby的错。我并不是在贬低那些被称为“假测试自动化工程师”的人，因为我们的IT教育（在大学层面）从未涵盖过端到端测试自动化的内容。此外，很少有公司提供相关培训或寻求外部帮助，比如真正的测试自动化辅导。与此同时，大多数软件项目都声称自己在实施敏捷开发，因此对测试自动化的需求非常大。管理层的责任在于没有充分评估这些工程师的能力，并提供全面的实践培训。

想象一下，如果托比承认自己没有测试自动化的技能，并且真心愿意学习。由于Russ的帮助，他得到了真正的培训，并且有机会与专业的测试自动化教练一起工作和学习。那真是太遗憾了！

但是我确实非常讨厌那些“造假者”，他们在见识了真正的自动化测试之后，因为觉得造假更容易，仍然继续他们的造假行为。这些人破坏了测试自动化工程师的声誉。