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

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

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

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

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

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

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

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

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

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

软件测试团队是整个项目团队大家庭中的成员之一，在软件质量上把关，要尽可能早、尽可能多地发现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较多，而项目又需要短时间把版本稳定下来，通常的做法是加人。然而加入的新兵需要一段时间的熟悉期，必要时还需要老兵来带，这本身又会影响到老兵的工作。另外一些性能测试、自动化测试工作也只有等版本稳定后才会有更好的效果。

下面是一个关于测试时间与重点模块该如何分配的案例。

【案例】

背景：某软件系统包含5个功能模块，分别为模块A、模块B、模块C、模块D、模块E。从客户使用的业务功能出发，模块B是产品必须有的，且是用户使用频率最高的功能模块；模块A，用户使用频率不高，但对数据的正确性要求特别高，存在些许错误，就可能会带来法律法规风险；模块C、D、E主要是为核心业务或为后续产品的维护活动而使用的支撑模块。从需求的复杂度及描述的篇幅来看，模块B的需求虽篇幅不算长（需求点不算多），但比较难于理解，隐含需求较多；模块A的需求描述虽然显得特别简单，只有几句话的要求，但其对软件设计的需求依赖性较大；其他模块由于是业务支撑模块，有些功能是用来支持安装升级及产品的后期维护服务使用的，需求描述很细，内容篇幅较多。

项目的测试经理陈A，并不是不清楚这些模块的用户使用需求，但他是一个完美主义者，在有时间与人力的情况下，总是想把所有模块的Bug尽可能多地找出来，始终坚守质量第一的原则，认为这是测试能给项目带来贡献的核心所在。于是在项目的初期测试人力不紧张的情况下，根据用例须对需求达到100%覆盖的原则，他做了如表2-2所示用例设计工作的安排。

用例设计完成，各模块的用例按流程完成了评审。进入执行阶段后，各模块的测试工程师用自己设计的用例开始测试执行的工作。表2-3所示是一周后各模块发现严重Bug的情况表。

模块中严重等级的Bug越多，表明质量越差，意味着离版本稳定时间越远。据最佳实践表明，一个存在10个以上Bug的模块（只有几百行代码量的小模块除外），如果严重等级的Bug大于等于30%，则表明该模块设计质量堪忧，在质量的关卡上已亮起了红灯。这是设计架构的问题，还是编码本身的错误，或者是其他原因等，需要及时启动原因分析，以拿出合理的解决方案。

从表2-3的数据可看出，模块B的Bug严重性比率已超出警戒线，其他模块看似正常。于是测试经理陈A在接下来的一周时间里，对各模块的人力资源分配进行了局部调整，如表2-4所示。模块A的测试用例已执行完成，测试工程师T1被调整到与测试工程师T2一起测试模块B。由于模块C、D、E用例还余下不少，所以负责相关模块的工程师留下来继续测试未完成的用例。而在第2周时，开发人员对上周提交的Bug有些已解决完成，测试人员在第2周需预留足够时间回归Bug。另外，测试过程中也存在补充或修改用例的工作。

进入测试执行的第3周后，陈A做了一个小结，如表2-5所示。

表中数据表明，除模块B外，其他模块的测试任务看似都可以在第2周结束，甚至负责模块C、D、E的测试工程师的工作量并不很饱满。模块B继续呈现警戒状态，Bug居高不下，当用例执行完成后，就提交Bug开发人员解决，测试人员再次回归，直到所有Bug关闭，预计的时间远远超过其他模块的工作量。在第3周，测试工程师T3、T4、T5已属闲置状态，但如果在第3周后再调入支持模块B的测试，为时已晚，因为用例已执行完成，回归Bug最好由发现Bug的人来回归是最合适的。也就是说，本轮提交测试的5个模块，需要在3周后才能完成测试。

站在项目的角度，上面5个模块的测试在两周内完成也是可以的，一方面从第2周开始从测试模块C、D、E的资源中调入一个加入到测试模块B，同时开发人员解决Bug的人力及速度需紧密配合。

而在实际的工程实践中，情况要复杂得多。比如遇到模块B需重新建构，测试完成的时间需重新评估；已解决的Bug并不一定彻底解决了，可能会重新打开或产生新的Bug，陷入一种拖泥带水的状况；实施几个版本后，项目才会彻底改观等，都是常有的事。

几个月后，项目以延期1个月左右的时间上市了（尽管延期的原因可能不仅仅在软件上），而让陈A万万没想到的是，原来表现最少Bug、最稳定的模块，用户端却反馈回一个关于数据正确性的错位问题（条目A的信息显示在条目B的地方了）。此问题很严重，存在法规风险。回过头来查看，用例确实没有考虑周全，明显对用户真正使用需求理解不足，重视不够。由于此产品的错误信息一旦被使用会涉及人身安全，所以如果用户真打起官司来，公司的损失可就大了。

上面的例子，一方面说明了测试对重点且复杂的模块认识不足，即使是后来出现严重警戒时，只是做了局部调整，致使后期有部分资源浪费，而某些资源却很紧张，最后拖延了项目的研发周期。另一方面是测试对用户的真实使用需求，以及出现问题后所造成的严重后果认识不足，在用例设计上出现遗漏，直接影响了软件的质量。但是，只要我们对测试工作进行科学的思考，不盲目地干活，把测试的2-8原则落实到实处，那么测试执行工作完全可以在提高关键质量目标的同时，为项目的研发降低成本、减少时间，并全面真正支撑起公司商业成功所必需的关键要素——更快的进度、更低的成本、更高的质量。这时，你还会认为“测试的价值仅仅是找Bug吗？”

2.3.2 测试的服务链

2.3.1节介绍了软件测试作为软件专业方向的一股力量在质量、成本、时间的合理控制上能促使项目成功。实际上，一个全新的项目或产品的研发，有一个长长的开发链，如图2-10所示。当跳出“测试仅仅是发现软件Bug”这个圈子时，会看到“山外有山，楼外有楼”，软件只不过是产品的一个子系统。要获得项目的成功，整个体系的各环节需紧密合作，相互支持。软件测试的服务对象虽然重点是软件，但不仅仅是软件，还会涉及机械、硬件，如软件在整机环境下的测试，需要这两个专业方向子系统的支持。反过来，它们有时也需软件给予支持，如协助开发某调试硬件部件的软件，方便相关组件的现场调试。除此之外，软件与工艺设计、生产、市场营销、客户支持也存在一些直接或间接的关系，如市场为了参展，需软件提供参展的特殊版本；用户支持需要软件帮助他们实现简易的安装升级程序等。产品研发链上的各环节，与软件都存在或多或少的关联，测试自然也就需考虑服务于这些特殊用户的需求。

“软件是产品的心脏”。回顾我们身边林林总总的产品，像手机、PDA、数码相机等消费性电子小产品，大一点如笔记本电脑、台式电脑，再大一点的如系统服务器、各式各样的医疗设备、军工产品等，如今哪里都是软件在主宰着。有时，在整机上测试软件时，会遇到测试出来的Bug最后定位不是软件的问题，而是硬件或机械设计的问题。所以软件测试并不仅仅是发现软件的问题，它对整个产品的质量都有不可估量的贡献。