测试策略的确定方式和方法.ppt

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