测试的三重境界

测试的第一重境界&＃xff1a;围着Bug转

“意 识决定行动&＃xff0c;行动决定结果”是管理学中众所周知的名言。做测试的前几年&＃xff0c;笔者并没有这个意识&＃xff0c;也没有主动地去思考过这个问题&＃xff0c;但随着一个个项目任务、一桩 桩事件的历练&＃xff0c;慢慢感悟到这句话也适合对测试工作境界的理解。“心态决定命运”&＃xff0c;“态度决定一切”&＃xff0c;有很多名家学者都写过这方面的书籍&＃xff0c;基本上已成了我们 不可否认的真理了&＃xff0c;但是要真正应用在自己的工作生活中&＃xff0c;恐怕就不那么简单了。诚然&＃xff0c;测试工作&＃xff0c;除了需要拥有过硬的测试技术外&＃xff0c;还必须有正确的测试心态&＃xff0c;也 正是这些心态意识左右着你的日常工作。不同的心态反映了不同的测试境界高度&＃xff0c;最终体现出不同的结果。

围着Bug转&＃xff0c;是测试三重境界中的第一重。概括起来&＃xff0c;它又可以分为三个阶段&＃xff0c;第一&＃xff0c;发现Bug&＃xff1b;第二&＃xff0c;定位Bug&＃xff1b;第三&＃xff0c;关闭Bug。这三个阶段对测试人员 的要求不仅在技术上需要逐层递进&＃xff0c;在综合素质上也提出更高的要求。三个阶段之间环环相扣。直到Bug的生命周期结束。围着Bug转的三个阶段对测试人员的 要求及Bug被发现到关闭的生命周期示意图。如图2-1所示。

图2-1 围着Bug转的三个进阶图

谈到围着Bug转的的三个阶段&＃xff0c;不禁想起中国近代著名学者王国维在《人间词话》中提到的人生的三重境界&＃xff1a;

“昨夜西风凋碧树&＃xff0c;独上高楼&＃xff0c;望尽天涯路”。

“衣带渐宽终不悔&＃xff0c;为伊消得人憔悴”。

“众里寻他千百度&＃xff0c;蓦然回首&＃xff0c;那人却在灯火阑珊处”。

细细思量&＃xff0c;感觉它们之间亦有异曲同工之处。

第一重“昨夜西风凋碧树&＃xff0c;独 上高楼&＃xff0c;望尽天涯路”是说“古今之成大事业、大学问者&＃xff0c;首先要树立明确的目标&＃xff0c;即使长路漫漫&＃xff0c;也下定决心将这条长路走下去。这是一个人在孤独之中寻找理 想、寻找生命的落脚点的痛苦时刻”。围着Bug转的第一阶“发现Bug”&＃xff0c;同样首先必须有明确清晰的目标&＃xff0c;找Bug的过程是漫长的&＃xff0c;反反复复、枯燥无味是 工作的特点&＃xff0c;但是为了达到目标“长路再漫漫&＃xff0c;也得坚持走下去”&＃xff0c;直到找到一堆堆的Bug。特别是对一些偶现的严重Bug&＃xff0c;重现Bug的过程真如大海捞针&＃xff0c; 但是坚持就是胜利。笔者曾经在经历的一个项目中&＃xff0c;花了近1个月的时间去重现与解决一个严重问题&＃xff0c;最后在与开发人员的紧密合作下&＃xff0c;终于找到问题的根源。

第二重“衣带渐宽终不悔&＃xff0c;为 伊消得人憔悴”是说“执着的追求、忘我的奋斗&＃xff0c;直至憔悴消瘦&＃xff0c;连衣服都变得宽大&＃xff0c;这一切努力都是为了心中的梦想”。对应软测中围着Bug转的第二阶“定位 Bug”。 这一阶段不仅在技术上提出了更高的要求&＃xff0c;还要有刻苦钻研、穷追到底、不撞南墙不回头的执著精神&＃xff0c;直到把问题的原因搞清楚才罢休。在国内目前的测试领域&＃xff0c;大 部分公司这一步并没有要求测试人员来做&＃xff0c;但是在国外&＃xff0c;特别是一些知名的大公司&＃xff0c;如在微软&＃xff0c;几乎所有的测试人员都拥有深入调试程序的技能。它除了包含以最短 路径重现问题&＃xff0c;还要分析问题的可能结果&＃xff08;例如分析Bug会影响到哪些模块&＃xff09;&＃xff0c;甚至给开发人员提出解决方案。显然&＃xff0c;这一步要求测试人员要比开发人员具有更高 的设计分析能力、代码调试能力、解决问题的能力。读者朋友&＃xff0c;看到这里&＃xff0c;对一些测试专业网上常看到的“测试人员是否要懂编程”这一问题已释然于怀了吧。

