第1章 持续测试概述
软件测试伴随着软件工程实践的进步也在不断地进步，它从最原始的开发调试中分离出来后，在瀑布模式的软件工程实践中摸索了很长时间，目前软件测试已经贯穿软件交付生命周期的全流程。这种在软件交付生命周期的每个阶段都存在测试活动的实践就是持续测试。
1.1 概述
持续测试并不是什么全新的测试技术、测试方法，而是一种测试实践方法。Tricentis公司的CMO（Chief Marketing Officer，首席营销官）Wayne Ariola在公司博客中题为“Continuous Testing: ‘Perfect’ Software Is not the Goal”的文章中给出了持续测试的定义：
持续测试侧重于业务风险并提供有关软件是否可以发布的决策基础。自动化测试对于连续测试至关重要，但它并非全部。自动化测试旨在生成一组与用户故事或应用需求相关的通过/失败数据检查点，而持续测试侧重于业务风险并提供有关软件是否可以发布的决策基础。除将测试用例自动化之外，持续测试还包括业务风险验证、应用服务虚拟化和状态化测试数据管理等以稳定持续测试；在每次迭代中使用探索性测试尽早发现阻碍性问题等实践。这不仅意味着使用更多的不同的工具，还要求包括技术在内的人和流程的深度转变。
Thomas Hamilton在“Continuous Testing in DevOps: What is, Definition, Benefit, Tools”文章中也给出了持续测试的定义：
持续测试是DevOps中的一种软件测试类型，它主要约束在软件开发生命周期中任何阶段都有对应的测试活动，从而尽早进行频繁的测试，这也就做到了在持续交付过程中每一步都有了质量评价活动从而实现了持续测试。
除这两种解释以外，还有很多其他解释，但是都没有说清楚持续测试是什么。
持续测试其实就是一种新的测试实践，指在软件交付生命周期中，以防控业务风险为目的，对每一个业务交付阶段都辅以测试活动进行质量保障，并尽最大可能自动化，通过测试结果不断反馈给制品交付过程的测试实践活动。
随着当今软件行业的发展，信息技术的快速进步，以及人们对软件系统的理解，一次性交付一个功能完善、质量完美的系统已经不再是首要任务。快速交付一个满足用户最需要的功能的系统，后续通过快速迭代逐渐完善成为当前的主流。在这种快速交付、快速迭代的要求之下，每次交付系统时，所有的领导都会问测试工程师同一个问题：“测试完了吗？”此时，如果测试工程师还抱着原来做测试的思想，就很难在短时间内回答领导的问题，而持续测试能够解决这种问题。
持续测试就是从产品发布计划开始，直到交付、运维，测试融于其中并贯穿整个开发过程，随时暴露出产品的质量风险，随时了解产品质量状态，从而满足持续交付对测试、质量管理所提出的新要求。
为了能够帮助团队构建更高质量的软件系统，测试工程师必须在整个交付过程中不断地运行测试（这里的测试既包含自动化测试，也包含手工测试），以验证开发中的系统的功能和架构。为了达到这个目标，测试人员需要从组织上和技术上共同推进。
在组织上，要允许测试工程师在整个软件交付过程与开发工程师、产品经理乃至运维工程师相互协作，从而建立制品团队共同交付高质量系统的文化。同时，在整个测试过程中，要充分发挥测试工程师的能力，广泛实现和推广探索测试。
在技术方面，最好维护一套行之有效的分层自动化测试解决方案。这里面既包含单元测试、接口自动化测试，也包含UI自动化测试，这样才能将质量保障工作和持续交付流水线集成到一起，通过流水线触发自动部署、自动测试，然后交付给测试工程师，完成人工主导的探索测试和可用性测试。
最后，如果在测试工程师工作步骤中未发现任何错误，则应用可以发布。通过流水线大大减少了从代码合并到发布整个过程的工作量，降低了生产环境中的错误率，开发者的绝大部分代码可以在很短的时间内完成验证，因此他们也可以快速完成修复，这就是持续测试的优越性。这也说明持续测试并非创新，而是另外一种实现方式，因此软件测试行业中已有的理论、方法在持续测试中仍然适用。
