软件测试专题 孙继荣 四川广播电视大学.

Presentation on theme: "软件测试专题 孙继荣 四川广播电视大学."— Presentation transcript:

1 软件测试专题 孙继荣 四川广播电视大学

2 软件测试的基本概念 软件可靠性的基本概念 软件测试与软件可靠性之间的关系 软件测试方法

3 软件测试的基本概念

4

5 作为计算机的灵魂,软件在其中起着举足轻重的作用。软件的失效有可能造成巨大的经济损失,甚至危及人的生命安全。例如,1996年Ａｒｉａｎｅ5运载火箭的发射失败等都是由软件故障引起的。
软件开发的各个阶段都需要人的参与。因为人的工作和通信都不可能完美无缺,出现错误是难免的。与此同时,随着计算机所控制的对象的复杂程度不断提高和软件功能的不断增强,软件的规模也在不断增大。例如,ＷｉｎｄｏｗｓＮＴ操作系统的代码大约有3200万行，这使得错误更可能发生。人们在软件的设计阶段所犯的错误是导致软件失效的主要原因。软件复杂性是产生软件缺陷的极其重要的根源。

6 软件失效引起的灾难实例

7 软件缺陷 软件缺陷这一概念用来描述各种软件错误，是所有软件错误的统称。 把符合下列5种特征之一的软件错误认为是软件缺陷：
软件缺陷这一概念用来描述各种软件错误，是所有软件错误的统称。    把符合下列5种特征之一的软件错误认为是软件缺陷： （1）软件未达到软件产品需求说明书中指明的要求； （2）软件出现了软件产品需求说明书中指明不会出现的错误； （3）软件功能超出了软件产品需求说明书中指明的范围； （4）软件未达到软件产品需求说明书中虽未指明但应达到的要求； （5）测试人员认为难以理解、不易使用、运行速度缓慢或者最终用户认为不好的问题。

8 软件测试的定义 软件测试是为了发现错误而运行程序的过程。
（1979，Glenford J.Myers《the art of the software tesing 》） 测试是使用人工的或自动的手段来运行或检测某个系统的过程，其目的是在于检验它是否满足约定的需求是比较预期结果与实际结果之间的差别。（1983，IEEE提出的软件工程标准术语给软件测试下的定义） 软件测试是软件开发过程中的一个阶段，是软件开发的重要组成部分。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。目的是为了发现错误。

9 软件测试的目标 测试的目标是以最少的时间和人力找出软件中潜在的各种错误和缺陷。如果成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。 (1)测试是程序的执行过程，目的在于发现错误； (2)一个好的测试用例在于能发现至今未发现的错误； (3)一个成功的测试是发现了至今未发现的错误的测试。

10 软件总是会出错的，而且会出现在软件开发的各个阶段。有统计表明，各种软件错误的出现比例如下：
①功能错。占整个软件错误57％，是需求分析设计不完整而引起的。 ②系统错。占整个软件错误26％，是总体设计错误而引起的。 ③数据错或编码错。占整个软件错以10％，是程序员编码错误引起的。 ④测试错误。占整个软件错误4％，是测试设计错误引起的。 ⑤其他错。占整个软件错误3％，由文档错和硬件错所引起的。

11 软件测试的原则 提早原则：应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
IPO原则：测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。 独立测试原则：程序员应避免检查自己的程序 回归测试原则：妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 错误不可避免原则 …

12 软件测试的对象 软件测试应贯穿于软件定义与开发的整个期间。
需求分析、概要设计、详细设计以及编码等各阶段所得到的文档，包括需求规格说明、概要设计说明、详细设计说明以及源程序，都应该是软件测试的对象。

13 软件测试的重要性 软件质量越来越受重视，而软件测试是保证软件质量的重要手段。
据统计，约60%的错误来自设计阶段以前，并且休整一个软件的错误所需要的费用随着软件生存周期的进展而上升。

14 确认和验证（1） 为了把握各个环节的正确性，人们需要进行各种工作确认和验证。
确认(Validation)是一系列的活动和过程，其目的是想证实在一个给定的外部环境中软件的逻辑正确性。软件确认是广义上的软件测试，它是企图证明程序软件在给定的外部外境中的逻辑正确性的一系列活动和过程，指需求说明书的确认、程序的确认。 验证(Verification)则试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。 确认与验证工作都属于软件测试。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节上发生了问题都可能在软件测试中表现出来。

15 确认和验证（2） 程序确认分静态确认与动态确认。静态分析是不执行程序本身，分析程序正文可能出现错误的异常情况。静态分析包括结构检查、流图分析、符号执行。动态分析是执行被测程序，从执行结果分析程序可能出现的错误，可以人工设计程序测试用例。动态测试包括功能测试和结构测试。

16 测试信息流 测试过程需要三类输入 (1)软件配置：包括软件需求规格说明、软件设计规格说明、源代码等；
(2)测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。 (3)测试工具：为提高软件测试效率，可使用测试工具支持测试工作，其作用就是为测试的实施提供某种服务，以减轻人们完成测试任务中的手工劳动。

17

18 测试与软件开发各阶段的关系 测试过程是依自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。当然不排除两者平行地进行测试。
软件工程范围内的测试按照测试步骤分为： 单元测试 组装测试 确认测试 系统测试。

19 ①单元测试又称模块测试，是针对软件设计的最小单位——程序模块的，以详细设计为指南的正确性检验的测试工作，其目的在于发现各模块内部可能存在的各种错误。此阶段大多采用白盒测试。

