数据仓库项目数据类测试流程综述

1、1编写目的 32角色与职责 33过程活动描述 43.1 单元测试 43.1.1 单元测试活动流程图 43.1.2 单元测试准备 63.1.2.1 单元测试计划准备 63.1.2.1.1 目的 63.1.2.1.2 角色和职责 63.1.2.1.3 进入条件 63.1.2.1.4 输入 63.1.2.1.5 任务描述 63.1.2.1.6 输出 63.1.2.1.7 退出条件 73.1.2.2 单元测试数据和环境准备 73.1.2.2.1 目的 73.1.2.2.2 角色和职责 73.1.2.2.3 进入条件 73.1.2.2.4 输入 73.1.2.2.5 任务描述 73.1.2.2.6 输出

2、 83.1.2.2.7 退出条件 83.1.3 单元测试 83.1.3.1 目的 83.1.3.2 角色和职责 83.1.3.3 进入条件 83.1.3.4 输入 83.1.3.5 任务描述 93.1.3.6 测试目标及测试方法 93.1.3.6.1 模型脚本单元测试目标及测试方法 93.1.3.6.2 应用脚本单元测试目标及测试方法 113.1.3.7 输出 113.1.3.8 退出条件 123.2 集成测试 133.2.1 集成测试活动流程图 133.2.2 集成测试准备 143.2.2.1 集成测试计划和方案准备 143.2.2.1.1 目的 143.2.2.1.2 角色和职责 143.

3、2.2.1.3 进入条件 143.2.2.1.4 输入 143.2.2.1.5 任务描述 143.2.2.1.6 输出 153.2.2.1.7 退出条件 153.2.2.2 测试数据和环境准备 153.2.2.2.1 目的 153.2.2.2.2 角色和职责 153.2.2.2.3 进入条件 163.2.2.2.4 输入 163.2.2.2.5 任务描述 163.2.2.2.6 输出 163.2.2.2.7 退出条件 163.2.3 集成测试（模型脚本） 163.2.3.1 目的 163.2.3.2 角色和职责 173.2.3.3 进入条件 173.2.3.4 输入 173.2.3.5 任务描

4、述 173.2.3.6 测试目标及测试方法 183.2.3.6.1 PDM 、建表语句或导数语句测试目标 183.2.3.6.2 脚本测试目标 183.2.3.6.3 调度测试目标 193.2.3.7 输出 203.2.3.8 退出条件 203.2.4 集成测试（应用脚本） 203.2.4.1 目的 203.2.4.2 角色和职责 203.2.4.3 进入条件 203.2.4.4 输入 213.2.4.5 任务描述 213.2.4.6 输出 213.2.4.7 退出条件 223.3 业务测试（只适用于应用脚本） 223.3.1 业务测试活动流程图 223.3.2 业务测试准备 233.3.2.

5、1 业务测试计划 233.3.2.1.1 目的 233.3.2.1.2 角色和职责 233.3.2.1.3 进入条件 233.3.2.1.4 输入 233.3.2.1.5 任务描述 233.3.2.1.6 输出 233.3.2.1.7 退出条件 243.3.2.2 测试数据和环境准备 243.3.2.2.1 目的 243.3.2.2.2 角色和职责 243.3.2.2.3 进入条件 243.3.2.2.4 输入 243.3.225任务描述243.3.2.2.6 输出243.3.2.2.7 退出条件253.3.3 业务测试253.3.3.1 目的253.3.3.2 角色和职责253.3.3.3

6、进入条件253.3.3.4 输入253.3.3.5 任务描述253.3.3.6 输出263.3.3.7 退出条件264 变更控制265 缺陷管理流程271编写目的为了规范项目的测试工作，给测试组及其与相关组的组间协调提供工作指导。数据仓库项目组成员可依照本细则开展与测试相关的工作。2角色与职责本部分列出了项目组成员日常工作中与测试相关的部分职责:角色职责负责人1、协调测试资源；2、负责过程总体控制；3、确定整体的测试计划和测试方案测试组1、准备集成测试用例，落实集成测试资源的准备；2、 执行集成测试用例、记录测试结果、执行验证测试；汇报测试结 果；3、参与测试计划、测试用例等的评审4、协助进行

