第9章软件测试.ppt

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

1、第9章 软件测试,6学时,引言-,据新华社洛杉矶2002年月报道，美国一家研究所公布的调查结果表明，软件错误使美国每年损失高达亿美元。同时指出，如能做好检测工作,即在软件开发的早期发现漏洞并进行弥补每年能给美国企业节省成本亿美元。然而,目前软件中一半以上的错误是在开发的后期或者售后使用中才被发现的。,第9章 软件测试,1）软件测试的概念 2）黑盒测试和白盒测试方法 3）单元测试过程 4）集成测试,系统测试,验收测试的基本过程 5）面向对象的测试概念和方法,掌握 掌握 理解 了解 了解,要求,9.1软件测试的概念,9.1.1测试的定义 从广义上讲是指软件产品生存周期内所有的检查、评审和确认活动

2、从狭义上讲，软件测试是为了发现错误而执行程序的过程 软件测试是根据软件开发各阶段的规格说明和程序内部结构而精心设计的一批测试用例,用这些测试用例运行程序,以发现程序错误的过程。 一个测试用例是一组输入数据及其对应的预期输出结果。,测试的工作量,一般性软件其测试工作量大约占整个开发工作量的40% 系统软件或关系到人的生命财产安全的重要软件，其测试工作量通常可能达到整个开发工作量的35倍,软件测试的目标,优秀的测试用例:以最小的代价、在最短的时间内，尽可能多地发现软件中的错误 。 测试并不仅仅是为了要找出错误,通过分析错误产生的原因和错误的分布特征,来帮助评价软件的质量、进一步发现软件的缺陷,同时

3、也有助于设计出更有针对性的测试方法,提高测试效率 。,测试原则,应该把测试贯穿在整个开发过程之中。事实上从需求分析阶段开始，每个阶段结束之前都要进行阶段审查，目的是尽早发现和纠正错误。 每个测试用例都应该包括测试输入数据和这组数据输入作用下的预期输出结果。在实际操作中可以列出一张电子表格，包括每个测试用例的编号、类型、输入数据、预期输出结果、实际输出结果、出错原因分析。,测试原则续,程序员应该尽量避免检查自己编写的代码。测试工作需要严格的工作作风，程序员在测试自己编写的代码时往往会带有一些倾向性，使得他们工作中常常出现一些疏漏。而且程序员对设计规格说明书的理解错误而引入的错误更是难于发现。,测

4、试原则续,在设计测试用例时，应该包括有效的、期望的输入情况，也要包括无效的和不期望的输入情况。即能够验证程序正常运行的合理输入，也能够验证对异常情况处理的不合理输入数据以及临界数据输入。 在测试时,人们常常过多地考虑合法和期望的输入条件,以检查程序是否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。 用户在使用系统时,输入一些错误指令和参数是经常发生的,如果软件遇到这种情况不能做出适当的反应,给出相应的提示信息,可能会误导用户,甚至会造成严重损失。,测试原则续,软件中遗留的错误数量与已经发现的错误数量成正比。根据这个规律对测试中发现错误成堆的模块更要仔细测试。例如，在某个著名的操作系

5、统中，44%的错误仅与4%的模块有关。 回归测试的关联性要特别引起注意，修改一个错误而引起更多错误的现象并不少见。,测试原则续,严格执行测试计划。在测试之前应该有明确的测试计划，内容包括：要测试的软件功能和内容、测试用例和预期结果、测试的进度安排、需要的工具和资源、测试控制方式和过程等。 做好测试记录，为统计和维护提供基础数据,测试的层次和类型层次,单元测试：针对模块代码的测试,测试的粒度最小 集成测试：把经过单元测试的模块组合在一起,重点测试模块之间的接口。 系统测试：系统集成后,对整个系统包括硬件等环境的综合测试。 验收测试：以用户为主,对软件功能、性能进行全面测试。验证软件是否满足需求规

