软件测试第2章测试原理.ppt

《软件测试第2章测试原理.ppt》由会员分享，可在线阅读，更多相关《软件测试第2章测试原理.ppt（71页珍藏版）》请在三一文库上搜索。

1、第 2 章,软件测试原理,本章内容提要,测试原则 软件测试的分类 软件测试流程 软件测试的过程模型,2.1测试原则,两种测试原则,1所有的测试都应追溯到用户需求 2应当把“尽早测试和不断地进行软件测试”作为软件测试者的座右铭 3Pareto原则应用于软件测试 4测试应从“小规模”开始，逐步转向“大规模” 5穷举测试是不可能的 6为了达到最佳效果，应该由独立的第三方来构造测试 7不充分的测试是不负责任的，过分的测试是一种资源的浪费，同样也是一种不负责任的表现,测 试 原 则,软件测试的目标在于揭示缺陷和错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误，从而无法满足用户需求,

2、1所有的测试都应追溯到用户需求,不应该将软件测试看成是程序写完之后才开始的一项工作。问题发现得越早，解决问题的代价越小，反之，缺陷发现得越晚，缺陷修复的成本越高。若缺陷遗留到用户手中，则将对公司、对用户都有可能带来极其严重的后果。,2.把“尽早测试和不断地进行软件测试”作为座右铭,简单地讲，Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%，这就是缺陷群集现象。,3Pareto原则应用于软件测试,所谓小规模是指测试的粒度，或某种程序的单元测试。进一步的测试将从单个单元的测试逐步过渡到多个单元的组合测试，即集成测试，最终过渡到系统测试。,4测试应从“小规模”开始逐步转向

3、“大规模”,（1）每个输入条件的数据量太大，不同输入条件之间的组合情况太多 （2）从输出来看，输出结果太多 （3）数据的处理方式是常规的方法，然而由于要处理的数据量太大，每种数据类型所包含的有效和无效数据往往是无穷多的 （4）从计算来看，由于算法的复杂度越来越高，结合业务的复杂性，导致路径组合近似天文数字，遍历每条路径的穷举测试，即使对于一个非常熟练的测试员而言，也是不可能的,5穷举测试是不可能的,测试出口条件参考标准,遗留缺陷数量低于10个，其中严重的缺陷少于5个 测试用例的执行率为100%，通过率为95% 对于单元测试，关键模块的语句覆盖率为100%，判定覆盖率为85%,6为达到最佳效果，

4、应该由独立的第三方来构造测试,理 由,不愿否定自己的工作 受到思维定势的局限 受进度压力的影响 程序员对程序的功能和接口很熟悉，这与最终用户的情况往往并不吻合，开发人员自己来测试程序难以具有典型性,7.不充分的测试是不负责的，过分的测试是一种资源的浪费,测试级别,2.2 软件测试的分类,2.2 软件测试的分类,按测试阶段分类 按是否需要执行被测试软件分类 按是否需要查看代码分类 按测试执行时是否需要人工干预分类 其他测试类型,2.2.1 按测试阶段分类,单元测试,确认测试,系统测试,验收测试等,集成测试,定义 单元测试（Unit Testing）又称模块测试（Module Testing），是

5、指对软件中的最小可测试单元进行测试，目的是检查每个单元是否能够正确实现详细设计说明中的功能、性能、接口和设计约束等要求，发现各个模块内部可能存在的各种缺陷。 优点 减轻调试的难度 提供同时测试多个单元的可能,1.单元测试,集成测试（Integration Testing）又称组装测试， 是在单元测试的基础上，按照设计要求，将通过单元测试的单元组装成系统或子系统而进行的有序的测试，目的是检验不同程序单元或部件之间的接口关系是否符合概要设计的要求，能否正常运行。 确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试检测与证实软件是否满足软件需求说明书中规定的要求。,2.集

