问题单电子流

产品问题缺陷库是研发系统最核心的一个IT系统，所有的测试执行过程都是基于这个系统进行的。问题单库是一个电子流，由测试人员提交，由开发人员定位解决，最后再由测试人员回归测试后关闭。在这个过程中，测试经理、开发经理负责审核。每个环节中相关的责任人都要填入必要的信息，以保证下一环节的人员能够顺利处理。

 

问题单基本流程

以下是一个最常见的问题单处理流程：
1.测试人员在测试过程中发现缺陷，提交问题单
说明：测试人员要输入缺陷所在版本号，缺陷描述，缺陷严重程度，导致缺陷出现的操作方法，问题出现时的界面截图，问题是否可重现（或随机重现），问题所在模块。详细的缺陷描述有助于开发人员精确的定位问题原因所在。其他的信息用于统计并评估版本质量。
2.测试经理审核问题单
说明：测试经理进行审核，判断问题是否合理有效、是否重复，测试人员填写的信息是否规范、清晰等。
3.开发经理审核问题单
说明：开发经理从开发的角度审核问题的有效性和规范性，并指派适当的开发人员进行定位。
4.开发人员定位问题原因
说明：这个阶段主要是定位问题原因，但不修改（至少在流程上没有体现出来），因为找到的问题原因是否合理需要有开发经理审核。也许一个问题可以有两种修改的方法，开发人员和开发经理可能有不同的看法，这时候不应该仓促着手修改。
5.开发经理审核问题定位的正确性
说明：同上
6.开发人员实施修改
说明：开发人员应该把修改的代码作为附件贴在电子流上，或者如果是采用ClearCase配置库，开发人员应该在配置库上创建以问题单号命名的分支，并在电子流中知会管理员。不管哪种方式，开发人员还应该将问题单号、描述、修改方法和修改文件列表按指定的格式填写清楚。因为配置管理员在合入问题的时候，需要将这些描述作为备注加入，以便后续的追溯。
7.配置管理员合入问题单
说明：这个环节不完全是一个机械性的动作。多个开发人员有可能同时修改一个文件并产生冲突，这需要配置管理员来判断和解决。根据版本发布计划，不一定所有的问题都在同一个版本中合入，配置管理员也会做一定的控制。
8.新版本发布时开发人员验证问题单修改情况
说明：新版本发布时，开发组进行内部验证，开发人员需要验证问题是否已经解决，因为多个环节的配合可能出现偏差，可能的原因有：代码修改错误、CMO忘记合入、代码冲突、版本制作出错。
9.测试经理接收修改后的问题单
说明：这个环节中，测试经理指派适当的测试人员进行回归测试。
10.测试人员执行回归测试后归档问题单
说明：回归测试，如果不通过，会将问题单打回开发人员重新修改。回归测试不通过是很严重的问题。
11.问题单归档
说明：问题单解决以后不会被简单删除，而是被归档起来，作为后续重复问题等的参考。有些问题作为已知缺陷或者无效问题不被解决，也是需要被归档下来，可供日后有争议的时候参考。

争议问题单裁决
另外一个重要的问题单处理流程是争议问题单裁决。如果开发经理认为测试人员提交的问题单无效，可以将问题单提交给变更控制委员会（CCB）进行裁决。变更裁决委员会由系统工程师、开发经理、测试经理等组成，组长是系统工程师。在充分讨论以后，组长如果裁决该问题单为无效，可以在电子流上给出结论，并将问题单归档。

问题单复制

还有一个流程是问题单的复制。对于需要跨团队解决的问题单，开发经理在保留本问题单库中问题单的同时，将问题单复制给其他团队，只有其他团队解决了问题单，本问题单库的问题单才能被关闭。

问题单统计

通过从电子流上导出统计信息或报表，开发和测试团队可以 评估每个版本的质量，如产生多少问题单、这些问题单的严重程度（致命、严重、一般、提示），当然，问题单是否可重现也是评估的一个要素。对于几个连续版本，问题单的收敛趋势理论上应该符合一定的经验规律。如果前两个版本问题单很多，第三个版本突然大幅度下降，管理人员有理由怀疑中间是否存在猫腻，开发经理是否和测试经理达成私下妥协。如果之前的版本问题单很少，后面没有合入重要修改但问题单数量却飙升，是否是测试组之前测试不充分？或者开发组出了什么问题？