牛

感谢回复，
是想参考学习一下大家当前的做法。

感谢回复，
接口测试通常只能覆盖单一层面的正确性（如参数校验、状态码），但无法验证业务场景完整性
请问基于业务场景的接口测试能解决吗
后端接收到不常见或未处理的参数组合，通过接口构造这些场景可行吗？
接口文档就是渣男，实际中接口文档都是这样操作的？
请问例如 swagger 等接口文档工具，对于接口文档不一致的问题 会好一些吗？
需求文档在开发过程中可能因以下原因频繁变更
如果需求或设计频繁大量变更，那肯定对整个项目来说都是灾难。

补充：即使接口测试通过，还是要进行端到端的测试，端到端的测试也覆盖了主要的功能，那提前的接口测试是否没有必要了？

这个方式是不是和我们的评估矩阵有点类似，评估矩阵抽象一些，这个具体些

统一回复一下：

1.冒烟测试是有的，但是依然出现了提测质量低、设计文档缺失、提测信息缺失的情况，导致测试工作难开展。
2.打分是匿名的，只有研发 leader 可以看，且不会占研发绩效大的比重，只是提供给研发 leader 参考，作为研发 leader 的辅助打分数据。
3.现阶段是刚开始试行 1 个季度。

看应用场景吧，如果迭代频繁，且用例稳定的话，还是比手工回归提效很多的

checklist 是设计测试用例的模板，设计完测试用例后对照一下 checklist 检查有没有遗漏的

目前用的 coding 免费版，但是最近在自研测试管理平台集成测试用例管理功能了（模仿 coding，因为 coding 免费版有用例条数限制，无限制的要收费）

一直在用，感觉是当前最好用的了