– 1.确保将测试工作的重点放在最适当的测试需求上 – 2.确保尽早地处理最关键、最有意义或风险最高的测试需求 – 3.确保在测试中考虑到了任意依赖关系（序列、数据等等）
要评估风险并确定测试优先级，可执行以下三个步骤：
– 评估风险 – 确定实施概要 – 确定测试优先级
评估风险
• 在开始时可确定并说明将要使用的风险程度指 标，例如：
评估风险
• 在确定风险程度指标之后，列出测试对象中的每个用 例或构件。为列表中的每一个用例或构件确定一个风 险程度指标，并简要说明您选择相应值的原因。 • 可以从三个方面来评估风险：
– 影响 - 指定用例（需求等）失效后将造成的影响或后果 – 原因 - 用例失效所导致的非预期结果 – 可能性 - 用例失效的可能性。
数据/数据库崩溃
H
无论是因为何种原因，数据的崩溃都是不可容忍的。 可能的原因包括： 因用户的干涉而没有完成/提交将写入数据库的事务 因 Internet 连接丢失而没有完成/提交将写入数据库的事务 用户在事务中输入无效的数据 数据库访问方法/实用程序 数据库没有正确地装入（当进行初始实例化时）
订单出现重复
• 例如：
– “为什么只有部分文件存在于系统中而且没有构造 出所有的注册项？” – “事务为什么没有在中央数据库中得到适当的反映？ – “付帐循环语句为什么只反映了数据库中满足预期 标准的部分记录?”
以下是这些问题的理由矩阵示例：
说明 风险降低因子 理由
缺少/应用程序文件和 注册项
H
致使应用程序（并可能使系统）不可用。安装使用户得到对应用程 序的第一印象。如果安装失败，用户就会对该软件形成负面的印象。 导致这种情况的原因可能包括： 安装过程没有安装所有文件，并且没有正确地更新注册表 因用户干涉（取消或退出）而使安装过程异常终止 因软件/硬件干涉（磁盘空间不足、配置不被支持等）而使安装过程 异常终止 因未知情况而使安装过程异常终止 用户删除了文件/注册项 在这些原因中，只有最后一个是安装过程所无法检测和处理的。
–H - 高风险，无法忍受。极易遭受外部的风险。公 司将遭受巨大的经济损失、债务或不可恢复的名誉 损失。 –M - 中等风险，可以忍受，但是不希望其出现。遭 受外部风险的可能性最小，公司可能会遭受经济损 失，但只存在有限的债务或名誉损失。 –L - 低风险，可以忍受。根本不会或不太可能遭受 外部的风险，公司只有少许经济损失或债务或根本 没有损失。公司的名誉也不会受到影响。
选择一个方面，确定风险程度指标并说明您所作选择 的原因。不必为风险的每个方面都确定一个指标。然 而，如果确定了一个低风险指标，最好再从另一个方 面来评估该风险，以确保它的确是低风险。
影响
• 要根据评估结果风险，应确定条件、事件或操作，从 而确定它的影响。 • 可以询问以下问题：
– “如果 ___________，将出现什么情况？”
– 1.时间语句，如响应时间或定时情况 – 2.指出在规定时间内必须出现的事件数或用例数的 语句 – 3.将某一项性能的行为与另一项性能的行为进行比 较的语句 – 4.将某一配置下的应用程序行为与另一配置下的应 用程序行为进行比较的语句 – 5.一段时间内的操作可靠性（平均故障时间或 MTTF） – 6.配置或约束
• 例如：
– “如果在安装新软件时，系统磁盘空间不足，将出现什么情 况？” – “如果 Internet 连接在查询事务过程中丢失，将出现什么 情况？” – “如果 Internet 连接在购买事务过程中丢失，将出现什么 情况？” – “如果用户输入一个非预期值，将出现什么情况？”
以下是这些问题的理由矩阵示例：
说明
风险降低因子
H
理由
安装过程中磁盘空 间不足
用户会从软件安装中获得对该产品的第一印象。任何非预 期的结果（如下列结果）都会降低用户系统（即已安装的 软件）的性能，并给用户造成一种负面的印象： 软件仅部 分安装（部分文件、部分注册项），使已安装的软件处于 不稳定的环境下；或者 安装过程异常终止，使系统处于不 稳定的状态 这种连接丢失不会给数据或数据库造成损坏。但应该注意 到：连接丢失会给用户造成一种负面的印象。 导致以下结果的连接丢失或事务丢失会增加日常开支并降 低利润，因此都是不可接受的： 数据库崩溃 订单不完整 数据或订单丢失 （重复的）多重订单 任意导致下列结果的事务都是无法接受的： 数据库崩溃 数据不准确
安装新软件
L
我们使用的是已经取得商业成功的安装实用程序。虽然失败的安装 会导致应用程序不可用，但我们选择的是由一个成功厂商提供的安 装实用程序，该厂商的产品已经占有了最大的市场份额，其从业时 间也超过四年。我们对他们的评估表明，该产品符合我们的需要而 且客户也对他们的产品、厂商以及他们的服务和水平感到满意。
用例 1、10、12 中的 高故障发现率/缺陷密 度。
H
由于先前的高故障发现率和缺陷密度，用例 1、10 和 12 被认为是 高风险的。
用例 14 和 19中的变 更请求。
H
对这些用例进行的大量更改将增加在代码中“注入”缺陷的可能性。
确定实施概要
• 在开始时可确定和说明将要使用的实施概要程度指标，例如：
评估风险和确定测试优先级
• 成功的测试需要在测试工作中成功地权 衡资源约束和风险等因素。为此，应该 确定测试工作的优先级，以便先测试最 重要、最有意义或风险最高的用例或构 件。为了确定测试工作的优先级，需执 行风险评估和实施概要，并将其作为确 定测试优先级的基础。
评估风险和确定测试优先级的步骤
确定测试需求只是确定测试内容的一部分。还应该确定 测试内容的优先级和先后顺序。之所以要执行这一步 骤，是为了以下几个目的：
可能性
• 根据可能性来评估风险也就是确定用例（或实施用例 的构件）失效的概率。这种概率通常基于某个外部因 素，例如：
– 故障率和/或密度 – 变更率 – 复杂性 – 来源/始创人
• 应该注意的是：当根据这一方面来评估风险时，风险 程度指标与发生故障的概率相关，而不是与故障对组 织的影响（它用于根据结果和原因来评估风险）相关。
变更率
随着用例或构件变更率的增加，发生故障的概率也会增加。因而，当变更次数增 加时，导致某个缺陷的概率也会随之增加。每改动一次代码，都存在向代码“注 入”另一个缺陷的风险。
复杂性
随着用例或构件复杂程度的增加，发生故障的概率也会增加。
来源/始创人
有 关 代码 来 源和 代码编 写 者的 知识 和 经验会 增 加或 降低 发 生故障 的 概率 。 如果使用第三方构件，通常会降低发生故障的概率。然而，其前提是第三方构件 已经通过认证（通过正式测试或经验判断，证明它满足您的需求）。 发生故障的概率通常随着实施员知识和技能的增加而降低。然而，即使由最优秀 的人员来实施，使用新工具、新技术以及担任多个角色等情况也会增加发生故障 的概率。
H
重复的订单会导致货运、处理以及重新进货等方面的成本，从而将 增加公司的日常开支并降低利润。 可能的原因包括： 因用户干涉、用户两次输入订单而没有确认输入而重复将订单写入 数据库这一事务 因非用户干涉（从丢失的 Internet 连接中进行恢复、恢复数据库 等）而重复将订单写入数据库这一事务
某个订单的数据不准 确
测试策略的制定方法
贺炘 Hcat@
制定测试策略的目的
• 测试策略用于说明某项特定测试工作的一般方 法和目标。 • 一个好的测试策略应该包括下列内容：
– – – – – 1.实施的测试类型和测试的目标 2.实施测试的阶段 3.技术 4.用于评估测试结果和测试是否完成的评测和标准 5.对测试策略所述的测试工作存在影响的特殊事项
性能测试需求
• 性能测试需求来自于测试对象的指定性 能行为。性能通常被描述为对响应时间 和 /或资源使用率的某种评测。性能在各 种条件下进行评测，这些条件包括：
– 1.不同的工作量和/或系统条件 – 2.不同的用例 – 3.不同的配置
性能测试需求
• 性能需求在补充需求中说明。检查这些材料， 对包括以下内容的语句要特别注意：
H
任何无法完成的订单或导致额外日常开支的订单都是不可接受的。 可能的原因包括： 因用户干涉而没有完成/提交订单事务 因 Internet 连接丢失而没有完成/提交订单事务 用户输入无效的数据
在语句中反应出错误 的记录数
H
业务决策和应收帐款都依赖于这些报告的准确性。 可能的原因包括： 搜索/选择标准不正确 SQL 语句不正确 数据库中的数据被破坏 数据库中的数据不正确
– H - 使用得相当频繁，在每个时期会使用很多次，或者由多个主角 或用例使用。 – M - 使用得比较频繁，在每个时期会使用若干次，或者由若干个主 角或用例使用。 – L - 很少使用，或者由很少的几个主角或用例使用。
• 所选择的实施概要指标应该基于用例或构件的执行频率，其中包 括：
– 一个主角（或用例）在给定时间内执行用例（或构件）的次数，或 者执行用例（或构件）的主角（或用例）的数量.通常，用例或构件 的使用次数越多，实施概要指标也就越高。 – 在确定实施概要程度指标之后，列出测试对象中的每个用例或构件。 为列出的每一项确定一个实施概要指标并且说明每个指标值的理由。 性能分析文档中的信息可用于此评估。
例如： 安装新软件 “过去，我们已经在用于实施用例 1、10 和 12 的构件中发现许多缺陷，而我们的客户要求对用例 14 和 19 进行多处更改。”
以下是这些问题的理由矩阵示例：
说明 风险降低因子 理由
安装新软件
H
我们正在编写自己的安装实用程序。致使应用程序不可用。安装使 用户得到对应用程序的第一印象。如果安装失败，用户求有若干个来源，它们通常在补 充需求、用户界面指南、设计指南和编程指南 中进行说明。 • 检查这些工件，对包括以下内容的语句要特别 注意：
– 1.有关可靠性或对故障、运行时错误（如内存减少） 的抵抗力的语句 – 2.说明代码完整性和结构（与语言和语法相一致） 的语句 – 3.有关资源使用的语句