原创 软件测试缺陷包含哪些状态?缺陷生命周期分析

软件测试缺陷包含哪些状态?在软件测试中，缺陷生命周期常常是绕不开的话题。本文就来详细为大家讲讲，软件测试缺陷的八种生命周期的状态，缺陷的等级、缺陷单应该包含的内容等等。对软件测试的基础理论知识感兴趣的小伙伴，现在就赶紧看下去吧！
　　

1、测试过程：软件测试过程管理，主要包括软件测试是什么样的过程，如何评价一个软件测试过程，如何进行配置管理和测试风险分析以及测试成本的管理。
　　

（1）对要执行测试的产品进行静态分析，制定测试计划。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。

（2）设计测试用例。设计测试用例要根据测试需求和测试计划来进行，在前期应该尽可能多的对需求进行静态测试。保证测试用例覆盖到关键性的测试需求。
　　

（3）开发方提测以后，按照用例执行测试。执行测试时要进行进度控制、项目协调等工作。
　　

（4）提交缺陷，跟踪缺陷
　　

（5）bug bush。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”，那么正常结束测试。
　　

（6）撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改。
　　

2、缺陷生命周期--状态
　　

（1）New（新的）：bug提交到缺陷库中会自动的被设置成New状态。缺陷状态为新报告的缺陷，等待分派。
　　

（2）Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”。缺陷状态为已确认的缺陷，等待开发人员修改。
　　

（3）Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”。缺陷状态为已确认的缺陷，等待开发人员修改。
　　

（4）Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组。缺陷状态为已经被修改，等待测试人员校验。
　　

（5）Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”。缺陷状态为不是缺陷或不需要校验。
　　

（6）Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”。缺陷状态为没有修复，重新返回。
　　

（7）Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”。缺陷状态为已经得到正确修复，可以关闭。
　　

（8）Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”。缺陷状态为没有修复，重新返回。
　　

3、缺陷的等级：
　　

轻微：在某些情况下会出错，但是造成的后果影响很小。
　　

一般：软件在某些情况下会出错，但是造成的后果影响不大。
　　

严重：软件的次要功能丧失，或者主要功能在一些特定情况下会出错，比如金额计算等。
　　

致命：软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果。
　　

4、缺陷单应该包含的内容：缺陷标题，严重级别，问题所属模块，问题描述，测试角色，复现步骤，预期结果，实际结果，有关的日志和截图。
　　

以上就是软件测试缺陷的八种生命周期的状态分析。想要继续深入学习软件测试，大家可以上博学谷官网，上面有全面系统的教学视频资源，感兴趣的小伙伴可以来看看。