按照我所接触的自动化测试,我认为可分为两个方面 UI自动化测试和接口自动化测试 。

我认为设计测试用例和编写脚本要分开来看 一般设计测试用例是在需求评审结束、需求文档下发后,来开始编写测试用例,在设计测试用例时需要考虑到哪些用例可以用自动化来实现,并将这些用例筛选出来,测试用例设计截至点在用例评审之前,评审之后也可有小范围的优化、改动,但是整体大的流程一般不会在动。
 

自动化测试

编写自动化脚本:

1、UI自动化测试 UI自动化测试还要看你对UI自动化的需求

(1)、回归测试

若是单纯做以后的回归测试,那么我建议是等版本稳定后,bug缺陷基本修复时,再来做自动化脚本的编写,这样就不需要消耗更多的时间来维护脚本, 我的建议还是让UI自动化的脚本来进行回归测试。

(2)、验证性测试

若是想利用UI自动化直接验证本次的功能点,那么建议在冒烟测试时就开始编写脚本,这样遇见问题,就需要不断维护脚本,最终使脚本运行达到稳定,根据我以往的经验来看,这种方式是不建议采取的,维护成本太高。
 

自动化测试

2、接口自动化测试

接口测试可以提前介入,在前后端联调后功能冒烟测试之前就可以开始写接口自动化脚本,这样能有效的避免冒烟测试轮次过多。