20 单元测试包括如下内容： 模块接口测试。对通过被测模块的数据流进行测试。对模块接口，包括参数表、调用子模块的参数、全程数据、文件输入/输出操作都必须检查。 局部数据结构测试。设计测试用例捡查数据类型说明、初始化、缺省值等方面问题，还要查清全程数据对模块的影响。 路径测试。 错误处理测试。 边界测试

21 ②组装测试 组装测试也叫做集成测试或联合测试。 组装测试是用于装配软件的一种系统化的技术，要在软件装配的同时进行测试。用以发现与接口联系的问题，目的是将经过单元测试的模块构成一个符合设计要求的软件系统。一般采用白盒测试与黑盒测试相结合的方法.

22 ③确认测试 在组装测试之后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误已经发现并纠正。这时可以对软件进行最后的测试，确认测试。 确认测试的任务是，验证软件的功能和性能及其他特性是否与用户的要求一致。 通常采用黑盒测试。

23

24 ④系统测试 软件只是计算机系统的一个元素，软件最终要与计算机系统的其他元素（如硬件、 外设、某些支持软件、数据和人员等）相结合。系统测试是把通过确认测试的软件作为整个计算机系统的一个元素与其他元素结合在一起在实际运行（使用）环境下对计算机系统进行一系列的组装测试和确认测试。通常采用黑盒测试。

25 软件测试各阶段与生存周期各阶段的对应关系
决定软件与系统的配合关系 系统测试 需求分析 确认测试 概要设计 集成测试 详细设计 单元测试 编码 软件测试各阶段与生存周期各阶段的对应关系

26 软件可靠性

27 问题的提出 　　 随着计算机和信息处理的广泛应用,计算机系统的可靠性问题越来越得到人们的关注。而软件体系规模的日益增大及其复杂性的日益增强,使软件的可靠性问题更为突出。据有关资料统计,软件故障占整个计算机系统故障的65%,为此,美国曾提出“使计算机在200年平均时间中连续不中断和一次修复只需一分钟”的目标,还提出“高可靠性计算机是21世纪计算机发展的主要方向之一” 。要达到这一目标,其首要问题就是提高软件质量。在软件质量指标体系中,可靠性是其最重要的固有特性,这就要求我们将软件可靠性问题在软件工程领域乃至整个计算机工程领域中进一步考虑和重视。另一方面,在预测或计算系统可靠性时,不考虑软件系统可靠性所得出的系统可靠性,其结果往往和实际情况相差甚远。因此,研究软件可靠性已成为计算机学科探讨的一个重要方向。

28 可靠性表示人们可指望系统完成所期望功能的这样一些特质,可靠性包含很多因素,如成熟性、容错性及易恢复性等
可靠性表示人们可指望系统完成所期望功能的这样一些特质,可靠性包含很多因素,如成熟性、容错性及易恢复性等.这些特质是软件工程各子学科所共同关心的问题,这些子学科包括需求工程、软件再工程、信息安全、可靠性工程等.在这些领域中的一个重要因素就是软件工业的多样性,或者说有众多不同的工业部门在生产或使用不同的计算机软件.各工业部门对软件的可靠性要求各不相同,所以控制软件可靠性和可用性的手段方法也不会完全相同.

29 软件可靠性源于传统工业的硬件可靠性,由于软件的抽象性及高度复杂性等特点,软件可靠性与传统硬件可靠性又有本质上的区别
软件可靠性源于传统工业的硬件可靠性,由于软件的抽象性及高度复杂性等特点,软件可靠性与传统硬件可靠性又有本质上的区别.软件可靠性研究方兴未艾,自1973年ＩＥＥＥ软件可靠性年会召开以后,软件可靠性成为ＩＥＥＥ、ＡＣＭ、ＡＩＡＡ、ＭＲＩ及其他学术、工业和政府部门的主要研究题目之一,而美国、英国在该领域的研究尤其活跃。 与国外相比,国内软件可靠性研究机构比较零散,力量相对薄弱.

30 什么是软件可靠性 自60年代末期开始定量研究软件可靠性以来,人们提出了许多软件可靠性的定义、数学模型和方法,但至今还没有一致的观点。由于完全测试不可能,而且测试环境与软件使用环境总存在差别,所以完全可靠的软件是不存在的,十分准确地评估软件可靠性也是困难的。

31 什么是软件可靠性 多数人承认并且比较容易理解的可靠性定义是:软件在给定的时间间隔及给定的环境条件下,按设计要求,成功地运行程序的概率。
(1)环境条件:软件的使用环境。 (2)规定的时间:软件的可靠性体现于软件的运行阶段,因此,在软件可靠性的定义中,一般采用“运行时间”t作为时间的度量。 (3)规定的功能:在考虑软件的可靠性时,首先应明确软件的功能是什么,哪些功能是主要的,哪些功能是次要的。由于功能不同,失效带来的损失就不一样,因此,要明确哪些失效是致命的,哪些失效是非致命的,哪些又是容易修复的, (4)成功地运行程序:这里的“成功地运行”是指不仅程序能正确地运行,满足用户对它的功能要求,而且当程序一旦受到意外的伤害或系统错误时,能尽快恢复,仍能正常地运行。

