大数据的仓库项目的大数据的类测试流程.docx

大数据的仓库项目的大数据的类测试流程.docx

《大数据的仓库项目的大数据的类测试流程.docx》由会员分享，可在线阅读，更多相关《大数据的仓库项目的大数据的类测试流程.docx（27页珍藏版）》请在冰豆网上搜索。

大数据的仓库项目的大数据的类测试流程

1编写目的

为了规范项目的测试工作，给测试组及其与相关组的组间协调提供工作指导。

数据仓库项目组成员可依照本细则开展与测试相关的工作。

2角色与职责

本部分列出了项目组成员日常工作中与测试相关的部分职责：

角色

职责

负责人

1、协调测试资源；

2、负责过程总体控制；

3、确定整体的测试计划和测试方案

测试组

1、准备集成测试用例，落实集成测试资源的准备；

2、执行集成测试用例、记录测试结果、执行验证测试；汇报测试结果；

3、参与《测试计划》、《测试用例》等的评审

4、协助进行业务测试

开发人员

1、修正和总结缺陷，执行系统上线；

2、进行单元测试；

3、必要时作为测试人员执行测试；。

配置管理员

1、提取测试版本，负责版本维护；

业务支持人员

1、给测试组提供必要的业务支持；

业务测试人员

1、进行业务测试相关工作

3过程活动描述

单元测试

3.1.1单元测试活动流程图

3.1.2单元测试准备

3.1.2.1单元测试计划准备

3.1.2.1.1目的

明确单元测试的范围、测试方法、规则，指导单元测试工作的正确执行。

3.1.2.1.2角色和职责

角色

职责

开发组长

确定单元测试的范围、规则、进度和人员安排等，编写单元测试计划

测试组

参与评审单元测试计划

3.1.2.1.3进入条件

Ø《XM_DW_P_XX项目计划》已完成

Ø《XM_DW_R_XX项目需求分析说明书》和《XM_DW_T_XX项目数据映射文档》初稿已完成

3.1.2.1.4输入

Ø《XM_DW_P_XX项目计划》

Ø《XM_DW_R_XX项目需求分析说明书》

Ø《XM_DW_T_XX项目数据映射文档》

3.1.2.1.5任务描述

Ø开发组长根据项目计划，编写单元测试计划，包括测试相关方的工作安排和测试过程等；

Ø开发组长组织测试组和开发组对单元测试计划进行评审，并形成评审记录；

3.1.2.1.6输出

Ø《XM_DW_P_XX项目单元测试计划》

Ø《XM_DW_M_XX项目单元测试计划评审记录》

3.1.2.1.7退出条件

《XM_DW_P_XX项目单元测试计划》评审通过

3.1.2.2单元测试数据和环境准备

3.1.2.2.1目的

确定测试环境，并获取测试数据，满足测试需要。

3.1.2.2.2角色和职责

角色

职责

开发组长

确定并申请需要的测试环境和测试数据

系统组

按需求准备测试环境

开发组

对单元测试环境和测试数据进行验证确认

3.1.2.2.3进入条件

《XM_DW_R_XX项目需求分析说明书》和《XM_DW_T_XX项目数据映射文档》初稿已完成

3.1.2.2.4输入

Ø《XM_DW_R_XX项目需求分析说明书》

Ø《XM_DW_T_XX项目数据映射文档》

3.1.2.2.5任务描述

Ø应用负责人在需求和映射文档通过评审时，提出测试环境（包括单元测试、集成测试和用户测试环境）申请；

Ø开发人员编写单元测试案例，包括所需要的测试数据；

Ø如测试数据需要其他组协助准备，则提出测试数据申请；

Ø系统组根据申请进行测试环境的搭建，并以邮件形式将配置参数信息通知给开发组和测试组；

Ø开发组对已搭建的测试环境和准备好的测试数据进行确认；

3.1.2.2.6输出

Ø测试环境

Ø《XM_DW_T_XX项目单元测试案例》

Ø《XM_DW_M_XX项目单元测试案例评审记录》

3.1.2.2.7退出条件

Ø测试环境已准备就绪

Ø《XM_DW_T_XX项目单元测试案例》已通过评审

3.1.3单元测试

3.1.3.1目的