6、成测试,3.确认测试,系统测试（System Testing）是为了验证和确认系统 是否达到其原始目标，而对集成的硬件和软件系统进行的测试，是在真实或模拟系统运行的环境下，检查完整的程序系统是否能和系统正确配置、连接，并满足用户需求。 系统测试主要由黑盒测试工程师在整个系统集成好之后进行。前期主要看系统功能是否满足需求，这被称为功能测试。后期主要测试系统运行是否满足要求，以及系统在不同硬件和软件环境中的兼容性等，这被分别称为性能测试、兼容性测试、用户界面测试等。 系统测试的主要依据是软件的需求规格说明文档。,4.系统测试,定义 验收测试（Acceptance Testing）又称接受测试，是一

7、种正式的测试，是在系统测试后期，以用户测试为主，是一般由用户或其他权威机构来决定是否可以接受产品的验证性测试。验收测试是软件正式交付给用户使用的最后一个测试环节，并决定用户是否最终验收签字和结清所有应付款。 主要依据 软件需求规格说明文档和验收标准。 测试用例 可以直接采用内部测试组所设计的系统测试用例的子集，也可由验收人员自行设计。,5.验收测试,验 收 测 试,测试,测试也称开发方测试，开发 方通过检测和提供客观证据， 证明软件运行是否满足用户规 定的需求。,测试,测试是内部测试之后的外部 公开测试，是将软件完全交给 用户，让用户在实际使用环境 下进行的对产品预发布版本的 测试。,测试的优

8、势, 提升了产品价值。 可发现一些在测试实验室无法发现、甚至重复出现的缺陷。测试常常会发现产品的局限所在，并测试产品的整个开发过程。 可以将公司推到“基准框架”之外。 有助于产品的成功发布。,2.2.2 按是否执行被测软件分类,一、静态测试 二、动态测试,一、静态测试,定义 静态测试（Static Testing）又称静态分析（Static Analysis），是不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷。,静态测试,（1）对于源代码 主要是看代码是否符合相应的标准和规范，如可读性、可维护性等，其工作过程类似一个编译器，随着语法分析的进行做特定工作，如分析模块调用图、程序的控制

