软件测试培训讲义软件测试技术概述.pptx

《软件测试培训讲义软件测试技术概述.pptx》由会员分享，可在线阅读，更多相关《软件测试培训讲义软件测试技术概述.pptx（58页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、课程目的了解软件工程的基本概念和过程了解软件质量定义和软件质量保证过程深入掌握软件测试原理、方法、过程通过实战掌握测试策略、技术第1页/共58页第二部分：软件测试的技术第五章 软件测试技术概述第2页/共58页内容和目的软件测试的基本方法黑盒测试白盒测试静态测试动态测试测试策略第3页/共58页第二部分：软件测试的技术第五章：软件测试技术概述软件测试的基本方法第4页/共58页软件测试的基本方法软件测试的方法和技术是多种多样的，对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒

2、测试；第5页/共58页测试的方法与技术测试的方法与技术软件测试的策略和方法静态测试方法动态测试方法人工测试方法计算机辅助静态分析方法白盒测试方法黑盒测试方法穷举测试方法第6页/共58页静态测试：静态测试：基本特征是在对软件进行 分析、检查和测试是不实 际运行被测试的软件。静态测试约可找出303070%70%的逻辑设计错误.对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错.静态测试第7页/共58页动态测试：动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性动态测试的两个基本要素：动态测试的两个基本要素：u 被测试程序u 测试数据（测试用例）动态测试第8页/

3、共58页动态测试方法动态测试方法(1)(1)选取定义域有效值,或定义域 外无效值.(2)(2)对已选取值决定预期的结果(3)(3)用选取值执行程序(4)(4)执行结果 与(2)(2)结果相比,不吻和程序有错.动态测试第9页/共58页黑盒测试第10页/共58页黑盒测试黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部

4、信息（如数据库或文件）的完整性第11页/共58页黑盒测试黑盒测试方法主要有:等价类划分边值分析因果图错误推测主要用于软件确认测试第12页/共58页黑盒测试“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试 第13页/共58页白盒测试第14页/共58页白盒测试白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的

5、规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。第15页/共58页白盒测试“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。第16页/共58页白盒测试贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径

6、测试可能发现不了一些与数据相关的错误第17页/共58页 黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序外部特征进行测试。白盒测试是根据程序内部逻辑结构进行测试。黑盒测试与白盒测试比较第18页/共58页黑盒测试与白盒测试比较第19页/共58页穷举测试第20页/共58页穷举测试(续)第21页/共58页 不论黑盒还是白盒测试都不能进行穷尽测试,所以软件测试不可能发现程序中存在的所有错误,因此需精心设计测试方案,力争尽可能少的次数,测出尽可能多的错误.第22页/共58页第二部分：软件测试的技术第五章：软件测试技术概述测试策略的制定方法第23页/共58页制定

7、测试策略的目的测试策略用于说明某项特定测试工作的一般方法和目标。一个好的测试策略应该包括下列内容：1.实施的测试类型和测试的目标 2.实施测试的阶段 3.技术 4.用于评估测试结果和测试是否完成的评测和标准 5.对测试策略所述的测试工作存在影响的特殊事项 第24页/共58页确定测试策略的一般方法1.确定测试的需求2.评估风险并确定测试优先级3.确定测试策略第25页/共58页确定测试的需求测试需求所确定的是测试内容，即测试的具体对象。在分析测试需求时，可应用以下几条一般规则：1.测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求，就无法对其进行评估，以确定需求是否已经满足。2.在每个

8、用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。测试需求可能有许多来源，其中包括用例、用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查，以收集可用于确定测试需求的信息。第26页/共58页确定测试的需求功能性测试需求性能测试需求可靠性测试需求第27页/共58页功能性测试需求正如其名称所示，功能性测试需求来自于测试对象的功能性行为说明。每个用例至少会派生一个测试需求。对于每个用例事件流，测试需求的详细列表至少会包括一个

