写在前面

请允许我以一句 “大连加油” 开始自动化测试的三两事儿的下半篇。虽然有些生硬以及格格不入，但是还请在座各位优秀的测试攻城狮们稍微体谅一下此刻疫情下大连人焦虑复杂的心情。特此声明：本篇文章虽产自大连，但是决对安全，请放心阅读~

关于自动化测试的另外三两事儿

上半篇我们讨论了什么是自动化测试以及我们对自动化测试的误解。下半篇主要讨论一下自动化测试的优势及实践策略。
自动化测的优势主要体现在以下几点：

• 减少失误率，提高准确性
• 节省时间和执行成本
• 提升测试覆盖率
• 做手工无法完成的测试
• 为开发人员提高质量反馈速度

但是传统自动化测试存在一些困境，测试用例执行成本高；执行频率低，通常只在软件开发完成后进行；质量反馈滞后；测试环境准备成本高；测试结果可信度低；人员依赖性强。因此在持续集成实践对自动化建设有了以下基本衡量维度：

• 快速：最好再 10 分钟内，不要超过 15 分钟
• 便捷：每个人都可以随时方便地执行自动化用例，不需要别人帮忙也不影响别人
• 及时：功能一旦改变，就能通过自动化测试用例告知对软件质量的影响
• 可信：不存在随机失败的情况，有失败立即修改

自动化测试的实施策略

在实施自动化测试时应该增加自动化测试用例的今天今天着手点，针对代码热区补充用例，随时跟进新功能的开发进度，从测试金字塔的中间层开始，向两端扩展，测试用例的质量比数量更重要，在保证质量的前提下用例数量越少越好。团队应该共享自动化测试的维护职责，用例代码也需要设计并且很好的维护，当有人对测试失败结果视而不见的时候就出现 “破窗效应”。关于代码覆盖率，谷歌给出的建议是 85%，非常重要，但也非常不重要。代码覆盖率是一个实实在在可衡量的指标，但是至于具体的数值，也要因项目情况而异。而良好的自动化测试应该满足以下特征：

• 用例之间必须相互独立
• 运行结果必须稳定
• 运行速度必须够快：sleep 少用，可以分解用例或用轮询替代
• 测试环境统一，不要只能在个人机器上运行

关于自动化测试的一些心得：

• 自动化测试用例运行次数越多，平均成本越低，收益就越大；
• 自动化测试用例之间应该尽可能相互独立，互不影响；
• 在质量有保障的前提下，自动化测试用例的数量越少越好；
• 遗留代码的自动化测试编写应该从代码热区开始；
• 自动化测试用例从测试金字塔的中间层开始补充，投入产出比最高。

最后，今天你测试了么？