32 软件可靠性的特点 (1)软件错误主要是由设计错误造成的,使用和维护对软件可靠性的影响不大。 (2)软件错误不随使用时间的延长而增加。
　软件可靠性的特点 (1)软件错误主要是由设计错误造成的,使用和维护对软件可靠性的影响不大。 (2)软件错误不随使用时间的延长而增加。 (3)软件修理就是通过再设计排除原有错误。 (4)软件可靠性增长与软件使用的时间无关,与检测并改正错误的努力有关。 (5)软件寿命期内无老化与耗损现象。 (6)正确的软件不因使用环境的变化而改变其正确性。 (7)同一软件的冗余技术不能提高软件的可靠性。 (8)采用高可靠性的标准件──系统软件所提供的各种库函数,未必能提高整体软件的可靠性。

33 软件可靠性研究的主要内容 首先要搞清楚软件为什么会出现故障或失效,这样,才能在软件开发过程中尽可能避免导致软件失效的原因,从而开发出高质量的软件。 其次,为了保障软件的高可靠性,在软件的设计、开发、研制中应遵从什么规范要求也是软件可靠性研究的一个重要方面。 第三,对于已开发的软件如何检验它是否满足可靠性要求,这便涉及到软件可靠性数据的收集、处理、软件测试、软件可靠性模型的建立、软件可靠性的预测等问题的研究。 最后,从软件工程经济学的观点出发,考虑软件的可靠性与软件的测试、维护、管理费用之间的权衡问题,也是软件可靠性研究的一项内容。

34 如何定量检验软件可靠性 　　在软件开发过程中,软件的测试和修改是一个不断反复的过程.什么时候软件达到了要求的可靠性水平从而能够投入使用是一个关键问题.过早地将软件投入使用,可能造成重大事故及损失.而测试到了一定阶段后,软件可靠性增长缓慢,继续进行测试将是无谓的活动,浪费人力、财力,对于商业软件来说,影响其进入市场的时机,从而造成损失;甚至不能补偿开发成本.从这方面讲,定量地评估软件当前的可靠性、预计将来的可靠性显得尤为重要。

35 定量检验软件可靠性的最直接方法是软件投入运行后在实际运行环境中检验软件失效情况。但这种方法的缺点在于:一是它要求软件运行时间较长;二是人们难于希望在软件开发阶段结束之前能估计或预测软件可靠性,以检验它是否达到期望的目标。

36 软件可靠性的主要指标（1） 软件可靠性的定量指标,是指能够以数字概念来描述可靠性的数学表达式中所使用的度量。
①软件修复:软件修复指排除软件代码中的错误。软件的修复工作能够降低系统故障率,提高系统的可靠性。软件修复时间是一个随机变量,为了简单,经常使用平均修复时间的概念。

37 软件可靠性的主要指标（2） ②软件有效性：关于可修复系统可使用能力的一般概念。它综合反映了软件的可靠性和可修复性所能达到的水平。它可理解为在任意时刻使用软件时,该系统在这一时刻的可用能力,所以也把有效性称为可用性。通常用有效性函数来表示系统有效性。有效性函数A(t)定义为系统在时刻t正常运行的概率。软件系统投入运行后,在某一段时间内,可以用大量的、复杂的输入数据引发程序中残留的错误,程序经多次修复后,错误逐渐减少甚至消除,程序的有效性不断提高。

38 软件可靠性的主要指标（3） ③MTTF(平均失效等待时间)与MTBF(平均失效间隔时间)：
设对n个相同系统进行测试,失效时间分别为t1,t2…,则平均失效等待时间MTTF定义为:各失效时间之和的平均数。MTTF是一个描述失效模型或一组失效特性的指标量。在运行阶段,可把失效率函数λ(t)视为常数λ,则平均失效等待时间MTTF就是失效率λ的倒数:MTTF=1/λ。平均失效间隔时间MTBF是指两次相继失效之间的平均时间。MTBF在实际使用时通常是指当n很大时,系统内第n次失效与第n+1次失效之间的平均时间。

39 软件可靠性的主要指标（4） ④到任一时刻t发生的软件失效累计次数N(t)服从均值Ｐｏｉｓｓｏｎ分布, 使得微小时间段(ｔ,ｔ+Δｔ)内软件失效发生次数与ｔ时刻软件残留缺陷数成正比。(每一缺陷有均等机会被检测发现,且等级相同)

40 软件可靠性模型 由于完全测试不可能,而且测试环境与软件使用环境总存在差别,所以完全可靠的软件是不存在的,十分准确地评估软件可靠性也是困难的。人们利用各种方法评估和预测软件可靠性,迄今为止所建立的软件可靠性模型已不下百余种,然而,由于各模型的假设或多或少的与实际情况不符,使得模型的应用受到限制。 总的说来国内与国外在软件可靠性研究与应用方面还存在一定差距。即使在国际上,软件可靠性研究也未达到满足实际可靠性管理应用需求的水平。

41 为此有两种相互补充的补救方法: 一是在软件测试阶段对测试过程中收集到的软件可靠性(失效)数据用模型来估计软件可靠性实际水平,从而从可靠性角度判断软件何时可停止测试交付用户验收使用。在软件测试阶段被发现的软件缺陷不断被剔除,软件可靠性呈增长趋势。因此,这一方法称为软件可靠性增长建模,主要由软件开发人员实现。迄今为止,软件可靠性增长建模是软件可靠性研究的主要内容。 另一种方法是在软件验收阶段,在用户参与下对软件进行测试,以检验其是否满足可靠性要求,而在测试过程中暂不剔除被发现的缺陷。这种方法同样需要建模,但更突出测试方法的重要性,因此称之为软件可靠性测试。