9、流图等图表，度量软件的代码质量等。 （2）对于程序界面 （3）对于文档 主要是检查用户手册与需求说明是否真正符合用户的实际要求。,1. 静态测试是采用走查、同行评审、会审等方法来查找错误或收集所需度量数据的。 2. 静态分析的查错和分析功能是其他方法所不能替代的，静态分析能发现文档中的问题（也只能通过静态测试发现），通过文档中的问题或其他软件评审发现来找出需求分析、软件设计等问题，而且能有效地检查代码是否具有可读性、可维护性，是否遵守编程规范。,main( ) int a10, i, j, tmp; for(i=0; i =10; i+) scanf(“%d“, ,无注释 书写格式不规范 tm

10、p变量未使用 数组下标越界使用,1:char *report(int m,int n,char *p) 2: 3: int result; 4: char *temp,*q=“null“; 5: long nm; 6: int i,k,kk; 7: char name12=“Joe Jakeson“; 8: nm=n*m; 9: temp=p=“?q:p; 10: for(i=0;i0) result=1; 17: else if(k0) result=-1; 18: if(m=result) return(temp); 19: else return(name); 20:,PC-LINT编译

11、出现的警告： 第9行的逻辑判定有问题 第12行的变量k没有初始化 第13行的kk未被使用 第18行的result有可能没有被初始化 第19行返回的是一个局部对象的地址,树状视图,定位违反编码规范的代码,使用LogiScope来检查代码的规范性：,使用LogiScope统计被测试程序的测试覆盖率：,用例覆盖率情况,使用LogiScope统计被测试程序的测试覆盖率：,各函数覆盖情况,以流程图形式显示覆盖情况,使用LogiScope查看某函数的覆盖情况：,二、动态测试,定义 动态测试（Dynamic Testing）又称动态分析（Dynamic Analysis），是指需要实际运行被测软件，通过观察

12、程序运行时所表现出来的状态、行为等发现软件缺陷，包括在程序运行时，通过有效的测试用例来分析被测程序的运行情况或进行跟踪对比，发现程序所表现的行为与设计规格或客户需求不一致的地方。,动态测试的局限性,往往需要借助测试用例来完成。即通过执行测试用例、分析测试用例来对被测软件重点考查，以期发现缺陷。相比静态测试，动态测试增加了测试用例的设计、执行和分析，以及由测试用例所带来的用例组织与管理等活动。 需要搭建软件特定的运行环境，增加了有关测试环境的配置、维护和管理的工作量。 不能发现文档问题，必须等程序代码完成后进行，发现问题相对迟得多。,三静态测试与动态测试的比较,静态测试与动态测试比较,（1）协同

13、性 静态测试是保守和健壮的，其测试结果离我们的期望值可能还有距离，但它保证了将来的执行。 动态测试是有效和精确的，它不需要花费大量的分析过程，尽管它确实需要测试用例的设计、执行和结果分析。动态测试给出了高度精确的结果。 （2）独立性 静态测试需要建立程序的状态模型（如函数调用图、控制流图等），在此基础上确定程序对该状态的反映（如通过各种图表分析，找出多入口多出口的模块、高层控制模块等）。因系统可能执行的状态有很多，测试必须跟踪多个不同的状态，通常经过大量细致的分析后也不一定能考虑到所有的系统状态。因此，静态分析通常采用程序状态的抽象模型，并需要较长时间的等待。 动态测试过程中不存在近似和抽象的

14、概念，它直接执行程序段，检查实时的行为，在控制流程路径中，几乎不存在不确定因素。,2.2.3 按是否需要查看代码分类,黑盒测试 白盒测试 灰盒测试,黑盒测试是将被测试软件看做一个黑盒子，只考虑系统的输入和输出，完全不考虑程序内部逻辑结构和处理过程。黑盒测试的依据是各阶段的规格说明书。 黑盒测试又称功能性测试（Functional Testing）或数据驱动测试（Data-driven Testing）。,黑 盒 测 试,黑盒测试,优点,局限性,黑盒测试用例与程序如何实现无关 测试用例的设计与程序的开发可以 并行进行。,输入条件多、组合复杂、数据量大， 不可能做到穷举测试。 因只选择部分输入构成

15、测试用例， 黑盒测试是很有可能存在漏洞的。,白盒测试是将黑盒子打开，研究源代码和程序内部的逻辑结构。白盒测试的依据是程序代码。 白盒测试又称结构性测试（Structural Testing）或逻辑驱动测试（Logic-driven Testing）。,白 盒 测 试,白盒测试,白盒测试可以利用不同的覆盖准则测试多个分支 白盒测试的覆盖指标可以充当黑盒测试的检查手段。例如，若采用黑盒方法设计的测试用例没有满足某些白盒测试覆盖指标（如判定覆盖）的要求，则证明该测试用例集合必然存在漏洞。 代码中常存在内存泄露的问题，尤其是C/C+程序，白盒测试可以方便地发现内存泄露的问题，且是直接定位缺陷，而黑盒测

16、试只能通过长时间运行程序，并仔细地检查用例执行结果，才能发现这类问题。,特 殊 的 应 用 领 域,白盒测试,无法穷举：程序中的逻辑路径太多， 常常要面对路径爆炸的问题。例如， 有的代码可能不到100行，却具有520条可能的路径，若每条路径设计一个测试用例，且每个测试用例执行一次需要1ms，则连续执行所有的测试用例大约需要3170年。 无法发现程序违反设计规范的地方，无法发现程序是否符合用户需求。,局 限 性,介于白盒测试和黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整。 灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特

17、定的系统知识和操作环境。,灰 盒 测 试,软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。走查、单元测试、集成测试、系统测试应用于整个开发过程中的不同阶段。开发文档和源程序可以应用单元测试应用走查的方法；单元测试可应用白盒测试方法；集成测试应用近似灰盒测试方法；而系统测试和确认测试应用黑盒测试方法。,2.2.4 按测试执行时是否 需要人工干预分类,手工测试 自动测试,手动测试,手动测试是完全由人工完 测试工作，包括测试计划 的制定，测试用例的设计 和执行，以及测试结果的 检查和分析等。传统的测 试工作都是由人工来完成 的。,自动测试,自动测试是使用自动化测试 工具或自动

18、化测试脚本来进 行的测试，包括测试脚本的 开发与执行等，以某种自动 测试工具来验证测试需求。 这类测试在执行过程中一般 不需要人干预，通常在功能 测试、回归测试和性能测试 中使用较为广泛。,自动测试,优点,能够产生出可靠的系统,改进测试工作质量,减少测试工作并缩短进度,2.2.5 其他测试类型,冒烟测试 随机测试,冒烟测试,定义 在测试中发现问题，找到了一个缺陷，然后开发人员会来修复这个缺陷。这时想知道这次修复是否真的解决了程序的缺陷，或者是否会对其他模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为冒烟测试。 优点是节省测试时间，防止创建失败；缺点是覆盖率还是比较低。 冒烟测试是自

19、由测试的一种。,随机测试,定义 根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程 主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊情况点、特殊的使用环境、并发性进行检查。尤其对以前测试发现的重大缺陷，进行再次测试，可以结合回归测试一起进行。,2.3 软件测试的流程,按生命周期和工作活动来分：,2.4,软件测试的过程模型,2.4.2 W 模型,2.4.1 V 模型,2.4.4 X 模型,2.4.3 H 模型,四种模型,2.4.1 V 模型, V模型是软件开发传统开发模型-

20、瀑布模型的变种，它反映了测试活动与分析和设计的关系，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程中各阶段的对应关系。,V模型,2.4.1 V 模型,2.4.1 V 模型,V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。,2.4.1 V 模型,V模型的软件测试策略,低层测试: 是为了源代码的正确性,高层测试:是为了使

21、整个系统满足用户的需求。,2.4.1 V 模型,局限性： V模型仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。,2.4.2 W 模型, 1W模型建立 V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。,2.4.2 W 模型, 2W模型应用 W模型是V模型自然而然的发展。它强调：测试伴随

22、着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。因此，相对于V模型，W模型更科学。,2.4.2 W 模型,2.4.2 W 模型,局限性： W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一阶段。这样就无法支持迭代、自发性以及变更调整。, 1H模型建立 在V模型和W模型中需求、设计、编码等一系列活动是串行的，而事实上，它们是可以交叉进行的。因此，相应的测试之间也不存在严格的

23、次序关系。同时，各层次间的测试也存在反复触发、迭代和增量关系。 为了解决以上问题，有专家提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。,2.4.3 H 模型,H模型,2.4.3 H 模型,2.4.3 H 模型,H模型揭示了：,软件测试不仅仅指测试的执行，还包括很多其他的活动；,软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。,软件测试要尽早准备，尽早执行；,软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行；,2.4.4 X 模型,X模型,2.4.4 X

24、模型,X模型提出探索性测试，即无事先计划的测试，只是随便测一下，这样有助于有经验的测试人员在计划外发现更多的软件缺陷。,本 章 小 结,1.介绍软件测试的一般原则、常见而重要的特殊测试类型、测试过程等内容。 2.试图从非技术的角度，以一个管理人的视角来看待软件测试。 3.主要目的是纠正对软件测试的一些误解，建立软件测试的思想，避免在实施软件测试的过程中犯低级错误。,习题,1,只要学会某种时下流行的自动化测试工具的使用， 就可以轻松搞定测试工作了吗？,4,自动化测试工具可以让繁重的手工劳动变得轻松， 那么，我们还有必要做手工测试吗？,3,良好的单元测试是否可以替代集成测试？,我们该如何应用各种测试过程模型,5,阐述测试的七大原则。,2,习题,6,从测试阶段和工作活动两方面简单阐述下软件测试的流程。,7,简单阐述W模型的优缺点及H模型的特点。,