1. 提测评审流程

需求阶段

  1. 研发：需求澄清和串讲，WBS 计划制定
  2. 测开：测开参与需求澄清，制定自动化测试方案，将自动化开发纳入 WBS 计划，与研发进度对齐

设计阶段

  1. 研发：接口定义，提供详细接口文档，接口文档上系统
  2. 测开：底层方法实现，接口封装

开发阶段

  1. 研发：业务开发，前后端联调
  2. 测开：按照用例开发脚本，脚本联调

测试阶段

  1. 研发：自动化提测，冒烟通过率 >= 95% 方可进入测试，其他测试范围包括安装部署、自动化无法覆盖的提测用例
  2. 测开：在测试环境上执行自动化（所有可用脚本）；自动化漏测分析（功能测试发现的 bug），查漏补缺；异常脚本每周分析（连续 5 天失败的脚本）

关于接口变更

  1. 上系统之后的接口信息变更需提前一周邮件同步测开，测开给出脚本修复计划，若没有提前告知，持续集成失败责任一律由研发承担
  2. 接口频繁变更将计入脚本重构数量
  3. 外部依赖的模块，项目经理在取大版本时需执行一遍对应自动化脚本，存在接口变更提前告知并给出详细变更信息

关于 Bug

  1. 缺陷管理平台提单，缺陷单简要描述中标注【自动化】，自动化发现选择「是」，提交版本为当前最新提测版本
  2. 调试阶段发现 bug 也要提单，比如接口异常类，接口信息不一致等
  3. 产品测试最后一轮，持续集成非严重影响功能的自动化问题建议延后提交
  4. 自动化发现的缺陷不计入版本提测修复率统计，但会计入最终发布的缺陷指标统计
  5. 研发需在 3 日内修复 bug，无法修复的请给出原因

其他

  1. 建议提测与持续集成流水分开，避免持续集成结果异常
  2. 持续集成每周需有脚本上架
  3. 开发若长期没有代码更新（至少一周一次），测试将暂停该项目脚本输出

2. 自动化开发规范

编码

  1. 不能有魔鬼数字 XX1，变量名不能随意命名
  2. 无效打印信息要去掉，print xxx
  3. 以兼容 python2/3 的方式编码，以防后期切换时大量返工
  4. 代码编写需要符合 PEP8 编码规范，PyCharm 中有波浪线的地方需要进行修改
  5. 方法、形参加注释，主要实现什么功能需要有注释说明
  6. 方法一些固定参数尽量使用类变量,不要用传参方式，方法定义 __init__ 中
  7. 对于语句的多层嵌套， 一般不允许超过两层， 超过两层不利于代码的阅读
  8. 唯一字符串（角色名、用户名等）使用随机值函数 get_random_string 生成，减少清理失败可能对其他用例的影响
  9. 捕捉异常的时候，使用具体的异常，而不是用一个单纯的 except:xxx，否则连 SystemExit 和 KeyboardInterrupt 也会被捕捉到
  10. try 语句包含的东西越少越好
  11. 对象类型的比较应该使用 isinstance() 而不是直接比较
  12. 对于序列 (字符串，列表，元组)，可以利用空序列为 false
  13. 布尔值不要用==和 is 来比较，直接用 if is_true:..

框架

  1. 自动化框架的 data 层不允许包含复杂的业务逻辑，编写业务流程中用到的数据模板即可
  2. 自动化框架的 api 层多用于处理接口的封装， 复用性较强的方法也可以封装在该层，api 层可以依赖于 data 和 base 层，禁止依赖于 scripts
  3. Scripts 层是用例层，主要编写用例的验证，封装的该层的用例方法不允许相互调用，这样容易导致用例执行异常

脚本

  1. setup 方法都要有对应的 tear_down 方法
  2. 可复用的对设备、人员等操作，suite 的 setup 添加，多用例共用提高效率，同时 tear_down 需有清理操作，避免对其他用例干扰，例如：人员、设备添加后删除；参数修改后恢复默认；
  3. 根据环境变化的变量不能写死，比如当前登录的用户信息，要通过接口获取用户信息
  4. 真实设备操作，例如：数据下发，云台控制，需校验设备中数据，可使用横向库方法
  5. 自动化脚本不允许直接操作数据库，不能删除的数据，就留在系统中，但要保证其他用例不使用该数据或者不能对其他用例产生影响
  6. 增、删、改专用用例，需要充分验证效果
    • 人员/设备添加用例：人员/设备添加，接口返回成功后，需用其他接口（例如：分页查询接口）查询添加成功，并校验关键字段信息，如人员姓名、编号（设备 IP、端口、名称）等
    • 人员/设备删除用例：人员/设备删除，接口返回成功后，需用其他接口（例如：分页查询接口）校验删除成功
  7. 依赖于数据的用例，必须先新增数据，再使用该数据验证用例，不推荐使用系统中已经存在的数据
  8. 脚本验证不管成功与否，通过接口删除对产生的数据进行删除， 无法删除的除外
  9. 接口验证需要对前端展示的所有字段都要验证
  10. 频率较高的长耗时操作，例如：部分设备添加后等待上线耗时较长，可用循环查询判断的方式（非睡眠 sleep 等待）
  11. 对于一些异常操作的用例，比如：停止 DP 服务，这种用例归到一类并打上特殊标签，后期统一跑，优先级降低
  12. Robot framework 里的脚本编号格式，示例：01系统管理 –> 01登录 –> 01_01_01_正常登录  -> 01_01_02_错误密码登录

自动化文本用例

  1. 用例中需包含验证结果的 sql 语句
  2. 接口传参的一些主要参数在用例中体现
  3. 自动化用例是按照 wetest 里自动化为是，脚本编号有值，且能找到对应的一条脚本，才会被执行，所以一条功能用例必须只能对应一条脚本用例
  4. 如果一条功能用例，自动化只能覆盖一半，那就将用例拆成两条，把能自动化的用例自动化标记为是，不能实现就标记为否，最终文本用例只有一个版本
  5. 部分特殊用例（如隔天验证效果用例），采用修改服务器时间等特殊方法，需确认服务器是否需要重启，若耗时过长，用例可以加标签，根据需要使用标签筛选用例测试
  6. 测试用例名称需要体现测试点