ZStack——自动化测试系统1：集成测试

测试，对于一个IaaS软件的可靠性、成熟度和可维护性而言，是一个重要的因素.测试在ZStack中是全自动的。这个自动化测试系统包括了三个部分：集成测试，系统测试，基于模块的测试。其中集成测试构建于Junit之上，使用了模拟器。通过这个集成测试系统提供的各种各样的功能，开发人员可以快速的写出测试用例，用于验证一个新特性或者一个缺陷修复。

概述

这个关键因素，在构建一个可靠的、成熟的和可维护的软件产品中，就是架构；这是我们自始自终相信的设计原则。ZStack已经付出了大量的努力，以设计这么一个架构：始终保持软件稳定，无论是添加新特性，常规的操作错误，还是为特殊目的裁剪；我们之前的文章：ZStack—进程内微服务架构、ZStack—通用插件系统、ZStack—工作流引擎、ZStack—标签系统，已经表现了我们的一些尝试。然而，我们也充分理解测试在软件开发中的重要性。ZStack，从第一天开始，设定了这么一个目标：每一个特性都必须有测试用例保证，测试必须是全部自动化的，写单元测试应该是验证一个新特性或任何代码改变的唯一方式。

为了实现这个目标，我们把我们的测试系统分成了三个组件：集成测试，系统测试，模块测试。分类方式是通过它们的关注点和功能。

集成测试系统构建于Junit，全部使用模拟器；测试用例存放在ZStack的Java源代码中；开发人员可以轻松地使用常规的Junit命令来启动测试套件。

系统测试系统是一个独立的Python项目，称之为zstack-woodpecker，基于ZStack的API；在一个真实的硬件环境中测试一切。

基于模块的测试系统构建于基于模块的测试这么一个理论，是zstack-woodpecker中的一个子项目。这个系统中的测试用例将会持续地，以随机的方式，执行API，直到一些预定义的条件被满足。

从这篇文章开始，我们将会有一系列的，共计三篇文章，来详细阐述我们的测试架构，以向你展示我们保证ZStack每一个特性的方式。

单元测试的几句话

好奇的读者可能已经在他们的心中问了这么一个问题，为什么我们没有提到单元测试，这么一个可能是最著名的，也是每一个冷静的测试驱动的开发人员会强调的测试概念。我们确实有单元测试。如果你看到了后续的章节：测试框架，你可能会困惑，为什么用在命令中的命名类似于：UnitTest balabala，但在这篇文章中被命名为集成测试。

一开始，我们认为我们的测试就是单元测试，因为每一个用例都是用于验证一个独立的组件，而不是整个软件；例如，这么一个用例：TestCreateZone，只测试Zone服务，其他的组件，像VM服务、存储服务将甚至不会被加载。然而，我们做测试的方式确实和传统的单元测试概念有所不同，传统的方式是测试一小段代码，通常是针对内部结构的白盒测试，使用mock和stub的方法论。当前的ZStack有大概120个测试用例满足这个定义，而剩下的500多个并不。大多数的测试用例，甚至关注于独立服务或组件的，都更像集成测试用例，因为会加载多个依赖的服务、组件用以执行一个测试活动。

另一方面，我们大多数的，基于模拟器的测试用例，都