51Testing软件测试网：制定项目的测试策略

你需要一个测试策略。为什么？

最近，我需要为自己工作的项目制定一份完整的测试策略。在我刚来到这个项目组时，我发现开发人员试图使用一个不完整的瀑布生命周期模型。这就意味着开发过程要具备专门的团队基础。刚好，这个项目组有大约12个开发人员，正处在利用并行开发工作来研究更多迭代方法的过程中。有一个测试新手，工作非常努力，为项目提供仅有的测试。而我为了帮助他们测试，也加入了这个项目。与此同时，项目组雇用了新的项目经理和架构师，非常主动地承诺会在剩余的一年时间内结束项目。这种沉闷的情景是不是听起来很熟悉？我猜它会是这样，因为这不是我第一次碰到这种情况。

这里，首要的问题是制定一份测试策略。什么是测试策略？这要看是谁在问你。这篇文章里，我们会把测试策略作为所有测试阶段、测试技术和项目所使用的测试工具的目标。最重要的一点，测试策略应该使测试过程中的交流变得更为容易，而它会影响到整个项目组。

通过制定测试策略来指导我们的工作，下面是项目组所碰到过的一些具体问题，我们需要寻找一些解决他们的方法：

· 缺乏可重复性测试—-项目缺少回归测试。

· 缺乏可见性测试—-没有收集衡量结果的指标，唯一的标准就是发布代码的期限。

· 反作用的构建过程—-他们只对项目的紧急程度构建响应，没有预测其他构建人的需要。

· 没有对测试环境或测试数据进行控制。

· 代码发布后，没有进行单元或集成测试。

· 没有简单的自动化过程，没有测试过程。

下面的故事会告诉我们如何定义并实施一个测试策略。

让我们开始吧

在制定测试策略时，你需要和项目中的关键人物一起，将关注点放在你们所面对的问题上，制定一个长期的解决方案，可以在整个项目周期内实施。除了上面列出的那些问题之外，我们的项目解决方案还要满足测试策略的基本需求：在开发周期内，帮助项目组尽可能早的找到最严重的bugs。想尽早地发现最严重的缺陷，需要把项目的测试部分和开发部分联合在一起，包括不同的测试阶段、测试类型、项目环境，以及如何在环境、角色、职责之间升级代码，还有普遍使用的工具。

这个看起来是不是有点复杂？实际上，它比你想象的简单。

保持简单：写字板上的计划

测试策略应该尽量的简单，这样我们可以将其展现在白色的写字板上，同时，一个简短的会议，你应该可以把它的含义解释给项目组内的任何一个人。在你花时间把测试策略的细节写入文档之前，清晰地定义简化的概念是简单性的保证。把想法和内容写到写字板上的过程是一件非常有参与性的事情，它可以帮助人们共享意见和观点，这时候，写字板往往是最好的媒介。人们使用写字板时，会画一些漂亮的图和流程图，而这些图形符号每个人都能理解。

制定测试策略时，你需要把项目组的其他人包含进来。一般有项目经理、开发主管、架构师、DBA（数据库管理员），以及其他一些关键人物，他们具有一些可利用的技术资源，所以他们可能具有更好的想法。此外，你的测试策略应该覆盖整个项目的生命周期，让每个人都能按照它的方式工作。这意味着你需要这些技术人员投入其中，以保证它能够成功地实施。至少，他们可以给你更多有关测试类型的现实想法（单元测试、代码复查、执行期分析等等）。我通常试着寻找那些最大程度地包含在项目中的人，和他们一起开会讨论。因为，他们的洞察力和建议往往是非常宝贵的。

第1步：基本策略轮廓

拿出一个空白的写字板，和大家一起开始。首先，把每个你想要捕获、制定的测试方面写到写字板上，分成列的形式。对于我们的项目，我把测试阶段（包含了项目所执行的测试类型）、不同的代码环境和衡量指标各分成了一列，其中的衡量指标决定我们何时在不同的环境之间移动代码。图一展现了它的基本面貌。

图一写字板—-轮廓

图一 写字板—-轮廓

我使用红色标注出这些定义。列出项目组当前并存执行的每个测试阶段；在测试阶段的下面，列出要执行的测试类型。而寻找测试类型的过程，会帮助你清晰地定义测试阶段，同时，你可以把每个阶段所代表的含义和产生的内容分成一组。这里没有所谓的“正确”定义；唯一重要的一点，就是大家都认可你所使用的定义。你也可能需要定义测试的类型，但更重要的是确保每个人都能够理解如何区分不同的测试类型。记住，你要使大家能够自由地讨论测试策略，一个清晰的框架需要清晰的定义。

第2步：目前的安排