6、格说明书的要求，检查所有的配置成份是否齐全。,测试的层次和类型类型（续）,静态测试：主要通过代码审查和静态分析，检查源代码中存在的问题。 过程：代码审查由有经验的程序设计人员根据软件详细设计说明书，阅读程序来发现源程序中类型、引用、参数传递、表达式等不必运行程序就能够发现的错误。 特点：这种方法不需要专门的测试工具和设备，一旦发现错误就能定位，但是此方法具有一定的局限性。静态分析主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等,测试的层次和类型类型（续）,动态测试：在指定的环境上运行被测程序，输入测试数据，获得测试结果，将获得的测试结果与预期的结果进行比较，发现程序的错误 。 过程

7、：设计测试用例，运行被测程序。 特点：需要有程序的运行环境，必要时要编写测试驱动程序和桩程序。,测试的层次和类型类型（续）,功能测试：验证软件是否提供了预期服务。 过程：根据软件需求规格说明书设计测试用例，并按照测试用例的要求运行被测程序。 特点：将被测程序看成是一个黑盒子，着重验证软件功能和性能的正确性，其典型测试方法包括价类划分、边值分析、因果分析、猜测错误等。,测试的层次和类型类型（续）,结构测试：对程序结构的检查，也称为白盒测试。采用这种测试方法，测试者需要了解被测程序的内部结构。白盒测试通常根据覆盖准则设计测试用例，有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖和条件组合覆盖等。,测

8、试的层次和类型类型（续）,用户界面测试：对软件提供的用户界面、系统接口的测试。验证其正确性、可操作性、可理解性。 性能测试：测试程序的响应时间、并发性、吞吐量、处理精度。 负载测试：测试一个软件在重负荷下的运行情况。例如，测试一个 Web应用软件在大量的负荷下，何时系统的响应会退化或失败 强度测试：在异乎寻常的重载下系统运行情况，如某个动作或输入的不断重复；大量数据的输入；对一个数据库应用系统大量的复杂查询等。,测试的层次和类型类型（续）,安全性测试：检查系统对非法侵入的防范能力。测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，截取或破译口令、破坏系统的保护机制、故意导致系统失败、试图

9、通过浏览非保密数据，推导所需信息等 网络通信测试：软件中的网络通信的速度、容量、安全性、延迟处理等方面的测试。,测试的层次和类型类型（续）,恢复测试:恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间内修正错误并重新启动系统。 恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化、数据恢复、重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。,软件历史上最严重的10大bug之一,1962年7月28日， Mariner I空间探测器事件。 Mariner 1航空软件的bug导致火箭在发射时偏离了其

10、的预期轨道。任务控制器在大西洋上空将整个火箭摧毁。在对这起事故进行调查中发现，使用铅笔撰写下的一个公式被不正确的录入到计算机代码中，直接导致计算机错误的计算了火箭的运行轨道。,软件历史上最严重的10大bug之二,1982年苏联的石油管道事件。 根据CIA(美国中央情报局)的陈述，为其工作的间谍们在苏联购买的用来控制跨西伯利亚石油管道的加拿大计算机系统中种下了一个bug。当时是苏联通过秘密购买或者偷窃美国的敏感技术来获取到了该系统。据说CIA发现了这个存在bug的程序，决定对可以通过苏联人检查的设备做一个让苏联人事与愿违的破坏，使得该设备一旦运行起来将会失败。该事件的结果据说在历史上造成了最大的

11、非原子破坏。,软件历史上最严重的10大bug之三,1985-1987年间 - Therac-25医疗加速器事件。 一个放射疗法的设备故障造成了在几个医疗设备中发出了致命的射线。Therac-25是一个在以前设计的基础上改进的治疗设备，该设备可能会发出两种射线:或者是一个低功耗的电子束或者是X射线。Therac-25的X射线是通过猛烈的高能电子束撞击到一块位于电子枪和患者之间的金属目标而产生的。第二项改进是对于更旧的Therac-20电动保险联动装置采取软件控制的方式代替，做这项改进是因为软件被认为更加可靠。 然而工程师所不知道的是20和25型号都是建立在有一个没有经过正规培训的程序员所开发的操

