至去年09年12月份开始，一直在做分布式存储系统的测试。那个时候除了接口测试以外，别的测试回归全部都是手动回归。看着接口测试自动回归，好几百个用例一天就回归完毕了，心中无比的苦闷。于是开始自己尝试着写写自动化测试代码，但往往都是只能覆盖很小的一个方面。最后开始写Linux Shell自动化脚本，通过ssh来控制整个集群的操作。写得很辛苦，可以达成自动化的目标，但是Shell脚本的代码比较难以维护，调试也颇为费时。难道就没有Junit，gtest那样方便的测试工具吗？这时，有位大大把在另一分布式存储系统上成功运用的分布式自动化测试解决方案推荐给我，让我眼前一亮。

　　这套自动化测试解决方案包括三部分：

　　一、STAF（Software Testing Automation Framework）软件测试自动化框架。这是一个开源的，支持多种平台，多种语言的测试框架，他的目的在于使软件测试更加容易，尤其更易于实现测试的自动化。

　　二、Junit，一个回归测试框架，大名鼎鼎，有关他的介绍我就不赘述了，我们把用例的代码实现都放在Junit里，方便自动化回归。

　　三、Linux Shell脚本。一些操作可以放在脚本里执行，比如重启网卡之类等等的。一些简单的操作也放在Shell脚本里，可以使得测试代码更加简洁清晰。

　　这三部分是如何协同工作的呢？我们以启动集群中指定一台服务器上的的一个进程为例。

　　一、首先客户端机器上Junit开始执行用例，此用例的验证点就是是否成功启动指定一台服务器上的一个指定进程。

　　二、在用例中调用STAF提供的方法，启动指定机器上的指定进程。

　　三、被指定的那台服务器上的STAF执行传递过来的启动命令启动指定进程。

　　四、执行启动后返回执行状态给客户端机器。

　　五、客户端机器上利用Junit提供的丰富断言来判断是否成功。

　　如下图所示：

　　在把一些基本操作作为基类方法整理后，你会发现你的用例代码将会非常简洁。可维护性，扩展性都上了一个台阶。Junit作为测试人员的基本工具，相信大家的上手都会比较快，用例的实现上应该说是没有什么门槛的。并且易于和hudson进行集成，为日后的持续化回归奠定了良好的基础。最重要的是这些都是自动的，再也不用写一大堆监控脚本，两只眼睛死死盯住屏幕，“人肉”回归了。