寫在前面

 

有時間我會把我初步的想法整理好分享出來，大家一起來探討它的可行性，它不一定適用你們的業務，但是非常適合我專案的業務。雖然它也可能難產，但是我想盡力去做、去完成，也算鞏固一下自己的知識，應用到專案中去。

這個框架需要大家不斷的鞭策、一起努力、共同搭建，可以隨時發表看法，歡迎拍磚，求不打臉！

它為何而來？

• 團隊專案流程的規範，團隊下一步的目標就是介面測試
• 一款應用上線前要測試3次伺服器（介面一樣，環境不同），純手工驗證是受夠了

它能做什麼？

• 簡單的介面測試（主要回歸測試）
• 持續化整合
• 介面日常監控
• 可能還有？

缺陷？

還沒想，相信你們閱讀後就會幫我回答了

框架整體思路

跪求積極發表看法、框架還在萌芽階段、確保方向細節處理。

天啊擼，又是Java

沒錯就是Java，可以是其他嗎？可以，你熟悉的語言都可以，首選Python，用過的都知道

Java的考量：

• Python很久沒碰了，忘的差不多（真相是原來水平就入門級還不到吧）
• 專案是Java開發的，http框架是基於okhttp的二次封裝（不以專案為導向的都是扯淡）
• 前面發現一個http框架的bug，想看下還有沒有什麼沒發現的bug，特別是多執行緒的時候它的單例會不會有問題（功能測試一般遇不到http框架的bug）

框架雛形

沒錯，這個框架已經在默默地搭建了。

目的：通過簡單的介面驗證發現伺服器介面異常

經驗：一般認為Response body code

實現：判斷每個介面的Response header code，如不是200則介面失敗（常見code：404/502，302情況說明，因為是API所以應該沒有重定向的，基於目前的經驗判斷，歡迎指正），再判斷Response body的JSON裡面的StatusCode是否為200，不是則初步判斷介面失敗，最後檢視失敗的檔案即可

評價：速度慢、手工錄製、簡單迴歸、簡單驗證

關於程式碼：明天補上

目前的情況彙報下：

• 介面錄製（已完成）

  • 通過手工錄製/monkey錄製
  • 資料來源錄製時機：功能測試過一遍後，一般此時伺服器介面比較穩定
  • 自動儲存每次請求的URL，用於與索引器遍歷，得出Diff
    檔案
  • 自動儲存每次請求的Request header、Request body、Response header、Response body
  • 考慮加入統計每次請求的耗時

• 索引器思路JAVA版（已完成）20160724

  • 由來：加快遍歷速度
  • 掌握知識：因沒接觸過索引器的知識，歡迎懂的/有更好思路的童鞋幫忙指正，改進
  • 思路
  • 取出介面頁面某個應用的所有介面存進一個List
  • 每個介面取出首字母，存進HashMap(key > firstLetter, value > start|end)，存字母在List中出現的位置和結束的位置(即字母區間)，中間用分隔符分割
  • 當資料對比時遍歷HashMap，匹配key，當匹配時拿出value，以分隔符分割value存進一個長度為2的陣列
  • for迴圈陣列的區間去匹配介面
  • 程式碼

  傳送門

• 拉取介面（已完成）20160726

  傳送門

• 移除錄製的介面（已完成）20160726

  傳送門

• 意外驚喜

  • 發現了還未登入就請求介面的若干bug，因為未登入請求的Header會缺少引數，伺服器JSON返回500錯誤（有些錯誤直接被客戶端遮蔽了，所以功能測試是沒發現的）
  • 之前公司的部分應用部分模組沒有內外網之分，導致不敢跑monkey，怕亂髮帖子。現在有新思路：通過Fiddler攔截髮帖Request header修改引數或缺少欄位後請求伺服器，伺服器必定返回500錯誤，此時帖子是傳送失敗的，再攔截Response body修改引數，欺騙客戶端發帖成功，進而可以跑monkey

框架的下一步

除以下幾點，其餘的都是下一步需要做的：

• Response body的各種引數驗證（此階段簡單驗證就好，參考框架雛形的經驗table）
• 注入特殊傳參介面資料
• 持續整合
• Html/郵件通知

關於資料來源儲存方式的思考

目前的情況：以最簡單的方式txt儲存

思考：

• xml儲存？那一個介面的所有傳參型別怎麼存？一個介面多個xml？
• 資料庫儲存？
• excel？
• 歡迎提供更好的方式

綜上所述，歡迎一起探討！

疑難雜症傳送門