7、业务测试开发人员1、修正和总结缺陷，执行系统上线；2、进行单元测试；3、 必要时作为测试人员执行测试；。配置管理员1、提取测试版本，负责版本维护；业务支持人员1、给测试组提供必要的业务支持；业务测试人员1、进行业务测试相关工作3 过程活动描述3.1 单元测试3.1.1 单元测试活动流程图3.1.2单元测试准备3.121单元测试计划准备31211目的明确单元测试的范围、测试方法、规则，指导单元测试工作的正确执行。31212角色和职责角色职责开发组长确定单元测试的范围、规则、进度和人员安排等，编写单元测试计划测试组参与评审单元测试计划31213进入条件XM_DW_P_X项目计划已完成XM_DW_R

8、_XX目需求分析说明书和 XM_DW_T_X项目数据映射文档初稿已完 成31214输入xm_dw_p_xM目计划XM_DW_R_XX目需求分析说明书XM_DW_T_X项目数据映射文档31215任务描述开发组长根据项目计划， 编写单元测试计划，包括测试相关方的工作安排和测试过程 等；开发组长组织测试组和开发组对单元测试计划进行评审，并形成评审记录；31216输出xm_dw_p_xM目单元测试计划XM_DW_M_XX目单元测试计划评审记录31217退出条件XM_DW_P_X项目单元测试计划评审通过3.122单元测试数据和环境准备31221目的确定测试环境，并获取测试数据，满足测试需要。31222角

9、色和职责角色职责开发组长确定并申请需要的测试环境和测试数据系统组按需求准备测试环境开发组对单元测试环境和测试数据进行验证确认31223进入条件XM_DW_R_XM目需求分析说明书和 XM_DW_T_X项目数据映射文档初稿已完成31224输入XM_DW_R_XX目需求分析说明书XM_DW_T_X项目数据映射文档31225任务描述应用负责人在需求和映射文档通过评审时，提出测试环境（包括单元测试、集成测试和用户测试环境）申请；开发人员编写单元测试案例，包括所需要的测试数据；如测试数据需要其他组协助准备，则提出测试数据申请；系统组根据申请进行测试环境的搭建，并以邮件形式将配置参数信息通知给开发组和测试

10、组；开发组对已搭建的测试环境和准备好的测试数据进行确认；31226输出测试环境XM_DW_T_X项目单元测试案例XM_DW_M_XX目单元测试案例评审记录31227退出条件测试环境已准备就绪XM_DW_T_X项目单元测试案例已通过评审313单元测试3.131 目的对软件各模块进行单元测试，寻找并改正缺陷，保证产品质量。单元测试一般由开 发人员来完成。测试人员负责测试执行情况的检查和审计，确保单元测试执行， 并满足进入Build和集成阶段条件。根据业务不同，必要时也可以安排测试人员执行 单元测试。3.1.3.2 角色和职责角色职责开发组长制定单元测试计划。开发人员编写测试用例，执行测试并记录缺陷

11、，修改错误。测试人员检查和审计单元测试执行情况，必要时执行单元测试；3.1.3.3 进入条件按测试计划的安排，项目进行到单元测试阶段。 程序可进行测试。3.1.3.4 输入XM_DW_T_XX 项目数据映射文档XM_DW_T_XX 项目单元测试案例待测试的脚本或代码3.1.3.5 任务描述根据总的测试计划明确和细化单元测试的测试计划；开发人员根据开发脚本的情况，完善单元测试案例； 开发人员根据单元测试计划和相应的测试用例来测试同伴或自己的代码； 在单元测试案例中记录测试结果，分析测试结果，对 Bug 进行纠正并记录； 在单元测试结束时编写单元测试报告；将单元测试时使用的 SQL 整理成脚本，作

