註冊 req 地方 數據 from 怎麽辦 完整 tab 大洋

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

淺談軟件測試之數據校驗