谈测试(3):问题单的处理

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

问题单的创建

• 记录问题是在哪个平台上出现的，属于哪个模块，出问题的是哪个版本
• 当时出现这样的问题是做了哪些操作，能否稳定复现
• 对该问题的严重程度进行评级，highlight那些严重的需要尽快解决的问题(系统挂死/难以规避/重要客户/...)
• 保证相关人都能收到通知邮件
• 尽量将能够收集到的相关信息都记录下来

问题单的处理

• 开发人员接到问题单后，通过代码review或是对现场进行debug，定位出问题(可能需要测试人员帮助)
• 有一些软件上的问题，例如逻辑考虑不周，内存没有分配成功或是忘记释放等，直接进行修复
• 有一些问题可能是能够修复的，但是会对已有的稳定架构造成很大冲击，此时需要进行仔细评估，做出是否要进行修改的决定
• 有一些问题，涉及到平台甚至是硬件，可能在软件层面上难以规避，只能记录为limitation，进行备案，同时为后续设计制造提供建议

问题单的“终结”

• 当bug修复后，测试人员需要按照之前的复现步骤进行尝试，如果发现确实问题被修复，那么就将bug verify掉
• 如果发现问题仍然存在却被开发人员标示为“已解决”，那么这是开发人员的失职，需要将bug置为reopen，并进行记录
• 即便是已经verify的bug，在后面也可能会因为各种原因而重新出现(“终结”两字打引号的原因)，所以最好能有自动化脚本进行覆盖。

一点补充

实际上问题单的记录本身就是一份很有价值的资料。从中可以对新模块的代码质量进行评估，可以对测试人员的工作成绩进行横向(与其它测试人员对比)和纵向(和自己过往对比)评估。测试人员与开发人员的关系，需要在工作中在“保证项目质量和交付日期”的前提下，保持一定的“敌意”，对发现的问题一定不能“大事化小，小事化了”，都要如实进行记录。这也是“测试”这个岗位存在的原因，否则开发做成什么样子，测试人员就按照什么样子去验证，那和开发人员自己去验证，也就没有什么差别了。