【读书笔记-020】持续交付2.0之自动化测试策略和方法

拥有完整而有效的自动化测试策略，是团队达成持续集成目标的一个至关重要的前提条件。

自动化测试的定位

测试领域存在四类基本活动，即：

• 问题认知：对业务问题本身的理解和认识，来源于探索环
• 分析：测试分析和设计，通过对业务的认知，分析并设计能够验证是否成功解决业务问题的方式和方法，不断优化，在确保验证质量的前提下降低测试成本
• 执行：执行测试分析得到的测试用例，得到测试结果或数据
• 决策：根据测试结果做出下一步行动判断

自动化测试：将“执行”阶段的大量重复性的劳动力交付给机器来完成，将人从重复的手工劳动中解放出来。

敏捷测试四象限

敏捷测试四象限

• 面向业务专家：指能够与业务专家无障碍沟通
• 面向技术人员：容易与技术人员达成共识
• 支持编程：为了帮助产品研发团队自己检查功能需求是否开发完成
• 评判标准：用于找出产品是否有缺陷

第二象限和第三象限的测试类型都可以被自动化，包括功能验收测试、单元测试、组件测试和系统集成测试；第四象限一部分可以自动化，大部分可以半自动化；第一象限只能通过手工方式运行。

自动化测试的优势

• 减少失误率，提高准确性：自动化测试每次执行相同的步骤，并且每次都会记录详细的执行结果，且不受人的因素影响；人手动测试会因个人的经验和情绪不同而导致执行结果不同；
• 节省时间和执行成本：在软件的生命周期中，测试活动需要经常重复执行以确保质量，自动化测试用例一旦创建，就可以做到无人看守地运行；
• 提升测试覆盖率：自动化测试可以增加测试的深度和范围以提高软件质量，从而提供手动测试所不及的覆盖范围；
• 做手工无法完成的测试：比如性能测试，靠人工模拟成千上万的用户访问软件，凭手工测试时无法完成的；
• 为开发人员提供质量反馈速度：开发人员可以使用共享的自动化测试快速发现问题，通过持续集成自动触发运行，并将通知团队成员是否失败，这样会节省开发人员的验证时间，也增加他们对自己编写软件代码质量的信心；
• 提供团队士气：将重复性的测试任务自动化，团队可以将时间花费在更具挑战性和更有价值的活动中，团队成员个人技能和信息的提高也同时反馈给了团队，提升了士气。

自动化测试的成本投入

• 工具投入成本：自动化测试需要工具的支持，需要相关测试工具的研发投入，以及对团队成员的测试框架、测试技能和工具培训；
• 用例成本维护：功能的新增、珊瑚和修改，其所对应的自动化测试用例也需要同步的改动，带来一定的维护成本；
• 专业技能人员成本：需要对自动化测试用例的创建者掌握软件设计与代码编写能力进行培训；
• 设备资源的投入：由于自动化测试无法完全代理手工测试，因此不但需要保留手工测试所需的测试环境，同时还要为自动化测试用例的执行准备相应的测试环境。

持续集成下的自动化测试

持续集成对自动化测试的要求

持续集成实践对自动化测试建设的四个基本衡量维度如下：

• 快速：自动化测试用例的执行速度要快，执行的时间代表着开发人员得到反馈的时间，最好在10分钟之内完成，不要超过15分钟；
• 便捷：团队成员能够随时随地很方便地执行自动化测试用例，而不需要他们帮助，也不会影响到他人，避免出现延迟反馈的问题；
• 及时：一旦功能发生改变，就能够通过自动化测试用例的运行，告知本次代码变更对软件质量的影响，包括对原有功能的影响，以及新增功能的质量情况；
• 可信：自动化测试用例运行的结果可以信赖，不存在随机失败的现象。持续集成要求一旦自动化测试用例失败，必须立即修复，“随机失败”会大大增加工程师的“无效投入”。

《Scrum敏捷软件开发》中指出，针对被测对象范围较大的上层测试用例，数量应该越少，而被测对象粒度较细的下层测试用例数量应该增加，形成稳定的正三角形。

不同类型的测试金字塔

微核架构的测试金字塔

• 组件测试：对单个组件或框架本身进行质量验证
• 组件和插件间服务的接口自动化测试：主要是验证两个或两个以上组件间的功能正确性。
  
  微核架构下的测试金字塔

微服务应用的测试金字塔

微服务应用的测试金字塔