12、作系统上的。由于这个不易察觉的叫做“race condition,“的bug，一个快速的打字员很可能会很偶然的配置Therac-25从而导致电子束将会在高能模式下启动。但是强烈的X射线偏移了目标。最后直接导致了五名患者死亡；其余患者受到了严重伤害。,软件历史上最严重的10大bug之四,1988年-伯克莱UNIX操作系统finger守护进程缓冲器溢出事件。 第一个网络蠕虫，莫里斯蠕虫利用缓冲器溢出在一天之内感染了2000到6000台计算机，起因是一个标准输入输出库函数gets()，原来设计为从网上获取一段文本，但遗憾的是，gets()函数没有规定输入文本的长度。过长的文本导致蠕虫入侵任何接入的计

13、算机。程序员们试图用工作码来取代gets()函数的功能，但是他们拒绝从C语言的标准输入输出库中删除它，直到今天还保留着。,软件历史上最严重的10大bug之五,1988-1996年间-Kerberos随机数字发生器事件。 Kerberos安全系统的作者忽略了产生真正的程序随机码时使用恰当的种子，导致长达八年依赖Kerberos验证的计算机可被轻易入侵。如果漏洞不被利用，就一直不会被发现。,软件历史上最严重的10大bug之六,1990年1月15日，AT&T网络瘫痪。 利用一个新发布软件的bug可以控制AT&T #4ESS远程交换机，在邻近计算机之间发送信息引起大型计算机瘫痪，机器恢复时发送信息又导

14、致邻近计算机当机。 一天纽约的一台交换机当机并且重启，引起它邻近交换机瘫痪，由此及彼，一个连着一个，很快，114台交换机每六秒当机重启一次，六万人九小时内不能打长途电话。当时的解决方式：工程师重装了软件以前的版本。,软件历史上最严重的10大bug之七,1993年-Intel奔腾浮点指数除法事件。 一个硅片上的错误导致Intel高性能奔腾芯片在一段范围内计算浮点指数除法时发生错误。例如4195835.0/3145727.0产生的是1.33374而不是1.33382，产生了0.006偏差。尽管该bug仅仅影响了几个用户，然而他却成了整个公众的噩梦。估计流通中的三百万到五百万的芯片存在着这样的缺陷，

15、起初Intel仅仅为那些能够证明他们确实有高精度计算需求的用户提供了取代奔腾的芯片。最后，Intel公司只好妥协为任何投诉的人提供替代芯片。该bug给Intel最终造成了4亿7千5百万损失。,软件历史上最严重的10大bug之八,1995/1996年致命的ping命令。 由于缺乏对IP段组装代码的完整性检查和错误的执行使得有可能通过从互联网的任意位置发送恶意的”ping”数据报而攻击多个操作系统。大部分受明显影响的是运行Windwos的计算机，当他们接受到数据报后，他们就会死锁同时显示所谓的“蓝屏死机”。但是攻击同时也影响很多Macintosh和Unix系统。,软件历史上最严重的10大bug之九

16、,1996年6月4号501航天飞机爆炸事件。 对于Ariane 4火箭的工作代码在Ariane 5中被重新使用，但是Ariane 5更高速的运算引擎在火箭航天计算机中的算法程序中触发了一个bug。该错误存在于将64位浮点数转换为16位带符号整数的程序中。更快的运算引擎导致了Ariane 5中的64位数据要比Ariane 4中更长，直接诱发了溢出条件，最终导致了航天计算机的崩溃。 首先501航天飞机的备份计算机崩溃，然后0.05秒之后，主计算机也崩溃了。这些计算机崩溃直接导致了火箭的主要处理器使火箭的运算引擎过载，同时导致火箭在发射40秒后解体破碎。,软件历史上最严重的10大bug之十,2000

17、年11月 巴拿马市国家肿瘤中心事件。 在这一系列事故中，由一家美国公司Multidata Systems International所开发的治疗软件错误的计算了对于正处于放射治疗中的病人所应该使用的合适剂量。 Multidata的软件允许放射治疗师利用计算机屏幕的一个叫做“blocks“的金属装置来保护健康组织以免受射线的伤害。但是该软件仅仅允许治疗师使用4个屏蔽块，但是巴拿马的医生希望用5块来保护。 医生发现他们可以通过将所有的屏蔽块画成一个在中间有孔的大块来欺骗该软件。然而医生们没有意识到的是Multidata软件在这种配置中根据该空画法的不同给出了不同的答案：如果该孔是在一个方向绘制的，

