之前的第一套框架在使用過程中發現存在以下問題：
一. 框架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類型的方法，運行時報錯找不到可運行的用例
原因： 有返回值的方法需要調用才能執行。
最后實現的大致的代碼結構如下：