12、为一个配置项，以便以后复用；测试组对单元测试进行抽样检查，并形成检查记录；3.1.3.6 测试目标及测试方法3.1.3.6.1 模型脚本单元测试目标及测试方法脚本成功运行检查测试内容： 脚本能否成功运行，是否有错误测试方法： 使用单元测试调度脚本（ unit_checking.pl 下同），脚本调度 0200.pl 脚本，随 后解析生成的日志， 将解析的结果 （日志中的错误个数） 插入单元测试结果表 （ dwptemp. checking_data_quality 下同）。存在缺陷： 无脚本重运行检查测试内容： 判断同一个脚本加载相同的数据重复运行后结果是否一致测试方法： 单元测试调度程序每次

13、调度都重复调度任务两次，数据质量检查脚本也会运 行两次，第一次运行后将目标表的数据进行备份，第二次判断备份表和源表整体数据是 否一致，将不一致数据的记录数插入单元测试结果表。存在缺陷： 无脚本规范性检查测试内容： 脚本是否符合项目组脚本规范性要求测试方法： 使用单元测试调度脚本，脚本调度脚本规范性检查脚本，随后解析生成的日 志，将解析的结果（不符合规范性个数）插入单元测试结果表。存在缺陷： 无主键重复检查测试内容： 数据加载完成后目标表中是否存在主键重复的纪录测试方法： 使用单元测试调度脚本，脚本调度数据质量检查9000.pl 脚本（下同） ，数据质量检查脚本中的主键重复性检查语句查询目标表中

14、主键重复的记录数并将该数值插 入单元测试结果表。存在缺陷： 无主键中包含空格检查测试内容： 数据加载完成后目标表的主键键值中是否存在空格测试方法： 数据质量检查脚本中的主键键值是否包含空格逻辑查询主键键值中包含空格 （去除值尾空格）的记录数并将该数值插入单元测试结果表。存在缺陷： 无PI 是否偏测试内容： 检查目标表数据分布情况测试方法： 数据质量检查脚本查询 Teradata 数据字典，计算数据分布偏值，将计算值插 入单元测试结果表。存在缺陷： 生产环境和测试环境的硬件差别导致数据分布情况也不一致，另外外测试的 数据量不大的情况下测试也不充分，该结果作为参考。源表目标表记录数一致性（不充分）

15、测试内容： 源表和目标表记录数核对 测试方法： 数据质量检查脚本查询源表记录数和目标表记录数，将查询结果插入单元测 试结果表。存在缺陷： 当目标表所对应的源表是一个表的情况下测试比较充分，但源表有多个或者 源表的取数规则比较复杂时， DMM 映射模版生成的审核语句不准确，需要手工进行脚 本修改，建议目前还是有测试组进行测试，待单元测试的其他内容执行顺利后再和测试 组沟通将该测试内容完整的纳入单元测试中。标准代码转换是否正确测试内容： 对选择进行标准代码转换的字段判断目标表该字段值是否在标准代码表中 测试方法： 数据质量检查脚本查询目标表中进行标准代码转换的字段，取值不在标准代 码表中记录个数插

16、入单元测试结果表。存在缺陷： 无拉链表拉链逻辑检查测试内容： 历史拉链表的拉链逻辑是否存在问题，是否有开链、断链问题 测试方法： 数据质量检查脚本根据拉链表逻辑检查拉链表是否存在问题，将查询出存在 拉链逻辑错误的记录数插入单元测试结果表。存在缺陷： 无字段是否发生截取检查测试内容： 检查当源表字段定义超过目标表定义情况下的字段值截取情况 测试方法： DMM 映射文档的脚本生成器在生成质量检查脚本时判断源表的字段定义是 否超过目标表的字段定义， 如果超过则生成审核语句判断数据实际加载中源表该段的最 大值是否超过目标表该字段的定义， 将超过目标表字段定义的记录数插入单元测试结果 表。存在缺陷： 尚

