数据类测试方法论

1.引言

1.1编写目的

编写本文档的目的是进一步规范数据仓库的基础层测试工作；用于指导数据数据仓库基础层相关集成测试，主要从测试环境、测试策略、测试具体执行方法、任务计划与安排等为测试工作的展开提供指导和依据；给其他相关组的组间协调提供工作指导。

1.2测试背景

数据仓库随着企业信息化程度的不断提高，各类应用系统同时并存并支撑着企业的业务应用。越来越多企业的信息化主管在开发企业应用时已经考虑到数据集成和将来对数据的整体有效利用，因此，数据仓库被必然的选择来避免信息孤岛，实现应用的内部联系和信息的共享。而现如今由于仓库的需求在仓库发展中不断增加、变化，这要求仓库开发效率加快、准确度提高、实现更加标准化，开发的工程化、自动化趋势也越来越明显，这就要求数据仓库测试在完备的测试条件下，更加迅速、高效的完成测试任务。

1.3预期读者

本文档的预期读者包括：项目管理人员、测试管理人员、参与基础层测试的测试组成员、其他相关项目组人员

2.测试概述

2.1测试目标

DW测试主要围绕ETL进行，即保证ETL和新需求增加的数据质量。其中 ETL 测试保证：

1) 程序的运行正常；

2) 数据的质量：保证准确性和数据的稳定性；

3) ETL的效率：对数据抽取上载时SQL进行部分优化测试等。

目标是保证模型层脚本的跑通性，验证数据是否按照设计需求中既定规则取数，通过内部集成的方式降低数据的出错概率，确保数据的准确性，将输出结果与期望结果控制在既定的置信水平范围内。

2.2测试范围

测试范围是数据仓库项目基础层模型脚本、修数追数脚本及其他建表语句等，其中模型层脚本包括新增脚本及变更脚本。

2.3测试角色与职责

3.测试流程

模型层脚本各组工作大体封版时间：

数据组设计封版时间：脚本上线点前至少15个工作日；

开发组开发封版时间：脚本上线点前至少10个工作日；

测试组测试封版时间：脚本上线点前至少5个工作日；

上线演练完成时间：脚本上线点前至少3个工作日。

注：这里各组封版时间请测试负责人及时关注设计组封版情况并提醒开发组确定落实封版，避免后期测试时间紧迫无法按时完成既定测试任务。

4.测试准备

4.1.准入条件测试

4.1.1.检查受控单

检查开发提交的受控单，一方面是为了规范开发人员的脚本提交流程，另一方面则是为了检查受控库中涉及的脚本是否为本次上线范围内的脚本，若不在本次上线范围内需与相关开发人员确认具体情况。

受控单中需填写内容如下：

1）变更号：与变更跟踪登记簿中的EDW变更号一致，有时候会出现一只脚本涉及多个变更号任务，所以请测试负责人分配脚本时需要将同只脚本分

配给同个测试人员，方便测试实施；

2）里程碑名称/变更编号；

3）开发流路径：脚本测试流存放路径与其一致；

4）程序文件名：与变更跟踪登记簿中脚本名称一致；

5）负责人：相关脚本开发负责人；

6）受控原因：包括设计变更、新增实体、新增映射、MQC缺陷等；

7）变更描述：与变更跟踪登记簿中变更描述一致；

8）测试环境：开发人员单元测试环境；

9）预计上线日期：脚本的上线日期。

4.1.2.检查单元测试结果

针对开发人员提供的项目源码提交受控库申请表中填写的测试环境，在相应的环境下查看脚本是否有进行单元测试，通过SQL语句查询表中数据，检查的内容如下：

1）目标表名，显示内容包括，检查表的表名；

2）主键名，显示内容包括，检查表的主键名

3）检查类型, 显示内容包括，主键重复检查，主键空格检查，检查表的数据空间和分布倾斜因子，检查表的记录分布情况，源表记录数与目标表记录数一致性，代码有效性检查，检查倒链，检查开链和交叉链，检查脚本重跑；

4）各检查内容对应的输出数据，显示内容包括：

a)检查主键重复（主键重复个数）；

b)检查主键空格（主键含空格记录数）

c)检查表的数据空间和分布倾斜因子，检查目标表的倾斜因子是否大于

50（占用空间，峰值空间，倾斜因子）；

d)检查表的记录分布情况（AMP最大记录，AMP最小记录）；

e)源表记录数与目标表中更新的记录数一致性（源表记录，目标记录，

记录数差）；

f)代码有效性检查，检查源字段的取值范围是否在包含在对照表的取值

范围中（代码字段，无效记录）；

g)检查倒链，检查是否存在开始日期大于和等于结束日期的记录（倒链

记录数）；

h)检查开链和交叉链，检查是否存在各时期的时间段总和不等于最大日

期和最小日期差的记录（开链记录数）；

5）检查结果，显示内容包括，正常，异常；

6）检查日期，显示内容包括，脚本运行的日期；

7）系统时间，显示内容包括，脚本运行的时间。

若返回结果非空，首先确认检查日期显示为近期的时间，以保证该单元测试为针对本次上线变更所进行的，再查看各检查结果是否正常；

否则将受控单打回，通知开发人员进行单元测试后重新提交受控单方可进行集成测试。

4.2.脚本准备

4.2.1.脚本提交流程

开发人员完成开发后，将脚本提交配置管理工具受控，并以受控申请单形式通知测试人员。

4.3.编写测试用例

所谓的测试案例就是将软件测试的行为活动，作一个科学化的组织归纳。

简单的说，测试案例就是设计一个情况，软件程序在这种情况下，必须能够正常的运行并且达到程序设计的预期执行结果，所以测试案例的设计要具有目的性，根据数据仓库的特点及数据类测试的特性，总结出以下几个测试点：1）脚本变更内容检查，对照变更跟踪登记簿（必需）；

2）源表字段与目标字段的转换（必需）；

3）源表字段与目标字段的映射（必需）；

4）PK重复检查、全记录重复检查（必需）；

5）PI分布是否均匀（必需）；

6）源表数据与目标表数据的数据比对，查看进行是否正确，是否发生字段截取等（必需）；

7）记录数是否一致（必需）；

8）脚本重复执行性（必需）；

9）删除的数据正确性，发生更新时，对数据的删除是否正确（必需）；

10）拉链表的状态断链、交叉链、开链（必需）；

11）代码的取值种类和代码的范围是否与源系统一致。；

12）特定字段的约束检验，如日期字段是否有进行格式化操作，有拼加前缀字段是否需考虑出现空值情况的处理；

13）表间关系所带来的字段检验；

14）总分关系是否能保持；