测试之美

那么测试人员到底是什么样的人呢？如果只列举少量的关键特质，那么首要的一点是 测试人员有好奇心。他们想弄清楚事物是怎么运行的；其次，他们喜欢动手实验，他 们想知道尝试使用功能演示时不同的用户场景和实验会发生什么；再次，好的测试人员 胆子比较大，他们不害怕会破坏什么东西，不管你有多位高权重，他们也不害怕把发现 的事实告诉你，他们更不害怕站出来据理力争，一定要把他们相信可能影响到产品成功 的问题解决掉。测试人员聪明，善于分析，善于学习。事实上，他们总是在学习，他们 的工作性质要求如此。技术总是在变化，他们接到的每个项目或多或少跟上一个项目不 太一样。有时候他们有很好的文档，有时候没有很好的文档，有时候甚至没有成文的文 档。他们必须问出正确的问题，研究正确的问题，把谜题的各个碎片联系在一起，然后 得出正确的结论。测试人员一般不关心办公室政治，如果你发现一个测试人员特别精通 此道，很有可能他的本职工作做得不是非常出色。当你的工作是发现和报告问题，要想 玩好政治游戏是很困难的。经常有人责备测试人员过于直接、粗鲁、团队合作精神不佳 等。其实不然，很有可能责备他们的人不了解或者没能意识到项目组中测试人员的角 色，他们的工作不允许他们隐瞒任何“不方便说”的信息。

上述这些是测试人员好的特质，还有其他一些不那么好的特质，但也是大部分测试人员 整体个性中不可分割的一部分，尤其对那些测试经验丰富的人来说。测试人员容易不信 任人，这是从实践经历中学来的，别人总是告诉他们模块X不需要测试，或代码Y“没 动过”，这种信息错的次数多到数也数不清了。所以就算你告诉测试人员草是绿的他们 也要亲自过目才敢相信。测试人员是挑剔的，这个习惯也贯穿在他们生活的其他方面。 他们的任务就是要发现和报告问题，这就是说如果你发给他们的电子邮件里有一个拼写 错误，他们整个团队都会跳出来好心指出，甚至还有你（或者其他人）的其他错误。测 试人员质疑一切，包括权威。一般来说想要用搞定其他部门的办公室政治手腕来欺骗或 者算计测试部门可不容易，倒是告诉他们严酷的真相要来得好得多，这是唯一赢得他们 尊重和信任的方法。

只懂执行其他人测试想法的人，不能算是一个真正意义上的测试人员。当一个测试人员 需要运行一大堆已有的测试用例时，容易心生厌烦，可能会尽快运行这些测试，只是想 让它们从眼前消失。这意味着他们可能不会非常关注这些测试，当然也就不能像认真彻 底的执行者一样找出某些问题。从好的另一方面来看，一个“真正的”测试人员一定会 把这些已有测试看作自己的职责范围，重新考虑其中的想法，提出问题，充实和改变测 试，探究原来的分析没有考虑到的地方。如果原来的分析实在很棒，那可能他们也找不 出来太多可以更新充实的内容，进而增加了无聊指数。你会发现，如果每天的工作就是 按部就班，如运行一大堆已有的手工测试用例，日复一日，那些真正富有创造力、勤勉 的、聪明的测试人员的精气神儿、自主性和创造力都会消磨殆尽。为了你的测试人员士 气着想，无疑需要让他们把手头工作交给愿意每天按部就班做事的人，或把手工测试自 动化，或者不要让他们再做这些事情。他们想做点新的事情，想发现和报告缺陷，想贡 献其他人无法贡献的力量。

你可能不清楚究竟有谁在乎这些表面错误，但是在IT领域工作过一段时间的人可以告诉 你，某个应用程序的最终用户可能会对你觉得微不足道的问题深切关注，也许这跟称为 “烦恼因素”的东西有点关系。当然，字段的标题或仅供参阅的文本里的拼写错误可能 当时并不会让人太不爽，项目组的所有人也都同意其严重级别大致跟一点小污垢相当。 但是对于每天要看两千遍的用户来说，“烦恼因素”是非常高的。项目组经常不能理解 一个从功能上来看很小的问题为什么会是最终用户的大难题。让我们来看一个导航的例 子——在屏幕上做简单的切换标签页的动作，如果现在完成一个功能要比以前多花25% 的时间，或要多敲三下键盘，你可能就会触及最终用户的利益。他们的工作、奖金或工 这对你有好处吗 15 作组的成果有可能是他们评估流程中参考的一种标准。如果你的改动让他们的成果减少 了，他们当然有理由认为这个问题是紧急的。

