什么是集成测试?(示例)
什么是集成测试?
整合测试 被定义为一种测试类型,其中软件模块在逻辑上被集成并作为一个组进行测试。一个典型的软件项目由多个软件模块组成,由不同的程序员编码。这种级别的测试的目的是在集成时暴露这些软件模块之间交互中的缺陷
集成测试专注于检查这些模块之间的数据通信。因此,它也被称为 '它' (集成和测试) “字符串测试” 有时 “线程测试”.
为什么进行集成测试?
尽管每个软件模块都经过单元测试,但由于各种原因,仍然存在缺陷,例如
- 模块通常由单个软件开发人员设计,其理解和编程逻辑可能与其他程序员不同。集成测试对于验证软件模块是否能够协同工作至关重要
- 在模块开发时,客户需求很有可能发生变化。这些新需求可能未经单元测试,因此系统集成测试变得十分必要。
- 软件模块与数据库的接口可能存在错误
- 外部硬件接口(如果有)可能会有错误
- 异常处理不充分可能会导致问题。
点击 点击这里 如果视频无法访问
集成测试用例示例
之路 测试用例 与其他测试用例的不同之处在于 主要关注模块之间的接口和数据/信息流. 这里优先考虑的是 整合链接 而不是已经测试过的单元功能。
以下场景的示例集成测试用例:应用程序有 3 个模块,例如“登录页面”,'Mail邮箱”和“删除邮件”,并且每个部分都逻辑地整合在一起。
这里不需要过多关注登录页面测试,因为它已经在 单元测试。但检查一下它是如何链接到 Mail Box 页面。
同样 Mail Box:检查其与删除的集成 Mail模块。
测试用例 ID | 测试用例目标 | 测试用例 Description | 预期结果 |
---|---|---|---|
1 | 检查登录和 Mail盒模块 | 输入登录凭据并点击登录按钮 | 指向 Mail Box |
2 | 检查 Mail框并删除 Mail模块 | 从 Mail框中选择电子邮件并点击删除按钮 | 选定的电子邮件应出现在“已删除/垃圾”文件夹中 |
集成测试的类型
软件工程定义了执行集成测试的多种策略,即:
- 大爆炸方法:
- 增量方法:进一步分为以下几类
- 自上而下的方法
- 自下而上的方法
- 三明治方法——自上而下和自下而上的结合
以下是不同的策略、它们的实施方式以及它们的局限性和优点。
大爆炸测试
大爆炸测试 是一种集成测试方法,其中所有组件或模块一次性集成在一起,然后作为一个单元进行测试。测试时,这组组合的组件被视为一个实体。如果单元中的所有组件未完成,则集成过程将不会执行。
优点:
- 适用于小型系统。
缺点:
- 故障定位很困难。
- 由于这种方法中需要测试的接口数量非常多,因此很容易遗漏一些需要测试的接口链接。
- 由于只有在“所有”模块设计完成后才能开始集成测试,因此测试团队在测试阶段的执行时间会减少。
- 由于所有模块都是一次性测试的,高风险的关键模块没有被隔离并优先测试。处理用户界面的外围模块也没有被隔离并优先测试。
增量测试
在 增量测试 该方法通过集成两个或多个逻辑上相互关联的模块进行测试,然后测试应用程序是否正常运行。然后逐步集成其他相关模块,并继续该过程,直到所有逻辑上相关的模块都集成并成功测试。
增量方法又通过两种不同的方法来实现:
- 由下往上
- 由上往下
存根和驱动程序
存根和驱动程序 集成测试中用于促进 软件测试 活动。这些程序充当测试中缺失模型的替代品。它们不实现软件模块的整个编程逻辑,但它们在测试时模拟与调用模块的数据通信。
存根:由被测试模块调用。
驱动器:调用要测试的模块。
自下而上的集成测试
自下而上的集成测试 是一种首先测试较低级别模块的策略。然后进一步使用这些经过测试的模块来促进更高级别模块的测试。这个过程一直持续到所有顶层模块都经过测试。一旦较低级别的模块经过测试和集成,就会形成下一级模块。
图解表示:
优点:
- 故障定位更加容易。
- 与大爆炸方法不同,无需浪费时间等待所有模块的开发
缺点:
- 控制应用程序流程的关键模块(位于软件架构的顶层)最后进行测试,因此可能容易出现缺陷。
- 无法实现早期原型
自上而下的集成测试
自上而下的集成测试 集成测试是一种按照软件系统的控制流程从上到下进行的方法。首先测试较高级别的模块,然后测试和集成较低级别的模块,以检查软件功能。如果某些模块尚未准备好,则使用存根进行测试。
图示:
优点:
- 故障定位更加容易。
- 有可能获得早期原型。
- 关键模块会优先进行测试;可以首先发现并修复重大设计缺陷。
缺点:
- 需要许多存根。
- 较低级别的模块测试不充分。
三明治测试
三明治测试 是一种策略,其中顶层模块与底层模块一起测试,同时将底层模块与顶层模块集成并作为一个系统进行测试。它是自上而下和自下而上方法的结合,因此被称为 混合集成测试. 它同时利用了存根和驱动程序。
如何进行集成测试?
集成测试过程与软件测试策略无关(如上所述):
- 准备集成 测试计划
- 设计测试场景、案例和脚本。
- 执行测试用例然后报告缺陷。
- 跟踪并重新测试缺陷。
- 重复步骤3和4,直到积分成功完成。
概述 Descript集成测试计划
它包括以下属性:
- 测试方法/方式(如上所述)。
- 集成测试的范围和超出范围的项目。
- 角色和职责。
- 集成测试的先决条件。
- 测试环境。
- 风险和缓解计划。
集成测试的进入和退出标准
任何软件开发模型中集成测试阶段的进入和退出标准
入学标准:
- 单元测试组件/模块
- 所有高优先级错误均已修复并关闭
- 所有待编码模块均已成功完成并集成。
- 集成测试计划、测试用例、场景需要签署并记录。
- 其他要求 测试环境 为集成测试进行设置
退出标准:
- 集成应用测试成功。
- 执行的测试用例已记录
- 所有高优先级错误均已修复并关闭
- 需要提交的技术文档以及发行说明。
集成测试的最佳实践/指南
- 首先,确定集成 测试策略 可以采用的,然后相应地准备测试用例和测试数据。
- 研究 Archi应用程序的结构设计并确定关键模块。这些模块需要优先测试。
- 从以下位置获取接口设计 Archi架构团队并创建测试案例来详细验证所有接口。必须详细测试与数据库/外部硬件/软件应用程序的接口。
- 继测试用例之后,测试数据起着至关重要的作用。
- 在执行之前,务必准备好模拟数据。执行测试用例时不要选择测试数据。