Ø对软件各模块进行单元测试，寻找并改正缺陷，保证产品质量。

单元测试一般由开发人员来完成。

测试人员负责测试执行情况的检查和审计，确保单元测试执行，并满足进入Build和集成阶段条件。

根据业务不同，必要时也可以安排测试人员执行单元测试。

3.1.3.2角色和职责

角色

职责

开发组长

制定单元测试计划。

开发人员

编写测试用例，执行测试并记录缺陷，修改错误。

测试人员

检查和审计单元测试执行情况，必要时执行单元测试；

3.1.3.3进入条件

Ø按测试计划的安排，项目进行到单元测试阶段。

Ø程序可进行测试。

3.1.3.4输入

Ø《XM_DW_T_XX项目数据映射文档》

Ø《XM_DW_T_XX项目单元测试案例》

Ø待测试的脚本或代码

3.1.3.5任务描述

Ø根据总的测试计划明确和细化单元测试的测试计划；

Ø开发人员根据开发脚本的情况，完善单元测试案例；

Ø开发人员根据单元测试计划和相应的测试用例来测试同伴或自己的代码；

Ø在单元测试案例中记录测试结果，分析测试结果，对Bug进行纠正并记录；

Ø在单元测试结束时编写单元测试报告；

Ø将单元测试时使用的SQL整理成脚本，作为一个配置项，以便以后复用；

Ø测试组对单元测试进行抽样检查，并形成检查记录；

3.1.3.6测试目标及测试方法

3.1.3.6.1模型脚本单元测试目标及测试方法

Ø脚本成功运行检查

测试内容：

脚本能否成功运行，是否有错误

测试方法：

使用单元测试调度脚本（unit_checking.pl下同），脚本调度0200.pl脚本，随后解析生成的日志，将解析的结果（日志中的错误个数）插入单元测试结果表（dwptemp.checking_data_quality下同）。

存在缺陷：

无

Ø脚本重运行检查

测试内容：

判断同一个脚本加载相同的数据重复运行后结果是否一致

测试方法：

单元测试调度程序每次调度都重复调度任务两次，数据质量检查脚本也会运行两次，第一次运行后将目标表的数据进行备份，第二次判断备份表和源表整体数据是否一致，将不一致数据的记录数插入单元测试结果表。

存在缺陷：

无

Ø脚本规范性检查

测试内容：

脚本是否符合项目组脚本规范性要求

测试方法：

使用单元测试调度脚本，脚本调度脚本规范性检查脚本，随后解析生成的日志，将解析的结果（不符合规范性个数）插入单元测试结果表。

存在缺陷：

无

Ø主键重复检查

测试内容：

数据加载完成后目标表中是否存在主键重复的纪录

测试方法：

使用单元测试调度脚本，脚本调度数据质量检查9000.pl脚本（下同），数据质量检查脚本中的主键重复性检查语句查询目标表中主键重复的记录数并将该数值插入单元测试结果表。

存在缺陷：

无

Ø主键中包含空格检查

测试内容：

数据加载完成后目标表的主键键值中是否存在空格

测试方法：

数据质量检查脚本中的主键键值是否包含空格逻辑查询主键键值中包含空格（去除值尾空格）的记录数并将该数值插入单元测试结果表。

存在缺陷：

无

ØPI是否偏

测试内容：

检查目标表数据分布情况

测试方法：

数据质量检查脚本查询Teradata数据字典，计算数据分布偏值，将计算值插入单元测试结果表。

存在缺陷：

生产环境和测试环境的硬件差别导致数据分布情况也不一致，另外外测试的数据量不大的情况下测试也不充分，该结果作为参考。

Ø源表目标表记录数一致性（不充分）

测试内容：

源表和目标表记录数核对

测试方法：

数据质量检查脚本查询源表记录数和目标表记录数，将查询结果插入单元测试结果表。

存在缺陷：

当目标表所对应的源表是一个表的情况下测试比较充分，但源表有多个或者源表的取数规则比较复杂时，DMM映射模版生成的审核语句不准确，需要手工进行脚本修改，建议目前还是有测试组进行测试，待单元测试的其他内容执行顺利后再和测试组沟通将该测试内容完整的纳入单元测试中。