17、在开发中，由于只能根据实际处理的数据来最终判断是否存在字段截取情 况，因此当被截取数据出现在测试加载数据之外的情况将无法发现。DMM 映射完整性测试内容： 判断开发组的开发内容和模型组的设计内容在范围上是否一致，是否存在遗 漏。模型组根据目标表的结构进行模型设计并提交设计文档，模型组设计的每一组映射 都应该在开发组进行映射开发，不能存在模型组作了设计而开发组遗漏的情况。 测试方法： 在 DMM 映射文档的 VB 宏中增加统计映射个数的逻辑，分别统计模型组 设计的映射个数和开发组开发的映射个数，不一致时提示错误。存在缺陷： 需要模型组根据目标表进行设计，该流程梳理中， VB 宏尚未开发。3.1.

18、3.6.2 应用脚本单元测试目标及测试方法脚本成功运行检查测试内容： 脚本能否成功运行，是否有错误 测试方法： 手工编写相应测试脚本进行测试。脚本重运行检查测试内容： 判断同一个脚本加载相同的数据重复运行后结果是否一致 测试方法： 手工编写相应测试脚本进行测试。脚本规范性检查测试内容： 脚本是否符合项目组脚本规范性要求 测试方法： 执行脚本规范性检查脚本，随后分析生成的日志。主键重复检查测试内容： 数据加载完成后目标表中是否存在主键重复的纪录 测试方法： 手工编写相应测试脚本进行测试。主键中包含空格检查测试内容： 数据加载完成后目标表的主键键值中是否存在空格 测试方法： 手工编写相应测试脚本进

19、行测试。PI 是否偏测试内容： 检查目标表数据分布情况 测试方法： 手工编写相应测试脚本进行测试。源表目标表记录数一致性测试内容： 源表和目标表记录数核对 测试方法： 手工编写相应测试脚本进行测试。标准代码转换是否正确测试内容： 对选择进行标准代码转换的字段判断目标表该字段值是否在标准代码表中 测试方法： 手工编写相应测试脚本进行测试。拉链表拉链逻辑检查测试内容： 历史拉链表的拉链逻辑是否存在问题，是否有开链、断链问题 测试方法： 手工编写相应测试脚本进行测试。字段是否发生截取检查测试内容： 检查当源表字段定义超过目标表定义情况下的字段值截取情况 测试方法： 手工编写相应测试脚本进行测试。3.

20、1.3.7 输出单元测试结果记录（在XM_DW_T_X项目单元测试案例中记录） 单元测试脚本XM_DW_M_XX目单元测试报告XM_DW_M_XX目单元测试检查记录3.1.3.8 退出条件发现的缺陷均得到修正单元测试抽样检查通过3.2集成测试3.2.1集成测试活动流程图3.2.2集成测试准备322.1 集成测试计划和方案准备32211目的明确集成测试的范围、测试方法、规则，指导单元测试工作的正确执行。32212角色和职责模型脚本:角色职责模型开发负责人提供集成测试范围，评审集成测试计划/方案和测试需求测试组确定集成测试的范围、规则、进度和人员安排等，编写集成测试计划 和方案，提取测试需求应用脚

21、本:角色职责应用负责人提供集成测试范围，评审集成测试计划/方案和测试需求应用测试人员确定集成测试的范围、规则、进度和人员安排等，编写集成测试计划 和方案，提取测试需求32213进入条件项目计划已完成需求分析规格和映射文档初稿已完成32214输入XM_DW_P_X项目计划XM_DW_R_XX目需求分析说明书XM_DW_T_X项目数据映射文档32215任务描述模型脚本：测试组根据项目计划，编写测试计划，包括测试相关方的工作安排和测试过程等;测试组组织模型开发组对测试计划/方案进行评审，并形成评审记录；测试组成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备;测试组组织模型开发负责人和相关人员

