捕捉回放伤害了功能测试自动化

总结

作为功能测试自动化过程中的辅助手段——捕捉回放，被当做功能测试的主要方法，导致我们认为，自动化测试工作就是简单的通过捕捉回放，实现高效重复人为操作，没有留意功能测试自动化的实现，需要我们对人工测试方法重新的审视和改变，而不是只是简单的重复而已。（感觉上，即便是只在各类具体的实现层面，捕捉回放的帮助，也只涉及到30%左右的工作量。）功能测试自动化的实现，需要我们从以下角度，重新思考人工测试的工作：
l 测试逻辑和测试数据的分离和整理，实现数据驱动相同的测试逻辑模块。简单说就是，在大的人工测试工作中，发现不能重复，反复做的的小单元。
l 测试行为模式化，提取和抽象实现底层技术模块化。简单说就是将手工测试中，某些反复点击的操作序列脚本化，辅助手工测试
l 软件质量要求适当的数据覆盖，而不是停留在人为数据抽样。实现高质量的软件产品，测试行为就必然出现不同操作数据下，相同操作的序列的重复，需要自动化技术来实现。
l 业务行为模块化，模型化，可实现基于机器自我学习的业务流程自动编排各类测试逻辑，包括自动生成异常行为逻辑，提高功能测试覆盖率，高效发现缺陷，提高产品质量。
思考停止于“没有重复就无需自动化”，使我们流失了一些本可提高工作效率，提高产品质量的机会。在本文，我们主要探讨在各类组织中，自动化功能测试面临的问题和改进的可能。

捕捉回放伤害了软件功能测试自动化！

想到这个标题，难免有点标题党的味道，即使我们自己。
因为作为功能测试领域的后来者，之前的十几年中，捕捉回放功能，都是当我们寻求什么是功能测试这一问题的答案时，必然会听到的名词。久而久之，我们自然也把捕捉回放作为软件功能测试自动化工作主要的方式来看待。捕捉就是为了可以记录测试人员的手工测试工作，以通过回放提高在日后重复时的效率。
这样，引出了一个测试领域似乎放之四海而皆准“真理”。
“重复的工作，是测试自动化最有价值的地方。”

没有重复就无需自动化?

“真理”的坏处，是他阻止了我们继续思考！经验告诉我们，止步于“真理”，也会使我们失去新知。
“没有重复就无需自动化”！
当我们将功能测试理解为捕捉回放；进而认为只有重复性的工作，才有捕捉回放的价值；更进一步，只有整个测试工作需要反复做，才需要自动化功能测试。这成为我们现在大量手工测试一直延续，而无法变革的强大阻碍和支柱。这使我们很多单位和人员，痛并快乐的埋头工作着。即便是我们，也生活在这个“幸福圈”中。近年来开始做功能测试技术工作时。发现这个“真理”在功能测试，黑盒测试领域，比白盒测试领域更具影响力。几乎黑盒测试领域的每一个客户都会和我说：
“我们不像其他单位，我们的功能测试，系统测试，验收测试工作，没有重复性，自动化测试帮不到我们。xx单位需要，但我们不需要。”
和大家透露一个秘密：“常有客户都这么说！”
或许职业带来生存动力，再包裹上专业上谋求真相的好奇心，促使我们来探求，自动化功能测试方法和价值到底是什么？
首先，让我们回顾“没有重复就无需自动化”这句话的本源，它本来是体现了软件测试的经济性问题的结果之一。

自动化测试的经济性

没有绝对正确的测试方案，就像没有不存在缺陷的产品一样。具体选择的测试方法，是在投入和产出之间的一种平衡。“没有重复就无需自动化”这句话的实质，同样是来源于一个投入产出比的考量。而这种考量得到的，本不是这一简单化的结论。
也就是，我们可以把自动化技术的采用，回归到对其所带来的收益和所支付的费用之间的权衡这一个关键的决策点上来考量。
自然是一种权衡，我们就可以本质投入和产出的比较，更广泛的考虑各种自动化工作可能的投入和收益，以及相关的影响因素，使我们的工作从重复开始而不必止步，逐步探讨重复范围和定义，重复投入和产出的关系。影响这个投入产出的其他因素。这些因素和组织的工作性质，工作方式，承担责任相关。所以，我们按照不同的组织，来描述我们看到的可能性。

不同组织中的自动化功能测试

迭代化开发团队中

