数据类测试方法论

1、1. 引言1.1 编写目的编写本文档的目的是进一步规范数据仓库的基础层测试工作； 用于指导数据 数据仓库基础层相关集成测试， 主要从测试环境、 测试策略、测试具体执行方法、 任务计划与安排等为测试工作的展开提供指导和依据； 给其他相关组的组间协调 提供工作指导。1.2 测试背景数据仓库随着企业信息化程度的不断提高， 各类应用系统同时并存并支撑着 企业的业务应用。越来越多企业的信息化主管在开发企业应用时已经考虑到数据 集成和将来对数据的整体有效利用， 因此，数据仓库被必然的选择来避免信息孤 岛，实现应用的内部联系和信息的共享。 而现如今由于仓库的需求在仓库发展中 不断增加、变化，这要求仓库开发效

2、率加快、准确度提高、实现更加标准化，开 发的工程化、 自动化趋势也越来越明显， 这就要求数据仓库测试在完备的测试条 件下，更加迅速、高效的完成测试任务。1.3 预期读者本文档的预期读者包括： 项目管理人员、 测试管理人员、 参与基础层测试的 测试组成员、其他相关项目组人员2. 测试概述2.1 测试目标DW测试主要围绕ETL进行，即保证ETL和新需求增加的数据质量。其中ETL 测试保证：1) 程序的运行正常；2) 数据的质量：保证准确性和数据的稳定性；3) ETL的效率：对数据抽取上载时SQL进行部分优化测试等。目标是保证模型层脚本的跑通性， 验证数据是否按照设计需求中既定规则取 数，通过内部集

3、成的方式降低数据的出错概率， 确保数据的准确性，将输出结果 与期望结果控制在既定的置信水平范围内。2.2测试范围测试范围是数据仓库项目基础层模型脚本、修数追数脚本及其他建表语句 等，其中模型层脚本包括新增脚本及变更脚本。2.3测试角色与职责角色职责测试负责人制定每次脚本上线点的测试计划；协调测试资源、跟踪测试进度；申请测试所需数据，并对测试数据进行验证、确认；编写测试阶段性小结和测试报告；维护测试环境和测试数据；上线脚本版本控制。测试人员抽样检查单元测试结果；设计测试案例和测试数据筛选；执行测试用例，提交缺陷报告并跟踪缺陷处理流程。3. 测试流程基基基基基基基基基基基基基基基基基基基基基基基基

4、基基基:基:基 基基基基基基基基基基 基 基 基:基:基基基基基基基基 基 基 基:基:基基基基基基基 基:基:基 :基 :基 基基基基基基基基 基 基 基:基:基基基基基基基基:基:基 :基 :基 基基基基基基基基基基基基基基基基基基基 基 基 基 基:基:基基基基基基基基:基:基 :基 :基 :基基基基基基基基基基基基基基基基基基基基基基基基基模型层脚本各组工作大体封版时间： 数据组设计封版时间：脚本上线点前至少 15 个工作日； 开发组开发封版时间：脚本上线点前至少 10 个工作日； 测试组测试封版时间：脚本上线点前至少 5 个工作日； 上线演练完成时间：脚本上线点前至少 3 个工作日。

5、 注：这里各组封版时间请测试负责人及时关注设计组封版情况并提醒开发组确定 落实封版，避免后期测试时间紧迫无法按时完成既定测试任务。4. 测试准备4.1. 准入条件测试检查受控单 检查开发提交的受控单，一方面是为了规范开发人员的脚本提交流程， 另一方面则是为了检查受控库中涉及的脚本是否为本次上线范围内的脚本， 若不在本次上线范围内需与相关开发人员确认具体情况。受控单中需填写内容如下：1）变更号：与变更跟踪登记簿中的EDW变更号一致，有时候会出现一只脚本 涉及多个变更号任务，所以请测试负责人分配脚本时需要将同只脚本分 配给同个测试人员，方便测试实施；2）里程碑名称 / 变更编号；3）开发流路径：脚

6、本测试流存放路径与其一致；4）程序文件名：与变更跟踪登记簿中脚本名称一致；5）负责人：相关脚本开发负责人；6） 受控原因：包括设计变更、新增实体、新增映射、MQ缺陷等；7）变更描述：与变更跟踪登记簿中变更描述一致；8）测试环境：开发人员单元测试环境 ；9）预计上线日期：脚本的上线日期。检查单元测试结果针对开发人员提供的项目源码提交受控库申请表中填写的测试环境，在相应的环境下查看脚本是否有进行单元测试，通过 SQ语句查询表中数据，检查的内容如下：1）目标表名，显示内容包括，检查表的表名；2）主键名，显示内容包括，检查表的主键名3）检查类型 , 显示内容包括，主键重复检查，主键空格检查，检查表的数