9、测试需求。第28页/共58页性能测试需求性能测试需求来自于测试对象的指定性能行为。性能通常被描述为对响应时间和/或资源使用率的某种评测。性能在各种条件下进行评测，这些条件包括：1.不同的工作量和/或系统条件 2.不同的用例3.不同的配置 第29页/共58页性能测试需求性能需求在补充需求中说明。检查这些材料，对包括以下内容的语句要特别注意：1.时间语句，如响应时间或定时情况 2.指出在规定时间内必须出现的事件数或用例数的语句 3.将某一项性能的行为与另一项性能的行为进行比较的语句 4.将某一配置下的应用程序行为与另一配置下的应用程序行为进行比较的语句 5.一段时间内的操作可靠性（平均故障时间或

10、MTTF）6.配置或约束 第30页/共58页可靠性测试需求测试可靠性需求有若干个来源，它们通常在补充需求、用户界面指南、设计指南和编程指南中进行说明。检查这些工件，对包括以下内容的语句要特别注意：1.有关可靠性或对故障、运行时错误（如内存减少）的抵抗力的语句 2.说明代码完整性和结构（与语言和语法相一致）的语句3.有关资源使用的语句 第31页/共58页评估风险和确定测试优先级成功的测试需要在测试工作中成功地权衡资源约束和风险等因素。为此，应该确定测试工作的优先级，以便先测试最重要、最有意义或风险最高的用例或构件。为了确定测试工作的优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础

11、。第32页/共58页评估风险和确定测试优先级的步骤确定测试需求只是确定测试内容的一部分。还应该确定测试内容的优先级和先后顺序。之所以要执行这一步骤，是为了以下几个目的：1.确保将测试工作的重点放在最适当的测试需求上 2.确保尽早地处理最关键、最有意义或风险最高的测试需求 3.确保在测试中考虑到了任意依赖关系（序列、数据等等）要评估风险并确定测试优先级，可执行以下三个步骤：评估风险确定实施概要确定测试优先级 第33页/共58页评估风险在开始时可确定并说明将要使用的风险程度指标，例如：H-高风险，无法忍受。极易遭受外部的风险。公司将遭受巨大的经济损失、债务或不可恢复的名誉损失。M-中等风险，可以忍

12、受，但是不希望其出现。遭受外部风险的可能性最小，公司可能会遭受经济损失，但只存在有限的债务或名誉损失。L-低风险，可以忍受。根本不会或不太可能遭受外部的风险，公司只有少许经济损失或债务或根本没有损失。公司的名誉也不会受到影响。第34页/共58页评估风险在确定风险程度指标之后，列出测试对象中的每个用例或构件。为列表中的每一个用例或构件确定一个风险程度指标，并简要说明您选择相应值的原因。可以从三个方面来评估风险：影响-指定用例（需求等）失效后将造成的影响或后果原因-用例失效所导致的非预期结果可能性-用例失效的可能性。选择一个方面，确定风险程度指标并说明您所作选择的原因。不必为风险的每个方面都确定一

13、个指标。然而，如果确定了一个低风险指标，最好再从另一个方面来评估该风险，以确保它的确是低风险。第35页/共58页影响要根据评估结果风险，应确定条件、事件或操作，从而确定它的影响。可以询问以下问题：“如果 _，将出现什么情况？”例如：“如果在安装新软件时，系统磁盘空间不足，将出现什么情况？”“如果 Internet 连接在查询事务过程中丢失，将出现什么情况？”“如果 Internet 连接在购买事务过程中丢失，将出现什么情况？”“如果用户输入一个非预期值，将出现什么情况？”第36页/共58页以下是这些问题的理由矩阵示例：说明风险降低因子理由安装过程中磁盘空间不足H用户会从软件安装中获得对该产品的

