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

测试策略的制定方法贺炘[e-mail]制定测试策略的目的•测试策略用于说明某项特定测试工作的一般方法和目标。•一个好的测试策略应该包括下列内容：–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-可能会测试，但只有在测试完所