前段时间测试了一个数据报表类系统-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_codesum(f.all_qz_cnt)值翻倍了,解决方案是,表voc_issue_***的的业务定位修改,作为issue_code的元数据表

 

这个过程中需要关注的问题

1、数据多样性评估不完整,导致部分数据未被统计

2、表定位错误,比如上面的例子说明的问题

 

三、综述

1、数据是否可以提取极大的依赖于原始数据本身的健壮性,原始数据质量很大程度上决定分析数据的效果

2、对于这类数据产品,测试侧重点主要是:数据完整性、数据准确性、数据有效性、业务合理性