04 | 为什么要做自动化测试？什么样的项目适合做自动化测试？
该思维导图由 AI 生成，仅供参考
什么是自动化测试？
为什么需要自动化测试？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
自动化测试在软件开发中扮演着重要角色，但其适用性因项目特点而异。本文深入探讨了自动化测试的定义、优势和劣势，以及适用的项目类型。自动化测试通过机器执行测试行为，提升回归测试效率，利用无人值守时间执行测试，并保证测试操作的一致性和可重复性。然而，自动化测试并非万能，无法取代手工测试的智能判断和发现更多缺陷。适用于自动化测试的项目需要考虑测试用例的有效执行次数、自动化测试用例的设计和实现质量，以及业务测试专家和自动化测试专家的紧密合作。读者在决定是否使用自动化测试时，需要权衡其优势和劣势，并结合项目特点进行取舍。适合自动化测试的项目特点包括需求稳定、研发和维护周期长、需要在多种平台上重复运行相同测试、手工成本过高以及测试人员具备一定的编程能力。总之，自动化测试是一种重要的实践，但并非适用于所有测试场景，需谨慎考虑其适用性。
《软件测试 52 讲》，新⼈⾸单¥68
全部留言(86)
- 最新
- 精选
龍蝦手工测试还涉及到一个人性的问题。 某些手工测试团队考核的标准就是找到的bug个数，个数越多绩效越好。而开发人员开发的代码，在一些问题上算不算bug有不同的见解。然后就开始扯皮了。作者回复: 以缺陷数量来衡量测试的绩效是不可取的，而且还会激化测试和开发之间的矛盾。
2018-07-06283
麦西尼在我之前参与的一个敏捷团队中，对自动化测试理解可能有些不一样，自动化测试更多的是被认为是保护已有软件功能的一张安全网，由QA和dev共同开发，和软件系统本身的功能代码一起成长，每当有新功能代码commit进主线的时候就会触发，以检测新代码是否会破坏原有功能。作者回复: 你说的是正确的，commit之后通常会自动触发静态代码扫描和单元测试，如果两周都通过后、通常会执行自动部署，然后还会自动执行smoke和e2e测试，这些都是自动化的范畴，后面的一篇文章会专门来讨论这个
2018-07-0638
Cynthia🌸实际项目中使用自动化的部分，接触过gui自动化测试，接口测试，性能测试。 执行次数肯定是远大于5次的，毕竟开发和维护成本都要算进去，收益远超手工测试时才会考虑去做。除非是“面子工程”，用来应付某些场合。 不过还是很好奇作者的“5次”这样一个分水岭是怎么来的，是否依据经验总结得来。作者回复: 5次完全完全是经验值，因为这个主要取决于自动化测试的开发成本，如果你有很好的框架，自动化用例开发的成本比较低，那么这个值就会偏小，如果有你的测试框架很低效，那么开发自动化用例的代价就很大，那么这个值自然就好大
2018-07-06227
Tomandy自动化的出发点是提高效率和质量监控。盲目追求所谓的“全自动化”往往得不偿失，应根据项目实际情况做出选择。可退而求其次选择“半自动化”测试，辅助手工测试来提升效率，比如开发小工具来做资源的整合（脚本执行结果自动同步案例管理系统及缺陷系统、批量执行案例生成可视化报告、表断言检查、依赖开源框架搭建性能测试平台等）。作者回复: 说得非常对，👍
2018-07-0622
木主人自动化测试如果由自动化测试架构工程师来牵头实现，辅以业务功能的开发或测试人员构成核心团队，这样的企业级自动化测试的成本和收益应该是线性回归的：1.测试架构师负责企业级核心代码的复用设计及实现，2.项目团队内负责功能共用模块的抽取，3.两者结合建立自动化测试数据池仓库的建立，4.结合项目具体情况做自动化代码实现的二次设计。作者回复: 非常棒的分享，我们以前也尝试过这种模式，效果还是不错的
2018-07-11216
浮生凉我们产品迭代很快（一周一个版本）连测试用例都没办法写全，只能写写测试点，更不要提自动化了，每次刚开个头就没有然后了作者回复: 这种短期项目就不太适合自动化测试，对于这类项目的测试重点可以放在如何设计有针对性的测试用例上面，建议可以开展手工探索式测试
2018-07-06316
MegaQi现在好多公司完全把业务测试和测试开发分离开来，导致开发自动化的人不理解业务，业务用自动化工具的觉得工具不够符合业务，这样往往就是自动化成效不高，所以我一直建议测试开发要去做业务，业务要去理解怎么利用代码和工具提高效率.作者回复: 是的，你说的这个是很多公司都有的典型问题，懂自动化的不懂业务，懂业务的不懂自动化，必须要让两者能够有机的结合，否则效率很难提高，之前有提BDD其实就是为了解决这个问题，但实际落地过程中大量的mapping又引入了很多新问题
2018-07-06214
棉花糖family老师，您好！我是一名刚毕业的学生，从事软件测试有快两个月，在公司做的是功能测试，最近看第四讲到第六讲都很懵，不知道老师能否给我些建议，如何更好的去了解消化这些知识！作者回复: 这应该不是你一个人会有这种感觉，因为第4-6讲不是基于黑盒来谈测试的，而是从软件实现的内部，即从白盒的视角来谈测试，所以需要你具有一定的代码能力，至少能够明白一门高级语言。但是你也不用太担心，因为基于代码的测试我们后面还会有专门的篇幅，那边我会以更多的实例来讲解，希望能够对你有帮助
2018-07-1112
郭婷我想说尽管是软件产品，它在不断发展过程中，也有项目迭代非常忙的时候，比如测试时间只有不到5天，质量的方针仍然定为接口测试为主，导致最终线上bug率很高，但是至今TL仍意识不到这个问题，规定一个月要写20个接口的自动化测试用例（补齐老用例），并把此列入绩效考评，可这是按量来的事么，测试人员不去看代码实现逻辑，简单的通过入参返回值去写用例，覆盖率难以提升，最终只能收效甚微，变成面子工程。作者回复: 一定不是为了测试而去测试，测试的根本在于寻求最高效的方法去发现尽可能多的问题，如果单单以用例数量做为衡量标准一定会本末倒置，用例不在于多，而在于针对性和全面性
2018-07-0626
王征目前项目中落地的重点还是接口测试的自动化，单元测试推不动，UI自动化耗时耗力效果也不好，项目更新太快，前端页面频繁变更，不适合做UI的自动化测试作者回复: 你说的是很典型的案例，但是还是建议有最基本的GUI测试当作smoke来用，保证产品基本功能的可用性
2018-07-066
