一个基于风险的测试策略

一、介绍

一个测试策略的开发意味着要和客户在测试试运行时对测试组织和策略的选择方面进行沟通。这个测试策略指

出测试将怎样被执行。为了使最好地利用时间和资源变为可能，他决定系统的那些部分重点做。这个测试策略

对于一个有组织的测试方法构成一个重要的基础，对于一个易管理的测试过程作出主要的贡献。

在运行的时候，试运行的用户将期望系统的一些特殊的品质，并想知道这个版本的系统是否达到他们的需求。

如果系统在质量上不能满足用户的需求，或仅能达到有限的范围，这就意味着对这个组织有更大的损失，比如

以后将付出更高的重做的代价或者客户不满意。因此，这种情形对这个机构形成了风险。风险的书面定义是：

风险就是错误发生时，可能影响到预期损失的可能性错误。

测试涵盖了在系统质量要求会议上所能洞察到的风险。当质量出现时间估计不足时被接受，例如重新开发。如

果运行系统对组织意味着很多风险，那么好的测试显而易见的解决办法，相反也是成立的：没有风险就没有测

试。

虽然我们以上涉及到的质量和风险属于一般意义的，但是可能有很大的不同取决于实际情况。和客户讨论这个

是非常重要的，并且用这种方式把客户的意愿转化成将要执行测试的方法。因而，测试策略被导向在测试外露

的结果和覆盖风险的要求之间找到最好的平衡。为了这个目标，风险被细化到质量特征水平和独立的子系统中

。为了做成这样，为评估的风险找到一种可能的测试覆盖变得可能。这是一个更高的测试覆盖通常结果在更多

的测试中。为了在需要的测试覆盖达到这种变化，需要更多的测试技术说明（测试设计技术），提供的每个测

试覆盖详细说明都是至关重要的。
 
一个类似的保险单可能阐明关于此问题更多。一个人想要涵盖一个相关的风险，并且最好可能得到一个覆盖该

风险的适合的保险。这个保险单会支付一笔确定的保险费，如果这个人想支付更少的钱，就要买一个覆盖最低

的保险。这个结果就是如果没有覆盖的风险发生，他将得不到保险金。另一方面，如果覆盖越大，就要支付更

多的保险费，因为对这个人来讲有可能一种被保险的情况不会发生。

二、风险评估
测试策略基于风险评估。意思就是评估缺陷结果造成的损失，包括系统实施前预先未发现的缺陷和在实施过程

中发生的缺陷。

风险评估发生在质量特征和子系统的基础之上。例如，如果系统不够友好，将会发生什么样的负面影响。薪水

计算模型在薪水系统工作有误的时候将会发生什么损失。

为了更好的执行评估，应该考虑把风险的各个方面分离：风险＝失败的机会×损失，失败的可能与系统各个部

分的使用频率和发生错误的可能有关。
以下列出这些方面：

使用频率
一个功能在一天被使用数次所发生一个错误的机会要远远大于一年使用一次。
错误的可能性
以下的列表对于评估错误发生的可能性是很有帮助的。它展现了错误易发生的地方。它部分内容是基于H.

Schaefer, 1996 （幸存于时间和预算的压力之下，在：Conference Proceeding EuroSTAR1996, Amsterdam,

the Netherlands）：
复杂的功能；
完全的新功能；
（特殊的，频繁的）变更的新功能；
第一次用特定的工具或新技术来开发的功能；
在开发过程中，开发功能的程序员被更调动过的；
功能在有限的时间内实行；
功能相对平均水平被更频繁的优化过；
很多缺陷被很着就发现的功能（例如，在早期的发布或更早的回顾过程中）；
包括很多接口的功能；
没有经验的程序员；
用户不足；
在开发中质量保证不足；
低水平测试导致质量不足；
新的开发工具和开发环境；
庞大的开发小组；
开发小组沟通不理想（例如，由于地理原因或个人原因）；

损失
如果错误自己出现了，对组织将产生什么样的损失。包括修复的代价（包括系统和结果的），放弃收益和丢失

