关于测试框架，应该考虑的方面

最近在使用公司新研发不久的测试框架，很多功能有缺陷或者不足。在此做一些记录，以后研发、选择测试框架的时候可以从这些方面进行一些考察。

---

• 基础框架：很多框架是基于既有框架junit、testng等做二次封装，提供便利性或者UI，所以很多能力是依赖于基础框架，所以对基础框架的能力很多时候觉得了上层框架的边界和上限。
• 封装策略：对于基础框架或者语言层面的封装策略、或者说框架定位。对于哪些能力/选项直接暴露，哪些做二次封装，哪些包装成黑盒，哪些额外增强。这些定位如果和使用场景的预期有偏差就会出现诸如“这个我不关心啊，为什么每次都让我配置”，“这么基础的订制化能力它居然不支持”之类的抱怨。
• 测试大环境准备：比如被测代码是spring应用，框架是如何启动应用的，与生产运行方式有何差异，性能如何。
• 测试小环境准备：
  • 测试db数据的准备
  • mock的准备（mock能力的强弱）
  • 测试请求的准备
  • 预先执行的操作（应用状态/内存状态的准备等）
• 测试的检查：
  • db数据检查
  • mock请求内容的检查
  • 内存数据的检查
  • 返回值的检查
• 数据的清理：
  • 所有准备项的清理
  • 过程产生数据、影响的清理
• 动态化与模板化：
  • 所有准备、检查、清理的数据的动态化（避免测试并发运行冲突，避免时间依赖等）
  • 所有配置的模板化，减少重复配置
• 测试逻辑与测试数据隔离：基本要求，同一套测试逻辑可以在不做修改的情况下支持多套不同入参、db、内存数据下的测试。
• 用例隔离：用例在不做特殊声明下可以并发运行，同一个用例可以并发运行。并发场景下数据准备与检查、mock互补干扰。（用例开发时主要考虑，有时依赖框架能力）