22、对测试计划/方案进行评审，并形成评审记录;测试组组织模型开发负责人和相关人员对测试需求和案例进行评审，并形成评审记 录。应用脚本：应用负责人根据项目计划， 编写测试计划，包括测试相关方的工作安排和测试过程等; 应用负责人根据项目的特性确定测试方案；应用测试成员熟悉需求，理解业务规则，编写测试需求，为测试做好准备；应用负责人组织相关人员对测试计划 /方案进行评审，并形成评审记录； 应用负责人组织相关人员对测试需求和案例进行评审，并形成评审记录。32216输出XM_DW_P_X项目模型/应用脚本集成测试计划/方案XM_DW_T_X项目模型/应用脚本集成测试需求XM_DW_T_X项目模型脚本测试案例

23、（体现在MQC 上）XM_DW_T_X项目应用脚本测试案例32217退出条件XM_DW_P_X项目模型/应用脚本集成测试计划/方案、XM_DW_T_X项目模型/应用脚本 测试需求、XM DW T X项目模型/应用脚本集成测试案例评审通过322.2测试数据和环境准备32221目的确定测试环境，并获取测试数据，满足测试需要。32222角色和职责角色职责模型开发/应用开发 负责人确定并申请需要的测试环境（一般在单元测试阶段一起申请）和测试数据ODS接口组/系统组按需求申请和准备测试数据和环境测试组对测试环境和测试数据进行验证确认3.2.2.2.3 进入条件XM_DW_R_XX目需求分析说明书和 XM

24、_DW_T_X项目数据映射文档初稿已完 成3.2.2.2.4 输入XM_DW_R_XX目需求分析说明书XM_DW_T_X项目数据映射文档3.2.2.2.5 任务描述应用负责人在测试需求通过评审时，确定测试数据范围，提交测试数据需求，申请测试数据； 测试负责人根据模型开发负责人确定测试数据范围，提交测试数据需求，申请测试数据；测试组对已搭建的测试环境和准备好的测试数据进行确认； 数据组对测试数据进行数据质量分析（在有现成规则的情况下） 。3.2.2.2.6 输出测试环境XM_DW_T_X项目测试数据需求测试数据3.2.2.2.7 退出条件测试环境和测试数据已准备就绪3.2.3 集成测试（模型脚本

25、）3.2.3.1 目的对系统接口、 PDM 、调度依赖配置文档、建表和导数语句或脚本进行集成测试，以满 足上线演练的需求。323.2角色和职责角色职责模型设计组提供可供集成测试 PDM建表DDL语句及导数脚本给模型开发人员模型开发负责人监控测试结果确保缺陷得到解决模型开发人员提供可供集成测试脚本、调度配置文档、PDM建表DDL语句及导数脚本给测试组，修改缺陷测试组编写测试案例，筛选测试数据与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。323.3进入条件按测试计划的安排，项目进行到集成测试阶段。测试数据已准备好脚本、调度配置文档、 PDM、建表DDL语句及导数脚本的版本可提交测试 单元

26、测试已经通过，满足“集成测试准入检查单”的条件。323.4 输入XM_DW_P_X项目集成测试计划XM_DW_M_XX目单元测试报告XM_DW_T_X项目映射文档PDM、建表DDL语句或导数脚本准备好的测试数据和环境已准备好进行集成测试的脚本、调度配置文档、323.5 任务描述测试组编写集成测试用例， 编写时要参考之前项目在生产环境发现的问题，以便在 以后的应用中进行针对性的测试;测试组从开发负责人提取要测试的各脚本、调度配置文档PDM、建表DDL语句及 导数脚本的版本来进行测试;测试人员在MQC中记录发现的缺陷，如可确定是谁负责修复的可直接分配缺陷; 反之则由开发负责人分配缺陷。缺陷修改后，

27、由开发负责人发布下一个测试版本， 测试人员进行回归测试；在集成测试的里程碑点，测试负责人根据测试记录提交集成测试报告; 最终上线演练的版本由测试组提供。3.2.3.6 测试目标及测试方法3.2.3.6.1 PDM 、建表语句或导数语句测试目标验证建表语句 DDL 与前一版本 PDM 的差异；新旧模型字段的差异性， 验证模型字段是否出现删减情况， 如果出现该情况需要向 设计人员确认；PDM 与脚本之间的相互验证，验证相应的脚本在新的 PDM 上运行是否正确，一 般空跑即可；验证导数语句是否正确，验证目标表与源表的结构、数据是否一致。3.2.3.6.2 脚本测试目标源表目标表数据量核对测试内容：

