通信软件白盒测试的三种境界

发表于:2009-06-02来源:作者:点击数: 标签:通信软件境界白盒
通信软件被普遍认为是 白盒测试 最难实施的领域,一方面,通信软件以C语言为主体语言,先进的白盒测试技术尚未有效渗透到这个区域,另一方面,通信软件通常是 嵌入式 实时系统,搭建 测试环境 非常复杂,又加上通信软件通常体积庞大、结构复杂,把通信软件的
 通信软件被普遍认为是白盒测试最难实施的领域,一方面,通信软件以C语言为主体语言,先进的白盒测试技术尚未有效渗透到这个区域,另一方面,通信软件通常是嵌入式实时系统,搭建测试环境非常复杂,又加上通信软件通常体积庞大、结构复杂,把通信软件的单元测试集成测试做好确非易事。

        笔者有幸在通讯领域工作多年,近些年又因为咨询的关系与国内众多企业打交道,感触颇多。国内企业普遍对白盒测试没感觉也不重视,少数比较注重质量的公司努力尝试了,但处处碰壁,不是缺少方法就是缺少合适的测试工具,或者因为管理不善白盒测试最终做不起来。当然,想做没做成,找不着道的企业不在少数,许多公司一开始就走错方向了,在叉路上徘徊很久而混然不觉。

        国内通信企业在单元测试与集成测试方面做得好与不好的,差别很大,我们划分三种境界:混沌、有序、自发,这三种境界指的就是三种发展阶段。当然,这里分门别类的意义并不在于区分出高低上下,而在于尝试指出白盒测试的发展方向,另外,对历史经验作一次总结,通信软件因其复杂性,白盒测试无法一蹴而就,某些特定阶段必须要亲身经历,我们划分三种发展境界同时,也尝试说明在各种境界下如何实施白盒测试?重点在哪?要规避哪些问题?

境界之一:混沌状态
        混沌状态是刚实施或从未实施白盒测试的发展阶段,在这个阶段,一个企业内只有零星的单元测试或集成测试实践,缺少成功案例,该阶段最典型的特征是:每一个人都很忙,整天忙于市场救火。

        企业上上下下谁都在忙,本该在实验室做测试的测试人员被赶到市场一线,在客户的机房上跳下蹿,低头忙于调测,抬头忙于跟客户掩饰问题。本该呆在家编码的开发骨干也时不时被逮到现场,架调试环境,使出混身解数来定位问题,遇到棘手些问题通常要耗上数天才能定位,也有许多时候现场定位不了,就偷偷地复位一下设备,谎称问题解决了,然后赶紧溜回公司,一行行翻阅代码通宵达旦的继续定位。

        混沌状态最大的特点是大家都忙于救火,系统测试的投入尚无保障,更别说代码级的测试投入了。该阶段会造就众多“救火英雄”,而“纵火犯”的责任难以追究,按照通信业界的通行规律,一个产品60%的BUG应在白盒阶段曝露,当公司尚充斥着众多“救火英雄”时,白盒阶段发现的BUG通常不到20%,甚至个别公司是零。

        混沌状态还有一个重要特点,公司成员普遍对白盒测试缺少概念,大致知道代码审查、单元测试、集成测试该怎么去做,但一涉及具体场景,对某模块实施单元测试或跨模块、跨子系统实施集成测试时,通常茫无头绪,不知从何下手。处于混沌状态的组织,还可能流行一种观点:产品不稳定是测试人员的责任。因为许多人认为,尽管单元测试与集成测试没做,或做少了,只要系统测试做好总能发现所有问题的。其实这种观点早已谬之千里了,令人费解的是,持这种观点不在少数,为什么会这样?就像该阶段出现的特有现象,明明某个开发人员水平很差,写的代码老出问题,但他在市场上救过几次大火,其兢兢业业的态度、忘我的投入,又为公司挽回多少多少损失,所以领导们毫不犹豫的将他评为“功臣”。

境界之二:有序状态
        一个企业实施过多次单元测试或集成测试,数次成功后进入到有序状态。这个阶段尽管个别项目的白盒活动不成功,但多数项目稍见成效,也有个别项目效果显著。此时,企业内会有特定的组织负责推动白盒测试,白盒测试过程也逐渐融入研发流程,典型的例如:将白盒测试发现的问题纳入统计,研发过程中会以缺陷密度(每千行代码发现多少BUG)作为衡量白盒测试是否充分的指标,另外还会以覆盖率指标作为检查个人是否充分测试的依据。将白盒测试纳入流程监控,主要控制一个项目是否做白盒测试,实施过程是否规范,实施结果是否合乎预期,对于不符合流程要求的行为QA有权要求返工。

       

原文转自:http://www.ltesting.net