42 软件可靠性模型 一个软件可靠性模型通常(但不是绝对)有以下几个部分组成:
①模型假设。模型是实际情况的简化或规范化,总是包含若干与实际情况基本相符的假设,譬如测试用例的选取代表实际运行剖面,不同软件失效独立发生等等。 ②性能度量。软件可靠性模型的输出量便为性能度量,如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。 ③参数估计方法。某些可靠性度量的实际值无法直接获得,譬如残留缺陷数,这时需通过一定的方法估计参数的值。从而间接确定可靠性度量的值。当然,对于可直接获得实际值的可靠性度量,便无需参数估计了。 ④数据要求。一个软件可靠性模型要求一定的输入数据,即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。

43 软件可靠性模型 模型假设 纵观迄今发表的数十种模型,可以发现绝大多数模型包含下列三个共同假设。这些假设至今主宰着软件可靠性建模的研究发展,人们尚未找到克服这些假设局限性的有效方法。 ①代表性假设。此假设认为软件测试用例的选取代表软件实际的运行剖面,甚至认为测试用例是独立随机地选取。此假设实质上是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。 ②独立性假设。此假设认为软件失效是发生于不同时刻,一个软件失效的发生不影响另一个软件失效的发生。 ③相同性假设。此假设认为所有软件失效的后果(等级)相同,即建模过程只考虑软件失效的具体发生时刻,不区分软件失效的性质。

44 软件可靠性模型 有两种最常用的方法来分析软件可靠性 ⑴基于软件规模、结构及复杂度的模型： ⑵基于软件失效时间的模型:
如Ｈａｌｓｔｅａｄ模型、Ｍｉｌｌｓ模型等,它们更多地应该归为软件质量模型一类,对软件可靠性的预计能力有限. ⑵基于软件失效时间的模型: 1972年Ｊｅｌｉｎｓｋｙ和Ｍｏｒａｎｄａ提出Ｊ-Ｍ模型 1973年Ｌｉｔｔｌｅｗｏｏｄ和Ｖｅｒａｌｌ提出Ｌ-Ｖ模型 1978年Ｇｏｅｌ和Ｏｋｕｍｏｔｏ提出Ｇ-ＯＮＨＰＰ模型 上述3个模型形成软件可靠性理论研究的骨架. 另外还有Ｍｕｓａ的执行时间模型等

45 对软件可靠性的错误理解 1)软件系统中若出现错误越多,软件可靠性就越低
问题(1)的解答:从定义可知,可靠性与错误发生的概率有关,即使是致命的错误,若不是经常发生,或永远不发生,那么它就不会影响软件可靠性,但致命的错误即使是发生一次,便有可能使系统瘫痪。故可知,可靠性不仅仅是由数量来决定的,而是由致命错误发生概率来衡量的。

46 对软件可靠性的错误理解 2)一个可靠的软件系统就是不发生错误
问题(2)的解答:一个可靠性的软件系统并不是不发生错误。在现实的生活中,要完全避免错误是不可能的。软件可靠性表明了一个程序按照用户的要求和设计的目标,执行其功能的正确程度。这要求一个可靠的程序应是正确的、完整的、一致的和健壮的,并尽可能排除致命的错误。

47 软件可靠性研究存在的主要问题 (1)观点、方法和工具问题。目前的研究主要是建立在概率论和数理统计基础上,这并不总是恰当的。软件可靠性理论和技术还有待大的发展,需要有新的数学工具,如模式识别、人工智能、ＰＥＴＲＩ网等。KhoshgoftaarＴ.Ｍ,根据软件可靠性数据,将知识发现与90年代兴起的数据挖掘技术应用于软件故障数预测中,取得了较好的效果。

48 软件可靠性研究存在的主要问题 (2)软件可靠性模型问题。虽然目前已建立了数百种软件可靠性模型,但均具有一定的局限性,因此,从软件可靠性模型的假设是否合理、实际应用是否简单方便、适用范围是否广泛等问题出发,如何进一步建立合理、实用的软件可靠性模型还有待于进一步研究。

49 软件可靠性研究存在的主要问题 (3)软件可靠性模型的应用问题。各类软件可靠性模型,特别是软件可靠性增长模型,模型预测的不一致仍然是一个有待于解决的问题。另外,如何将软件可靠性模型有效地应用于实际的软件开发、评价、管理中也是当前需进一步探讨的问题。

50 软件可靠性研究存在的主要问题 (4)数据问题。软件数据的收集是一项艰巨又繁琐的工作,到目前为止,尚未建立起用于测试软件可靠性模型,证明它们的估计精度、可用性以及模型与模型之间差别的数据库,因此,软件失效数据库的建立及软件失效数据的自动收集都是当前迫切需要解决的一个问题。

51 软件可靠性研究存在的主要问题 (5)软件测试用例的自动生成问题。现有的软件测试用例生成方法缺乏形式化方式,因此各种软件测试工具中测试用例的自动生成工具还有待于进一步开发和完善。

52 软件可靠性研究存在的主要问题 (6)硬-软件混合系统可靠性问题。计算机系统中硬、软件故障产生的方式截然不同,故硬、软件可靠性不完全一致,同时考虑到人的可靠性,目前虽然已建立了一些硬-软件可靠性模型，但这些模型都是针对一些具体的问题提出的,其侧重点各不相同,因而模型的问题还很多。

