常见问题及建议
缺陷管理工具对 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 所示。
图 3. ODC Responder 选项签中新增加属性 ODC Validated:
有四个选项可供选择。
- “空”：默认情况下，该属性项为空。表示校验人员还没有开始进行该缺陷的校验工作；
- “是”：已被校验过，并且相关人员已经把错误的 ODC 属性进行了修改；
- “否”：已被校验过，但是相关人员还没有进行修改；
- “N/A”：对于无效的缺陷，是不算在最后的统计数据中的。出现无效缺陷的情况可以包括：由于测试人员的问题，开的无效缺陷（User Error）；所发现的问题并不是一个缺陷，而恰恰在产品设计上就是这样的（As Design）；该缺陷与之前开的另一缺陷重复（duplicate）；
文章来源于领测软件测试网 https://www.ltesting.net/