7、据 空间和分布倾斜因子，检查表的记录分布情况，源表记录数与目标表记录 数一致性，代码有效性检查，检查倒链，检查开链和交叉链，检查脚本重 跑；4）各检查内容对应的输出数据，显示内容包括：a）检查主键重复（主键重复个数） ；b）检查主键空格（主键含空格记录数）c）检查表的数据空间和分布倾斜因子， 检查目标表的倾斜因子是否大于50（占用空间，峰值空间，倾斜因子） ；d）检查表的记录分布情况（ AMP 最大记录， AMP 最小记录）；e）源表记录数与目标表中更新的记录数一致性（源表记录，目标记录， 记录数差）；f）代码有效性检查， 检查源字段的取值范围是否在包含在对照表的取值 范围中（代码字段，无效记

8、录） ；g）检查倒链，检查是否存在开始日期大于和等于结束日期的记录（倒链 记录数）；h）检查开链和交叉链， 检查是否存在各时期的时间段总和不等于最大日 期和最小日期差的记录（开链记录数） ；5）检查结果，显示内容包括，正常，异常；6）检查日期，显示内容包括，脚本运行的日期；7）系统时间，显示内容包括，脚本运行的时间。若返回结果非空，首先确认检查日期显示为近期的时间，以保证该单元测试为针对本次上线变更所进行的，再查看各检查结果是否正常；否则将受控单打回，通知开发人员进行单元测试后重新提交受控单方可进行 集成测试。4.2. 脚本准备脚本提交流程 开发人员完成开发后，将脚本提交配置管理工具受控，并以

9、受控申请单 形式通知测试人员。4.3. 编写测试用例所谓的测试案例就是将软件测试的行为活动， 作一个科学化的组织归纳。 简单的说，测试案例就是设计一个情况，软件程序在这种情况下，必须能够 正常的运行并且达到程序设计的预期执行结果 ，所以测试案例的设计要具有 目的性，根据数据仓库的特点及数据类测试的特性， 总结出以下几个测试点：1）脚本变更内容检查，对照变更跟踪登记簿（必需）；2）源表字段与目标字段的转换（必需）；3）源表字段与目标字段的映射（必需）；4）PK重复检查、全记录重复检查（必需）；5）PI 分布是否均匀（必需）；6）源表数据与目标表数据的数据比对， 查看进行是否正确， 是否发生字段截

10、 取等（必需）；7）记录数是否一致（必需）；8）脚本重复执行性（必需）；9）删除的数据正确性，发生更新时，对数据的删除是否正确（必需）；10）拉链表的状态断链、交叉链、开链（必需） ；11）代码的取值种类和代码的范围是否与源系统一致。；12）特定字段的约束检验，如日期字段是否有进行格式化操作，有拼加前缀 字段是否需考虑出现空值情况的处理；13）表 间关系所带来的字段检验；14）总分关系是否能保持；15）主外关系延续性（测试范围内的表）；16）复杂算法的正确性。随着测试工作不断的深入，测试组会对质量组、运维组及其他组发现的 问题进行归纳总结，以不断完善测试测试点。测试案例的设计要根据脚本业务规则

11、的不同，来选择相应的测试点进行案例设计。4.4. 数据准备申请测试数据在测试前首先保证有足够的测试数据，与设计确认是否已同步生产数据或从0D接口组加载测试数据到测试环境，包括加载的测试环境，库名及日期, 也可使用以下SQ语句查询。若在测试过程中发现所需源表不存在或数据为空或源表的业务日期不统一，且该表涉及变更描述内容的情况，可联系设计人员或 0D接口组请求重新加载数据。但实际申请测试数据流程可能较长，一般很难在测试计划内得到 解决，为了不影响测脚本的正常上线，可先通过建立空表或修改业务日期或 手工造数进行解决，待数据重新申请下来再进行验证。5. 测试实施5.1. 规范性检查为了方便仓库统一管理

12、， 避免由开发人员的编写习惯等原因带来的潜在问题 和风险。项目组要求所有上线脚本必须通过规范性检查。 目前仓库的规范性检查， 主要通过脚本自动检查 +手工检查的方式实现。5.1.1. 自动检查编写自动检查脚本以便检查开发人员提交测试脚本的规范性。 检查的指标由项目组或者是客户制定。手动检查由于部分规范化的检查暂未实现，为了规范化的检查程度达到更广，规范检 查脚本运行完毕后，根据规范性要求进行“手动检查”。5.2. 执行脚本1）脚本跑通检查；nohup perl 脚本名 源表数据日期 >.log &2）检查脚本是否能重复执行：使用同一个业务日期跑两次脚本（第二次执行脚 本不对目标表

13、数据产生任何影响）。3）运行二天以上业务日期的数据 检查目标记录是否被更新；更新数据时，经过删除和插入的操作后，检查数 据记录是否丢失。5.3. 指标检查白盒检查通过且脚本成功运行后， 根据目标表的输出数据情况进行指标检查。 指标检查主要包含： 主键检查，字段空值检查，代码转换结果检查， 数据量检查， 拉链检查（针对拉链表）， PI 分布检查。主键检查1）目标表数据要求主键不重复，检查 PK重复,结果为“ 0 rows processed ”时 通过。2）目标表主键要求不包含空格，检查 PK是否包含空格，结果为“0”时通过。5.3.2. 字段空值检查结果为“ 0”时通过。5.3.3. 代码转换

