简单分析百度ITEST接口测试框架实现
在分析跟踪之前要理解用JUnit4进行参数化测试的过程（@Parameters标记方法最先执行）
1.初试化配置
config.properties
2.收集测试用例
搜索包含config.properties 文件夹的测试集合（获得所有集合的路径）
循环集合的路径找包含caseinfo.properties的目录（获得case），最后将所有的case返回到测试集中。
在caseinfo中是否为stop的case，是不是debug的状态（有的话，就直接运行debug的case，其他的不会执行）
stop的优先权大于debug。
所有的测试集都包含了具体测试用例，这些测试用例已经有自己的数据了
注：具体是如何得到测试用例的数据的，casedata对象，caseinfo.properties中获得caseid,desc（描述），
action（请求地址），status（状态），requesttype（请求的类型），var(变量，此时测试用例会标记为
允许变量替换），
然后找到Input目录，这个目录只支持4种后缀名的文件 properties,soap,json,tpl(会对这些文件进行utf8转码）
tpl，soap文件的话，不做处理，properties（只对post请求处理）解析所有对，到一个map集合中，json格式的
设置json字符串，
接着是Expect目录，暂时没有处理，只是把文件列表设置进去了，
然后是判断Setup和TearDown目录存在吗，设置到casedata中,
最后设置casedata的路径，
这样就得到了一个完整的casedata对象，而一个集合中包含了所有它目录的casedata对象，
最后得到一个用例集合列表。
3.统计case数目
统计总共有多个case，包括要重复执行的次数在内
4.获得当前case
@Parameters标记的方法，返回测试用例集合，而集合中的数据，在每一个testcase执行钱，
都会调用构造函数然后给其赋值
5.初试化数据
然后是setup方法，
1.先清理测试用例的Output文件夹
2.如果是第一个集合，设置cookie
3.如果是第一个集合，执行集合上的teardown
4.执行case中的teardown
5.如果是第一个集合，设置集合上的setup
6.执行case上的setup
6.执行case
然后到执行case的时候
1.首先会休眠一段时间，延迟执行case作用
2.然后将casedata和config交给对应类型服务进行处理，如 HttpServiceClientImpl
前期设置的文件，主要在这里起作用，tpl文件重置input
3.request类型为get，使用requestGetMethod方法，首先将cookie写入头文件中
判断相应的状态码是200吗
4.获得回复内容，并设置为UTF-8格式的，然后返回
5.将获取到内容，写入output文件夹下面的，response后缀名的文件中
6.验证结果，首先生成一个actual.txt文件，然后对比期望结果生成一个diff.html文件，最后验证结果
7.验证结果
前面知道Expect目录是没做任何处理的，只是获得了文件列表，那它是怎么验证的了
1.先对文件进行排序
2.response后缀名的VerifyResponseImpl 的verifyResponseWithExpectString，
csv后缀名的VerifyMysqlDataImpl verifyMysqlDataByCsvFile，
sql后缀名的VerifyMysqlDataImpl，verifyMysqlDataBySqlFile
http后缀名的VerifyResponseImpl verifyTestResultByHttpRequest
select后缀名的VerifyMysqlDataImpl getMysqlDataBySqlUsedToVerify
tpl后缀名的做替换
3.最后如果验证抛出异常就认为是fail的case或者由于认证方法里面断言失败也认为是失败的case
8.清理测试后数据
然后是teardown方法
1.清理当前用例的数据
2.如果是第一个集合的用例，清理集合数据
总结：
整体实现思路很清晰，数据驱动的模式
1.以识别文件名的方式，来识别每一个集合和每一个case
2.约定大于配置的方式，来进行数据处理
3.支持集合和单个测试用例的数据设置和清理
4.验证思路为：查询以文本数据对比，增删改则与数据库中数据对比
不足之处：
1.用例编写比较难（技术要求较高，编写效率低：限制较多，没有用例编写工具）
2.测试结果没有统计功能，以及历史对比功能
3.整个框架扩展性偏低，框架缺乏单元测试，文档说明，虽然是采用接口编程，但整体粒度较大。