|
认识缺陷报告 1. 缺陷报告的重要性 软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的。 清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。 提高软件缺陷修复的速度，使项目组能够有效地工作。 提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。 加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作 2. 缺陷报告的注意事项 尽量确保缺陷可以重现 如果提交的缺陷无法重现，会影响开发人员的工作效率。 简洁、准确、完整 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。 一个缺陷一个报告 有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点： 不便于分配。 比如缺陷报告有2个缺陷，分别属于不同的开发人员，到底该分配给谁呢？ 不便于验证。 比如一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2还没有解决，那么这个缺陷报告该不该关闭呢？ 3. 缺陷书写规范 标题：应保持简短、准确，提供缺陷的本质信息 尽量按缺陷发生的原因与结果的方式书写； 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状； 为了便于他人理解，避免使用俚语或过分具体的测试细节。 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。 为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题： 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解； 包含的信息过少，丢失了操作的必要步骤；
复现步骤的正确书写方式: 提供测试的环境信息； 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多； 每个步骤前使用数字对步骤编号； 尽量使用短语或短句，避免复杂句型句式； 复现的步骤要完整、准确、简短； 将常见步骤合并为较少步骤； 按实际需要决定是否包含步骤执行后的结果。 实际结果: 是执行复现步骤后软件的现象和产生的行为。 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。 期望结果:描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。 附件：对缺陷描述的补充说明，可以是以下一些类型： 缺陷症状的截图； 测试使用的数据文件; 其他： 选择合适的缺陷严重性属性； 按相应的规定，填写相应的字段信息 3.1避免常见错误 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替避免使用情绪化的语言和强调符号； 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果； 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息； 避免提交不确定的测试问题，自己至少需要重现一次再提交。 反面的示例： 上海人：哪能查询到的结果和查询条件不搭噶的。 北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了
3.2 缺陷报告
3.3 缺陷处理流程 3.4缺陷跟踪 新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。 如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开； 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。 还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。 对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。 3.5 缺陷统计 缺陷按活动分布 缺陷按严重程度分布 缺陷按引入源分布 3.6 缺陷数据分析 1）缺陷数据分析关注的问题 2）缺陷数据分析的重要性 3）缺陷数据分析的数据指标 3.7 缺陷数据分析关注的问题 正在测试的软件哪个模块的问题最多测试人员中谁报告的软件缺陷最多 各类缺陷所占的数量百分比分别是多少开发人员能及时修复软件缺陷吗 开发人员一次正确修复缺陷的百分比是多少正在开发的软件能否在计划的时间内正常发布 河南省郑州市 高新区长椿路11号大学科技园（西区）东门8号楼三层 来校路线 地铁一号线梧桐街站A口出 | 
收藏
淘帖
踩