• 业务组件或服务测试：对单个组件或服务的测试，以验证该组件的行为是否符合设计预期。
• 契约测试：又称消费者驱动的契约测试，契约是指软件系统中各个服务间交互的数据标准格式，其目标是测试消费者接口与服务者接口之间的正确性，验证服务者提供的数据是否为消费者所需要的，从而将测试范围缩小到两个服务间的契约，以更低的成本发现问题。
• 业务工作流测试：启动两个或以上微服务，进行业务流程上的测试，以验证多个被测服务之间是否可以正常工作， 完成某一业务请求，关注的是多服务组合交互、测试接口连通性和流程的可用性。
• 端到端测试：对整个软件服务的流程进行测试，以验证其工作流自始至终的执行是否符合设计预期，识别系统以来关系，确保在各种系统之间传递正确的信息。其中一种端到端的测试时模拟用户在可视化界面上执行各种操作。

自动化测试的实施策略

增加自动化测试用例的着手点

除了符合测试金字塔结构，还可以从以下四个方面入手：

• 针对代码热区补充自动化测试用例：代码热区指那些改动频率相对较高的文件或函数，以及经常出问题的功能组件；对代码热区写自动化测试是投入产出比最划算的。
• 跟随新功能开发的进度：跟随开发进度编写对应的自动化测试用例。写好的测试用例可以直接应用为开发提供及时的质量反馈。如果自动化测试用例覆盖一直落后于功能开发，就无法起到保护网的作用。
• 从测试金字塔的中间层向上下两端扩展：从中间层级别开始入手，投入产出比最高。
• 自动化测试用例的质量比数量重要：自动化测试具有维护成本，在达到质量目的的前提下，自动化测试的数量越少越好，数量够用就行，不必要的测试用例只会单纯增加维护成本和工作量。

良好自动化测试的特征

• 用例之间必须相互独立：用例之间的执行顺序依赖会降低测试用例并行能力，从而导致执行时间太长，大大降低自动化测试的反馈效率；
• 测试用例的运行结果必须稳定：当测试脚本和被测代码都保持不变的情况下，多次执行的测试结果应该是稳定的、不变的，降低无效的时间浪费；
• 测试用例的运行速度必须快：通过测试用例的拆分和“轮询”来去除测试用例中的“等待”，减少等待时间，从而缩短整个测试用例的执行时间；
• 测试环境应该统一：环境的依赖和易用性会降低自动化测试用例的收益，环境的统一对自动化测试的回报至关重要。

用户验收自动化测试的要点

处于测试金字塔顶层的用户验收测试的数量不应该太多，其重点在于：

• 以用户旅程地图的方式来验证软件应该活服务的核心工作流程，从用户的角度出发，以叙述故事的方式描述用户与软件产品之间的交互；
• 应该验证软件应用或服务的端到端行为，而非具体的实现细节；
• 通过各种手段让端到端自动化测试的调试更容易，如提供完整的日志文件，记录常用的测试失败模式，保留所有相关的系统状态信息（自动截屏、出错时现场镜像保存）等；
• 数据准备。可以将生产环境的数据克隆一份请求，原有的请求仍旧通过原来的服务正常处理，而克隆出来的请求引流到新版本的服务。

其他质量检查方法

差异批注测试方法

一种半自动测试方法，当做预定义的数据集输入系统后，收集运行后的输出结果，对其中需要验证的数据进行提取，并将提取结果放入文本文件中，通过对比前后两次测试的结果，用人工批注的方式进行半自动测试。需要特别注意动态信息的处理，常见的工具包括TextTest和ApprovalTests等。

代码规范检查与代码动静态检测

• 代码规范检查：通过一些工具依赖团队定义的一些代码编写规范，针对源代码进行检查，发现破坏规则的代码并加以指正。常用的工具包括：Checkstyle，PMD，SonarQube等。
• 代码动静态检测：通过一些工具对产品源代码进行自动化扫描，发现代码中存在的问题或潜在风险。

1. 静态扫描：无需编译器编译而直接使用一些扫描工具对其进行扫描，找出代码中存在的一些语义缺陷、安全漏洞的解决方案。常用的工具包括：lint，Coverity，ColcWork等。
2. 动态分析：通过在真实或虚拟处理机器上执行目标程序进行分析，比如，在可能的漏洞处插入专门编制的故障发生函数，迫使目标软件产生异常，然后通过监控程序来检查是否发生了边界溢出或者其他异常现象。常用工具包括：Valgrind，Purify等。

总结

前置周期越短，说明交付效率越高，越能提升客户的满意度；对交付频率的要求越高，希望前置周期越短，自动化测试就越为重要。秉承着快速、便捷、可信和即使的自动化测试原则，遵循自动化测试金字塔结构，合理设计自动化测试的实施策略，降低自动化测试的成本，从而增加自动化测试的收益。