持续集成：软件质量改进和风险降低之道

问题

　　在软件行业发展的初期，软件项目中最棘手、最紧张的时刻就是集成。单独能工作的一些模块被组装在一起，系统整体却常常失败，而且很难找到失败的原因。

　　解决办法

　　解决办法的关键在于更为频繁地进行集成。

　　它给项目带来了完全不同的感觉。项目的可见性变得好了很多，因为问题能够更快地检测出来。引入缺陷和发现缺陷之间的时间间隔变短，就更容易发现缺陷，您可以很容易地看见改变了什么，以方便找到问题的根源。当它与良好的测试程序配合时，可以大大减少缺陷的数量。结果是，开发者在调试上花的时间减少了，在增加功能上花的时间更多了，他们相信自己是在一个坚实的基础上开发软件。

　　持续集成意味着：

　　● 所有开发者都先在他们自己的工作站上执行私有构建，然后再将他们的代码提交到版本控制库中，从而确保他们的变更不会导致集成构建失败。

　　● 开发者每天至少向版本控制库提交一次代码。

　　● 集成构建每天在一台独立的计算机上进行多次。

　　● 每次构建都必须 100%通过测试。

　　● 生成可以进行功能测试的产品（如 WA R、配件、可执行程序等）。

　　● 修复失败的构建是优先级最高的事情。

　　● 某些开发者复查构建生成的报告，如编码标准报告和依赖分析报告，寻找可以改进的地方。

　　最佳实践

　　为缺陷编写测试

　　当缺陷被发现时，找出并隔离有问题的代码，为了修复缺陷，我们基本上需要破坏测试，先编写一个会失败的测试用例，然后不断执行这个测试（在修复缺陷的过程中），直到测试不再失败为止。

　　让组件测试可重复

　　数据库对于测试来说是相当沉重的依赖关系，所以您有两种选择：要么尽量地进行模拟，在尽可能长的时间内完全避免使用数据库，要么使用数据库并承受其开销。实现这种测试最容易的方法是使用某种xDbUnit 这样的数据库填充框架（如

　　针对.NET 的NDbUnit、针对 Java 的DbUnit 、针对 Python 的PDbSeed ）。这些框架将数据库的数据集抽象到 XML 文件中，然后为开发者提供细粒度的控制，即在测试过程中如何将这些数据填充到数据库中。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/