自动化测试对于前置数据的构造

• 資深大佬 : warcraft1236

  你先说明前置数据是个啥玩意

• 資深大佬 : HappyFox

  调用接口，存在业务依赖的地方 Mock 返回

• 主 資深大佬 : Aresxue

  @HappyFox 我觉得这是最合理的，但是不够健壮，如果是较靠前的业务接口出问题了，后续接口都没法玩了

• 資深大佬 : HappyFox

  @Aresxue #3 这需要你梳理一下自动化的测试范围，给系统依赖分级
  0 级：底层接口，无外部依赖，自动化优先进行
  1 级：依赖 0 级系统，日常回归时可 mock0 级返回，全链路时先检查 0 级是否正常

  其实类似于一个自动化任务调度中心，初期可以考虑写一个规则脚本来维护 case 执行顺序，后期建议做一个可视化的平台，然后接入流水线。每次研发一打包，自动执行你们的测试 case 。

• 資深大佬 : HappyFox

  @Aresxue #3 你是想做某个系统的测试，还是想做全链路测试？
  单一系统测试，就别考虑那么多，根据 wiki 保证你的输入输出正常即可
  全链路测试，建议每个系统都测完以后进行单独的联调测试
  而且关于底层接口故障的问题，你完全可以做一套接口监控系统（线上线下）+全链路请求追踪系统（测试环境挺有用的）来解决

• 資深大佬 : passerbytiny

  请首先区分好是测试数据，还是服务依赖。

  如果你是用外部方法来生成测试数据，那么你说的那种接口依赖情况压根不存在，因为你不能用不稳定的工具去生成测试数据。

  你搞得这两种方法，都不行，因为不管是调用接口还是用基本实现接口的 sql 生成数据，你生成的数据都受到外部业务逻辑的干扰，是极不稳定的。

  你应该按照待测试内容的业务逻辑要求，使用工具（独立且稳定的 dao 、sql 等等）直接生成数据。

• 主 資深大佬 : Aresxue

  单一系统的，接口监控系统（线上线下）和全链路请求追踪系统其实都已经有了，现在是想做业务回归，因为项目在重构且变化比较快。十分感谢您的耐心