18、则给出正确的计算出的剂量，如果是在另外不同的方向绘制的，软件就会推荐出要比必须需要暴露的射线的两倍剂量。至少有8个病人在这次事故中丧生，同时接受了过多剂量放射的20个病人产生了严重的健康问题。被要求手动两次检查计算机的计算的医生被以谋杀罪起诉。,软件错误的一些事例1,1991年2月25日在海湾战争中，一个软件故障扰乱了“爱国者”导弹的雷达跟踪系统，产生了1/3秒的时间误差，结果未能击中伊拉克发射来的飞毛腿导弹，造成美军28名士兵死亡，98人受伤。 爱国者导弹连在载赫蓝已经连续工作了100小时, 导弹的时钟已经偏差了三分之一秒, 相等于600米的距离误差。由于这个时间误差,使雷达系统侦察到飞毛腿

19、导弹并且预计了它的弹道,系统却找不到实际来袭的导弹,雷达发现的目标被视为一次假警报,侦测到的目标也从系统中删除。,软件错误的一些事例2,美国丹佛新国际机场投资1.93亿美元的自动化行李系统，由于其中的软件错误，致使该机场的开放时间推迟了半年以上，造成巨大损失。,软件错误的一些事例2,1996年6月4日，欧洲航空航天局耗资67亿美元研制的Ariane501火箭在首次飞行试验中，点火后仅37秒即在空中爆炸。 事故调查委员会经过调查分析后认为，灾难是由惯性制导系统软件中的一个错误引起的。,测试的难点,测试用例是设计者对测试对象的理解，因此，其质量很大程度上取决于设计者的分析、理解和设计能力。这是一种

20、缺乏指导性方法的、不易制订标准规范的、需要“技巧”的设计活动。 开发组织与测试组织难一很好的配合。长期以来，大都数软件开发人员认为测试活动是对开发人员劳动成果的不断“挑剔”。但实际上，测试工作的出发点是确保开发人员的劳动成果成为可接收的、高品质的软件产品。 有效的测试工作需要投入足够的人力和物力，需要对工作的难度和消耗有充分的估计。,测试的产品,软件测试工作所产生的文档、程序、服务、以及相关的文件总和称之为软件测试产品 。 测试配置包括：测试计划；测试方案（包括测试输入数据、测试的功能、测试预期结果）；文档审查项列表；代码审查项列表；软件测试报告；软件问题报告；软件变更报告；软件测试日志。,测

21、试的信息流,9.2设计测试用例,测试用例是用于软件测试的输入数据及预期结果 。 一个好的测试用例有以下几个特征： 是最有可能发现错误的； 不是重复的、多余的； 通常先按黑盒测试法设计基本测试用例，发现软件功能和性能上的问题，然后再用白盒测试方法补充一些测试用例，发现程序逻辑结构的错误。,黑盒测试法,等价类划分 边值分析 因果分析 猜测错误,白盒测试法介绍三种方法,语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 多条件覆盖,白盒测试,语句覆盖测试用足够多的测试用例使程序的每条语句至少执行一次。这是一个非常弱的测试方法。因为每条语句都执行一次，仍然会有许多错误测试不出来 。,例子,BEGIN . I

22、f (A1) AND (B=0) THEN DO X:=X/A; IF (A=2) OR (X1) THEN DO X:=X+1; END,每条语句都执行一次，程序中第二个判定OR写成AND仍然不能被发现错误,判定覆盖法设计足够多的测试用例，不仅使每条语句都至少执行一次，还要使程序中每个判定分支都至少执行一次，也就是说，设计的测试用例使每个判定都有一次取“真”和“假”的机会。,条件组合覆盖设计足够多的测试用例，使得每条语句都至少被执行一次，还要使得每条判定表达式中条件的各种组合都至少出现一次。,黑盒测试,功能测试中如果能够穷尽所有的有效输入和无效输入，那么也可以得到正确的程序，但是，实际上我们

