测试用例与缺陷

1. 测试用例的内容

主要内容

• 用例编号(如何命名)
• 所属模块
• 用例标题(验证谁在什么情况下，去做什么，最后结 果是什么)
• 优先级
• 前置条件
• 操作步骤
• 测试数据
• 预期结果
• 实际结果

辅助内容

• 通过否
• bugID
• 编写人员
• 编写时间
• 测试人员
• 测试时间
• 备注

2. 缺陷的验证程度

• 严重
• 一般
• 次要
• 轻微

3. 缺陷报告的核心要素

• 缺陷编号
• 缺陷状态
• 缺陷标题
• 重现步骤(复现步骤)
• 严重程度
• 优先级
• 缺陷类型
• 测试环境

3.1 提交缺陷的注意事项

• 可复现: 缺陷可以复现
• 唯一性: 一条缺陷只报告一个问题
• 规范性: 缺陷报告编写要规范, 符合公司或者项目要求
  • 准确: 描述的信息是正确的
  • 具体: 有细节且是真实特定的, 避免使用模糊不清的词语, 如功能中断, 功能不正确, 功能不起作用等等.
  • 简洁易懂: 描述简单容易理解, 不要产生歧义
  • 次序清晰: 描述缺陷过程有条件, 有先后顺序

3.3缺陷的生命周期

测试人员提交新的Bug入库，错误状态为New。如果确认是错误，设置状态为Open。如果不是错误，设置为Declined状态。如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决，置Bug的状态为Closed，如没有解决,置bug状态为Reopen。

4. 如何判断该bug是前端bug还是后端bug？

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口，传参，响应。

1. 请求接口url是否正确
   如果请求的接口url错误，为前端的bug
2. 传参是否正确
   如果传参不正确，为前端的bug
3. 请求接口url和传参都正确，查看响应是否正确
   如果响应内容不正确，为后端bug
4. 也可以在浏览器控制台输入js代码调试进行分析

如果定位为后端的bug，应该如何精确定位是哪里出了bug呢

1. 查看报错日志，通过日志分析问题点
2. 查看数据库确认数据的正确性
3. 查看缓存是否正确

版权声明：本文为CSDN博主「张喵喵是小仙女」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/miaomiao_zhang/article/details/86612539