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

　　兼容性测试

　　现在软件需要兼容的环境越来越多，包括操作系统、应用服务器、数据库、浏览器，像上面案例中的产品还要兼容主流虚拟化服务(比如，VMware 、XenServer、KVM)的各种版本。如果全靠人工测试来保证兼容性，是不太现实的事情。

　　兼容性测试有个特点，就是如果不兼容，往往在一些主要流程上就能明确的体现出来，一般不用深入到每个业务细节，也不用靠人来主观分析。因此也非常适合通过自动化测试来完成。

　　下面分享一个笔者在撰文的前一天刚刚遇到的实际案例(如下图所示)。

　　这个一个最基本的用户维护界面，里面包括必填信息和可选信息(比如，生日)。在一次自动化测试中，Web UI层面的“用户信息修改”用例出现了如下异常：

　　Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Incorrect datetime value: '' for column 'ext_date' at row 1

　　这个功能后台业务接口是有单元测试用例对应的，并且也做了一些边界值测试(比如，“生日”属性为空)，但遗漏了另外一个边界条件(空字符串)，而恰恰如果界面不选择“生日”，传到后台的就是空字符串。Web UI层面最基本的测试用例恰恰弥补了这个缺憾。

　　写到这里，可能会有敏锐且尖锐的读者继续提出质疑：“这么表面的缺陷在手工测试阶段一定会发现的，怎么会轮到通过Web UI自动化回归测试来发现呢?”

　　我们来回顾一下上面的异常信息“Caused by: com.mysql.jdbc.MysqlDataTruncation…”。是的，这个缺陷只有在使用MySQL数据库时才出现，而日常开发和手工测试使用的都是Oracle数据库。

　　我们把在各种组合环境下的兼容性测试交给自动化用例来完成。因此，如果有兼容性方面的Bug，也是“得来全不费工夫”!

　　稳定性测试

　　稳定性测试可以分为“服务端稳定性测试”和“客户端稳定性测试”。其中服务端(比如，应服务器、数据库等)的稳定性测试是最常见的，笔者这里不做赘述。

　　RIA(Rich Internet Applications)技术的广泛应用为Web用户提供越来越赞的使用体验。与此同时，也比传统应用占用更多的客户端(浏览器)资源。所以对此类应用的客户端稳定性测试也是非常关键的。

　　验证客户端的稳定性需要两个条件：长时间的不间断操作、监控浏览器资源占用。

　　我们通过对Web UI自动化测试用例的循环执行可以模拟长时间的不间断操作。另外，在自动执行的同时，自动获取并记录浏览器资源占用，就可以达到验证客户端稳定性的目的。

　　如果系统前端代码出现内存泄露(比如，弹出页面关闭后未销毁生成的DOM对象)，Web UI自动化用例长时间运行后生成的浏览器内存占用报告就会如下图所示：

　　而正常应该是整体呈水平趋势的锯齿状图形。如果出现上述情况，其表现出来的现象是用户感觉操作响应越来越慢，严重的情况下会导致浏览器宕掉。

　　至此，本系列文章就结束了。下面用三句短话总结一下本系列的主要内容：

　　Web自动化测试困难的根本原因是什么;

　　如何才能更容易的成功实施Web自动化测试;

　　要么不断提升、持续证明自动化测试的价值，要么就变成鸡肋!

　　最后分享笔者这几年在实施自动化测试和持续集成工作中的一些心得体会：

　　在设计某个功能“自动化测试应该怎么实现”之前，一定要先全面、仔细的分析“手工测试时是怎么做的”;

　　当提到自动化测试的“测试设计”时，不光要考虑“测试用例设计”，一定还要考虑“自动化测试方案或框架的设计”

　　敢于面对各种质疑和挑战，并用持续的改善作为回应;

　　对于开发团队来说“不改善，尤可活”，对自动化测试来说“不改善，就等死”;

　　不断发掘自动化测试对各个团队的附加价值，只有这样才能得到来自四面八方的支持;

　　自动化测试的目的是节省成本，所以如果发现某个项目、模块或功能在进行自动化测试时的投入产出比还不如人工测试，就应该果断暂停;

　　当有人用“自动化测试的返工成本”来刻意刁难测试团队时，不妨请他考虑一下研发阶段的返工吧;

　　对测试用例失败的原因进行归类(比如，缺陷、环境错误、用例未更新等)，并据此生成测试报告，非常有助于提高测试结果分析的效率;

　　在持续集成过程中，最初觉得技术是个坎儿，迈过之后发现管理是个更大的坎儿。要想持续集成获得成功必须让研发、测试、实施等各个团队都认识到它对自己的价值，然后大家才会主动的、同心协力将此事做好;

　　再忙也必须每日修正完持续集成测试发现的缺陷，唯有此持续集成发现的缺陷比才会越来越少。当每日构建都能成功的时候，团队信心和士气会得到很大的提振;

　　每次集成后测试用例全部都通过和基本都不通过都是不正常的现象，“全部都通过”往往代表测试用例覆盖率不够或缺乏有效断言，“基本都不通过”则可能因为研发提交代码质量太差或持续集成环境有问题;

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