这些年多多少少写过许多不正经的自动化测试框架，每每开开心心的写完，都会发现这不正经的框架跟不上时代的转变，测试环境各种各样的突发环境，数据各种各样的变化，功能各种各样的需要增强，烦恼不堪，就挺想写一个稍微正经一点的，耐用的，更加普遍性好扩展，好管理数据的自动化测试框架来。组里的意思是，要上就要上个大的，再于是乎，就有了nits这个东西。顺带着说，其实它本来叫marlboro（万宝路），原因是哥那时候正抽着红白相间的，然则既然要正经点写，那就用个正经点的名字把，NITS（Netease Interface Test Solution），不得不说组里的团结的力量就是大，这名字大家一起取的，那是相当的霸气。这个框架先支持我们的本职接口测试，但又不止于此，支持起别的测试相信扩展起来也不是这么难的事。

　　Nits需要什么，很简单也很麻烦，一要尽量把代码和数据隔离，二要扩展起来一定要简单，三要使用起来方便，四是日志要清楚。

　　代码和数据隔离篇

　　代码和数据的隔离好处是什么？最简单的，我们以后写用例不怕不怕了，不需要太多的考虑代码的东西，专注的写逻辑吧。看起用例不怕不怕了，一目了然的知道这个用例大概是干什么的，改起来so easy。

　　数据流的存储暂时看来最好还是用xml去存储，缺点是xml的格式导致篇幅有点长，如果用例的操作比较多久需要很多屏才能看完整个用例，但是优点更明显，可读性很高，操作简单，许多类库可以帮我们去操作xml文件。这里我选了xstream，xml和类的转化很简单。

　　扩展方便篇

　　这个地方需要考虑的情况就比较多了。不同的项目的自动化测试会碰到各种不同的需求，比如说环境清理，动态生成的参数，可配的相对稳定的参数，格式各样的结果检查方法等等。所以总结一下，最大的问题就是适应性。

　　抽象一下，我们做自动化需要用到参数的可变和方法的可变。

　　设计中，加上了两个配置文件，1个是环境配置EnviromentConfig.xml，主要放置的是我们需要支持的一些框架支持功能的配置，比如数据库的地址和用户信息，ssh测试机的地址和用户信息，服务器的路径，测试数据放置的地点等。1个是自定义配置ManualConfig.xml，不同项目可以把自己会用到的一些自定义参数放置到这个配置文件里，配置文件比较简单，全是key-value的存储方法，例如

　　另外用户会用到的方法，不管是验证结果的方法还是动态生成参数的方法都采用挂载，框架根据挂载的配置去反调。例如

　　同样的，这些也会放到两个配置文件里，公共支持的一些通用的方法配置到EnviromentConfig.xml，自定义的方法配置到ManualConfig.xml

　　使用方便篇

　　有了上面两篇介绍的东西，我们就可以开始使用框架去写自动化接口测试了。我们要写一个用例，目标是挂载一个云硬盘，以下存储的测试数据，我们针对测试数据来分析

　　1、http connection的值根据需要发送的方式写死，我们可以用post方法，也可以用put等，这里我们用post方式去发送

　　2、http服务器的地址在EnviromentConfig.xml里面配置好，其他的http url带的参数如上面配置

　　　　a）写死的部分如Action参数的写法

　　　　b）云硬盘需要新建到虚拟机的，虚拟机是相对固定的，我们换个环境可能就要换虚拟机，我们把虚拟机的InstanceId配置到ManualConfig.xml里面，key叫validInstance，value就是这次会用到的虚拟机uuid。InstanceId这个参数的写法就是从配置文件里去取validInstance对应的值赋给InstanceId这个参数。

　　　　c）有些参数是动态生成的，比如VolumeId就是卷的编号，这个编号是创建完了云硬盘会自动生成的，我们的取法是从数据库里拿到这个id。我自己写了一个根据卷名去取Id的方法，挂载到ManualConfig.xml，框架会根据getVolumeIdFromName对应的类和方法名去反调取得卷ID，赋给VolumeId参数

　　3、接下去我们要检查返回的信息对不对，我提供了一个公共的检查方法叫CompareJson，已经在配置文件里挂载好了，用的时候直接把期望的返回值写到value下就好了

　　像我们写的一些getVolumeIdFromName方法都是高度复用的，以后其他用例就可以直接用了。框架的jar包都上传到公司的maven库了，咱要用框架直接去公司的maven库下一个就行了，so easy.

　　日志篇

　　无论对开发和测试来说，日志都很重要，因为自动化的代码都是不间断跑全部用例的，等跑完所有用例，失败用例的环境早就清理掉了，我们需要根据日志去分析出了什么问题才好重现。记录日志的工具很简单，log4j绝对能够满足需求，打什么日志，才是重点。http请求的信息，实际的参数的信息，尤其的用例失败后的提示信息一定要准确详尽。

　　这些年我们写的nits日志差不多就先说到这里把，我们在不断的完善框架，更快更好更强的服务我们的自动化测试，大家有什么意见建议的请直接留言，谢谢。