这些单位，往往是大家认为的xx单位。
实施迭代开发做产品的单位，似乎是大家公认，应该使用自动化功能测试的单位。但事实上，这类单位的各级测试人员，也会有不同的看法，考虑自动化功能测试的开展。
１. 编码阶段应关注白盒测试，而不是系统测试，影响了功能测试自动化的使用。
迭代化开发组织中，我们本可有机会重新审视这个可能性。白盒测试是重要的，但当我们在流程上实施Agile和DevOps变革，成为一个更加重视用户体验，拥抱需求变更，以用户需求为导向的组织时，我们更应该及早的关注用户面对的最终产品的功能界面的测试。
２. 基于界面的功能测试在编码阶段由于没有界面原型，影响了功能测试自动化的使用。
迭代开发，导致系统界面更早的被发布；设计团队可以提供快速原型，不但可以服务于用户需求沟通，而且可以作为功能测试开发的起点，实现系统测试和开发并行，测试驱动开发；着力于测试用例中测试逻辑和测试数据的分离，保证了测试逻辑的重用性。
３. 功能测试的技术限制带来的测试可用性问题，影响了功能测试自动化的使用。
新的测试技术，保证了测试可以实现和应用开发技术无关，和软件的技术架构无关，和设备的应用架构无关。系统测试自动化工作无需等待被测应用的开发，可以简单的基于可能的界面元素开展系统测试自动化的开发。
４. 功能测试的技术限制带来的测试维护问题，影响了功能测试自动化的使用。
相关项目显示，在新的基于界面图像的功能测试自动化技术支撑下，功能测试自动化开发工作中，控制界面交互的工作量，最多占用了整个测试自动化准备工作30%精力和时间；而且，编写的测试逻辑可以在不同设备上的相同应用测试中复用。
５. 功能测试的易用性涉及到测试成本和可维护性，影响了功能测试自动化的使用。
当我们在测试开发中，说到某个测试点无法实现时，更准确的内涵，实际是实现的代价高昂。现在的测试组织，往往具备软件开发背景良好的测试开发人员，对他们来说，熟悉开发技术并擅长脚本开发，使我们反而有时会忽略测试工具自身易用性的价值。实际上，工作中，我们往往需要面对的不是能不能做到的问题，而是值不值得做的问题，对于熟练的测试开发人员，一样需要易用的测试开发手段，降低测试开发成本，实现更大范围的自动化测试。

第三方评测中心中

这些单位，由于作为独立的第三方评测中心，主要的工作职责是对即将发布的应用，代表甲方提供专业的产品质量评估。所以，他们最经常做的工作就是功能测试。但是也正是他们的独特位置和职责，以及现有的工作方式，会影响自动化功能测试的开展。
１. 测试软件通常通过率较高，反复回归测试的可能性小。
建立测试脚本库，对于有升级等反复测试的项目，形成可复用的资产，也是未来新版本发布时再次获得测试在成本，技术和时间方面的优势。
２. 不同单位待测系统业务不同，脚本可重用的可能性不大。
测试行为模式化，提取和抽象不同应用中，类似的测试操作，实现底层技术模块化。简单说就是将手工测试中，某些反复点击的操作系列脚本化，辅助手工测试，提高测试效率，降低测试成本。

３. 测试逻辑和测试数据的分离和整理，实现数据驱动相同的测试逻辑模块。
简单说就是发现可以复用的小的重复的工作单元。着力于被测系统中业务需重复操作业务逻辑的抽取和模块化，建立基于业务关键字的“半自动化”的测试流程，提高测试效率，降低测试成本。

