纠正两个常见的错误观念。端到端测试自动化是 "简单而容易 "还是 "复杂而不可能
blog
纠正两个常见的错误观念。端到端测试自动化是 "简单而容易 "还是 "复杂而不可能
当前市场上各种端到端的测试工具层出不穷,工具市场很繁荣,但真正成功的项目实践却很少见。今天看到了一篇很有意思的文章,我愿称作者为典型的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自动化变得更加容易等