2020年软件测试趋势报道：彻底实现持续测试（上）
看到国内外不少机构在总结：“2020年最好的持续测试工具”，比如：
https://www.softwaretestinghelp.com/continuous-testing-tools/
https://www.katalon.com/resources-center/blog/continuous-testing-tools/
还有的机构或公司试图给出“什么是持续测试？”的定义，比如：
https://www.guru99.com/continuous-testing.html
https://www.tricentis.com/products/what-is-continuous-testing/
这说明，随着敏捷开发和DevOps的推广，持续测试这个概念确实越来越火。但同时也发现大家对于持续测试的理解并不一致，列举的持续测试工具也五花八门。因此觉得有必要讲一讲“持续测试”这一2020年重要趋势。
什么是持续测试？
持续测试的概念有广义和狭义两种理解。广义上来说，持续交付是敏捷开发、DevOps的目标，为了实现这一目标，软件测试就要尽早测、按需测、频繁测，这体现的是软件测试在敏捷和DevOps中采取的测试策略。持续测试就是从产品发布计划开始，直到交付、运维，测试融于其中、并与开发形影不离，随时暴露出产品的质量风险，随时了解产品质量状态，从而满足持续交付对测试、质量管理所提出的新要求。从这个角度上来说，敏捷、DevOps中的一切测试活动都可以算成是持续测试，既包括测试左移，也包括测试右移；既包括持续集成中的测试活动，也包括持续集成之后、上线部署前的测试活动；既包括测试分析和设计，也包括测试执行和结果呈现/报告。
图1 敏捷、DevOps的目标：持续交付
狭义的持续测试指的是一次软件迭代开发中的主要测试活动，测试之所以会成为持续交付的瓶颈，就是因为没能做到持续测试。设计评审、单元测试、用户故事实现的验证、集成测试等，也包含持续的新功能测试和持续的回归测试，以及性能测试、安全性测试、兼容性测试等针对软件质量属性的专项测试，如图2所示。
图2 Scrum 模式下的敏捷测试流程
持续测试不等同于自动化测试，也包括手工测试，比如每次迭代中的新功能的测试采用手工（探索式测试）测试更快，因为人更灵活，更智能。再比如人工的需求评审、设计评审和代码评审（Code Review）也必不可少，这些测试左移中的测试活动帮助团队在早期预防缺陷，让随后的研发活动更顺利。采用自动化的方式尽量提高回归测试的覆盖率也非常必要，以手工测试为主肯定不可持续，要么为了赶进度，测试不充分，漏测的缺陷会越来越多，产品质量越来越差，团队会被技术债慢慢拖垮，越做越慢。要么为了测试充分，就需要大量时间，交付速度会受影响。两种情况都会让测试成为敏捷开发的瓶颈。采用自动化回归测试与手工探索式测试相结合的方式，两种测试都持续进行，才能达到质效合一。
持续测试不等同于全面测试，即使自动化测试达到很高的覆盖率，要想在每一个发布的版本上进行全面测试，也是件不可能的事情，首先是软件测试无法穷尽每条业务路径，其次也没有必要，要想做得既快又好，不仅要做加法：尽可能提高自动化测试覆盖率，让测试左移，尽可能提高单元测试、API测试的覆盖率，更要做减法，拥抱基于风险的测试策略，精准测试就是一个好例子，基于对代码变更的分析和其它信息，选择正确的测试范围，既不多测，也不少测。
持续测试不等同于持续测试工具化，持续测试需要优秀的测试工具链的支持，这个我们稍后会讲，但持续测试不能只靠工具来实现，更重要的是如何从道、法、术、器各个层面让持续交付变得无障碍。比如开发和测试的彻底融合，让沟通协作变得无障碍；比如奥地利的软件测试公司Tricentis提出的基于业务风险的测试分析方法，对产品需求根据业务风险进行量化，排序；再比如，我们可以运用各种测试设计方法以更少的测试用例覆盖更多业务风险。
持续测试是敏捷化、DevOps化的需要
在持续交付流水线中，相比持续集成、持续部署等，持续测试的建设相对落后，这也是为什么大家认为软件测试是影响持续交付主要瓶颈。持续测试作为一个主题在国内被讨论的还不多，但是在国外已经成为促进敏捷和DevOps转型的焦点之一。展望软件测试的未来，持续测试必定是未来几年里最具确定性的趋势之一。
要说起来，持续测试也不是一个新的概念，只是目前所能实现的持续测试和理想中的持续测试还有一定差距，仅仅是测试自动化一项在实践中就碰到很多问题，很多时候想快也快不起来，想连续也连续不起来，很多节点还需要靠手工完成，以便接续上后面的任务。因此，大家更加期待在不久的将来能够实现真正的、彻底的持续测试。
持续测试工具链
持续测试工具链的作用是支持测试过程能够平滑有序的进行，不仅支持各种类型的测试，而且针对对测试全过程的支持，充分体现测试的服务化，让测试想测就测、有始有终，过程无障碍。
持续测试对测试工具的需求包含三个层次：
首先，测试工具可以支持各种类型（功能、性能、安全性...）的自动化测试。
其次，从测试用例创建、测试执行到结果分析、测试报告生成，测试工具向着平台化的方向发展，将自动化扩展到整个测试生命周期，并且提供功能、性能测试服务或提供与这类工具的集成，即持续测试平台。
第三，测试工具或平台与DevOps工具链进行集成，这样才能实现和持续构建、持续集成、持续部署融为一体的持续测试。
这样来说，持续测试工具包含的范围很广，只要符合这三个层次的任何一个都可以称为持续测试工具。甚至DevOps工具链中和测试相关的工具/框架都可以算是持续测试工具。这也是为什么有人认为Jenkins、Jira、Docker这些工具也是DevOps的持续测试工具。
用单一的工具/平台支持所有的测试类型，全生命周期管理非常困难，我们应该关注的不是哪一个测试工具是持续测试工具，而是应该关注在持续测试工具链里有哪些优秀的测试工具。同时，测试工具本身也逐渐扩展到平台化、DevOps化，这也是测试工具目前的趋势。
下面就来列举一些测试工具中所包含的促进持续测试的趋势和优秀实践：
先说说持续测试工具。API（接口测试）工具代替UI自动化测试工具成为焦点。对于有条件采用API或接口测试的产品和团队，应该多开展接口测试，不仅覆盖单个接口的测试，还覆盖系统端到端的功能测试、性能测试。目前有的测试工具致力于针对API测试提供更完善的支持，为了完成API测试，我们常常需要使用Postman进行接口调试，使用WireMock等Mock工具来模拟接口响应数据，使用像Karate、Jmeter这类测试工具做接口自动化测试。这样就需要维护不同的工具，而且工具之间维护数据一致性的工作量也比较大。
这里介绍下API Fortress，这个工具（其实也是一个测试平台，这里只介绍其对于API测试的支持）对于微服务架构的软件系统提供了接口测试的持续测试解决方案。我们来看一下它提供了哪些功能，同时又怎样解决了当前自动化测试的上述痛点：
无代码化的自动化测试，从Web UI界面点击操作、规范文档或录制的流量中自动创建API功能测试的测试脚本。
可以支持API的各种测试类型，包括单个API的功能测试，压力测试，性能测试，以及API性能监控。
在研发早期通过自带的Mock功能隔离不稳定的API依赖对象对API进行测试。
支持和多种CI/CD工具以及测试管理工具的集成，比如Jenkins、GitLab、axway（API管理工具）、Zephyr（测试用例管理工具）、Jira等。
即使是UI自动化测试工具，就像上一篇文章“2020年软件测试趋势报道：无代码化的测试自动化”中介绍的，很多UI测试工具也致力于提供模块化、无代码化的自动化测试，并且也开始把自身功能扩展到API测试。
再说说持续测试平台。测试管理平台中有一些被定位为持续测试平台，这里列举两个，
一个是国内飞致云公司的开源持续测试平台MeterSphere，覆盖测试用例管理、测试计划到测试执行、测试报告分析等；支持接口的自动化测试，兼容JMeter支持分布式性能测试。
一个是Tricentis公司开发的持续测试平台Tricentis Tosca。Tricentis 公司的测试自动化产品在Gartner 魔力四象限（Magic Quadrant）中处于“LEADERS”的位置，如图3所示。
图3 测试自动化产品的Gartner 魔力四象限
Tricentis Tosca支持以下功能：
支持基于模型的UI和API自动化测试
支持服务虚拟化：通过模拟第三方系统组件为自动化测试创造一个稳定的测试环境，并且覆盖更多的异常测试场景
支持基于风险的测试需求分析，这是这个平台最具亮点之处。简单来说，用户可以在平台界面上为每个产品需求（Epic、用户故事）从两个维度（用户使用频率和失效后的影响）进行评分，然后根据评分计算每个需求的风险权重和风险贡献率。这会作为进一步进行测试用例设计，优化测试覆盖率，按照风险权重确定测试优先级，以及评估测试结果进行软件发布决策的基础。
未完待续，敬请期待“2020年软件测试趋势报道：彻底实现持续测试（中）”