软件测试基础.ppt_第1页
软件测试基础.ppt_第2页
软件测试基础.ppt_第3页
软件测试基础.ppt_第4页
软件测试基础.ppt_第5页
已阅读5页,还剩48页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、软件测试基础培训,张梅娜 2009年5月,主要内容,软件测试一些基本概念 软件测试的一般过程和流程介绍,一、测试基本概念,对软件测试的理解 软件测试的衡量标准 软件测试的原则 软件测试的分类 软件测试方法,基本概念对软件测试的理解(一),什么是软件测试 早期的软件定义 测试的目的是寻找错误,并尽最大可能找出最多的错误。 现在的观点 测试不仅仅是为了发现软件缺陷和错误,而且也是对软件质量进行度量和评估,以提高软件质量。,基本概念对软件测试的理解(二),软件测试的目的 以最少的时间和人力、物力找出软件中潜在的各种错误和缺陷 通过修正各种错误和缺陷提高软件质量,回避软件发布后由于潜在的软件缺陷和错误

2、造成的隐患所带来的商业风险。 对软件质量进行度量和评估 验证软件的质量满足用户需求的程度,为用户选择与接受软件提供有力的依据。 促进软件过程的改进 通过分析错误产生的原因和对测试结果的分析整理,发现软件开发过程中的缺陷,修正软件开发规则。,基本概念对软件测试的理解(三),什么是软件质量 在1999年,软件“产品评价”国际标准 ISO 14598 的“软件质量”定义是:软件特性的总和,软件满足规定或潜在用户需求的能力。 2001年,软件“产品质量”国际标准ISO 9126 中,软件质量包括“内部质量”、“外部质量”和“使用质量” 三部分。 外部质量和内部质量特性:功能性、可靠性、易用性、效率、维

3、护性、可移植性。 使用质量特性:有效性、生产率、安全性、满意度。,基本概念对软件测试的理解(四),软件测试与质量保证的区别 质量保证(QA) 通过在整个软件开发生命周期内进行预防、检查与改进来保证软件质量。 关注的是软件开发活动中的过程、步骤和产物,而不是对软件进行剖析找出问题或评估。 软件测试 保证软件质量的一个重要环节。 虽然与开发过程相关,但主要关注的是过程中的产物(文档、源码、程序等)进行分析:对文档和代码走查、运行软件找出问题、对发现的问题进行分析跟踪和回归测试、报告质量。,基本概念软件测试的衡量标准,多 能够找到尽可能多的、以至于所有的缺陷 快 能够尽可能早地发现最严重的BUG 好

4、 找到的BUG是关键的、用户最关心的 找到BUG后能够重现找到的BUG,并为修正BUG提供尽可能多的信息 省 能够用最少的时间、人力和资源发现BUG 测试的过程和数据可以重用,基本概念软件测试的原则,所有的测试都应追溯到需求 尽早地不断地进行软件测试 只检查程序是否做了它应该做的事仅仅完成了测试工作的一半,另一半则是要检查程序是否做了它不该做的事 一段程序中存在错误的概率与在这段程序中已发现的错误数成正比 尽量避免测试的随意性 完全测试是不可能的,测试需要终止 测试无法显示软件潜在的缺陷 。,基本概念测试完成准则,资源耗尽 采用的测试方法满足某种测试充分性要求 满足覆盖率等可度量的测试要求 一

5、段时期没有发现问题且所有发现问题均已解决 通过测试评估出软件达到要求的可靠度 测试发现频率和趋势达到预先计划的限度之下(限度根据要求、经验和历史数据得到) 在一段时期没有出现等级高的问题,基本概念软件测试的分类方法(一),按开发阶段划分: 单元测试(模块测试) 集成测试(模块组装测试) 确认测试 系统测试 验收测试,测试技术,不实际运行程序,而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态分析技术。,实际运行程序,并通过观察程序运行的实际结果来发现错误的软件测试技术。,在不知道程序内部结构,只知道程序规格的情况下采用的测试技术或策略。,在知道程序内部结构的情况下采用的

6、测试技术或策略。,开发组内部进行的,采用讲解、讨论和模拟运行的方式进行的查找错误的活动。,开发组内部进行的,采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,开发组、测试组和相关人员(QA、产品经理等)联合进行的,采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,针对要求的程序功能,按照规范的流程进行的测试。,针对要求的程序功能以外的其他要求,包括性能、安全、配置、负载等指标,按照规范的流程进行的测试。,针对要求的程序功能、性能、安全、配置、负载等指标,基于破坏目的、按照经验进行的随机测试。,程

7、序修改或者版本更新以后,为了确保以前正确的功能和其他指标仍旧正确,而重新进行的测试。,在测试过程中,选择足够的测试用例,使得每一个可执行语句至少被执行一次。,在测试过程中,选择足够的测试用例,使得程序中的每一个分支判断的每一种可能结果都至少被执行一次。,在测试过程中,选择足够的测试用例,使得程序中的每一条可能执行的路径都至少执行一次。,基本概念软件测试的分类方法(一),按开发阶段划分(一) 单元测试(模块测试) 检查每个程序单元是否正确实现详细设计说明书中的模块功能、性能、接口和设计约束等要求,发现模块内部可能存在的各种错误。 单元测试需要从程序内部结构出发设计测试用例。 多个模块可以平行地独