第三重“众里寻他千百度&＃xff0c;蓦 然回首&＃xff0c;那人却在灯火阑珊处”。这一阶段是指经过不断磨炼&＃xff0c;多次的失败&＃xff0c;某一时刻忽然灵犀一点&＃xff0c;领悟真谛&＃xff0c;发现自己想要的东西原来就在自己的身边或领悟后 的心里。在旁人看来&＃xff0c;他的“蓦然回首”是如何偶然而幸运&＃xff0c;但其背后的用功之勤、平时的积累之深&＃xff0c;又岂是常人所能坚持&＃xff0c;所能想象的呢&＃xff1f;这时候&＃xff0c;世俗目标是否 已经达到已不再重要&＃xff0c;重要的是灵魂的解放和心灵的归属。对应围着Bug转的第三阶“关闭Bug”&＃xff0c;如果仅从字面理解&＃xff0c;很简单&＃xff0c;不就是开发解决了Bug&＃xff0c;回 归Bug&＃xff0c;然后把Bug关闭。如果是这样&＃xff0c;笔者认为这种观念仍属于第一阶。第三阶的关闭Bug&＃xff0c;是指测试人员提交一个Bug后&＃xff0c;要有主动意识推动开发人员 解决问题&＃xff0c;并协助他们解决&＃xff0c;只有问题解决了&＃xff0c;软件的质量才得以提高&＃xff0c;测试人员的最终目的才能达到。提交的有些问题严格来说&＃xff0c;它不属于Bug&＃xff0c; 而是一种设计缺陷&＃xff0c;此时测试人员该怎么办呢&＃xff1f;需主动召集相关专家进行其影响面的风险分析&＃xff0c;并跟进此问题的整个解决过程&＃xff0c;如果风险点涉及其他专业的更改&＃xff08;如 嵌入式软件涉及硬件、机械等方面的知识&＃xff09;&＃xff0c;可能需要专门成立一个专项问题解决团队&＃xff0c;以全面解决此问题&＃xff0c;直到各专业方向的问题解决到位&＃xff0c;回归验证完成&＃xff0c;此 Bug方能关闭。站在Bug的生命周期角度分析&＃xff0c;一个Bug由被发现的起点&＃xff0c;走到被关闭的终点&＃xff0c;才是一个合理的、完整的过程&＃xff0c;如图2-2所示。但是要达到 这一层&＃xff0c;很可能有一大部分的工作已完全脱离了纯软件测试层面的工作&＃xff0c;可是测试的最终目标不就是给用户一个高质量、信得过的产品吗&＃xff1f;我们需要有这样的大气胸 怀&＃xff0c;才能把产品的测试工作做得更深远、更宽阔。

接下来结合案例对围着Bug转的三个阶段分别进行介绍。

图2-2 Bug 生命周期曲线闭环图

测试的第二重境界&＃xff1a;站在Bug之上

测试的价值仅仅是发现Bug吗&＃xff1f;通过“站在Bug之上”测试第二重境界的介绍&＃xff0c;希望能帮助读者正确理解测试的真正价值是什么&＃xff0c;在实际工作中如何操作以体现 这些价值。不同的理念&＃xff0c;将会牵引着测试人员朝不同的方向迈进&＃xff0c;“站在Bug之上”可以拓宽测试人员的视野&＃xff0c;找到更多可以充分体现测试价值的测试链&＃xff0c;让测试 人员为项目的成功做出更大的贡献&＃xff0c;从而带来更宽范围的测试成功。

测试的价值不仅仅是发现Bug

一提到测试&＃xff0c;大家马上会想到Bug。测试仅仅就是为了发现Bug吗&＃xff1f;这是值得我们思考的问题。

从软件测试最基本的定义出发&＃xff0c;早在1979年J. Myers在《软件测试的艺术》一书中提到&＃xff1a;

1、软件测试的目的就是尽早发现Bug。

2、一个成功的测试就是发现了至今为止尚未发现的Bug的测试。

总之&＃xff0c;测试就是为了发现Bug&＃xff0c;测试所做的工作无一不是围绕Bug而展开&＃xff0c;如图2-8所示。测试发现Bug越多&＃xff0c;测试人员越自豪&＃xff0c;越有成就感&＃xff0c;这个观点已几乎根深蒂固地扎在了我们的心里&＃xff0c;测试除了发现Bug真没其他事情可做吗&＃xff1f;

