关于自动化接口测试及过程管理的思考

对接口自动化需要讨论的一些内容：

  1. 根据生产环境（或测试环境）导出一份 sql dump 的数据，业务持续发展时测试数据基准如何跟进(即自动测试的数据库的结构与数据始终保持到最新，或有其他更好的策略)？

  2. docker mysql 数据直接存放在容器内（一次性，下次新启动则是原始数据），还是外部卷（可重用，但数据变更可能导致测试用例失败的会不会变多）？

    1. 如何记录环境配置？例如本次测试使用的是哪个容器？对应的业务系统是哪个版本？
    2. 对于可重复的、自动化测的测试应该用每次初始化新数据库？每次的测试数据如何与测试用例本身关联起来，用来查找测试失败原因（及本次测试所使用的容器并查找相关数据）

  3. 涉及到第三方系统的时候，如何动态正确的 mock 数据？（程序员来开发，会增加工作量 有没有简单设置规则就能 mock 出相应结果的动态 mock？）

  4. postman 的数据库支持，用的较多的是 xMysql(nodejs 开发），不太熟，看了下也不够灵活。（已用 go 写了个 sql2json 的简单查询应用，支持多数据库），有无更好的简单的方案？

测试的管理流程

  1. 了解需求： 与研发、产品参加需求研讨会，目的是了解业务需求。
  2. 提取测试用例：xMind(梳理测试关键点)+excel(主要是录入、批量编辑会更快)? 最后导入到禅道进行管理
  3. 测试用例评审：与研发、产品讨论确定测试用例。对于讨论后确定的测试用例，通过工具最后导入到禅道进行管理。
  4. 编写测试脚本：研发人员需要先提供接口文档（包括：接口地址、请求参数、响应返回），测试人员根据测试用例编写对应的测试脚本。测试脚本 jmx 文件使用 git 进行版本管理，文件命名等参考相应的规范。
  5. 测试报告：对于自动化测试生成的报告，存放到 http 服务器指定文件夹下，能够通过浏览器查看测试报告。测试报告内容应包括：本次测试了多少个测试用例？本次通过多少个，失败多少个？失败的原因是什么？涉及到的接口是哪几个？等等
  6. BUG 管理：提交 bug 时需要指明应用平台类型（例如：IOS，Android，微信小程序，抖音小程序等），文字说明操作的关键步骤，截图并对重点区域进行说明？bug 修复的持续跟进采用禅道进行管理。

git 管理测试的一些规范

  1. 项目目录结构 测试与项目关系紧密，因此测试脚本及用例使用和源码项目一样的 git 群组，且名称以 testing 结尾。例如 巨星优选的项目是 jxyx/jxyx-app-parent ,则测试相关内容应该放在 jxyx/jxyx-app-testing
    • 项目根目录
      • jxyx/jxyx-app-parent
      • jxyx/jxyx-app-testing
  2. 测试目录结构 测试目录结构规范，主要约束 git 仓库保存测试脚本，并同等作用于 postman 和 jmeter 两个工具的测试集合(Collection 或 ThreadGroup)。
    1. 目录 目录名称主要依据业务功能模块进行中文命名或完整的英文单词。注意：名称中不允许出现空格、特殊汉字、特殊字符等。主要以普通汉字+字母+数字等，允许出现英文下划线。 每个目录是一个完整的业务功能模块（或业务流程）
    2. 文件 对于 postman 测试脚本（json 格式)，JMeter 的测试脚本(jmx 格式)。文件名以单一的业务接口为名称。每个文件是一个单一的接口功能实现。
    3. 存储 测试脚本采用文本文件(json 或 jmx)的方式存储在 git 仓库。
  3. 测试接口文档 测试接口文档采用 swagger2 的标准文档，openapi 各个版本变动较大，而 swagger2 是各种语言支持度相对更成熟的实现，且公司的现实情况也是 swagger2 使用的更为普遍，因此采用 swagger2 作为接口文档标准。
    1. swagger2 json 转换成 postman api 及 collection. 首先获取 swagger2 的文档接口的 json 地址，然后在 postman 中导入该地址即可。
    2. postman 导出的 collection 使用工具转化为 JMeter 的 jmx 脚本。
  4. 测试流程 xMind 根据需求提取测试用例，用于讨论及确定最终的测试用例。该 xMind 文档存入 git 仓库进行版本管理。 -> xMind 文件转化成 Excel 文件（使用禅道导出的 Excel 模板），生成可以导入到禅道的 Excel 文件。 -> 将该 Excel 文件的测试用例导入到禅道系统。-> 根据禅道系统的测试用例，编写 jmx 文件 -> jmx 文件线程组遵循命名规范（例如：业务名称+（#禅道用例 ID）)的形式，方便以后开发 JMeter 的插件与禅道系统建立自动化更新测试结果。自动化测试报告网页地址更新到禅道即可。

