测试人员进行分类

　　从图 1 中我们可以看到，ODC Submitter 选项签中有三个选项，分别是 Activity、Trigger 和 Impact。这三个选项是由测试人员，也就是该缺陷的发现者来填写的。由这几个属性可以得知，该缺陷是在进行何种类型测试的时候，由怎样的触发方法来发现的。同时，对用户造成的影响是什么。仅靠这三个 ODC 属性，就可以一目了然。

　　开发人员进行分类

　　从图 2 中我们可以看到，ODC Responder 选项签中有六个选项，分别是 Target，Defect Type，Qualifier Source，Age 和 ContentType。这六个选项是由开发人员，也就是该缺陷的解决者来填写的。由这几个属性可以得知，开发人员做了哪方面的修改用以解决问题？改动大不大？是原来的代码有遗漏？不正确？还是需要被删除一部分？原来的版本中是否存在这个问题？等等。有了这些属性的值，就可以很快的知道产生这个缺陷的根源了。

　　常见问题及建议

　　缺陷管理工具对 ODC 的支持不完善

　　有些 ODC 属性间是有关联关系的。例如：在 ODC Submitter 选项签中，如果在 Activity 属性中选择了“Function Test”，那么 Trigger 属性就只能在“Coverage”，“Sequence”，“Variation”和“Interaction”中进行选择。如果在 Activity 属性中选择了“System Test”，那么可选的 Trigger 属性的值又是截然不同的另外几种选项，分别为：“Workload”，“Recovery”，“Startup/Restart”，“Hardware config”和“Software config”。在缺陷管理工具中，若对这些属性间的关联关系不做限制，选择每个选项时都会把所有的值列出来供用户选择，这样很容易造成选项间的不匹配。从而导致最后统计 ODC 数据时，结果不合理。

　　另外，没有对 ODC 属性项进行必填操作的校验，也是缺陷管理工具对 ODC 支持不完善的表现之一。例如：仅填写了 Activity 属性，即表明了该缺陷是在何种类型的测试中发现的，但是不填写 Trigger 属性，也就是说不指明是在哪种触发条件下发现的该缺陷，就会造成信息缺失，从而分析出的结果也不会准确。

　　因此，我们强烈建议在配置缺陷管理工具用以支持 ODC 时，加上对有关联关系属性的限制，并对必填的 ODC 属性进行强制填写的校验，强制每个人必须填写，否则无法提交成功。从而在工具的层面上，保证 ODC 数据输入的完整性和正确性。

　　测试或开发人员对各自需要填写的 ODC 属性不熟悉

　　ODC 这种缺陷分析方法并没有普及到每一个项目中，因此在第一次应用 ODC 的项目中必须在分类阶段前，就要在项目内部做好 ODC 知识的系统培训。不仅仅是简单的了解，而是需要知道每个属性所有可选项的含义。这样就不会在分类阶段开始后，一片茫然。另外，由于 ODC 属性选项众多，不可能靠之前的几次培训就全部记住。建议打印一份类似于 ODC 属性快速参考手册的资料。这样在填写 ODC 数据时，可一边参考手边的文档一边填写。

　　2. 校验阶段

　　在第一步中，测试人员和开发人员已经填写了 ODC 数据。那么接下来就需要 ODC 专家对这些数据进行校验。因为填写不正确的 ODC 数据会导致后面的评估和行动两个流程步骤没有意义。因此校验数据的正确性尤为重要。

　　常见问题及建议

　　校验结果如何在缺陷管理工具中体现？

　　校验员在校验完某个缺陷并确认相关人员已经完成修改后，校验工作还并没有结束。为了在下一阶段，即评估阶段中，仅仅对已被校验过的缺陷进行分析，就需要在缺陷管理工具中有地方进行标识，用以过滤掉未校验过的缺陷。

　　可以在 ODC Responder 选项签中增加一个属性项，叫做“ODC Validated”。如图 3 所示。

　　有四个选项可供选择。

　　* “空”：默认情况下，该属性项为空。表示校验人员还没有开始进行该缺陷的校验工作；

　　* “是”：已被校验过，并且相关人员已经把错误的 ODC 属性进行了修改；

　　* “否”：已被校验过，但是相关人员还没有进行修改；

　　* “N/A”：对于无效的缺陷，是不算在最后的统计数据中的。出现无效缺陷的情况可以包括：由于测试人员的问题，开的无效缺陷（User Error）；所发现的问题并不是一个缺陷，而恰恰在产品设计上就是这样的（As Design）；该缺陷与之前开的另一缺陷重复（duplicate）；