软件产品的构成都是非常复杂的,这也就意味着它将含有多个模块,这些模块通过接口进行交互。针对于这些集成模块的测试,我们称之为集成测试。也可以认为它是由单元测试扩展出来的。
什么是集成测试
集成测试是测试单元模块之间的连接或数据传输的过程。它又称为I&T(集成与测试)。
它分为大爆炸法、自上而下法、自下而上法和三明治或混合集成法(自上而下和自下而上相结合)。这个过程是通过使用名为stub和Drivers的虚拟程序来执行,其不需要实现软件整个模块,而只是模拟与调用模块的数据通信即可。
它通常是在单元测试之后完成之后执行的。集成测试中涉及的每个模块都应该在集成测试之前进行单元测试。通过在集成测试之前进行单元测试,可以提高执行软件集成测试的信心。
集成测试也需要编写相应的测试计划,从而减少了测试的混乱,并为有效执行集成测试提供了清晰的路径。
我们都知道,自动化测试是持续集成必不可少的一部分,基本上,没有自动化测试的持续集成,都很难称之为真正的持续集成。
我们希望持续集成能够尽早的暴露问题,但这远非配置一一个Hudson/Jenkins 服务器那么简单,只有真正用心编写了较为完整的测试用例,并一直维护它们,持续集成才能孜孜不倦地运行测试并第一时间报告问题。
这里强调的是测试的自动化,并基于具体的技术(Maven、 JUnit、Jetty 等)来介绍一种切实可行的自动化 Web 应用集成测试方案。当然,自动化测试还包括单元测试、验收测试、性能测试等,在不同的场景下,它们都能为软件开发带来极大的价值。
基于 Maven 的一般流程
集成测试与单元测试最大的区别是它需要尽可能的测试整个功能及相关环境,对于测试 Web 应用而言,通常有这么几步:
- 启动 Web 容器
- 部署待测试 Web 应用
- 以 Web 客户端的角色运行测试用例
- 停止 Web 容器
启动 Web 容器可以有很多方式,例如你可以通过 Web 容器提供的 API 采用编程的方式来启动容器,但在 Maven 的环境下,配置插件显得更简单。
如果你了解maven的生命周期模型,就可能会想到,我们可以在 pre-integration-test 阶段启动容器,部署待测试应用,然后在 integration-test 阶段运行集成测试用例,最后在 post-integrate-test 阶段停止容器。
也就是说,对于步骤 1,2 和 4 我们只须进行一些简单的配置,不必编写额外的代码。第 3 步是以黑盒的形式模拟客户端进行测试,需要注意的是,这里通常要求你理解一些基本的 HTTP 协议知识,例如服务端在什么情况下应该返回 HTTP 代码 200,什么时候应该返回 401 错误,以及所支持的 Content-Type 是什么等等。
至于测试用例该怎么写,除了需要用到一些用来访问 Web 以及解析响应详细的基础设施工具类之外,其他内容与单元测试大同小异,基本就是准备测试数据、访问服务、验证返回值等等。