测试的三重境界

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

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

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

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

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

“昨夜西风凋碧树，独上高楼，望尽天涯路”。

“衣带渐宽终不悔，为伊消得人憔悴”。

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

细细思量，感受它们之间亦有殊途同归之处。

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

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

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

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

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

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

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

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

一提到测试，你们立刻会想到Bug。测试仅仅就是为了发现Bug吗？这是值得咱们思考的问题。

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

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

二、一个成功的测试就是发现了至今为止还没有发现的Bug的测试。

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

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

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

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

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

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

小贴士：

一、作正确的事与正确地作事

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

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

对于测试，作正确的事就是站在用户的角度，进行经常使用功能（模块） 重点测试，而避免很是用功能的过分测试，浪费成本，包括人力与时间的投入。正确地作事，就是采用合理、全面的测试方法验证软件是否符合用户需求，不想固然 地经过用户根本不可能用到的非法操做或后门进行验证。下面讲述关于软件测试的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的手段来控制吗？

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

一、缺陷的防与堵

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

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

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

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

二、缺陷的防堵

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

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

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