当开发人员开始开发“登录功能”时，测试人员会和他说，这里有三个测试用例，你的开发完成时，我需要看到至少三个自动化测试覆盖这三种情况。开发人员说，没问题。

　　当开发人员开发完毕，测试人员看到了这三个自动化测试用例后，测试人员说，“可以了，我再进行一些登录的手工测试和探索性测试，你给我一个测试环境吧。”

　　那么开发人员如何给测试人员准备测试环境呢？

　　这也好办，我们不是有持续集成服务器（以下简称CI）嘛，开发人员提交代码到SVN后，CI检测到有代码提交，会自动运行一遍“mvn clean install”，  如果结果是Success，CI会生成一个构建号码，比如“1292”。

　　开发人员会对测试人员说，“我的功能代码对应的CI构建号是1292，你去把1292号版本发布到测试环境吧。”

　　这里先说明一下，我们的环境分为DEV，SYS，UAT等。这几个环境的配置大都是一样的，只是给不同的人使用。其中，DEV是给开发人员开发用的，SYS是给测试人员测试用的，UAT是给产品经理和BOSS演示用的。

　　这时候，是自动化带来的威力了。

　　如上图，测试人员访问CI服务器，会看到这样的构建流水线，1292号版本已经在CI上运行通过（第一个绿色），并且被部署到DEV环境中（第二个绿色），SYS和UAT还没有部署1292号版本（蓝色）。

　　由于我们事先已经在CI上配置好了把代码部署到测试环境的脚本，用Groovy写的，所以测试人员只需要在“1292”号版本的sys环境上点击一个按钮（上图中红色框所示），能把代码发布到测试环境了。

　　上图是一个已经发布到测试环境的版本。我们也可以用同样的办法发布某个特定版本到UAT环境，随时给BOSS做演示。

　　几分钟之后，测试人员开始Happy地进行手工测试和探索性测试了。

　　新功能发布到测试环境后，如果测试人员发现功能不对，想手工验证下当前测试环境的版本，也是可以的。只需要在浏览器输入“http://应用地址/appcheck.jsp”，能得到如下页面，

　　其中的信息包括：应用的maven版本号，CI服务器（我们用的是免费的Jenkins）构建号码，SVN提交版本号，构建时间等信息。

　　如果测试人员又发现了一些Bug，会和开发人员一起尝试着再写一些自动化测试代码，以此保证一些重复的验证都由便宜又听话的机器去做，测试人员则抽出他们宝贵的精力来关注测试策略和探索性测试。

　　好了，三天以后，具有自动化测试代码的“登录功能”OK了，产品经理/Boss看后非常满意，说可以发布到产品环境了。

　　那么，我们是怎么发布到产品环境，我们的上线流程是怎么样的呢？

　　还有和系统B 的联调，我们是怎么做的呢？

　　未完待续，敬请期待。。。