14、第一印象。任何非预期的结果（如下列结果）都会降低用户系统（即已安装的软件）的性能，并给用户造成一种负面的印象：软件仅部分安装（部分文件、部分注册项），使已安装的软件处于不稳定的环境下；或者 安装过程异常终止，使系统处于不稳定的状态 Internet 连接在查询过程中丢失L这种连接丢失不会给数据或数据库造成损坏。但应该注意到：连接丢失会给用户造成一种负面的印象。Internet 连接在购买过程中丢失H导致以下结果的连接丢失或事务丢失会增加日常开支并降低利润，因此都是不可接受的：数据库崩溃 订单不完整 数据或订单丢失（重复的）多重订单 输入了非预期值H任意导致下列结果的事务都是无法接受的：数据库崩

15、溃 数据不准确 第37页/共58页原因与根据评估结果风险相对的是根据原因评估风险。在开始时可以声明某个非预期的事件或条件，并确定一组能够允许该条件存在的事件。询问如下问题：“_为什么会发生？”例如：“为什么只有部分文件存在于系统中而且没有构造出所有的注册项？”“事务为什么没有在中央数据库中得到适当的反映？“付帐循环语句为什么只反映了数据库中满足预期标准的部分记录?”第38页/共58页以下是这些问题的理由矩阵示例：说明说明风险降低因子风险降低因子理由理由缺少/应用程序文件和注册项H致使应用程序（并可能使系统）不可用。安装使用户得到对应用程序的第一印象。如果安装失败，用户就会对该软件形成负面的印象

16、。导致这种情况的原因可能包括：安装过程没有安装所有文件，并且没有正确地更新注册表因用户干涉（取消或退出）而使安装过程异常终止因软件/硬件干涉（磁盘空间不足、配置不被支持等）而使安装过程异常终止因未知情况而使安装过程异常终止用户删除了文件/注册项在这些原因中，只有最后一个是安装过程所无法检测和处理的。订单不完整H由于无法执行不完整的订单，因而会导致收入和客户两方面的损失。可能的原因包括：因用户操作（断开调制解调器、关闭PC等）而导致Internet连接丢失数据库访问方法/实用程序数据库没有正确地装入（当进行初始实例化时）因IP而导致Internet连接丢失因雇员操作（断开调制解调器，关闭服务器电

17、源等）而导致Internet连接丢失数据/数据库崩溃H无论是因为何种原因，数据的崩溃都是不可容忍的。可能的原因包括：因用户的干涉而没有完成/提交将写入数据库的事务因Internet连接丢失而没有完成/提交将写入数据库的事务用户在事务中输入无效的数据第39页/共58页订单出现重复H重复的订单会导致货运、处理以及重新进货等方面的成本，从而将增加公司的日常开支并降低利润。可能的原因包括：因用户干涉、用户两次输入订单而没有确认输入而重复将订单写入数据库这一事务 因非用户干涉（从丢失的 Internet 连接中进行恢复、恢复数据库等）而重复将订单写入数据库这一事务 某个订单的数据不准确H任何无法完成的订

18、单或导致额外日常开支的订单都是不可接受的。可能的原因包括：因用户干涉而没有完成/提交订单事务 因 Internet 连接丢失而没有完成/提交订单事务 用户输入无效的数据 在语句中反应出错误的记录数H业务决策和应收帐款都依赖于这些报告的准确性。可能的原因包括：搜索/选择标准不正确 SQL 语句不正确 数据库中的数据被破坏 数据库中的数据不正确 第40页/共58页可能性根据可能性来评估风险也就是确定用例（或实施用例的构件）失效的概率。这种概率通常基于某个外部因素，例如：故障率和/或密度 变更率 复杂性 来源/始创人应该注意的是：当根据这一方面来评估风险时，风险程度指标与发生故障的概率相关，而不是与

