正如一千个人心中有一千个哈姆雷特,一千个软件开发团队有一种个DevOps落地方法，也就有一千种持续测试实践。
持续测试和自动化测试的关系
持续测试是在软件交付生命周期过程中，以防控业务风险为目的，将每一个阶段都通过测试活动进行质量保障，并尽最大可能自动化测试活动，并将测试结果不断的反馈给制品过程的测试实践活动就是持续测试。通过持续测试的定义我们可以知道，尽最大可能自动化测试活动将会是持续测试是否能够落地实践的重要手段。
持续测试包含了两部分实践约束：
- 第一部分是每一个DevOps中的阶段都应该有对应的质量保障活动的存在
- 第二部分持续不断的将测试结果反馈到制品过程中进行改进
那么如果要实现如上两种重要的实践，自动化将会是不可避免落地的实践方法。自动化测试设计对团队的测试资产的积累，自动化测试是实现持续测试的必要手段，但是拥有了自动化测试并不一定就实践了持续测试。我们常说的自动化测试包含了API自动化测试、UI自动化测试，那么这两种自动化测试都是功能性验证，持续测试在前面我们也已经说过，除了功能性验证，非功能性需求也是必将被考核的一部分。
自动化测试的目的是结果验证，如果测试失败说明了被测试系统有些不满足预期内容，但是持续测试保障的是风险预防，通过devops每一个阶段都进行质量保障活动，通过层层质量保障最后交付一下优秀的系统，通过自动化的效率提升从而达到交付一个又快又好的系统（JKK）的目的。持续测试还隐含了持续反馈，缩短了从发现问题到解决问题的循环时间，从而在单位时间内加大了PDCA循环，从而通过质量运营实现了质量提升。
持续测试还关注什么质量特性
持续测试是一种测试实践，因此它也是站在质量模型之上做的质量特性的验证。持续测试并不是变革性的，而是基于之前测试经验基础之上的。因此在持续测试在测试分类上也包含了功能性需求和非功能性需求的验证。
从质量模型上我们知道，质量模型也有各式各样的包含层次模型、关系模型、构建模型等，当前比较流行的还是层次模型中的ISO25010，因此持续测试同样关注ISO25010的质量特性，包含了：功能适合性（Functional suitability）、性能效率（Performance Efficiency）、兼容性（Compatibility）、易用性（Usability）、可靠性（Reliability）、安全性（Security）、可维护性（Maintainability）、可移植性（Portability）等。
持续测试和质量保障的关系
质量保障（Quality Assurance，简称QA)最为根本的含义就是通过一系列的标准化的程序或者流程，保障交付给客户的软件或者服务所应该具有的质量水平。质量保障和实际的测试还是有区别的，质量保障（QA）不涉及软件产品的实际测试方法、过程，质量保障工程师更加专注于帮助公司创建满足业务方期望的流程方法从而提高客户忠诚度，因此可以看出质量保障是面向过程的。
软件测试是为了发现软件定义问题和内部存在缺陷的实践方法。因此可以看出软件测试和质量保障是解决不同问题而存在的，那么质量保障和软件测试也不是说完全无关的，在实践中，质量保障工程师以协同不同团队工作为主，通过不断的度量从而督促各个团队的持续改进，而开发工程师、测试工程师共同为100%的又快又好的交付系统负责。质量保障工程师应该和制品团队一起为最大限度的交付高质量的软件而努力，最好的实践方法就是通过持续测试实践，在持续测试过程中嵌入质量保障工程师，从而促使质量保障工程师的工作是制品过程中发挥作用而不是在制品后发挥作用的。
安利一下新书
《接口测试方法论》这本书是我在极客时间上接近2万人都在学习的专栏“接口测试入门课“的扩展，本书从接口测试相关基础理论到实践应用对接口测试做了系统化的讲解。站在对于接口测试的角度，回答了为什么要有接口测试框架，怎么创建接口测试框架以及如何打造一个成熟的测试框架等问题。 从使用工具完成接口测试到自己写代码完成接口测试，然后慢慢封装自己的框架，最后走到让测试框架更智能的技术路线上，这一路我走了十几年，走过不少弯路也淌过不少坑。
