1、1 编写目的 42 角色与职责 43 过程活动描述 53.1 单元测试 53.1.1 单元测试活动流程图 53.1.2 单元测试准备 73.1.2.1 单元测试计划准备 73.1.2.1.1 目的 73.1.2.1.2 角色和职责 73.1.2.1.3 进入条件 73.1.2.1.4 输入 73.1.2.1.5 任务描述 73.1.2.1.6 输出 73.1.2.1.7 退出条件 83.1.2.2 单元测试数据和环境准备 83.1.2.2.1 目的 83.1.2.2.2 角色和职责 83.1.2.2.3 进入条件 83.1.2.2.4 输入 83.1.2.2.5 任务描述 83.1.2.2.6
2、 输出 93.1.2.2.7 退出条件 93.1.3 单元测试 93.1.3.1 目的 93.1.3.2 角色和职责 93.1.3.3 进入条件 93.1.3.4 输入 93.1.3.5 任务描述 103.1.3.6 测试目标及测试方法 103.1.3.6.1 模型脚本单元测试目标及测试方法 103.1.3.6.2 应用脚本单元测试目标及测试方法 123.1.3.7 输出 123.1.3.8 退出条件 133.2 集成测试 143.2.1 集成测试活动流程图 143.2.2 集成测试准备 153.2.2.1 集成测试计划和方案准备 153.2.2.1.1 目的 153.2.2.1.2 角色和职
3、责 153.2.2.1.3 进入条件 153.2.2.1.4 输入 153.2.2.1.5 任务描述 153.2.2.1.6 输出 163.2.2.1.7 退出条件 163.2.2.2 测试数据和环境准备 163.2.2.2.1 目的 163.2.2.2.2 角色和职责 163.2.2.2.3 进入条件 173.2.2.2.4 输入 173.2.2.2.5 任务描述 173.2.2.2.6 输出 173.2.2.2.7 退出条件 173.2.3 集成测试（模型脚本） 173.2.3.1 目的 173.2.3.2 角色和职责 183.2.3.3 进入条件 183.2.3.4 输入 183.2.3
4、.5 任务描述 183.2.3.6 测试目标及测试方法 193.2.3.6.1 PDM、建表语句或导数语句测试目标 .193.2.3.6.2 脚本测试目标 193.2.3.6.3 调度测试目标 203.2.3.7 输出 213.2.3.8 退出条件 213.2.4 集成测试（应用脚本） 213.2.4.1 目的 213.2.4.2 角色和职责 213.2.4.3 进入条件 213.2.4.4 输入 223.2.4.5 任务描述 223.2.4.6 输出 223.2.4.7 退出条件 233.3 业务测试（只适用于应用脚本） 233.3.1 业务测试活动流程图 233.3.2 业务测试准备 24
5、3.3.2.1 业务测试计划 243.3.2.1.1 目的 243.3.2.1.2 角色和职责 243.3.2.1.3 进入条件 243.3.2.1.4 输入 243.3.2.1.5 任务描述 243.3.2.1.6 输出 243.3.2.1.7 退出条件 253.3.2.2 测试数据和环境准备 253.3.2.2.1 目的 253.3.2.2.2 角色和职责 253.3.2.2.3 进入条件 253.3.2.2.4 输入 253.3.2.2.5 任务描述 253.3.2.2.6 输出 253.3.2.2.7 退出条件 263.3.3 业务测试 263.3.3.1 目的 263.3.3.2 角
6、色和职责 263.3.3.3 进入条件 263.3.3.4 输入 263.3.3.5 任务描述 263.3.3.6 输出 273.3.3.7 退出条件 274 变更控制 275 缺陷管理流程 281 编写目的为了规范项目的测试工作，给测试组及其与相关组的组间协调提供工作指导。数据仓库项目组成员可依照本细则开展与测试相关的工作。2 角色与职责本部分列出了项目组成员日常工作中与测试相关的部分职责：角 色 职责负责人 1、协调测试资源；2、负责过程总体控制；3、确定整体的测试计划和测试方案测试组 1、准备集成测试用例，落实集成测试资源的准备；2、执行集成测试用例、记录测试结果、执行验证测试；汇报测试
7、结果；3、参与测试计划 、 测试用例等的评审4、协助进行业务测试开发人员 1、修正和总结缺陷，执行系统上线；2、进行单元测试；3、必要时作为测试人员执行测试；。配置管理员 1、提取测试版本，负责版本维护；业务支持人员 1、给测试组提供必要的业务支持；业务测试人员 1、进行业务测试相关工作3 过程活动描述3.1 单元测试3.1.1 单元测试活动流程图单元测试计划单元测试计划评审通过评审 ？单元测试案例和数据是否单元测试案例和数据评审通过评审 ？是否单元测试环境申请单元测试环境准备单元测试环境验证验证通过 ？否开始结束开发组长 单元测试计划 应用负责人 、 开发组 、 测试组开发人员 单元测试计划
8、评审记录 单元测试案例和数据 设计人员 、 测试组 、开发组 单元测试案例和数据评审记录 开发组长 测试环境申请单 系统组开发组测试环境角色 活动流程 输出 / 提交件单元测试案例执行并记录缺陷是编写单元测试报告整理测试脚本测试组对单元测试结果进行抽样检查开发人员 单元测试案例 中的测试记录测试组 单元测试抽样检查记录 检查通过 ？是否开发组长 单元测试报告 介入时机项目计划通过评审单元测试计划初稿完成单元测试计划通过评审映射初稿完成单元测试案例初稿完成单元测试计划和案例通过评审单元测试报告提交环境申请单提交后测试环境已具备测试环境检查通过测试案例通过评审单元测试发现的缺陷已解决 单元测试脚本
9、 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.
10、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 角色和职责角 色 职 责开发组长 确定并申请需要的测试环境和测试数据系统组 按需求准备测试环境开发组 对单元测试环境和测试数据进
11、行验证确认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 任务描述 应用负责人在需求和映射文档通过评审时，提出测试环境（包括单元测试、集成测试和用户测试环境）申请； 开发人员编写单元测试案例，包括所需要的测试数据； 如测试数据需要其他组协助准备，则提出测试数据申请； 系统组根据申请进行测试环境的搭建，并以邮件形式将配置参数信息通知给开发组和测试组； 开发组对已搭建的测试环境和准备好的测试数据进行确认；
12、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 角色和职责角 色 职 责开发组长 制定单元测试计划。开发人员 编写测试用例，执行测试并记
13、录缺陷，修改错误。测试人员 检查和审计单元测试执行情况，必要时执行单元测试；3.1.3.3 进入条件 按测试计划的安排，项目进行到单元测试阶段。 程序可进行测试。3.1.3.4 输入 XM_DW_T_XX 项目数据映射文档 XM_DW_T_XX 项目单元测试案例 待测试的脚本或代码3.1.3.5 任务描述 根据总的测试计划明确和细化单元测试的测试计划； 开发人员根据开发脚本的情况，完善单元测试案例； 开发人员根据单元测试计划和相应的测试用例来测试同伴或自己的代码； 在单元测试案例中记录测试结果，分析测试结果，对 Bug 进行纠正并记录； 在单元测试结束时编写单元测试报告； 将单元测试时使用的
14、SQL 整理成脚本，作为一个配置项，以便以后复用； 测试组对单元测试进行抽样检查，并形成检查记录；3.1.3.6 测试目标及测试方法3.1.3.6.1 模型脚本单元测试目标及测试方法 脚本成功运行检查测试内容：脚本能否成功运行，是否有错误测试方法：使用单元测试调度脚本（unit_checking.pl 下同） ，脚本调度 0200.pl 脚本，随后解析生成的日志，将解析的结果（日志中的错误个数）插入单元测试结果表（dwptemp. checking_data_quality 下同） 。存在缺陷：无 脚本重运行检查测试内容：判断同一个脚本加载相同的数据重复运行后结果是否一致测试方法：单元测试调度
15、程序每次调度都重复调度任务两次，数据质量检查脚本也会运行两次，第一次运行后将目标表的数据进行备份，第二次判断备份表和源表整体数据是否一致，将不一致数据的记录数插入单元测试结果表。存在缺陷：无 脚本规范性检查测试内容：脚本是否符合项目组脚本规范性要求测试方法：使用单元测试调度脚本，脚本调度脚本规范性检查脚本，随后解析生成的日志，将解析的结果（不符合规范性个数）插入单元测试结果表。存在缺陷：无 主键重复检查测试内容：数据加载完成后目标表中是否存在主键重复的纪录测试方法：使用单元测试调度脚本，脚本调度数据质量检查 9000.pl 脚本（下同） ，数据质量检查脚本中的主键重复性检查语句查询目标表中主键
16、重复的记录数并将该数值插入单元测试结果表。存在缺陷：无 主键中包含空格检查测试内容：数据加载完成后目标表的主键键值中是否存在空格测试方法：数据质量检查脚本中的主键键值是否包含空格逻辑查询主键键值中包含空格（去除值尾空格）的记录数并将该数值插入单元测试结果表。存在缺陷：无 PI 是否偏测试内容：检查目标表数据分布情况测试方法：数据质量检查脚本查询 Teradata 数据字典，计算数据分布偏值，将计算值插入单元测试结果表。存在缺陷：生产环境和测试环境的硬件差别导致数据分布情况也不一致，另外外测试的数据量不大的情况下测试也不充分，该结果作为参考。 源表目标表记录数一致性（不充分）测试内容：源表和目标
17、表记录数核对测试方法：数据质量检查脚本查询源表记录数和目标表记录数，将查询结果插入单元测试结果表。存在缺陷：当目标表所对应的源表是一个表的情况下测试比较充分，但源表有多个或者源表的取数规则比较复杂时，DMM 映射模版生成的审核语句不准确，需要手工进行脚本修改，建议目前还是有测试组进行测试，待单元测试的其他内容执行顺利后再和测试组沟通将该测试内容完整的纳入单元测试中。 标准代码转换是否正确测试内容：对选择进行标准代码转换的字段判断目标表该字段值是否在标准代码表中测试方法：数据质量检查脚本查询目标表中进行标准代码转换的字段，取值不在标准代码表中记录个数插入单元测试结果表。存在缺陷：无 拉链表拉链逻
18、辑检查测试内容：历史拉链表的拉链逻辑是否存在问题，是否有开链、断链问题测试方法：数据质量检查脚本根据拉链表逻辑检查拉链表是否存在问题，将查询出存在拉链逻辑错误的记录数插入单元测试结果表。存在缺陷：无 字段是否发生截取检查测试内容：检查当源表字段定义超过目标表定义情况下的字段值截取情况测试方法：DMM 映射文档的脚本生成器在生成质量检查脚本时判断源表的字段定义是否超过目标表的字段定义，如果超过则生成审核语句判断数据实际加载中源表该段的最大值是否超过目标表该字段的定义，将超过目标表字段定义的记录数插入单元测试结果表。存在缺陷：尚在开发中，由于只能根据实际处理的数据来最终判断是否存在字段截取情况，因
19、此当被截取数据出现在测试加载数据之外的情况将无法发现。 DMM 映射完整性测试内容：判断开发组的开发内容和模型组的设计内容在范围上是否一致，是否存在遗漏。模型组根据目标表的结构进行模型设计并提交设计文档，模型组设计的每一组映射都应该在开发组进行映射开发，不能存在模型组作了设计而开发组遗漏的情况。测试方法： 在 DMM 映射文档的 VB 宏中增加统计映射个数的逻辑，分别统计模型组设计的映射个数和开发组开发的映射个数，不一致时提示错误。存在缺陷：需要模型组根据目标表进行设计，该流程梳理中，VB 宏尚未开发。3.1.3.6.2 应用脚本单元测试目标及测试方法 脚本成功运行检查测试内容：脚本能否成功运
20、行，是否有错误测试方法：手工编写相应测试脚本进行测试。 脚本重运行检查测试内容：判断同一个脚本加载相同的数据重复运行后结果是否一致测试方法：手工编写相应测试脚本进行测试。 脚本规范性检查测试内容：脚本是否符合项目组脚本规范性要求测试方法：执行脚本规范性检查脚本，随后分析生成的日志。 主键重复检查测试内容：数据加载完成后目标表中是否存在主键重复的纪录测试方法：手工编写相应测试脚本进行测试。 主键中包含空格检查测试内容：数据加载完成后目标表的主键键值中是否存在空格测试方法：手工编写相应测试脚本进行测试。 PI 是否偏测试内容：检查目标表数据分布情况测试方法：手工编写相应测试脚本进行测试。 源表目标
21、表记录数一致性测试内容：源表和目标表记录数核对测试方法：手工编写相应测试脚本进行测试。 标准代码转换是否正确测试内容：对选择进行标准代码转换的字段判断目标表该字段值是否在标准代码表中测试方法：手工编写相应测试脚本进行测试。 拉链表拉链逻辑检查测试内容：历史拉链表的拉链逻辑是否存在问题，是否有开链、断链问题测试方法：手工编写相应测试脚本进行测试。 字段是否发生截取检查测试内容：检查当源表字段定义超过目标表定义情况下的字段值截取情况测试方法：手工编写相应测试脚本进行测试。3.1.3.7 输出 单元测试结果记录（在XM_DW_T_XX 项目单元测试案例中记录） 单元测试脚本 XM_DW_M_XX 项
22、目单元测试报告 XM_DW_M_XX 项目单元测试检查记录3.1.3.8 退出条件 发现的缺陷均得到修正 单元测试抽样检查通过3.2 集成测试3.2.1 集成测试活动流程图编写集成测试计划和方案集成测试计划和方案评审通过评审 ？提取测试需求是否测试需求评审通过评审 ？是否编写集成测试案例集成测试案例评审通过评审 ？否开始结束应用负责人 集成测试计划和方案 应用负责人 、 数据组测试组测试组 集成测试计划和方案评审记录 测试需求 设计人员 、 测试组 测试需求评审记录 应用负责人 测试数据需求与脚本清单 设计人员 、 开发组 、测试组 集成测试案例 角色 活动流程 输出 / 提交件筛选测试数据是
23、编写集成测试报告测试组 M Q C 中的缺陷库测试组测试组 集成测试报告 确定测试数据范围提出测试数据申请集成测试案例执行并记录缺陷 集成测试案例评审记录 与测试案例绑定的测试数据介入时机项目计划通过评审映射初稿完成集成测试计划和方案初稿完成映射初稿完成集成测试方案通过评审测试需求初稿完成映射初稿完成映射初稿完成测试需求通过评审集成测试案例初稿完成测试案例通过评审测试数据已具备集成测试案例和数据已绑定集成测试发现的缺陷已解决测试组3.2.2 集成测试准备3.2.2.1 集成测试计划和方案准备3.2.2.1.1 目的明确集成测试的范围、测试方法、规则，指导单元测试工作的正确执行。3.2.2.1.
24、2 角色和职责模型脚本：角 色 职 责模型开发负责人 提供集成测试范围，评审集成测试计划/方案和测试需求测试组 确定集成测试的范围、规则、进度和人员安排等，编写集成测试计划和方案，提取测试需求应用脚本：角 色 职 责应用负责人 提供集成测试范围，评审集成测试计划/方案和测试需求应用测试人员 确定集成测试的范围、规则、进度和人员安排等，编写集成测试计划和方案，提取测试需求3.2.2.1.3进入条件 项目计划已完成 需求分析规格和映射文档初稿已完成3.2.2.1.4 输入 XM_DW_P_XX 项目计划 XM_DW_R_XX 项目需求分析说明书 XM_DW_T_XX 项目数据映射文档3.2.2.1
25、.5 任务描述模型脚本： 测试组根据项目计划，编写测试计划，包括测试相关方的工作安排和测试过程等； 测试组组织模型开发组对测试计划/方案进行评审，并形成评审记录； 测试组成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备； 测试组组织模型开发负责人和相关人员对测试计划/方案进行评审，并形成评审记录； 测试组组织模型开发负责人和相关人员对测试需求和案例进行评审，并形成评审记录。应用脚本： 应用负责人根据项目计划，编写测试计划，包括测试相关方的工作安排和测试过程等； 应用负责人根据项目的特性确定测试方案； 应用测试成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备； 应用负责人组织相关
26、人员对测试计划/方案进行评审，并形成评审记录； 应用负责人组织相关人员对测试需求和案例进行评审，并形成评审记录。3.2.2.1.6 输出 XM_DW_P_XX 项目模型/应用脚本集成测试计划/方案 XM_DW_T_XX 项目模型/应用脚本集成测试需求 XM_DW_T_XX 项目模型脚本测试案例 （体现在 MQC 上） XM_DW_T_XX 项目应用脚本测试案例3.2.2.1.7 退出条件XM_DW_P_XX 项目模型/应用脚本集成测试计划/方案 、 XM_DW_T_XX 项目模型/应用脚本测试需求 、 XM_DW_T_XX 项目模型/应用脚本集成测试案例评审通过3.2.2.2 测试数据和环境准
27、备3.2.2.2.1 目的确定测试环境，并获取测试数据，满足测试需要。3.2.2.2.2 角色和职责角 色 职 责模型开发/应用开发负责人确定并申请需要的测试环境（一般在单元测试阶段一起申请）和测试数据ODS 接口组/系统组 按需求申请和准备测试数据和环境测试组 对测试环境和测试数据进行验证确认3.2.2.2.3 进入条件 XM_DW_R_XX 项目需求分析说明书和XM_DW_T_XX 项目数据映射文档初稿已完成3.2.2.2.4 输入 XM_DW_R_XX 项目需求分析说明书 XM_DW_T_XX 项目数据映射文档3.2.2.2.5 任务描述 应用负责人在测试需求通过评审时，确定测试数据范围
28、，提交测试数据需求 ，申请测试数据； 测试负责人根据模型开发负责人确定测试数据范围，提交测试数据需求 ，申请测试数据； 测试组对已搭建的测试环境和准备好的测试数据进行确认； 数据组对测试数据进行数据质量分析（在有现成规则的情况下） 。3.2.2.2.6 输出 测试环境 XM_DW_T_XX 项目测试数据需求 测试数据3.2.2.2.7 退出条件 测试环境和测试数据已准备就绪3.2.3 集成测试（模型脚本）3.2.3.1 目的对系统接口、PDM、调度依赖配置文档、建表和导数语句或脚本进行集成测试，以满足上线演练的需求。3.2.3.2 角色和职责角 色 职 责模型设计组 提供可供集成测试 PDM、
29、建表 DDL 语句及导数脚本给模型开发人员模型开发负责人 监控测试结果确保缺陷得到解决模型开发人员 提供可供集成测试脚本、调度配置文档、PDM、建表 DDL 语句及导数脚本给测试组，修改缺陷测试组 编写测试案例，筛选测试数据与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。3.2.3.3 进入条件 按测试计划的安排，项目进行到集成测试阶段。 测试数据已准备好 脚本、调度配置文档、PDM、建表 DDL 语句及导数脚本的版本可提交测试 单元测试已经通过，满足“集成测试准入检查单”的条件。3.2.3.4 输入 XM_DW_P_XX 项目集成测试计划 XM_DW_M_XX 项目单元测试报告 XM
30、_DW_T_XX 项目映射文档 准备好的测试数据和环境 已准备好进行集成测试的脚本、调度配置文档、PDM、建表 DDL 语句或导数脚本3.2.3.5 任务描述 测试组编写集成测试用例，编写时要参考之前项目在生产环境发现的问题，以便在以后的应用中进行针对性的测试； 测试组从开发负责人提取要测试的各脚本、调度配置文档 PDM、建表 DDL 语句及导数脚本的版本来进行测试； 测试人员在 MQC 中记录发现的缺陷，如可确定是谁负责修复的可直接分配缺陷；反之则由开发负责人分配缺陷。缺陷修改后，由开发负责人发布下一个测试版本，测试人员进行回归测试； 在集成测试的里程碑点，测试负责人根据测试记录提交集成测试
31、报告； 最终上线演练的版本由测试组提供。3.2.3.6 测试目标及测试 方法3.2.3.6.1 PDM、建表语句或导数语句测试目标 验证建表语句 DDL 与前一版本 PDM 的差异； 新旧模型字段的差异性，验证模型字段是否出现删减情况，如果出现该情况需要向设计人员确认； PDM 与脚本之间的相互验证，验证相应的脚本在新的 PDM 上运行是否正确，一般空跑即可； 验证导数语句是否正确，验证目标表与源表的结构、数据是否一致。3.2.3.6.2 脚本测试目标 源表目标表数据量核对测试内容：源系统的记录数与进入仓库的记录数是否一致（剔除根据需求不需要进入仓库的数据）测试方法：Select count(
32、*) from table where ? 机构撤并测试内容：检查机构撤并的相关脚本运行结果是否准确，主要是系统帐号与客户账户的对应关系是否正确。测试方法：根据对照关系表进行数据的验证。 金额相关内容核对测试内容：检查脚本运行后金额相关字段的值是否准确，主要是币种是否关联正确和完整以及金额的数值是否正确。测试方法：根据实际的业务规则对数据进行核对验证。 总分关系延续性测试内容：总分约束关系主要是针对在源系统中存汇总表与明细表之间必须保持一致的关系。具体表现为：汇总表中的总数值要与明细表中该类数据的合计保持一致。在银行的账户类数据中存在着大量这样的情况。对于这列关系的处理也是通过对比数据来实现对
33、脚本的检测。测试方法：Select filed，sum（field）as sum from table_a A Left join (select field,sum(field) as sum from table_b group by field) b On a. filed =b. fieldwhere a.sum b.sum 复杂算法的正确性测试内容：对于复杂的数据处理原则，测试需要对其算法进行验证。这种算法需要从需求出发，提炼算法规则，并将符合此类规则的数据提取出来，运用算法加工这部分数据并将结果与脚本结果进行对比。测试方法：此类检查由于出来比较复杂，所以不需要全量检验，只需按照规则
34、获取符合规则的部分数据进行验证。3.2.3.6.3 调度测试目标 调度是否能正常运行；测试方法：每个应用的 CONTROL-M 调度都有一个开始作业 pre_job,右键点击作业pre_job,在弹出的菜单中选择Free,本应用的调度解除了锁定,调度开始执行，中间不进行其它操作,观察调度能否正常跑完； 任务的命名是否合乎规范，与脚本名是否一致；测试方法：根据仓库规范，调度任务名和原 Perl 脚本名称要保持一致，否则任务将执行错误，根据出错的任务，可检查出任务的命名是否符合规范； 废弃任务是否被剔除；测试方法：检查调度模板中 type 类型为 delete 的任务，查找该任务在 CONTROL
35、-M调度是否中还存在，如存在，即调度配置错误； 任务的依赖是否正确、是否覆盖完全；测试方法：分析系统脚本，得出一份脚本的依赖关系列表，再与调度进行核对，每个脚本在调度中都有一个任务名，首选从主脚本开始查找脚本在该调度中的任务名称，在依赖关系列表中进行记录，如果在调度中无法查到，说明该依赖被遗漏。然后再查找该脚本在调度中的依赖是否与关系中的依赖相同，用这种方法逐个脚本的往下核对，可以测试出调度依赖是否正确、覆盖是否完全； 调度运行频率、翻牌是否符合设计；测试方法：在某一业务日期的调度全部执行完毕后，并能正确进行下一业务日期的执行，则表明调度的翻牌符合设计要求。目前 CONTROL-M 调度按照脚
36、本运行频率分组设计，让调度多翻牌几次，查看运行日志，检查调度的业务日期与脚本的执行日期是否一致，如一致则表明运行频率正确 任务出错时是否影响调度的正常运行；测试方法：CONTROL-M 调度在运行时，作业会因库空间不足、 SPOOL 空间不足、数据质量、脚本问题等原因导致执行失败。针对此类情况，可以用人为干预的方法导致要测试的作业执行失败，例如可以在脚本中设置语法错误、修改测试数据等，用来测试在该任务失败后，后续依赖任务是否可以继续执行，调度是否能够翻牌。调度执行完毕后，检查结果数据是否符合要求：调度正常执行完并翻牌一次后，可用集成测试的案例的执行来检验结果数据是否符合要求。此类检查不要求执行
37、全部的案例，只需选择优先级高或者测试范围大的案例来执行，须尽量保持检验的粗粒度。通过查看日志（日志产生的时间先后，日志内容）来确定调度运行时间、调度依赖是否正确。 调度是否重复配置。测试方法：CONTROL-M 调度的任务写入后台数据库调度表 def_job，可以用查找调度表的方法,来检查任务是否重复配置,例如: select * from def_job where job_name=T05_EVENT_DETAIL_DC_A,查询结果为两条或以上,表明此任务已经重复配置,调度配置错误。3.2.3.7 输出 XM_DW_T_XX 项目模型脚本集成测试用例 XM_DW_M_XX 项目模型脚本集
38、成测试用例评审记录 XM_DW_M_XX 项目模型脚本集成测试报告 缺陷库（MQC）3.2.3.8 退出条件 集成测试中发现的缺陷得到纠正。 过程要求的所有文档完成。3.2.4 集成测试（应用脚本）3.2.4.1 目的对系统接口或脚本进行集成测试，以满足业务测试的准入条件。3.2.4.2 角色和职责角 色 职 责应用负责人 监控测试结果确保缺陷得到解决。开发人员 提供要测试的代码版本或脚本，修改缺陷测试组 筛选测试数据与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。3.2.4.3 进入条件 按测试计划的安排，项目进行到集成测试阶段。 测试数据已准备好 版本可提交测试 单元测试已经通过，
39、满足“集成测试准入检查单”的条件。3.2.4.4 输入 XM_DW_P_XX 项目应用脚本集成测试计划 XM_DW_M_XX 项目应用脚本单元测试报告 XM_DW_T_XX 项目映射文档 准备好的测试数据 已准备好进行集成测试的代码或脚本3.2.4.5 任务描述 测试组编写集成测试用例，编写用例时要参考之前项目在生产环境发现的问题，以便在以后的应用中进行针对性的测试； 测试组根据测试用例在已有测试数据范围内筛选测试数据，与测试用例绑定； 组织设计人员和开发组对测试用例进行评审，并形成评审记录，纳入 CC 进行管理； 测试人员根据集成测试计划和通过评审的集成测试用例，从 CC 的集成测试流上提取
40、要测试的版本来进行测试，配置管理员对集成测试流上的版本进行严格控制； 测试人员在 MQC 中记录发现的缺陷，开发组长对缺陷进行分析，如是缺陷则分配给开发人员进行修改，如需要其他组（设计组等）进行解决，则通过项目组的协同工单进行缺陷的解决，缺陷修改后，由配置管理员发布下一个测试版本，测试人员进行回归测试。 在集成测试的里程碑点，测试组长根据测试记录提交集成测试报告。3.2.4.6 输出 XM_DW_T_XX 项目应用脚本集成测试用例 XM_DW_M_XX 项目应用脚本集成测试用例评审记录 XM_DW_M_XX 项目应用脚本集成测试报告 缺陷库（MQC）3.2.4.7 退出条件 集成测试中发现的缺
41、陷得到纠正。过程要求的所有文档完成。3.3 业务测试（只适用于应用脚本）3.3.1 业务测试活动流程图编写用户测试计划用户测试计划评审通过评审 ？测试数据申请是否编写业务测试案例执行业务测试案例开始结束应用负责人 用户测试计划 应用负责人 、 业务人员 、 测试组业务人员 用户测试计划评审记录 测试数据申请单 业务人员 、 测试组业务人员业务人员 、 测试组开发组M Q C 缺陷库角色 活动流程 输出 / 提交件解决缺陷编写业务测试报告业务人员 业务测试报告 业务测试案例组内互查 测试用例走查记录 介入时机项目计划通过评审用户测试计划初稿完成业务测试开始前 业务测试用例 业务测试计划通过评审业
42、务测试用例初稿完成业务测试用例已通过走查业务测试人员有提交缺陷业务测试发现的缺陷已解决3.3.2 业务测试准备3.3.2.1 业务测试计划3.3.2.1.1 目的明确业务测试的范围、测试方法、规则，指导业务测试工作的正确执行。3.3.2.1.2 角色和职责角 色 职 责应用负责人 确定业务测试的范围、规则、进度和人员安排等，编写业务测试计划业务人员、测试组参与评审业务测试计划3.3.2.1.3 进入条件 XM_DW_P_XX 项目计划已完成 XM_DW_R_XX 项目需求分析说明书和XM_DW_T_XX 项目映射文档初稿已完成3.3.2.1.4 输入 XM_DW_P_XX 项目计划 XM_DW
43、_R_XX 项目需求分析说明书 XM_DW_T_XX 项目映射文档3.3.2.1.5 任务描述 应用负责人根据项目计划，编写业务测试计划，包括测试相关方的工作安排和测试过程等； 应用负责人组织业务人员和测试组对测试计划进行评审，并形成评审记录；3.3.2.1.6 输出 XM_DW_P_XX 项目业务测试计划 XM_DW_M_XX 项目业务测试计划评审记录3.3.2.1.7 退出条件XM_DW_P_XX 项目业务测试计划评审通过3.3.2.2 测试数据和环境准备3.3.2.2.1 目的确定测试环境，并获取测试数据，满足测试需要。3.3.2.2.2 角色和职责角 色 职 责业务人员 确定并申请需要
44、测试数据，并对业务测试环境和数据进行确认3.3.2.2.3 进入条件 XM_DW_R_XX 项目需求分析说明书和XM_DW_T_XX 项目映射文档初稿已完成3.3.2.2.4 输入 XM_DW_R_XX 项目需求分析说明书 XM_DW_T_XX 项目映射文档3.3.2.2.5 任务描述 业务人员在业务测试开始之前，提出测试数据申请； 业务人员对已搭建的测试环境和准备好的测试数据进行确认；3.3.2.2.6 输出 测试环境 测试数据3.3.2.2.7 退出条件 测试环境和测试数据已准备就绪3.3.3 业务测试3.3.3.1 目的 对最终软件系统进行业务测试，确保最终软件系统满足业务需求。3.3.
45、3.2 角色和职责角 色 职 责测试组、业务人员业务人员执行测试、记录缺陷，补充、维护测试用例，编写业务测试报告，测试人员协助开发人员 定位和修正缺陷3.3.3.3 进入条件 按测试计划的安排，项目进行到业务测试阶段。 集成测试完成。 为系统测试做好了准备，满足业务测试的准入条件。3.3.3.4 输入 XM_DW_P_XX 项目业务测试计划 XM_DW_T_XX 项目集成测试案例 XM_DW_M_XX 项目集成测试报告 待测试的工作产品 测试数据3.3.3.5 任务描述 应用负责人编写业务测试计划并组织业务人员和测试组进行评审，并形成评审记录； 业务测试人员编写业务测试用例； 业务测试组内进行
46、测试用例的组内互查，并形成走查记录，纳入 CC； 业务测试人员根据业务测试计划和测试用例，从 CC 的集成测试流上提取已通过集成测试并形成基线的版本来进行测试，配置管理员对集成测试流上的版本进行严格控制； 测试组对业务测试组进行测试支持，如缺陷管理工具等的使用支持； 业务测试人员在 MQC 中记录发现的缺陷，开发组长对缺陷进行分析，如是缺陷则分配给开发人员进行修改，如需要其他组（设计组等）进行解决，则通过项目组的问题跟踪单进行缺陷的解决，缺陷修改后，由配置管理员发布下一个测试版本，测试人员进行回归测试。 在业务测试的里程碑点，业务测试组长根据测试记录提交业务测试报告。3.3.3.6 输出 XM
47、_DW_T_XX 项目业务测试用例 XM_DW_M_XX 项目业务测试用例走查记录 XM_DW_M_XX 项目业务测试报告 缺陷库（MQC）3.3.3.7 退出条件 业务测试中发现的缺陷得到修正； 过程要求的所有文档完成。4 变更控制 在最后一轮测试之前的测试过程中发生的变更，对所有受影响的测试项必须在下一轮测试中覆盖； 在最后一轮测试中发生的变更，原则上在本轮测试中不予考虑，需作为新的需求提出或者作为后续优化的内容。5 缺陷管理流程提交缺陷 新建是缺陷 ？已否决已关闭打开 / 重新打开可以重现 ？更正缺陷现在修复 ？固定已修复通过验证 ？否是否是否是是否附：缺陷类型划分为：业务需求不明确、数据分析不充分、映射设计问题、脚本问题、测试人员理解偏差、源数据质量问题、仓库历史数据质量问题