14、结果检查 检查代码对照表中的代码是否正确转换，无输出结果时通过。5.3.4. 数据量检查1 ）检查是否有重复记录，当两条查询结果相同时通过：2）查询目标表的记录数是否跟源表的一致 ;535.拉链检查（目标表为拉链表）1）检查开链、断链和交叉链，无输出结果时通过：2） 检查倒链，主要是检查是否存在开始日期小于和等结束日期的记录，无输出 结果时通过。6. 缺陷管理6.1. MQC缺陷库Mercury Quality Center 的简称,是美科利公司开发的一个基于 Web方式的 测试管理系统。可以系统的控制和管理应用程序测试流程的各个阶段，包括测试需求、计划 测试、执行测试及跟踪缺陷，从而保证应用

15、系统测试的质量。采用B/S模式，数据集中在后台的数据库中，便于共享。打开 IE，输入 URL 。进入到登陆页面，输入用户名及密码，通过身份认证后再选择域及项目，其中域选择“开发三部”，项目选择“数据仓库应用支持2008测试项目62缺陷流程图测试人员开发人员原测试人员注意：只有提出缺陷的测试人员或测试经理才能关闭缺陷6.3. 缺陷提交规范新建缺陷通过用例库中的用例去新建缺陷，具体如下：测试计划-新建缺陷-链接的缺陷丈忡昨Et J!)取工&團*!此妳O后ie，O' id Id 6尸齊换s令a*母旦 l_p KI山31 ,，r 1- 1 < Mlp7/L；l. £ %

16、 IT? B%Ci/lltti.ft/iluli_K Mt632.缺陷完善紧急丹度严帀探反需填写-分配蛉处FP.TS统缺陪皤述测试人员页面咼交人缺附状态系统自幼牛戚-案例編号±JE 崖交0期a、主题：自动生成，在自动生成脚本名字其前方填写开发人员名字，在其后方 填写缺陷主要问题描述；b、缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，包括：提出、处理、 拒绝、待验证、重现、关闭；c、严重程度：是指因缺陷引起的故障对系统的影响程度。由提出人初步指定，缺陷修复人员负责确认，包括：严重、一般、轻微；d、紧急程度：指缺陷必须被修复的紧急程度。由提出人指定，包括：高、中、低；e、缺陷起源：指引

17、起缺陷的起因，包括：需求、架构、设计、编码、环境、数 据、拒绝；f 、缺陷描述要求提出人描述的缺陷分类准确、叙述简洁、步骤清楚、有实例、易再现、 复杂缺陷有据可查（截图或其它形式的附件）；g、分析和修改内容开发人员修复或拒绝修复缺陷时，需在“缺陷详细信息” 模块中的“分析和 修改内容”中使用“添加注释”按钮详细填写修复的内容及拒绝的原因。其他MQ（使用请参考附件：CC目录2480MQC相关资料。缺陷跟踪 缺陷提交完成后，系统会自动发邮件通知相关缺陷负责人，但由于实际工作影响，缺陷负责人可能会忽略缺陷邮件提醒， 故缺陷提出人要对缺陷负责人进行 友情提醒，以便及时解决问题， 避免影响脚本上线进度。

18、 做到定期查看缺陷状态， 进入MQ缺陷管理页面，查看提交的缺陷状态： 对状态为待验证'的缺陷及时进行回归验证， 如验证通过， 关闭缺陷， 否则需 要再重新打开缺陷，并通知缺陷负责人及时修改。对状态为拒绝'或挂起'的缺陷， 需要和缺陷负责人进行确认， 并让缺陷负 责人对缺陷做出注释，给出拒绝或挂起的理由。在脚本封版后，统计出状态为挂起'、拒绝'的缺陷，与脚本版本一起 提交，并让相关开发人员做好后续跟踪。7. 测试后期7.1. 测试版本控制测试版本对比 在脚本完成测试后，MQ上的问题都得到解决情况下，进行上线版本封版，要保持封版的版本是最新的，以免版本产生混乱，故需对版本进行比对。7.1.2. 测试版本输出1）测试版本封版在脚本完成测试后，MQ上的问题都得到解决情况下，进行上线版本封版，封版脚本包括以下几个提交件：a. 经测试的最新上线模型脚本；b. 代码初始化脚本c. 物理模型建表语句及导数脚本；d. 追数 &修数脚本；e. 上线模型脚本清单；f. 上线遗留缺陷清单及相关风险提醒（提醒开发人员、质量组相关人员进 行跟踪）。2）上线演练版本 版本封版完成后，需要在测试环境进行一次模型上线测试，以验证所封版的脚本是否无错、对其它生产脚本有无影响，进而可以检验分析人员的影 响性分析是否遗漏。3）上线版本上线演