测试用例编写
当前测试组(集成测试/接口测试)的方式
-
采用行业内流行的 xmind（脑图）的方式编写测试用例，通过生成遵循一定格式的 Excel 文件，可以导入到禅道系统。参见《测试用例设计-模板.xmind》 优点：
- xmind 文档能够清晰体现出主线思路。
缺点：
- 额外安装软件
- 用例过多时，无法直观看到有多少个用例
-
采用 jmeter 作为测试工具，编写 jmeter 测试脚本，研发人员提供 mock 接口(可能只限定在测试模式)
-
采用禅道管理测试用例、测试结果及 bug 的管理
-
测试环境分为研发同事的开发环境及测试组搭建的测试环境，搭建的部署环境分 2 种方式，一种与研发或生产一致；另一种采用 docker+compose 方式，数据库采用 mysql
-
参数化测试方式，采用 csv 文件存储输入数据、预期数据。命名规则是 csv 文件与脚本文件名称一致。同一个业务测试文件夹内至少有 3 个文件,包括：1 个.xmind （测试用例）文件，1 个.jmx （测试脚本）文件，1 个.csv （测试数据）文件。但是由于集成测试接口参数众多，因此只会放置业务关键参数到 csv 文件，其他不太重要的参数则固化到脚本中。
-
mock 第三方接口(测试模式)，初始至少模拟第三方接口成功和失败的 2 种结果。至于失败结果的细分，则具体情况具体分析，可以后续补充。
-
测试脚本可以重复跑。2 种方式：
- 脚本调整数据库的数据并构造所需数据
- 脚本使用接口构造所需数据，数据库开始测试前重置
单元测试的方式（待讨论）
-
测试用例编写及管理方式（在单元测试代码内用注释的方式写测试用例或也使用 xmind？是否也要登记到禅道？） 优点：
- 测试用例与单元测试代码集成在一起，不用费神去额外更新其他文件
缺点：
- 测试用例的业务流程没那么直观
-
测试技术栈 JUnit5+AssertJ+Mockito ?
-
需要使用禅道管理用例及 bug 等吗？好处是登记到系统内，有权限即可看到。
-
测试环境在个人电脑上搭建吗？数据库本机搭建一个？内存数据库（与 mysql 兼容程度）？可选 docker
-
参数化（parameterization）测试时也使用 csv，所有参数都放到 csv 中?或者使用其他建议方式？
-
mock 模式，模拟第三方接口(测试模式)
-
单元测试代码可以重复跑