缺陷管理:代码出现缺陷,都是如何修复的?

发表于:2021-8-30 09:50

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:软件测试test    来源:CSDN

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

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号