53 软件测试 与 软件可靠性

54 软件测试与软件可靠性 软件测试的目的是发现软件错误,排除软件缺陷,提高软件可靠性.
设Ｍ是给定的测试方法,Ｔ是在Ｍ下的测试时间,在Ｍ测试下,ｔ0(=0),ｔ1,ｔ2,…,tｎ-1,ｔｎ(=Ｔ)是软件发生错误的ｎ个时刻,按传统的可靠性理论,则可以建立多种软件可靠性模型。

55 软件测试与软件可靠性 由于软件测试的复杂性,目前随机测试是评估软件可靠性的重要测试方法.在随机测试下,评估软件可靠性有以下两种情况需要考虑.
(1)当测试时间为Ｔ时,共检测了ｎ个故障,此时　 (2)在Ｔ时间内没有发现任何错误,此时,可以认为 ＭＴＢＦ≥Ｔ

56 软件可靠性测试 软件可靠性测试是指为了保证和验证软件的可靠性要求而对软件进行的测试,其主要特征是按照用户实际使用软件的方式来测试软件。为了满足用户对软件的可靠性要求、评价软件可靠性水平及验证软件产品是否达到可靠性要求,软件可靠性测试是一个最有效的途径。

57 软件可靠性测试与软件正确性测试 软件可靠性测试是一种面向使用的测试。程序存在错误是必然的,然而是不是需要将所有的错误都找出来,答案是否定的,测试的时间、人力、物力都是有限的,如何将有限的测试资源更有效地用于测试,人们提出了基于可靠性的测试,即针对用户使用得多的、易出错的功能就多测,集中力量先发现对可靠性影响大的错误。这样就意味着多发现错误并不是软件可靠性测试的目的,多发现对可靠性影响大的错误才是可靠性测试的目的和出发点。

58 软件可靠性测试的分类 按照测试目的的不同,软件可靠性测试分为软件可靠性验证测试和软件可靠性增长测试。
软件可靠性验证测试的目的是验证软件的可靠性要求,即通过对软件进行测试,获得其真实的可靠性水平,在验证测试过程中不需要对错误进行改正。因此,软件可靠性验证测试充分意味着随机抽样产生的测试数据集合完全反映了用户使用软件的统计特征,从而使得利用这些数据估计出来的可靠性水平反映了软件真实的可靠性水平。 软件可靠性增长测试的目的是通过不断地发现错误,加以改正,使得软件的可靠性水平不断增长,达到可靠性要求,这意味着充分的软件可靠性测试应该保障测试后的软件具有满足要求的可靠性。

59

60 软件可靠性测试技术作为提高软件质量和软件可靠性的重要手段,正成为国内外软件可靠性工程的主要研究方向。如何通过软件可靠性测试,及早暴露出实际使用过程中高发生概率的软件缺陷,是亟待突破的技术难关。
软件可靠性测试是按照用户实际使用软件的方式来测试软件,软件的运行剖面(ＯｐｅｒａｔｉｏｎａｌＰｒｏｆｉｌｅ)是定量描述用户实际使用软件方式的有力工具,也是软件可靠性测试最主要的特征。

61 软件可靠性测试从概念上讲采用的是黑盒测试方法,因为它是面向需求、面向使用的测试,它不需要了解程序的结构以及如何实现等问题,测试数据的生成和可靠性估计与测试中软件如何运行没有任何明确的关系。
这种明确关系的缺乏,是我们反对用单纯的“黑盒测试”方法估计软件可靠性的出发点。而且,这种传统作法生成的测试数据中,很多是对程序结构的重复执行,使得某些结构测试的密度高,某些结构测试的密度低,带来了许多无用的测试代价。大量的测试数据需要花费大量的人力、物力和财力,在交货期限紧张的情况下,往往不能满足,导致获得的可靠性估计值是不可信的。因此,需要结合“白盒测试”的信息,作为衡量测试质量和控制测试进程的手段。

62 软件测试方法

63 软件测试是保证软件质量和可靠性的重要手段。目前许多项目的软件工程实践以结构化分析和设计为核心,在开发阶段的前期,包括需求分析和设计都是以技术评审和工程管理作为质量保证的手段,而技术评审和工程管理主观因素很大,很可能又引入错误并扩展到后续开发阶段。 另一方面,软件测试确实能够发现软件中隐藏的许多缺陷。例如,在英国约克大学为英国海军开发的Sholis项目中,尽管采用形式化方法描述和证明软件规约,并且采用程序正确性证明方法排除了软件开发前期的许多缺陷,单元测试仍然发现了整个软件开发过程15.75%的缺陷。随着人们对软件测试重要性的认识越来越深刻,软件测试阶段在整个软件开发周期中所占的比重日益增大。现在有些软件开发机构将研制力量的40%以上投入到软件测试之中;对于某些性命攸关的软件,其测试费用甚至高达所有其他软件工程阶段费用总和的3到5倍。 程序代码最终体现了软件的质量,无论是从软件开发方法学还是软件测试自身的效益看,软件测试在今后较长时间内仍将是保证软件质量的重要手段。