客户或信心。通常，如果错误影响到其他功能或系统时，损失会增大。在批处理中错误发生的情况下，兴许有

一种可能性会阻止他们妨碍用户，因此最后的损失将会比类似的在线进程减小。当然，唯一的把握就是错误被

及时发现。
因为事情的复杂性，不可能完全的详细客观的估计风险：这是一个全球性的评估。所以对于不能单独被测试经

理所颁布的测试评估它是重要的。一大批潜心于这个计划的人要作出贡献：客户，用户，开发小组，会计，IT

审计员等等。这不仅提高了策略的资量，而且有利于不同部门的人更加能意识到风险和扩大测试范围来是这些

风险用一种更好的办法来变得易处理。

测试策略的制定者应该意识到用户是评估损失和评价风险时使用频率的最好人选（最终用户，系统经理，和实

施经理，在线管理），而项目小组人员却最好的评估错误可能性的人（项目经理，设计人员，程序员，项目质

量成员，测试经理）。

测试评估的焦点在产品的风险上，或者，换句话说，如果产品不能证明预期的质量，对于组织来讲什么才是风

险。除此之外，还有项目风险。如果系统必须要在一月一日产出，如果功能说明书被延期太多，如果没有有经

验的测试人员以使用，或者没有测试组织按时准备好，那么我们就可以称之为项目风险。这些没有在决定测试

策略时被放在估计中；他们在测试计划中扮演角色。

开发中的测试策略目的是为了明确在确定可行的范围内，测试以这样一种方式组织工作。
最重要的问题将被建立；
问题将在很早的阶段建立；
最先发现那些需要最多的重做时间的问题；
资源造成有效的使用；
最终给出一个正确的质量建议。
总结如下：
测试策略的目的在于依靠最低的成本尽可能早的找到最重要的错误。

实际上，测试策略的制定往往与准备预算是一致的，比如要借助于测试点的分析。被采纳的测试策略结果立即

转化未测试时间需求和因此产生的测试成本的优点使策略选择易于管理。如果测试可用的时间或多或少是可以

固定的，就有可能用测试策略组合测试点分析来决定什么在有限的时间下是可以完成的。或许更重要的是在这

个时候搞清楚哪部分不需要测试，或者不能完全测试，并且因此将会招致什么样的风险。

3.质量特征
质量特征我们可以区别分为动态和静态的质量特征。动态质量特征处理一些在信息系统中使用的主要特征，如

：安全性、可用性、持续性、可描述性、功能性、友好性、适用性、效率和性能。静态特征与信息系统的本质

特征和文件有关，从开发者和将来的系统管理者出发考虑，如易管理性，可维护性、连接性、可重用性、便携

性和可测性。

4.程序
在执行测试策略时要区别主要的测试计划和特殊测试阶段的测试计划，如验收测试和系统测试。
程序要遵循新系统的开发和环境维护。为了后面，最好是在基础程序中做一些少量的变更。
一个测试策略的制定不是单纯的做一些方法上和形式上的事情。下面的步骤是帮助和指导。对于一个有效合理

的测试策略，在测试领域中经验丰富和有技术的测试执行者是主要的成功因素。有一点也应该认识到测试策略

源于重复过程的结果并且和对测试计划有关的其他活动。如果第一次测试策略指出许多必要的测试结果或者一

个客户无法接受的确定的时间计划，那么测试需要变更。缺乏测试技术相应的结构也会导致测试策略的变更。

4.1 在主要的测试计划中的策略
对于一个测试策略在主要的测试计划中的步骤有：
对质量特征作出决定；
确定有关了质量特征的重要性；
归纳质量特征到测试水平。

4.1.4 步骤1：选择质量特征
停止客户和其他有关选择质量特征在哪些测试制定的成员的联络应该关注。为了做成这样，一方面要把商业风

险估计进去，也要把系统需求包括的各方面和关系到信息系统的商业目标，以及计算机中心的方针和标准。这