19、故障对组织的影响（它用于根据结果和原因来评估风险）相关。第41页/共58页这些因素与发生故障的概率之间存在以下相关性：外部因素概率故障发现率和/或密度发生故障的概率随着故障发现率或密度的增加而增加。缺陷有聚集的趋势，因此，随着用例或构件内缺陷发现率或缺陷数量（密度）的增加，发现另一个缺陷的概率也会增加。由于先前的高发现率或密度表明了其他故障的高概率，所以当利用此因素来评估风险时，还应该考虑先前版本中的发现率和密度。变更率随着用例或构件变更率的增加，发生故障的概率也会增加。因而，当变更次数增加时，导致某个缺陷的概率也会随之增加。每改动一次代码，都存在向代码“注入”另一个缺陷的风险。复杂性随着用例

20、或构件复杂程度的增加，发生故障的概率也会增加。来源/始创人有关代码来源和代码编写者的知识和经验会增加或降低发生故障的概率。如果使用第三方构件，通常会降低发生故障的概率。然而，其前提是第三方构件已经通过认证（通过正式测试或经验判断，证明它满足您的需求）。发生故障的概率通常随着实施员知识和技能的增加而降低。然而，即使由最优秀的人员来实施，使用新工具、新技术以及担任多个角色等情况也会增加发生故障的概率。第42页/共58页例如：安装新软件“过去，我们已经在用于实施用例 1、10 和 12 的构件中发现许多缺陷，而我们的客户要求对用例 14 和 19 进行多处更改。”以下是这些问题的理由矩阵示例：说明风

21、险降低因子理由安装新软件H我们正在编写自己的安装实用程序。致使应用程序不可用。安装使用户得到对应用程序的第一印象。如果安装失败，用户将对该软件形成负面的印象。安装新软件L我们使用的是已经取得商业成功的安装实用程序。虽然失败的安装会导致应用程序不可用，但我们选择的是由一个成功厂商提供的安装实用程序，该厂商的产品已经占有了最大的市场份额，其从业时间也超过四年。我们对他们的评估表明，该产品符合我们的需要而且客户也对他们的产品、厂商以及他们的服务和水平感到满意。用例 1、10、12 中的高故障发现率/缺陷密度。H由于先前的高故障发现率和缺陷密度，用例 1、10 和 12 被认为是高风险的。用例 14

22、和 19中的变更请求。H对这些用例进行的大量更改将增加在代码中“注入”缺陷的可能性。第43页/共58页确定实施概要在开始时可确定和说明将要使用的实施概要程度指标，例如：H-使用得相当频繁，在每个时期会使用很多次，或者由多个主角或用例使用。M-使用得比较频繁，在每个时期会使用若干次，或者由若干个主角或用例使用。L-很少使用，或者由很少的几个主角或用例使用。所选择的实施概要指标应该基于用例或构件的执行频率，其中包括：一个主角（或用例）在给定时间内执行用例（或构件）的次数，或者执行用例（或构件）的主角（或用例）的数量.通常，用例或构件的使用次数越多，实施概要指标也就越高。在确定实施概要程度指标之后，

23、列出测试对象中的每个用例或构件。为列出的每一项确定一个实施概要指标并且说明每个指标值的理由。性能分析文档中的信息可用于此评估。第44页/共58页示例：安装新软件 对联机目录项进行排序 在发出订单后，客户联机查询他们的订单 商品选择对话框 说明实施概要因子理由安装新软件H（通常）只执行一次，但是由许多用户执行。然而，不进行安装，应用程序就无法使用。对目录项进行排序H这是用户执行得最多的用例。客户查询订单L很少有客户在发出订单后查询他们的订单商品选择对话框H客户使用此对话框来发出订单，而负责库存的职员则利用此对话框来补充库存。第45页/共58页确定测试优先级在开始时可确定和说明将要使用的测试优先程