图2-3已发现Bug为核心的测试机制

发现了很多Bug&＃xff0c;测试人员高兴了&＃xff0c;但老板肯定是不高兴的。很明显的道理&＃xff0c;为了解决这些Bug&＃xff0c;他必须付出更多的成本&＃xff0c;包括开发人员与测试人员的工资&＃xff0c;更 严重的还可能影响产品交付市场的时间。商场如战场&＃xff0c;时间就是金钱&＃xff0c;时间能给产品带来更多的市场空间&＃xff0c;为企业赢得更多的利润。理解这些商业知识能帮助我们做 正确的事&＃xff0c;并且正确地做事。认识到这一点后&＃xff0c;相信测试朋友就不会再为某个Bug还没有解决&＃xff0c;版本却上市而耿耿于怀了。测试人员应该跳出仅发现Bug就沾沾 自喜的圈子&＃xff0c;看到项目整体&＃xff0c;站在公司的角度想测试可以做什么。只有项目成功了&＃xff0c;公司才能获得利润&＃xff0c;最终达到员工与公司双赢的目标。

质量、成本、时间是项目管理的三要素。它们像三足鼎立&＃xff0c;稳如泰山&＃xff0c;即质量好、成本低、工期短&＃xff0c;这样的项目当然是项目经理求之不得的。但它们又是矛盾地存在 着&＃xff0c;形象地看&＃xff0c;它们犹如一个等边三角形&＃xff0c;如图2-4所示。对其中的任何一个元素处理不当&＃xff0c;三元素的三角关系就会变得不稳定&＃xff0c;将给项目的成功带来风险。

图2-4 测试与项目管理要素关系图

软件测试团队是整个项目团队大家庭中的成员之一&＃xff0c;在软件质量上把关&＃xff0c;要尽可能早、尽可能多地发现Bug。这也是软件测试成立的根本&＃xff0c;是质量上能给项目做出 贡献的地方。那么在成本与时间的控制上&＃xff0c;测试可以做些什么&＃xff0c;要如何做呢&＃xff1f;也就是前面提到的测试如何配合项目的成功做正确的事&＃xff0c;并且正确地做事。

小贴士&＃xff1a;

1、做正确的事与正确地做事

2、做正确的事出发点是企业利益最大化&＃xff0c;而不是站在个人和小团体的立场去做事&＃xff0c;也不是怕承担责任&＃xff0c;把事推给别人。要求我们在众多的可能性中选择&＃xff0c;辨别出什么是正确的&＃xff0c;什么是最直接、最可行的做事方式和方法&＃xff0c;把企业效益最大化作为办事的标准。

3、正确地做事&＃xff0c;是驱动具体做事的人员如何按照领导的意见去做事&＃xff0c;而不去考虑是否符合企业效益最大化的原则。

对于测试&＃xff0c;做正确的事就是站在用户的角度&＃xff0c;进行常用功能&＃xff08;模块&＃xff09; 重点测试&＃xff0c;而避免非常用功能的过度测试&＃xff0c;浪费成本&＃xff0c;包括人力与时间的投入。正确地做事&＃xff0c;就是采用合理、全面的测试方法验证软件是否符合用户需求&＃xff0c;不想当然 地通过用户根本不可能用到的非法操作或后门进行验证。下面讲述关于软件测试的2-8原则&＃xff0c;通过此2-8原则&＃xff0c;可以使软件测试在项目的成本与时间的应用上做 到效益最大化。

举个大家在日常生活中常遇到的例子&＃xff0c;如经常看到广告上说&＃xff0c;现在的手机软件的功能如何强大&＃xff0c;如何丰富&＃xff0c;但每一功能用户使用的频度都一样吗&＃xff1f;回答是否定的。这 就有了在软件测试范围侧重点上存在的2-8原则&＃xff0c;即要把80%的精力放在测试20%的重点功能上。从用户角度出发&＃xff0c;这是值得的&＃xff0c;也是需要这样做的。

首先&＃xff0c;分析在我们的软件系统中&＃xff0c;哪些功能对用户来说是核心且重要的功能&＃xff0c;然后安排合适的测试工程师负责这些模块。设计出的测试方案、用例进行重点评审&＃xff0c;测 试执行过程重点跟踪。每一次软件版本发布时&＃xff0c;即使没有更改此部分的代码&＃xff0c;也对它们进行回归测试&＃xff08;这种回归需讲究策略与方法&＃xff09;&＃xff0c;因为它们太重要了&＃xff0c;不允许有错误。