接下来，列出不同的项目环境，以及当前所使用的衡量指标，后者决定了何时在环境之间移动构建。在我们的项目中，我询问了每一个参加会议的人，发现项目组会执行系统测试和一些回归测试，以及为少量用户提供的专门的接受测试。而这里缺少单元测试和集成测试的一致性，以及通常在代码提交给用户之后所要进行的代码复查工作。系统测试中，我们利用一些功能测试和生命周期测试，将大部分的需求做了验证。而在前面的迭代中，项目组执行了一个或两个临时的潜在测试，所以我们已经包含了那些测试。所有的回归测试，在时间允许的情况下，从前面的一次发布开始，是手工地基于测试用例的测试。

我们具有5个项目环境。每个开发人员有着他们自己的本地环境，接着，他们要将其全部集成到一个普遍的开发环境中。一旦被集成，项目要构建一个测试环境，以进行系统测试的工作。然后，基于需求验证和发布日期（关键的衡量指标），把代码移动到质量保证（QA）的环境中。用户根据发布的版本对大多数的期望功能进行复查，然后在一系列的结束标志（另一个关键的衡量指标）出现后，代码即可移动到产品中。图2展现了我们的测试策略，它包含了上面所说的全部内容。在衡量指标的那一列中，我们对每个环境中的需求验证级别进行了讨论，确定了那些能准确地反映当前过程的数字。

图2 写字板—-测试的当前状态

第3步：突如其来的改进

一旦所有的人都同意了写字板上有关衡量指标的内容，我们就可以开始制定项目测试希望达到的目标了。我们谈论了一些有关实践和工具的内容，后者可以帮助我们提高效率，并与我们当前的资源（人力和财力）水平相符合。同时，我们意识到，很可能不能再扩大测试组的规模了，这样我们会设法让开发人员为测试提供帮助，而谈论的关注点也随之开始围绕在此问题上。当然，我们也可以把关注点放在我们所经历的那些关键问题上。（还记得前面我所罗列的那些问题吗？）

在第六届IEEE关于Web Site发展的国际研讨会上，Hung Nguyen为我们描述了一种制定测试策略的技术—-获得一个“bug centric”。他的方法是查看产品中已发现的问题，然后将这些具体问题视为目标，反向地创建策略。他的关注点是设法添加可见性，以此确定成本，来提高产品的发布速度。无论你的上下文背景是什么，都要确保自由讨论的小组能够了解到他们所要解决的问题。如果你的测试策略没有一个明确的完成目标，那么就后退一步，先建立一个清晰的目标。最糟的莫过于你的测试策略具有一个错误的目标—-这个策略注定会以失败告终。它会产生新的问题，也会把现有的问题变得更糟。最好的情况，它偶尔可能会解决一些问题，但同时，会让我们更加的难于解决剩余的问题（实际没有如此困难）。

在我们自由讨论的时候，商定了许多问题，并得到了一些结论：

· 利用单元测试和集成测试，我们可以尽早地发现更多的问题，并准备好自动化测试的初始级别，同时，它们为我们提供了一些衡量指标，这些指标让我们可以更好的跟踪开发过程，这样，我们可以做出决定—-何时移动我们的代码。（多数情况下，我们使用J2EE和Oracle来构建应用程序，同时，也使用一些其他的技术补充。但不论J2EE或Oracle，它们都具有非常健壮和自由的单元和集成测试工具。）

· 系统测试中，我们以每次发布用户基线为结束，用户基线会增长，同时他们也会逐渐地要求一些更为精确的性能测试—-尽管我们对此还只是略知皮毛。

· 我们不能再依赖于需求验证，不能再继续将其作为我们主要的测试类型了。尽管那是非常重要的事情，因为我们不能忽略安全性测试、可用性测试、配置测试和数据完整性测试，以及上百种其他类型的测试。

· 我们决定进行一些基于session（session-based）的探索性测试，而最初是以成对的方式执行该测试的，直到我们更为适应这种类型测试的过程，同时，也发展了我们快速学习和解决问题的能力。一旦我们适应了探索性测试的工作，那么我们可以开始执行更多的sessions。

· 我们发觉，需要建立一个正规的且自动化的烟雾测试，它适用于所有的环境，它和自动化回归测试的脚本集一起被用来测试那些高风险的功能，以及高容量的事务处理。

· 我们知道，用户的接受测试（UAT）远远达不到它应有的效果。因此，我们提出要制定更为详细的UAT测试计划，将其与测试脚本和培训材料一起提供给用户，以帮助他们快速地提高。然而，这并不意味着我们希望能够全权负责UAT的工作，由我们提供更多的指南、资源和培训来帮助用户进行接受测试，我们的目的只是希望UAT执行的更为顺利。

· 我们商定了代码何时可以在环境之间移动的衡量指标。无论是单元测试，还是集成测试，90%的测试通过率对代码而言已经足够了，甚至可以从中了解到一些还会出现的bug—-只要不存在长期影响系统正常运行的bug就行。