24、度指标，例如：H-必须测试 M-应该测试，只有在测试完所有 H 项后才进行测试 L-可能会测试，但只有在测试完所有 H 和 M 项后才进行测试 在确定要使用的测试优先程度指标之后，列出测试对象中的每个用例或构件。然后，为列出的每一项确定一个测试优先级指标并且说明您的理由。以下为确定测试优先级指标提供了一些指南。当确定每一项的测试优先级指标时，应考虑下列各项：先前确定的风险程度指标值 先前确定的实施概要程度指标值 主角说明（主角是否有经验？他们是否能够接受变通方法？等等）合同责任（如果不交付用例或构件，测试对象能否被接受？）第46页/共58页确定测试优先级的策略对于每一项，将最高的评估因素（风险

25、、实施概要等）值用作总体优先级。确定一个最有意义的评估因素（风险、实施概要及其他），然后将该因素的值用作优先级。使用评估因素的组合来确定优先级。采用权重方案。在该方案中，将确定每个因素的权重，然后根据权重来计算各因素的值和优先级。第47页/共58页示例：安装新软件 对联机目录项进行排序 在发出订单后，客户联机查询他们的订单 商品选择对话框 当使用最高的评估值来确定优先级时，得到的优先级为：测试项风险实施概要主角合同优先级安装新软件HHLHH对目录项进行排序HHHHH客户查询LLLLL商品选择对话框LHLLH第48页/共58页当使用一个因素（风险）的最高评估值来确定优先级时，得到的优先级为：测试

26、项风险实施概要主角合同优先级安装新软件HHLHH对目录项进行排序HHHHH客户查询LLLLL商品选择对话框LHLLL第49页/共58页当使用权重值来计算优先级时，得到的优先级为：（注：在以下的矩阵中：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(

27、2)1(1)1(3)9L(4)商品选择对话框1(3)5(10)1(1)1(3)17L(3)第50页/共58页确定测试策略一个好的测试策略应该包括下列内容：1.实施的测试类型和测试的目标 2.实施测试的阶段 3.技术 4.用于评估测试结果和测试是否完成的评测和标准5.对测试策略所述的测试工作存在影响的特殊事项 第51页/共58页测试类型和目标应清楚地说明所实施测试的类型和测试的目标。清楚地说明这些信息有助于尽量避免混淆和误解（尤其是由于有些测试看起来非常类似）。测试目标应该表明执行测试的原因。示例：“功能性测试。功能性测试侧重于从用户界面上执行在测试对象内实施的以下用例。”“性能测试。系统的性能

28、测试将侧重于测评用例 2、4 和 8-10 的响应时间。对于这些测试，将使用一个主角的工作量来执行这些用例，而且不在测试系统上施加任何其他的工作量。”“配置测试。通过执行配置测试来确定和评估测试对象在三种不同配置下的行为，并根据我们的基准配置来比较性能特征。”第52页/共58页测试阶段 测试阶段测试类型单元集成系统验收功能性测试（配置、功能、安装、安全性、容量）XXXX性能测试（各个构件的性能曲线）XX(X)可选，或者当系统性能测试发现缺陷时性能测试（工作量、强度和竞争）XX可靠性（完整性，结构）XX(X)可选，或者当其他测试发现缺陷时第53页/共58页技术技术应该说明将如何实施和执行测试。其

29、中包括测试内容、在测试执行过程中执行的主要操作以及用于评价结果的方法。第54页/共58页完成标准规定完成标准的目的在于以下两方面：确定可接受的产品质量 确定测试工作成功实施的时间表述明确的完成标准应该包括以下内容：所测评的功能、行为或条件 测评方法标准或与测评的相符程度 第55页/共58页特殊的考虑事项本节应该确定所有会影响测试策略中所述测试工作的影响因素或依赖关系。这些影响因素可能包括：人力资源（如用来支持/参与测试的非测试资源的可用性或对这些资源的需要）约束（例如设备限制或可用性，或对特殊设备的需要/特殊设备的缺乏）特殊需求（例如测试时间安排或对系统的访问）第56页/共58页谢谢大家！谢谢大家！第57页/共58页感谢您的观看！第58页/共58页