23、不可能也没有必要穷尽所有的输入。我们要力争找到这样的测试用例，使得每个测试用例都尽可能地发现更多的错误。并且这类测试用例具有很强的代表性，它能够覆盖尽可能多的其他输入。,等价类划分,等价类划分的核心思想是将程序的所有输入划分为不同区域，同一个区域中的所有输入数据具有相同的测试效果。使用这种方法可以滤掉所有同类数据，极大地提高了测试的效率。等价类划分方法由两步组成：先划分等价类，再找出测试用例。,原则,如果程序的某个输入条件规定了值的范围，则确定一个有效等价类、一个无效等价类（小于最小有效值和大于最大有效值）。 如果输入条件中规定了“必须如何”的条件，则我们可以确定一个有效等价类和若干个从不同角

24、度破坏规定条件的无效等价类。 如果某个等价类中的元素在程序处理上是有区别的，那就要把这个等价类拆成更小的等价类。 在实际项目中要根据具体的情况划分等价类，宗旨就是一个等价类中的各个元素具有相同的测试效果。,方法,1）给每个等价类规定一个唯一的编号。 2）设计一个新的测试用例，使其尽可能多的覆盖未被覆盖的有效等价类，直到所有的有效等价类都被覆盖为止，即每个有效等价类都包含于某个测试用例之中。 3）设计一个新的测试用例，使其仅仅覆盖一个未被覆盖的无效等价类。重复第三步，直到所有的无效等价类都被覆盖为止。,注意,设计无效等价类测试用例时之所以要求仅覆盖一个无效等价类，是因为某些无效测试用例会掩盖其他

25、的错误。例如，输入考生的专业编号（G表示钢琴、S表示手风琴、T表示小提琴）和成绩（20100），测试用例：XY11 同时覆盖了专业编号和成绩两个无效的测试等价类，但是，程序可能会认为XY 11是一个专业编号，而不去测试成绩，导致成绩这个无效等价类的测试用例少了一类测试。,例子：编写一个程序将字符类型的数字串转换成整数。字符串是右对齐的，并且最大长度是6，不足6位时左边补空格，表示负值时，在字符数字的最左边应该是负号。如果输入的是正确的字符数字，程序应该输出转换后的数字，如果输入的不正确，程序输出提示信息。,边值分析法,选择的测试用例是正好等于边界值、稍小于或稍大于边界值的情况。 前面讨论的等价

26、类是在等价类内部寻找测试用例，边值分析法是在等价类的边界上选择测试用例。在实际项目中将而者结合会得到令人满意的结果。,原则,如果输入条件规定了值的范围，则设计测试用例恰好等于边界值、刚刚超出边界值。例如，输入范围是1到10的整数，则测试用例的取值： 0，1，10，11 如果输入条件规定了值的个数，则设计测试用例分别等于规定的个数，刚刚超出、刚刚小于规定的个数。例如，要求的记录个数是1到255，则设计的记录个数分别为：0，1，255，256,原则,如果输出条件规定了值的范围，则设计测试用例使输出恰好等于边界值。例如，输出范围是1到10的整数，则设计测试用例，使其输出能够得到1和10。然后再设计测

27、试用例，试图使其输出为0和11，检查程序对这组测试用例的处理结果，很有可能发现程序的问题。 如果输出条件规定了值的个数，则设计测试用例使输出恰好等于规定的边界值。例如，输出范围是1到255条记录，则设计测试用例，使其输出1条记录和255条记录。然后再设计测试用例，试图使其输出0条记录和256条记录，检查程序对这组测试用例的处理结果，很有可能发现程序的问题。 另外，不断积累测试的经验，找出其他的边界条件。,错误猜测法,等价类划分和边值分析法都只是孤立地考虑各种测试用例的功效，因果图是比较机械地设计测试用例，它们都缺乏综合考虑的效应。 错误推测法的基础是经验和对程序的直觉，它的基本思想是列举出程序

