鲸云效总结自动化测试存在的风险

鲸云效总结自动化测试存在的风险
鲸云效是腾讯优测推出的为企业制定软件质量全景解决方案的平台，其基于腾讯软件质量管理体系，以质量体系标准为准绳，以工程效能提升为宗旨，致力于以科学化和体系化的理论和实践，赋能传统行业实现数字化转型。
一、管理层决策风险
1. 管理层视野缺乏

自动化测试对非技术的管理层是个黑盒子，管理层对它的理解是有限的，而他们对自动化测试的学习和调查时间几乎不存在。

既然其他项目组能用，那我们也能用，盲目的开始自动化测试，后由于前期准备不充分，低估了自动化测试的前期投入，项目组测试人力资源不够，技术储备不足等等，然后以失败告终。

还有种多的情况，项目经理听说自动化测试好，而且觉得很有13格，现在公司也重视自动化测试这块，那么就不管自己项目现在是什么情况，自己手下的项目必须开始自动化测试。这种自动化到后一般就是形式主义，能忽悠上面领导层就行。

2. 想在短期内看到成效

想要在几周或者几个月内看到非常好的成效，既然开始自动化，那么找到了多少个bug，节省多少时间。

找到了多少个bug，怎么会没有多少，为什么大多数是些环境问题bug，bug的质量不高。

节省多少时间，怎么自动化之后你们还加班更多了，而且其他测试任务还不能按时完成，拖慢了整个项目的进度。

3. 盲目追求KPI，KPI考核制定不合理

将自动化测试覆盖率做为指标，自动化脚本寻找到bug的数量等，作为KPI考核的指标。

做UI自动化测试当你用例的覆盖率达到70%以上时，你每天的时间都会用来检查报告，维护测试脚本等等。

二、项目团队风险
1. 项目组团队间合作不紧密

自动化测试是需要所有人配合的事，开发，运维，测试，大家同心协力才能搞成的事。

测试脚本的维护与编写，是单人负责，全员参与。

元素如果要能被快速定 位需要开发配合，接口有变更需要开发知会测试，测试跟进调整接口测试脚本。

运维需要负责测试环境的搭建，并配合解决各类环境问题，还需要将持续集成环境与自动化测试整合。

2. 孤狼模式

创建和维护测试的责任降落在一个人身上，但他还要和其他成员一样参与手工测试。

如果项目时间紧张，后期根本没有时间来解决自动化测试用例的问题，所以很多用例会停留在失败状态，过段时间发现想要来维护用例，还不如重新写。

三、技术风险
1. 用例编写采用粗放的 "录制 - 回放" 模式

“录制-回放”快速创建的用例非常脆弱，界面元素与测试逻绑定，页面轻微变动导致大批用例测试失败。后期由于用例量变多，重新录制时间不够，测试用例停留在失败的状态中。

2. 自动化测试方案不合理

自动化测试方案不合理，从开始自动化注定就失败

3. 用例的可靠性太低

自动化测试用例可靠性太低经常出现误报，对报告的检查工作量增加，对自动化测试结果缺乏信心。

4. 对产品业务理解不透彻

自动化测试团队对业务理解不透彻，导致自动化测试需求覆盖不合理。

5. 太过相信工具

太过相信工具，光靠工具是做不好自动化测试。

测试工具起到的只是辅助功能，重要的是测试思想、自动测试框架、测试套件、测试用例的设计，在更多的时候还要测试工程师发挥他们的经验和智慧实施有效的测试。

6. 编程能力太差

编程能力太差，当你遇到真正困难的问题时，无法以开发的角度来解决问题，发挥测试工程师他们的经验和智慧实施有效的测试大多数会体现在编程能力方面。

7. 自动化方案制定不合理，盲目追求自动化率

轻易将指定自动化指标，100%的自动化率。没有考虑项目进度会对自动化测试的影响，也没有考虑自动化实现时会不会有什么问题或困难，使得花精力开发出来的自动化脚本没有太大的作用。

8. 没有做好自动化的准备，盲目开始自动化

不打无准备的仗，开始自动化前需要做好调研，确认自动化工具与方案，确认需要自动化哪些内容，这些东西都不应该在自动化开发的时候才来决定，而应该是事先就确定好了。

太过于相信自动化测试,且没有经过严格的自动化测试流程和前期分析设计就草率的进脚本的开发,终的结果一定是失败!

9. 测试脚本设计不合理

测试脚本设计是否合理决定了用例的可靠性。

10. 测试脚本无版本控制

需要考虑脚本版本和测试对象的匹配性，测试脚本也需要做严格的版本控制。

11. 测试脚本兼容性

测试脚本在本地调试能跑通，上传在自动化测试中心就出现问题，脚本肯定没考虑到不同系统或不同环境的兼容性。

12. 有了自动化测试，从而忽略了手工测试或探索性测试

一旦实施了自动化测试，便不再进行手工测试和探索性测试。如果脚本有问题，但测试脚本执行通过，则很可能会有bug被永远掩盖。