些质量特征也被用于在测试执行和完成阶段向客户报告。

有些质量特征是难以测试的。把系统变得用户友好和通用，那可能是个理想，举例为证，这些理想不能转化为

可度量的需求。这就是为什么一个真实的部分要被尽可能可度量和明确的描述为有关的质量需求。这也就是质

量特征要求相关的更多结果在测试中的原因。因为这对于提出不能完成的可能性是没有用的，她应该被决定在

一个需要做决定的评估结果之前。

对于非IT人来讲我们的质量特征可能是难以处理的。她在我们给外界合作伙伴翻译时给予帮助。通过找到可说

明问题可能发生在产品中和可能导致损失的例证来做到。这是明确表达测试策略的最难的部分。

4.1.2 步骤2：质量特征相关的重要性
基于步骤1 的结果，决定质量特征的重要性是相互决定的。通过衡量每个质量特征相关的风险，在重要性矩阵

中作出来。相关重要性通过百分比的形式展示出来。注释不是给出重要性的确切百分比：达到目标在不同质量

特征相关重要性的概述图表。在矩阵中的图像可帮助评估风险。
客户被迫作出选择。因此，作为一个指导，我们最少询问5％。百分比的总数可能达不到100％。例如：

在表中百分比最高的功能性可能惊动读者。这与实际经验是一致的：通常这个特征描述大于50％的重要性。原

因是通常这些功能使用不正常的系统的风险远远大于运行慢的系统或难于使用的系统。

4.1.3 步骤3：质量特征归结于测试水平
为了达到尽可能有效的使用测试开销，测试策略的制定取决于测试水平或将要选择测试的不同质量特征合并的

测试水平。同样检查也受到主要测试计划和测试策略范围的影响。当测试被使用时，保留部分，检查也包括在

内。

通过这种方法，一个项目内不同的测试标准使得平衡。显然，不同的职责保持完整。

表里的符号+显示测试策略是否要把一个质量特征计入在内。＋＋或＋＋＋表示给指定的测试标准更多的质量特

征关注。显然一个质量特征对多个测试标准是有效的，但是深度是有所不同的。如果使用规范结构测试技术，

例如：验收测试，可能会使用之前的测试结果，基于此可以决定测试的浅度。
图例:
Insp RQMS 检查需求
Insp Specs 检查功能详细设计
Insp Design 检查技术设计
PT  程序测试
IT  集成测试
ST  系统测试
FAT  功能验收测试
PAT  产品验收测试

4.2对于一个测试标准的测试策略
对于一个明确的测试标准，要执行的测试策略步骤有：
1.取决于质量特征
2.测定质量特征相关的重要性
3.把系统分为子系统
4.测定子系统相关的重要性
5.详细说明每个子系统和质量特征的测试重要性
6.设立使用的测试技术

对于一个指定的测试标准，策略决定有作为前提和起点的主要测试计划策略。如果一个主要的测试计划，步骤1

被忽略，并且步骤2被简单快速的执行完毕。然而，所有的步骤在下面执行。

4.2.1 步骤1：对质量特征作决定
合作的客户和可能与质量特征相关的其他成员决定关注哪个测试涉及到商业风险。在测试和完成阶段，结果会

基于质量特征被报告。
4.2.2步骤2：确定相关质量特征的重要性
基于步骤1的结果来决定选择质量特征相关的重要性。通过衡量每个质量特征决定要发生的最重要的。通过百分

比展示在一个衡量的表的相关重要性的列里。为了促使客户作出决定，5％是最小值。

给出一个功能验收测试的例子：
4.2.3步骤3：把系统分为子系统
在这个阶段和接下来的阶段，测试策略被精练更多。这意味着如表中所显示的质量特征和他们相关的重要性因

为测试技术说明和子系统的合并而破坏，随后开始测试技术说明和单元测试。
信息系统被分成多个子系统。原因是同样的质量要求对于每个子系统不是有效的。而且，不同的子系统对于组

