自动化测试思路：先思考测试，再思考自动化，切莫本末倒置
上一篇 / 下一篇 2023-05-08 17:23:43 / 个人分类：自动化测试
写在前面
这篇文章译自测试人James Bach的《Test Automation Snake Oil》一文，是笔者在学习和研究探索性测试时偶然发现的一篇较有意义的文章，很好地解答了我们对自动化测试的疑惑。 加我VX：atstudy-js 回复“测试”，进入 自动化测试学习交流群~~
比如自动化测试是否可以替代一切，还给我们提供了可行性很强的建议。
正如作者所说：先思考测试，再思考自动化，切莫本末倒置。
案例分析
先看几个案例。
案例1
一个产品从开发运维人员传递到下一个。
新开发人员发现产品设计文档已经过时，构建过程被破坏了。经过一个月的分析，每个人都宣称自己的设计很差，并坚持重写大部分代码。再过几个月，开发人员要么辞职，要么被重新分配，如此循环往复。
案例2
一个产品在开发过程中被匆忙完成，开发人员没有充分理解它应该解决的问题。
交付几个月后，审查发现问题，运行和维护系统的成本比自动化执行的流程的成本要高。
案例4
编写软件是为了自动化一组的业务任务，但是任务变化太大，导致项目远远落后于进度，系统的输出也不可靠。为了帮助手工完成任务，开发人员会周期性地退出项目，这使得他们在软件上的落后程度进一步加深。
案例5
一个由数百个几乎独立的功能组成的程序，只经过了基本的测试就投入使用，就在交付之前，作为调试的一部分，很大一部分功能被停用。几乎过了一年，才有人发现这些功能不见了。
这些都是我自己的经历，但我打赌它们听起来很熟悉。人们经常抱怨大多数软件项目都失败了，这也不该惊讶——从外部来看，软件似乎很简单，但魔鬼就藏在细节中，不是吗？
经验丰富的软件工程师知道这一点，并以警惕的眼光和怀疑的心态来对待每个新项目。
自动化测试也很困难，再看一下上面的五个例子，它们不是来自产品开发项目，相反，它们每一个都是自动化测试的成果。
在我管理测试团队和与测试自动化一起工作的9年里(注意，在一些软件行业最时髦、最富有的公司)，我获得的最重要的洞察力是，测试软件项目和任何其他软件项目一样容易失败。
事实上，在我的经验中，他们失败的频率更高，主要是因为大多数组织没有像对待交付产品那样，对他们的测试件报以同样的关心。
奇怪的是，几乎所有的测试专家、实践测试人员、测试经理，当然还有销售测试工具的公司，都以压倒性的热情推荐测试自动化。
好吧，也许用“奇怪”这个词并不合适，毕竟CASE工具曾经风行一时，测试工具只是CASE的另一种。
从面向对象到“无程序员”编程，对我们这个行业来说，不切实际的鼓吹并不是什么新鲜事。
因此，也许关于测试自动化的公开信息和分析质量不高并不奇怪，而仅仅是该领域不成熟的标志。
也许我们还处于赞赏测试自动化很酷的想法阶段，还没有到认识到它的陷阱的地步。
比起其他测试任务，我更喜欢做自动化。大多数全职测试人员，以及可能所有的开发人员都梦想着可以按下一个巨大的绿色按钮，让一个充满忠诚的机器人的实验室去做艰难的测试工作，解放自己去做其他事，比如玩游戏。然而，我们想要实现这样的梦想，就必须谨慎行事。
本文对GUI应用回归测试自动化的“脚本和回放”进行了批判性分析。
剖析自动化测试
揭穿经典自动化的理由
“自动化测试在没有人为干预的情况下执行一系列操作，这种方法有助于消除人为错误，并提供更快的结果。由于大多数产品需要多次测试，而自动化测试通常会带来显著的人工成本节省。通常，一个公司在运行两到三次自动化测试后，就会超过劳动力成本的盈亏平衡点。”
这句话来自于一个领先的测试工具供应商发布的关于测试自动化的白皮书，类似的声明可以在大多数商业回归测试工具的广告和文档中找到。
有时，文档中还夹杂着令人印象深刻的图表，这些说法与图标可以归结为：计算机比人类更快、更便宜、更可靠，因此选择自动化。
这种推理基于许多不顾后果的假设，让我们来看看其中的8个：
鲁莽假设1：测试是一个“行动序列”
一种更有用的方法是将测试看作是穿插着评估的一系列交互，这些交互中有些是可预测的，有些可以用纯粹客观的术语来指定。
然而，还有许多其他的交互是复杂、模糊和不稳定的。尽管将包含给定测试的一般动作序列概念化通常是有用的，但如果我们试图将测试简化为死记硬背的一系列动作，结果将得到一个狭窄和浅层的测试集。
而人工测试则是一个容易适应变化、能够应对复杂情况的过程。人类能够检测出数百种问题模式，一眼望去，就能立刻将它们与无害的异常区分开。
人类甚至可能不会意识到他们正在进行评估，但在“行动序列”中，每一个评估都必须明确规划。测试可能看起来只是一组行动，但好的测试是一个互动的认知过程。这就是为什么自动化最好只应用于一小部分的测试，而不是大部分的测试过程。
如果你打算将所有必要的测试都执行自动化，可能会花费大量的金钱和时间来创建相对较弱的测试，这些测试忽略了许多有趣的bug，并发现许多“问题”，这些问题最终只不过是意料之外的正确行为。
鲁莽假设2：测试意味着一遍又一遍地重复相同的动作
一旦一个特定的测试用例被执行了一次，并且没有发现任何bug，那么这个测试用例找到bug的可能性就很小了，除非一个新的bug被引入到系统中。
不过，如果测试用例中有变化，就像手工执行测试时通常会出现的情况一样，那么新问题和旧问题暴露出来的可能性就会更大，可变性是手工测试相对于脚本和回放测试的一大优势。
当我在Borland的时候，电子表格组用来跟踪bug是通过自动化还是手动测试发现的——始终如一。超过80%的bug是通过手动发现的，尽管在自动化方面投入了几年的时间。
他们的理论是，手工测试的变量更多，针对新功能就更容易发现bug的特定变化领域。
高度可重复性的测试实际上可以将发现所有重要问题的几率降到最低，同理，踩着别人的脚印也可以将踩坑的几率降到最低。
鲁莽假设3：我们可以做自动化测试
一些对人来说容易的任务对计算机来说很难，也许自动化最难的部分是解释测试结果。对于GUI软件来说，在忽略无关紧要的问题的同时，自动注意到所有类别的重大问题是非常困难的。
在一个典型的创新软件项目中，高度的不确定性和变化加剧了自动化的问题。在市场驱动的软件项目中，通常使用增量开发方法，这几乎可以保证产品将发生根本性的变化。
再加上通常没有完整准确的产品规格说明，使得自动化开发有点像开车穿越无指示牌的森林：可以做到，但必须慢一点，有可能会走回头路，也可能会卡住。
即使我们有一个特定的操作序列，原则上是可以自动化的，但我们只有在拥有合适的的工具的情况下，才能做到这一点。
然而，关于工具的信息很难获得，回归测试工具的最关键的点是不可能评估的，除非我们使用该工具创建或审查工业规模的测试套件。
以下是在选择测试工具时需要考虑的一些因素，请注意，其中有多少永远无法通过阅读用户手册或观看贸易展演示来评估：
可学习性：能在短时间内掌握工具吗，是否有培训课程或书籍来帮助这个过程？
性能阐述：与手工测试相比，该工具的是否足够快，能够大幅节省测试开发和执行时间？
非侵入性：该工具模拟实际用户的效果如何，被测软件在有没有自动化的情况下是一样的吗?
鲁莽假设4:自动化测试更快，因为它不需要人工干预
所有自动化测试套件都需要人工干预，哪怕只是诊断结果和修复有问题的测试，要让一个复杂的测试套件顺利运行，也可能出乎意料地困难。
常见的罪魁祸首是被测软件的变化、内存问题、文件系统问题、网络故障以及测试工具本身的bug。
鲁莽假设5：自动化减少了人为错误
确实减少了一些错误，比如人类在被要求执行一长串测试时会犯的错误。
但其他错误被放大了，任何在生成主比较文件时未被注意到的bug都会消失。
每次执行套件时都会系统地忽略掉，或者调试过程中的一个疏忽可能会意外地使数百个测试失效。
Borland的dBase团队曾经发现，他们的套件中大约有3000个测试被硬编码报告成功，而不管产品中实际存在什么问题。为了避免这些问题，应该定期对自动化进行测试或审查。
在另一方面，使用基本的测试管理文档、报告和实践，更容易发现相应的失误。
鲁莽假设6：我们可以量化手动测试和自动化测试的成本和收益
事实是，手动测试和自动化测试实际上是两个不同的过程，而不是两种不同的方式来执行同一个过程。它们的动态是不同的，它们倾向于揭示的bug也是不同的。
因此，直接以成本或发现的bug数量来比较它们是没有意义的。
此外，最好的评估方法是在一系列真实的软件项目的背景下进行。这就是为什么我建议把测试自动化作为一个优秀的测试策略的多方面追求的一部分，而不是一个支配过程的活动，或者独立于它。
鲁莽假设7：自动化将带来“显著的劳动力成本节省”
“通常，一家公司在进行两到三次自动化测试后，就会超过劳动力成本的盈亏平衡点。”这种估计可能来自实地数据，也可能来自营销专家的想法，无论如何，这都是无稽之谈。
自动化测试的成本由几个部分组成:阐述自动化开发的成本-操作自动化测试的成本-产品变化时维护自动化的成本-其他必要的新任务的成本。
这必须与任何剩余的人工测试的成本进行权衡，这可能会相当多。事实上，我从未经历过这样的自动化，它将手动测试的需求减少到如此程度，以至于手动测试人员最终需要做的工作更少。
这些成本如何计算取决于很多因素，包括被测试的技术、使用的测试工具、测试开发人员的技能，以及测试套件的质量。
编写一个测试脚本并不一定需要很多精力，但是构建一个合适的测试工具可能需要几周或几个月的时间。决定购买哪种工具、自动化哪些测试、如何将自动化跟踪到测试过程的其余部分，当然还有学习如何使用工具，然后实际编写测试程序的过程，也是如此。
要思考出一个全面的方法来处理这个过程（即一个产生有用的产品）通常需要几个月的全职工作，如果自动化开发人员对测试自动化的问题或工具和技术的细节缺乏经验，则需要更长的时间。
持续的维护成本如何呢？大多数自动化测试的成本分析完全忽略了因为自动化而必须完成的特殊的新任务，比如：
测试用例必须被仔细地记录下来；
自动化本身必须经过测试；
每次执行套件时，都必须有人仔细检查结果，以区分假阴性和真正的bug；
必须审查待测试产品中的根本变化，以评估它们对测试套件的影响，并且可能必须编写新的测试代码来应对它们；
如果被测试的产品随后被移植到一个新的平台，甚至是同一个平台的新版本，那么必须要做移植测试。
这些新任务对测试人员的日常生活产生了重大影响，我工作过的大多数GUI软件测试团队都尝试过让所有测试人员做兼职自动化工作，但每个团队最终都放弃了这个想法，转而选择一个专门的自动化工程师或团队。
编写测试代码和执行交互式手测试是如此不同的活动，一个被分配到这两种职责的人将倾向于专注于其中一项而忽略另一项。
而且，由于自动化开发是软件开发，它需要一定的开发人才数量，有些测试人员做不到。无论如何，对自动化持严肃态度的公司通常最终会有全职员工来做这件事，而这必须计入到整体战略的成本中。
不计后果的假设8：自动化不会伤害测试项目
最后留下了我们在追求自动化策略时面临的所有问题中最棘手的一个：将我们不理解的东西自动化是危险的。
如果我们在引入自动化之前没有弄清楚测试策略，测试自动化的结果将是大量完全没有人能理解的测试代码。
随着套件的原始开发人员漂移到其他任务中，其他人接管维护工作，套件在测试团队中获得了某种归属身份。维护者害怕扔掉任何旧的测试，即使它们看起来毫无意义，因为它们可能在以后被证明是重要的。
因此，这套套件继续增加新的测试，成为一个越来越神秘的神谕，就像一些古老的喜马拉雅大师或迪士尼电影中的说话橡树。没有人知道套件实际测试的是什么，也没有人知道产品“通过测试套件”意味着什么，而且规模越大，就越不可能有人不费苦心地去寻找。
这种情况在我个人身上发生过（不止一次，在我吸取教训之前），我也看到和听说过这种情况发生在许多其他测试经理身上。
大多数人甚至没有意识到这是一个问题，直到有一天一个开发经理问测试套件覆盖了什么，不覆盖什么，没有人能够给出答案。
或者有一天，在最需要它的时候，整个测试系统崩溃了，并且没有手动的过程来进行备份。这种情况的讽刺之处在于，诚实地尝试更专业地进行测试，最终可能会确保它是盲目和无知地完成的。
手动测试策略也可能会受到混淆的影响，但是当测试是从相对较小的一组原则或文档动态创建时，审查和调整策略就容易得多。是的，手动测试速度较慢，但更灵活，它可以应对不完整和不断变化的产品和规格的混乱。
一种明智的自动化方法
尽管本文提出了关注，但我确实相信测试自动化，毕竟我是一名测试自动化顾问。
就像可以有高质量的软件一样，也可以有高质量的自动化测试。然而，要创建好的测试自动化，我们必须小心谨慎，这条道路充满了陷阱。以下是一些需要牢记的关键原则:
仔细区分自动化和它所自动化的过程。测试过程应该是一种便于审查的形式，并映射到自动化过程中，套件将与人工测试一起使用，而不是作为人工测试的替代品。
仔细选择测试工具。从其他测试人员和组织收集经验，在购买之前尝试候选工具的评估版本。
仔细考虑购买或构建一个测试管理工具，一个好的测试管理系统可以真正帮助使套件更可查看和可维护。
确保测试套件的每一次执行都会产生一个状态报告，其中包括哪些测试通过了，哪些测试失败了，以及实际发现的bug。该报告还应详细说明为维护或增强套件所做的任何工作，我发现这些报告是分析自动化的成本效益的不可或缺的原始材料。
确保产品足够成熟，使不断更改测试的维护成本不会压倒所提供的任何好处。
几年前的一天，在一场猛烈的夜间风暴中发生了一次停电，影响了我们团队创建的测试套件。当我们第二天早上到达工作地点时，我们发现我们的套件已经自动重启了自己，重置了网络，从中断的地方重新开始，并完成了测试。
为了让我们的套件变得如此防弹，我们做了很多工作，我们很高兴。事情是这样的，我们后来在审查套件中的测试脚本时发现，在大约450个测试中，只有大约18个测试是真正有用的。
这是一个很长的故事，但它的结果是，我们有一个可靠性极高测试套件，发现我们正在测试的软件的任何重要的bug。
我已经把这个故事告诉了其他不以为然的测试经理,他们不认为这种事情会发生在他们身上，但如果测试的机器让你从测试的技巧上分心，它就会发生。
自动化是个好想法，但要让它成为一项好的投资，秘诀是先考虑测试，然后再考虑自动化。如果测试是为了了解软件质量的一种手段，那么自动化只是一种手段中的手段。你不会从广告中了解到这一点，但它只是支持有效软件测试的众多策略之一。
最后：
TAG: