数据类测试方法论Word文件下载.docx

数据类测试方法论Word文件下载.docx

《数据类测试方法论Word文件下载.docx》由会员分享，可在线阅读，更多相关《数据类测试方法论Word文件下载.docx（11页珍藏版）》请在冰豆网上搜索。

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）总分关系是否能保持；

15）主外关系延续性（测试围的表）；

16）复杂算法的正确性。

随着测试工作不断的深入，测试组会对质量组、运维组及其他组发现的问题进行归纳总结，以不断完善测试测试点。

测试案例的设计要根据脚本业务规则的不同，来选择相应的测试点进行案例设计。

4.4.数据准备

4.4.1.申请测试数据

在测试前首先保证有足够的测试数据，与设计确认是否已同步生产数据或从ODS接口组加载测试数据到测试环境，包括加载的测试环境，库名及日期，也可使用以下SQL语句查询。

若在测试过程中发现所需源表不存在或数据为空或源表的业务日期不统一，且该表涉及变更描述容的情况，可联系设计人员或ODS接口组请求重新加载数据。

但实际申请测试数据流程可能较长，一般很难在测试计划得到解决，为了不影响测脚本的正常上线，可先通过建立空表或修改业务日期或手工造数进行解决，待数据重新申请下来再进行验证。

5.测试实施

5.1.规性检查

为了方便仓库统一管理，避免由开发人员的编写习惯等原因带来的潜在问题和风险。

项目组要求所有上线脚本必须通过规性检查。

目前仓库的规性检查，主要通过脚本自动检查+手工检查的方式实现。

5.1.1.自动检查

编写自动检查脚本以便检查开发人员提交测试脚本的规性。

检查的指标由项目组或者是客户制定。

5.1.2.手动检查

由于部分规化的检查暂未实现，为了规化的检查程度达到更广，规检查脚本运行完毕后，根据规性要求进行“手动检查”。

5.2.执行脚本

1）脚本跑通检查；

nohupperl脚本名源表数据日期>

[].log&

2）检查脚本是否能重复执行：

使用同一个业务日期跑两次脚本（第二次执行脚本不对目标表数据产生任何影响）。

3）运行二天以上业务日期的数据

检查目标记录是否被更新；

更新数据时，经过删除和插入的操作后，检查数据记录是否丢失。

5.3.指标检查

白盒检查通过且脚本成功运行后，根据目标表的输出数据情况进行指标检查。

指标检查主要包含：

主键检查，字段空值检查，代码转换结果检查，数据量检查，拉链检查（针对拉链表），PI分布检查。

5.3.1.主键检查

1）目标表数据要求主键不重复，检查PK重复,结果为“0rowsprocessed”时通过。

2）目标表主键要求不包含空格，检查PK是否包含空格,结果为“0”时通过。

5.3.2.字段空值检查

结果为“0”时通过。

5.3.3.代码转换结果检查

检查代码对照表中的代码是否正确转换，无输出结果时通过。

5.3.4.数据量检查

1）检查是否有重复记录，当两条查询结果相同时通过：

2）查询目标表的记录数是否跟源表的一致;

5.3.5.拉链检查（目标表为拉链表）

1）检查开链、断链和交叉链,无输出结果时通过：

2）检查倒链，主要是检查是否存在开始日期小于和等结束日期的记录,无输出结果时通过。

6.缺陷管理

6.1.MQC缺陷库

MercuryQualityCenter的简称,是美科利公司开发的一个基于Web方式的测试管理系统。

可以系统的控制和管理应用程序测试流程的各个阶段，包括测试需求、计划测试、执行测试及跟踪缺陷，从而保证应用系统测试的质量。

采用B/S模式，数据集中在后台的数据库中，便于共享。

打开IE，输入URL：

128.32.96.172:

8080/qcbin/start_a.htm。

进入到登陆页面，输入用户名及密码，通过身份认证后再选择域及项目，其中域选择“开发三部”，项目选择“数据仓库应用支持2008测试项目”。

6.2.缺陷流程图

注意：

只有提出缺陷的测试人员或测试经理才能关闭缺陷。

6.3.缺陷提交规

6.3.1.新建缺陷

通过用例库中的用例去新建缺陷，具体如下：

测试计划->

的缺陷->

新建缺陷

6.3.2.缺陷完善

a、主题：

自动生成，在自动生成脚本名字其前方填写开发人员名字，在其后方填写缺陷主要问题描述；

b、缺陷状态：

指缺陷通过一个跟踪修复过程的进展情况，包括：

提出、处理、拒绝、待验证、重现、关闭；

c、严重程度：

是指因缺陷引起的故障对系统的影响程度。

由提出人初步指定，缺陷修复人员负责确认，包括：

严重、一般、轻微；

d、紧急程度：

指缺陷必须被修复的紧急程度。

由提出人指定，包括：

高、中、低；

e、缺陷起源：

指引起缺陷的起因，包括：

需求、架构、设计、编码、环境、数据、拒绝；

f、缺陷描述

要求提出人描述的缺陷分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂缺陷有据可查（截图或其它形式的附件）；

g、分析和修改容

开发人员修复或拒绝修复缺陷时，需在“缺陷详细信息”模块中的“分析和修改容”中使用“添加注释”按钮详细填写修复的容及拒绝的原因。

其他MQC使用请参考附件：

CC目录\2480\MQC相关资料。

6.3.3.缺陷跟踪

缺陷提交完成后，系统会自动发通知相关缺陷负责人，但由于实际工作影响，缺陷负责人可能会忽略缺陷提醒，故缺陷提出人要对缺陷负责人进行友情提醒，以便及时解决问题，避免影响脚本上线进度。

做到定期查看缺陷状态，进入MQC缺陷管理页面，查看提交的缺陷状态：

对状态为‘待验证’的缺陷及时进行回归验证，如验证通过，关闭缺陷，