标签：状态 修复 开发人员 测试人员 日常 测试 缺陷 复现

缺陷报告基础*
一，缺陷的概念：英文defect，软件或者程序中存在的错误或者问题，表现为产品的功能没有满足需求。

二，缺陷的范围定义：
1） 软件没有达到需求规格说明书要求的功能。
2） 软件出现需求规格说明书中明确不会出现的问题。
3） 软件超出了需求规格说明书中要求的功能
4） 软件出现了需求规格说明书中虽未要求但应该达到的问题（容错）
5） 测试人员或者最终用户认为的其他问题（界面设计，性能）

三，缺陷状态：
注意：**在很多情况下，开发人员拒绝或者推迟修复缺陷时，需要相关人员确认

四，严重程度：缺陷对于系统的影响程度 【S1-- S4 】

五，优先级：
1） P0 紧急 需要立即进行修复（比如，12小时以内或者24小时以内）。
2） P1 一般紧急 产品发布前必须修复好。
3） P2 一般般 可以在下一个版本中修改
4） P3 不急 可以不修复（建议性问题）

写缺陷报名的基本要点
一，注意事项
1）尽量保证缺陷可以复现

• 测试时留意环境，测试操作步骤。
• 出现问题后，在本地进行多次复现。
• 注意：
  1，对于难以复现的缺陷也要提缺陷报告。
  2，难以复现的缺陷复现后可以通过截图或者保留现场进行相关证明。
  2）报告描述要简洁，准确，完整
  3）一个缺陷写一个报告

二，缺陷书写规范

• 标题
• 复现步骤
• 实际结果
• 预期结果
  1，标题：对缺陷的概要说明
• 简短，准确，提供缺陷本质信息。
• 可以尽量按照因果关系进行说明。（因果不符，就是缺陷）

2，复现步骤：按复现步骤操作，可以复现出问题

• 编号，内容简短
• 适当合并步骤，但是不要合并过多步骤
• 根据需要决定是否包含执行结果
• 注意：复现的环境要求可以放在前置条件中

3，实际结果：按照缺陷的复现步骤复现出的结果

• 对结果现象的描述要全面

4，预期结果：执行操作希望出现的结果

• 对结果现象的描述要全面

三，缺陷处理流程（缺陷的状态跟踪）

• 新提交的缺陷为新建状态，
• 确认有效后为打开状态，
• 经开发人员修改后，缺陷变为已修复（待验证）状态。
• 此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开；
• 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。
• 还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。
• 对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。

四，缺陷统计

• 严重程度：确定当前软件状态。
• 模块分布：确定哪些模块比较多，需要重点关注。
• 发现人员：一定程度上反映测试人员的技术水平
• 缺陷所处状态：Reopen状态数量多，开发人员一次修复缺陷的能力低。

**注意：**不是所有的缺陷都会被修复：
1） 缺陷修复的性价比低。
2） 缺陷无法再次复现

五，缺陷报告模板

标签：状态,修复,开发人员,测试人员,日常,测试,缺陷,复现
来源： https://blog.csdn.net/m0_45055386/article/details/119354975

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。