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

问题

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

解决办法

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

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

持续集成意味着: 

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

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

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

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

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

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

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

最佳实践

为缺陷编写测试

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

让组件测试可重复 

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

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

相关推荐