Ø标准代码转换是否正确

测试内容：

对选择进行标准代码转换的字段判断目标表该字段值是否在标准代码表中

测试方法：

数据质量检查脚本查询目标表中进行标准代码转换的字段，取值不在标准代码表中记录个数插入单元测试结果表。

存在缺陷：

无

Ø拉链表拉链逻辑检查

测试内容：

历史拉链表的拉链逻辑是否存在问题，是否有开链、断链问题

测试方法：

数据质量检查脚本根据拉链表逻辑检查拉链表是否存在问题，将查询出存在拉链逻辑错误的记录数插入单元测试结果表。

存在缺陷：

无

Ø字段是否发生截取检查

测试内容：

检查当源表字段定义超过目标表定义情况下的字段值截取情况

测试方法：

DMM映射文档的脚本生成器在生成质量检查脚本时判断源表的字段定义是否超过目标表的字段定义，如果超过则生成审核语句判断数据实际加载中源表该段的最大值是否超过目标表该字段的定义，将超过目标表字段定义的记录数插入单元测试结果表。

存在缺陷：

尚在开发中，由于只能根据实际处理的数据来最终判断是否存在字段截取情况，因此当被截取数据出现在测试加载数据之外的情况将无法发现。

ØDMM映射完整性

测试内容：

判断开发组的开发内容和模型组的设计内容在范围上是否一致，是否存在遗漏。

模型组根据目标表的结构进行模型设计并提交设计文档，模型组设计的每一组映射都应该在开发组进行映射开发，不能存在模型组作了设计而开发组遗漏的情况。

测试方法：

在DMM映射文档的VB宏中增加统计映射个数的逻辑，分别统计模型组设计的映射个数和开发组开发的映射个数，不一致时提示错误。

存在缺陷：

需要模型组根据目标表进行设计，该流程梳理中，VB宏尚未开发。

3.1.3.6.2应用脚本单元测试目标及测试方法

Ø脚本成功运行检查

测试内容：

脚本能否成功运行，是否有错误

测试方法：

手工编写相应测试脚本进行测试。

Ø脚本重运行检查

测试内容：

判断同一个脚本加载相同的数据重复运行后结果是否一致

测试方法：

手工编写相应测试脚本进行测试。

Ø脚本规范性检查

测试内容：

脚本是否符合项目组脚本规范性要求

测试方法：

执行脚本规范性检查脚本，随后分析生成的日志。

Ø主键重复检查

测试内容：

数据加载完成后目标表中是否存在主键重复的纪录

测试方法：

手工编写相应测试脚本进行测试。

Ø主键中包含空格检查

测试内容：

数据加载完成后目标表的主键键值中是否存在空格

测试方法：

手工编写相应测试脚本进行测试。

ØPI是否偏

测试内容：

检查目标表数据分布情况

测试方法：

手工编写相应测试脚本进行测试。

Ø源表目标表记录数一致性

测试内容：

源表和目标表记录数核对

测试方法：

手工编写相应测试脚本进行测试。

Ø标准代码转换是否正确

测试内容：

对选择进行标准代码转换的字段判断目标表该字段值是否在标准代码表中

测试方法：

手工编写相应测试脚本进行测试。

Ø拉链表拉链逻辑检查

测试内容：

历史拉链表的拉链逻辑是否存在问题，是否有开链、断链问题

测试方法：

手工编写相应测试脚本进行测试。

Ø字段是否发生截取检查

测试内容：

检查当源表字段定义超过目标表定义情况下的字段值截取情况

测试方法：

手工编写相应测试脚本进行测试。

3.1.3.7输出

Ø单元测试结果记录（在《XM_DW_T_XX项目单元测试案例》中记录）

Ø单元测试脚本

Ø《XM_DW_M_XX项目单元测试报告》

Ø《XM_DW_M_XX项目单元测试检查记录》

3.1.3.8退出条件

Ø发现的缺陷均得到修正

Ø单元测试抽样检查通过

集成测试

3.1.4集成测试活动流程图

3.1.5集成测试准备

3.1.5.1集成测试计划和方案准备

3.1.5.1.1目的

明确集成测试的范围、测试方法、规则，指导单元测试工作的正确执行。

