一、白盒測試：一種測試策略，允許我們檢查程序的內部結構，對程序的邏輯結構進行檢查，從中獲取測試數據。白盒測試的對象基本是源程序，所以它又稱為結構測試或邏輯驅動測試，白盒測試方法一般分為靜態測試和動態測試。
二、如何做白盒測試
1、使用靜態代碼分析工具：FindBugs先找出一些簡單的bug
- 操作空對象；
- 數組訪問越界
- 線程安全
- 字符串拼接
- 資源關閉
2、diff評估影響范圍，找邊界和影響范圍
往上找，找它的調用鏈，找測試范圍的邊界；
往下找，找它對下游的影響，找影響范圍；
3、做單測，從上往下傳
不只是對改動方法做單測；
還要找到它影響的點，從上到下往下串。
4、單獨拉分支，梳理代碼邏輯
checkpoint：根據checkpoint畫出流程圖/時序圖，后面做接口測試的測試點/檢查點；
bug：梳理代碼時能夠確定的問題；
5、接口測試：
基於第四步代碼梳理的checkpoint來做接口測試；
只做白盒測試不做接口測試，無法將代碼的整個邏輯理順；
6、debug：debug執行、
三、接口測試策略
根據接口文檔，構造不同的參數組合，各種正常/異常的參數，然后組裝請求發送服務端，最后進行返回結果的判斷。但是對線上系統會有極大的風險，因為隨着業務的越來越復雜，很多測試點是接口文檔所描述不到的。
根據代碼梳理的結果來畫流程圖/時序圖，然后根據時序圖上的各個點來構造各種正常/異常的測試場景進行接口測試，這樣才能更為完善的進行接口測試，減小線上的風險。
時序圖：序列圖、循序圖，通過描述對象之間發送消息的時間順序顯示多個對象之間的動態協作，可以直觀的傳達系統內外的交互過程。我們可以簡單的舉個例子：
程序從入口進來，先做了什么邏輯判斷和處理；
處理完成后進行入庫，入庫的數據是什么，關鍵的狀態是什么；
入庫的數據哪些字段是我們要去檢查的，狀態是如何變更的；
緩存的key是什么，緩存失敗的策略又是什么；
如何設計接口測試，微信掃描二維碼支付：
發起支付請求：
構造相同訂單，基於並發或者多線程請求被測服務；
超時；
其它異常；
微信server回調pay接口生成預支付訂單：
回調多次，是否能保證只生成一筆訂單
回調失敗，內部又如何處理
返回未知異常
返回已知異常
接口測試一定要先把代碼的邏輯梳理清楚。如果只從接口文檔的描述來做接口測試，我們對這些后台處理邏輯不清楚，那么這些測試點就會被遺漏，把所有風險都遺留在了線上。
四、接口自動化測試：
1、分析功能及接口的優先級別
實施前，首先應該明確自動化測試的目標，可以從以下幾個維度考慮：
功能維度
業務維度
流量維度
風險維度
黃金流程維度
我們需要從以上五個方面去考慮需要做接口自動化測試的接口有哪些，然后就能夠梳理出各接口及業務的級別（P0、P1、P2）
基於以上分析，我們就定義接口測試的策略，是要做單接口的還是模塊級甚至是系統級的接口測試，又或者是三者都要做。
場景及--單接口
模塊級--只在模塊內，預下單-提交訂單--確認支付
系統級--整個業務流程-訂單-支付-網關-回調
定義自動化達成目標
定義好自動化測試的策略后，然后需要定義自動化測試要達成的目標。例如：
核心接口覆蓋率50%
黃金流程覆蓋率normal級別case，場景級40%
框架建設
基本訴求：case規范要求、case量級預估、現狀：系統變更頻繁程度、業務接入的快慢程度、當前資源投入情況、變更的傾向性
實現：common_env --工具+環境
dao + client --MySQL、Redis、dubbo、HTTP
Core--測試用例能力擴展、執行前、執行后、參數處理等
gen--自動生成代碼
manager--case管理，報告輸出等等
case模板：
clean db.
db init
mock client add
build request param
send request
rpc response assert
db assert
accountDao
columnHolder
assert.assertEquals
accountDaaoassert.assertEquals
log assert
db clean