28、可能出现的错误，根据这些错误设计测试用例。,错误猜测法看一个颇有启发的故事 发生在美国通用汽车的客户与该公司客服部间的真实故事,一天美国通用汽车公司的客服收到一封客户抱怨信,这样写的：我们家有一个传统的习惯,就是每天晚餐后,会吃冰淇淋甜点,我开车去买。奇怪的是每当我买香草口味的冰激凌，车子就发不动。但如果我买的是其他的口味,车子发动就顺得很.难道你们的车对香草冰激凌过敏？ 客服经理心存怀疑,但他还是派了一位工程师去查看究竟。工程师与这位仁兄上车，往冰淇淋店开去，买香草口味，当回到车上后，车子起不动了。这位工程师之后又依约来了三个晚上：第1晚巧克力冰淇淋，车子没事；第2晚草莓冰淇淋，车子也没事；

29、第3晚香草冰淇淋，车子又不动了。 工程师开始记下从头到现在所发生的种种详细资料，如时间、车子使用油的种类、车子开出及开回的时间，根据资料显示他有了一个结论，这位仁兄买香草冰淇淋所花的时间比其它口味的要少。为什么呢？原因是香草冰淇淋是所有冰淇淋口味中最畅销的口味，店家为了让顾客每次都能很快的取拿，将香草口味特别分开陈列在单独的冰柜，时间比买其他口味的要快。 买其他口味冰激凌时由于时间较久，引擎有足够的时间散热，重新发动时就没有太大的问题。买香草口味时，由于花的时间较短，引擎太热以至于还无法让“蒸气琐”有足够的散热时间。 有时问题看起来真的是疯狂，但它是真正存在的；我们应保持冷静的思考去找寻解决的

30、方法。,测试大纲,当某一测试结果为时表示通过，为 时表示还存在错误。 本表内容不足以记录时，可以在附页填写，总页数可用铅笔填写。 模块编号按模块依据从属关系或按层次编号。,测试问题卡 -测试员：,上表解释,“等级”是指错误等级，可分为A：严重影响系统运行；B：影响系统运行；C：不影响运行但必须修改；D：所提建议。 “频率”指错误出现频率，分为A：操作即出现；B：偶尔出现。 “时机”指错误出现时机，分为A：修改后出现；B：已发现但未修改；C：首次出现。 “改否”项由开发人员填写，如果已修改该问题，填“”，否则为空。 “建议返回时间”指要求开发人员在某时间之前，将修改后的软件返回给测试人员重新测试

31、。,测试用例模版：,上表解释,测试用例描述：用于说明本测试用例的测试要点。 操作步骤：用于描述执行该功能的基本操作。 操作过程及测试数据：用于描述测试用例的操作步骤及所使用的测试数据。此项内容根据测试用例的复杂性选择使用，对没有必要写明操作步骤的此项可省略 预期结果和验证过程：这两项内容用于记录测试用例正确执行应得到的结果，预期结果多用于描述界面上可见结果。验证过程多用于界面上无可见结果但在其它操作中可验证的过程。预期结果和验证过程根据实际需要均可省略，但至少要有一项以明确测试结果。 运行预期时间；该项对在运行时间上有要求的，或通过运行时间能反映执行情况的测试用例使用。 备注：用于记录该测试用

32、例执行的一些特殊说明，如必须先运行某测试用例。,9.3 单元测试,单元测试是软件测试环节中最基本的测试，测试的对象是独立的模块。 单元测试开始之前要先通过编译程序检查并改正语法错误，然后用详细设计说明书作为指南对模块的功能和模块代码中的重要执行路径及主要算法进行测试。 单元测试可以对多个模块同时进行。 单元测试主要分为人工静态检查和动态执行跟踪两个步骤进行。,人工静态检查,主要是保证算法代码实现的正确性和高效性，代码编写清晰、规范。 经验表明，使用人工静态检查法能够有效的发现30%-70%的逻辑设计和编码错误。 成立一个34人的代码审查小组，包括经验丰富的测试人员、被测程序的作者和其他程序员。

33、被测程序的作者讲述程序的逻辑结构，大家发现问题可随时提问，以判断是否存在错误 。,方法,检查算法实现的正确性。确定所编写的代码和定义的数据结构实现了模块或方法所要求的功能。 检查模块接口的正确性。检查模块的参数个数、类型、顺序是否正确，确定返回值的正确性。 调用其他方法接口的正确性。检查实参类型、数值、个数的正确性，特别是具有多态性的方法。检查返回值的状态，最好对每个被调用方法的返回值用显式代码做正确性检查，如果被调用方法出现异常或错误，程序应该给予反馈，并添加适当的出错处理代码。,出错处理。模块代码要求能预见出错的条件，并设置适当的出错处理，这种出错处理应当是模块功能的一部分。若出现下列情况