3.1.5.1.2角色和职责

模型脚本：

角色

职责

模型开发负责人

提供集成测试范围，评审集成测试计划/方案和测试需求

测试组

确定集成测试的范围、规则、进度和人员安排等，编写集成测试计划和方案，提取测试需求

应用脚本：

角色

职责

应用负责人

提供集成测试范围，评审集成测试计划/方案和测试需求

应用测试人员

确定集成测试的范围、规则、进度和人员安排等，编写集成测试计划和方案，提取测试需求

3.1.5.1.3进入条件

Ø项目计划已完成

Ø《需求分析规格》和《映射文档》初稿已完成

3.1.5.1.4输入

Ø《XM_DW_P_XX项目计划》

Ø《XM_DW_R_XX项目需求分析说明书》

Ø《XM_DW_T_XX项目数据映射文档》

3.1.5.1.5任务描述

模型脚本：

Ø测试组根据项目计划，编写测试计划，包括测试相关方的工作安排和测试过程等；

Ø测试组组织模型开发组对测试计划/方案进行评审，并形成评审记录；

Ø测试组成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备；

Ø测试组组织模型开发负责人和相关人员对测试计划/方案进行评审，并形成评审记录；

Ø测试组组织模型开发负责人和相关人员对测试需求和案例进行评审，并形成评审记录。

应用脚本：

Ø应用负责人根据项目计划，编写测试计划，包括测试相关方的工作安排和测试过程等；

Ø应用负责人根据项目的特性确定测试方案；

Ø应用测试成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备；

Ø应用负责人组织相关人员对测试计划/方案进行评审，并形成评审记录；

Ø应用负责人组织相关人员对测试需求和案例进行评审，并形成评审记录。

3.1.5.1.6输出

Ø《XM_DW_P_XX项目模型/应用脚本集成测试计划/方案》

Ø《XM_DW_T_XX项目模型/应用脚本集成测试需求》

Ø《XM_DW_T_XX项目模型脚本测试案例》（体现在MQC上）

Ø《XM_DW_T_XX项目应用脚本测试案例》

3.1.5.1.7退出条件

《XM_DW_P_XX项目模型/应用脚本集成测试计划/方案》、《XM_DW_T_XX项目模型/应用脚本测试需求》、《XM_DW_T_XX项目模型/应用脚本集成测试案例》评审通过

3.1.5.2测试数据和环境准备

3.1.5.2.1目的

确定测试环境，并获取测试数据，满足测试需要。

3.1.5.2.2角色和职责

角色

职责

模型开发/应用开发负责人

确定并申请需要的测试环境（一般在单元测试阶段一起申请）和测试数据

ODS接口组/系统组

按需求申请和准备测试数据和环境

测试组

对测试环境和测试数据进行验证确认

3.1.5.2.3进入条件

Ø《XM_DW_R_XX项目需求分析说明书》和《XM_DW_T_XX项目数据映射文档》初稿已完成

3.1.5.2.4输入

Ø《XM_DW_R_XX项目需求分析说明书》

Ø《XM_DW_T_XX项目数据映射文档》

3.1.5.2.5任务描述

Ø应用负责人在测试需求通过评审时，确定测试数据范围，提交《测试数据需求》，申请测试数据；

Ø测试负责人根据模型开发负责人确定测试数据范围，提交《测试数据需求》，申请测试数据；

Ø测试组对已搭建的测试环境和准备好的测试数据进行确认；

Ø数据组对测试数据进行数据质量分析（在有现成规则的情况下）。

3.1.5.2.6输出

Ø测试环境

Ø《XM_DW_T_XX项目测试数据需求》

Ø测试数据

3.1.5.2.7退出条件

Ø测试环境和测试数据已准备就绪

3.1.6集成测试（模型脚本）

3.1.6.1目的

对系统接口、PDM、调度依赖配置文档、建表和导数语句或脚本进行集成测试，以满足上线演练的需求。

3.1.6.2角色和职责

角色

职责

模型设计组

提供可供集成测试PDM、建表DDL语句及导数脚本给模型开发人员

模型开发负责人

监控测试结果确保缺陷得到解决

模型开发人员

提供可供集成测试脚本、调度配置文档、PDM、建表DDL语句及导数脚本给测试组，修改缺陷

