小说园

第13部分（第3页）

“不知道别的员工怎么想，我觉得这样做，会更有价值。只不过，你就得多花些时间在这上面了。”阿朱笑着说。

“这倒没关系！关心并帮助每个员工向前发展，本来就是我的责任。我会再做一个调查，了解一下其他人的看法。你今天提出来，非常好！”阿捷抬头看了一下墙上的表，还有半个小时的时间，得赶紧讨论这次的主题了。“我们接下来看看我们上次提到的敏捷测试，你有什么最新进展吗？”

“我这几天思考了一下，我觉得我们的项目有必要采用XP的持续集成。”阿朱针对自己的“敏捷测试”目标，提出了自己的想法。

“为什么要持续集成？”阿捷问。

“你看，我们现在的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试，随着软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划分模块这种传统的模式的弊端也越来越明显，由于很多　Bug　在项目的早期就存在，到最后集成的时候才发现问题，我们测试人员需要在集成阶段帮助开发人员花费大量的时间来寻找Bug　的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况！”

“是啊，所以好多团队在这个阶段的除虫会议（Bug　Meeting）特别多，会议的内容基本上都是讨论Bug　是怎么产生的，最后往往发展为不同模块的负责人互相推诿责任。”

“通过持续集成，可以有效地解决这个问题。”

“具体该怎么做呢？”阿捷拿起笔，准备记录。

“你看我们的开发、测试流程：当任何一个人修改代码后，首先运行单元测试；通过后，提交代码；构建产品；把它放在模拟的产品运行环境下，进行测试；遇到问题，进行修正并重复上述过程。我们需要首先让上述过程自动化。”

“嗯，这样肯定可以大幅提高开发测试效率。”阿捷表示赞同，并示意她继续讲下去。　txt小说上传分享

第10章　持续集成（3）

“我觉得需要做这样几件事情：编译自动化、单元测试自动化，再加上自动打安装包、自动部署到测试环境，并进行功能测试、性能测试！”

“我觉得还有必要加上一条，自动统计测试结果，并通过邮件发送给相关的人。有了这样的一个框架，你们测试人员就可以从一些烦琐的手工工作中解放出来，做真正有意义的事情了。”

“嗯，有道理。”

“看来关键是如何实现完全的自动化，从读取源代码、编译、连接、测试，整个创建过程都应该自动完成。对于一次成功的创建，我们要做到在这个自动化过程中的每一步都不能出错。”

“这么一来，也就不需要专人做Build　Manager了！我总算解放了　。”阿朱对这个想法的实施，肯定已经神往很久了。

“嗯，具体的工作是不需要你亲自动手了，但是策略性的东西，还得你把关。譬如软件配置管理（SCM）、分支合并策略、软件发布通知（Release　Notes）等。”

“这些工作不需要经常做的。我会搞好的。”阿朱笑着说。

“不过，上述所说的持续集成过程，实际上要求开发过程也要有对应的改变，譬如自动单元测试那块，应该由开发人员负责。”

“对，因为这不再是传统的编译和连接那么简单，属于自测试的范畴。自测试的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试，将所有的这些自测试代码整合到一起形成测试集，在所有的最新的源码通过编译和连接之后，还必须通过这个测试集的测试，才能算是一次成功的创建。”

“这好像就是McConnell　提出的‘冒烟测试’吧。”阿捷突然想起了前几天看过的一篇文章。

“对！这种测试的主要目的是为了验证创建的正确性。在持续集成里面，这叫做集成验收测试——Build　Verify　Test，简称　BVT。我们测试人员按理不会感受到　BVT　的存在，我们只针对成功的创建进行测试，如功能测试。”

“嗯，这块我会跟大民、小宝他们说的，让他们去实现。”

“那我和阿紫负责其他部分的测试框架。”

“我还有一个问题，持续集成和日创建有什么关系？二者是不是就是一个东西？”阿捷绝对不会放过任何一个学习的机会。

“有些不同。

持续集成强调了集成频率，和日创建相比，持续集成显得更加频繁，目前业界推荐的最佳实践是每一个小时就集成一次。

持续集成强调及时反馈，日创建的目的是得到一个可以使用的稳定的发布版本，而持续集成强调的是集成失败之后向开发人员提供快速的反馈，当然成功创建的结果也是得到稳定的版本。

日创建并没有强调开发人员提交（check　in）源码的频率，而持续集成鼓励并支持开发人员尽快提交对源码的修改并得到尽快的反馈。

“噢，重点就是‘频率’和‘反馈’两个方面。”阿捷若有所思。

“对！持续集成有一个与直觉相悖的基本要点，那就是‘经常性的集成比偶尔集成要好’。对于持续集成来说，集成越频繁，效果越好　，如果集成不是经常进行的，少于每天一次，那么?