TA的每日心情 | 怒 2015-9-10 15:08 |
---|
签到天数: 1 天 连续签到: 1 天 [LV.1]测试小兵
|
综述对软件测试认识的十二大误区
阿七
[摘要]
随着大家对于软件质量的重视程度越来越高,导致了测试在软件开发中的地位越来越重要了。没错,测试是目前用来验证软件是否能够完成所期望功能的最有效的方法之一。在这一趋势的引导下,现在很多软件相关的公司都非常重视对于他们所开发的软件的测试,甚至不惜花费巨资购买商用的测试工具,但是效果却不一定理想。究其原因主要是存在着对于软件测试的诸多误区。本文对一些比较普遍的关于测试的误区进行些剖析,并且就测试对于软件产品质量可能带来的更深远的影响方面,也进行些论述。
[关键字]: 测试 误区 软件质量
引子
测试在软件开发过程中一直都是备受关注的,即使是在传统的软件工程中,也有一个明确、独立的测试阶段。随着软件危机的频频出现以及人们对于软件本质的进一步认识,测试的地位得到了前所未有的提高。测试已经不仅仅局限于软件开发中的一个阶段,它已经开始贯穿于整个软件开发过程,人们已经开始认识到:测试开始的时间越早,测试执行的越频繁,所带来的整个软件开发成本的下降就会越多。
但是,相对于测试这个词的流行程度而言,有关测试教育方面的工作做的还远远不够,很多关于测试的文章都是针对某种测试工具使用方面的,而测试工具厂商也往往出于商业的目的对于测试工具的作用夸大其词。这样,很多的软件从业者就很容易陷入一些误区,导致了测试并没有在他们所在的软件开发项目中起到有效的作用。下面几点将对于一些比较具有代表性的误区进行剖析,并对于测试背后所蕴含的一些设计思考进行了阐述,希望能够起到抛砖引玉的作用。
误区一: 需求-实现-测试,软件测试是开发后期的一个阶段;
实际上,软件测试贯穿整个软件产品生命期。一方面,软件测试也要经历测试计划、测试用例的设计和实现,以及测试运行一系列的阶段,因此,早在软件需求阶段,甚至更早,软件测试的工作就要开始了。另一方面,软件测试越早进行越好,因为BUG越早发现,BUG造成的影响和修改的代价就越小。而且,软件测试并不仅仅针对程序,软件的需求、设计等等也要被测试。
测试是一个 “ 泛型概念 ” (全程测试)。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话,需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷同样也是软件缺陷,而且 “ 软件缺陷具有生育能力 ” 。需求有问题,连带着设计会出问题,最后到测试完成,客户拿到自己不是想要的产品。缺陷不断放大。所以软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验证(自检)也可以算作软件测试(建议称为:需求测试和设计测试)的一种。软件测试应该是一个泛型概念,涵盖整个软件生命周期,这样才能确保周期的每个阶段经得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理),即测试本身也应当被测试,从而确保测试自身的可靠性和高效性。否则自身不正,难以服人。 另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件,软件测试是提高产品质量最直接、最快捷的手段,但决不是一个根本手段。
误区二:软件测试对技术要求不高,至少比编程容易得多。
很多人认为测试就是运行一下软件,然后看看结果对不对就可以了。首先这就是一个对测试缺乏根本的认识。看看结果对不对,可以采取很多方式,白盒测试需要分析代码逻辑来输入特例数据,黑盒测试需要执行常规操作来看反馈是否正确。测试是有目的的发现程序的错误,如果对程序本身不理解,是无法找出程序的不合理的。所以,测试人员不仅知道程序员的代码,还要知道程序员的思维漏洞。
(A) 白盒测试不仅要理顺程序员的思路,还要找出其不合理之处;
(B) 黑盒测试不仅要理解客户的需求,还要找出其暗藏的逻辑不合理性;
(C) 白盒测试相对黑盒测试更具体一些,但正是黑盒测试面对的不确定性、抽象性、逻辑性、变动性、随机性和发散性,从而增加了其自身含金量。
这里要补充的是,软件测试的经验累积也是非常重要的。而且,测试不仅仅只是运行程序,还涉及到测试的管理。而管理能力的扩展,是无限延伸的。
[url=]误区三:使用测试工具,就是进行了有效的测试[/url]
一个软件开发团队往往认为只要自己使用了某种软件测试工具,那么就应该可以获取测试带来的种种好处,这种想法当然是错误的。因为,要想对一个软件或者模块进行有效的测试,首先该软件或者模块应该是可测试的。可测试性是反映软件质量的一个内在属性,不会因为你使用了某种测试工具进行了测试行为,就使得被测试的软件具有了可测试性。如果被测试的软件本身并不具备可测试性,那么使用多么昂贵的测试工具进行测试所能够带来的收益都是微乎其微的。
还好,可测试性和好的软件品质的其他方面有天然的关联,一个具有可测试性的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件,而不可测试的软件往往具有过强的耦合和混乱的逻辑。关于可测试性方面更多的内容不在本文的论述范围,请自行参见相关的文献。
要想真正获取测试带来的巨大好处,并且使得测试工具能够发挥最大的效率,关键就是要使软件本身具有很好的可测试性。这种能力的获取是一个逐步的过程,是不可能一蹴而就的。最关键的一点就是要不断实践,不断学习一些优秀的经验,不断的反思。要想获取好的结果,就必须要付出努力,这是亘古不变的真理。
对于测试工具的选择,只要满足需要并能够自动运行测试用例就可以了。不要一味的追求复杂的功能和不必要的灵活性。目前没有比较好的满足各方面需要通用的测试工具,不过使用脚本语言,循序渐进的自行开发一个适合自己的验收测试工具也不是一件困难的事情,一句话:只有提高了自身团队内在的素质,外在的工具才能够发挥作用。
误区四: 自动化测试是万能的。
自动化测试可以提高效率,但不可能提高质量。业界的80/20法则同样适用于此,即20%的工作量可以完成80%的自动化工作,其余20%的自动化,需要再投入80%的成本。完全相信自动化测试的人,就好像相信机器人能够取代人类一样。 自动化测试存在有以下的缺点:
(1)、不能完全取代手工测试
(2)、手工测试比自动测试发现的缺陷更多
(3)、对测试质量的依赖性极大
(4)、测试自动化不能提高有效性
(5)、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱,所以维护会受到限制,从而制约软件的开发。
(6)、工具本身并无想像力 |
|