註明:DBCheck即資料庫資料校驗;
一．為什麼需要DBCheck?
你同學去年向你借了一萬大洋，今天你打電話想他還錢給你，老同學很大方的給你說馬上給你打到銀行卡上。一會兒，回電話給你說，錢已經全部打到你銀行卡了，讓你等會兒去查詢自己銀行卡的來賬。可是，你左等右等，等到西湖的水都幹了，還是沒有收到銀行的進賬通知......
此時，你該怎麼辦？你是不是很迷茫？
那麼，在我們程式碼世界幾乎很多這種場景。前端傳送一個Request給後端進行相關業務的處理(你打電話給同學讓他還錢)，後端也順利的接收到了請求並給你返回正確的Response(同學回電話說錢已經給你打過去了)，但是，後端實際上卻沒有按照要求給你處理好前端的請求，比如:實際上沒有給你進行資料庫的增刪改查或者對資料庫操作錯誤了。
就像上面的例子一樣，為了查清楚同學的錢是不是打錯了，得讓他去銀行查下打款的對方賬戶是不是你的，或者問下銀行剛才的打款是不是成功的。
這樣，在我們的測試過程中，能夠確定前端請求是否正確:1.如果是操作後臺資料的請求，那麼測試在傳送請求後必須要進行資料庫校驗了，也就是文章提到的DBCheck，只有這樣才能保證請求達到設計的目的；如果是請求新的資源(獲取新的頁面、下載後臺資源等等)，就要求跳轉後的頁面是否是前端想要的結果......
這裡，我們只論述前者，前端可能接收到後端返回成功就認為後端處理是正確的。但是，測試必須要去驗證後端的成功是否是真正的成功，這就要求去驗證資料處理的結果--資料庫了。
你讓同學還錢，你同學給你回覆說已經打你銀行卡上了.......如果，他說打款到你銀行卡就是還錢了，你也認同，那此話題你不用往下看了；如果，你認同只有自己賬戶的餘額增加了且打款方是對方才算對方是還款了，那你也就認同了測試過程DBCheck的重要性了(都是以資料說話)，也請耐心閱讀下面內容。
二.如何進行DBCheck
要進行DBCheck，就必須要知道各個請求幹了啥。就相當於化學實驗，你每新增一步化學試劑就會產生不同的化學反應。在軟體程式設計中也一樣，每個請求都會處理不同的業務，不然這個請求就是無效的了，也就沒有什麼實際意義了。所以，在進行DBCheck之前，你必須要清楚介面請求的功能並熟悉系統的資料庫設計，通過介面知道業務處理後落庫的資料表及對應的各個欄位。介面請求對資料的操作一般包含:增、刪、改、查，當我們熟悉請求的後臺業務後就能只能知道該請求是對資料進行了那種操作，操作了哪些資料表及各個表的資料是如何進行關聯的。只有熟悉了這些，測試者才能真正的知道哪些欄位是關鍵的，哪些欄位是該次請求後必須要驗證的或者說哪些欄位是有意義的。
這裡所說的DBCheck不是指對所有的欄位都要進行驗證，也不是場景A不用驗證場景B也同樣不驗證，所有的測試工作(測試用例)都是根據測試的目的來設計的。例如:某個使用者註冊的介面(需要簡訊驗證)，資料庫要insert使用者註冊是使用者名稱、登入密碼及其他的使用者資料，但資料庫同樣會儲存住戶註冊提交的時間及系統傳送驗證簡訊的時間。我們在進行測試註冊功能的時候，就只需要Check使用者提交的資訊就可以了；但是在測試使用者註冊時驗證簡訊傳送的效能(提交註冊到傳送驗證簡訊的響應時間差)時就必須要驗證兩個時間差是否滿足效能要求了。
總而言之，DBCheck就是在後臺response之後通過查詢資料庫來比較資料庫中的實際值與期望值是否相等

。那麼，DBCheck的步驟就是：
1.準備工作:
a.設計對應的測試用例及準備測試資料，弄清該介面的業務邏輯及確定最後落庫的表和對應的欄位（欄位是否有價值需要根據不能的業務不能的場景及本測試用例的目的來確定，不是唯一的）；
b.根據測試資料準備好需要Check表及欄位的sql語句及期望值；
2.執行階段
a.系統釋出後，執行測試用例，當用例的實際結果和期望結果相同時則該用例通過(此時DBCheck也肯定是通過的)，否則測試用例失敗；
三.自動化測試的DBCheck思路
上面說到，前端Request之後後臺一般對資料庫的操作包含了:增刪改查，我們只需要根據不同的場景準備好測試資料及對應的sql語句來驗證資料庫即可。
可能有同學說，準備sql語句不是應該很簡單的嗎？直接在各個測試用例的後面附上事先準備好的sql即可。但是，現在測試的門檻越來越高，越來越多的公司要求進行自動化測試。本小節就如何簡單、明瞭、方面地準備複用性強的自動化DBCheck。
竟然DBCheck的本質就是要比較資料庫的實際值與期望值是否相同。目的明確了，那現在就分解下內容，1.查詢的條件該怎麼寫(where);2.實際值和期望值該如何比較(也就是常說的Assert)；
先看where部分：
一般在測試過程中，where後的條件比較簡單,常用的就是select from tablename where columnname = ‘value’ 或者就是 select from tablename where columnname in (‘value1’,‘value2’)
再看Assert部分(資料的驗證規則)：
可能在整個DBCheck中難點的地方就在於資料庫的實際值和期望值的Assert方式多種多樣，1.實際值和期望值是否完全相等(也就是常說的equal);2.只要求某一欄位實際有值即可;3.要求比較該欄位值與另外值的差值;4.要求實際值是某些值中的任意一個即可;
上面已經列出了DBCheck的要點，後面需要做的就是封裝一個完整的類來實現上述的所有情況，這樣下次就可反覆的使用了。再者就是將其在控制檯做成視覺化的形式。作者本人是通過csv檔案來進行資料準備的，DBCheck的結果如下圖所示:

四.DBCheck的其他注意點
在實際中，還應該考慮到前端request後後臺處理資料並資料落庫的時間，如果機器效能不好資料落庫慢，此時直接去進行DBCheck肯定會導致DBCheck失敗的，應該考慮進行間隔時間多次DBCheck後失敗才算真正的DBCheck失敗。
五.歡迎關注作者公眾號平臺