· 我们决定要执行严格的代码复查，以保证在早期（更可取的是在写完或接近完成代码时）就发现问题，而不是在代码发布之后。我们创建了烟雾测试之后，代码必须100%的通过这些测试，这样才能前进入下一个级别。

· 系统测试中，我们无论如何都不能让任何严重或高级别的缺陷遗留到下一个过程中，但是也存在这样的一些缺陷，是我们所能容忍的，我们可以和用户进行交流，以此来确定他们的期望：问题现在就被修复，还是放在后面解决。

我们使用了代码覆盖的测试工具，根据它添加了一些相关的衡量指标，同时根据工具的缺陷趋势分析，来帮助我们衡量系统测试工作的效果。

我在写字板上记录了会议内容，如图3所示，分别用不同的颜色进行了标注。

图3 写字板—-添加的测试类型和衡量指标

第4步：组织计划

这个时候，我询问了会议室中的每一个人，一起来检查我们刚才所达成的（写在写字板上）共识，这种感觉就像是我们已经成功地执行了这个计划。下一步，划分职责和活动的实际区域范围。我们花了几分钟时间在写字板上做了相应的标注，如图4所示的蓝色方括号和箭头。

图4 书写板—-职责、环境

这些分组反映出项目中所包含的工作小组。当然，你的项目可能包含了更多的工作小组—多个开发或测试组，甚至有独立的行政或QA组。写字板上的蓝色箭头表示我们要执行的测试类型与环境的关联关系。虽然还不算完美，但这些内容为我们提供了一个测试提纲，使我们知道了大多数测试工作的分布情况。

第5步：确定要使用的工具

最后一步，我们需要计划测试中实际所使用的工具，把这些工具添加到我们的测试策略里。在这一方面，该公司以IBM Rational的相关产品为主，于是我们确定了主要的测试工具，当然，我们也需要其他一些有帮助意义的工具作为它们的补充。比如单元测试，我们选用JUnit，因为我们的开发人员知道该如何使用它—-另外，免费和容易上手的特点也是选择它的原因。静态分析，我们选用Jlint。其他的工具，我们全部选用Rational的产品：使用ClearCase进行资源和测试资产的控制；使用ClearQuest跟踪问题；Purify、Quantify和PureCoverage被用来进行运行期分析；需求管理（rm）工具使用Requisite Pro；自动化测试使用Robot和TestManager。本来，我们也讨论过使用其他一些运行期分析和资源控制工具，但是考虑到统一的平台更便于我们的管理。图5展现的写字板上，包含了这些信息。

图5 书写板—-最终所形成的测试策略

完成这些之后，接下来我们可以实施它了。

实施

现在，你已经有了一个策略，将它共享给项目中的每一个人。通过写字板来收集每个人的看法—-或者，更好的方法，使用Visio把写字板上的内容转变成幻灯片。让制定这份策略的人来帮助你解释策略和你要实施的计划。每一个参与策略制定的人都可以帮助你，这样不会让人有这不过是你一个人空想的感觉，并且你会获得来自于整个项目组的支持。回答人们的问题，得到他们的反馈，准备好策略变更。因为有一些人可能知道更好的工具，更合适的技术，或者更有意义的衡量指标。

一旦大家都同意，把该测试策略作为一个可接受的解决方案，那么就可以制定一个实施计划了。在此计划中，回答下面的问题：

· 包含了各新测试类型的迭代过程是什么？（划分测试类型对应的每个迭代过程。）

· 我们如何对之前没有做过测试的小组进行测试培训？（事关测试资源的利用和分配。）

· 我们何时开始安装、配置新的测试工具，并进行相关的培训？（测试工具的使用问题，会影响测试的实际进度。）

· 由谁来负责每个测试阶段的管理工作？（指定一个测试负责人。）

· 我们如何计划这份测试策略的修订和更新工作？（需要控制测试策略的版本变更。）

· 我们如何衡量这份测试策略的有效性？（对该测试策略的效果进行评估，评估的标准是什么？）

· 由谁来负责该测试策略的维护工作？（我们应该有自己的配置管理员来维护这些测试资产。）

进一步思考，你会遇到其他一些实施方面的问题，这些和你的项目背景有关。但是，你只要能确保下面的一些情况就可以了：你拥有所需的资源（人、硬件和软件）；你有时间和能力给项目组内的人做相关的培训；你是个越干越起劲的人。

这篇文章所讨论项目的测试策略还没有具体地实施。我们发现了一些变更，比之前面的更具效力。我们已经完成了测试策略，但每次的迭代过程，我们依然关注具体的新工具和新技术，或者关注与人员的培训，以使其具有更高的效率。我们的测试策略很简单，它具有的格式也使我们可以容易地修改和更新，在我们开发其他的软件时，发现它不仅灵活，而且很有帮助性。