【CC说】用一页纸“自动化测试画布”治理自动化测试

随着Devops和Agile的持续推进，很多公司都把自动化测试作为了持续交付上的一个最佳实践，自动化测试的好处我们在这里不再累述，通常实践下来会遇到以下几个难点：

• 自动化测试代码日渐庞大，维护性成本高
• 为追求自动化测试覆盖率，测试代码前期没有明确的设计，后期发现代码的扩展性困难
• 自动化测试并没有嵌入持续交付流水线，无法形成系统上的质量把关

基于上面的难点，不少的测试主管在新接手一个团队或者领导要求去梳理自动化测试库的要求都头痛不止，那么大的一个代码库怎么样能够更好的去梳理呢？

通常，当大家开始梳理一件事情的时候，善于使用的方法是分类统计，怎么将一个分类统计的事情能做的更简单易懂且团队里能快速的达成共识，这里推荐一个工具，叫做”自动化测试画布“。

Test Suite Canvas.png

自动化测试画布准确的定义为自动化测试套件画布(TEST SUITE这个名词翻译为测试套件，总觉得怪怪的，又没找到特别好的定义，有好建议的小伙伴请留言)

画布里面包括了八个方面：

1. 原因 ：在这个套件中是试图测试什么业务场景，减轻了什么样的风险。（比如测试一个汇率换算的交易场景，减轻汇率波动时测试人员需要持续监测系统的工作）
2. 依赖：当需要这个测试套件运行成功的时候，有什么样的系统或者工具必须运行正常。（比如测试一个交易时，交易双方的后台系统需要运行）
   3.约束：若此测试套件想测试一个复杂的业务场景，有什么约束了我们此测试更多的条件，有没有什么对应的代替措施？（比如写出Mock的系统）
   4.流水化：此测试套件是否为测试流水化中的一部分？若是，它什么时候会被触发？执行的频率如何?
   5.数据：执行此测试的时候，是否需要Mock，查询或者注入一些数据？测试数据是如何被管理的？（比如测试一个登录功能，可能就需要有效，无效等一套数据进行测试）
   6.默认规则和错误处理：谁创建了这个测试套件，目前是谁在维护？谁会来进行错误修复当测试套件出错的时候？（比如一个公司里有很多人都在维护测试代码的时候，知道负责人是很关键的）
   7.维护性：此测试套件是否经过了代码评审？是否有相关的文档对应？（CC先生认为，注释就是代码最好的文档形式）
   8.有效性：如何知道此测试套件的有效性？它主要测试出了什么问题，是为了预防什么错误的发生？（比如测试一个汇率换算的交易场景可能就是因为当时汇率换算的时候有汇率兑换有误，需要预防不正常的汇率兑换发生）

当然在画布上，你可能最需要写的是测试套件（TEST SUITE）的名字。

此画布比较适合用来做团队对自动化测试库的一个梳理，特别是测试库年代久远以后的历史梳理。

此画布出自ahunsberger分享的一个项目： https://github.com/ahunsberger

其中提到的流水线也可以参考她画的如下流水线，很有参考性：

TEST SUITE PIPELINE.png

实践出真知，下次梳理自动化测试用例库的时候，小伙伴们不妨试试此工具。