數據報表類系統測試
前段時間測試了一個數據報表類系統-VOC系統
VOC:Voice Of Customer, 根據每天的電話求助量,機器人咨詢量、人工咨詢量、云客服咨詢量等數據出發,關聯到具體問題、產品、部門等信息上分析并展現出會員最大痛點。
VOC 的數據報表的最終展現分為兩個過程
1、獲取源數據并整合數據為最終表
2、數據關聯到問題、產品、部門后進行分析展現
針對這兩個過程,測試方法也分別兩個步驟
一、 獲取源數據并整合數據為最終表-ETL過程
實現方式:云梯、hive腳本、datax
開發跟進業務需求了解原始表結構,編寫hive腳本,“在云端”平臺上運行,獲取最終表,使用dataX工具將數據導入到線上數據庫
平臺:在云端(內部系統)
Datax:離線同步工具
對應的測試方法
1、最終表的正確性
常見的測試方式:測試中間表的正確性、抽樣或全量數據比對、hive腳本review
因為voc對應的最終表的獲取邏輯相對簡單,所以選擇的測試方式是hive腳本review,前提條件是要先了解各個源數據表的含義及結構,對原始數據表非常了解就很容易發現問題,尤其是一些特殊值的處理
舉個例子
create table if not exists r_yunong_rest ( #新建一個中間表 report_date string, prd_code string, question_code string, date_type string, value_type string, base_value string, gmt_create string, gmt_modified string ) partitioned by (pt string) row format delimited fields terminated by '\"' lines terminated by '\n' STORED AS TEXTFILE; insert overwrite table r_yunong_test #表數據插入 PARTITION (pt='$env.lastPartition') select report_date, prd_code, question_code, 'D' as date_type, '01'as value_type count(case when sid is not null then sid when caseid is not null then caseid else null end) as base_value, #特殊字段的處理,驗證重點 '$env.date' as gmt_create, '$env.date' as gmt_modified from r_test #從另一個已創建的中間表r_voc_fact_question獲取數據 where pt='$env.lastPartition' and question_code <>'unknown' group by report_date,prd_code,question_code; |
這個過程中需要關注的問題
1、 數據不完整
2、 數據不準確
3、 某些數據需要特殊處理,比如為null、為0的情況
4、 發現原始表數據質量不理想,需要進行處理
二、數據關聯到問題、產品、部門等進行分析展現—邏輯代碼
平臺實現了將傳入的參數組裝成一條復雜的sql語句,將源數據關聯到產品數據、問題點數、時間數據后的數據結果輸出。
所以驗證的是報表數據的正確性,簡單來說就是驗證一條復雜sql寫的對不對,采用的測試方式是根據業務理解測試整理出對應sql,輸出數據,和系統輸出的數據進行對比
測試要點
1、表結構設計決定業務拓展性 例 測試過程中發現有些元數據表必須是唯一性的
2、對整個數據庫設計非常了解,明確每個表的業務定位
舉個栗子
某業務 測試驗證sql
select f.date_id,d.issue_name,sum(f.all_qz_cnt) from voc_tb_*** f, voc_issue_*** d, bi_time_*** t, voc_prd_*** v where d.issue_code = f.issue_codes and v.id = f.prd_id_sk and t.date_id = f.date_id and v.prd_id=711 and t.day = 20140316 group by f.issue_code order by sum(f.all_qz_cnt) desc |
開發sql
SELECT bi_time_***.day,voc_prd_***.prd_id,voc_issue_***.issue_code,sum(voc_tb_***.all_qz_cnt) as index_135 FROM voc_tb_*** LEFT JOIN voc_issue_*** ON voc_tb_***.issue_code = voc_issue_***.issue_code and voc_issue_***.flow_step=voc_tb_***.dim7 LEFT JOIN voc_prd_*** ON voc_tb_***.prd_id_sk = voc_prd_***.id LEFT JOIN bi_time_*** ON voc_tb_***.date_id = bi_time_***.date_id WHERE voc_prd_***.prd_id=711 and bi_time_***.day=20140316 GROUP BY bi_time_***.day,voc_prd_***.prd_id,voc_issue_***.issue_code ORDER BY index_135 desc |
發現的問題:表voc_issue_***中的issue_code不是唯一值,LEFT JOIN的特性使非唯一issue_code的sum(f.all_qz_cnt)值翻倍了,解決方案是,表voc_issue_***的的業務定位修改,作為issue_code的元數據表
這個過程中需要關注的問題
1、數據多樣性評估不完整,導致部分數據未被統計
2、表定位錯誤,比如上面的例子說明的問題
三、綜述
1、數據是否可以提取極大的依賴于原始數據本身的健壯性,原始數據質量很大程度上決定分析數據的效果
2、對于這類數據產品,測試側重點主要是:數據完整性、數據準確性、數據有效性、業務合理性
posted on 2014-09-02 09:41 順其自然EVO 閱讀(250) 評論(0) 編輯 收藏 所屬分類: 測試學習專欄