64 对于安全性软件,软件的错误是往往由于软件需求的不确定性、软件设计的缺陷或编程失误所造成的,测试用例的设计与选择决定了是否能找出软件存在的错误
对于安全性软件,软件的错误是往往由于软件需求的不确定性、软件设计的缺陷或编程失误所造成的,测试用例的设计与选择决定了是否能找出软件存在的错误.因此为了保证软件的可靠性,软件测试既强调按实际使用软件的概率分布,随机或有目的地选择输入数据;又强调数据信息的合法使用,防止数据信息的非法泄露、修改与通过安全漏洞合法使用数据.这使得这些软件测试的用例与一般测试不同.其测试既要按照使用的概率分布选择测试用例,又要根据安全需求构造测试实例.这样才能得到比较准确的可靠性估计,便于查出软件的错误.

65 软件测试在整个软件开发周期所占的比重很大。据统计,在所有的软件测试的开销中,约40%花费在设计测试用例上,约50%花费在编写和编译测试脚本上,另外约10%花费在测试脚本的执行和配置管理上。

66 测试用例 测试用例（Test case）实际上是对软件运行过程中所有可能存在的目标、运动、行动、环境和结果的描述，是对客观世界的一种抽象。设计测试用例即设计针对特定功能或组合功能的测试方案，并编写成文档。测试用例应该体现软件工程的思想和原则。测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。因为测试的目的是暴露应用软件中隐藏的缺陷，所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据，结合复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。

67 软件测试的基本思想 ⑴软件测试的技术与过程 ⑵持续的软件测试 ⑶软件测试的充分性准则

68 ⑴软件测试的技术与过程 现有的软件测试技术通常分为静态测试和动态测试。
静态测试是不执行程序代码而寻找程序代码中可能存在的缺陷或评估程序代码的过程。静态测试包括主要由人工进行的代码审查、代码走查、桌面检查以及主要由软件工具自动进行的静态分析。如果广义地理解,静态测试还包括软件需求分析和设计阶段的技术评审。 动态测试通过在抽样测试数据上运行程序来检验程序的动态行为和运行结果以发现缺陷。动态测试包括生成测试用例、运行程序和验证程序的运行结果3部分核心内容,以及文档编制、数据管理、操作规程及工具应用等辅助性工作。动态测试最重要的问题是生成测试用例的策略。它是动态测试有效、高效的关键。测试用例包括输入数据和期望结果。

69 软件测试技术的分类

70 黑盒测试 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫做功能测试或数据驱动测试。黑盒测试可以发现以下类型的错误： 功能错误或遗漏 界面错误 数据结构或外部数据库访问错误 性能错误 初始化或终止错误

71 白盒测试 软件的白盒测试是对软件的过程性细节做细致的检查。这一方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

72 白盒测试 白盒测试密切关注处理细节，针对程序的每一条逻辑路径分别设计测试用例，检查分支和循环情况。路径测试是白盒测试方法中的一种，即设计足够的测试用例，覆盖程序中所有可能的路径。路径测试是白盒测试中最强的覆盖准则，是最常用的白盒测试方法。但是，在路径数目很大时，路径测试要做到完全覆盖所有路径很困难，所以必须将覆盖路径数目压缩到一定限度，力争用尽可能少的测试发现尽可能多的错误，以保证软件的可靠性．

73 灰盒测试 显然,这两类测试方法是从完全不同的角度出发对软件进行测试。实践证明,两类方法各有侧重,在测试的实践中都是有效和实用的,不能指望一类方法能够完全代替另一类方法。但显然二者又各具缺点,这些缺点不是通过在各自的测试方法内部进行完善就能够解决的。只有通过将二者有效地结合,即进行所谓的“灰盒测试”,才能弥补任何一种方法的不足,使测试方法的机理更完善。

74 测试用例集价值 所有为了满足某个测试准则而设计的测试用例在一起形成了测试用例集合。要进行测试用例集合价值的度量，首先必须分析决定和影响测试用例集合价值的关键要素。软件工程实践表明软件越复杂的地方隐藏故障的概率就越高，测试必须给予这些部分以更多的重视，因此软件复杂性是测试用例集合价值模型的重要因素。同时，测试用例集合的执行结果也是重要的因素。

75 测试用例集约简 在软件测试过程中，穷尽测试既不可能，也没必要。测试数据生成是软件测试的核心与关键，但是不同测试数据对发现软件故障的能力差别很大。为了节约时间和资源，提高测试效率，测试用例集约简技术就是从大量的输入数据中精心挑选出少数有代表性的测试数据，使得采用这些测试数据能够达到最佳的测试效果，高效地把隐藏的故障揭露出来，是软件测试研究中的关键课题。目前，对于测试用例集约简技术的研究主要集中在两个方面： 基于组合覆盖的测试用例集生成和约简技术的研究 基于测试需求的测试用例集约简技术的研究

76 ⑵持续的软件测试 软件测试是保障软件质量的重要手段,但它不是万能的,不能取代其他软件质量保障手段。完整的软件质量保障活动应该贯穿整个软件生存周期,包括评审、检查、审查、设计方法学和开发环境、文档编制、标准、规范、约定及度量、培训、管理等。软件质量需要综合运用包括软件测试在内的诸多手段才能得到最有力的保障。 完整的软件测试工作也应该贯穿整个软件生存周期,它有两方面的含义:(1)软件开发不同阶段都有软件测试工作;(2)软件测试工作的各个步骤分布在整个软件生存周期中。

77 软件测试各阶段工作在软件生存周期中的分布情况

