|
|
知识路径： > 电子商务系统程序设计基础 > 电子商务系统的测试 > 软件测试阶段 >
|
|
相关知识点：29个
|
|
|
|
|
1999年9月，火星气象人造卫星在经过41周4.16亿英里飞行后，在即将要进入火星轨道时失败了，为此，美国投资5万美元调查事故原因，发现太空科学家洛克希德·马丁采用的是英制（磅）加速度数据，而喷气推进实验室则采用的是公制（牛顿）加速度数据进行计算。如果他们进行了集成测试，事故本来是可以避免的。
|
|
|
|
在每个模块完成单元测试之后，需要着重考虑的一个问题是：通过什么方式将模块组合起来进行集成测试，这将影响到模块测试用例的设计、所用测试工具的类型、模块编码的次序、测试的次序以及设计测试用例的费用和纠错的费用等。
|
|
|
|
集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用，一般不使用真实数据，可以使用一部分代表性的测试数据。在创建测试数据时，应保证数据能充分测试软件系统的边界条件。
|
|
|
|
|
|
|
|
非增量式集成测试采用一步到位的方法来进行测试，对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。
|
|
|
|
增量式集成测试具体包括自顶向下增量式测试和自底向上增量式测试。
|
|
|
|
|
|
自顶向下增量式测试按结构图自上而下进行逐步集成和逐步测试。模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。自顶向下的集成方式可以采用深度优先策略和广度优先策略，如下图所示。由图可知，深度优先顺序为T1->T2->T5->T8->T6->T3->T7->T4，广度优先顺序为T1->T2->T3->T4->T5->T6->T7->T8。
|
|
|
|
|
|
|
|
|
|
①以主模块为所测试模块兼驱动模块，而所有直属于主模块的下属模块全部用桩模块替换，并对主模块进行测试。
|
|
|
|
②采用深度优先或广度优先测试方式，用实际模块替换相应桩模块，再用桩代替它们的直接下属模块，从而与已经测试的模块或子系统组装成新的子系统。
|
|
|
|
|
|
④判断是否所有的模块都已经组装到系统中。如果是，则测试结束，否则，转到②。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.随着底层模块的不断增加，会导致底层模块的测试不充分，特别是被重用的模块。
|
|
|
|
.由于每次组装都必须提供桩，会使得桩的数目急剧增加，从而维护桩的成本也会快速上升。
|
|
|
|
因此，该方法适合采用结构化方法开发软件的体系结构相对比较简单的软件系统。
|
|
|
|
|
|
自底向上增量式测试是从“原子”模块（软件结构中最低层的模块）开始，按结构图自下而上逐步进行集成和测试。
|
|
|
|
|
|
|
|
②写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出。
|
|
|
|
|
|
④去掉驱动程序，沿软件结构由下向上移动，把子功能族组合成更大的功能族。
|
|
|
|
|
|
|
|
.虽然模拟中断或异常需要设计一定的桩模块，但总体上减少了桩模块的工作量。
|
|
|
|
|
|
.在测试初期，可以并行进行集成，相应地比使用自顶向下的方式效率高。
|
|
|
|
|
|
.随着集成到顶层，整个系统变得越来越复杂，对于底层的一些模块将很难覆盖。
|
|
|
|
|
|
下面给出了非增量式集成测试和增量式集成测试的比较结果。
|
|
|
|
（1）非增量式集成测试模式是先分散测试，然后集中起来一次完成集成测试。如果在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来。在非增量式集成测试时可能发现很多错误，但为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能会引入新的错误，从而更难断定出错的原因和位置；与此相反，增量式集成测试采用逐步集成和逐步测试的方法，测试的范围逐步增大，从而错误易于定位和纠正。因此，增量式集成测试比非增量式集成测试有比较明显的优越性。
|
|
|
|
（2）自顶向下测试的主要优点是逐步求精，从一开始让测试者了解系统的框架。它的主要缺点是需要提供被调用的模拟子模块，被调用的模拟子模块可能不能反映真实情况，因此测试有可能不充分。
|
|
|
|
（3）自底向上测试的优点在于，由于驱动模块模拟了所有调用参数，从而测试数据没有困难。其主要缺点在于，只有到最后一个模块被加入之后才能知道整个系统的框架。
|
|
|
|
（4）核心系统先行集成测试能保证一些重要功能和服务的实现，对于快速软件开发十分有效。如果采用此种模式的测试，则要求系统应能明确区分核心软件部件和外围软件部件，采用高频集成，借助于自动化工具实现测试。
|
|
|
|
总之，采用自顶向下集成测试和自底向上集成测试的方案较为常见。在实际测试工作中，应该结合项目的实际环境及各种测试方案适用的范围进行合理的选型。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（4）集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。
|
|
|
|
|
|
（6）在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通。
|
|
|
|
（7）当接口发生修改时，涉及的相关接口必须进行再测试。
|
|
|
|
|
|
|
|
在集成测试过程中的两个重要的里程稗是功能冻结和代码冻结的确定。这两个里程碑可界定出回归测试期的起止界限。
|
|
|
|
（1）功能冻结。经过测试，符合设计要求，确认系统功能和其他特性均不再做任何改变。
|
|
|
|
（2）代码冻结。理论上，在无错误时冻结程序代码，但实际上，代码冻结只标志系统当前版本的质量已达到预期的要求，冻结程序的源代码，不再对其做任何修改。这个里程碑设置在软件通过最终回归测试之后。
|
|
|
|
|
|
|
|
（1）测试的单元不同。单元测试是针对软件从基本单元（如函数等）所做的测试；而集成测试则是以模块和子系统为单位进行的测试，主要测试接口间的关系。
|
|
|
|
（2）测试的依据不同。单元测试是针对软件详细设计所做的测试，测试用例主要依据详细设计；而集成测试是针对高层（概要）设计所做的测试，测试用例主要依据概要设计。
|
|
|
|
（3）测试空间不同。集成测试的测试空间与单元测试和系统测试是不同的。集成测试也不关心内部实现层的测试空间，只关注接口层的测试空间，即关注的是接口层可变数据间的组合关系。
|
|
|
|
（4）使用的方法不同。集成测试关注的是接口的集成，和单元测试只关注每个单元不同，因此在具体的测试方法上也不同，集成测试在测试用例设计方面和单元测试有一定的差别。
|
|
|
|
|
|
|
|
按照集成构建计划及增量集成策略完成了整个系统的集成测试。
|
|
|
|
|
|
|
|
|
|
在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
|
|
|
