【测试工程思考】测试自动化基础能力建设

1 回顾

传统软件研发体系下定义的软件测试是从用户视角设计的。测试是试图穷尽用户行为的工程，从测试用例（use case）的英文定义就可见一般。测试的逻辑资产就是用自然语言去描述用户的操作行为或路径。

但随着软件工程向分布式架构和敏捷交付的变革。软件设计变得比以前更加复杂，要验证一个分布式部署的微服务架构应用，简单的use case根本无法发掘应用的质量风险。一个无论是代码上还是能力上都高度依赖其他组件/模块的应用，都允许测试还像对待黑盒一样对他们的测试对象进行质量评估。测试需要有更细致，更全局，更系统的洞察力去识别潜在的质量风险。因此，“测试”这个工种在更多的团队里被定义成概念更宽泛的QA。

2 测试自动化的语言学原理

被测对象是用编程语言构筑的，如果测试用例是自然语言编写的，那从测试用例作用到被测对象，是需要多轮语义转译的。从单元测试中获得灵感，如果我们的测试用例和被测对象用同样的语言，这种语言上的同构会省掉语义转译的麻烦。让我们的测试能够像探针一样，深入到代码逻辑的缝隙，做更有针对性的观测和假设验证。

• 微服务应用的验证那就基于API/SDK定义的schema驱动测试。测试断言可以精确到每个接口返回的字段（这是自然语言用例观测不到的）
• 应用可靠可用性的验证就用打桩的方式改变一部分组件代码的返回结果作为假设来触发单点故障
• 大规模背景数据模拟或者数据迁移的验证就直接用脚本访问数据库，比通过接口请求更加快捷。

因此QA的能力要求在此基础上变得更高，除了编程基础，还需要更系统的分析和动手等综合能力。因此越来越多的测试工程师职位转变为“测试开发”。

3. 自动化代码在测试工程中的重要性

3.1 代码即生产力

自动化框架的设计结构将测试脚本的开发变成搭积木游戏或者是数据集驱动的盲盒游戏。一个验证动作，手动执行永远是重复最小粒度的操作，AW的灵活组合，可以快速生产出新的业务逻辑的测试脚本来。

对于较小的改动或粒度比较小的需求，高优先级的脚本用例和文本用例可以同时编写，一些不明确的预期结果可以立马呈现出结果。

对于一个即将生成50-100个大特性的需求来说，直接用自动化构筑验证任务，比写文本用例高效得多。

3.2 代码即资产

测试代码被纳入版本管理工具，有系统性的组织和传递，除了要求测试代码符合公司的自动化规范，还要小组内部达成一致：

• 对齐频繁调用的公共AW，查漏补缺，统一路径，避免多个地方重复出现功能一致的AW
• 对齐脚本组织结构和特性树，测试脚本不是业务代码，是为了提高测试效率的测试语言，要能有助于快速执行继承和回归测试
• 对齐自动化实现的层级和事件节点，不同分级的用例不但表征用例的优先级，也可以作为用例自动化的优先级：优先级越高的用例，越早实现
• 对齐AW封装程度：AW封装程度越高，测试脚本越简洁直观，但是会提高定位成本和学习成本，复杂的封装关系蒙蔽了测试逻辑本身就适得其反了。

3.3 代码即知识——why use it

敏捷开发实践中，不断的迭代导致还来不及写文档，特性细节就又变化了。一个变化的特性，在传统既定的测试流程中设计大量文本的调整。一些部门组织中对测试用例文本的可信度的执念构筑着产品整体的质量信心，但在版本节奏催促下，测试人员最可能的反应是直接手动验证，一个特性验证完，相关的测试资产没有完整记录跟踪，测试资产的可信度很难在高强度下得到保证。文档没有比肩代码的版本控制系统。不可避免会对成员造成误导。

3.4 代码即沟通语言——what it means

业务交流时团队定期内部传递能力的重要部分。以定期业务培训和团队知识库管理两种方式维护。

在组织团队培训时，往往是主讲人输出后，听众雅雀无声。双方对领域知识都有相同的了解程度，才能让交流更加顺畅。在架构庞大，调用链过长的系统中，测试代码可以精准快速定位到具体的问题。从某一行代码、某一个断言触发， 可以节省很多自然语言的描述。

在管理知识库时，我们发现文档偏描述性语言，优势在于承载设计思路和逻辑架构，但无法传递具体的测试方法。一堆命令行和截图的拼凑的文档不如一个好的测试脚本：静态代码阐述测试步骤，动态执行体现实测结果。

在系统日渐复杂的产品测试团队中，全员熟悉每个特性和业务细节、演进进度的学习成本和沟通成本巨大，但又不能完全各自为营不闻不问，测试脚本就是很好的沟通语言，它建立在懂代码、懂测试框架这样的基础公共能之上，原则上具备这类公共能力的人员即可理解。如果不能，一种可能是脚本质量差，一种可能是测试对产品知识储备少，无论那种可能，都指向一个更好的提升方向——代码提交者优化测试脚本，代码阅读者补齐相关背景知识，而文档形式的知识，不具备这种生命力。

4 特性测试责任人即脚本责任人

传统测试自动化策略是基于在设计好的用例中，识别可自动化的用例，由相关开发或专门编写测试脚本的人员完成。这种实践方式带来两个问题：

1. 新特性场景用例开发代价高，自动化交付不及时
2. 继承特性用例无效或无法再多种场景下重用

从对特性理解和产品整体把握上，专职的脚本开发人员没有特性测试责任人理解深入，从测试文本到测试脚本的转化，中间会产生很多认知沟通成本。
并且，从绩效结果导向上看，特性直接测试责任人如果只对交付结果质量负责，缺少自动化的驱动力就会也缺少对整体测试脚本的掌控力，在后期，整个团队的测试资产对齐维护和测试脚本有效性上都会付出更多的成本。

当要求测试团队每个成员都具备脚本开发，甚至是测试框架的深度理解后，测试代码的开发会从简单的AW组装变成更贴近产品形态结构的简洁高效设计。

高效的自动化能力储备需要前期积累的自动化能力基础，并投入更多的精力去维护和提升自动化测试的效率：

• 测试自动化是一个细水长流的过程，应该成为测试人员的习惯动作
• 要将这个习惯培养成好的习惯，制定一定的团队公约并自觉遵守让更多成员获益
• 同时也要悉心呵护自动化资产，才能让大家的好习惯不至于乏味

5 建设高可用自动化能力

CI/CD不只是代码持续交付的优质生产力，测试执行也可以接入CI/CD流程中。用容器承载每个版本的测试代码，规划一部分核心用例作为转测门禁来实现测试前移。

用监控业务的方法，监控测试结果。云平台的运维监控平台不光可以监控基础设施硬件，集群业务指标。将短平快的核心用例打包发布到现网（测试后移），将拨测结果视为为测试服务的业务指标，在监控运维平台上对接测试结果，可以进一步提升测试发现问题的效率。

测试能力的迁移和后移，让测试工程的精力更多得投入到更有价值工程创造上去。