正式從PHP開發轉到測試崗位已有1年半，中間的職業發展與所思所考應該有1個階段的總結，總結將在下一篇完成。今天就先通過在工作中實際用到的python腳本+復雜sql記錄一下自己在測試過程中做的數據驗證。

測試中經常會遇到一些數據報表，數據統計的分析，這部分的測試重點在于數據統計的正確性，如何驗證數據的正確性，操作中大概分為以下幾個階段：

初級階段：了解需求，手動準備數據。根據需求手動生成一部分數據，記錄生成數據的控制條件，驗證不同條件下生成的數據是否與數據統計一致。

中級階段：使用大量數據做數據驗證。初級階段的數據量太少，很多隱藏問題往往不容易發現，需要大量數據時，手動準備數據是不現實的，這時候應該向研發人員了解數據生成邏輯，使用python腳本偽造大量數據，最后SQL進行數據統計對比研發測數據統計的正確性。

初級階段，是每個測試人員的必備功課，也是測試人員測試過程中的主要工作，只要需求理解到位，就可以完成。中級階段需要一些python編程基礎及SQL編寫能力。數據統計分析中，各種條件控制下的統計往往需要測試人員有編寫復雜SQL語句的能力。

python腳本生成大量數據，不僅需要了解需求也需要了解具體的表結構，才能為后續SQL編寫查詢做好基礎準備工作。這主要涉及編程能力，由于本人是開發轉測試，所以目前腳本都是在隨用隨學隨寫，基本就是接口調用，數據庫連接，數據的增刪改查工作，后續做數據統計分析也可以結合使用ECharts圖表，但是僅是為了做數據的驗證，再做頁面的圖表展示實在沒有必要，所以一條SQL往往能解決很多問題。

雖然測試的方法千千萬，內卷也是日益嚴重，但是驗收交付中反饋的問題越少，才越能體現出一個測試人員的真實水平，靠譜是第一位的。

編寫SQL中總結一下個人常用到的一些函數及方法，這里以MySQL為例：

• GROUP BY 不對值為NULL的分組

下面是對一個新老客的數據分析，表中uid=null的為新客，后續相同uid記錄數=1的標識為新客，相同uid記錄數>1的標識為老客。如果只是通過GROUP BY uid，就會將所有uid=null的記錄分為一組，這時uid=null的記錄會被標記為老客，與需求不符。

有些博主會使用GROUP BY IFNULL(uid, UUID())，我實際運行了一下發現此種場景下UUID()生成的值相等，依然不符合需求統計，不知道是不是我的用法有誤，有知道的大神可以給與指點。

SELECT Id,uid, CASE WHEN COUNT(Id)=1 THEN 'new' WHEN COUNT(Id)>1 THEN 'old' END `status` FROM table_name WHERE DATE_FORMAT(create_date,'%Y-%m-%d')='2022-04-19' -- 時間格式的控制 GROUP BY IFNULL(uid,Id)) --有些博主使用IFNULL(uid,UUID()))，但在實際應用中我發現這樣使用UUID()生成的值是相同的，依然不能滿足需求判斷

• 根據不同條件對數據進行整合

下面是根據素材類型，統計素材的展示時長。圖片類型默認展示5s，視頻素材根據素材的時長進行數據統計。不同的數據擁有不同的素材類型，需要統計所有數據下素材的展示時長。

select SUM( IF(SUBSTRING_INDEX(dsm.material_mime,'/',1)='image',dap.count*5, (IF(SUBSTRING_INDEX(dsm.material_mime,'/',1)='video',dap.count*dsm.show_time,0)) )) from table_name1 dap inner join table_name2 dsm on dsm.schedule_id = dap.schedule_id where dap.ad_position IN('free1','free2','free3','free4') AND dap.opt_time between '2021-12-01 00:00:00' and '2021-12-01 23:59:59'

總結

以上是生活随笔為你收集整理的测试中的数据统计分析的验证：python脚本+复杂SQL总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。