测试组

编写测试案例，筛选测试数据与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。

3.1.6.3进入条件

Ø按测试计划的安排，项目进行到集成测试阶段。

Ø测试数据已准备好

Ø脚本、调度配置文档、PDM、建表DDL语句及导数脚本的版本可提交测试

Ø单元测试已经通过，满足“集成测试准入检查单”的条件。

3.1.6.4输入

Ø《XM_DW_P_XX项目集成测试计划》

Ø《XM_DW_M_XX项目单元测试报告》

Ø《XM_DW_T_XX项目映射文档》

Ø准备好的测试数据和环境

Ø已准备好进行集成测试的脚本、调度配置文档、PDM、建表DDL语句或导数脚本

3.1.6.5任务描述

Ø测试组编写集成测试用例，编写时要参考之前项目在生产环境发现的问题，以便在以后的应用中进行针对性的测试；

Ø测试组从开发负责人提取要测试的各脚本、调度配置文档PDM、建表DDL语句及导数脚本的版本来进行测试；

Ø测试人员在MQC中记录发现的缺陷，如可确定是谁负责修复的可直接分配缺陷；反之则由开发负责人分配缺陷。

缺陷修改后，由开发负责人发布下一个测试版本，测试人员进行回归测试；

Ø在集成测试的里程碑点，测试负责人根据测试记录提交集成测试报告；

Ø最终上线演练的版本由测试组提供。

3.1.6.6测试目标及测试方法

3.1.6.6.1PDM、建表语句或导数语句测试目标

Ø验证建表语句DDL与前一版本PDM的差异；

Ø新旧模型字段的差异性，验证模型字段是否出现删减情况，如果出现该情况需要向设计人员确认；

ØPDM与脚本之间的相互验证，验证相应的脚本在新的PDM上运行是否正确，一般空跑即可；

Ø验证导数语句是否正确，验证目标表与源表的结构、数据是否一致。

3.1.6.6.2脚本测试目标

Ø源表目标表数据量核对

测试内容：

源系统的记录数与进入仓库的记录数是否一致（剔除根据需求不需要进入仓库的数据）

测试方法：

Selectcount（*）fromtablewhere?

Ø机构撤并

测试内容：

检查机构撤并的相关脚本运行结果是否准确，主要是系统帐号与客户账户的对应关系是否正确。

测试方法：

根据对照关系表进行数据的验证。

Ø金额相关内容核对

测试内容：

检查脚本运行后金额相关字段的值是否准确，主要是币种是否关联正确和完整以及金额的数值是否正确。

测试方法：

根据实际的业务规则对数据进行核对验证。

Ø总分关系延续性

测试内容：

总分约束关系主要是针对在源系统中存汇总表与明细表之间必须保持一致的关系。

具体表现为：

汇总表中的总数值要与明细表中该类数据的合计保持一致。

在银行的账户类数据中存在着大量这样的情况。

对于这列关系的处理也是通过对比数据来实现对脚本的检测。

测试方法：

Selectfiled，sum（field）assumfromtable_aA

Leftjoin（selectfield,sum（field）assumfromtable_bgroupbyfield）b

Ona.filed=b.field

wherea.sum<>b.sum

Ø复杂算法的正确性

测试内容：

对于复杂的数据处理原则，测试需要对其算法进行验证。

这种算法需要从需

求出发，提炼算法规则，并将符合此类规则的数据提取出来，运用算法加工这部分数据

并将结果与脚本结果进行对比。

测试方法：

此类检查由于出来比较复杂，所以不需要全量检验，只需按照规则获取符合规则的部分数据进行验证。

3.1.6.6.3调度测试目标

Ø调度是否能正常运行；

测试方法：

每个应用的CONTROL-M调度都有一个开始作业pre_job,右键点击作业pre_job,在弹出的菜单中选择'Free',本应用的调度解除了锁定,调度开始执行，中间不进行其它操作,观察调度能否正常跑完；

Ø任务的命名是否合乎规范，与脚本名是否一致；

测试方法：

根据仓库规范，调度任务名和原Perl脚本名称要保持一致，否则任务将执行错误，根据出错的任务，可检查出任务的命名是否符合规范；

