《(2.7)--07章 实现软件工程.ppt》由会员分享，可在线阅读，更多相关《(2.7)--07章 实现软件工程.ppt（158页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第第7 7章章 实实 现现软件工程导论（第软件工程导论（第6版）版）第第7 7章章 实现实现实现编码测试编码编码就是把软件设计结果翻译成用某种程序设计语言书写的程序，是对设计的进一步具体化。程序的质量主要取决于软件设计的质量。软件测试测试是保证软件质量的关键步骤，是对软件规格说明、设计和编码的最后复审。引 言章节目录章节目录7.1 编码编码7.2 软件测试基础软件测试基础7.3 单元测试单元测试7.4 集成测试集成测试7.5 确认测试确认测试7.6 白盒测试技术白盒测试技术7.7 黑盒测试技术黑盒测试技术7.8 调试调试7.9 软件可靠性软件可靠性主 要内 容7.1 编码编码7.2 软件测试基
2、础软件测试基础7.3 单元测试单元测试7.4 集成测试集成测试7.5 确认测试确认测试7.1 编码编码 程序设计语言是人和计算机通信的最基本的工具，会影响人的思维和解题方式，影响人和计算机通信的方式和质量，影响其他人阅读和理解程序的难易程度。选择适宜的程序设计语言的原因：选择适宜的程序设计语言的原因：l根据设计去完成编码时，困难最少；l可以减少需要的程序测试量；l可以得到更容易阅读和更容易维护的程序。7.1.1 选择程序设计语言选择程序设计语言7.1 编码编码高级语言优于汇编语言：l汇编语言编码需要把软件设计翻译成机器操作的序列，既困难又容易出差错；l高级语言写程序比用汇编语言写程序生产率可以
3、提高好几倍；l用高级语言写的程序容易阅读、容易测试、容易调试、容易维护。7.1.1 选择程序设计语言选择程序设计语言7.1 编码编码理想理想标准：准：l应该有理想的模块化机制，以及可读性好的控制结构和数据结构；l使编译程序能够尽可能多地发现程序中的错误；l应该有良好的独立编译机制。7.1.1 选择程序设计语言选择程序设计语言实用用标准：准：l系统用户的要求；l可以使用的编译程序；l可以得到的软件工具；l工程规模；l程序员的知识；l软件可移植性要求；l软件的应用领域。7.1 编码编码 源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准，为了做到这一点，应该遵循下述规则。1.程序内部的文档程
4、序内部的文档 所谓程序内部的文档包括恰当的标识符、适当的注解和程序的视觉组织等。7.1.2 编码风格编码风格7.1 编码编码l标识符：含义鲜明的名字、缩写规则一致、为名字加注解；l注解：正确性，简要描述模块的功能、主要算法、接口特点、重要数据以及开发简史或解释包含这段代码的必要性；l视觉组织：适当的阶梯形式使程序的层次结构清晰明显。7.1.2 编码风格编码风格2.数据说明数据说明 数据说明的原则：l数据说明的次序应该标准化；l当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量；l如果设计时使用了一个复杂的数据结构，则应该用注解说明用程序设计语言实现这个数据结构的方法和特点。7.1 编码
5、编码7.1.2 编码编码风格风格3.语句构造语句构造 下述语句构造的原则有助于使语句简单明了：l不要为了节省空间而把多个语句写在同一行；l尽量避免复杂的条件测试；l尽量减少对“非”条件的测试；l避免大量使用循环嵌套和条件嵌套；l利用括号使逻辑表达式或算术表达式的运算次序清晰直观。7.1 编码编码7.1.2 编码风格编码风格4.输入输出输入输出 在设计和编写程序时需考虑有关输入输出风格的规则：l对所有输入数据都进行检验；l检查输入项重要组合的合法性；l保持输入格式简单；l使用数据结束标记，不要要求用户指定数据的数目；7.1 编码编码7.1.2 编码风格编码风格4.输入输出输入输出 在设计和编写程
6、序时需考虑有关输入输出风格的规则：l明确提示交互式输入的请求，详细说明可用的选择或边界数值；l程序设计语言对格式有严格要求时，应保持输入格式一致；l设计良好的输出报表；l给所有输出数据加标志。7.1 编码编码7.1.2 编码风格编码风格5.效率效率 效率效率主要指处理机时间和存储器容量两个方面。l效率是性能要求，因此应该在需求分析阶段确定效率方面的要求；l效率是靠好设计来提高的；l程序的效率和程序的简单程度是一致的，不要牺牲程序的清晰性和可读性来不必要地提高效率。7.1 编码编码7.1.2 编码风格编码风格5.效率 (1)程序运行时间 写程序的风格会对程序的执行速度和存储器要求产生影响，应遵循
7、的规则如下：写程序之前先简化算术的和逻辑的表达式；仔细研究嵌套的循环，以确定是否有语句可以从内层往外移；尽量避免使用多维数组；7.1 编码编码7.1.2 编码风格编码风格5.效率 (1)程序运行时间 写程序的风格会对程序的执行速度和存储器要求产生影响，应遵循的规则如下：尽量避免使用指针和复杂的表；使用执行时间短的算术运算；不要混合使用不同的数据类型；尽量使用整数运算和布尔表达式。7.1 编码编码7.1.2 编码风格编码风格5.效率效率(2)存储器效率存储器效率l在大型计算机中必须考虑操作系统页式调度的特点，一般说来，使用能保持功能域的结构化控制结构，是提高效率的好方法。l在微处理机中如果要求使
8、用最少的存储单元，则应选用有紧缩存储器特性的编译程序，在非常必要时可以使用汇编语言。l提高执行效率的技术通常也能提高存储器效率。提高存储器效率的关键同样是“简单”。7.1 编码编码7.1.2 编码风格编码风格5.效率(3)输入输出的效率输入输出的效率 简单清晰是提高人机通信效率的关键。从写程序的角度看，却有些简单的原则可以提高输入输出的效率。l所有输入输出都应该有缓冲，以减少用于通信的额外开销；l对二级存储器(如磁盘)应选用最简单的访问方法；l二级存储器的输入输出应该以信息组为单位进行；l如果“超高效的”输入输出很难被人理解，则不应采用这种方法。这些原则对于软件工程的设计和编码两个阶段都适用。
9、7.1 编码编码7.1.2 编码风格编码风格7.1 编码编码7.1.2 编码风格编码风格1、选择程序设计语言2、编码风格本节小结本节小结主 要内 容7.1 编码编码7.2 软件测试基础软件测试基础7.3 单元测试单元测试7.4 集成测试集成测试7.5 确认测试确认测试G.Myers给出的关于测试的一些规则：l测试是为了发现程序中的错误而执行程序的过程。l好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。l成功的测试是发现了至今为止尚未发现的错误的测试。测测试试的正确定义是“为了发现程序中的错误而执行程序的过程”。测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发
10、现的错误潜藏在程序中。7.2 软件测试基础软件测试基础7.2.1 软件测试的目标软件测试的目标 主要的软件测试准则如下：l所有测试都应该能追溯到用户需求；l应该远在测试开始之前就制定出测试计划；l把Pareto原理应用到软件测试中；l应该从“小规模”测试开始，并逐步进行“大规模”测试；l穷举测试是不可能的；l为了达到最佳的测试效果，应该由独立的第三方从事测试工作。7.2 软件测试基础软件测试基础7.2.2 软件测试的准则软件测试的准则 黑黑盒盒测测试试（又称功能测试）把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试，只检查程序功能是否能按照规格说明书的规
11、定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息（例如数据库或文件）的完整性。7.2 软件测试基础软件测试基础7.2.3 软件测试的方法软件测试的方法程序接口 白白盒盒测测试试（又称结构测试）是把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。7.2 软件测试基础软件测试基础7.2.3 软件测试的方法软件测试的方法程序结构程序结构和处理算和处理算法法 根据第4条测试准则，测试过程也必须分步骤进行，后一个步骤在逻辑上是前一个步骤的继续。大型软件系
12、统通常由若干个子系统组成，每个子系统又由许多模块组成，因此，大型软件系统的测试过程基本上由模模块块测测试试、子子系系统统测测试试、系统测试系统测试、验收测试验收测试和平行运行平行运行等五个步骤组成。7.2 软件测试基础软件测试基础7.2.4 测试步骤测试步骤 1.模块测试模块测试 在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单单元元测测试试。在这个测试步骤中所
13、发现的往往是编码和详细设计的错误。7.2 软件测试基础软件测试基础7.2.4 测试步骤测试步骤2.子系统测试子系统测试 子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此，这这个个步步骤着重测试模块的接口骤着重测试模块的接口。7.2 软件测试基础软件测试基础7.2.4 测试步骤测试步骤3.系统测试系统测试 系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误，
14、也可能发现需求说明中的错误。7.2 软件测试基础软件测试基础7.2.4 测试步骤测试步骤 子系统测试和系统测试，都兼有检测和组装两重含义，通常称为集成集成测试。4.验收测试验收测试 验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用用户户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在在这这个个测测试试步步骤中发现的往往是系统需求说明书中的错误骤中发现的往往是系统需求说明书中的错误。验收测试也称为确认测试确认测试。7.2 软件测试基础软件测试基础7.2.4 测试步骤测试步骤5.平行运行
15、平行运行 所谓平行运行平行运行就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。这样做的具体目的有如下几点。(1)可以在准生产环境中运行新系统而又不冒风险。(2)用户能有一段熟悉新系统的时间。(3)可以验证用户指南和使用手册之类的文档。(4)能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。7.2 软件测试基础软件测试基础7.2.4 测试步骤测试步骤上图描绘了测试阶段的信息流，这个阶段的输入信息有两类：(1)软件配置，包括需求说明书、设计说明书和源程序清单等；(2)测试配置，包括测试计划和测试方案。7.2 软件测试基础软件测试基础7.2.5 测
16、试阶段的信息流测试阶段的信息流 如果经常出现要求修改设计的严重错误，那么软件的质量和可靠性是值得怀疑的，应该进一步仔细测试。如果看起来软件功能完成得很正常，遇到的错误也很容易改正，则仍然应该考虑两种可能：(1)软件的可靠性是可以接受的；(2)所进行的测试尚不足以发现严重的错误。7.2 软件测试基础软件测试基础7.2.5 测试阶段的信息流测试阶段的信息流如果经过测试，一个错误也没有被发现，则很可能是因为对测试配置思考不充分，以致不能暴露软件中潜藏的错误。软件件可可靠靠性性模模型型使用错误率数据估计将来出现错误的情况，并进而对软件可靠性进行预测。7.2 软件测试基础软件测试基础7.2.5 测试阶段
17、的信息流测试阶段的信息流1、软件测试的目标2、软件测试的准则3、软件测试的方法4、测试步骤5、测试阶段的信息流本节小结本节小结主 要内 容7.1 编码编码7.2 软件测试基础软件测试基础7.3 单元测试单元测试7.4 集成测试集成测试7.5 确认测试确认测试l单元测试集中检测软件设计的最小单元模块。l单元测试和编码属于软件过程的同一个阶段。l在源程序代码通过编译程序的语法检查后，可以用详细设计描述作指南，对重要的执行通路进行测试，以便发现模块内部的错误。l可以应用人工测试和计算机测试这样两种不同类型的测试方法，完成单元测试工作。l单元测试主要使用白盒测试技术，而且对多个模块的测试可以并行地进行
18、。7.3 单元测试单元测试 在单元测试期间着重从以下5个方面对模块进行测试。1.模块接口模块接口对模块接口进行测试时主要检查以下几个方面：l参数的数目、次序、属性或单位系统与变元是否一致；l是否修改了只作输入用的变元；l全局变量的定义和用法在各个模块中是否一致。7.3 单元测试单元测试7.3.1 测试重点测试重点2.局部数据结构局部数据结构对于模块来说，局部数据结构是常见的错误来源。应该仔细设计测试方案，以便发现局部数据说明、初始化、默认值等方面的错误。3.重要的执行通路重要的执行通路由于通常不可能进行穷尽测试，因此，在单元测试期间选择最有代表性、最可能发现错误的执行通路进行测试是十分关键的。
19、应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。7.3.1 测试重点测试重点7.3 单元测试单元测试4.出错处理通路出错处理通路 好的设计应该能预见出现错误的条件，并且设置适当的处理错误的通路。不仅应该在程序中包含出错处理通路，而且应该认真测试这种通路。评价出错处理通路应该着重测试下述一些可能发生的错误。(1)对错误的描述是难以理解的；(2)记下的错误与实际遇到的错误不同；(3)在对错误进行处理之前，错误条件已经引起系统干预；(4)对错误的处理不正确；(5)描述错误的信息不足以帮助确定造成错误的位置。7.3 单元测试单元测试7.3.1 测试重点测试重点5.边界
20、条件边界条件l边界测试是单元测试中最后的也可能是最重要的任务。l软件常常在它的边界上失效，例如，处理n元数组的第n个元素时，或做到i次循环中的第i次重复时，往往会发生错误。l使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案，非常可能发现软件中的错误。7.3 单元测试单元测试7.3.1 测试重点测试重点 代码检查代码检查是指由审查小组正式对源程序进行人工测试。它是一种非常有效的程序验证技术，对于典型的程序来说，可以查出30%70%的逻辑设计错误和编码错误。审查小组最好由下述4人组成。(1)组长，应该是一个很有能力的程序员，而且没有直接参与这项工程；(2)程序的设
21、计者；(3)程序的编写者；(4)程序的测试者。7.3 单元测试单元测试7.3.2 代码审查代码审查在审查会上由程序的编写者解释他是怎样用程序代码实现设计的，通常是逐个语句地讲述程序的逻辑，小组其他成员仔细倾听他的讲解，并力图发现其中的错误。审查会上需要对照程序设计常见错误清单，分析审查这个程序。当发现错误时由组长记录下来，审查会继续进行(审审查查小小组组的的任任务务是是发发现现错错误而不是改正错误误而不是改正错误)。审查会另外一种常见的进行方法，称为预预排排：由一个人扮演“测试者”，其他人扮演“计算机”。会前测试者准备好测试方案，会上由扮演计算机的成员模拟计算机执行被测试的程序。7.3 单元测
22、试单元测试7.3.2 代码审查代码审查测试方案在代码审查中起一种促进思考引起讨论的作用。在大多数情况下，通过向程序员提出关于他的程序的逻辑和他编写程序时所做的假设的疑问，可以发现的错误比由测试方案直接发现的错误还多。代码审查比计算机测试优越的是：一次审查会上可以发现许多错误；用计算机测试的方法发现错误之后，通常需要先改正这个错误才能继续测试，即：采用代码审查的方法可以减少系统验证的总工作量。人工测试和计算机测试是互相补充，相辅相成的，缺少其中任何一种方法都会使查找错误的效率降低。7.3 单元测试单元测试7.3.2 代码审查代码审查模块不是一个独立的程序，因此必须为每个单元测试开发驱动软件和(或
23、)存根软件。驱动程序是一个“主程序”，它接收测试数据，把这些数据传送给被测试的模块，并且印出有关的结果。存根程序代替被测试的模块所调用的模块，它使用被它代替的模块的接口，可能做最少量的数据操作，印出对入口的检验或操作结果，并且把控制归还给调用它的模块。7.3 单元测试单元测试7.3.3 计算机测试计算机测试 右图是一个正文加工系统的部分层次图，假定要测试编号为3.0的关键模块正文编辑模块。正文编辑模块不是一个独立的程序，需要有一个测试驱动程序来调用它。这个驱动程序说明必要的变量，接收测试数据字符串，设置正文编辑模块的编辑功能。并且需要有存根程序简化地模拟正文编辑模块的下层模块来完成具体的编辑功
24、能。7.3 单元测试单元测试7.3.3 计算机测试计算机测试测试时，设置修改(CHANGE)和添加(APPEND)两种编辑功能，用控制变量CFUNCT标记要求的编辑功能，而且只用一个存根程序模拟正文编辑模块的所有下层模块。7.3 单元测试单元测试7.3.3 计算机测试计算机测试7.3 单元测试单元测试TEST STUB(*存根程序*)初始化；输出信息“进入了正文编辑程序”;输出“输入的控制信息是”CFUNCT;输出缓冲区中的字符串;IF CFUNCT=CHANGE THEN 把缓冲区中第二个字改为*ELSE 在缓冲区的尾部加?END IF;输出缓冲区中的新字符串;END TEST STUBTE
25、ST DRIVER(*驱动程序*)说明长度为2500个字符的一个缓冲区;把CFUNCT置为希望测试的状态;输入字符串;调用正文编辑块;停止或再次初启;END TEST DRIVER7.3.3 计算机测试计算机测试1、测试重点2、代码审查3、计算机测试本节小结本节小结主 要内 容7.4 集成测试集成测试7.5 确认测试确认测试7.6 白盒测试技术白盒测试技术7.7 黑盒测试技术黑盒测试技术7.8 调试调试集成测试是测试和组装软件的系统化技术。由模块组装成程序时有两种方法。一种方法一种方法是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，这种方法称为非非渐增式测试方法渐增式测试
26、方法；另一种方法是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法称为渐增式测试渐增式测试，这种方法实际上同时完成单元测试和集成测试。7.4 集成测试集成测试集成测试是测试和组装软件的系统化技术。由模块组装成程序时有两种方法。一种方法一种方法是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，这种方法称为非渐增式测试方法非渐增式测试方法；另一种方法是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法称为渐增式
27、测渐增式测试试，这种方法实际上同时完成单元测试和集成测试。7.4 集成测试集成测试非非渐渐增增式式测测试试把所有模块放在一起，作为一个整体来测试。测试时会遇到许多的错误，改正错误非常困难，因为在庞大的程序中想要诊断定位一个错误非常困难，而且改正一个错误之后，马上又会遇到新的错误，这个过程会继续下去，没有尽头。7.4 集成测试集成测试渐渐增增式式测测试试与“一步到位”的非渐增式测试相反，它把程序划分成小段来构造和测试，在这个过程中比较容易定位和改正错误；对接口可以进行更彻底的测试；可以使用系统化的测试方法。因此，目前在进行集成测试时普遍采用渐增式测试方法。当使用渐增方式把模块结合到程序中去时，有
28、自自顶顶向向下下和自自底底向向上上两种集成策略。7.4 集成测试集成测试l自自顶顶向向下下集集成成方方法法是从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。在把附属于（及最终附属于）主控制模块的那些模块组装到程序结构中去时，或者使用深度优先的策略，或者使用宽度优先的策略。l深深度度优优先先的的结结合合方方法法先组装在软件结构的一条主控制通路上的所有模块。选择一条主控制通路取决于应用的特点，并且有很大任意性。l宽宽度度优优先先的的结结合合方方法法是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。7.4 集成测试集成测试7.4.1 自顶向下集成自顶向下集成模块
29、结合进软件结构的具体过程由下述4个步骤完成：对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块；根据选定的结合策略(深度优先或宽度优先)，每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序)；在结合进一个模块的同时进行测试；为了保证加入模块没有引进新的错误，可能需要进行回归测试(即全部或部分地重复以前做过的测试)。从开始不断地重复进行上述过程，直到构造起完整的软件结构为止。7.4 集成测试集成测试7.4.1 自顶向下集成自顶向下集成l自自顶顶向向下下的结合策略能够在测试的早期对主要的控制或关键的抉择进行检验。在一个分解得好的软件结构中，关键的抉择位
30、于层次系统的较上层，因此首先碰到。l如果选择深深度度优优先先的结合方法，可以在早期实现软件的一个完整的功能并且验证这个功能。l在自顶向下测试的初期，存根程序代替了低层次的模块，因此，在软件结构中没有重要的数据自下往上流。为了解决这个问题，测试人员有两种选择：把许多测试推迟到用真实模块代替了存根程序以后再进行；从层次系统的底部向上组装软件。7.4 集成测试集成测试7.4.1 自顶向下集成自顶向下集成 自底向上测试自底向上测试从“原子”模块开始组装和测试。因为是从底部向上结合模块，总能得到所需的下层模块处理功能，所以不需要存根程序。用下述步骤可以实现自底向上的结合策略。把低层模块组合成实现某个特定
31、的软件子功能的族；写一个驱动程序(用于测试的控制程序)，协调测试数据的输入和输出；对由模块组成的子功能族进行测试；去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。上述第步实质上构成了一个循环。7.4 集成测试集成测试7.4.2 自底向上集成自底向上集成 右图描绘了自底向上的结合过程。首先把模块组合成族1、族2和族3，使用驱动程序(虚线方框)对每个子功能族进行测试。族1和族2中的模块附属于模块Ma,去掉驱动程序D1和D2，把这两个族直接同Ma连接起来。类似地，在和模块Mb结合之前去掉族3的驱动程序D3。最终Ma和Mb这两个模块都与模块Mc结合起来。随着结合向上移动，对
32、测试驱动程序的需要减少了。7.4 集成测试集成测试7.4.2 自底向上集成自底向上集成l自顶向下测试方法自顶向下测试方法的主要优点主要优点是不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。l自顶向下测试方法自顶向下测试方法的主要缺点主要缺点是需要存根程序，可能遇到与此相联系的测试困难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力。l自底向上测试方法的优缺点与上述自顶向下测试方法的优缺点刚好相反。自底向上测试方法的优缺点与上述自顶向下测试方法的优缺点刚好相反。7.4 集成测试集成测试7.4.3 不同集成测试策略的比较不同
33、集成测试策略的比较 一般说来，纯粹自顶向下或纯粹自底向上的策略可能都不实用，人们在实践中创造出许多混合策略。(1)改改进进的的自自顶顶向向下下测测试试方方法法。基本上使用自顶向下的测试方法，但是在早期使用自底向上的方法测试软件中的少数关键模块。一般的自顶向下方法所具有的优点在这种方法中也都有，而且能在测试的早期发现关键模块中的错误；但是，它的缺点也比自顶向下方法多一条，即测试关键模块时需要驱动程序。7.4 集成测试集成测试7.4.3 不同集成测试策略的比较不同集成测试策略的比较 一般说来，纯粹自顶向下或纯粹自底向上的策略可能都不实用，人们在实践中创造出许多混合策略。(2)混混合合法法。对软件结
34、构中较上层使用的自顶向下方法与对软件结构中较下层使用的自底向上方法相结合。这种方法兼有两种方法的优点和缺点，当被测试的软件中关键模块比较多时，这种混合法可能是最好的折衷方法。7.4 集成测试集成测试7.4.3 不同集成测试策略的比较不同集成测试策略的比较l在集成测试过程中，每当一个新模块结合进来时，程序就发生了变化：建立了新的数据流路径，可能出现了新的I/O操作，激活了新的控制逻辑。在集成测试的范畴中，回回归归测测试试是指重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。7.4 集成测试集成测试7.4.4 回归测试回归测试l回回归归测测试试就是用于保证由于调试或其他原
35、因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。l回回归归测测试试可以通过人工地进行，也可以使用自动化的捕获回放工具自动进行。利用捕获回放工具，软件工程师能够捕获测试用例和实际运行结果，然后可以回放（即重新执行测试用例），并且比较软件变化前后所得到的运行结果。7.4 集成测试集成测试7.4.4 回归测试回归测试 回归测试集（已执行过的测试用例子集）包括下述3类不同的测试用例。(1)检测软件全部功能的代表性测试用例。(2)专门针对可能受修改影响的软件功能的附加测试。(3)针对被修改过的软件成分的测试。在集成测试过程中，回归测试用例的数量可能变得非常大。因此，应该把回归测试集设计成只包
36、括可以检测程序每个主要功能中的一类或多类错误的那样一些测试用例。7.4 集成测试集成测试7.4.4 回归测试回归测试1、自顶向下集成2、自底向上集成3、不同集成测试策略的比较4、回归测试本节小结本节小结主 要内 容7.4 集成测试集成测试7.5 确认测试确认测试7.6 白盒测试技术白盒测试技术7.7 黑盒测试技术黑盒测试技术7.8 调试调试l确认测试确认测试也称为验收测试，它的目标是验证验证软件的有效性。l通常，验验证证指的是保证软件正确地实现了某个特定要求的一系列活动；确认确认指的是为了保证软件确实满足了用户需求而进行的一系列活动。l软软件件有有效效性性的一个简单定义是：如果软件的功能和性能
37、如同用户所合理期待的那样，软件就是有效的。l需求分析阶段产生的软件需求规格说明书，准确地描述了用户对软件的合理期望，因此是软件有效性的标准，也是进行确认测试的基础。7.5 确认测试确认测试 确认测试必须有用户积极参与，或以用户为主进行。用户应该参与设计测试方案，使用用户界面输入测试数据并且分析评价测试的输出结果。确认测试通常使用黑盒测试法。应该仔细设计测试计划和测试过程，测试计划包括要进行的测试的种类及进度安排，测试过程规定了用来检测软件是否与需求一致的测试方案。7.5 确认测试确认测试7.5.1 确认测试的范围确认测试的范围 通过测试和调试要保证软件能满足所有功能要求，能达到每个性能要求，文
38、档资料是准确而完整的，此外，还应该保证软件能满足其他预定的要求（例如安全性、可移植性、兼容性和可维护性等）。确认测试有下述两种可能的结果:(1)功能和性能与用户要求一致，软件是可以接受的。(2)功能和性能与用户要求有差距。7.5 确认测试确认测试7.5.1 确认测试的范围确认测试的范围软件配置复件配置复查是确认测试的一个重要内容。复查的目的是保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。除了按合同规定的内容和要求，由人工审查软件配置之外，在确认测试过程中还应该严格遵循用户指南及其他操作程序，以便检验这些使用手册的完整性和正确性。
39、必须仔细记录发现的遗漏或错误，并且适当地补充和改正。7.5 确认测试确认测试7.5.2 软件配置复查软件配置复查l广义上对测试有着三个传统的称呼：Alpha()、Beta()和Gamma()，用来标识测试的阶段与范围。lAlpha()版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug（漏洞）较多，普通用户最好不要安装。主要是开发者自己对产品进行测试，检查产品是否存在缺陷、错误，验证产品功能与说明书、用户手册是否一致。lAlpha测测试试指的是内测，即现在说的 CB，即开发团队内部测试的版本或者有限用户的体验测试版本。7
40、.5 确认测试确认测试7.5.3 Alpha和和Beta测试测试lBeta()版本相对于版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。lBeta()测试指的是公测，即针对所有用户公开的测试版本。l做过一些修改，成为正式发布的候选版本时（现在叫做 RC-Release Candidate），叫做 Gamma。7.5 确认测试确认测试7.5.3 Alpha和和Beta测试测试l如果一个软件
41、是为许多客户开发的，绝大多数软件开发商都使用被称为Alpha测试测试和Beta测试测试来发现那些看起来只有最终用户才能发现的错误。lAlpha测测试试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。lAlpha测试测试是在受控的环境中进行的。lBeta测测试试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场。lBeta测试测试是软件在开发者不能控制的环境中的“真实”应用。7.5 确认测试确认测试7.5.3 Alpha和和Beta测试测试1、确认测试的范围2、软件配置复查3、Alpha
42、和Beta测试本节小结本节小结主 要内 容7.5 确认测试确认测试7.6 白盒测试技术白盒测试技术7.7 黑盒测试技术黑盒测试技术7.8 调试调试7.9 软件可靠性软件可靠性 7.6 白盒测试技术白盒测试技术l通常把测试数据和预期的输出结果称为测试用例测试用例。l不同的测试数据发现程序错误的能力差别很大，为了提高测试效率降低测试成本，应该选用高效的测试数据。因为不可能进行穷尽的测试，所以选用少量“最有效的”测试数据，做到尽可能完备的测试就更重要了。l设计测试方案的基本目标是，确定一组最可能发现某个错误或某类错误的测试数据。已经研究出许多设计测试数据的技术，这些技术各有优缺点；同一种技术在不同的
43、应用场合效果可能相差很大，因此，通常需要联合使用多种设计测试数据的技术。7.6 白盒测试技术白盒测试技术 逻逻辑辑覆覆盖盖是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。1.语句覆盖语句覆盖 语语句句覆覆盖盖的含义是，选择足够多的测试数据，使被测程序中每个语句至少执行一次。7.6.1 逻辑覆盖逻辑覆盖7.6 白盒测试技术白盒测试技术 右图为被测试模块的流程图为了使每个语句都执行一次，程序的执行路径应该是sacbed,为此只需要输入下面的测试数据(实际上X可以是任意实数)：A=2，B=0，X=4。7.6.1 逻辑覆盖逻辑覆盖7.6 白盒测试技术白盒测试技术7.6.1 逻辑覆盖
44、逻辑覆盖 语句覆盖对程序的逻辑覆盖很少，上例中两个判定条件都只测试了条件为真的情况，如果条件为假时处理有错误，显然不能发现。语句覆盖只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值时的情况。为了执行sacbed路径，以测试每个语句，只需两个判定表达式(A1)AND(B=0)和(A=2)OR(X1)都取真值，因此使用上述一组测试数据就够了。但是，如果程序中把第一个判定表达式中的逻辑运算符AND错写成OR，或把第二个判定表达式中的条件X1误写成X1,A1,B=0,B0；在b点有下述各种结果出现：A=2,A2,X1,X1；7.6 白盒测试技术白盒测试技术7.6.1 逻辑覆盖逻辑覆盖
45、只需要使用下面两组测试数据就可以达到上述覆盖标准：A=2,B=0,X=4(满足A1,B=0,A=2和X1，执行路径sacbed)A=1,B=1,X=1(满足A1,B0,A2和X1，执行路径sabd)条件覆盖通常比判定覆盖强，但满足条件覆盖的测试数据不一定满足判定覆盖。例如，上面两组测试数据也同时满足判定覆盖标准。但是，如果使用下面两组测试数据，则只满足条件覆盖标准并不满足判定覆盖标准(第二个判定表达式的值总为真)：A=2,B=0,X=1(满足A1,B=0,A=2和X1，执行路径sacbed)A=1,B=1,X=2(满足A1,B0,A2和X1，执行路径sabed)7.6 白盒测试技术白盒测试技术
46、7.6.1 逻辑覆盖逻辑覆盖4.判定判定/条件覆盖条件覆盖 判定判定/条件覆盖条件覆盖是是一种能同时满足判定覆盖和条件覆盖的逻辑覆盖，它的含义是，选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。对于上例而言，下述两组测试数据满足判定/条件覆盖标准：A=2,B=0,X=4 A=1,B=1,X=1 但是，这两组测试数据也就是为了满足条件覆盖标准最初选取的两组数据，因此，有时判定/条件覆盖也并不比条件覆盖更强。7.6 白盒测试技术白盒测试技术7.6.1 逻辑覆盖逻辑覆盖5.条件组合覆盖条件组合覆盖 条条件件组组合合覆覆盖盖是更强的逻辑覆盖
47、标准，它要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。对于上例，共有8种可能的条件组合，它们分别是：(1)A1,B=0 (2)A1,B0(3)A1,B=0 (4)A1,B0(5)A=2,X1 (6)A=2,X1(7)A2,X1 (8)A2,X17.6 白盒测试技术白盒测试技术7.6.1 逻辑覆盖逻辑覆盖6.点覆盖点覆盖 从对程序路径的覆盖程度分析，能够提出下述一些主要的逻辑覆盖标准。图论中点覆盖点覆盖的定义如下：如果连通图G的子图G是连通的，而且包含G的所有结点，则称G是G的点覆盖。在第6.5节中已经讲述了从程序流程图导出流图的方法。在正常情况下流图是连通的有
48、向图。满足点覆盖标准要求选取足够多的测试数据，使得程序执行路径至少经过流图的每个结点一次，由于流图的每个结点与一条或多条语句相对应，显然，点覆盖标准和语句覆盖标准是相同的点覆盖标准和语句覆盖标准是相同的。7.6 白盒测试技术白盒测试技术7.6.1 逻辑覆盖逻辑覆盖7.边覆盖和路径覆盖边覆盖和路径覆盖 图论中边覆盖边覆盖的定义是：如果连通图G的子图G是连通的，而且包含G的所有边，则称G是G的边覆盖。为了满足边覆盖的测试标准，要求选取足够多测试数据，使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。通常边覆盖和判定覆盖是一致的。路径覆盖路径覆盖的含义是，选取足够多测试数据，使
49、程序的每条可能路径都至少执行一次(如果程序图中有环，则要求每个环至少经过一次)。7.6 白盒测试技术白盒测试技术7.6.1 逻辑覆盖逻辑覆盖1、白盒测试概念2、逻辑覆盖技术本节小结本节小结7.6.2 控制结构测试控制结构测试7.6 白盒测试技术白盒测试技术1.基本路径测试基本路径测试1：i=1;total.input=total.valid=0;sum=0;2：DO WHILE valuei -9993：AND total.input=minimum6：AND valuei011：THEN average=sum/total.valid;12：ELSE average=-999;13:ENDI
50、F END average7.6 白盒测试技术白盒测试技术 计算流图的环形复杂度。计算流图的环形复杂度。环形复杂度定量度量程序的逻辑复杂性。使用第6.5.1小节讲述的3种方法之一计算环形复杂度。经计算，流图的环形复杂度为6。确定线性独立路径的基本集合。确定线性独立路径的基本集合。独立路径是指至少引入程序的一个新处理语句集合或一个新条件的路径，即独立路径至少包含一条在定义该路径之前不曾用过的边。7.6.2 控制结构测试控制结构测试1.基本路径测试基本路径测试7.6 白盒测试技术白盒测试技术 程序的环形复杂度决定了程序中独立路径的数量，而且这个数是确保程序中所有语句至少被执行一次所需的测试数量的上