《软件工程第七章软件测试.ppt》由会员分享，可在线阅读，更多相关《软件工程第七章软件测试.ppt（69页珍藏版）》请在三一办公上搜索。
1、软件工程第七章软件测试,2,Contents,7.1 软件测试概述,软件危机(1.2),7.2 软件测试方法与技术,7.3 软件测试过程,3,Contents,7.1 软件测试概述,4,7.1软件测试概述 7.1.1软件测试的目的 统计资料表明，测试的工作量约占整个项目开发工作量的40%左右，对于关系到人的生命安全的软件（如飞机飞行自动控制系统），测试的工作量还要成倍增加。那么，为什么要花这么多代价进行测试?其目的何在？它是“说明程序能正确地执行它应有的功能”，还是“表明程序没有错误”。如果是这样一个目的，就要朝着“证明程序正确”这个目标靠拢，无意识地选择一些不易暴露错误的例子。因此G.J.M
2、yers对软件测试的目的提出了以下观点：,5,(1)软件测试是为了发现错误而执行程序的过程。(2)好的测试用例能够发现至今尚未发现的错误。(3)成功的测试是发现至今尚未发现的错误的测试。因此，测试阶段的基本任务应该是根据软件开发各阶段的文档资料和程序的内部结构，精心设计一组“高产”的测试用例，利用这些用例执行程序，找出软件中潜在的各种错误和缺陷。,6,软件测试的目的,基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了
3、用户的要求，确立人们对软件质量的信心。,7,换言之，测试的目的是 想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析提供了依据。测试不能表明软件中不存在错误，它只能说明软件中存在错误。,8,软件测试的原则,1.应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。2.测试用例应由测试输入数据和对应的预期输出结果这两部分组成。3.程序员应避免检查自己的程序。4.在设计测试用例时，应包括合理的输入条件和不合理的输入条件。,9,5
4、.充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。6.严格执行测试计划，排除测试的随意性。7.应当对每一个测试结果做全面检查。8.妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。,10,软件测试的对象,软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。,11,为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。确认(Validation)，是一系列的活动
5、和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。需求规格说明确认 程序确认(静态确认、动态确认)验证(Verification)，试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。,12,13,测试信息流,14,测试信息流,软件配置：软件需求规格说明、软件设计规格说明、源代码等；测试配置：测试计划、测试用例、测试程序等；测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。,15,测试结果分析：比较实测结果与预期结果，评价错误是否发生。排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，
6、同时修改相关的文档。修正后的文档再测试：直到通过测试为止。,16,通过收集和分析测试结果数据，对软件建立可靠性模型利用可靠性分析，评价软件质量：软件的质量和可靠性达到可以接受的程度；所做的测试不足以发现严重的错误；如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。,17,测试与软件开发各阶段的关系,软件开发过程是一个自顶向下，逐步细化的过程软件计划阶段定义软件作用域软件需求分析建立软件信息域、功能和性能需求、约束等软件设计把设计用某种程序设计语言转换成程序代码,18,测试过程是依相反顺序安排的自底向上，逐步集成的过程。,19,Contents,软件危机(1.2)
7、,7.2 软件测试方法与技术,20,7.2.1 静态测试与动态测试 1.静态测试 静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测，方法如下：(1)人工测试：是指不依靠计算机而靠人工审查程序或评审软件。人工审查程序偏重于编码质量的检验，而软件审查除了审查编码还要对各阶段的软件产品进行检验。,21,(2)计算机辅助静态分析：指利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。如用错的局部量和全程量、不匹配参数、不适当的循环嵌套和分支嵌套、潜在的死循环及不会执行到的代码等。还可能提供一些间接涉及
8、程序欠缺的信息、各种类型的语句出现的次数、变量和常量的引用表、标识符的使用方式、过程的调用层次及违背编码规则等。静态分析中还可以用符号代替数值求得程序结果，以便对程序进行运算规律的检验。,22,2.动态测试 动态测试指通过运行程序发现错误。一般意义上的测试大多是指动态测试。为使测试发现更多的错误，需要运用一些有效的方法。测试任何产品，一般有两种方法：一是测试产品的功能，二是测试产品内部结构及处理过程。对软件产品进行动态测试时，也用这两种方法，分别称为黑盒测试法和白盒测试法。,23,7.2.2 黑盒测试法与白盒测试法 1.黑盒法 该方法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构
9、和处理过程，只在软件的接口处进行测试，依据需求说明书，检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试。,24,通过黑盒测试主要发现以下错误：(1)是否有不正确或遗漏了的功能。(2)在接口上，能否正确地接受输入数据，能否产生正确的输出信息。(3)访问外部信息是否有错。(4)性能上是否满足要求等。,25,用黑盒法测试时，必须在所有可能的输入条件和输出条件中确定测试数据。是否要对每个数据都进行穷举测试呢？例如测试一个程序，需输入 3 个整数值。微机上，每个整数可能取值有216个，3个整数值的排列组合数为216216216=24831014。假设此程序执行一次为一毫秒，用这些所有
10、的数据去测试要用1万年！但这还不能算穷举测试，还要输入一切不合法的数据。可见，穷举地输入测试数据进行黑盒测试是不可能的。,26,2.白盒法 该方法把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。,27,白盒法也不可能进行穷举测试，企图遍历所有的路径，往往是做不到的。如测试一个循环20次的嵌套的IF语句，循环体中有5条路径。测试这个程序的执行路径为520，约为1014，如果每毫秒完成一个路径的测试，测试此程序需3170年！对于白盒测试，即使
11、每条路径都测试了，程序仍可能有错。例如要求编写一个升序的程序，错编成降序程序（功能错），就是穷举路径测试也无法发现。再如由于疏忽漏写了路径，白盒测试也发现不了。,28,所以，黑盒法和白盒法都不能使测试达到彻底。为了用有限的测试发现更多的错误，需精心设计测试用例。黑盒法、白盒法是设计测试用例的基本策略，每一种方法对应着多种设计测试用例的技术，每种技术可达到一定的软件质量标准要求。,29,Contents,软件危机(1.2),7.3 软件测试过程,30,31,集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。验收测试（确认测试）则是要检查已实现的软件是否满足了需求规格
12、说明中确定了的各种需求，以及软件配置是否完全、正确。系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。,32,单元测试(Unit Testing),单元测试又称模块测试，是针对软件设计的最小单位 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。,33,1.单元测试的内容,在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输
13、入，都能鉴别和响应。,34,35,(1)模块接口测试,在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：调用本模块的输入参数是否正确；本模块调用子模块时输入给子模块的参数是否正确；全局量的定义在各模块中是否一致；,36,在做内外存交换时要考虑：文件属性是否正确；OPEN与CLOSE语句是否正确；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写输入错误，IO错误是否检查并做了处理。,37,(2)局部数据结构测试,不正确或不一致的数据类型说明使用尚未赋值或尚未初始化的变量错误的初始值或错误的缺省值变量名拼写错或书写错不一致的数
14、据类型全局数据对模块的影响,38,(3)路径测试,选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试可以发现大量的路径错误。,39,(4)错误处理测试,出错的描述是否难以理解出错的描述是否能够对错误定位显示的错误与实际的错误是否相符对错误条件的处理正确与否在对错误进行处理之前，错误条件是否已经引起系统的干预等,40,(5)边界测试,注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。如果对模块运行时间有要求的话，还要专门进行关
15、键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。,41,2.单元测试的步骤,模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。驱动模块(driver)存根模块(stub)存根模块,42,43,如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。,44,集成测试（Integrated Testing）,集成测试(集成测试、联合测试）通
16、常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；一个模块的功能是否会对另一个模块的功能产生不利的影响；,45,各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。,46,子系统的集成测试特别称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。通常，把模块组装成为系统的方式有两种 一次性组装方式 增殖式组
17、装方式,47,1.一次性组装方式,它是一种非增殖式组装方式。也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。,48,49,2.增殖式组装方式,这种组装方式又称渐增式组装首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统在组装的过程中边连接边测试，以发现连接过程中产生的问题通过增殖逐步组装成为要求的软件系统。,50,(1)自顶向下的增殖方式,这种组装方式将模块按系统程序结构，沿控制层次自顶向下进行组装。自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。选用按深度方向组装的方式，可以首先实现和验证一
18、个完整的软件功能。,51,52,(2)自底向上的增殖方式,这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要存根模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。,53,自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。,54,(3)混合增殖式测试,衍变的自顶向下的增殖测试 首先对输入输出模块和引入新算法模块进行测试;再自底向上组装成为功能相当完整且相对独立的子系统;然后由主模块开始自顶向下进行增殖测
19、试。,55,自底向上自顶向下的增殖测试 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;然后对含写操作的子系统做自顶向下的组装与测试。,56,关键模块问题,在集成测试时，应当确定关键模块，对这些关键模块及早进行测试。关键模块的特征：满足某些软件需求；在程序的模块结构中位于较高的层次（高层控制模块）；较复杂、较易发生错误；有明确定义的性能要求。,57,验收测试（Validation Testing）,验收测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件验收测试的基础。,58,5
20、9,1.进行有效性测试（黑盒测试）,有效性测试是在模拟的环境(可能就是开发的环境)下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。,60,通过实施预定的测试计划和测试步骤，确定 软件的特性是否与需求相符；所有的文档都是正确且便于使用；同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试,61,在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。测试
21、结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。,62,2.软件配置复查,软件配置复查的目的是保证 软件配置的所有成分都齐全；各方面的质量都符合要求；具有维护阶段所必需的细节；而且已经编排好分类的目录。应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。,63,验收测试（Acceptance Testing）,在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用生产中的实际数据进行测试。,6
22、4,在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。验收测试应交付的文档有：验收测试分析报告 最终的用户手册和操作手册 项目开发总结报告。,65,系统测试（System Testing）,系统测试，是将通过验收测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和验收测试。系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统的定义不符合或与之矛盾的地方。,66,测试和测试,在软件交付使用之后，用户将如何实际使用程序
23、，对于开发者来说是无法预测的。测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。,67,测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重产品的界面和特色。测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在验收测试过程中产品达到一定的稳定和可靠程度之后再开始。,68,测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，测试是在开发者无法控制的环境下进行的软件现场应用。在测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。,69,测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当测试达到一定的可靠程度时，才能开始测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。,
