讲完了单元测试，我来分享下个人感觉另一个开发团队的重要测试步骤：持续集成测试，continuous integration testing。

稍具规模的软件开发，不管是商业或开源，一般是由一个团队来完成。团队写软件，必然会有一系列的分工。比方说，张三可能会写一些处理客户订单方面的library, class,和/或function；李四会写库存管理方面的代码；而王五负责物流和采购；等等。当然也不能排除张三发现李四代码内的问题进而修正的现象。我们在这里假定队里的工程师们已经统一使用一种单元测试机制并且会写单元测试。但最终我们要把这些代码通过代码库整合集中起来，确保作为一个整体，这些代码可以通过所有单元测试，没有冲突和编译错误，并且编译好的binary/executable符合事先订好的规范。这种源代码的整合、总体通过所有单元测试、代码链接和编译以及编译后的一些测试，即为集成测试，integration testing。

在团队开发环境里，各团队成员写的部件会有依赖性。如果我们数天、一周、甚至更长的时间里才做一次代码集成，就很可能会遇到以下情况：来自不同成员的代码部件可能有冲突，界面和生产环境的变化没能及时得到沟通和传达到每个队员，一部分的代码故障修复造成了其它部分的故障，等等等等。这会引进bugs，造成部分或全部的代码回滚，代码的不可编译，甚至拖延产品的发布或升级。为了解决这一常见问题，我们需要尽可能早、多次、自动化地运行集成测试。持续集成测试，即continuous integration testing，就应运而生。

自动化的持续集成测试由软件来完成。现在业界有不少continuous integration testing的工具，开源和商业的都有，像Buildbot（Python写成），Jenkins（Java写成），TeamCity，CruiseControl等。在本文底下我会给两个实战集成测试链接：一个是MariaDB的，用的是Buildbot；一个是Percona的，用的是Jenkins。读完本博后你可以到那两个网站看看，可以分析出他们的集成测试都做什么，有什么报告等，希望对你有所启发。集成测试机制一般有以下特点：

1. 和代码库挂钩。代码提交/check in/commit会自动触发集成测试；
2. 除了代码提交的自动激活测试外，一般可以安排时间定期来做集成测试，比如每天晚上一次；
3. 在编译和构建binary的同时或之后，该机制还可以和其它机制挂钩，如生成文档，给软件打包，做其它测试甚至生产发布，等等；
4. 有网页界面来回报集成测试结果。这结果包括集成测试状态，该集成包括哪些代码变化、bug fixes，新性能等，代码覆盖测试/code coverage报告等等。

一般情况下，如果队伍和产品有一定规模，可以考虑设置专门的build server来完成以上步骤。持续集成测试会给我们带来以下优势：
1. 尽早发现不同队员代码之间的冲突，减少甚至铲除难缠的由于不能尽快整合而对全局有负影响的问题；
2. 促进团队内部沟通；
3. 在紧急情况下，如果需要部署最新软件来解决生产环境中的燃眉之急，你有了可以直接部署的binary。

我个人以为建立持续集成测试机制对一个团队很重要。从我的理解和体会，我觉得以下几点值得注意：
1. 如上文所述，团队用统一的单元测试架构很重要。有了这个架构，工程师要写单元测试；
2. 养成多次从代码库拉下更新自己代码的习惯，每个工作日至少一次。一天可以多次提交代码；
3. 在代码提交之前，完整运行一次所有单元测试，包括组内其他成员的单元测试。测试不通过，不提交自己的代码。更何况，如果你的代码没通过单元测试而被提交，那集成测试机制会发现这个问题并在网页上公布出来，你会觉得很没面子。

好，这次就写到这儿。下次继续，可能会写下接收测试acceptance testing，stress/performan testing之类吧。如上文所述，这里是MariaDB的持续集成测试网站链接（Buildbot）；这里是Percona的持续集成测试网站链接（Jenkins）。