78 上表描述了软件测试各阶段工作在软件生存周期中的分布情况。按照软件测试流程,将软件测试工作划分为计划(指进行测试计划)、设计(指进行测试设计)和执行(含评价,指执行测试并判别结果、评价测试效果和被测试软件)几个阶段。上表表明软件测试工作连续不断地在软件开发过程中进行。这体现了软件测试的一个原则:尽早开始软件测试工作,不断进行软件测试工作。

79 软件测试过程框架

80 ⑶软件测试的充分性准则 Ｇｏｏｄｅｎｏｕｇｈ和Ｇｅｒｈａｒｔ于1975年在研究软件测试能否保证软件的正确性时提出软件测试充分性的概念。软件测试的充分性是根据被测软件在有限多个测试数据上的行为判断在所有测试数据上的行为的逻辑基础。其度量充分度是充分程度的定量表示,也是测试执行程度的定量描述。

81 ⑶软件测试的充分性准则 　　 测试充分性准则是判定测试数据集对于被测程序是否充分的准则。如果测试数据集不充分,就必须增加更多的测试数据,否则可以结束当前测试工作。在文献中,有许多软件测试的充分性准则,以及对充分性准则的研究。良好的软件测试充分性准则应该具有如下基本性质:空集不充分性、有限性、单调性、非复合性、非分解性、非外延性、一般多重修改性、复杂性、回报递减律。

82 ⑶软件测试的充分性准则 20世纪80年代中期,提出了充分性准则满足的11条公理。目前,通常用测试覆盖准则度量测试充分性。到目前为止,已经提出许多针对程序内部结构的测试覆盖准则,主要包括控制流测试覆盖准则和数据流测试覆盖准则。控制流测试覆盖准则包括语句覆盖、分支覆盖、条件覆盖、判定 条件覆盖、路径覆盖等。数据流测试覆盖准则包括定值覆盖、引用覆盖、定值 引用覆盖等准则。这些准则不仅可以定量地规定软件测试需求,指导测试数据的选择,而且可以度量测试数据集揭示软件特定特征的能力,对测试结果和软件可靠性评估具有重要影响。

83 软件测试中的若干问题 ⑴面向路径的测试数据的自动生成 ⑵测试预言(ｔｅｓｔｏｒａｃｌｅ)和期望结果的自动生成 ⑶回归测试

84 ⑴面向路径的测试数据自动生成 在软件测试中,面向路径的测试数据生成问题(简称为Ｑ问题)描述为:给定一个程序Ｐ和Ｐ中一条路径Ｗ,设Ｐ的输入空间为Ｄ,求 ｘ∈Ｄ,使得Ｐ以 ｘ为输入运行,所经过的路径为Ｗ。 软件的单元测试中控制流测试中诸如语句覆盖、分支覆盖、条件覆盖、判定 条件覆盖、路径覆盖等问题和数据流测试中的全定值覆盖、全引用覆盖等问题,以及组装测试中的调用对覆盖和数据流测试等问题可以归结为Ｑ问题。面向断言的测试中的一些测试数据生成问题也可以归结为Ｑ问题。回归测试中的一些测试数据生成问题也归结为Ｑ问题。

85 ⑴面向路径的测试数据自动生成 自动求解Ｑ问题将有效地减轻测试人员的劳动强度,提高测试的效率和质量,节省软件开发的成本。根据估算,对于一个典型的大型软件项目,若能自动生成测试数据,则能节省整个软件开发费用的4%,相当于数百万美元。

86 ⑵测试预言、期望结果的自动生成 测试预言是一种检验待测系统在特定执行下是否正确运行的方法。期望结果用来确定测试用例执行的成功与否,它是程序根据输入应该得到的输出。因此,期望结果是一种比较理想的测试预言。 自动生成期望结果不仅能有效地减轻测试人员的负担,而且能为不间断的持续测试提供有力的支持。但是现有的对自动生成期望结果的研究工作很少。

87 ⑵测试预言、期望结果的自动生成 但是在有些情况下,某些程序的期望结果很难获得,即此时不能得到相应的测试预言。此时就需要研究不需借助测试预言来对程序进行测试的技术。利用该技术可以对无法获得测试预言的程序进行测试。其原理是根据被测程序的性质,采用变形关系,即被测程序必要但不充分的条件,按照多组测试数据执行被测程序,检查变形关系是否能被满足。若变形关系不能被满足,则说明被测程序中肯定存在缺陷。

88 ⑶回归测试 回归测试的目的是确认修改后的软件,以保证在以前测试过的代码中没有引入新的缺陷。
据统计,回归测试占整个软件系统开销的13%。已有的测试用例集是回归测试的基础。回归测试还要根据需要设计新的测试用例。针对已有的测试用例集,回归测试主要有选择性重测和全部重测两种策略。为减少回归测试的开销,在保证回归测试的质量的前提下,应尽量减少回归测试时需求运行的测试用例数目。

89 软件测试的发展趋势 软件的易测试性设计 构件测试 ＷｅｂＳｅｒｖｉｃｅｓ测试

90 ⑴软件的易测试性设计 Ｖｏａｓ将软件的易测试性定义为一定测试策略迫使软件中存在的故障被暴露的概率。软件的易测试性包括可观察、可控制、可理解等几个方面。 软件易测试性设计即是在软件的设计和编码中考虑测试问题,它借鉴了硬件易测试性设计的思想。为了减少测试集成电路的测试开销,提高产品的质量,工程师采用易测试性设计技术,即在集成电路上增加额外的引脚,通过这些引脚能够在测试时探测集成电路的内部,提高了可控制性和可观察性。