下面是软件测试2-8原则的详细内容。

1&＃xff0e;80%的错误是由20%的模块引起的

简单、容易的模块或功能是很少引入过多Bug的&＃xff0c;而对于存在复杂逻辑的一些关键模块往往会引起系统80%的错误。只有关键模块稳定了&＃xff0c;整个系统才可能真正的健壮和稳定。

这个原则对于测试来说就是站在用户角度&＃xff08;而不是研发实现的角度&＃xff09;&＃xff0c;正确地选择重要功能模块作为测试的重点&＃xff0c;不偏离方向。

2&＃xff0e;80%的测试成本花在20%的软件模块中

设计测试用例时&＃xff0c;常会用日产多少条用例来衡量工程师的工作。用例的多少与需求量有关&＃xff0c;而影响软件架构设计的需求描述往往是比较少的。在这种情况下&＃xff0c;设计测 试用例时特别需要结合软件的概要设计、详细设计一起考虑。如果用例设计人员为了达到用例的数量&＃xff0c;通过大量复制用例&＃xff0c;修改个别字眼&＃xff0c;而没有真正去设计高效的 测试用例&＃xff0c;那么用如此低效甚至更多的用例数量来对待复杂的20%的核心模块&＃xff0c;在测试执行过程中必将导致一部分关键Bug找不出来。

3&＃xff0e;80%的测试时间花在20%的软件模块中

对于复杂的模块&＃xff0c;前期的测试设计和思考可能会耗费大量时间&＃xff0c;而产出的用例量可能并不大。对于复杂的系统&＃xff0c;特别是对于全新系统&＃xff0c;必须舍得投入充足的时间来优先考虑设计&＃xff0c;前期方案、用例设计的时间越短&＃xff0c;后期的风险越大。

在项目进展到一定阶段后&＃xff0c;增加人力并不一定能解决缩短时间的问题。例如&＃xff0c;如果复杂且核心模块在项目的后期才开始执行测试&＃xff0c;由于Bug较多&＃xff0c;而项目又需要短 时间把版本稳定下来&＃xff0c;通常的做法是加人。然而加入的新兵需要一段时间的熟悉期&＃xff0c;必要时还需要老兵来带&＃xff0c;这本身又会影响到老兵的工作。另外一些性能测试、自动化测试工作也只有等版本稳定后才会有更好的效果。

测试的第三重境界&＃xff1a;挑战零缺陷

孔子说“人无远虑&＃xff0c;必有近忧”&＃xff0c;用在软件测试上&＃xff0c;是什么意思呢&＃xff1f; 可以这样理解&＃xff0c;如果我们不从发生问题的根源上解决问题&＃xff0c;认为测试仅仅是找Bug&＃xff0c;千方百计找Bug&＃xff0c;觉得Bug总是找不完&＃xff0c;意识中就会陷入“永无天日”的 状态。然而&＃xff0c;有小部分测试人员还真希望软件存在多一些问题&＃xff08;唯恐天下不乱&＃xff09;&＃xff0c;这样可以多提交Bug&＃xff0c;认为业绩比没有提交多少Bug肯定要好。无独有偶&＃xff0c;有 小部分开发人员也把自己犯下的程序错误视为理所当然&＃xff0c;甚至还有个别人会戏虐地说“软件如果没有Bug的话&＃xff0c;测试人员不就失业了”。这好像在唱一出双簧戏。 软件开发的整个过程中&＃xff0c;Bug是理所当然要存在的&＃xff0c;是这样吗&＃xff1f;软件工程中软件危机的根源问题只能通过找到Bug的手段来控制吗&＃xff1f;

实际上&＃xff0c;我们都很清楚&＃xff0c;任何一个Bug的产生都是有来源的&＃xff0c;来源 包括需求的设计、软件的设计&＃xff08;含代码的编写&＃xff09;等。相对于前端的设计&＃xff0c;测试是事后的验证&＃xff0c;是一种“堵”漏洞的措施。然而&＃xff0c;在实际工作中&＃xff0c;时间与成本并不允许 我们去堵住所有的Bug。日本质量大师田口玄一说得好“质量是设计出来的&＃xff0c;而不是测试出来的”。如果我们能变被动为主动&＃xff0c;在设计之前&＃xff0c;就做好设计的防患措 施&＃xff0c;为设计高质量的软件打下坚实的基础&＃xff0c;这便是本节打算向读者介绍的测试的第三重境界&＃xff1a;挑战零缺陷。

