第一步:

得到功能测试的常规用例,查看是否可以进行自动化,要明确,自动化不是为了自动化而自动化,自动化是节省人力,主要做回归测试,如果变动性特别大,不建议做自动化,具体可查看其它文章“什么适合做自动化”,且有些自动化要评判付出与收益比,如果付出很大,收益很小,这种也不值得做自动化

第二步:

确认可以做自动化,需要把用例转成自动化用例

我关注的点:

  1. 自动化用例我会更注重,验证点,数据的准确性,ui的结果不单单只关注界面显示,为了数据准确性,我会从数据库中拿数据进行对比,或者是通过接口请求数据得到数据,
  2. 界面手工操作的,可用接口获取就用接口,如商品数据

第三步:

转成了自动化用例后,我们要合适自己部门的工具,工具选型, 我工具选取几个要点:

  1. 适合项目组成员能力
  2. 扩展性强
  3. 易维护和推广
  4. 帮助文档尽量多的

目前在考虑是否使用airetest或rbotoframework工具,这块需要调研

第四步:

脚本编写,把自动化用例转成脚本 我关注的点: 1.ui框架的模式,关键字驱动,数据驱动,混合驱动等 2.代码要注意封装,使用PO模式,减少冗余 3.考虑脚本的扩展性

第五步:

验收,我关注的点:

  1. 是否达到了预期效果
  2. 脚本稳定性
  3. 脚本的运行速度
  4. 脚本准确性

第六步:

持续集成,集成方式有很多,目前使用多点的是使用Jenkins 我关注的点: 1. 定时的构建 1. 构建时会触发其他内容 1. 编译的日志

第七步:

消息通知 我关注的点: 1.结果的及时通知,如公司用到的一些聊天工具,是否可及时发送内容

第八步:

维护阶段,出现问题能快速定位,ui自动化就存在维护成本高的风险

 

版权声明:本文为chongyou原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/chongyou/p/10821445.html