28、源系统的记录数与进入仓库的记录数是否一致 (剔除根据需求不需要进入仓 库的数据)测试方法： Select count(*) from table where ?机构撤并测试内容： 检查机构撤并的相关脚本运行结果是否准确， 主要是系统帐号与客户账户的 对应关系是否正确。测试方法：根据对照关系表进行数据的验证。金额相关内容核对测试内容： 检查脚本运行后金额相关字段的值是否准确， 主要是币种是否关联正确和完 整以及金额的数值是否正确。测试方法：根据实际的业务规则对数据进行核对验证。总分关系延续性 测试内容：总分约束关系主要是针对在源系统中存汇总表与明细表之间必须保持一致的 关系。 具体表现为： 汇总

29、表中的总数值要与明细表中该类数据的合计保持一致。在银行的账户类数据中存在着大量这样的情况。 对于这列关系的处理也是通过对比数据来实现对脚本的 检测。测试方法：Select filed ， sum( field ) as sum from table_a ALeft join (select field,sum(field) as sum from table_b group by field) bOn a. filed =b. fieldwhere a.sum b.sum复杂算法的正确性测试内容： 对于复杂的数据处理原则， 测试需要对其算法进行验证。 这种算法需要从需 求出发， 提炼算法规则，

30、 并将符合此类规则的数据提取出来， 运用算法加工这部分数据 并将结果与脚本结果进行对比。测试方法： 此类检查由于出来比较复杂， 所以不需要全量检验， 只需按照规则获取符合 规则的部分数据进行验证。3.2.3.6.3 调度测试目标调度是否能正常运行；测试方法：每个应用的CONTROL-M调度都有一个开始作业preob,右键点击作业pre_job, 在弹出的菜单中选择 Free, 本应用的调度解除了锁定 , 调度开始执行， 中间不 进行其它操作 , 观察调度能否正常跑完；任务的命名是否合乎规范，与脚本名是否一致；测试方法 ：根据仓库规范，调度任务名和原 Perl 脚本名称要保持一致，否则任务将执

31、行错误，根据出错的任务，可检查出任务的命名是否符合规范；废弃任务是否被剔除；测试方法：检查调度模板中type类型为delete的任务，查找该任务在 CONTROL-M 调度是否中还存在，如存在，即调度配置错误；任务的依赖是否正确、是否覆盖完全；测试方法： 分析系统脚本，得出一份脚本的依赖关系列表， 再与调度进行核对， 每个脚 本在调度中都有一个任务名， 首选从主脚本开始查找脚本在该调度中的任务名称， 在依 赖关系列表中进行记录， 如果在调度中无法查到， 说明该依赖被遗漏。 然后再查找该脚 本在调度中的依赖是否与关系中的依赖相同， 用这种方法逐个脚本的往下核对， 可以测 试出调度依赖是否正确、覆

32、盖是否完全；调度运行频率、翻牌是否符合设计；测试方法： 在某一业务日期的调度全部执行完毕后， 并能正确进行下一业务日期的执行， 则表明调度的翻牌符合设计要求。 目前 CONTROL-M 调度按照脚本运行频率分组设计， 让调度多翻牌几次，查看运行日志，检查调度的业务日期与脚本的执行日期是否一致， 如一致则表明运行频率正确任务出错时是否影响调度的正常运行；测试方法： CONTROL-M 调度在运行时，作业会因库空间不足、 SPOOL 空间不足、数 据质量、 脚本问题等原因导致执行失败。 针对此类情况， 可以用人为干预的方法导致要 测试的作业执行失败， 例如可以在脚本中设置语法错误、 修改测试数据等