自动化测试方案选型

对于自动化工具和脚本等的选型主要着重于一下几个方面

  1. 工具的简易型和扩展性的平衡
  2. 现有资源的情况下能否快速上手
  3. 工具链上是否有足够的文档及解决方案 针对选项和目前公司的资源情况，备选的接口自动化方案有如下 2 种：
    1. PostMan(GUI)+NewMan(CLI)使用 javascript 作为断言的组合
    2. JMeter(GUI)+JMeterMavenPlugin(CLI)使用符合 JSR223 的语言进行断言（例如：javascript,groovy,java)
  • 方案 1: 优势就是非常简单，容易上手，缺点则是参数化数据只支持 csv 文件，无法直接访问数据库，后续也比较难与 JUnit 单元测试集成。（网络上实现的访问数据库的第三方实现比较难用）
  • 方案 2: 优势是扩展性非常强，不但可以是用 csv 作为参数化数据，还支持 JDBC 访问各种数据库作为参数化数据，天然支持 JUnit 集成。缺点则是因为太灵活，入门和进阶有一定的门槛。

考虑到无论方案 1 还是方案 2 都需要测试人员写脚本，开发人员在编写测试脚本这一步作用虽然有限， 但如果需要开发 JMeter 插件（只能使用 Java）打通测试与其他管理系统集成的话，则未来价值更为明显，故而倾向于采用 JMeter 做为主要的接口自动化测试工具。

JMeter 脚本的编写规范

JMeter 脚本就是一个 jmx 文件，其文件为标准的 XML 文件。对于一个测试脚本，其内部建议如下标准化编写结构。

  1. 标准化 JMeter 脚本内的布局，从上到下的顺序依次为：
    1. 用户自定义变量 原则：对于常用的比如接口主机(host),端口(port),mysql 数据库配置(mysqlJdbcUrl,mysqlUsername,mysqlPassword)等需要定义变量，并允许命令行覆盖。
    2. JDBC Connection Pool 定义（测试数据的提供优先使用 JDBC 方式，尽量少用外置的 csv 文件方式） 原则：单一数据源，指定链接池名称为 mysql （即默认）；多个数据源，则mysql_数据库名的方式进行命名。
    3. 全局静态数据(csv)文件及变量的定义
    4. setup 线程组，用于当前环境的初始化
    5. 全局的断言，至少 2 个。包括： HTTP 200 的返回码断言和接口返回的业务成功的断言
    6. 测试线程组 N 个 （至少 1 个）
    7. 结果查看树（用于本机测试和调试时观察请求及返回结果）
    8. tearDown 线程组，用于资源的清理
  2. 引用资源的方式
    1. 对于引用外部的资源，例如第三方库（jmeter的扩展），不允许在JMeter GUI环境下直接指定，应该使用 maven 的 pom.xml 用相对路径的方式引入到脚本中来
    2. 对于用户自定义变量，必须要在pom.xml 以及 对应的profile下的 properties 文件覆盖该用户自定义变量的值
    3. 运行某个测试用例的命令 mvn clean jmeter:configure 后运行 mvn verify -Djmx_file="**/demo.jmx" -Ptest
    4. 使用GUI打开test环境配置的某个jmx文件，命令：mvn jmeter:gui -DguiTestFile="src/test/jmeter/demo.jmx" -Ptest