之前的第一套框架在使用过程中发现存在以下问题：
一. 框架1缺点：
1.登陆的账号每个人写的不一样，一旦用户在测试环境被修改，则导致用例失败
2.每次读取访问网址，需要在同一个java文件下切换测试和正式环境，浪费时间
3.封装的过于模块化，导致方法和用例分离太破碎，只看用例并不能直观看出执行的思路，复杂化了
4.每次httpclient都需要绑定各个用户，太麻烦
5.根据类名并不能知道里面写了哪些用例
二. 框架2改变：
先介绍一下轻量级的HTTP开发库 Unirest的用法：
- 使用Unirest请求的数据一般是
JsonNode，若返回类型报错，一般为String，最后得到的为.asString(); .header用了设置header的各种参数，包括token.routeParam用于设置路径中带有参数的如{cid}之类的- .paramString用于设置get命令中 &的键值对
- .
field用于设置post的参数，也可以直接用一个map,.fields(prams) //prams是一个map，put了很多参数进去，和直接多个fields一样的效果 - 返回的结果打印一般用，response.getBody( ).getObject( ) 得到的JSON对象，之后的JSON解析出需要的内容都是以此为基础分层剥离。
- 返回的状态用response.getStatus(),即返回的状态码，注意有个别成功码并不一样，如前台是200，后台是302
新框架思路：
1.所有的用例用同一个账号，运行哪一个用例，就先清除这个账号附带的所有身份信息，然后构造符合条件的用户，然后执行用例（用户升级和破坏式构造）
2. 对于各个用户之间的httpclient状态切换，直接用用户.attach( )进行状态转换。
3. 写测试用例特别容易出错的地方：
声明一个全局变量cid，动态获取后，所有的方法都引用同一个cid时，经常出现多次调用，使cid不一样。
思路：getCid() 获取this.cid getStatus( )获取获取cid状态的方法，只是参数用this.cid，但是方法里面不能再调用getCid( )，收藏和取消收藏也是如此，
用例组织时，先getCid(）,再执行获取状态，收藏之类的，此时即用的同一个不变的cid，调用成功！！！
4. 任何涉及清理的函数，都不应抛出异常。如果清理失败，打个日志，默默退出。
5. 运行用例前设置：
@BeforeSuite：用来设置Header @AfterSuite发送邮件，使用公司内部的发送邮件的接口
@BeforeClass: 运行整个类之前先清除删除账号信息（有的时候创建公司前先删除公司相关内容），然后用户登录（创建符合身份的用户），审核用户登录，
@AfterClass: 清除删除账号信息，用户和审核用户关闭httpclient。
@BeforeMethod:准备用例
@AfterMethod:清除用例
6.写备注的时候用 /** +回车 生成注释，这样javadoc就可以解析每个类中的用例，生成报告
调试的思路：
1.保证账号名，密码，接口路径，网址，环境配置没有问题（可以先在浏览器中直接调用接口试一试），代理设置时fiddler是否开启了（可以看到报错返回信息）
2.报错异常处理： 可以打印log日志看 logger.debug("the response is {}"+response.getBody().getObject(); 返回的JSON结果是什么，然后做相应处理。
3.最多的异常是空指针（对象没有生成就调用对象方法），HttpHostConnectException（未开启fiddler），UnknownHostException（host地址不对），assert判断值不一致。出现问题最多的就是登陆和身份构建啦！
常见报错原因分析
1.com.mashape.unirest.http.exceptions.UnirestException: java.net.UnknownHostException: ***test01.****.comapi
（1）没有绑定访问的host或者host名称错误，如：***test01.** ** 中间加了一个corp
（2）接口路径错误，api前少了一个/
2.使用logback没有打出日志
其实需要其中一个文件即可，在自定义记录器时引用类名时多打了一个双引号，我是有多粗心！！！
3.运行的返回值为String类型的方法，运行时报错找不到可运行的用例
原因： 有返回值的方法需要调用才能执行。
最后实现的大致的代码结构如下：