软件集成测试指导书详解.doc

集成测试操作指导书 1、简介 1.1 集成测试的关键目标 由于集成测试所处层次、检验对象与单元测试、系统测试有着很大的差异，其操作方法与检验标准也有所不同。 首先，集成测试必须是可重复的。在产品的生命周期中软件维护贯穿始终，不停的修改代码成为必然，仅考虑一次操作的集成测试是一种低效劳动，而且集成测试处于系统的中间层次（与单元测试与系统测试不同），需要编写一系列测试代码，操作难度也较大，所以构造可重复的集成测试过程是保证低投入高产出的前提。 其次，集成测试必须是规范的操作。代码千差万别，有简单的有复杂的、有规范性好的与规范性差的，如何保证不同的代码有相同的测试效果。测试者的素质也千差万别，有经验的与没经验的，能力强的与能力弱的，测试效果大不一样。要保证集成测试是可操作的、可推广的，需要解决这些问题。 另外，集成测试还需是可度量的。不可度量的测试往往意味着失控，质量与进度得不到保证，尤其对于集成测试，有一定难度，执行起来差异很大，更需要对测试效果进行度量。在提供覆盖分析的测试中，我们可以直观的看到哪些代码覆盖到了，哪些代码没覆盖到，再有针对的设计测试用例，这种白盒的方法，有力保证了高效测试。 以上三点是集成测试首先要解决的问题，也是集成测试的关键目标，如下： 关键目标1：构造可重复的集成测试过程 关键目标2：定义规范的集成测试操作 关键目标3：度量集成测试效果 1.2 达成关键目标的对策 1.2.1 构造可重复的集成测试过程 构造可重复的测试过程依赖自动测试工具，使用自动工具是一种手段，目标是构造可重复过程，在达成此目标的前提下，是否使用工具视具体情况，所以使用自动工具很重要，但非必须。一个理想的集成测试工具应具备以下特征： 1、用规范的格式（下称脚本）记录测试用例，测试执行在脚本控制下进行。 2、能方便的维护测试用例。要标识测试用例，能方便的扩充、修改用例。 3、支持测试过程管理，包括起停控制，测试过程记录，执行中的异常处理。 4、支持测试结果自动分析。 基于消息处理的被测系统中，测试驱动可以简化，构造出驱动消息放到指定队列。自动测试结果分析首先要截取程序变量，然后发送到测试管理模块在脚本控制下完成比较。 1.2.1 定义规范的集成测试操作 集成测试是对设计进行验证，设计有明确的层次性，一般而言，在函数调用被调用结构中，顶层部分对应于概要设计，底层部分对应于详细设计。相对应的集成测试也有明确的层次性，设计时怎么细化下去的，集成就怎么合回来，设计是怎么个粗略程度，集成时也该这么个粗略程度。明确这一点对定义集成测试操作有重要意义，实际上这也是V模式的一个核心思想，单元测试对应于编码，集成测试对应于设计，系统测试对应于功能与需求，测试过程就是正向开发的逆向验证过程，各阶段的测试对象对应于相应开发阶段所要分析的对象。 规范的集成测试必须是基于接口的，因为程序设计是根据接口一层一层细化，集成时也只需考察接口。基于接口的集成测试只关注接口的正确性，而不关注函数过程执行的正确性。函数内执行过程的正确性应该属于单元测试范畴，集成测试再关注这个意味着重复，工作量也异常庞大，最终也导致集成测试可操作性差，且失去重点。只关注接口的另一个好处理是：考察点清晰，截取变量的值便可实现自动测试，否则，基于过程的测试最终因函数过程千差万异，而使自动测试无法实现。另外，代码经常在变，而接口相对稳定，基于接口的测试保证较好的可继承性。还有，脱离千差万别的过程，使得整个测试不过分的依赖于测试者的个人素质，该操作是易用易推广的。 基于接口的集成测试是规范的测试，而非调试。之所以要把集成测试与调试严格区分，一方面是因为调试过程不是规范的，随机因素很多，批量的测试实现不了，测试结果无法自动比较，可重复的过程也不能实现；另一方面，调试效果因人而异，调试方法并非可拷贝的。 1.2.3 度量集成测试效果 量化测试效果一方面为了控制质量，另一方面是为了改进，在集成测试中后者更为重要。集成测试方法是黑盒的，只关注输入输出，若没有指标度量，测试程度无从了解，测试质量就失控了。所以，作为一条规则，集成测试需要提供覆盖指标。在覆盖分析中能直观的看到哪些代码未被覆盖，可以有针对性的再作测试，这样的集成测试过程是可改进的过程，保证了测试效率。 2、入口准则 集成测试的入口准则已在《DP0070-软件集成测试过程》中定义，下面描述几项重要规则。 集成测试首先要求被测对象具备基本的稳定性，联调要通过，否则集成测试将无法做起。另外，环境物料应有充分的保障，这在集成测试前几个月就得准备。