在测试的过程中，测试人员对发现的问题(bug)进行记录跟踪，除了对于问题本身的解决非常重要之外，也是衡量测试和开发工作质量和产出的重要依据。现在有很多成熟的问题单跟踪软件或者叫管理系统，例如Jira和禅道。每个问题单都有自己的生命周期，下面对于各个阶段进行一下简单描述。

 

问题单的创建

 

1)记录问题是在哪个平台上出现的，属于哪个模块，出问题的是哪个版本

 

2)当时出现这样的问题是做了哪些操作，能否稳定复现

 

3)对该问题的严重程度进行评级，highlight那些严重的需要尽快解决的问题(系统挂死/难以规避/重要客户/…)

 

4)保证相关人都能收到通知邮件

 

5)尽量将能够收集到的相关信息都记录下来

 

问题单的处理

 

1)开发人员接到问题单后，通过代码review或是对现场进行debug，定位出问题(可能需要测试人员帮助)

 

2)有一些软件上的问题，例如逻辑考虑不周，内存没有分配成功或是忘记释放等，直接进行修复

 

3)有一些问题可能是能够修复的，但是会对已有的稳定架构造成很大冲击，此时需要进行仔细评估，做出是否要进行修改的决定

 

4)有一些问题，涉及到平台甚至是硬件，可能在软件层面上难以规避，只能记录为limitation，进行备案，同时为后续设计制造提供建议

 

问题单的“终结”

 

1)当bug修复后，测试人员需要按照之前的复现步骤进行尝试，如果发现确实问题被修复，那么就将bug verify掉

 

2)如果发现问题仍然存在却被开发人员标示为“已解决”，那么这是开发人员的失职，需要将bug置为reopen，并进行记录

 

3)即便是已经verify的bug，在后面也可能会因为各种原因而重新出现(“终结”两字打引号的原因)，所以最好能有自动化脚本进行覆盖。

 

一点补充

 

        实际上问题单的记录本身就是一份很有价值的资料。从中可以对新模块的代码质量进行评估，可以对测试人员的工作成绩进行横向(与其它测试人员对比)和纵向(和自己过往对比)评估。

 

        测试人员与开发人员的关系，需要在工作中在“保证项目质量和交付日期”的前提下，保持一定的“敌意”，对发现的问题一定不能“大事化小，小事化了”，都要如实进行记录。这也是“测试”这个岗位存在的原因，否则开发做成什么样子，测试人员就按照什么样子去验证，那和开发人员自己去验证，也就没有什么差别了。