。测试人员的工作是寻找、发现、报告，而不 是用像神一样的能力去评判，测试人员应该随心所欲地提供他们的专业意见；事实上， 项目组的所有人都应该随心所欲地提供专业意见。不过，最终需要权衡对用户影响的 人，还是用户自己。对于产品是否达到发布标准的争执意见，需要上升到公司管理层， 管理层的一部分工作就是为公司评估风险、做出重大决策。如此说来，测试人员就应该 是（通常实际也是如此）偏向于改掉缺陷的。

幸运的是，开发实验室利用虚拟技术构建了基于不同平台的测试镜像。有了虚拟技术， 时间和步骤也是“可复制”的。由于测试环境必须支持多平台，使用自动化方式搭建第一 个测试平台的时间是不可节省的；但是，第二个、第三个测试环境的搭建时间确实可以节 省。奥秘就在于虚拟技术。成功搭建一套测试环境后，就可以把这个环境保存成镜像 （Image）。以后任何时间需要再使用这套环境，不必重新安装，仅需要把镜像恢复，并替 换必要的机器信息即可。虚拟技术被多个平台支持，包括 AIX、Windows、UNIX/Linux。 用于恢复镜像的硬件环境既可以是实际存在的，也可以是虚拟的。

中间件（Middleware）是提供系统软件和应用软件之间连接的软件，以便于各种部件 之间的沟通，特别是应用软件对于系统软件的集中的逻辑。中间件技术在现代信息技术应 用框架，如 Web 服务（Web Service）、面向服务的体系结构（Service Oriented Architecture， SOA）等应用中应用得比较广泛。中间件不提供具体的功能，但它却是系统中各个部件有 机连接的桥梁。中间件可以提供对外围服务器，包括数据库服务器、应用服务器、Web 服 务器等的支持和管理。中间件技术建立在对应用软件部分常用功能的抽象上，将常用且重 要的过程调用、分布式组件、消息队列、事务、安全、连接器、商业流程、网络并发、HTTP 服务器、Web 服务等功能集于一身或者分别在不同品牌的不同产品中分别完成。

代码覆盖率测试是检验代码是否满足指定覆盖率的测试。例如，可以设计一个测试， 通过改变输入条件，使程序中所有代码行都被执行至少一次，并检验输出是否符合预期。 覆盖率测试在一般条件下，最大限度地覆盖代码，评估代码的整体质量。缺陷注入关注代 码在错误和临界条件的表现。错误和临界条件在所有输入条件中只占小部分，但这部分输 入却非常关键，而且存在问题的可能性较大。测试涵盖了错误和临界条件，就能保证代码 的健壮性。健壮的程序不仅能处理期望的输入，对于“不速之客”，同样能够从容应对。

在软件开发的前期甚至是设计阶段，某些缺陷可能已经存在，然而在这个时期要发现 问题并不是件容易的事情。原因是多方面的。首先，在系统的很多功能模块尚未开发完善 时，由于相互依赖关系而引起的缺陷一般难以被发现，因为缺陷只有在系统进行了集成以 后才会真正暴露出来。例如，有些模式在简单的系统架构下可以带来不错的开发效率和运 行效率，但是随着新模块的加入，这种架构的集成复杂度会急剧提高，系统原有的“精简” 优势在这种条件下不复存在，新模块的运行效率会受到明显影响。这是个很明显的缺陷， 但是这种设计的缺陷在新模块加入以前不可能很容易地暴露。其次，有些缺陷在开发前期 看起来也许算不上是个缺陷，测试人员很容易忽略或仅仅把它当做一个“事件”。这种问 题的严重性随着开发的深入才会逐渐显现。一个典型的例子是数据库查询的效率问题。使 用全表扫描（Table Scan）可以获取完整的数据集合，全表扫描的效率缺陷在开发初期常 常不容易被察觉，随着越来越多的数据和查询的加入，全表扫描的问题才会变得越加明显。 另外，在开发周期的前期，项目人员通常会把注意力放在开发新功能上，在测试方面投入 的资源相对较少，因此发现问题的可能性也降低了。

