目前是智能家居领域的测试
感谢回复,
是想参考学习一下大家当前的做法。
感谢回复,
接口测试通常只能覆盖单一层面的正确性(如参数校验、状态码),但无法验证业务场景完整性
请问基于业务场景的接口测试能解决吗
后端接收到不常见或未处理的参数组合,通过接口构造这些场景可行吗?
接口文档就是渣男,实际中接口文档都是这样操作的?
请问例如 swagger 等接口文档工具,对于接口文档不一致的问题 会好一些吗?
需求文档在开发过程中可能因以下原因频繁变更
如果需求或设计频繁大量变更,那肯定对整个项目来说都是灾难。
补充:即使接口测试通过,还是要进行端到端的测试,端到端的测试也覆盖了主要的功能,那提前的接口测试是否没有必要了?
这个方式是不是和我们的评估矩阵有点类似,评估矩阵抽象一些,这个具体些
统一回复一下:
1.冒烟测试是有的,但是依然出现了提测质量低、设计文档缺失、提测信息缺失的情况,导致测试工作难开展。
2.打分是匿名的,只有研发 leader 可以看,且不会占研发绩效大的比重,只是提供给研发 leader 参考,作为研发 leader 的辅助打分数据。
3.现阶段是刚开始试行 1 个季度。
看应用场景吧,如果迭代频繁,且用例稳定的话,还是比手工回归提效很多的
checklist 是设计测试用例的模板,设计完测试用例后对照一下 checklist 检查有没有遗漏的
目前用的 coding 免费版,但是最近在自研测试管理平台集成测试用例管理功能了(模仿 coding,因为 coding 免费版有用例条数限制,无限制的要收费)
一直在用,感觉是当前最好用的了
你们测试要做单元测试?
目前是智能家居领域的测试