8、立进行单元测试。,基本概念软件测试的分类方法(一),按开发阶段划分(二) 集成测试(模块组装测试) 在单元测试的基础上,把所有的程序模块按照一定方式有序的、递增的测试。 集成测试检验单元或部件的接口关系,逐步集成为符合概要设计要求的程序部件或整个系统。 集成的过程是一个持续的过程,会形成很多临时版本,在不断的集成过程中,功能集成的稳定性是一个挑战。在每个版本提交时,都需要进行冒烟测试,即对程序的主要功能进行验证。 在集成测试过程中会进行多个回归测试,回归测试也就是在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件

9、版本上再次出现,基本概念软件测试的分类方法(一),按开发阶段划分(三) 确认测试 通过检验和提供客观依据(需求说明书),证实软件是否满足特定预期用途的需求。,基本概念软件测试的分类方法(一),按开发阶段划分(四) 系统测试 为验证和确认系统是否达到其原始目标,而对集成的硬件和软件系统进行的测试。 是在真实的或模拟系统运行的环境下,检查完整的程序系统是否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接,并满足用户需求。,基本概念软件测试的分类方法(一),按开发阶段划分(五) 验收测试 按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收或拒

10、收系统。,基本概念软件测试的分类方法(二),按照测试实施组织划分 开发方测试(通常也叫测试) 在软件开发环境下 用户测试(通常也叫测试) 在用户的应用环境下,由用户来使用、评价、反馈问题 第三方测试 介于软件开发方和用户方之间的测试组织的测试。,基本概念软件测试的分类方法(三),按测试技术划分(一) 静态测试 不运行程序,通过人工对程序和文档进行分析和检查。(代码复查、评审等) 动态测试 通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。,基本概念软件测试的分类方法(三),按测试技术和方法划分(二) 白盒测试(也叫结构测试) 通过对程序内部结构的分析、检测来寻找问题。 白

11、盒测试可以把程序看成装在透明的白盒子里,也就是清楚、了解程序结构和处理过程。 检查是否所有的结构及路径都是正确的 检查软件内部动作是否按照设计说明的规定正常进行。,基本概念软件测试的分类方法(三),按测试技术划分(二) 黑盒测试 通过软件的外部表现来发现其缺陷和错误 把测试对象看成一个黑盒子,完全不考虑程序的内部结构和处理过程 是在程序界面处进行测试 检查程序是否按照需求规格说明书的规定正常实现 灰盒测试 介于白盒测试和黑盒测试间的测试。,基本概念软件测试的分类方法(四),按测试的内容划分 功能测试、性能测试、压力测试、安全测试、可恢复性测试、兼容性测试、安装测试、文档测试等等。,基本概念软件

12、测试的分类方法(总结),软件测试方法和技术的分类与软件开发过程相关联,它贯穿了整个软件生命周期。 单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。 开发文档和源程序可以应用单元测试用复查的方法 单元测试应用白盒测试方法 集成测试应用近似灰盒测试方法 系统测试和确认测试应用黑盒测试方法,基本概念软件测试方法,什么是测试用例 将测试行为具体量化的一种方法(输入、操作、输出) 简单说,就是设计一个情况,软件在这种情况下,必须能够正常运行且达到程序所设计的执行结果 因为不可能进行穷举测试,为了节省时间和资源、提高测试效率,必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据

13、来进行测试。,基本概念软件测试方法,使用测试用例的好处 在开始实施测试前设计好测试用例,可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度,缩短项目周期。 功能模块的通用化和复用化使软件易于开发,而测试用例的通用化和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升。,基本概念软件测试方法,黑盒测试用例设计方法 等价类划分法 边界值分析 错误推测法 因果图、判定表、正交试验法 其他,基本概念软件测试方法,黑盒测试用例设计方法 等价类划分法(有效等价类、无效等价类) 把程

14、序的输入域划分为若干个部分,然后从每个部分中选取少数代表性数据作为测试用例。 每一类的代表性数据在测试中的作用等价于这一类中的其他值,基本概念软件测试方法,黑盒测试用例设计方法 边界值分析法 大量的错误发生在输入或输出范围的边界上。 次边界条件(内部边界条件)在文档里没有明确指出的。(如 数据库字段类型的取值范围) 其他一些边界条件(空值等),基本概念软件测试方法,黑盒测试用例设计方法 因果图、判定表、正交试验法 考虑到输入情况的各种组合和制约关系。,基本概念软件测试方法,白盒测试用例设计方法 代码检查法 代码复查 静态结构分析 使用测试工具分析程序源码的系统结构、生成相应的分析数据 逻辑覆盖