织来讲有不同的风险。原则上划分的模块和给的设计文档是一致的。如果偏离了这一点，我们必须清楚的表明

这样做的动机。例如可供选择的模块是基于风险范围的或者基于开发者发布的命令。如果有一个变更的模型，

它就要被视为一个分离的子系统。通常子系统和总系统是被区别开来的。这个服务的意图是表明一些质量特征

仅仅是通过继承测试被有效评估的，测试子系统的一致性。
在后面的阶段，这些子系统被更细的分为独立的测试单元。例如，在一个后勤系统的子系统，销售可分为报价

单和订单测试单元。
4.2.4步骤4：决定子系统的相关重要性
基于前面步骤的结果，子系统相关的重要性在表中显示。通过衡量每个子系统的风险作出来。和看到客户和相

关其他人的关于子系统重要性的全局的印象，这不是一个精确百分比的问题。这步可以帮助有这方面疑问的人

们。

确定下系统系统中的每个子系统相关的重要性。在表中通过百分比的形式显示相关重要性。

以下给出一个关于功能验收测试的这方面的例子（基于在主要测试计划中对测试标准的策略）：

4.2.5步骤5：说明每个子系统和质量特征的测试重要性
最终一个完美的方案由评估质量特征和子系统的重要性组成，例如，一个完美的方案可能认为用户友好是重要

的，但是它对子系统1是支持的，对子系统3却一点关系也没有。再次强调测试策略决定并非是一个精确的事情

：它意味着通过不同子系统相关测试的重要性和质量特征，得到一个印象。这也就是我们为什么选择＋，＋＋

，＋＋＋做为标记，而不选其他假拟确定的数学公式。下列的假设对于用户友好和一批指定的子系统是非常重

要的，在一批程序上做关于用户友好的大的测试才可能会得到数学公式。

4.2.6步骤6：确定可用的测试技术
测试策略的最后一步包括在即将测试的已选择的质量特征和子系统集合选择测试规范技术。一个高的重要性意

味着通过一个高的覆盖率使用技术或使用更多的技术，一个低的重要性意味着使用低的覆盖率技术或使用少的

技术。

在选择技术的时候要把不同的其他因素计入成本，以下列出一些：

被测试的质量特征
一种技术适用一种或更多的质量特征。有些质量特征可以用一系列技术做最好的测试，其他的用另一种。

应用领域
有些技术是专门用来测试用户和系统交互的，另外一些则能更好的用于系统处理。通过一种技术，能发现相关

的一类型的错误，例如，错误输入检查，错误处理或错误集成。

测试基础的可用性
每种技术都是开始于一种确定的测试基础。这可能是功能说明书，技术设计，编码或最终用户的说明书。精确

的测试基础也与选择技术有关，例如，确定表，伪代码，结构化语言或无结构的文档。

正式的范围
不正式的测试技术说明相对于正式的技术，在编写测试用例时，给测试人员更多的自由。

资源的利用
技术的实施需要许多特定的资源，根据人和机器的能力。使用资源需要成本做指导。

必需的知识和技术
不是每个测试人员都会每种技术。为了使有些技术更好的应用，大量的商业知识是必要的。对于另外一些技术

，还需要更多的分析才能。因此，测试人员的知识和技术也影响到技术的选择。
出于实际的原因，还应该考虑用一系列最少的测试技术规格来覆盖所有选择的测试特征。
选择测试技术规格应该在早期的测试阶段做好，因为之后测试小组就可以在学习技术上作出恰当的行为，并列

出必要的清单，或调整某些特殊的情形。
这个阶段的结果就是用于每个子系统的技术将被详细说明。随意的，特别是一些大的测试项目，这个最后的阶

段在测试策略执行的稍有些晚，也就是说在准备阶段。作为测试阶段优先执行的一部分是决定的。目的就是使

最重要的测试尽可能早的执行。

4.3测试过程的策略
测试策略提前定好往往在后面的测试阶段会有压力。在这种情况下，测试经理要执行更少的测试或更短的测试

