淺談軟件測試之數據校驗

註明: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失敗。
五.歡迎關注做者公衆號平臺