06第十二讲测试A.

第十二讲测试（Testing)本讲（第七章）的主要内容一、软件测试及其目标二、软件测试准则三、测试阶段的信息流四、测试方法五、测试阶段一、Myers的软件测试的定义测试是为了发现程序中的错误而执行程序的过程；好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；成功的测试是发现了迄今为止尚未发现的错误的测试。测试的意义和几点说明软件质量保证的最重要手段是否达到需求说明的功能和预期的指标测试耗时费力，应用最小的测试代价获得最大的测试效果。测试是为了发现错误，不是为了证明程序无错误。测试不能证明程序中没有错误。测试的可信度（dependability)问题。“Testingistheunavoidablepartofanyresponsibleefforttodevelopasoftwaresystem.”—WilliamHowden“Optimismistheoccupationalhazardofprogramming;testingisthetreatment.”—KentBeck“Errorsaremorecommon,morepervasive,andmoretroublesomeinsoftwarethanothertechnologies.”—DavidParnas“Thefirstmistakethatpeoplemakeisthinkingthatthetestingteamisresponsibleforassuringquality.”—BrianMarick“Everyprogramdoessomethingright;itjustmaynotbethethingwewantittodo.”—weunknown二、软件测试准则所有的测试都应追溯到用户需求，从用户角度看，最严重的错误是不能满足需求。制定测试计划，并严格执行，排除随意性。测试计划在需求分析阶段就开始了，详细的测试用例在设计阶段确定。Pareto原则：所发现错误的80%很可能源于程序模块的20%中。测试应当从‘小规模’开始，逐步转向‘大规模’。穷举测试是不可能的（Exhaustivetesting）。由独立的第三方或专门的测试小组进行独立测试。Cont.测试用例由输入数据和相应的预期输出组成。测试用例不仅选用合理的输入数据，还要选择不合理的。不仅检查程序是否做了应该做的事，还应该检查是否不应该做的。长期保留测试用例，以便进行回归测试和维护。软件测试的对象软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。确认(Validation是否满足用户的需求？)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。需求规格说明的确认程序的确认(静态确认、动态确认)验证(Verification是否实现了所设计的要求？)，试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。测试信息流三、测试信息流软件配置：软件需求规格说明、软件设计规格说明、源代码等；测试配置：测试计划、测试用例、测试程序等；测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。测试结果分析：比较实测结果与预期结果，评价错误是否发生。排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档再测试：直到通过测试为止。通过收集和分析测试结果数据，对软件建立可靠性模型利用可靠性分析，评价软件质量：软件的质量和可靠性达到可以接受的程度；所做的测试不足以发现严重的错误；如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。测试与软件开发各阶段的关系软件开发过程是一个自顶向下，逐步细化的过程软件计划阶段定义软件作用域软件需求分析建立软件信息域、功能和性能需求、约束等软件设计把设计用某种程序设计语言转换成程序代码测试过程是依相反顺序安排的自底向上，逐步集成的过程。四、测试技术的分类静态测试代码会审codeinspection走查walk-through办公桌检查deskchecking例如：Yourdon结构化走通、IBM的Fagan检查动态测试黑盒测试白盒测试穷举和选择测试。静态测试人工测试，代码复审,即人工方式进行的代码复审。目的：检查程序的静态结构，找出编译不能发现的错误和人的主观认识上的偏差。范围：需求定义、设计文档、源代码（着重分析）特点：Myers的研究表明，对于某些类型的错误，静态测试更有效。经验表明，组织良好的代码复审可以发现程序中30%到70%的编码和逻辑设计错误。不存在错误定位问题。动态测试机器测试，在设定的测试数据上执行被测试程序的过程。目的:通过执行程序代码动态地验证结果的正确性。三个过程：设计测试用例；执行被测试程序；分析执行结果并发现错误。三个要素：程序、测试数据、需求定义两个方面：在测试数据上程序是对的；测试数据是正确的。黑盒测试（Black-BoxTesting)把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。又叫做功能测试或数据驱动测试。一般用于综合测试、系统测试等。黑盒测试在程序接口上进行，主要是为了发现以下错误:是否有不正确或遗漏了的功能?在接口上，输入能否正确地接受?能否输出正确的结果?是否有数据结构错误或外部信息(例如数据文件)访问错误?性能上是否能够满足要求?是否有初始化或终止性错误?用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。穷举测试是不可能的。假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：232×232＝264如果测试一组数据需要1毫秒，一年工作365×24小时，完成所有测试需5亿年。白盒测试（White-BoxTesting)把测试对象看做一个透明的盒子(Glassbox)，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此又称为结构测试或逻辑驱动测试。必须完全了解程序的内部结构和处理过程，才能按照程序内部的逻辑测试，以检验程序中每条路径是否正确，因此一般用于规模较小软件。使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性，等。对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环。包含的不同执行路径数达520条，对每一条路径进行测试需要1毫秒，假定一年工作365×24小时，要想把所有路径测试完，需3170年。灰盒测试（Gray-BoxTesting)使用推断的或不完整的结构或设计信息来进行黑盒测试。——DickBender在算法、内部状态、体系结构或其他程序行为等高级描述知识的基础上设计的测试。——DougHoffman测试涉及输入和输出，但是测试人员无法看到的有关代码或程序操作的信息影响着测试设计。——CemKaner对Web应用的灰盒测试灰盒测试非常适用于Web测试，因为它涉及到高层设计、环境和互操作条件。发现容易被黑盒和白盒测试所忽略的问题，如端到端的信息流问题、分布式硬/软件的配置问题及兼容性问题。善于发现与Web系统密切相关的具体环境问题。穷举测试（ExhaustiveTesting）定义：包含所有可能情况的测试。对于黑盒测试，必须对所有输入数据的各种可能值的排列组合都进行测试。对于白盒测试，程序中每条可能的路径在每种可能的输入数据下至少执行一次。穷举测试是不可能的对于黑盒是不可能的。例如，对C编译器进行测试，一方面要编出所有合法程序让它编译；另一方面又要编出一切不合法的程序，考察它能否指出程序的非法性质。显然，这两类程序的数量是无限的。对于白盒也是不可能的。选择测试仅选择一些具有代表的、典型的测试用例，进行有限的测试。以最少的测试用例发现最多的程序错误。五、软件测试的阶段1.单元测试（模块测试）：目的是保证每个模块作为一个单元能正确运行。主要测试编码和详细设计阶段的错误。2.子系统测试：把经过单元测试的模块放在一起形成子系统。注重模块接口。3.系统测试（集成测试）：测试由子系统组成的整个系统，不仅测试模块间的协调和通信能力。还要测试设计错误、需求说明中的功能错误。4.验收测试：确认系统能够满足用户的需求，方法同系统测试，主要强调用户的参与（alpha测试），测试需求说明中的功能错误。5.平行运行、beta测试软件测试的策略测试过程按4个步骤进行，即单元测试、组装测试、确认测试和系统测试。开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。组装测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。单元测试(UnitTesting)单元测试又称模块测试，是针对软件设计的最小单位─程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。单元测试的内容在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。单元测试主要评价模块的五个特性模块接口（具体细节参照P143）局部数据类型重要的执行通路出错处理通路影响以上特性的边界条件(1)模块接口测试在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：调用本模块的输入参数是否正确；本模块调用子模块时输入给子模块的参数是否正确；全局量的定义在各模块中是否一致；在做内外存交换时要考虑：文件属性是否正确；OPEN与CLOSE语句是否正确；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写／输入错误，I／O错误是否检查并做了处理。(2)局部数据结构测试不正确或不一致的数据类型说明使用尚未赋值或尚未初始化的变量错误的初始值或错误的缺省值变量名拼写错或书写错不一致的数据类型全局数据对模块的影响(3)路径测试选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试可以发现大量的路径错误。(4)错误处理测试出错的描述是否难以理解出错的描述是否能够对错误定位显示的错误与实际的错误是否相符对错误条件的处理正确与否在对错误进行处理之前，错误条件是否已经引起系统的干预等(5)边界测试注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。如果对