91 ⑴软件的易测试性设计 软件易测试性设计的目的是在不增加或者少增加软件复杂性的基础上,将易于测试的原则融合到设计和编码之中。软件易测试性设计符合软件测试的一个原则:尽早开始软件测试工作,不断进行软件测试工作。 软件易测试性设计体现软件测试的如下观点:软件产品的质量是生产(包括分析、设计、编码、测试)出来的,而不是仅仅依靠软件测试来保障。 软件易测试性设计也体现了软件测试的一个发展趋势:向软件开发的前期发展,与软件开发的设计和编码阶段相融合。易于测试的软件本身所包含的缺陷也会减少。软件易测试性设计将有效地提高软件测试的效率和质量,提高软件设计和编程的质量,进而提高软件产品的质量。

92 ⑴软件的易测试性设计 软件的易测试性设计方法包括合约式设计、内建式测试和内建式自测试等几种方法。
合约是管理对象之间的交互的一组规则。合约的来源是软件的规约,它指明了软件“做什么”而不涉及“怎样做”。 软件的内建式测试方法是在程序中添加额外的测试机制,使软件能够工作在测试模式下。 软件的内建式自测试方法就是在此基础上再增加测试用例生成机制。

93 ⑵构件测试 当前社会的信息化过程对软件的开发方法与生产能力提出了新的要求,软件复用是提高软件产品质量与生产效率的关键技术。软件构件概念的提出为软件复用提供了技术基础。构件的高可靠性是构件能被成功复用的前提。构件测试是保障和提高构件的可靠性的重要手段。构件的开发者和复用者必须对构件进行充分的测试,以确保它在新的环境中工作正常。

94 ⑵构件测试 与传统的软件测试相比,构件测试有着自身的固有特点:(1)不能对构件的执行环境和用户的使用模式进行完全准确的预测,故构件开发者不能完全、彻底地对构件进行测试,并且很难确定何时结束测试;(2)构件复用者和第三方测试人员通常无法得到构件的源代码及详细的设计知识,通常只能对构件进行黑盒测试,即调用构件的方法后只能通过观察执行的结果判断构件的行为是否正确,无法检查执行过程中的构件的内部状态,使得构件执行过程中的一些故障被隐藏。这些困难对构件测试提出了严峻的挑战。

95 ⑵构件测试 国际上于20世纪90年代后期对构件测试开展了研究。近年来,出现了大量的文献报道。构件测试成为当前软件工程学术界和工业界的热点问题之一。大体上,对构件的测试可以从以下几个方面来进行分类。 从构件测试的内容可分为:构件内部实现细节的测试,构件接口的测试,构件组装(构架)的测试。 从测试者与构件的关系可分为:构件开发者的测试(拥有构件的源代码)、构件复用者和第三方的测试(没有源代码)。 从测试过程中所采用的技术手段可分为:基于变异测试的方法基于构件状态机的方法,对构件的回归测试,以及构件的易测试性设计等。

96 ⑵构件测试 构件测试一个重要的发展方向是基于合约的构件易测试性设计。合约可以在运行时被检查,便于捕获构件执行过程中的一些故障,提高构件的易测试性。因此,基于合约的构件易测试性设计不仅为构件开发者开发高质量的构件提供帮助,而且在构件开发者与复用者之间架起一座桥梁,为构件复用者的测试提供支持,也为构件开发者捕获错误提供便利,便于区分构件开发者与复用者的责任。如果众多的构件开发者都采用合约式设计方法生产构件,那么失效时很容易定位到构件和其中的方法。为使基于合约的构件易测试性设计方法能够实用,需要研究解决以下问题:构件合约的描述、表达,构件中合约的获取,对构件合约的自动检查,以及针对构件合约的软件测试。

97 ⑶ＷｅｂＳｅｒｖｉｃｅｓ测试 随着软件产业模式从以产品为中心的制造业转变为以客户为中心的服务业,ＷＷＷ从2层体系转变为3层体系,Ｂ2Ｂ从复杂专用的连接转变为简单通用的连接,分布计算中间件从Ｉｎｔｒａｎｅｔ扩展到Ｉｎｔｅｒｎｅｔ,ＣＯＲＢＡ、ＣＯＭ及ＥＪＢ等中间件技术已不能适应这些发展需求,因而导致了新型中间件技术ＷｅｂＳｅｒｖｉｃｅｓ的产生。

98 ⑶ＷｅｂＳｅｒｖｉｃｅｓ测试 当前,ＷｅｂＳｅｒｖｉｃｅｓ越来越受到人们的关注,它使用了包括ＳＯＡＰ、ＷＳＤＬ和ＵＤＤＩ在内的标准协议。这些标准协议体现了互操作性,并用于应用的开发及运行时ＷｅｂＳｅｒｖｉｃｅｓ的选择和调用。ＷｅｂＳｅｒｖｉｃｅｓ的测试和评估对服务提供者和服务使用者来说都是相当重要的。Ｗｅｂｅｒｖｉｃｅｓ的测试相当于黑盒测试,可以获得规约,却不能得到设计或源代码。ＷｅｂＳｅｒｖｉｃｅｓ规约是用ＷＳＤＬ写的,而代码是用Ｊａｖａ、Ｃ#或其他编程语言写的。