34、之一，则表明模块的错误处理功能不够完善： 出错信息描述难以理解； 错误信息的描述不足以对错误定位，不足以确定出错原因 显示的错误信息与实际的错误原因不符； 对错误条件的处理不正确； 在对错误进行处理之前，错误条件已经引起系统的干预等,保证表达式、SQL语句的正确性。表达式应该保证不含二义性，对于容易产生歧义的表达式或运算符优先级（如 、=、 、 &、|、+、 -等）可以采用括号“（）”运算符避免二义性，这样一方面能够保证代码的正确可靠，同时也能够提高代码的可读性。 检查常量或全局变量使用是否正确。 标识符定义是否规范一致。保证变量名能够见名知意并且简洁，但不宜过长或过短，还应规范、容易记忆，最

35、好能够拼读。尽量保证用相同的标识符代表相同功能。 检查方法内部注释是否完整；是否清晰简洁；是否正确地反映了代码的功能，错误的注释比没有注释更糟；是否做了多余的注释，对于简单的一看就懂的代码没有必要注释。,人工走查的数据要简单，检查后程序的修改由作者自己完成。 测试委员会可以再次开会审查，这次审查仍然要整个过程都走一遍，因为修改可能会带来新的错误。,注意,有时为了测试一个程序需要设计一个模块驱动程序和桩程序。 驱动程序用于向被测试的模块提供测试数据，接受返回的结果。 桩程序是被测试的模块调用的下层模块，一般开发一个虚模块，只返回上层模块需要的数据即可。,动态执行跟踪,设计测试用例，执行待测程序，

36、比较实际结果与预期结果，发现程序中的错误。 动态执行测试通常分为黑盒测试与白盒测试。黑盒测是指已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测是指已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格的要求，所有内部成分是否已经检查。 对于单元测试来说主要应该采用白盒测试法对每个模块的内部作跟踪检查测试。,方法,对模块内所有独立的执行路径至少测试一次； 对所有的逻辑判定，取“真”与“假”的两种情况都至少执行一次； 用边值法测试循环边界和运行界限； 测试内部数据的有效性等等。,9.4 集成测试,集成测试针对的是各个相关模块的组合测试，最终的目标是将整个系

37、统正确的组合成功，没有明显的模块之间的匹配问题。 时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。 主要原因是，模块相互调用时接口会引入许多新问题。 数据经过接口可能丢失； 一个模块对另一模块可能造成不应有的影响； 几个子功能组合起来不能实现主功能； 误差不断积累达到不可接受的程度； 全局数据结构出现错误，等等。 集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试以便发现与接口有关的各种错误。,自顶向下集成测试的具体步骤,以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代； 依据

38、所选的集成策略（深度优先或广度优先），每次只替代一个桩模块测试； 每集成一个模块立即测试一遍； 只有每组测试完成后，才着手替换下一个桩模块； 为避免引入新错误，需不断地进行回归测试（即全部或部分地重复已做过的测试）。从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。,自顶向下集成特点,优点：能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。 缺点：在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。 解决问题办法： 第一种是把某些测试推迟到用真实模块替代桩模块之后进行， 第二种是开发能模拟真实模块的桩模块； 第三

39、种是自底向上集成模块。,自底向上集成,是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。自底向上集成测试的步骤分为： 把低层模块组织成实现某个子功能的模块群； 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出； 对每个模块群进行测试； 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。,特点,优点：自底向上集成方法不用桩模块，测试用例的设计亦相对简单。 缺点：程序最后一个模块加入时才具有整体形象。 在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混合使用两种策略

40、更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。,9.5 系统测试,针对概要设计，检查系统作为一个整体是否能够有效地运行。例如在产品设置中是否达到了预期的高性能。 系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。,几类系统测试,验证测试。以用户需求规格说明书的内容为依据，验证系统是否正确无误的实现了需求中的全部内容。 强度测试：检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行，验证系统的健壮性是否可靠。 性能测试：对于那些实时系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每