1、缺陷的防与堵

几乎在每次面试测试工程师时&＃xff0c;笔者都会问一个这样的问题&＃xff1a;“你所负责测试过的模块&＃xff0c;是否存在漏测的情况”&＃xff0c;几乎每个应聘者都回答说“有”。面对复杂的软件&＃xff0c;纷繁复杂的运行环境&＃xff0c;在有限时间内进行的测试活动&＃xff0c;做到真正的零Bug是 不可能的&＃xff0c;也是不现实的。但这些都不是理由&＃xff0c;所有的测试活动是有目的的商业活动&＃xff0c;每个公司有自己测试通过的一套标准或原则。虽然漏测不可避免&＃xff0c;但并不是说 漏测是一种正常现象或应该的现象&＃xff0c;出现的漏测问题如果超出公司所能接受的原则&＃xff0c;就属于不正常的现象&＃xff0c;很有必要进行漏测分析。进行漏测分析活动&＃xff08;需要特别注 意的是它绝不是对漏测人员的批斗会&＃xff09;&＃xff0c;它的主要目的是通过分析过去的教训&＃xff0c;找出问题的根源&＃xff0c;分析测试中哪个环节工作存在缺失&＃xff0c;以拿出规避的可操作的措施出来。

测试人员进行漏测分析时&＃xff0c;免不了对问题进行追本溯源。软件是由开 发人员设计出来的&＃xff0c;所以漏测分析活动少不了开发人员在场&＃xff0c;甚至有时还会涉及需求设计人员。关于漏测分析的追本溯源&＃xff0c;这里有一个关于开发与测试之间的工作关 系像修筑堤坝一样的有趣比喻&＃xff0c;如图2?11所示。开发人员设计软件就像修筑一道堤坝&＃xff0c;如果堤坝在结构上存在问题&＃xff0c;当洪水冲击时&＃xff0c;可能不只是局部的泄漏&＃xff0c;而 是直接的决堤&＃xff0c;犹如软件的崩溃。高高的堤坝&＃xff0c;难免会存在漏水的小洞&＃xff0c;或渗水的小孔&＃xff0c;就好像软件中存在的小Bug。越是在堤坝基部的漏水或渗水问题越难发 现&＃xff0c;解决的代价也越大。

在设计时要把结构建牢&＃xff0c;不存在漏洞当然更好&＃xff0c;这是一种防范。如果超越防范界线&＃xff0c;把设计带出的大洞小孔遗留到测试环节&＃xff0c;它只好拿着各种放大镜&＃xff08;使用各种方法&＃xff09;来检测&＃xff0c;以网罗各种深深浅浅、大大小小的问题&＃xff0c;最后通过“打补丁”的方式&＃xff0c;堵住堤坝上的“百孔千疮”。

图2-5缺陷的防堵与堤坝的防堵形象理解示意图

2、缺陷的防堵

在对缺陷的防与堵方面&＃xff0c;测试是发现问题的中间角色&＃xff0c;告诉开发人员 哪里漏水或渗水了。防与堵的工作是由建堤者来做的。当然&＃xff0c;防是主动的&＃xff0c;堵是被动的&＃xff0c;主动变为被动后&＃xff0c;中间经历了资源与时间的投入&＃xff0c;诚然即使是同一个 Bug&＃xff0c;它们的代价也是完全不一样的。这种堵越在后面&＃xff0c;影响越大&＃xff0c;代价也就越大&＃xff0c;如图2-6所示&＃xff08;摘自《代码大全》&＃xff09;是一个根据缺陷出现的阶段来增加测试 成本的例子。

图2-6 根据缺陷的引入和检测时间&＃xff0c;修正同一缺陷所需的平均成本

如上图2-6所示为在需求阶段引入的一个缺陷。如果立即发现了此 问题&＃xff0c;修改成本只需要1美元&＃xff0c;但如果在系统测试阶段发现它&＃xff0c;修改成本就增加了10倍。更为严重的是&＃xff0c;如果在版本发布后用户端发现了此问题&＃xff0c;则需付出10倍 以上甚至是100倍的代价。缺陷在系统中的时间越长&＃xff0c;解决它的代价就越大&＃xff0c;因为时间越长&＃xff0c;开发与测试人员修改的成本就越高&＃xff0c;还将影响大面积的用户端升级。