【测试基础】三、为什么要做自动化测试?哪种项目合适?
作者:互联网
又要聊到自动化了,感觉现在不管是主动或者被动,“自动化”已经是我们测试人员避不开的话题了。
主动,你觉得需要做一些测试提效,于是你去学习了解,并在工作中应用。
被动,或许你想换份工作了。当你打开各公司的招聘JD,又会看到“自动化”,还是得去学习了解。
一、什么是自动化测试
我的理解是:能代替我们手工测试的行为。
比如常见的Web自动化和接口自动化,就是代替我们人工去执行页面操作和接口的操作,并且还要可以验证结果是否符合预期。
二、为什么要做自动化测试
自动化近几年之所以大受追捧(趋之若鹜),肯定还是有它的优势的:
- 可以替代大量重复性工作,测试人员可以有更多时间投入到新功能、或者更全面的用例设计上。
- 可以大幅提高回归测试效率,非常适合敏捷开发过程。
- 可以更好地利用无人值守时间,去更频繁地执行测试,特别适合现在非工作时间执行测试,工作时间分析失败用例的工作模式。
- 可以高效实现某些手工测试无法完成或者代价巨大的测试类型,比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试等。
- 还可以保证每次测试执行的操作以及验证的一致性和可重复性,避免人为的遗漏或疏忽。
缺点?那必须存在:
- 自动化测试并不能取代手工测试,它只能替代手工测试中执行频率高、机械化的重复步骤,起到互补。
- 自动化也不智能,只会按照代码里我们既定好的步骤去执行,中间发生任何意外,没有任何处理能力。
- 自动化测试用例的开发工作量远大于单次的手工测试,所以只有当开发完成的测试用例的有效执行次数大于等于 5 次时,才能收回自动化测试的成本。
- 自动化测试发现的bug通常会很少,主要职责就是用来回归。
- 测试的效率很大程度上依赖自动化测试用例的设计以及实现质量,不稳定的自动化测试还不如不要。
- 实行自动化测试的初期,用例开发效率通常都很低。
- 自动化测试开发人员必须具备一定的编程能力,这对传统的手工测试工程师会是一个挑战,需要额外学习成本。
所以,对于自动化测试,不能一概而论,不管三七二十一就上,具体还是看你的项目是否适合。
三、什么项目适合做自动化测试
1. 需求文档,不会频繁变更
如果需求频繁变,那么对应你的自动化维护成本也会直线上升。你想想,刚调试完的case,结果页面或者接口逻辑变了,又得重调了。
2. 研发和维护周期长,需要频繁执行回归测试
这里说的是软件产品,比如微信app、淘宝web系统。软件产品的生命周期一般都比较长,通常会有多个版本陆续发布,每次版本发布都会有大量的回归测试需求。
而对于项目软件(比如给XX公司开发一套系统,2个月后交付实施),就要视情况而定了。
通常来看,短期的一次性项目并不适合做自动化测试,ROI(投入产出比)不高,以手工探索测试更合适。
对于一些中长期项目,可以这样:
- 对比较稳定的软件功能进行自动化测试,
- 对变动较大或者需求暂时不明确的功能进行手工测试,
最终目标,是用 20% 的精力去覆盖 80% 的回归测试。
3. 需要在多种平台上重复运行相同测试的场景
这种其实就比较常见了,比如web端的多浏览器执行、app端的多系统版本或者多机型测试等等。
这些项目中的单个测试用例都需要被反复执行多次,能够使自动化测试的投资回报率最大化。
4. 某些测试项目通过手工测试无法实现,或者手工成本太高
通常为性能和压力测试。
比如,某一个项目要求进行一万并发用户的基准性能测试,难道你真的要找一万个用户按照你的口令来操作被测软件吗?又比如,对于 7×24 小时的稳定性测试,难道你也要找一批用户没日没夜地操作被测软件吗?
这时候必须借助自动化测试技术了,用机器来模拟。
5. 测试人员已经具备一定的编程能力
如果测试团队的成员没有任何开发编程的基础,推行自动化测试就会比较困难:
- 短期收益:前期的学习成本通常会比较大,很难在短期内对实际项目产生实质性的帮助。此时如果管理层对自动化测试没有正确的预期,很可能会叫停自动化测试。
- 本末倒置:如果测试人员不能正确地看待自动化测试,很可能会花大量的精力放在自动化测试技术的学习与实践上,而忽略了测试用例的设计,这很致命。
所以,要综合实际情况来看待“自动化测试”。它的确可以从一定程度上解放测试人员的劳动力,完成一些人工无法实现的测试,但并不适用于所有的测试场景。
如果,维护自动化测试的代价高过了节省的测试成本,往往会得不偿失。
标签:手工,测试人员,测试用例,测试,自动化,合适,执行 来源: https://www.cnblogs.com/pingguo-softwaretesting/p/14994441.html