测试策略(2)
(2)集成测试
集成测试也叫做组装测试或联合测试。通常,在单元测试的基础上,需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
-
组装时需要考虑的问题
①在把各个模块连接起来的时候,穿越模块接口的数据时否会丢失
②一个模块的功能是否会对另一个模块的功能产生不利的影响
③各个子功能组合起来,能否达到预期要求的父功能
④全局数据结构是否有问题
⑤单个模块的误差累积起来,是否会放大,以至达到不能接受的程度
-
模块组装成为系统的方式
①一次性组装方式
是一种非增殖式组装方式,也叫整体拼装。首先对每个模块分别进行模块测试,再把所有模块组装在一起进行测试,最终得到要求的软件系统。例如,有一个模块系统结构,如下图2-11(a)所示。其单元测试和组装顺序如图2-11(b)所示。
在如图2-11(b)中,模块d1,d2,d3,d4,d5是对各个模块做单元测试时建立的驱动模块,s1,s2,s3,s4,s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下,在分别完成模块单元测试的基础上,将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题,所以一次试运行成功的可能性并不很大。其结果是,发现有错误,却茫然找不到原因。差错和改错都会遇到困难。
②增殖式组装方式
组装方式又称渐增式组装,是首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统,在组装的过程中边连接边测试,以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
-
自顶向下的增殖方式
这种组装方式是将模块按系统程序结构,沿控制层次自顶向下进行组装。其步骤如下:首先以主模块作为所有模块兼驱动模块,所有直属于主模块的下属模块全部用桩模块代替,对主模块进行测试。再采用深度优先或广度优先的策略,用实际模块替换相应的桩模块,再用桩模块代替它们的直接下属模块,与已测试的模块或子凶弹组装成新的子系统。然后,进行回归测试(即重新执行以前做过的全部测试或部分测试),排除组装过程中引入新的错误的可能。最后,判断是否所有的模块都已组装到系统中。是,则结束测试;否则,转到B去执行。
-
自底向上的增殖方式
这种组装方式是从程序模块结构的最底层模块开始组装和测试。应为模块是自底向上进行组装的,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所有不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下:首先由驱动模块控制最底层模块的并行测试;也可以把最底层模块组合成实现某一特定软件功能的簇,由驱动模块控制它进行测试。再用实际模块代替驱动模块,与它已测试的直属子模块组装成为子系统。然后,为子系统配备驱动模块,进行新的测试。最后判断是否已组装到达主模块。是,则结束测试;否则,执行B。
以如图2-11(a)所示的一次性组装方式系统结构为例,可以用如图2-13说明自底向上组装和测试的顺序。
-
混合增殖式测试
自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难,因为,桩模块在接收了所测模块发送的信息后,需要按照它所代替的实际子模块功能返回应该回送的信息,这必将增加建立桩模块的复杂度,而且导致增加一些附加的测试。同时,涉及复杂算法和真正输入/输出的模块一般在底层,他们是最容易出问题的模块,到组装和测试的后期才遇到这些模块,一旦发现问题,就会导致过多的回归测试。而而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
自底向上增殖方式的缺点是“程序一直未能作为一个实体存在,知道最后一个模块加上去后才形成一个实体”。就是说,在自底向上组装和测试的过程中,对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块,而建立驱动模块一般比建立桩模块容易,同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试,可以把最容易出问题的部分在早期解决。此外自底向上增殖方式可以实施多个模块的并行测试,提高测试效率。因此,通常是把以上两种方式结合起来进行组装和测试。
在进行集成测试时,测试者应当确定关键模块,对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一:
❶满足某些软件需求
❷在程序的模块结构中位于较高的层次(高层控制模块)
❸较复杂、较易发生错误
❹有明确定义的性能要求
-
集成测试的组织和实施
集成测试是一种正规测试过程,必须精心计划,并与单元测试的完成时间协调起来。在制定测试计划时,应考虑如下因素:
①采用何种系统组装方式来进行集成测试
②集成测试过程中连接各个模块的顺序
③模块代码编制和测试进度是否与集成测试的顺序一致
④测试过程中是否需要专门的硬件设备
解决了上述问题之后,就可以列出各个模块的编制、测试计划表,标明每个模块单元测试完成日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
-
集成测试完成的标志主要有以下几项:
①成功地执行了测试计划中规定的所有集成测试。
②修正了所发现的错误。
③测试结果通过了专门小组的评审。
集成测试应有专门的测试小组来进行,测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
(3)确认测试
确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查,确认测试一般由独立的第三方测试机构进行。
-
进行有效性测试
有效性测试是在模拟的环境下,运用黑盒测试的方法,验证所测软件是否满足需求规格说明书列出的需求。
①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合。
②测试结果与预期的记过不相符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要提交一份问题报告。
-
软件配置复查
软件配置复查的目的是保证软件配置的所有成分都齐全,个方面的质量都符合要求,具有维护阶段所必须的细节,而且已经编排好分类的目录。
在确认测试的过程中,还应当严格遵守使用手册和操作手册中规定的使用步骤,以便检查文档资料的完整性和正确性。
(4)系统测试
系统测试是将通过集成测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际或者模拟运行环境下,对计算机系统进行一系列测试。
系统测试的目的在于通过与系统的需求定义作比较,发现软件与定义不符合或与之矛盾的地方。
(5)验收测试
验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据,并分析测试的输出结果。一般使用生产中的实际数据进行测试。
目前在国内实际软件开发,特别是系统集成的过程中,验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定,由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是,验收测试往往不是对系统的全覆盖测试。而是针对用户的核心业务流程进行的测试;同时,测试的执行人员也不是开发方的测试组成员,而是由用户方的使用人员完成。