全程软件自动测试介绍

软件自动化测试的概念

“什么是软件自动化测试？”也许很多人的回答是：“使用自动化测试工具或者编写自动化脚本来自动化测试软件”，还有一些权威网站，比如WikiPedia是这样定义的：

“在软件测试中，自动化测试指的是使用独立于待测软件的其他软件来自动执行测试、比较实际结果与预期并生成测试报告这一过程。在测试流程已经确定后，测试自动化可以自动执行一些重复但必要的测试工作，也可以完成手动测试几乎不可能完成的测试。对持续交付和持续集成的开发方式而言，测试自动化是至关重要的。”

这些回答都没有错，都说到了基本的关键点上。但是自动化测试不仅是编写自动化测试代码和使用自动化测试工具这么简单，就像软件开发本身也不仅仅是编写代码这么简单。

我将自动化测试分为狭义的自动化测试和广义的自动化测试。狭义的自动化测试主要指通过编写自动化测试代码和使用自动化测试工具，将测试用例自动起来去测试被测系统。而广义的自动化测试则是将其看作一个独立的软件项目，要完成它则需要经历整个软件开发生命周期（SDLC）的各个阶段，如分析、架构、开发、测试和上线等。就算只使用自动化测试工具，不需要写代码来进行测试，也是会包含这些阶段的。只不过有时候，一些小项目中有些阶段很短，工作量也很少，就算做了，也不会有强烈的感知。但是在很多大项目中，大部分阶段感知比较强烈。所有软件自动化测试就好比一只麻雀，虽小却五脏俱全。

要进行广义的自动化测试，首先需要对项目进行，包括业务需求、技术架构、研发计划、管理流程和质量需求等。通过这些分析，可以有效地制定自动化测试策略和计划，从而获得合理的ROI，这样才能保证自动化测试有效地实施，并获得期望的结果。

然后根据自动化测试策略和计划，设计自动化测试的架构，并完成相应的调研和预演工作。在设计体系结构时，可能仅仅选择一个成熟的自动测试工具，如 Selenium IDE, PostMan, JMeter等；可能选择一个需要二次开发的自动化测试框架和测试驱动，如 Cucumber, JUnit, Mocha, Gatling, SeleniumWebDriver, RestAssured, Cypress等；可能已经存在的自动测试工具或框架都不适合自己的项目，因此重新开发适合自己项目的自动化测试工具或框架。重新造轮子的情况虽然不是很普遍，但是总有人和项目会遇到一些新的问题，并且通过当前已有的工具和框架不容易解决，而需要开发新的自动化测试工具或者框架。因此出现了数量众多的自动化测试工具和框架，所以如果不全新开发，则需要在如此多的工具和框架中选择适合的，这是设计和架构阶段很重要且相对比较困难的工作。因为要了解并熟悉尽可能多的工具和框架，才能尽可能地选择最适合的。

当策略、设计和架构都已经确定并完成之后，则需要进行开发和测试。主要内容是通过使用自动化测试工具实现测试用例自动化，或者是通过编写代码实现测试用例自动化。并在开发过程中完成对于自动化测试本身的测试，类似于开发人员编写完代码之后的自测。由于成本等原因，一般不会有另外的人员来对自动化测试进行二次测试，所以自动化测试开发人员需要充分自我保证自动化测试的正确性和有效性。如果其存在问题，而自测的时候又没有发现，则很难再次被发现，并造成自动化测试失效，最终就无法发现被测系统的bug。为了解决这个问题，业界出现了变异测试（Mutation Test），用以检测自动化测试的有效性，从而可以缓解这个问题。

开发和测试完成之后，就需要上线并运维了。上线就是将自动化测试部署到测试环境中，运行自动化测试对被测系统进行测试；而运维则是需要对运行中的自动化测试进行监控，对自动化测试的结果和日志进行分析等，特别是针对大规模的自动化测试。

不管是狭义的自动化测试，还是广义的自动化测试，其核心是以软件测试为需求的软件开发，所以要做好自动化测试，需要以软件开发的视角来对待，只有这样才能做好自动化测试，特别是大规模的自动化测试。

软件自动化测试的意义

随着软件系统的规模越来越大，涉及的领域越来越多，软件测试也越来越困难和复杂，而人工测试的问题也越来越明显。自动化测试可以改善或者解决人工测试的这些问题，所以软件自动化测试的意义主要包括：

极大地减少回归人工测试的成本
极大地提高测试的执行效率
可以避免测试人员由于各种不确定的情况所导致测试疏漏，误判等错误
可以完成一些人工无法或者很难完成的测试，比如性能测试，模糊测试等
作为测试驱动开发（TDD）和DevOps等的关键实践，帮助团队更高效地开发出高质量的软件

虽然自动化测试有这么多好处，但是仍有不少局限，比如需要相应的开发和维护成本，需要对测试结果和日志进行分析的成本，以及相应的测试环境成本等。但是这些成本的大小，依赖于自动化测试的规模和被测系统的复杂度等。

自动化测试的意义和优点