４. 软件质量要求适当的数据覆盖，而不是停留在人为数据抽样。
实现高质量的软件产品，需要设计合理的数据覆盖，而不是仅仅有人工任意抽取一两组数据即可完成测试。将设计好的测试数据放置在文件或数据库中，通过模块化的测试逻辑读取这些数据源，高效的完成自动化测试，提高功能测试覆盖率，提高产品质量。高质量的测试不可能没有重复，小颗粒度的功能模块。业务逻辑级别的的重复，需要自动化来实现。
５. 软件测试不但要测试软件应有的功能，还应该测试可能的异常操作。
软件验收测试，除了完成按照软件功能要求下的测试之外，还应考虑操作逻辑异常时被测系统的应对能力。软件测试逻辑自动化，脚本化，模块化后，可以利用人工智能，机器学习的算法，对可能的各类其他业务流程自动编排，快速提高功能测试覆盖率，尽可能多的发现缺陷，减少调度、时序、数据组合等类型脚本的编写量。
第三方验收测试工作，经常在软件开发结束即将发布时才介入，面对的测试对象业务上纷繁复杂，留给组织的测试时间是有限的，应用的业务学习时间也是有限的。上诉的自动化测试设计技术，可以帮助第三方软件评测中心单位时间内，提高产品质量。当然，结合细致的前期准备，重新梳理日程的测试工作，组织上的配合，实现会更加顺畅。
６. 对被测软件没有界面的快速原型和功能需求，没有时间开发自动化测试。
像开发单位一样，有这些需求文档，可以帮助第三方软件评测中心实现测试和开发并行，这是提高测试效率，提高产品质量的重要手段。应在组织和沟通上设法改善，是自动化测试更能发挥作用。
７. 被测试软件质量要求不高，对测试数据的覆盖没有要求。
像之前谈到的，作为手工测试的辅助手段，基于图像的自动化功能测试工具可以做到简便易用，在较小的耗费之下，可以帮助手工测试人员自动化某些需要反复手工操作的环节，提高手工测试的效率，例如，测试环境的批量搭建，反复的应用登录行为，应用的打开和基本的输入，测试行为的无人值守的操作，例如批量截图等辅助工作。

高质量要求的产品系统测试中

这些单位，由于他们的软件或系统，往往涉及人的生命，大量的金钱或社会影响，所以，对软件的质量提出较高的要求。被测软件往往测试逻辑复杂，测试数据海量，甚至关键输入要求遍历。大量的人工的，不可重复的，难以审计的的局面应该着力改观；没有可重用的自动化模块，使测试本身的质量依赖于人员和团队的能力，而得不到稳步的积累和提高。系统测试，或工程现场部署测试的工作往往只做一两次有限的迭代，只是记录认为操作的录制回放成为没有价值的额外负担。
这些单位对于功能自动化测试技术的采用，除了可以继承以上两种类型单位的使用场景之外，还可以更进一步的考虑，

1. 测试行为的模块化。
   测试逻辑和测试数据的分离和整理，实现数据驱动相同的测试逻辑模块。即抽取测试中反复执行的业务逻辑，模块化，重复输入测试数据，高效实现遍历。
   应着力于被测系统中业务可重复操作序列的抽取和模块化，可以考虑以功能菜单和子菜单为单位总结业务逻辑形成模块，为第一层的业务模块,例如登录，订酒店，搜索酒店，功能模块往往可划分为菜单上显示的功能，和这些功能实现时，一些有公用价值的子功能；在其下层，建立和数据或界面进行交互和验证的技术模块，完成抽取和封装，为第二层的技术模块，例如，滚动到上面的特定文本，选择检查框，切换窗口等。
2. 测试数据和测试逻辑的遍历。
   将可能合理的测试数据记录整理在文件或数据库中，可以有自动化工具逐行读取和整理，对输入没有限制的界面，应该考虑各类异常数据也要加入到测试数据中。
   使用人工智能，机器学习的算法，发现可能的各类正常和异常的业务流程自动编排，测试应用的异常处理能力，快速提高功能测试覆盖率，尽可能多的发现缺陷，减少调度、时序、数据组合等类型脚本的编写量。
3. 关键字驱动技术。
   实现测试设计和测试执行的组织人员的分离，实现测试逻辑和测试数据的分离，做“半自动化”测试。

后记

已知缺陷的来源分析，也很重要，因为不是这里谈论的重点，我们附一张图，作为提要吧。

作为一个从业几十年的软件工程咨询人员，开始涉及功能测试也才几年，同时实践工作的经验也不能和大家相比，一直不敢贸然在各位同仁面前谈自己的感觉。后来一想，工作中的点滴感受，与其说是拿来和大家分享，不如说，是请大家指正。也不隐晦工作职责的原因，位置决定思想的嫌疑，是一定有可能的，所以更应把这些想法拿出来请教大家，也就贸然发表了。
听说我们东边的邻国，天性有崇尚“自动化”的习惯，常常做出自动售卖机，自动拉面机，仿真机器人此类的产品。还手机上，看到德国的大型打鸡蛋的流水线。他们真的自动的可以了。相比之下，我们日常工作中，常常和客户解释如何应对工具引入后，可以解决人工测试也难得一见的难题，其实也有可能代表了我们严谨细密的工作态度，这一切都是和风细雨之前的小考验啦。
好了，完工。 ：-）