集成测试分析

Posted 2021-05-01 一朵儿的软件测试之旅

• 体系结构分析

• 首先从需求的跟踪实现出发，划分出系统实现上的结构层次模型

• 其次需要划分系统组件之间的依赖关系图

• 体系结构的分析为集成测试策略的选择提供了思路

• 模块分析

• 模块划分的好坏直接影响了集成测试的工作量、进度以及质量

• 一般模块划分可以从以下几个角度考虑

• 本次测试主要是希望测试哪些模块

• 这个模块与哪几个模块有最密切关系

• 把该模块与关系最密切的模块首先集成在一起

• 再考虑这样划分后的外围模块，这些模块与被集成模块之间的消息流是否容易模拟，是否方便控制

• 一个合理的模块集成划分应该满足以下几点

• 被集成的几个子模块关系亲密

• 外围模块便于屏蔽，外围模块与集成模块之间没有太多，太频繁的调用关系

• 模拟外围模块发往被集成模块的消息便于构造、修改

• 外围模块发往被测模块的消息能够模拟大部分实际环境的情况

• 在软件工程中有一条事实上的原则，即 2/8 原则，该原则对测试同样起作用。从测试实践发现，测试中发现的错误中的百分之八十很可能起源于程序模块中的百分之二十。并且经验也表明，很多错误报告常常可以在同一个模块中被追踪到，并且统计数据表明一段程序中已经发现的错误数目往往和尚未发现的错误数目成正比

• 一个关键模块具有一个或多个下列特性

• 和多个软件需求有关，或与关键功能相关、

• 处于程序控制结构的顶层

• 本身是复杂的或者是容易出错的

• 含有确定性的性能要求

• 被频繁使用的模块

• 在实际操作中，可以通过以下途径分析关键模块

• 尽可能和开发人员多讨论，一般开发人员对哪些模块是关键模块比较清楚

• 通过使用静态分析工具来分析系统各模块，寻找高内聚的模块、被频繁调用的模块或处于控制顶层的模块

• 根据需求跟踪表来分析关键模块，一般与关键功能或关键接口相关的模块都是比较关键的。同时与一些特殊需求相关的模块也需要特别关注

• 对于一个维护性的项目，可以根据以往的历史经验来判定，这包括产品历史缺陷的分析

• 对于一个新的产品，可以根据开发过程前期包括文档的检视、代码的走读、单元测试发现的问题进行分析，并因此确定可能风险最大的模块

• 接口分析

• 集成测试的重点就是要测试接口的功能性、接口的可靠性、接口的安全性、接口的完整性、接口的稳定性等多个方面。因此必须对被测对象的接口进行详细的分析。这些分析包括接口的划分，接口的分类和穿越接口的数据分析

• 接口的划分

• 确定系统的边界、子系统的边界和模块的边界

• 确定模块内部的接口

• 确定子系统内模块间接口

• 确定子系统间接口

• 确定系统与操作系统的接口

• 确定系统与硬件的接口

• 确定系统与第三方软件的接口

• 接口的分类

• 系统内接口：系统内部各模块交互的接口，这是集成测试的重点

• 系统外接口：外部系统（包括人、硬件、软件）对系统交互的接口，这类测试一般会延续到系统测试阶段完成

• 系统内接口主要包括

• 函数接口

• 消息接口

• 类接口

• 其他接口：其他类型接口包括全局变量、配置表、注册信息、中断等。这类接口具有一定的隐蔽性，往往测试人员会忽略这部分接口。这类接口的测试需要借助一定的自动化工具

• 接口数据分析

• 接口数据分析就是要分析穿越接口的数据。从这些数据的分析过程中可以直接产生测试用例。

• 对于函数接口，关注穿越函数接口的参数个数、参数属性（参数类型，输出输入属性）、参数的顺序、参数的等价类情况、参数的边界值情况等。如果需要的话还要考虑它们的组合情况

• 关于消息接口，需要分析消息的类型、消息的域、域的顺序、域的属性、域的取值范围、可能的异常值等。如果需要的话也要考虑它们的组合情况

• 关于类接口，需要对类的属性进行分析。分析的方法包括等价类划分和边界值分析。

• 对于其他类接口的分析，需要分析其读写属性、并发性、等价类和边界值。特别对于配置文件这类接口，其涉及到的数据变化了是及其庞大的，在分析这类数据的时候，可能需要结合一定的约束条件，尽可能减少用例的数量

• 风险分析

• 一般风险分析包含三个阶段

• 风险识别：识别风险的方法可以依靠观察，掌握有关的知识。调查研究，参考相关资料和经验数据，听取专家意见等。

• 风险评估：对已识别的风险要进行估计，主要任务的确定风险发生的概率和后果

• 风险处理：一旦风险被识别、评估以及风险量被确定之后，就要考虑各种风险的处理方法。针对集成测试过程来说，一般有三种方法：

• 风险控制：包括主动采取措施避免风险、消灭风险、中和风险，或一旦风险发生，即采用紧急应急方案，力争将损失减少到最低限度

• 风险自留：如果风险量被确认不大，不超过集成测试应急资源时，可以将该风险留在项目组中

• 风险转移：将风险转移给另一方或其他测试阶段

• 在集成测试中，常见的风险包括

• 技术风险

• 人员风险

• 物料仪器

• 管理风险

• 市场风险

• 可测试性分析

• 系统的可测试性分析应当在项目开始的时候作为一项需求提出来，并设计到系统中去。尽可能早的分析接口的可测试性，提前为测试的实现做好准备

• 集成测试策略分析

• 一般来说，一个好的集成测试策略应该具有以下特点

• 能够对被测对象进行比较充分的测试，尤其是对关键模块

• 能有使模块对接口的划分清晰明了，尽可能的减小后续操作难度，同时使需要做的辅助工作量最小

• 整体工作量对于投入测试的资源来说大致相当，参与测试的人力、环境、时间等资源能够得到充分利用

• 常见的集成测试故障

• 配置/版本控制错误

• 遗漏、重叠或冲突的函数

• 文件或数据库使用不正确或不一致的数据结构

• 文件或数据库使用冲突的数据视图/用法

• 破环全局存储或数据库数据的完整性

• 由于编码错误或未预料到的运行时绑定导致的错误方法调用

• 客户发送违反服务器前提条件的消息

• 客户发送违反服务器顺序约束的消息

• 错误的对象和消息的绑定（多态中经常发生）

• 错误参数或不正确的参数值

• 由不正确的内存管理分配/收回引起的失败

• 不正确的使用虚拟机、ORB 或 OS 服务

• 组件之间的冲突

• 资源竞争：目标环境不能分配象征性装载所需要的资源