做软件测试工作的三重境界

测试的第一重境界：围着Bug转 “意 识决定行动，行动决定结果”是管理学中众所周知的名言。

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

测试人员 的要求不仅在技术上需要逐层递进，在综合素质上也提出更高的要求。三个阶段之间环环相扣。直到Bug的生命周期结束。围着Bug转的三个阶段对测试人员的 要求及Bug被发现到关闭的生命周期示意图。如图2-1所示。

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

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

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

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

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

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

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

小贴士：

测试方法验证软件是否符合用户需求，不想当然地通过用户根本不可能用到的非法操作或后门进行验证。下面讲述关于软件测试的2-8原则，通过此2-8原则，可以使软件测试在项目的成本与时间的应用上做到效益最大化。

工程师负责这些模块。设计出的测试方案、用例进行重点评审，测 试执行过程重点跟踪。每一次软件版本发布时，即使没有更改此部分的代码，也对它们进行回归测试（这种回归需讲究策略与方法），因为它们太重要了，不允许有错误。

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

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

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

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

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

性能测试、自动化测试工作也只有等版本稳定后才会有更好的效果。

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

1、缺陷的防与堵

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

2、缺陷的防堵

系统测试阶段发现它，修改成本就增加了10倍。更为严重的是，如果在版本发布后用户端发现了此问题，则需付出10倍以上甚至是100倍的代价。缺陷在系统中的时间越长，解决它的代价就越大，因为时间越长，开发与测试人员修改的成本就越高，还将影响大面积的用户端升级。

原文转自：http://www.uml.org.cn/Test/201306184.asp

来源：Alan_Wdd