Ø废弃任务是否被剔除；

测试方法：

检查调度模板中type类型为delete的任务，查找该任务在CONTROL-M调度是否中还存在，如存在，即调度配置错误；

Ø任务的依赖是否正确、是否覆盖完全；

测试方法：

分析系统脚本，得出一份脚本的依赖关系列表，再与调度进行核对，每个脚本在调度中都有一个任务名，首选从主脚本开始查找脚本在该调度中的任务名称，在依赖关系列表中进行记录，如果在调度中无法查到，说明该依赖被遗漏。

然后再查找该脚本在调度中的依赖是否与关系中的依赖相同，用这种方法逐个脚本的往下核对，可以测试出调度依赖是否正确、覆盖是否完全；

Ø调度运行频率、翻牌是否符合设计；

测试方法：

在某一业务日期的调度全部执行完毕后，并能正确进行下一业务日期的执行，则表明调度的翻牌符合设计要求。

目前CONTROL-M调度按照脚本运行频率分组设计，让调度多翻牌几次，查看运行日志，检查调度的业务日期与脚本的执行日期是否一致，如一致则表明运行频率正确

Ø任务出错时是否影响调度的正常运行；

测试方法：

CONTROL-M调度在运行时，作业会因库空间不足、SPOOL空间不足、数据质量、脚本问题等原因导致执行失败。

针对此类情况，可以用人为干预的方法导致要测试的作业执行失败，例如可以在脚本中设置语法错误、修改测试数据等，用来测试在该任务失败后，后续依赖任务是否可以继续执行，调度是否能够翻牌。

调度执行完毕后，检查结果数据是否符合要求：

调度正常执行完并翻牌一次后，可用集成测试的案例的执行来检验结果数据是否符合要求。

此类检查不要求执行全部的案例，只需选择优先级高或者测试范围大的案例来执行，须尽量保持检验的粗粒度。

通过查看日志（日志产生的时间先后，日志内容）来确定调度运行时间、调度依赖是否正确。

Ø调度是否重复配置。

测试方法：

CONTROL-M调度的任务写入后台数据库调度表def_job，可以用查找调度表的方法,来检查任务是否重复配置,例如:

select*fromdef_jobwherejob_name='T05_EVENT_DETAIL__DC_A’,查询结果为两条或以上,表明此任务已经重复配置,调度配置错误。

3.1.6.7输出

Ø《XM_DW_T_XX项目模型脚本集成测试用例》

Ø《XM_DW_M_XX项目模型脚本集成测试用例评审记录》

Ø《XM_DW_M_XX项目模型脚本集成测试报告》

Ø缺陷库（MQC）

3.1.6.8退出条件

Ø集成测试中发现的缺陷得到纠正。

Ø过程要求的所有文档完成。

3.1.7集成测试（应用脚本）

3.1.7.1目的

对系统接口或脚本进行集成测试，以满足业务测试的准入条件。

3.1.7.2角色和职责

角色

职责

应用负责人

监控测试结果确保缺陷得到解决。

开发人员

提供要测试的代码版本或脚本，修改缺陷

测试组

筛选测试数据与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。

3.1.7.3进入条件

Ø按测试计划的安排，项目进行到集成测试阶段。

Ø测试数据已准备好

Ø版本可提交测试

Ø单元测试已经通过，满足“集成测试准入检查单”的条件。

3.1.7.4输入

Ø《XM_DW_P_XX项目应用脚本集成测试计划》

Ø《XM_DW_M_XX项目应用脚本单元测试报告》

Ø《XM_DW_T_XX项目映射文档》

Ø准备好的测试数据

Ø已准备好进行集成测试的代码或脚本

3.1.7.5任务描述

Ø测试组编写集成测试用例，编写用例时要参考之前项目在生产环境发现的问题，以便在以后的应用中进行针对性的测试；

Ø测试组根据测试用例在已有测试数据范围内筛选测试数据，与测试用例绑定；

Ø组织设计人员和开发组对测试用例进行评审，并形成评审记录，纳入CC进行管理；

Ø测试人员根据集成测试计划和通过评审的集成测试用例，从CC的集成测试流上提取要测试的版本来进行测试，配置管理员对集