数据仓库项目数据类测试流程.docx
《数据仓库项目数据类测试流程.docx》由会员分享,可在线阅读,更多相关《数据仓库项目数据类测试流程.docx(24页珍藏版)》请在冰豆网上搜索。
数据仓库项目数据类测试流程
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进入条件
Ø"*M_DW_P_**工程方案"已完成
Ø"*M_DW_R_**工程需求分析说明书"和"*M_DW_T_**工程数据映射文档"初稿已完成
3.1.2.1.4输入
Ø"*M_DW_P_**工程方案"
Ø"*M_DW_R_**工程需求分析说明书"
Ø"*M_DW_T_**工程数据映射文档"
3.1.2.1.5任务描述
Ø开发组长根据工程方案,编写单元测试方案,包括测试相关方的工作安排和测试过程等;
Ø开发组长组织测试组和开发组对单元测试方案进展评审,并形成评审记录;
3.1.2.1.6输出
Ø"*M_DW_P_**工程单元测试方案"
Ø"*M_DW_M_**工程单元测试方案评审记录"
3.1.2.1.7退出条件
"*M_DW_P_**工程单元测试方案"评审通过
3.1.2.2单元测试数据和环境准备
3.1.2.2.1目的
确定测试环境,并获取测试数据,满足测试需要。
3.1.2.2.2角色和职责
角色
职责
开发组长
确定并申请需要的测试环境和测试数据
系统组
按需求准备测试环境
开发组
对单元测试环境和测试数据进展验证确认
3.1.2.2.3进入条件
"*M_DW_R_**工程需求分析说明书"和"*M_DW_T_**工程数据映射文档"初稿已完成
3.1.2.2.4输入
Ø"*M_DW_R_**工程需求分析说明书"
Ø"*M_DW_T_**工程数据映射文档"
3.1.2.2.5任务描述
Ø应用负责人在需求和映射文档通过评审时,提出测试环境〔包括单元测试、集成测试和用户测试环境〕申请;
Ø开发人员编写单元测试案例,包括所需要的测试数据;
Ø如测试数据需要其他组协助准备,那么提出测试数据申请;
Ø系统组根据申请进展测试环境的搭建,并以形式将配置参数信息通知给开发组和测试组;
Ø开发组对已搭建的测试环境和准备好的测试数据进展确认;
3.1.2.2.6输出
Ø测试环境
Ø"*M_DW_T_**工程单元测试案例"
Ø"*M_DW_M_**工程单元测试案例评审记录"
3.1.2.2.7退出条件
Ø测试环境已准备就绪
Ø"*M_DW_T_**工程单元测试案例"已通过评审
3.1.3单元测试
3.1.3.1目的
Ø对软件各模块进展单元测试,寻找并改正缺陷,保证产品质量。
单元测试一般由开发人员来完成。
测试人员负责测试执行情况的检查和审计,确保单元测试执行,并满足进入Build和集成阶段条件。
根据业务不同,必要时也可以安排测试人员执行单元测试。
3.1.3.2角色和职责
角色
职责
开发组长
制定单元测试方案。
开发人员
编写测试用例,执行测试并记录缺陷,修改错误。
测试人员
检查和审计单元测试执行情况,必要时执行单元测试;
3.1.3.3进入条件
Ø按测试方案的安排,工程进展到单元测试阶段。
Ø程序可进展测试。
3.1.3.4输入
Ø"*M_DW_T_**工程数据映射文档"
Ø"*M_DW_T_**工程单元测试案例"
Ø待测试的脚本或代码
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输出
Ø单元测试结果记录〔在"*M_DW_T_**工程单元测试案例"中记录〕
Ø单元测试脚本
Ø"*M_DW_M_**工程单元测试报告"
Ø"*M_DW_M_**工程单元测试检查记录"
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输入
Ø"*M_DW_P_**工程方案"
Ø"*M_DW_R_**工程需求分析说明书"
Ø"*M_DW_T_**工程数据映射文档"
3.1.5.1.5任务描述
模型脚本:
Ø测试组根据工程方案,编写测试方案,包括测试相关方的工作安排和测试过程等;
Ø测试组组织模型开发组对测试方案/方案进展评审,并形成评审记录;
Ø测试组成员熟悉需求,理解业务规那么,编写测试需求,为测试做好准备;
Ø测试组组织模型开发负责人和相关人员对测试方案/方案进展评审,并形成评审记录;
Ø测试组组织模型开发负责人和相关人员对测试需求和案例进展评审,并形成评审记录。
应用脚本:
Ø应用负责人根据工程方案,编写测试方案,包括测试相关方的工作安排和测试过程等;
Ø应用负责人根据工程的特性确定测试方案;
Ø应用测试成员熟悉需求,理解业务规那么,编写测试需求,为测试做好准备;
Ø应用负责人组织相关人员对测试方案/方案进展评审,并形成评审记录;
Ø应用负责人组织相关人员对测试需求和案例进展评审,并形成评审记录。
3.1.5.1.6输出
Ø"*M_DW_P_**工程模型/应用脚本集成测试方案/方案"
Ø"*M_DW_T_**工程模型/应用脚本集成测试需求"
Ø"*M_DW_T_**工程模型脚本测试案例"〔表达在MQC上〕
Ø"*M_DW_T_**工程应用脚本测试案例"
3.1.5.1.7退出条件
"*M_DW_P_**工程模型/应用脚本集成测试方案/方案"、"*M_DW_T_**工程模型/应用脚本测试需求"、"*M_DW_T_**工程模型/应用脚本集成测试案例"评审通过
3.1.5.2测试数据和环境准备
3.1.5.2.1目的
确定测试环境,并获取测试数据,满足测试需要。
3.1.5.2.2角色和职责
角色
职责
模型开发/应用开发负责人
确定并申请需要的测试环境〔一般在单元测试阶段一起申请〕和测试数据
ODS接口组/系统组
按需求申请和准备测试数据和环境
测试组
对测试环境和测试数据进展验证确认
3.1.5.2.3进入条件
Ø"*M_DW_R_**工程需求分析说明书"和"*M_DW_T_**工程数据映射文档"初稿已完成
3.1.5.2.4输入
Ø"*M_DW_R_**工程需求分析说明书"
Ø"*M_DW_T_**工程数据映射文档"
3.1.5.2.5任务描述
Ø应用负责人在测试需求通过评审时,确定测试数据围,提交"测试数据需求",申请测试数据;
Ø测试负责人根据模型开发负责人确定测试数据围,提交"测试数据需求",申请测试数据;
Ø测试组对已搭建的测试环境和准备好的测试数据进展确认;
Ø数据组对测试数据进展数据质量分析〔在有现成规那么的情况下〕。
3.1.5.2.6输出
Ø测试环境
Ø"*M_DW_T_**工程测试数据需求"
Ø测试数据
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输入
Ø"*M_DW_P_**工程集成测试方案"
Ø"*M_DW_M_**工程单元测试报告"
Ø"*M_DW_T_**工程映射文档"
Ø准备好的测试数据和环境
Ø已准备好进展集成测试的脚本、调度配置文档、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输出
Ø"*M_DW_T_**工程模型脚本集成测试用例"
Ø"*M_DW_M_**工程模型脚本集成测试用例评审记录"
Ø"*M_DW_M_**工程模型脚本集成测试报告"
Ø缺陷库〔MQC〕
3.1.6.8退出条件
Ø集成测试中发现的缺陷得到纠正。
Ø过程要求的所有文档完成。
3.1.7集成测试〔应用脚本〕
3.1.7.1目的
对系统接口或脚本进展集成测试,以满足业务测试的准入条件。
3.1.7.2角色和职责
角色
职责
应用负责人
监控测试结果确保缺陷得到解决。
开发人员
提供要测试的代码版本或脚本,修改缺陷
测试组
筛选测试数据与测试用例绑定,执行测试、记录缺陷,补充、维护测试用例。
3.1.7.3进入条件
Ø按测试方案的安排,工程进展到集成测试阶段。
Ø测试数据已准备好
Ø版本可提交测试
Ø单元测试已经通过,满足“集成测试准入检查单〞的条件。
3.1.7.4输入
Ø"*M_DW_P_**工程应用脚本集成测试方案"
Ø"*M_DW_M_**工程应用脚本单元测试报告"
Ø"*M_DW_T_**工程映射文档"
Ø准备好的测试数据
Ø已准备好进展集成测试的代码或脚本
3.1.7.5任务描述
Ø测试组编写集成测试用例,编写用例时要参考之前工程在生产环境发现的问题,以便在以后的应用中进展针对性的测试;
Ø测试组根据测试用例在已有测试数据围筛选测试数据,与测试用例绑定;
Ø组织设计人员和开发组对测试用例进展评审,并形成评审记录,纳入CC进展管理;
Ø测试人员根据集成测试方案和通过评审的集成测试用例,从CC的集成测试流上提取要测试的版本来进展测试,配置管理员对集成测试流上的版本进展严格控制;
Ø测试人员在MQC中记录发现的缺陷,开发组长对缺陷进展分析,如是缺陷那么分配给开发人员进展修改,如需要其他组〔设计组等〕进展解决