缺陷（Bug），一般是指系统存在的问题或者需要加强的细节。从广义的角度而言，系 统中任何需要修改或强化的任务都可以归类为缺陷。发现缺陷的人员在系统中创建一个新 的缺陷，对于这个缺陷而言，创建的人是缺陷的创始人（Originator）。创始人会明确说明 缺陷的内容，包括测试的时间、环境、测步和问题的描述、建议等。缺陷创建后，它处于 开启（Open）状态，在任何时候它都会有一个直接的负责人（Owner），负责人是必须对 缺陷采取行动的那个人。负责人的义务是推动缺陷的解决。初始化的时候，系统会根据一 定的规则指定缺陷的负责人，创始人或者被指定的负责人可以重新指定（Assign）更适合 解决该缺陷的人员为新的负责人。 针对一个开启状态的缺陷，首要的任务是验证其有效性，因为在不少情况下，缺陷对 应的问题是由于不符合规定的操作导致的。遇到这种缺陷时，负责人仅需要把缺陷退回 （Return）给创始人。如果缺陷被返回，创始人可以再次确认缺陷是否合法，假如缺陷确实 合法，则可以重新开启（Reopen）缺陷，使缺陷回到开启状态；如果证实缺陷仅是不符合 规定的操作引起的问题，则可以把它取消（Cancel）。取消状态是缺陷生命周期的其中一 种终结状态。如果负责人经过验证后证实了缺陷的有效性，那么下一步的工作就是谋求解 决方法。开始考虑解决方案前，需要接受（Accept）这个缺陷，使缺陷的状态从开启转成 工作中（Working）。 1 此处使用的缺陷管理模型覆盖了典型的缺陷生命周期状态，根据项目差异不排除其他衍生状态。 第 1 章 上班第一天，新人培训  23  在工作中状态下，缺陷的负责人可以与测试人员（缺陷创始人）及相关人员一同讨论 问题的原因和解决办法，并根据方案对文档或系统进行修改。修改完成以后，负责人需要 把缺陷的状态改为验证（Verify）状态，并创建一个验证记录（Verification Record）供缺 陷创始人验证。这时缺陷的创始人同时也是负责人。如果验证通过，问题已经解决，则缺 陷创始人可以认可（Accept）这个解决方案，这时缺陷的状态会变成认可（Accept）。系统 可以关闭（Close）处于认可状态的缺陷。

如果抛开测试的具体技术和实现细节，只是关注测试的目的，那么测试的本质其实就 是发现问题和解决问题的过程。在讲述问题分析的方法时，我们介绍过自顶向下和自底向 上的方法。作为对一般性问题的分析方法，这两种方法都有助于问题的分析。但对于一些 非常规性的问题，这种系统的方法却不一定奏效，可能效率并不高。这时，需要有非常规 的方法来应对。 如果让完全没有经验的人员进行测试并发现问题（我们称这个人为外行），遇到问题 时，这个人可能有两种应对情形，第一种情形是束手无策，不知发现问题和解决问题都该 从何入手；第二种情形是，这个外行不受任何成规的约束，提出一些天马行空的想法。因 为没有专业背景的限制，这些想法可能真的不着边际，甚至扰乱了问题本身的解决，然而， 这些不着边际的想法有时却能带来令人意想不到的效果，或是从全新的角度发现了问题的 本质，或是找到了不同的思路和方法。相对而言，一个普通的专家因为受到许多既有方式 的限制，就不太可能得出这种天马行空的点子了。外行以一种随性的方式思考，这种方式 往往会带来意外的效果，因为随性的思考方式不会被规则限制。 作为测试人员，在发现和解决问题时，外行的思考方式可以成为有效的切入点。好的 切入点是一个不错的开始，然而，真正的实践还是必须以专家的严谨和慎重来验证想法是 否正确。像专家一样实践——我们倡导的还是一种小心求证的态度。软件测试是一个非常 严谨并且以事实说话的过程，任何假设都必须通过测试实践的检验。 第 1 章 上班第一天，新人培训  27  对测试已经有深入了解的人，想做到像外行一样思考，并非易事。测试专家往往下意 识地对一个方法的技术可行性做判断，这种下意识能够高效地排除许多不可行的方式方 法。但在某些时候，这种下意识却阻碍了创造性灵感的萌生。很多有意义的想法会因为可 行性的判断而被扼杀在摇篮之中。像外行一样思考——追求的是一种新的方法或者角度， 仅仅考虑某个问题是否可能存在或者某种方法是否能解决问题，不考虑方法是否有理论依 据，也避免过多地考虑可行性。

面对复杂系统的问题，这种“大胆假设，小心求证”的方法往往能产生神奇的效用。 以下是一个真实的例子，在对一个多节点的集群电子商务进行系统测试时，发现在高并发 访问的条件下，从应用服务器到数据库的连接数骤然增加，并很快到达连接数的上限。数 据库连接数一旦到达上限并且没有及时释放时，新的请求会因为无法获取连接而被阻塞， 在表面上看，系统的性能会表现得非常糟糕。 面对这样的问题，一般的问题分析方法可能难以在短时间内找到原因。这时候需要在 现有的条件下大胆假设可能有问题的地方。“现有的条件”指的是一些表面的系统运作数 据，如应用服务器日志、数据库锁信息、数据连接池信息等。根据这些信息，发现有种特 定的操作一旦出现，系统的数据库连接请求会急剧增加。通常情况下，因为存在系统级别 的缓存，重复的访问一般不会给系统带来重新计算的负担。然而，问题的表现是，反复的 访问似乎对系统产生了明显的性能影响。