RFint是目前team测试的项目。它的大部分testcase已经ready，并开始了manualtest。现在要开始自动
测试的开发。
测试环境
* 一台celerra cabinate，包括至少两个datamover
* 一台clariion作为后台storage
* 若干linux client
* 若干solaris client
* 若干windows client
* 也许还有hpunix client
1. 分层
主要分成3层。
最上层(distribution runner)
主要负责处理“在多个client上运行测试”的问题。具体包括测试程序的deploy，execution and report generation。
用ssh/scp来处理网络通信，用nfs/cifs
server来处理文件共享/交换的问题。(don't invent wheels)
这一层用bash开发
中间层(
test runner)
中间层包装test这样一个概念。test是一系列相关testsuite/testcase的集合
test里所有的testsuite/testcase共享相同格式的testenv, testconf
test里所有的testsuite/testcase共享library，实现代码重用。
中间层还向最上层提供了统一的调用接口
中间层可以用任何合适特定test的语言开发（向上的接口基于cli）
test的范围的划分是考验经验的。小的test更容易理解，但代码重用性低。
最下层(test logic implemenation)
具体的testsuite and testcase， 执行实际的测试逻辑
在testsuite层次，所有的testcase可以共享testconf，setup，cleanup和library
一般和中间层使用相同的开发语言
1. 从
自动化测试的角度，测试可以分成两种
一种是数据驱动的，这是程序擅长的。
一种是过程驱动的，这是人类擅长的。
一般regular的testcase容易数据驱动
一般negative的testcase都是过程驱动的
应该尽可能把过程驱动的testcase转化为数据驱动的testcaes。
1. 如何把过程驱动的testcae转化为数据驱动的testcase
构造更通用的测试环境，满足更多的testcase
比如有两个关于文件copy的case，一个是在folder内部copy，一个事跨folder copy，那么构造一个多folder的环境，就能满足这两个testcase的要求
构造更丰富的操作集合，包括多个testcase中的操作
比如一个testcase是关于文件写操作，另外一个是关于文件读操作，那么构造一个既包括文件写又包括文件读的操作集合，就能实现这两个testcase的覆盖要求
关键字驱动
有时候，仅仅是data还不足以覆盖所有的测试。这时，可以加少量能“影响”测试逻辑的关键字(keyword)。
比如对于文件写有“同步”和“异步”两种，那么可以加入对应的关键字。但增加这样的关键字会提高测试逻辑的复杂性，所以一定要把握好度。
通过上面的方式，可以程序擅长的方式处理更多的testcase。
1. 自动化测试case和手工测试case不用一一对应
由上可见，自动化的case和手工测试的case很不一样，完全不应该一一对应。
1. 写简单的程序
最上层和中间层通过cli的方式调用，它们完全是独立的。
中间层和最下层是API级的，需要小心不要让他们联系太多。现在中间层只为最下层提供testenv, testconf和common library.
1. testresult打印到testlog里
没有专门的test result文件，而是打印到testlog里。这样的好处是
简化了log的管理，framework的代码更简单
劣势是需要另外的程序来从testlog中吧result parse出来，在重新格式化。
1. setup/cleaup在那里执行的问题
在test level有setup和cleanup，这没有什么问题，但到底是testsuite还是testcase level加入setup/cleanup，这是一个问题。
现在的方案是在testsuite level。也就是在开始运行testsuite里的testcase之前，执行setup，然后依次执行testcase。 而不是，在运行每一个testcase前都运行setup。
这样的好处是，testcase可以实现自己的setup/cleanup，但framework不负责管理他们。
