通信软件被普遍认为是白盒测试最难实施的领域,一方面,通信软件以C语言为主体语言,先进的白盒测试技术尚未有效渗透到这个区域,另一方面,通信软件通常是嵌入式实时系统,搭建测试环境非常复杂,又加上通信软件通常体积庞大、结构复杂,把通信软件的单元测试或集成测试做好确非易事。
笔者有幸在通讯领域工作多年,近些年又因为咨询的关系与国内众多企业打交道,感触颇多。国内企业普遍对白盒测试没感觉也不重视,少数比较注重质量的公司努力尝试了,但处处碰壁,不是缺少方法就是缺少合适的测试工具,或者因为管理不善白盒测试最终做不起来。当然,想做没做成,找不着道的企业不在少数,许多公司一开始就走错方向了,在叉路上徘徊很久而混然不觉。
国内通信企业在单元测试与集成测试方面做得好与不好的,差别很大,我们划分三种境界:混沌、有序、自发,这三种境界指的就是三种发展阶段。当然,这里分门别类的意义并不在于区分出高低上下,而在于尝试指出白盒测试的发展方向,另外,对历史经验作一次总结,通信软件因其复杂性,白盒测试无法一蹴而就,某些特定阶段必须要亲身经历,我们划分三种发展境界同时,也尝试说明在各种境界下如何实施白盒测试?重点在哪?要规避哪些问题?
境界之一:混沌状态
混沌状态是刚实施或从未实施白盒测试的发展阶段,在这个阶段,一个企业内只有零星的单元测试或集成测试实践,缺少成功案例,该阶段最典型的特征是:每一个人都很忙,整天忙于市场救火。
企业上上下下谁都在忙,本该在实验室做测试的测试人员被赶到市场一线,在客户的机房上跳下蹿,低头忙于调测,抬头忙于跟客户掩饰问题。本该呆在家编码的开发骨干也时不时被逮到现场,架调试环境,使出混身解数来定位问题,遇到棘手些问题通常要耗上数天才能定位,也有许多时候现场定位不了,就偷偷地复位一下设备,谎称问题解决了,然后赶紧溜回公司,一行行翻阅代码通宵达旦的继续定位。
混沌状态最大的特点是大家都忙于救火,系统测试的投入尚无保障,更别说代码级的测试投入了。该阶段会造就众多“救火英雄”,而“纵火犯”的责任难以追究,按照通信业界的通行规律,一个产品60%的BUG应在白盒阶段曝露,当公司尚充斥着众多“救火英雄”时,白盒阶段发现的BUG通常不到20%,甚至个别公司是零。
混沌状态还有一个重要特点,公司成员普遍对白盒测试缺少概念,大致知道代码审查、单元测试、集成测试该怎么去做,但一涉及具体场景,对某模块实施单元测试或跨模块、跨子系统实施集成测试时,通常茫无头绪,不知从何下手。处于混沌状态的组织,还可能流行一种观点:产品不稳定是测试人员的责任。因为许多人认为,尽管单元测试与集成测试没做,或做少了,只要系统测试做好总能发现所有问题的。其实这种观点早已谬之千里了,令人费解的是,持这种观点不在少数,为什么会这样?就像该阶段出现的特有现象,明明某个开发人员水平很差,写的代码老出问题,但他在市场上救过几次大火,其兢兢业业的态度、忘我的投入,又为公司挽回多少多少损失,所以领导们毫不犹豫的将他评为“功臣”。
境界之二:有序状态
一个企业实施过多次单元测试或集成测试,数次成功后进入到有序状态。这个阶段尽管个别项目的白盒活动不成功,但多数项目稍见成效,也有个别项目效果显著。此时,企业内会有特定的组织负责推动白盒测试,白盒测试过程也逐渐融入研发流程,典型的例如:将白盒测试发现的问题纳入统计,研发过程中会以缺陷密度(每千行代码发现多少BUG)作为衡量白盒测试是否充分的指标,另外还会以覆盖率指标作为检查个人是否充分测试的依据。将白盒测试纳入流程监控,主要控制一个项目是否做白盒测试,实施过程是否规范,实施结果是否合乎预期,对于不符合流程要求的行为QA有权要求返工。
进入有序状态须满足两个条件:一是白盒测试在少数项目获得成功,成为可拷贝的活动;二是实施白盒测试有组织与流程保证。如果这两个条件无法同时满足,说明单元测试或集成测试在这个企业中仍缺少保障,即使有人偶尔做成功了,也是不可靠的,个体行为难以转化为组织行为。
有序状态是通信企业白盒测试必经历阶段,多数比较漫长,快则一、两年,慢则十余年,要有长时间技术积累,以及组织与流程的优化。另外,从有序状态转向自发状态,会涉及白盒测试理念的大幅转型,从现实操作角度考虑,这些是很难在一两个项目周期就能跨越过去的。
有序状态的发展过程中,多数企业会遇到如下问题或现象:
1. 开始认识到单元测试该由开发人员去做
多数尚处于混沌境界的企业会认为,单元测试应由测试人去做,可能会觉得开发人员自己编码又自己测试会陷入惯性思维,测试效果不佳。但让测试人员现实操作几次,又会冒出几个难以逾越的问题,首先是测试效率,测试人员不熟悉代码,他上手把源码读懂然后想办法做测试,要知道,单元测试面对众多琐碎的函数,随意一个开发人员一天就能写一堆新函数,所以,测试人员若把单元测试做好,通常要比开发人员自测多付10倍的精力,这一情况很致命,单元测试必然难以为继。其次,测试人员做单元测试,经常不能断定某种现象是不是问题,还得找相应开发人员去定位,问题定位了,修正问题又是个麻烦,测试人员不拥有给产品编码的权限,大量时间又浪费在反复沟通上。
所以碰过几次壁后,多数企业都会回到这种操作方式:每个开发人员自己写代码,自己做单元测试(主要是模块级白盒测试)。这是主流运作方式,非主流的,还可能间或让两个互相熟悉对方代码的开发人员,交叉一下做单元测试,这也是比较有效的方式。
2. 会发现只拿覆盖率评估测试是否充分是不够的
引入业界工具实施覆盖率测试,当一个企业白盒测试做到一定程度时,会陷入一个困惑:拿覆盖率评估测试充分与否是否足够?为覆盖率而覆盖率,目标太容易达成,运行一两个高层次的业务调用,覆盖率很快就上去了,也即,如果有人想作 弊,他完全可以只写很少用例就让覆盖率满足要求。有人就这个问题进一步思考,又产生另一个困惑:白盒测试到底测什么?测看得到的代码吗?代码覆盖率直观的表达了可见代码是否跑到,但如果规格有要求又忘实现了,覆盖率能说明什么?
3. 不同员工做白盒测试,效果差别巨大
这种现象是每个公司都会遇到的,在白盒测试推行初期表现尤为明显。能力强的就是很少漏测,很少遗漏问题到后续阶段,能力差的,尽管他很努力的想把每件事做好,漏测总还很多。
4. 会有白盒测试无用论产生
产生白盒测试无用论,多半不是从理论上反对白盒测试,而是实践走不通,做了不少单元测试,效果不佳,发现问题留于表面,深层次逻辑问题或接口问题发现不了,所以就认定白盒测试没多大用处。
也常见一种情况,发现白盒测试没效果会认为自己没掌握测试方法,所以想方设法寻求“见血封喉”的致命武器,几经努力后,仍无特效药可买,这种情形继续发展,白盒测试无用论很可能就产生了。
白盒测试没效果的本质是难以突破“机械测试”的盲区,所谓机械测试,是指依据可得见的代码做测试,典型的比如,被测代码有“1+1=2”语句,所以设计用例,结果也验证“1+1”必然是等于2的,测试用例总数、覆盖率都达标了,就是发现不了多少问题。突破“机械测试”盲区的法宝是“按规格去设计用例”,但这么一条简单的规则说起来容易,做起来很难,能力强的会不自觉得遵守这条规则,能力弱的常想不起来,想起来也经常无处着手,思维被条条框框禁锢住了。所以,许多时候个体很见效的白盒测试难以上升到组织行为。
5. 白盒测试能否成功很大程度上依赖于牛人经理或牛人QA
这一点也是白盒测试推行初期经常出现的,执行力强一些的经理或QA,白盒测试可以推行成功,执行力弱一些的就不成功。不少企业因为尝试几次单元测试都失败了,就全盘放弃白盒,只做黑盒测试了。
有一些企业坚持下来,在一两个项目组取得成功,然后针对性的优化组织机构,比如设置专门工作推动组,建设白盒测试专家资源池,为各个项目提供测试引导人员,进一步优化流程,把白盒测试的监控点纳入流程来控制。当一个企业的组织机构与流程逐步完善,白盒测试能否成功就较少依赖于个别牛人了。
6. 阶段化实施白盒测试,测试用例无法维护
集中一段时间编码,编码完了再集中一段时间做单元测试,单元测试完了开始集成,这时又集中时间做一次集成测试,这是多数企业实施白盒测试的模式。这一模式下,单元测试或集成测试只是特定时间段内(比如一个版本周期内的一两星期中)才实施的活动,但产品修改代码却是时时刻都在进行的,毫无疑问的会带来一个深刻问题:用例维护与产品代码维护不同步!所以,大家就经常会看到,某个产品的第一个版本可以把单元测试完整实施一遍,而此后时不时为解决问题改代码,或为追加功能改代码,单元测试很难继续,常导致单元测试只在V1版本做一遍,其后V2、V3等版本无法再做。
不间断的代码修改与阶段化的白盒测试明显不协调,这问题表面看起来并不严重,解决起来却远没想象的简单,该问题可以上升到操作模式问题,解决这个问题,必然要引入一种时时测试的模式,很自然,大家马上猜得出用什么模式?就是持续集成!
或许有人会觉得,为让白盒测试在版本周期内坚持做下去,不见非得引入持续集成吧?试想一下,从编码到版本进入维护,开发人员独立无干扰的编码时间有多少?而从两两开始集成之后,又占去多少时间?无疑后者占去大部分时间。如果开始集成后的每次版本修改都有测试跟进,大家岂非天天写测试用例,这不是持续集成是什么?如果不想天天补充用例,隔周、隔月,或隔一个版本补充用例,怎知你增补的用例会覆盖全部变动过的代码?
通信领域的代码普遍很庞大、很复杂,一个版本周期通常是30~40星期,从开始编码到第一次两两合版本,通常是2~3周时间,之后就进入持续集成测试的阶段,该阶段会延续很长时间,通常10周以上,所以,如果坚持阶段性测试,必然导致白盒测试难以为继,每个人写的用例难以维护,写一次用一次,然后就扔了。
为清晰起见,我们将阶段性测试称作一次测试,与之相对的持续集成方式下的测试称作持续测试。尽管很多人不认为阶段性测试的用例只用一次,但现实情况好不到哪儿去,集中一段时间写的用例,当源码有较多修改后,再集中一段时间维护旧用例会很痛苦。
7. 每个研发阶段结束,尝试将每个人的用例合并起来
合并测试用例是一次测试思维的自然延续,其出发点是为了让测试集能更好的维护,但事与愿违,越是合并的用例越是无法维护,除非被测系统非常简单,也很少去变更,当然,如果系统很少变更,维护用例的需求也不强烈了。
合并之前的脚本尚有明确的维护责任人,但合并之后测试脚本该由谁去维护?况且按照经验,一次充分的单元测试,测试脚本的规模应与被测代码相当,各人编写用例的运行环境又千差万别,如此庞大的体系合起来并不容易,合起来后也无法维护。所以,合并用例是企业处于有序状态特定阶段才做的事,通常只做几次,达不到效果就不会反复去做了。事实上,遵循一次测试模式的组织内,大家自己管自己,用例不合并都已经很难维护了。
8. 仍有员工试着要上单板做单元测试
嵌入式产品的单元测试该不该上单板?这个问题更多的可归结为实践上可不可行,从理论上讲没人规定单元测试就不能上单板。但现实操作中,通信产品上单板做单元测试大部分都失败,失败的情形笔者见过的不是两三个,而是十数个,尤其是大公司,每个产品组中总有一些自信满满的员工,都愿意相信上单板做UT才是正道。
当然,本文并不否定上单板做UT就不能成功,而是说成功的机率比较低,况且,是否成功的定义也是因人而异,见仁见智的。打个比方说,一个开发人员写一天代码,然后用一天时间就把新写的代码测试完了,这种情况下,白盒测试是可维持的,做得下去的,而当种种条件限制(比如上单板每次下载都要消耗很长时间,单元测试面对初始代码,没测几分钟板上程序就会跑飞),写1天的代码要用10天才能测完,这种测试是很难维持的。
上单板做单元测试的致命因素是测试效率,试想一下,主流通信软件使用C语言,想把纯软件C语言工程的白盒测试做好,相对java、C++等工程已属不易,上单板在实时操作系统下把UT做成功,更是难上加难。所以,依据实践的推论,通信软件的单元测试应在仿真环境下按纯软件的方式去做,集成测试倒是可以上单板,在真实环境下去做。
任何事物都有3种发展方向:前进、原地踏步、倒退,上面我们描述了白盒测试在有序境界下的行为特征,字里行间还点出了各种行为的改进方向,有针对性的改进了,白盒测试就不断前进,反之出现倒退,回到混沌状态。比如在推行初期,白盒测试能否成功很大程度受项目组的执行力度影响,改进这一点须要优化组织结构与流程方法,若任其自然,在个别项目已成功的白盒实践仍无法拷贝到其它项目。
有序状态介乎混沌状态与自发状态之间,因其时间跨度较长,我们还可经细分出有序初期阶段与有序后期阶段,在有序初期阶段什么都不规范,白盒测试也常在成功与不成功之间晃动,而在有序后期阶段,应该具备某些自发状态的表现特征了。具体而言,有序状态向自发状态发展,要跨越两大考验,其一,要解决一次测试的问题,要向持续测试过渡,其二,要在组织运作层面解决“机械测试”的问题,上面提到不同员工做测试效果差别很大,有差别是正常的(否则优秀员工无法称之为优秀),但能否将能力差异对结果影响缩小到系统测试那样呢?
通常,白盒测试能力强的员工编码能力也强,测试能力差的编码能力也差,极少听说测试能力很强但编码很差。所以,要让白盒测试做得更深入、更有效,重点是解决思维方式问题,通过培训、日常锻炼也能起到一定效果,但终归不明显,毕竟项目组内个个都是得道高僧比较少见。根据实践经验,解决这个问题的最有效的措施是测试先行,如果编码之前就写用例,只能依据规格做测试设计了,这对能力强的与能力弱的都一样,思维方式强行改变,其测试无疑是最彻底、最见效的。
从有序前期阶段过渡到有序后期阶段,如何看待测试代码也有很大变化,在前期,开发是开发,测试是测试,测试操作连同测试代码是附加的,可选的,到有序后期阶段,大家会把测试代码也看成一种产品代码,是必需的,也自然而然纳入产品维护。
境界之三:自发状态
自发状态是白盒测试的共产主义境界,此时生产力高度发达,设计用例的效率提高了,做测试不再是沉重负担。所谓自发,就像共产主义社会里劳动是个人意愿而非生存手段,开发人员自测也上升到个人意愿,即使领导不强制,流程也不限定白盒测试必须要做,开发人员仍自愿去做测试。自发状态是白盒测试的最高境界,它的典型表现特征是:白盒测试已成员工的普遍行为与自发行为。
白盒测试进入自发状态,必须经历两大转变,一是测试效率要有数倍提高,这是基础,二是测试实践能够深入,能有效发现各种问题。目前已有一些公司经历过这两种转变,前者测试效率提高主要依赖于在线测试、持续测试、黑盒调测等理念(详情请见《第4代白盒测试方法概述》中拉通测试小循环、拉通研发大循环、调试转化为测试等章节),而后者有效发现问题,测试先行(TDD)已接受广泛的实践检验。当上述两大转变完成了,白盒测试就成为每位员工的必须行为,就像调试操作,每位员工写完代码,正常都要“调一调”,在自发境界下,随时“测一测”是每位员工自然而然要做的事。自发境界下的一个组织,实际操作中“测一测”很大程度上代替了“调一调”,这时,员工数月不开调试器是常见的现象,因为“测一测”对开发人员来说是让程序跑起来最经济实惠的手段,也是查错、检错最便利的方式,使用调试器并非必需。
在自发境界下,时时测试、持续测试已成一种风气。另一方面,员工从领导层到基层,都普遍对白盒测试有着深入认识,知道白盒测试应该“有所为有所不为”,企业培养了一批白盒测试专家,他们很清楚哪些被测对象是可以做白盒测试的,哪些不大容易做。即使处于白盒测试最高境界,也并非所有系统都适合完整的做测试,尤其那些严重依赖特定硬件环境的软件层,当白盒专家识别出哪些模块不宜做单元测试或集成测试后,他会考虑替代方案,比如加强代码审查、加强同行评审、为特定接口追加模拟器设计等。
总结
本文描述了通信业界的白盒测试三种境界:混沌、有序、自发,这三种境界反映了通信企业在白盒测试领域的一般发展过程。从混沌状态升级到有序状态,核心焦点是要解决测试效率的问题,只要效率提高了,一个组织是很容易从混沌状态进阶到有序状态的初级阶段,接着通过组织结构与流程措施的优化,巩固已有成果,然后着重解决持续测试与深入测试的问题,解决好了就升级到有序的高级阶段,升级的关键在于“持续测试”这个理念的转型。从有序状态进阶到自发状态,涉及测试效率与测试质量的全面提升,操作模式会有很大变化,测试工具是关键,工具不仅方便易用、测试效率奇高,而且要方便让大家从“调一调”向“测一测”转变。
上述企业白盒测试三种境界,可与孔夫子的人生境界相比拟,孔夫子说:吾十有五,而志于学,三十而立,四十而不惑,五十而知天命,六十而耳顺,七十从心所欲,不逾矩。
“十有五而志于学”,这是混沌境界,“志于学”三字点出该阶段要做的事,对于白盒测试来说,处于混沌状态下的企业要勇于尝试,否则永远是原地踏步,没有进步;“三十而立,四十而不惑”对应于有序境界,此时白盒测试已找到门道,“不惑”是坚定自己的信仰,持续做下去,持续优化下去,所以,处于有序状态的企业贵在坚持;“七十从心所欲,不逾矩”,这是自发境界,老夫子的从心所欲,并非无限制的为所欲为(要不,孔圣人不该叫圣人,而应该叫神人),关键是“不逾矩”,知道规矩在哪才能不逾矩,才能从心所欲,所以,自发境界下的白盒测试还要“有所为有所不为”。我们概括一下:企业白盒测试处在混沌状态贵在尝试,处在有序状态贵在坚持,处在自发状态贵在自知。
参考文献:
1. ezTester,Wayne Chan,《第4代白盒测试方法通俗释义》
2. ezTester,Wayne Chan,《第4代白盒测试方法介绍(理论篇)》
3. ezTester,Wayne Chan,《第4代白盒测试方法介绍(VcTester实践篇)》
4. ezTester,《企业如何推行白盒测试》
5. ezTester,《实施白盒测试的几个误区》
================ END ==========================
本专题相关的文章:
第4代白盒测试方法介绍--理论篇
第4代白盒测试方法介绍--VcTester实践篇
第4代白盒测试方法通俗释义
第4代白盒测试方法之“为什么要做白盒测试”
第4代白盒测试方法之“企业如何推行白盒测试”
第4代白盒测试方法之“实施白盒测试的几个误区”
第4代白盒测试方法之“如何选择嵌入式白盒测试工具”
第4代白盒测试方法实践之“VcTester持续集成框架的应用价值”
第4代白盒测试方法实践之“使用VcTester实施持续集成的组织管理模式”
第4代白盒测试方法实践之“如何在VcTester集成自动构建功能”
第4代白盒测试方法实践之“使用VcTester构造持续集成及每日构建平台”
第4代白盒测试方法实践之“内存泄露检查工具VLD如何与VcTester配合使用”
第4代白盒测试方法实践之“如何将Pclint嵌入到VcTester中使用”
第4代白盒测试方法实践之“VcTester插装原理与各种覆盖率配置”
发表于 @ 2007年08月10日 15:22:00
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/wayne_chan/archive/2007/08/10/1736324.aspx
分享到:
相关推荐
在本实验报告中,主要探讨了白盒测试方法,这是一种基于程序内部逻辑结构的测试方法。 【白盒测试】 白盒测试,也称为结构测试或逻辑驱动测试,它侧重于程序的内部逻辑和工作流程。测试者通常需要理解程序的源代码...
- **测试培训:** 依据《软件测试》第四章中的白盒测试理论进行。 #### 七、测试设计说明 **控制程序流程图:** 由于文档中未给出具体的流程图,这里不做详细介绍。但根据文本描述可以推测,流程图应该包括了输入...
* 白盒测试的定义:白盒测试是一种软件测试方法,它关心软件的内部结构和实现细节,以了解软件的内部工作机理。 * 白盒测试的优点:白盒测试可以发现软件的逻辑错误和算法错误,需要了解软件的内部实现细节。 四、...
白盒测试是一种软件测试方法,它通过检查程序的内部结构和执行路径来检测程序的正确性。白盒测试的主要目的是为了确保程序的逻辑正确性和执行结果的正确性。在白盒测试中,测试人员需要详细了解程序的内部结构和执行...
根据提供的文件信息,我们可以了解到该文档是一份关于软件测试的实验报告,涉及了黑盒测试、白盒测试以及系统测试三种不同的测试方法。下面将对这三种测试进行详细的知识点说明。 首先,黑盒测试是软件测试方法之一...
白盒测试是软件测试中的一种测试方法,它从程序的控制结构导出测试用例,以发现软件中的缺陷和错误。本文将详细介绍白盒测试的相关知识点。 白盒测试的目的 白盒测试的主要目的是尽早发现软件中的缺陷,以减少软件...
本资料主要涵盖了软件测试中的两个核心方法:白盒测试和黑盒测试,同时也包含了一些可能的简答题内容,这些都是软件测试期末考试的重点。 一、白盒测试 白盒测试,也称为结构测试或逻辑驱动测试,其主要依据是程序...
白盒测试是一种软件测试技术,它基于程序的源代码,通常也称为基于代码测试(code-based testing)。白盒测试的基本思想是把测试对象的每部分代码至少执行一次,设计面向控制流的测试用例,分析程序的逻辑,然后执行...
【嵌入式软件白盒测试工具】在软件测试领域,白盒测试是一种重要的测试方法,它侧重于代码的内部逻辑和结构。本文将介绍两款常用的嵌入式软件白盒测试工具——VcTester和CodeTest。 **VcTester**是由深圳市领测科技...
软件测试的方法众多,其中黑盒测试和白盒测试是最为常见的两种。在本实验中,我们将通过为一个判断三角形类型的程序设计测试用例,掌握这两种测试技术的核心。 黑盒测试方法不关注程序内部的逻辑结构,而是侧重于...
在软件测试领域,黑盒测试和白盒测试是两种主要的测试方法,它们分别关注不同的角度来确保软件的正确性。 黑盒测试,也称为功能测试,主要关注软件的外部行为,即根据软件的需求和规格说明书,检查软件是否能够正确...
接下来,黑盒测试和白盒测试是两种常见的软件测试方法。黑盒测试关注的是系统的功能,它不考虑内部结构或实现,而是基于系统的行为和输出来设计测试用例。测试人员仅根据需求规格说明书来确定预期结果。而白盒测试...
灰盒测试是介于黑盒测试和白盒测试之间的一种测试策略,它结合了两者的优点,既关注软件的输入输出行为,也考虑到内部状态,但不像白盒测试那样对内部结构进行详尽的探索。 **核心理念**:灰盒测试的目标是提高测试...
白盒测试是一种软件测试技术,它的主要目的是检测软件内部结构和运行机制是否正确无误,并且检测软件是否满足预定的要求和规范。白盒测试可以分为三种境界:单元测试、集成测试和系统测试。 嵌入式软件白盒测试 ...
在软件工程领域,白盒测试是一种重要的质量保证手段,它通过审视代码和软件内部逻辑来确保软件产品的质量和功能正确性。白盒测试流程图1提供了一种视觉化的方法来表示整个测试过程,通过清晰的步骤指导测试人员完成...