软件工程6章

3．集成测试有两种集成方式：非增量集成方式；增量集成方式。
6.4.1非增量集成方式
非增量集成方式是将经过单元测试的所有模块一次性全部组装起来，然后进行整体测试，最后得到所要求的软件系统。
这种集成方式容易出现混乱，开始可能遇到一大堆错误，错误定位非常困难，新旧错误交织在一起，会使测试变得更加困难。因此，一般不应采用这种集成方式。
2.自底向上集成优缺点
优点：
①只需设计驱动模块，不需要设计桩模块，测试用例的设计也相对简单。
②由于涉及到复杂算法和直接输入输出的模块最先得到组装和测试，可以在早期解决这些最容易出问题的部分；
③自底向上集成可以实施多个模块并行测试。
缺点：
对高层控制与判断进行测试的时间较晚，如果到测试的后期才发现整体存在较严重问题，就不得不进行较大的返工，此时代价将是巨大的。
④出现上溢出、下溢出、地址异常等。
3）模块中所有独立路径的测试
单元测试旨在找出如下错误：
①计算中常见的错误，有：运算符优先级错误、混合运算类型匹配错误、变量初值错、达不到精度、表达式不正确等。
②不正确的比较判断和不恰当的控制流常见的错误，有：被比较的对象的类型不匹配、错误地使用逻辑运算符及其优先级、计算误差引起的判断错误、循环终止条件不合适、错误地修改了循环变量、迭代发散时不能退出循环等。
④保证每一循环都在边界条件和一般条件至少各执行一次；
⑤验证所有内部数据结构的有效性。
几种典型的白盒测试技术
1．逻辑覆盖
逻辑覆盖是指设计测试用例对程序的内部分支逻辑结构进行部分或全部覆盖的技术。包括如下内容：
1）语句覆盖
2）判定覆盖
3）条件覆盖
4）判定/条件覆盖
5）条件组合覆盖
6）路径覆盖
6.6.2控制结构测试
自顶向下集成的优缺点
(1)自顶向下集成的特点是不需要驱动模块，但需要大量的桩模块。
(2)优点是能够尽早地验证程序的主要控制和判断机制，可以较早发现此类错误，从而减少以后的返工。
(3)缺点是在测试较高层模块时，低层模块采用较简单的桩模块来代替，不能反映实际情况，测试可能不充分。
2.自底向上集成
即从程序结构的最底层模块开始组装和测试。这种测试需要一定数量的驱动模块，而不需要桩模块。
教学内容
备注
第六章实现
6.1编码
6.1.1选择程序设计语言
程序的可靠性、可维护性和效率通常由程序设计语言、源代码的质量、和语言的实现机制决定的。
1.程序设计语言选择的理想标准
为了使程序容易测试和维护以减少软件的总成本,所选用的高级语言应该有理想的模块化机制,以及可读性好的控制结构和数据结构；为了便于调试和提高软件可靠性，语言特点应该使编译程序能够尽可能多地发现程序中的错误；为了降低软件开发和维护的成本，选用的高级语言应有良好的独立编译机制。
1）模块接口测试
①输入的实参与本模块的形参在个数、类型、顺序、量纲上是否一致；
②调用其他模块时所给实际参数与被调模块的形式参数在个数、类型、顺序、量纲上是否一致；
2）模块局部数据结构的测试
主要的测试内容有：
①不适合或不相容的类型说明；
②变量名不正确（拼写或截断错误等）；
③变量无初值或初始化、缺省值有错；
6.4集成测试
1．集成测试—将软件组装成系统的一种测试技术。因此，又称为组装测试或综合测试。
2．集成测试旨在发现与接口有关的错误。这些错误包括：
①数据通过接口时会丢失；
②一个模块的功能对另一个模块产生了不利影响；
③几个子功能组合起来没有实现主功能；
④全局数据结构出现错误；
⑤误差的不断积累达到不能接受的程度。
6.4.2增量集成方式
可分为自顶向下集成和自底向上集成两种方法。
1.自顶向下集成
自顶向下集成方式是从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块组装在一起。
深度优先策略
广度优先策略
广度优先策略——沿控制层次结构水平地向下移动，按一层一层的顺序将模块一个个地集成起来。如图的集成的顺序为M1、M2、M3、M4、M5、M6、M7、M8，在集成的过程中也需桩模块的配合。
1．验收测试的实施
验收测试需要采用一系列的黑盒测试来完成。
参加人员有：专门的测试人员，必须有用户或客户参加。
文档：需求规格说明书、用户手册等，应事先制定测试计划，确定测试的种类、测试进度、设计具体的测试用例。
2．软件配置复审
软件配置复审是验收测试的重要环节之一。软件配置复审的任务是审查软件配置（组成程序、所有文档资料、数据结构的所有项目）的正确性、完整性和一致性，以便确保软件配置齐全、分类有序，并包括软件维护所必需的细节，从而为以后的软件维护工作奠定了基础。
系统测试需要有硬件工程师、软件工程师、数据库工程师、专业领域的专家等各类技术人员参加，协同完成调试和测试任务。
6.6设计测试方案
6.6.1白盒测试
白盒测试的原则是：
①保证程序中每一独立的路径至少执行一次；
②保证所有判定的每一个分支至少执行一次；
③保证每个判定表达式中每个条件的所有可能结果至少出现一次；
2．测试结果评价
（1）经常发现严重的错误并需要修改软件，则软件的质量和可靠性一定不高，需要进一步测试；
（2）如果测试所发现的错误不多且易于改正，软件功能看起来也较完善，则需考虑两种可能：一方面软件质量和可靠性确实令人满意；另一方Biblioteka 测试不全面，很可能还潜伏着严重错误；
（3）如果测试过程没有发现任何错误，则很有可能是测试配置不合理。
计算机辅助静态分析是指利用静态分析软件工具对程序进行静态分析，主要检测变量是否用错、参数是否匹配、循环嵌套是否有错、是否有死循环和永远执行不到的死代码等等。同时，它还可对程序的特性进行分析。
2．动态测试
动态测试是指事先设计好一组测试用例，然后通过运行程序来发现错误。
动态测试有两种测试方法：黑盒测试和白盒测试。
1．基本路径测试
其主要思想是根据软件详细设计的过程性描述或源代码中的控制流程求出程序的环形复杂性度量，然后用此度量确定程序的基本路径集合，并由此导出一组测试用例来覆盖该集合中的每一个独立的路径，从而可以保证每个语句至少执行一次。
2.条件测试
用条件测试技术设计出的测试用例,能够检查程序模块中包含的逻辑条件.一个简单条件是一个布尔变量或一个关系表达式。关系表达式形式如下:
4）模块中各条错误处理路径的测试
5）模块边界条件的测试
模块边界条件的测试是单元测试中最后、也是最重要的一项测试任务，因为程序最容易在边界上出错。可以采用边界值分析技术针对边界值及其左、右值设计测试用例，很有可能检测出新的错误。
6.3.2单元测试的步骤
通常，单元测试在编码阶段进行。在源程序代码编制完成并经过编译检查和评审后，就可以开始进行单元测试。测试用例的设计应与评审工作相结合，根据测试计划和详细设计信息设计测试数据，并应给出对应的期望结果。
（2）用户能有一段熟悉新系统的时间
（3）可以验证用户指南和使用手册之类的文档。
（4）能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。
6.2.4测试阶段的信息流
1．测试的输入流有软件配置和测试配置。
（1）软件配置由需求规格说明、设计说明、源代码等组成；
（2）测试配置包括测试计划、测试用例（其中包括预期的结果）、测试工具等组成。
2．实用选择标准
6.1.2编程风格
不同的程序员可能具有不同的编程风格，有时候很难说哪种风格好，哪种风格不好，比如在分支语句之后的语句块，一些程序员可能习惯这样：
if(a>b){
.......
}
而另外的程序员喜欢这样：
if(a>b)
{
......
}
一般的软件组织允许程序员在不影响代码的可读性、可修改性、可测试性、可维护性的基础上使用自己的风格编写程序。但是有些规则则是所有程序员必须遵守的。
E1<关系算符>E2
其中E1和E2是算术表达式，而<关系算符>是下列算符之一：<,<=,=,!=,>,或>=。复合条件由两个或多个简单条件、布尔算符和括弧组成。布尔算符有OR，AND，NOT。不包含关系表达式的条件称为布尔表达式。
6.2.3软件测试的步骤
根据软件测试的第四条准则,测试过程也必须分步进行,后一步在逻辑上是前一步的继续。
1．模块测试
把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块的正确性。
2．子系统测试
把经过单元测试的模块放在一起形成一个子系统来测试。模块相互之间的协调和通信是这个测试过程的主要问题，因此这个测试也称为接口测试。
3．α、β测试
要验证所开发的软件是否真正满足最终用户的要求，就应由用户在其实际工作的环境中进行一系列的“验收测试”。
但一方面用户进行“验收测试”可能导致开发延期，另一方面是一个软件产品不可能由每个用户验收。因此，通常的做法是采用“α、β测试”的方法。
6.5.2系统测试
软件开发完毕，就应和系统硬件、数据库等其他系统要素集成为一个完整的系统。在集成的过程中，要进行一系列的系统调试和测试，以便验证各个系统要素能否在软件的控制下有条不紊地工作，实现系统规格说明中所规定的系统功能、性能等系统需求。
6.2.1软件测试的目标与原则
测试用例——为了进行有效的测试而设计的输入数据和预期的输出结果数据。
1．Myers在其软件测试著作中对软件测试的目标提出以下观点：
2．测试原则
6.2.2软件测试的常用方法
1．静态测试
静态测试是采用人工检测和计算机辅助静态分析的方法对程序进行检测。
人工检测是指靠人工走查程序或评审软件。这种走查与评审主要针对编码的质量和软件开发各个阶段的文档，特别是总体设计和详细设计阶段的错误。能发现30%~70%的逻辑设计和编码错误。