一个欺骗性端到端测试自动化工程师的故事

2024-07-11   出处: medium  作/译者:Zhimin Zhan / Mint

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

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

长期读者曾多次目睹我引用国际知名的敏捷和测试专家的观点,这些专家都传达了同样的信息:通过用户界面(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的帮助,他得到了真正的培训,并且有机会与专业的测试自动化教练一起工作和学习。那真是太遗憾了!

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


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
181° /1819 人阅读/0 条评论 发表评论

登录 后发表评论