41、一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。,9.6 验收测试,以用户为主，验证软件的有效性，即验证软件的功能和性能满足用户的要求。通常使用实际数据，根据需求规格说明书的功能和性能描述逐条进行测试。 应该在集成测试、系统测试之后进行。 验收测试还有一项重要的任务是检查软件配置，检查的目的是保证软件配置的所有成分齐全，各方面的质量都符合要求，文档与程序一致，具有维护阶段所必需的细节，而且已经编制好目录。 验收测试的操作应该严格遵循用户手册进行，以便检验这些手

42、册的完整性和正确性 。,测试,测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为版本）进行测试，试图发现错误并修正。测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。,测试,经过测试调整的软件产品称为版本。紧随其后的测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对版本进行改错和完善。,9.7面向对象的测试,对象是属性和操作的封装体，对象彼此之间通过发送消息启动相应的操作，由于对象并没有明显地规定用什么次序启动它的操作才是合法的，测试的对象也不再

43、是一段顺序的代码，所以照搬传统的测试方法就不完全适用了。 继承与多态机制是面向对象程序中使用的主要技术，它们给程序设计带来了新的手段，但同时也给程序的测试提出了一些新的问题。例如，在父类A中定义了属性s和方法f1，f2和f3，在A的子类B中定义了属性r、方法f1和f4，在测试子类B时应该把它展开成下列内容： 属性 s，r 方法 f1，f2，f3，f4 虽然方法f1、f2和f3在父类中已经被测试通过，但是由于在子类中重载了方法f1，原来的测试结果不再有效，因为A:f1和B:f1是具有不同定义和实现。新的方法f4的加入也增加了启动操作次序的组合情况，某些启动序列可能会破坏对象的合法状态。因此，测试

44、人员往往不得不重复原来已经做过的测试。 由此可见，随着继承层次的加深，虽然可重用的构件越来越多，但是测试的工作量和难度也随之增加。,面向对象程序的测试策略和方法,传统的测试策略是从单元测试开始，然后是集成测试和系统测试。 在面向对象软件中，单元的概念发生了变化，最小的可测试单位是封装的类或对象。 面向对象的集成测试有两种策略： 基于线程的测试，即集成对应系统的一个输入或事件所需要的一组类，每个线程被分别测试并被集成，使用回归测试以保证集成后没有产生副作用。 基于使用的测试，先测试那些主动类，然后测试依赖于主动类的其它类，逐渐增加依赖类测试，直到构造完整个系统。,对于面向对象的软件系统，测试应该

45、在以下层次展开： 测试类的操作：使用前面介绍的黑盒测试和白盒测试方法，对类的每一个操作进行单独测试； 测试类：使用等价类划分、边界值测试等方法，对每一个类进行单独测试； 测试类集成：使用基于用例场景的测试方法对一组关联类进行集成测试； 测试面向对象系统：与任何类型的系统一样，使用各种系统测试方法进行测试。,本章要点,软件测试是为了发现错误而执行程序的过程，其目的在于以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。 由于软件错误的复杂性，软件测试需要综合应用测试技术，并且实施合理的测试步骤，即单元测试、集成测试、系统测试和验收测试。单元测试集中于每一个独立的模块；集成测试集中于模块的组装；系统测试确保整个系统与系统的功能需求和非功能需求保持一致；验收测试是用户根据验收标准，在开发环境或模拟真实环境中执行的可用性、功能和性能测试。 软件测试技术大体上可以分成结构测试和功能测试。结构测试技术依据的是程序的逻辑结构，主要包括逻辑覆盖方法；功能测试技术依据的是软件行为的描述，主要包括等价类划分、边界值分析测试等方法。 面向对象程序的单元测试以类为基本的测试单位，使用黑盒测试和白盒测试方法，对类的每一个操作进行单独测试；使用等价类划分、边界值测试等方法，对每一个类进行单独测试；使用基于用例场景的测试方法对一组关联类进行集成测试；最后可以使用各种系统测试方法进行系统测试。,