四、早测试和经常测试——封闭签入和滚动生成

　　敏捷开发中最可怕的事情莫过于在迭代最后一两天进行测试，结果发现了严重功能缺陷或者回归缺陷，导致不能按计划发布给用户试用。要想彻底解决这样的问题，一方面要在迭代开发阶段测试人员就要参与进来，从客户的角度出发对功能需求和设计文档进行文档测试，即文档评审。测试人员和开发还有项目经理一起从源头上保障将要实现的功能是用户想要的。另一方面就是要在迭代的早期就开始就开始测试，特别前几个迭代已经实现好的自动化测试用例，尽早的执行它们可以有效地避免回归问题的出现。在TFS 2010 上专门提供封闭签入（Gated Check-in）、滚动生成（Rolling Builds）和持续集成（Continuous Integration）等功能，帮助敏捷团队实现早测试和经常测试。这其中封闭签入和滚动生成是对敏捷团队比较实用的功能。

　　封闭签入是TFS 2010 提供的一种新的代码签入方式，在配置这项功能后，当用户要签入任何代码时，系统会先将用户本地要签入的代码打包成一个搁置集（shelve-set），然后提交到服务器端，TFS 生成（Build）服务先从TFS 源代码控制器中同步项目的最新代码，再将提交的代码与之进行自动合并，然后进行编译，如果编译成功，则执行配置的自动化测试用例，如果测试用例全部通过则代码会被自动签入到代码库中，否则返回错误信息给用户，代码是不会进入到代码库。表面上看是与产品测试没有直接关系，但实际上它和测试以及最终产品质量的密不可分。因为代码签入是整个开发过程中发生最为频繁的操作，每次签入代码的质量直接影响着日常的开发活动。对于绝大多数的开发团队来说，check in 代码前不仅要保证编译通过，同时还要最大限度的保证新代码不会破坏已有的功能，也就是要执行测试用例去验证。Gated Check-in 中提到的“Build 成功”，实际上包含两部分内容：编译成功和测试用例执行成功，有了它作为保护代码库的第一道屏障，就可以保证它在任何适合都是可编译，并且达到一定质量标准的。

　　滚动生成是在VS2008种就有的功能，当TFS检测到在它所监控的范围内有任何新的代码变化被签入后，它就启动对最新的代码库进行生成验证，该验证包括编译和运行指定的自动化测试用例。之所以称之为“滚动”，因为它是在一个生成验证操作完成后再去探测有没有新的签入发生，对这期间发生的所有新签入进行新的生成验证。这里需要再强调一下滚动生成的重要意义：它看似只是一个自动生成代码的功能，但实际上起着协调整个开发团队、时刻监控代码库质量、以及尽早暴露产品问题的作用。因为滚动生成时刻都在不停的运转着，对于任何代码签入它都保持着警觉，会去自动验证编译是否成功，自动化测试用例是否都能通过。它就像一个不知疲倦的“代码守护者”一样监控着代码库，第一时间发现其中的任何问题，将问题通知给整个团队，从而避免了问题的积累和拖延。这非常符合敏捷开发中“今日问题今日解决，不要拖到以后”的原则，它帮你最早的发现问题、报告问题，开发团队则应该建立制度要及时响应滚动生成所报告的问题，把它作为Priority为0或1的高优先级问题去对待和解决。

　　封闭签入和滚动生成都是来保护代码库的正确性和产品质量，它们是否在功能上重复反而让我们不敏捷了呢？其实两者并不重复，只是各有侧重，将它们搭配使用才会发挥其最大效能。

　　封闭签入是在代码进入代码库之前进行验证，签入提交者一般希望竟快知道结果，以便决定下一步的工作，所以封闭签入的时间（编译和运行测试用例）不要太长（10-20分钟）。这也就决定了我们加入的测试用例不能太多，只添加那些高优先级的测试用例，保证主要的用户故事不被破坏。滚动生成是在代码签入后在后台执行的，由于不存在着与用户的交互等待，所以它执行时间可以更长（几个小时），可以为它加入更多的测试用例，从而全面验证代码库的质量，一旦有任何问题它可以及时通知团队进行修复，这种验证是在几个小时或者每天都在发生的，保证了敏捷对频繁测试的。