现实就是那么相似，我们都知道测试自动化对软件开发有好处（就像坚果对我们的身体一样！），很遗憾很多公司在不考虑细微差别的情况下就赶着上线测试自动化。如果您不遵循一些规则，您可能会弄巧反拙。
计划先行
必工欲善其事必先利其器
关于开发人员使用的测试框架，我曾经在其它的推文里介绍过一款 Google 开源的 C++ 测试框架，有兴趣可以点击下方链接了解一下。
可见需要的工具名目众多，而且分阶段配合，也非常需要集成到统一的平台并便于成员理解各个阶段的作用和相互协调。
比如，Katalon、LambdaTest、Perfecto、Zebrunner等。
在项目早期就开始
bug发现越早，留给工程师修复的时间也就越多，严重的问题更适合在项目早期就发现，后续跟进的同事也能对此类问题了解更全面。否则，等到工程代码堆积如屎山，待到何时休？唯有项目难产了。
合理利用虚拟环境和真实应用环境
如果还需要测试产品的性能，获取实时数据，比如传感器、部件、网络信号强弱、电量等，必须要使用到真实的应用环境才可以达到目标。真实的应用环境往往需要购买特定的设备配合测试，这些设备还要考虑定期维护保养，所以成本也是一个很重要的因素了。
手动自动相互配合
首先，脚本无法模仿人类的所有行为和反应。其次，如果计划的测试只需只执行一次，那么没有必要为此写个自动化脚本，等写完脚本，花都谢了。
| 需要实施自动化的测试场景： |
|---|
| 大量重复动作 |
| 操作大量数据 |
| 需要注意力比较集中的操作 |
| 需要兼顾各种运行平台的功能，比如不同操作系统、浏览器、硬件等 |
| 比较常用的功能 |
回归测试
回归测试是需要重复执行的，所以自动化地执行并一遍又一遍地运行就显得很必要了。一般建议在回归测试套件种添加冒烟测试、完整性测试和测试用例，方便在测试周期中发现更多的bug。
端到端(E2E测试
切忌独揽所有环节
如果每个成员都充分了解项目的测试阶段，他们或许可以为流程做出更多贡献。测试工程师如果都能共享测试脚本，那么其中优秀的知识和技能也能被传播到其他成员。还有，共享测试会使到测试过程更加透明。
预期和结果对比，效率最大化
在测试工作结束后，对比一下预期的计划和实际的花费，为下一阶段的工作做好调整，目标是实现效率的最大化。
保持更新
所以在回归测试中，要及时删除过时的测试例程，更新对应的功能测试。