測試-http介面測試點
前言
2015年開始接觸QA這個行業，從實習到正式入職，一直都在Qunar的QA崗位上。回顧這兩年多的工作經歷（中間回學校一段時間），雖然做了許多自認為很高大上的東西，但是晉升答辯中被問到的許多基礎問題，卻成了自己最薄弱的一項。所以現在更想把更多的經歷去放到基礎知識的鞏固整理上，將自己的知識形成體系，樹立自己的方法論。
答辯中被問到：給你一個dubbo介面，如何進行測試？這個問題在答辯前自己也進行了整理相關的wiki，從配置、程式碼、系統等多角度都進行了測試點的總結，但是答辯中回答的也不是很流暢，拋開因為當時緊張的原因，其實最根本的還是自己的方法論並不是特別完整，還需要進一步的鞏固。所有出於這個原因的考慮，想從http、rpc、mq三個角度去總結相關測試點。是否還要總結資料庫相關的測試點，這個以後再考慮。
這是第一篇，關於http的測試總結。
checklist
checklist對QA來說一定不陌生，我們做事之前都可以寫一個checklist，來減少我們所犯的錯誤。
那麼對於一個http介面又有哪些check點呢？
- 功能
- 效能
- 併發
- 日誌
- 監控
- 安全
- 系統結構
以上是我能想的一些類別，歡迎各大牛隨時補充。
1.功能
這部分我們必須實現產品提出的所有需求點，如果不能實現，必須在需求階段就溝通好。
這裡跟多的是QA對業務的理解，能夠考慮到各種業務情景，並且特別要關注邊界測試點。
2.效能
效能的質量是需要開發進行保證的，對於QA而言我們僅僅是發現其中的效能問題。我們的手段你會第一時間想到壓測，但是在Qunar這種快節奏的公司而言，並且我所負責的是售後相關的業務，本身的效能問題就不多，所以更多的是通過code diff進行發現（Qunar的測試開始於diff程式碼，開發需要給QA講程式碼，QA會通過程式碼發現bug、增加測試點等），根據diff指出常見的效能問題。
這裡我們要關注http介面的
- qps是多少？
- 介面響應的平均時間與最大時間？
- 會不會因為其他因數有所變化？
- 新介面的上線會不會影響現有功能的效能？
3.併發
- 是否涉及到併發問題
- 是否需要加鎖
4.日誌
- 入參
- 出參
- 異常堆
- 便於查詢的業務日誌
5.監控
- 訪問總數
- 異常
- 時間
- 業務成功
- 業務失敗
- 特殊要求
6.安全
安全其實要分的東西就很多種了
- 協議的選擇：http or https
- 業務許可權：登入許可權、操作許可權、登入過期時間
- 敏感資訊：特殊資訊的加密包括日誌、引數、資料庫儲存
- 請求型別：get or post
- ip白名單：白名單是網關出口ip，並不是工程所在ip
- sql注入
- js注入
- CSRF
- 解碼
7.系統結構
這部分其實是最難的，因為要考慮到系統整體的架構。許多公司都會選擇ng作為反向代理伺服器，這裡就要考慮相關配置；如果是前後端分離，rpc服務化，又要考慮呼叫鏈的問題。
- 介面呼叫鏈的超時處理
- 異常降級處理
- 是否冪等
- 是否影響主流程
- 是否無縫上線