一、什么是白盒測試
白盒測試是一種測試策略，這種策略允許我們檢查程序的內部結構，對程序的邏輯結構進行檢查，從中獲取測試數據。白盒測試的對象基本是源程序，所以它又稱為結構測試或邏輯驅動測試，白盒測試方法一般分為靜態測試和動態測試。
二、如何去做白盒測試
網上很多介紹白盒測試的文章會提到白盒測試的方法有：代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、路徑覆蓋等等。實際工作中的白盒測試並不是一上來就進行代碼分析，我個人理解白盒測試應該從以下幾個步驟來一步一步執行：
1、使用靜態代碼分析工具：Findbugs先找出一些簡單的 bug
- 操作空對象；
- 數組訪問越界；
- 線程安全；
- 字符串拼接；
- 資源未關閉；
2、diff評估影響范圍，找邊界和影響范圍
- 往上找，找它的調用鏈，找測試范圍的邊界；
- 往下找，找它對下游的影響，找影響范圍；
3、做單測，從上往下串
- 不只是對改動方法做單測；
- 還要找到它影響的點，從上到下往下串；
4、單獨拉分支，梳理代碼邏輯
- checkpoint：根據checkpoint畫出流程圖/時序圖，后面做接口測試的測試點/檢查點；
- bug：梳理代碼時能夠確定的問題；
5、接口測試
- 基於第四步代碼梳理的checkpoint來做接口測試；
- 只做白盒測試不做接口測試，無法將代碼的整個邏輯理順；
6、debug再做一遍
- 遠程debug，將整個流程走一遍；
另外，對於接口測試和白盒測試，有些公司會引入代碼覆蓋率工具來衡量測試用例對代碼的覆蓋率，關於這一點我們將在其他文章中做詳細介紹。
常用的代碼覆蓋率工具有：
- Cobertura
- EclEmma
- Jacoco
三、接口測試的策略
看過有些介紹接口測試的文檔，核心思想就是根據接口文檔，構造不同的參數組合，各種正常/異常的參數，然后組裝請求發送服務端，最后進行返回結果的判斷。這可能是很多測試同學認知的接口測試，我們不能說這么做是錯的，但是，如果我們只是這樣來做接口測試，對於線上系統來說有着極大的風險，因為隨着業務的越來越復雜，很多測試點是接口文檔所描述不到的。
在上面描述白盒測試的步驟時我們說到會根據代碼梳理的結果來畫出流程圖/時序圖，然后根據時序圖上的各個點來構造各種正常/異常的測試場景進行接口測試，這樣才能更為完善的進行接口測試，減小線上的風險。
什么是時序圖：
時序圖（Sequence Diagram），亦稱為序列圖、循序圖，它通過描述對象之間發送消息的時間順序顯示多個對象之間的動態協作，可以直觀的傳達系統內外之間的交互過程。我們可以簡單的舉個例子：
- 程序從入口進來，先做了什么邏輯判斷和處理；
- 處理完成后進行入庫，入庫的數據是什么，關鍵的狀態是什么；
- 入庫的數據哪些字段是我們要去檢查的，狀態是如何變更的；
- 緩存的key是什么，緩存失敗的策略又是什么；
如何設計接口測試
我們以下面這個微信掃描二維碼支付為例來說明：
發起支付請求
- 構造相同訂單，基於並發或者多線程請求被測服務；
- 超時；
- 其他異常；
微信Server回調Pay接口生成預支付訂單
- 回調多次，是否能保證只生成一筆訂單
- 回調失敗，內部又如何處理
- 返回未知異常
- 返回已知異常
調用微信下單接口提交預支付訂單
- 調用失敗，如何處理
- 預支付訂單不存在
- 預支付訂單過期
確認訂單
- 密碼正確
- 密碼不正確
返回訂單詳情
- 訂單不存在
未收到支付狀態
- 查詢不到結果
- 查詢到支付中/支付成功/支付失敗
通過以上分析可以看出，為什么我們說做接口測試一定要先把代碼的邏輯梳理清楚。如果我們只從接口文檔的描述來做接口測試，我們對這些后台處理邏輯不清楚，那么這些測試點就會被遺漏，把所有風險都遺留到了線上。
四、接口自動化測試
1、分析功能及接口的優先級別
在談到自動化測試的時候，很多同學上來就說：我們使用 Python + UnitTest/Java + Junit，使用了什么什么技術，使用了什么什么框架。但是在我們考慮實施之前，首先應該明確自動化測試的目標，可以從以下幾個維度考慮：
- 功能維度
- 支付
- 代收
- 代付
- 開戶...
- 這些功能包括的接口有哪些，條用順序是什么樣的，具體的執行流程又是什么樣的
- 業務維度
- 核心業務
- 流量維度
- 百萬級別
- 千萬級別
- 風險維度
- 資金風險：出金、入金
- 黃金流程維度
- 核心業務流程
我們需要從以上五個方面去考慮需要做接口自動化測試的接口有哪些，然后就能夠梳理出各接口及業務的的級別（P0/P1/P2）。
2、自動化策略
基於以上分析，我們就定義接口測試的策略，是要做單接口的還是模塊級甚至是系統級的接口測試，又或者是這三者都要做。
- 場景級 --> 單接口
- 模塊級 --> 只在模塊內，預下單->提交訂單->確認支付
- 系統級 --> 整個業務流程->訂單->支付->網關->回調
3、定義自動化達成目標
定義好自動化測試的策略后，然后需要定義自動化測試要達成的目標。例如：
- 核心接口覆蓋率 達到 50%
- 黃金流程覆蓋率, normal級別case, 場景級40%, 模塊30%,系統 30%
- 出金業務, 100% normal級覆蓋
- 入金, 60% normal級覆蓋
4、框架建設
基本訴求
- case規范要求
- case量級, 預估, 2000多條.
- 現狀: 系統變更頻繁程度, 業務接入的快慢程度, 當前資源投入情況. 變更的傾向性
實現
- common + env --> 工具 + 環境
- dao + client --> MySQL、Redis、Dubbo、Http
- core(extension) --> 測試用例能力擴展，執行前，執行后，參數處理等
- gen --> 自動生成代碼
- manager -- > case管理, 報告輸出等等
case模板
- 1.clean db,
- 2.db init(user_info)|= redis init |= Hive, Hbase,
- 3.mock client add
- 4.build request param
- 5.send request(Dubbo|Http,Thrift, RPC), RetMsg. 1000,2000,
- sendRequestForSuccess()
- 6.response assert,(errNo=200,)
- 7.db assert|redis assert.
- AccountDao().of().query(ColumnHolder.of().addColumn(order_id,111))
- ColumnHolder.getColumn("amount");
- Assert.assertEquals(ColumnHolder.getColumn("amount"),100)
- AccountDaoAssert.assertEquals("amount","200")
- 8.log assert(weak)
- 9.db clean
五、分庫分表關注點
- 表的數量：2的冪指數；
- 字段的選擇：
- 一般基於單個字段去分，也有少數情況是基於多個字段；
- 一般基於索引字段；
- 能夠讓請求均分到各張表，如：按 OrderID 划分比較合理，按 MerchID 划分就不太合理，會使一個商戶的所有數據都在同一張表；
- 分庫分表后的查詢：插入和取出邏輯一致；
- 關注性能：不能比分之前差；