bug状态开发人员必知必会

在项目开发过程中，我发觉很多人在解决测试人员提出的bug之后，应该将这个bug修改成什么状态不太了解，导致了最后统计bug解决数量，以及遗留bug等等数据不准确。作为开发人员，我觉得了解bug的解决状态是一门基础课程。这里我将开发人员用到的bug解决状态列举出来，希望对大家有所帮助（这些都是开发人员在解决相应bug时应该在测试库中修改的状态）：

New（新bug）：一般测试人员录入一个新bug时，这个就是第一个默认初始状态，而开发人员看到这个状态时bug,就知 道这是一个新引入的bug。见到这个状态表示该bug必须被处理。

Assigned（已指派的）：当一个bug被指认为New之后，将这个bug指定给开发人员处理，并将bug的状态指定为“Assigned”。

Reopen(重新打开)：开发人员FIXED之后，但是经过测试他的这个bug仍然没有被解决（如果这个bug解决掉，引入的新bug不在此列）。

Close（关闭bug）：bug已经被解决,解决方案是被认为是正确的（这一步表示bug修复过程已经完成）。

Fixed（已解决）：bug已经被解决,并且通过经过测试。

Invalid（不是bug）：被描述的问题不是一个bug（测试人员提出这个bug,但是开发人员认为不是bug）。

Wontfix（不修改bug,NeedlessFix）：被描述的问题是一个bug,但是不准备进行修改。

Later（下一版本再修改）：被描述的问题是一个bug,但是不在当前版本中进行修改。（已经确定在下一版本修改）

Remind（可能到下一个版本再修改）：被描述的问题是一个bug,但是很可能不在目前版本中进行修改（注意是可能，注意later）

Duplicate（bug重复）：提出的问题和当前已经存在的某个bug重复。

Worksforme（bug不能重现）：不能重现这个bug,查看源代码也不知道为什么会出现这样的bug 现象,如果以后有更多的关 于这个bug的线索,将重新接受这个bug。（这个是对于那些知道有bug，但是却不能重现bug的情况）

可见，bug状态并不是随便指定的，是要根据具体情况具体处理，我见有的开发人员是这样处理bug的：测试人员提出bug，开发人员不管这个是不是bug，或者是重复bug，或者留待LATER修改的bug,一律设置为FIXED。这时很不负责的表现，殊不知，就有可能因为你随便设置bug状态这么一个小动作，就把bug留在了产品中，最终可能导致严重后果。切记！！！！

转载于:https://www.cnblogs.com/yangzhiqw/articles/1923745.html