来与变更的计划保持一致。在最后的开发阶段，主要的结论有：突然有些测试必须被取消或者只能不深入的执

行。以测试策略为基础，测试经理可以和客户讨论哪些测试可以被取消或者哪些地方可以不深入的测试。通过

标注哪些测试与评估的风险关联较小（在策略中转化成的重要性），测试经理可以出具一个关于测试之后增加

的风险的格式一致的报告。所以不去改变步骤1－5是本质的：风险和重要性水平都没有改变。结果就是，当测

试减少时，在执行系统时会有更多的风险。

抛开这一点，还有一种情况就是在测试时会出现部分系统包含非常多的错误或非常少的错误。两者都可以使测

试策略作出调整，也就是说分别增加或减少测试。相反的情形就是在之前的章节讲的风险同样会在执行系统之

后被保留。可以概括为：
在发现和改正错误的成本低于关系到发生在产品中错误的成本时，测试应该继续。

在发现和修改错误的成本要高于测试成本该充当的角色；另外，大量的成本是与运输产品延迟有关的。对于发

生在产品中的错误也应该被估计到偶然性，因为错误将真的会发生：一个错误将永远不会发生才是没有错误。

4.4维护的策略
开发新系统和维护测试策略两者之间，主要的不同是偶然性的错误。维护变化的依据是现有的已做好的信息系

统。这些变化应该被测试。在维护中，新错误的引入是一个风险，会导致系统质量下降。

在维护的情况下，这些不同偶然性错误的含义是意味着对于策略而言，子系统相关的重要性可能会改变：一个

子系统在开发的时候有很高的重要性，在维护的时候可能没有变化。因为在衰退的可能性是这种情况下仅有的

风险，测试的重要性就更低了。因此，针对测试水平测试策略的开发，可以通过把在这些阶段子系统的概念变

为改变来修改。为了每个变化要分析系统的哪些部分变异了，哪些部分会因此产生影响，哪些质量特征是有关

联的。基于风险，对测试每个改变有些不同的可能性：
一个只针对变化的有限的测试；
一个对改变的功能的完整的测试；
改变的功能和相关的功能的一致性测试；

对系统也要做一个整体的衰退测试。测试的中心是有关系统改变和未改变部分的一致，因为衰退的偶然性是最

大的。如果测试策略对于一个新开发的系统是可用的，重要性水平归结于子系统的使用。

处理改变的错误的可能性，在开发的系统和维护的系统之间还有更多的不同。尽管，他们对测试策略开发的技

术没有影响。例如，不同之处包括：

测试原则丧失，不完整或不是最新的
在维护中很频繁的这种情况，导致对测试技术的选择。

可预测的点对点的维护
多数维护情况是可预料的，并且可以计划。策略很容易决定这种类型维护的应用。在点对点的维护下，这种情

况更难，重心是让一个坏掉的产品恢复正常，并且使系统尽快传播出去。一个正式的策略决定要花掉很多时间

。对于测试策略场景是可用的。如果程序x出错又修复了，该测试什么？对于点对点测试，这些场景支持一个最

理想的测试。

5.结论
信息系统的测试基于组织在系统中体验的的商业风险。测试经理经常设法用一种直觉的方式从风险来做测试覆

盖。在这篇文中，对于测试策略已定义好的步骤是直接的。这样一个测试策略对于相关成员是一个很好的见识

，对于讨论测试深度也是一个合理的根据。

好的风险评估是这些步骤中的一部分。这是基本的，可以以一致直接的方式认识风险没有被测试经理或测试员

单独做到。确定包括的人员（用户，客户经理，审计师，工程人员如开发，测试 QA和项目经理）是必要的。实

际上，风险的讨论和有关的测试策略用这种方式使所有人大开眼见。讨论了测试深度，通过顾客决定的，理论

可被怎样彻底测试。

这种逐步定义的测试策略可被用于任何测试阶段（如，系统测试，验收测试），对于一个全部的策略也是一样

（主要测试计划，包括和调整的所有测试阶段和检查）