第一步:
得到功能测试的常规用例,查看是否可以进行自动化,要明确,自动化不是为了自动化而自动化,自动化是节省人力,主要做回归测试,如果变动性特别大,不建议做自动化,具体可查看其它文章“什么适合做自动化”,且有些自动化要评判付出与收益比,如果付出很大,收益很小,这种也不值得做自动化
第二步:
确认可以做自动化,需要把用例转成自动化用例
我关注的点:
- 自动化用例我会更注重,验证点,数据的准确性,ui的结果不单单只关注界面显示,为了数据准确性,我会从数据库中拿数据进行对比,或者是通过接口请求数据得到数据,
- 界面手工操作的,可用接口获取就用接口,如商品数据
第三步:
转成了自动化用例后,我们要合适自己部门的工具,工具选型, 我工具选取几个要点:
- 适合项目组成员能力
- 扩展性强
- 易维护和推广
- 帮助文档尽量多的
目前在考虑是否使用airetest或rbotoframework工具,这块需要调研
第四步:
脚本编写,把自动化用例转成脚本 我关注的点: 1.ui框架的模式,关键字驱动,数据驱动,混合驱动等 2.代码要注意封装,使用PO模式,减少冗余 3.考虑脚本的扩展性
第五步:
验收,我关注的点:
- 是否达到了预期效果
- 脚本稳定性
- 脚本的运行速度
- 脚本准确性
第六步:
持续集成,集成方式有很多,目前使用多点的是使用Jenkins 我关注的点: 1. 定时的构建 1. 构建时会触发其他内容 1. 编译的日志
第七步:
消息通知 我关注的点: 1.结果的及时通知,如公司用到的一些聊天工具,是否可及时发送内容
第八步:
维护阶段,出现问题能快速定位,ui自动化就存在维护成本高的风险