空间管理您的位置: 51Testing软件测试网 » 啄木鸟的个人空间 » 日志

赢在测试2 读书笔记（2）彭月篇

上一篇 / 下一篇 2014-07-18 18:52:15 / 个人分类：读书笔记

查看( 1008 ) / 评论( 0 ) / 评分( 0 / 0 )

l 有多种业余爱好是一笔宝贵的财富，可修身养性，也可打法时间

l 测试一定要比客户更专业

l 挑战1，特殊用户使用的场景
挑战2，专业知识深度不够
挑战3，实验室环境与客户环境不同

l 敏捷中保证测试工程师独立而独特的视角，坚决同意

l CMM5,千行代码bug率在千分之2.53之下

l IBM ODC Orthogonal Defect Classification正交缺陷分类[1]

l 绩效分为基本绩效和贡献

l 软件测试做2个纬度
验证我们的产品是否达到设计要求
在第二步基础上再去发现更多缺陷，并且是否可以优化

l 作为一个管理者，首先要有经营意识

l 支持鼓励渐进性创新，而不是变革性创新。注：可操作性强

l 测试框架
云计算服务层
核心驱动层
自动化测试框架

l 招聘看中
聪明
有激情
该学的都学好

l 突破发展前景
保持危机意识
实现专业生存
保持开发心态

附录

[1]

正交缺陷分类（ODC）流程简介及应用经验分享

2010-04-30作者：谷珊来源：IBM

正交缺陷分类（ODC）简介

正交缺陷分类法，Orthogonal Defect Classification（以下简称ODC）是一种缺陷分析方法，由IBM在1992年提出。它通过给每个缺陷添加一些额外的属性，利用对这些属性的归纳和分析，来反映出产品的设计、代码质量、测试水平等各方面的问题。从而得到一些解决办法来进行改进。例如对于测试团队，通过ODC可以知道测试工作是否变得更加复杂；每一个测试阶段，是否利用了足够多的触发条件来发现缺陷；退出当前测试阶段有什么风险；哪个测试阶段做得好，哪个测试阶段需要改进等。对于开发团队，利用ODC可以知道产品设计和代码编写的质量情况。而给产品用户带来的好处就是提高客户满意度，减小产品投入市场后的维护花费。

ODC的工作流程分为四部分：“缺陷分类”，“校验已被分类的缺陷”，“评估数据”以及“采取行动来改进工作”。下面我们将逐一进行讲解。

1.分类阶段

分类，是ODC工作流程中的第一步，即需要测试和开发人员分别对每一个缺陷填写ODC属性。对于团队成员来说，正确的了解每个属性的值尤为重要，这样才能保证他们在分类时尽量选择正确的选项。

前提条件

有些缺陷管理工具在默认情况下是不支持ODC的，这就需要在填写之前，对缺陷管理工具进行改进，配置额外的属性。常用的缺陷管理工具包括Clear Quest(CQ)和Configuration Management Version Control(CMVC)等。需要增加的9个ODC相关属性分别是。

Activity：表示在做哪种测试时发现的缺陷。比如：UT(单元测试)、FVT（功能测试），SVT（系统测试）等；
Trigger；表示采取哪种方式触发的该缺陷，不同的activity对应不同的trigger类型；
Impact：表示该缺陷的发生会对客户造成的影响；
Target：表示开发人员为了修复这个缺陷，需要在哪方面做修改。比如可以修改的方面包括：产品设计、相应的代码和文档等；
Defect Type：缺陷类型；
Qualifier：表示该缺陷是由于丢失相关代码、还是代码不正确造成的。或者是由于第三方提供的代码造成的；
Source：表示该缺陷的来源是由于内部编写的代码引起的问题，还是由外包公司提供的代码引起的等；
Age：表示该缺陷是由新代码产生的还是由于修改其它缺陷而引发的，或是在上一个发布版本中就已经有的问题等；
Content Type:表示修复文档的类型。仅对文档类的缺陷有效。

对于CMVC，自从1.7版本后就自带了ODC属性，可直接使用。而对于CQ，需要安装一个ODC包即可。关于该ODC包可从附件中下载，解压后里面有详细的文档教读者如何在CQ中安装该包。

在配置好ODC后，CQ的应用程序窗口中会出现新的选项签：ODC Submitter和ODC Responder，如图1和图2所示。

图1. CQ中的ODC Submitter选项签

图2. CQ中的ODC Responder选项签

在缺陷管理工具支持ODC后，就需要测试人员和开发人员分别填写ODC属性，后面的流程都会用到这些数据。

测试人员进行分类

从图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所示。

图3. ODC Responder选项签中新增加属性ODC Validated:

有四个选项可供选择。

“空”：默认情况下，该属性项为空。表示校验人员还没有开始进行该缺陷的校验工作；
“是”：已被校验过，并且相关人员已经把错误的ODC属性进行了修改；
“否”：已被校验过，但是相关人员还没有进行修改；
“N/A”：对于无效的缺陷，是不算在最后的统计数据中的。出现无效缺陷的情况可以包括：由于测试人员的问题，开的无效缺陷（User Error）；所发现的问题并不是一个缺陷，而恰恰在产品设计上就是这样的（As Design）；该缺陷与之前开的另一缺陷重复（duplicate）；

校验小组成员间如何更有效的沟通？

校验小组成员通常会从测试和开发人员中分别挑选。在很多大项目中，测试和开发团队可能并不在一个地区，甚至存在时差。如何增强跨地区小组成员的交流，使得资源共享、沟通及时无误呢？这就需要有一个信息共享平台。从我们的实际经验中来看，wiki是一个不错的选择。wiki是一种多人协作的写作工具，每个人都可以在上面发表意见。下面是作者正在参与的一个项目组所采用的ODC校验小组wiki上的内容，包括如下方面。

目的：明确校验工作的目的；
校验小组人员名单：包括姓名和联系方式；
校验流程说明：针对本项目的特点，制定出适合本项目的校验流程。以作者参与的项目为例，校验流程可以包括：

每周一，由ODC校验小组负责人分配给每个人这周需要校验的缺陷（分配的方式，会在下面的“每周工作安排”中提到）；
校验小组中的每位成员开始逐一校验分配给自己的缺陷。如果发现该缺陷的ODC属性有填写不正确的或忘记填的，就需要马上发邮件给该缺陷的发现者或解决者，予以修改。若缺陷本身的描述信息足以令校验员分析出正确的选项，那么在邮件中需要写明校验员的修改意见及原因。若缺陷的描述信息不清晰以至于校验员无法作出准确判断的，也需要在邮件中指明。待测试或开发人员在缺陷中补充了更详细的信息，校验员再重新进行校验。
一旦校验完成，校验员需要在缺陷管理工具中对该缺陷进行标识，如前面我们提到的“ODC是否已被校验”属性项，这时把它的值从默认值“否”修改为“是”。以表明该缺陷已被校验过。校验组长下次再分配待校验的缺陷时，就会把已被校验过的缺陷过滤掉。
校验员把在校验过程中发现的问题，例如错误分类趋势等进行反馈；