这是我在从事网站自动化测试的工作当中构建出的一个“生态系统”。“生态系统”这个概念是我从公司的前辈身上学到的，他一直以来都认为自动化测试人员不应仅仅局限于编写测试代码，还应该让整个自动化测试的过程（测试代码的持续集成、分发、执行等）都自动化，形成一个“系统”，这个系统的自动化程度越高，自动化测试人员越省力。
　　一、概念
　　这里我画了一张示意图：

　　之所以称之为“生态系统”，是因为建成之后需要的人为干涉很少，其余的时间都是系统内部循环运作。作为自动化测试人员的你只需要提交代码，之后便可以在AutomationDashboard上看到运行的结果了，其余的事情都由系统内部消化。当然，结果的分析还是需要人来完成，机器还没有聪明到可以灵活分析出各种各样让case fail掉的原因。
　　我们可以把整个系统看作一个黑盒子，那么上面的图可以变成：

　　实际上这里画的人不于自动化测试人员，也可以是：
　　（1）产品的管理者，比如产品经理需要从自动化回归测试知道这次release有无推迟风险；
　　（2）团队的管理者，比如开发经理、QA经理需要从自动化的daily/weekly regression知道近的代码质量如何；
　　（3）开发人员，他们也许会想通过quick regression（提交的产品代码被部署到测试环境之后运行的测试）知道自己刚提交的代码有没有破坏系统的基本功能；
　　（4）其他帮忙做自动化测试的开发人员、刚刚开始学习编写自动化测试代码的手动测试人员，他们不必关心生态系统的内部实现。
　　二、实现
　　说完概念，接下来该说说具体实现了。我这里讲的是我认为适合我所测试的产品的实现，工具不止一种，方式不止一种。Jenkins可以用TeamCity或其它CI替换，git也可以是svn或tfs，AutomationDahsboard可以用.NET、SpringMVC、ROR等等实现，运行测试的slave可以是Windows/Linux/Mac（土豪！），总之选择一种适合你所测试的产品的实现。还有一点是自动化测试代码是用关键字驱动思想实现的，这是另外一个话题了，有时间另外写篇文。
　　好，进入正题。依次说说系统的每个重要组成部分吧：
　　1、SCM（Source Code Management）。我选的是git，可以是git服务器（公司自己搭建了一个git server），也可以是一个bare repo（http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/） 。
　　2、CI（continuous integration）。我选的是部署方便、插件丰富的Jenkins。
　　它的职责是：
　　（1）从git上取出代码，build（.NET对应msbuild，如果是ruby则不用build了，直接部署即可）；
　　（2）把build好的*.dll部署（这里即是拷贝）到所有的slave上；
　　（3）启动或停止所有slave上的AutomationService（后面还会讲到AutomationService），从而控制测试的执行。