偶遇的一篇ui自动化博文链接

• jenkins做持续集成
• python写代码
• requests发送请求
• stmplib+email发送邮件
• pytest/unittest测试框架
• allure测试报告
• excel/yaml管理测试数据
• git+gitlib仓库做版本管理

接口测试覆盖范围(逐步覆盖,优先级由高到低)

• 主流程全覆盖
  • 如:用户模块:登录/注册/收货信息/用户信息等
  • 如:商品模块:创建商品/上下架商品/编辑商品/商品列表/商品详情等
  • 如:订单模块:下单/支付/发货/收货等
  • 如:售后模块:申请售后/售后拒绝/售后同意/退货/退款等
• 正常场景全覆盖
  • 如:修改批量操作/搜索等
• 关键业务流异常场景覆盖
  • 如:重复支付,权限校验等
• 关键字段非法传参测试
  • 如:金额负数,非法状态转移
• 手工很难或无法完成的测试
  • 如:分页为200条,计算量大的

断言

• 数据结构断言
• 数据类型断言
• 期望值断言
• 逻辑性字段断言,如状态字段
• 敏感性字段断言,如金额字段

疑难杂症

• 数据驱动
• 多接口数据依赖关联
• 数据库操作进行前后置处理
• 数据库结果断言
• 环境准备
• ???接口路径或请求或响应数据结构变了怎么办???①url需要反复用到的进行封装,改的话只用改一处②请求参数同一个文件中管理,一个文件编辑器中还是很好修改的③需要断言的字段提取方式进行封装

既然修改是无法避免的,那么就做到方便修改,不要写重复代码和逻辑,重复的越多,改动就要改的越多还不一定能改全
虽然只是写脚本,但是也要优雅,不要出现迷惑代码,毕竟优雅用不过时
减少依赖,依赖无法避免时,强依赖转弱依赖

一些解决方法

• 封装&分层
• 测试环境初始化(如初始用户/初始店铺等)
• 用例之间不要依赖,确保用例可以独立运行
• 通过接口造数据(表关系复杂的,如多表关联)
• 通过sql造数据(关系简单的,如个别字段)
• 测试数据和代码隔离(1个参数需要隔离吗?30个参数需要隔离吗?100个参数需要隔离吗?隔离不隔离需要根据实际情况!)