自动化测试（尤其是单元测试的自动化），是极限编程和敏捷软件开发的一个关键特征，这也被称为测试驱动开发 (TDD)。单元测试的用例可以在代码编写完成之前就设计好，并作为功能的一种定义形式存在。随着新的代码不断完成编写，单元测试随之进行，缺陷被不断找出，因而代码也不断得到改进。由于开发人员能够及时发现缺陷然后立即作出改变，修复的代价大大减小，这种不断发展的开发方式被认为比瀑布模型这类开发结束再测试的方式更为可靠。

使用单元测试框架（如JUnit、NUnit等“xUnit”类型测试框架）执行自动化测试是目前软件开发行业的大趋势。单元测试框架的应用使得各部分代码开发完成后立即进行相关单元测试来验证它们是否如预期在运行成为可能。

手工完成一些软件测试的工作（例如大量的低级接口的回归测试）十分艰苦耗时，而且寻找某些种类的缺陷时效率并不高，因而测试自动化，提供一种完成这类工作的有效方法。

一旦自动化测试方法开发完成，日后的测试工作将可以高效循环完成。很多时候这是针对软件产品进行长期回归测试的高效方法。毕竟，早期一个微小的补丁中引入的回归问题可能在日后导致巨大的损失。

全程软件自动化测试

全程软件测试已经是一个成熟并且比较普及的概念，但是由于自动化测试技术本身的一些局限和普及率，导致全程软件自动化测试对于很多团队来讲还是一个不知道或者可望而不可及的实践。但是随着自动化测试技术的发展，比如基于自然语言的自动化测试框架（Cucumber，Concordion等）出现，使得业务分析阶段就可以产出一些自动化测试可以直接使用的测试用例；比如高速稳定易用的Web UI自动化测试工具（Cypress和TestCafe等）的出现，使得基于Web UI的大规模功能测试，加入日常的持续集成流水线成为了可能；比如基础设施技术（Docker，Prometheus 和Google Analytics等）的成熟，从而可以更容易和安全地在产品环境实施并监控自动化测试。并且随着敏捷开发和DevOps的理念和实践的普及，全程软件自动化测试的思想越来越容易被接受，实施成本会越来越低，从而真正实现全程软件自动化测试。

1、测试左移与自动化测试

测试左移是预防缺陷最有效的方法和实践之一，它的核心理念就是缺陷发现得越早，修复的成本越低，比如修复的时间长短和人力成本。从而可以实现质量内建，并且尽可能在相同的研发周期内获得更高的质量。它的核心实践就是将测试工作左移到软件开发生命周期（SDLC）中开发之前的阶段，比如业务分析阶段。利用测试分析的各种方法帮助业务人员发现一个不合理的业务需求，帮助开发人员理解业务需求，发现其中的一些思考的盲点，从而尽可能地避免将这些问题遗留给开发人员。

2、持续集成与自动化测试

持续集成（CI）是敏捷开发中非常重要的一个实践，其核心就是开发人员频繁地将工作产出（比如代码等）集成在一起，并通过各种方法（比如编译，测试等）来验证它们集成在一起之后是否存在问题。这种实践可以尽可能早地发现软件的很多问题，但是发现问题的时间点和数量很大程度依赖于其中自动化测试执行的速度和覆盖率。

3、测试右移与自动化测试

随着软件系统的技术架构，基础设施和业务复杂度的不断高速增长，软件系统在产品环境的问题越来越多。所以如果能快速发现产品环境的问题，则可能减少很多损失；或者能持续发现产品环境上的问题，并能自动生成重现问题的自动测试用例，则可以持续提高自动化测试的有效性。

4、敏捷开发、DevOps、持续测试与自动化测试

敏捷开发和DevOps是现代软件开发，交付和运维中非常流行和重要的两个思想。经过多年的发展，它们分别包含了很多的方法和实践。在它们共同的实践中，自动化测试占到了非常重要的位置。可以毫不避讳的说，如果没有自动化测试，敏捷开发就很难敏捷起来，DevOps几乎无法做到其希望的快捷，频繁和可靠的交付软件。
而持续测试更是需要大规模的自动测试才能真正的高效实施，否则更多的则是缘木求鱼。

对于全程软件测试中的自动化测试，需要通过测试前移来进行自动化测试策略，分析和设计等，通过在开发中实施持续自动化测试，并在系统交付后在线上仍然进行自动化测试，并结合敏捷开发，DevOps等思想和实践，从而真正的实施全程软件自动化测试。

小结

软件自动化测试一直都被很多人诟病成本高，难以实施，不仅是因为它确实需要一定的成本，还因为大量编写自动测试的人员并不具备专业的自动化测试开发技能，包括代码编写技能，软件设计技能，测试工具和框架的熟悉度，基础设施的熟悉程度等等。但是由于软件规模和复杂度的增加，以及软件交付周期的缩短，团队必须通过实施自动化测试来应对大规模和高复杂度的软件，以及符合业务需求的交付周期。

另外，由于现代自动化测试技术的蓬勃发展，在整个软件开发生命周期中的各个阶段都能使用自动化测试技术来进行一定自动化测试的工作。随着技术的发展和普及，各个阶段的自动化测试程度会越来越高，从而可以更好地实现全程软件自动化测试。