首页 程序猿 软件测试 浏览内容

白盒测试的三种境界之有序状态

1463 0 BaiDu已收录 评论留言

境界之二:有序状态

  一个企业实施过多次单元测试或集成测试,数次成功后进入到有序状态。这个阶段尽管个别项目的白盒活动不成功,但多数项目稍见成效,也有个别项目效果显著。此时,企业内会有特定的组织负责推动白盒测试白盒测试过程也逐渐融入研发流程,典型的例如:将白盒测试发现的问题纳入统计,研发过程中会以缺陷密度(每千行代码发现多少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天才能测完,这种测试是很难维持的。
从有序前期阶段过渡到有序后期阶段,如何看待测试代码也有很大变化,在前期,开发是开发,测试是测试,测试操作连同测试代码是附加的,可选的,到有序后期阶段,大家会把测试代码也看成一种产品代码,是必需的,也自然而然纳入产品维护。

标签:
墨月的头像
  • 本文由墨月网络整理编辑,转载请以链接形式注明本文地址:https://www.moyoo.net/10891.html
    版权所有© 墨月网络 | 本文采用 BY-NC-SA 进行授权丨发布于:2014-09-16 19:54
    若未注明,均为原创;部分内容源于网络,版权归原作者所有,如有侵权,请联系我们删除。
评论头像

关注我们,实时联系

AD

注册即送25美刀

Vultr

推广

Vultr

赞助商

广而告之

alimama