数据仓库项目数据类测试流程.doc

.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输出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角色和职责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.5任务描述183.2.3.6测试目标及测试方法193.2.3.6.1PDM、建表语句或导数语句测试目标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业务测试准备243.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角色和职责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、执行集成测试用例、记录测试结果、执行验证测试；汇报测试结果；3、参与测试计划、测试用例等的评审4、协助进行业务测试开发人员1、修正和总结缺陷，执行系统上线；2、进行单元测试；3、必要时作为测试人员执行测试；。配置管理员1、提取测试版本，负责版本维护；业务支持人员1、给测试组提供必要的业务支持；业务测试人员1、进行业务测试相关工作3 过程活动描述3.1 单元测试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.2 集成测试3.2.1 集成测试活动流程图3.2.2 集成测试准备3.2.2.1 集成测试计划和方案准备3.2.2.1.1 目的明确集成测试的范围、测试方法、规则，指导单元测试工作的正确执行。3.2.2.1.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.5 任务描述模型脚本： 测试组根据项目计划，编写测试计划，包括测试相关方的工作安排和测试过程等； 测试组组织模型开发组对测试计划/方案进行评审，并形成评审记录； 测试组成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备； 测试组组织模型开发负责人和相关人员对测试计划/方案进行评审，并形成评审记录； 测试组组织模型开发负责人和相关人员对测试需求和案例进行评审，并形成评审记录。应用脚本： 应用负责人根据项目计划，编写测试计划，包括测试相关方的工作安排和测试过程等； 应用负责人根据项目的特性确定测试方案； 应用测试成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备； 应用负责人组织相关人员对测试计划/方案进行评审，并形成评审记录； 应用负责人组织相关人员对测试需求和案例进行评审，并形成评审记录。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 测试数据和环境准备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 任务描述 应用负责人在测试需求通过评审时，确定测试数据范围，提交测试数据需求，申请测试数据； 测试负责人根据模型开发负责人确定测试数据范围，提交测试数据需求，申请测试数据； 测试组对已搭建的测试环境和准备好的测试数据进行确认； 数据组对测试数据进行数据质量分析（在有现成规则的情况下）。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、建表DDL语句及导数脚本给模型开发人员模型开发负责人监控测试结果确保缺陷得到解决模型开发人员提供可供集成测试脚本、调度配置文档、PDM、建表DDL语句及导数脚本给测试组，修改缺陷测试组编写测试案例，筛选测试数据与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。3.2.3.3 进入条件 按测试计划的安排，项目进行到集成测试阶段。 测试数据已准备好 脚本、调度配置文档、PDM、建表DDL语句及导数脚本的版本可提交测试 单元测试已经通过，满足“集成测试准入检查单”的条件。3.2.3.4 输入 XM_DW_P_XX项目集成测试计划 XM_DW_M_XX项目单元测试报告 XM_DW_T_XX项目映射文档 准备好的测试数据和环境 已准备好进行集成测试的脚本、调度配置文档、PDM、建表DDL语句或导数脚本3.2.3.5 任务描述 测试组编写集成测试用例，编写时要参考之前项目在生产环境发现的问题，以便在以后的应用中进行针对性的测试； 测试组从开发负责人提取要测试的各脚本、调度配置文档PDM、建表DDL语句及导数脚本的版本来进行测试； 测试人员在MQC中记录发现的缺陷，如可确定是谁负责修复的可直接分配缺陷；反之则由开发负责人分配缺陷。缺陷修改后，由开发负责人发布下一个测试版本，测试人员进行回归测试； 在集成测试的里程碑点，测试负责人根据测试记录提交集成测试报告； 最终上线演练的版本由测试组提供。3.2.3.6 测试目标及测试方法3.2.3.6.1 PDM、建表语句或导数语句测试目标 验证建表语句DDL与前一版本PDM的差异； 新旧模型字段的差异性，验证模型字段是否出现删减情况，如果出现该情况需要向设计人员确认； PDM与脚本之间的相互验证，验证相应的脚本在新的PDM上运行是否正确，一般空跑即可； 验证导数语句是否正确，验证目标表与源表的结构、数据是否一致。3.2.3.6.2 脚本测试目标 源表目标表数据量核对测试内容：源系统的记录数与进入仓库的记录数是否一致（剔除根据需求不需要进入仓库的数据）测试方法：Select count(*) from table where ? 机构撤并测试内容：检查机构撤并的相关脚本运行结果是否准确，主要是系统帐号与客户账户的对应关系是否正确。测试方法：根据对照关系表进行数据的验证。 金额相关内容核对测试内容：检查脚本运行后金额相关字段的值是否准确，主要是币种是否关联正确和完整以及金额的数值是否正确。测试方法：根据实际的业务规则对数据进行核对验证。 总分关系延续性测试内容：总分约束关系主要是针对在源系统中存汇总表与明细表之间必须保持一致的关系。具体表现为：汇总表中的总数值要与明细表中该类数据的合计保持一致。在银行的账户类数据中存在着大量这样的情况。对于这列关系的处理也是通过对比数据来实现对脚本的检测。测试方法：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 复杂算法的正确性测试内容：对于复杂的数据处理原则，测试需要对其算法进行验证。这种算法需要从需求出发，提炼算法规则，并将符合此类规则的数据提取出来，运用算法加工这部分数据并将结果与脚本结果进行对比。测试方法：此类检查由于出来比较复杂，所以不需要全量检验，只需按照规则获取符合规则的部分数据进行验证。3.2.3.6.3 调度测试目标 调度是否能正常运行；测试方法：每个应用的CONTROL-M调度都有一个开始作业pre_job,右键点击作业pre_job,在弹出的菜单中选择Free,本应用的调度解除了锁定,调度开始执行，中间不进行其它操作,观察调度能否正常跑完； 任务的命名是否合乎规范，与脚本名是否一致；测试方法：根据仓库规范，调度任务名和原Perl脚本名称要保持一致，否则任务将执行错误，根据出错的任务，可检查出任务的命名是否符合规范； 废弃任务是否被剔除；测试方法：检查调度模板中type类型为delete的任务，查找该任务在CONTROL-M调度是否中还存在，如存在，即调度配置错误； 任务的依赖是否正确、是否覆盖完全；测试方法：分析系统脚本，得出一份脚本的依赖关系列表，再与调度进行核对，每个脚本在调度中都有一个任务名，首选从主脚本开始查找脚本在该调度中的任务名称，在依赖关系列表中进行记录，如果在调度中无法查到，说明该依赖被遗漏。然后再查找该脚本在调度中的依赖是否与关系中的依赖相同，用这种方法逐个脚本的往下核对，可以测试出调度依赖是否正确、覆盖是否完全； 调度运行频率、翻牌是否符合设计；测试方法：在某一业务日期的调度全部执行完毕后，并能正确进行下一业务日期的执行，则表明调度的翻牌符合设计要求。目前CONTROL-M调度按照脚本运行频率分组设计，让调度多翻牌几次，查看运行日志，检查调度的业务日期与脚本的执行日期是否一致，如一致则表明运行频率正确 任务出错时是否影响调度的正常运行；测试方法：CONTROL-M调度在运行时，作业会因库空间不足、SPOOL空间不足、数据质量、脚本问题等原因导致执行失败。针对此类情况，可以用人为干预的方法导致要测试的作业执行失败，例如可以在脚本中设置语法错误、修改测试数据等，用来测试在该任务失败后，后续依赖任务是否可以继续执行，调度是否能够翻牌。调度执行完毕后，检查结果数据是否符合要求：调度正常执行完并翻牌一次后，可用集成测试的案例的执行来检验结果数据是否符合要求。此类检查不要求执行全部的案例，只需选择优先级高或者测试范围大的案例来执行，须尽量保持检验的粗粒度。通过查看日志（日志产生的时间先后，日志内容）来确定调度运行时间、调度依赖是否正确。 调度是否重复配置。测试方法：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项目模型脚本集成测试用例评审记录 XM_DW_M_XX项目模型脚本集成测试报告 缺陷库（MQC）3.2.3.8 退出条件 集成测试中发现的缺陷得到纠正。 过程要求的所有文档完成。3.2.4 集成测试（应用脚本）3.2.4.1 目的对系统接口或脚本进行集成测试，以满足业务测试的准入条件。3.2.4.2 角色和职责角 色 职 责应用负责人监控测试结果确保缺陷得到解决。开发人员提供要测试的代码版本或脚本，修改缺陷测试组筛选测试数据与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。3.2.4.3 进入条件 按测试计划的安排，项目进行到集成测试阶段。 测试数据已准备好 版本可提交测试 单元测试已经通过，满足“集成测试准入检查单”的条件。3.2.4.4 输入 XM_DW_P_XX项目应用脚本集成测试计划 XM_DW_M_XX项目应用脚本单元测试报告 XM_DW_T_XX项目映射文档 准备好的测试数据 已准备好进行集成测试的代码或脚本3.2.4.5 任务描述 测试组编写集成测试用例，编写用例时要参考之前项目在生产环境发现的问题，以便在以后的应用中进行针对性的测试； 测试组根据测试用例在已有测试数据范围内筛选测试数据，与测试用例绑定； 组织设计人员和开发组对测试用例进行评审，并形成评审记录，纳入CC进行管理； 测试人员根据集成测试计划和通过评审的集成测试用例，从CC的集成测试流上提取要测试的版本来进行测试，配置管理员对集成测试流上的版本进行严格控制； 测试人员在MQC中记录发现的缺陷，开发组长对缺陷进行分析，如是缺陷则分配给开发人员进行修改，如需要其他组（设计组等）进行解决，则通过项目组的协同工单进行缺陷的解决，缺陷修改后，由配置管理员发布下一个测试版本，测试人员进行回归测试。 在集成测试的里程碑点，测试组长根据测试记录提交集成测试报告。3.2.4.6 输出 XM_DW_T_XX项目应用脚本集成测试用例 XM_DW_M_XX项目应用脚本集成测试用例评审记录 XM_DW_M_XX项目应用脚本集成测试报告 缺陷库（MQC）3.2.4.7 退出条件 集成测试中发现的缺陷得到纠正。过程要求的所有文档完成。3.3 业务测试（只适用于应用脚本）3.3.1 业务测试活动流程图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_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项目业务测试计划评审通过