33、， 用来测试在 该任务失败后，后续依赖任务是否可以继续执行，调度是否能够翻牌。 调度执行完毕后，检查结果数据是否符合要求：调度正常执行完并翻牌一次后， 可用集成测试的案例的执行来检验结果数据是否符合要 求。此类检查不要求执行全部的案例， 只需选择优先级高或者测试范围大的案例来执行， 须尽量保持检验的粗粒度。通过查看日志（日志产生的时间先后，日志内容） 来确定调度运行时间、调度依赖是否正确。调度是否重复配置。测试方法：CONTROL-M调度的任务写入后台数据库调度表def_job，可以用查找调度表的 方法,来检查任务是否重复配置,例如：select * from def_job where jo

34、b_name=T05_EVENT_DETAIL_DC_A ，查询结果为两条或以上，表明此任务已经重复 配置，调度配置错误。323.7 输出XM_DW_T_X项目模型脚本集成测试用例XM_DW_M_XX目模型脚本集成测试用例评审记录XM_DW_M_XX目模型脚本集成测试报告缺陷库（MQC）323.8 退出条件集成测试中发现的缺陷得到纠正。过程要求的所有文档完成。3.2.4集成测试（应用脚本）3.241 目的对系统接口或脚本进行集成测试，以满足业务测试的准入条件。3.2.4.2 角色和职责角色职责应用负责人监控测试结果确保缺陷得到解决。开发人员提供要测试的代码版本或脚本，修改缺陷测试组筛选测试数据

35、与测试用例绑定，执行测试、记录缺陷，补充、维护测试用例。3.2.4.3 进入条件按测试计划的安排，项目进行到集成测试阶段。 测试数据已准备好 版本可提交测试 单元测试已经通过，满足“集成测试准入检查单”的条件。3.2.4.4 输入XM_DW_P_X项目应用脚本集成测试计划XM_DW_M_XX目应用脚本单元测试报告XM_DW_T_X项目映射文档准备好的测试数据 已准备好进行集成测试的代码或脚本3.2.4.5 任务描述测试组编写集成测试用例， 编写用例时要参考之前项目在生产环境发现的问题， 以 便在以后的应用中进行针对性的测试； 测试组根据测试用例在已有测试数据范围内筛选测试数据，与测试用例绑定；

36、 组织设计人员和开发组对测试用例进行评审， 并形成评审记录， 纳入 CC 进行管理； 测试人员根据集成测试计划和通过评审的集成测试用例， 从 CC 的集成测试流上提 取要测试的版本来进行测试，配置管理员对集成测试流上的版本进行严格控制； 测试人员在 MQC 中记录发现的缺陷，开发组长对缺陷进行分析， 如是缺陷则分配 给开发人员进行修改，如需要其他组（设计组等）进行解决，则通过项目组的协 同工单进行缺陷的解决，缺陷修改后， 由配置管理员发布下一个测试版本，测试 人员进行回归测试。 在集成测试的里程碑点，测试组长根据测试记录提交集成测试报告。3.2.4.6 输出XM_DW_T_X项目应用脚本集成测

37、试用例XM_DW_M_XX目应用脚本集成测试用例评审记录XM_DW_M_XX目应用脚本集成测试报告缺陷库（ MQC ）3.247退出条件集成测试中发现的缺陷得到纠正。过程要求的所有文档完成。3.3业务测试（只适用于应用脚本）3.3.1业务测试活动流程图332业务测试准备3.321 业务测试计划33211目的明确业务测试的范围、测试方法、规则，指导业务测试工作的正确执行。33212角色和职责角色职责应用负责人确定业务测试的范围、规则、进度和人员安排等，编写业务测试计划业务人员、测试组参与评审业务测试计划33213进入条件XM_DW_P_X项目计划已完成XM_DW_R_XX目需求分析说明书和 XM_DW_T_X项目映射文档初稿已完成33214输入xm_dw_p_xM目计划XM_DW_R_XX目需求分析说明书XM_DW_T_X项目映射文档33215任务描述应用负责人根据项目计划， 编写业务测试计划，包括测试相关方的工作安排和测试过 程等；应用负责人组织业务人员和测试组对测试计划进行评审，并形成评审记录；33216输出xm_dw_p_xM