大家都知道自动化测试在软件开发过程中可以节约很多手工测试的时间,提高生产效率。虽然自动化测试能为我们带来巨大的收益,但实施过程中由于成本高,对自动化工程师自身要求比较高等因素,想要具体是实施起来也并非易事。
时间是衡量一个项目是否决定采用自动化测试的重要要素。
如果一个项目从立项到结束到结束只有一个月的时间,那这个项目基本就没有必要采用自动化测试。如果项目一旦稳定之后,你要在相当长的一段时间内进行进行维护,那么这个项目采用自动化测试将会在后面的工作中带来巨大的收益。
在项目中采用自动化,我们一般根据如下原则:
1. 技术方面的原则
标准 1.1:可用于回归测试的测试用例
回归测试意味着: 可以验证那些已有的功能,确保这些功能不能被新版本破坏。即新版本不会影响的那些功能。
由于测试用例不相同,可以为它们分配不同优先级:比如P0,P1,P2 ......,或严重,高,中......等。
一般来讲回归测试中的P0(最重要的)测试用例 - 是自动化测试的最佳候选者。
标准 1.2:非功能性测试,难以手动执行或无法手动
在测试场景中的性能测试:压力测试,负载测试等。它们很难甚至无法手动执行。自动执行此类测试用例通常是个好主意。
在软件生产过程中,一些持续集成和持续交付(CI / CD)流程将部分服务器部署到生产环境(针对测试用户)并监控性能指标以评估软件的性能。有了自动化测试的脚本,您可以使用CI / CD进程+监控“自动化”测试。
因此,这就是为什么这些非功能性测试也是测试用例自动化的最佳选择。
标准 1.3:从易于自动化的用例入手
有些测试用例比较容易写成自动化,而手动做这些测试相对重复和繁琐。
有些情况下,手动测试很难模拟某些条件。但是对于自动测试案例,它可以轻松完成!比如我们在做测试的时候有时需要手动清空数据库或者恢复数据库为某一状态。
这些测试用例也是自动化的最佳选择。
2. 业务方面的原则
标准 2.1:能够吸引投资者的眼球
一些投资者关注公司的增长情况(比如员工数量),那么你正好可以聘请相对廉价的自动化测试工程师,让他们自动化任何测试需求。
一些投资者喜容易被“100%测试自动化覆盖”、“持续集成”、“持续交付”、“基于云”、“人工智能”、“大数据”等短语所吸引,这就是为什么你聘请所有这些自动化工程师可以来赢得这样的投资者。
一些投资者关注开支增长。您也可以支付自动化设备这一费用。这就是启动DevOps和自动化测试流程的原因之一。
结论
和其他地方一样,没有什么灵丹妙药。所有问题的答案都是:“视情况而定”。
这就是为什么总有一些标准可以帮助您为您的问题定义最佳(或接近最优)的解决方案。
领取专属 10元无门槛券
私享最新 技术干货