围绕自动化测试开展持续集成

　　本文不会介绍持续集成的概念、理论以及相关工具的用法，而是基于实际的项目案例，分享如何利用自动化测试保障持续集成的有效性，同时也借助持续集成提升自动化测试用例的价值。

　　在本系列的前几篇文章中，首先分析了测试不够敏捷的原因，然后从“降低测试脚本维护成本”和“优化断言机制”两方面分享了Web自动化测试的改善实践。

　　前面几篇文章其实都在讲“如何成功实施Web自动化测试”，本文将要涉及一个很敏感，但不应该回避的话题“自动化测试的意义到底有多大?”。

　　做过自动化测试的同仁都应该对“自动化测试用例能发现多少缺陷”这话题不陌生，业界也有很多支持“自动化测试用例主要不是用来发现缺陷，而是提高回归测试效率”这个观点的文章。即便这样，“发现缺陷”也像是自动化测试人员“肉中的一根刺”，很多时候大家不愿意去触碰它(不碰就不痛)。这样时间久了，很可能会让自动化测试人员丧失发现缺陷的斗志。笔者在这里就尝试拨动一下这根“刺”，希望可以再次引发大家的思考。

　　“自动化测试主要不是用来发现缺陷”这一观点的主要依据是“自动化测试是严格按照已有用例进行的自动回归测试”。说白了就是“它每次做的事儿相同的”，所以不能像手工测试那样依靠人的主观能动性来发现新的缺陷。

　　“它每次做的事儿相同的”，这一点我们改变不了。

　　但我们能做的是在不同的场景中做“相同的事儿”!从而增加发现缺陷的几率，降低软件释放后风险。

　　下面就通过实际案例分享笔者在提升自动化测试价值方面的经验：“在持续集成中对每日构建的版本进行回归测试”，并对一些里程碑版本进行“在各种环境组合下(应用服务器、数据库、浏览器、操作系统)的兼容性测试”和“7*24小时的稳定性测试”。

　　对每日构建版本的回归测试

　　本案例中的产品是面向云计算领域的通用云环境管理软件，在云数据中心构建及运维过程中提供全方位、多层次的管理能力，基于云环境实现应用的快速部署及其资源的弹性供应，通过简化管理极大地降低成本、提高效益。

　　产品的逻辑架构、主要技术路线及对应的自动化测试方案如下图所示：

　　该产品大致可以分为三层：

　　最底层负责与各类虚拟化资源或物理资源的交互，比如，创建虚拟机、获取CPU利用率;

　　中间层负责对底层返回的数据进行持久化及业务处理，并向外提供大量REST接口;

　　最顶层通过多个应用门户向不同类型的用户提供体验一致的交互界面，它本身没有太多业务逻辑和持久化操作，主要靠调用中间层的REST接口来实现。

　　持续集成方案选择的CI工具是Jenkins，具体步骤如下图：

　　对每个步骤的要点简述如下：

　　更新编译代码

　　项目采用分布式开发，需要从不同的配置管理库中更新各个模块的功能代码和自动化测试用例。

　　代码质量检查

　　项目要求开发人员使用Findbugs和PMD对自己的代码进行质量检查并修正相关问题。同样也在持续集成过程中通过Sonar(集成Findbugs和PMD)使用相同的策略进行代码检查，以确保该要求的执行效果。

　　更新数据库

　　在更新功能代码和测试脚本之后，自动化测试还是可能出现大面积无法通过的情况。其中一个很常见的原因就是“当天开发库中的数据库结构发生了变化”，而持续集成所使用的数据库并没有更新。

　　所以我们执行自动化测试用例之前增加一个“检查开发库和持续集成库的表结构是否一致，如果不一致就做增量同步”的任务。

　　执行单元测试

　　通过单元测试确保系统与虚拟化资源或物理资源的交互是没问题的。如果这个环节出现严重问题，后面的持续集成任务就没必要执行了。

　　部署后台服务

　　单元测试通过之后，把后台服务(即，上面说的中间层)发布到目标服务器并启动服务。

　　执行REST接口测试

　　基于上面发布的后台服务，对其提供的大量REST接口进行回归测试。如果这个环节出现严重问题，就没有必要再部署前台应用并进行后续测试了。

　　部署前台应用

　　REST接口测试通过之后，才把各个前台门户应用发布到目标服务器并启动服务。

　　执行Web UI测试

　　基于上面发布的前台应用，执行各自Web UI层面的自动化测试用例(采用本系列前面几篇文章中介绍的方案)。

　　发布构建结果

　　通报每日构建结果(如下图所示)，测试用例按照模块进行分类，对不通过的用例进行分析然后提交相关缺陷。

　　上述持续集成案例的关键是“自动化测试”，而无论从技术还是从管理的角度，其难点也是“自动化测试”。

　　从技术角度来说，在上面三类自动化测试中最困难的是UI层面的自动化测试。笔者在本系列前面几篇文章中主要分享的就是这方面的改善实践。

　　从管理角度来说，要对自动化测试相关数据(比如，用例通过率、用例增长率、代码覆盖率等)实施公开、准确的度量，如下图所示。

　　度量的最终目标不是为了考核，而是为了改善。

　　从度量结果中团队能看出问题，才能有的放矢的改善;

　　从度量结果中团队能看出进步，才能得到激励和信心。

原文转自：http://www.infoq.com/cn/articles/develop-continuous-integration-around-automation-test