数据报表类系统测试
前段时间测试了一个数据报表类系统-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 ' ' 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、对于这类数据产品，测试侧重点主要是：数据完整性、数据准确性、数据有效性、业务合理性
