软件测试的三重境界

测试的第一重境界：围着Bug转

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

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

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

测试的第二重境界：站在Bug之上

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

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

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

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

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

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

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

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

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

小贴士：

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

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

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

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

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

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

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

1．80%的错误是由20%的模块引起的

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

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

2．80%的测试成本花在20%的软件模块中

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

3．80%的测试时间花在20%的软件模块中

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

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

测试的第三重境界：挑战零缺陷

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

1、缺陷的防与堵

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

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

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

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