15、法 语句覆盖 判定覆盖(又称分支覆盖) 条件覆盖 判定-条件覆盖 路径覆盖 组合覆盖,基本概念软件测试方法,测试覆盖率 采用白盒法进行测试时,考虑的是测试用例对程序内部逻辑的覆盖程度。 最彻底的白盒法是覆盖程序中的每一条路径,但这往往大到无法实现。 因此采用其它一些标准来量度覆盖的程度,并希望覆盖程度尽可能高些。,基本概念软件测试方法,测试覆盖率方法 目前常用的一些覆盖方法从低到高分别是: 语句覆盖:是一个比较弱的测试方法,它的含义是:选择足够的测试用例,使得程序中每个语句至少都能被执行一次。 它是最弱的逻辑覆盖,效果有限,必须与其它方法交互使用。 判定覆盖(也称为分支覆盖):执行足够的测试用

16、例,使得程序中的每一个分支至少都通过一次。 判定覆盖只比语句覆盖稍强一些,但实际效果表明,只是判定覆盖,还不能保证一定能查出在判断的条件中存在的错误。因此,还需要更强的逻辑覆盖准则去检验判断内部条件。 条件覆盖:执行足够的测试用例,使程序中每个判断的每个条件的每个可能取值至少执行一次;条件覆盖深入到判定中的每个条件,但可能不能满足判定覆盖的要求,例题:,下图程序流程图,图中红色字母代表程序执行路径,语句覆盖测试用例设计:,如果此时A路径上的语句1T去掉,那么用例如下,语句覆盖是最起码的结构覆盖要求,语句覆盖要求设计足够多的测试用例,使得程序中每条语句至少被执行一次; 优点:可以很直观地从源代码

17、得到测试用例,无须细分每条判定表达式 缺点:由于这种测试方法仅仅针对程序逻辑中显式存在的语句,但对于隐藏的条件和可能到达的隐式逻辑分支,是无法测试的。在本例中去掉了语句1T去掉,那么就少了一条测试路径。在if结构中若源代码没有给出else后面的执行分支,那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行,而往往这种错误会经常出现。再如,在Do-While结构中,语句覆盖执行其中某一个条件分支。那么显然,语句覆盖对于多分支的逻辑运算是无法全面反映的,它只在乎运行一次,而不考虑其他情况,分支覆盖测试用例设计:,判定覆盖又称为分支覆盖,它要求设计足够多的测试用例,使得程序中

18、每个判定至少有一次为真值,有一次为假值,即:程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次 优点:判定覆盖比语句覆盖要多几乎一倍的测试路径,当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性,无须细分每个判定就可以得到测试用例。 缺点:往往大部分的判定语句是由多个逻辑条件组合而成(如,判定语句中包含AND、OR、CASE),若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径,条件覆盖测试用例设计:,条件覆盖要求设计足够多的测试用例,使得判定中的每个条件获得各种可能的结果,即每个条件至少有一次为真值,有一次为假值 优点:显然条件

19、覆盖比判定覆盖,增加了对符合判定情况的测试,增加了测试路径。 缺点:要达到条件覆盖,需要足够多的测试用例,但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真,而不考虑所有的判定结果,判定-条件覆盖测试用例设计:,设计足够多的测试用例,使得判定中每个条件的所有可能结果至少出现一次,每个判定本身所有可能结果也至少出现一次 优点:判定/条件覆盖满足判定覆盖准则和条件覆盖准则,弥补了二者的不足。 缺点:判定/条件覆盖准则的缺点是未考虑条件的组合情况,路径覆盖测试用例设计:,设计足够的测试用例,覆盖程序中所有可能的路径 优点:这种测试方法可以对程序进行彻底的测试,比前面五种的覆盖面都广

20、。 缺点:由于路径覆盖需要对所有可能的路径进行测试(包括循环、条件组合、分支选择等),那么需要设计大量、复杂的测试用例,使得工作量呈指数级增长。而在有些情况下,一些执行路径是不可能被执行的,如:If(!A)B+, If(!A)D-;这两个语句实际只包括了2条执行路径,即A为真或假时候对B和D的处理,真或假不可能都存在,而路径覆盖测试则认为是包含了真与假的4条执行路径。,组合覆盖测试用例设计:,要求设计足够多的测试用例,使得每个判定中条件结果的所有可能组合至少出现一次 优点:多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例,使得判定中每个条

21、件的所有可能结果至少出现一次,每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。 缺点:线性地增加了测试用例的数量,二、软件测试的一般过程和流程,软件测试的一般过程 软件测试工作的一般流程,软件测试的一般过程,软件测试的一般过程,规格定义,设计,编码,系统测试,集成测试,单元测试,用户需求,验收测试,回 归 测 试,配置管理,缺陷跟踪,软件测试的一般过程单元测试,目标: 检验程序最小单元有无错误 接口、数据结构、边界、覆盖、逻辑 检验单元编码与设计是否吻合 时机: 编码完成后,首先要实施的测试 方法: 静态测试 白盒测试 责任: 开发工程师,软件测试的一般过程集成测试,目标: 检验组成系统的模块接口有无错误 代码实现的系统设计与需求定义是否吻合 时机: 主要的单元测试完成后,经常与单元测试同步进行 方法: 黑盒测试(或灰盒测试) 责任: 开发工程师 测试工程师,软件测试的一般过程系统确认测试,目标: 检验组成整个系统的代码、以及

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论