DevOps 文字培训
为什么 DevOps 组织需要测试自动化？
如果软件交付部门还没有像样的自动化测试，开发与测试之间就一定有明显的脱节。开发人员收到工作质量反馈时，早已在忙别的任务。他们通常无法把缺陷与自己写过或没写的代码联系起来。为切换上下文、回想当初引入缺陷时的情况所付出的精力，显然会降低生产力。反馈迟来时，系统和缺陷之间的联系已变得复杂而模糊，此时既不现实也不应指望能得到不依赖临时解决办法的高质量修复。
显然，没有自动化测试，DevOps 组织将需要更多时间和资金才能交付优质产品和服务。无论从事哪种业务，这都不再是 21 世纪技术组织可以扩展的业务模式。
测试可以自动化，
创造质量的能力却无法自动化
DevOps 团队应尽可能多地实现测试用例自动化。测试可以自动化，但团队创造质量所需的思考能力无法自动化，所以不应将人才浪费在软件能够完成的重复性工作上。
良好测试自动化的 DevOps 原则
- 测试自动化应尽早、快速地反馈工作质量。
- 在不同测试运行的条件相同的情况下，测试结果应一致、确定且可重复。
- 测试不应产生误报。
- 少量可靠的自动化测试用例，胜过大量不可靠的手动测试。后者即使在相同条件下多次运行，也可能得到不一致的结果。
- 自动化测试首先应验证系统为内部和外部客户提供的关键功能和收益。即便只做到这个程度，也比完全没有测试自动化好得多。
- 然后专注于尽可能多地自动化测试用例，充分发挥 DevOps 团队成员的才能。
- 在测试自动化中，应避免缓慢且定期才出现的反馈。每当你或开发人员尝试将代码提交到主干时，都需要快速获得反馈。
- 如果自动化测试不够快，就想办法加快测试和/或软件运行速度。这对确保持续交付平台和部署流水线可靠、为客户提供优质服务都至关重要。还可以并行执行自动化测试以进一步提速。
- 考虑测试驱动开发。先编写自动化测试，再构建软件。
测试自动化是持续交付与部署流水线的关键
如前所述，DevOps 方法使开发人员能够将代码部署到生产系统。然而，对早期 DevOps 团队的观察表明，开发人员虽然能很快将代码提交到主干、关闭任务和工单，却不太愿意按下按钮把代码发布到生产系统。他们担心破坏生产环境并因此受到指责。
只有当 DevOps 团队通过测试自动化实现全面、可靠的测试覆盖后，开发人员才能克服这种担忧。
例如，在 Google，开发人员将代码提交到主干后，系统先执行静态代码分析、重复代码分析和测试覆盖率分析等初步检查，再运行近一百万个自动化测试用例来验证代码。如果所有检查和测试用例都通过，就从主干生成构建，将其投入生产并复制到其他所有生产服务器。Google 的 5,000 支小型独立团队大体上就是这样保持生产力，每天执行数万次生产部署。没有测试自动化，这是不可能做到的。
快速、可靠的反馈是确保部署流水线安全、保护其完整性的唯一途径。自动化测试用例失败导致部署流水线中断时，DevOps 团队会在将其他工作提交到主干之前，修复有误的代码和配置。此外，每当你发现部署流水线中的错误本可以用自动化测试用例提前识别并预防时，还应创建该用例并将其加入自动化测试存储库。
可以自动化的测试类型
- 单元测试： 验证应用中的单个函数、类或模块。
- 验收测试： 验证应用为客户提供的功能和收益。
- 集成（服务）测试： 验证应用间的交互及其端到端服务流程。
- 性能和压力测试： 验证服务在预期与意外的客户负载下能否扩展。对最常使用的服务而言，这尤其重要。
- 非功能测试： 验证安全性、可用性、容量和可扩展性。
如果你和团队难以自动化单元测试和验收测试，却非常依赖自动化集成（服务）测试，那么你们的架构可能是紧耦合的。应寻找办法，将架构的各元素解耦。
总结
本章介绍了测试自动化在 DevOps 中的重要性。测试自动化是安全、快速交付的关键。
无论组织是否采用 DevOps，缺乏测试自动化，就无法打造世界一流、成功、高效、有盈利能力且能为内外部客户提供良好服务的 IT 组织。
