数据类测试方法论

1 引言引言 1 1 编写目的编写目的 编写本文档的目的是进一步规范数据仓库的基础层测试工作 用于指导数 据数据仓库基础层相关集成测试 主要从测试环境 测试策略 测试具体执行 方法 任务计划与安排等为测试工作的展开提供指导和依据 给其他相关组的 组间协调提供工作指导 1 2 测试背景测试背景 数据仓库随着企业信息化程度的不断提高 各类应用系统同时并存并支撑 着企业的业务应用 越来越多企业的信息化主管在开发企业应用时已经考虑到 数据集成和将来对数据的整体有效利用 因此 数据仓库被必然的选择来避免 信息孤岛 实现应用的内部联系和信息的共享 而现如今由于仓库的需求在仓 库发展中不断增加 变化 这要求仓库开发效率加快 准确度提高 实现更加 标准化 开发的工程化 自动化趋势也越来越明显 这就要求数据仓库测试在 完备的测试条件下 更加迅速 高效的完成测试任务 1 3 预期读者预期读者 本文档的预期读者包括 项目管理人员 测试管理人员 参与基础层测试 的测试组成员 其他相关项目组人员 2 测试概述测试概述 2 1 测试目标测试目标 DW 测试主要围绕 ETL 进行 即保证 ETL 和新需求增加的数据质量 其中 ETL 测试保证 1 程序的运行正常 2 数据的质量 保证准确性和数据的稳定性 3 ETL 的效率 对数据抽取上载时 SQL 进行部分优化测试等 目标是保证模型层脚本的跑通性 验证数据是否按照设计需求中既定规则 取数 通过内部集成的方式降低数据的出错概率 确保数据的准确性 将输出 结果与期望结果控制在既定的置信水平范围内 2 2 测试范围测试范围 测试范围是数据仓库项目基础层模型脚本 修数追数脚本及其他建表语句 等 其中模型层脚本包括新增脚本及变更脚本 2 3 测试角色与职责测试角色与职责 角色角色职责职责 测试负责人 制定每次脚本上线点的测试计划 协调测试资源 跟踪测试进度 申请测试所需数据 并对测试数据进行验证 确认 编写测试阶段性小结和测试报告 维护测试环境和测试数据 上线脚本版本控制 测试人员 抽样检查单元测试结果 设计测试案例和测试数据筛选 执行测试用例 提交缺陷报告并跟踪缺陷处理流程 3 测试流程测试流程 基础层脚本测试 测试组主要工作内容 编编写写测测试试案案例例 缺缺陷陷管管理理 加载测试数据 跟踪缺陷 发现缺陷 脚脚本本封封版版 申请测试数据 执执行行测测试试 测测试试案案例例评评审审 准备测试环境 回归验证 跟踪缺陷 发现缺陷 回归验证 编编写写测测试试计计划划 接接收收受受控控单单 准准备备测测试试数数据据 编编写写测测试试报报告告 模型层脚本各组工作大体封版时间 数据组设计封版时间 脚本上线点前至少 15 个工作日 开发组开发封版时间 脚本上线点前至少 10 个工作日 测试组测试封版时间 脚本上线点前至少 5 个工作日 上线演练完成时间 脚本上线点前至少 3 个工作日 注 这里各组封版时间请测试负责人及时关注设计组封版情况并提醒开发组确 定落实封版 避免后期测试时间紧迫无法按时完成既定测试任务 4 测试准备测试准备 4 1 准入条件测试准入条件测试 4 1 1 检查受控单检查受控单 检查开发提交的受控单 一方面是为了规范开发人员的脚本提交流程 另一方面则是为了检查受控库中涉及的脚本是否为本次上线范围内的脚本 若不在本次上线范围内需与相关开发人员确认具体情况 受控单中需填写内容如下 1 变更号 与变更跟踪登记簿中的EDW变更号一致 有时候会出现一只脚 本涉及多个变更号任务 所以请测试负责人分配脚本时需要将同只脚本 分配给同个测试人员 方便测试实施 2 里程碑名称 变更编号 3 开发流路径 脚本测试流存放路径与其一致 4 程序文件名 与变更跟踪登记簿中脚本名称一致 5 负责人 相关脚本开发负责人 6 受控原因 包括设计变更 新增实体 新增映射 MQC缺陷等 7 变更描述 与变更跟踪登记簿中变更描述一致 8 测试环境 开发人员单元测试环境 9 预计上线日期 脚本的上线日期 4 1 2 检查单元测试结果检查单元测试结果 针对开发人员提供的项目源码提交受控库申请表中填写的测试环境 在 相应的环境下查看脚本是否有进行单元测试 通过SQL语句查询表中数据 检查的内容如下 1 目标表名 显示内容包括 检查表的表名 2 主键名 显示内容包括 检查表的主键名 3 检查类型 显示内容包括 主键重复检查 主键空格检查 检查表的数据 空间和分布倾斜因子 检查表的记录分布情况 源表记录数与目标表记 录数一致性 代码有效性检查 检查倒链 检查开链和交叉链 检查脚 本重跑 4 各检查内容对应的输出数据 显示内容包括 a 检查主键重复 主键重复个数 b 检查主键空格 主键含空格记录数 c 检查表的数据空间和分布倾斜因子 检查目标表的倾斜因子是否大 于 50 占用空间 峰值空间 倾斜因子 d 检查表的记录分布情况 AMP 最大记录 AMP 最小记录 e 源表记录数与目标表中更新的记录数一致性 源表记录 目标记录 记录数差 f 代码有效性检查 检查源字段的取值范围是否在包含在对照表的取 值范围中 代码字段 无效记录 g 检查倒链 检查是否存在开始日期大于和等于结束日期的记录 倒 链记录数 h 检查开链和交叉链 检查是否存在各时期的时间段总和不等于最大 日期和最小日期差的记录 开链记录数 5 检查结果 显示内容包括 正常 异常 6 检查日期 显示内容包括 脚本运行的日期 7 系统时间 显示内容包括 脚本运行的时间 若返回结果非空 首先确认检查日期显示为近期的时间 以保证该单元 测试为针对本次上线变更所进行的 再查看各检查结果是否正常 否则将受控单打回 通知开发人员进行单元测试后重新提交受控单方可进行 集成测试 4 2 脚本准备脚本准备 4 2 1 脚本提交流程脚本提交流程 开发人员完成开发后 将脚本提交配置管理工具受控 并以受控申请单 形式通知测试人员 4 3 编写测试用例编写测试用例 所谓的测试案例就是将软件测试的行为活动 作一个科学化的组织归纳 简单的说 测试案例就是设计一个情况 软件程序在这种情况下 必须能够 正常的运行并且达到程序设计的预期执行结果 所以测试案例的设计要具 有目的性 根据数据仓库的特点及数据类测试的特性 总结出以下几个测试 点 1 脚本变更内容检查 对照变更跟踪登记簿 必需 2 源表字段与目标字段的转换 必需 3 源表字段与目标字段的映射 必需 4 PK重复检查 全记录重复检查 必需 5 PI分布是否均匀 必需 6 源表数据与目标表数据的数据比对 查看进行是否正确 是否发生字段 截取等 必需 7 记录数是否一致 必需 8 脚本重复执行性 必需 9 删除的数据正确性 发生更新时 对数据的删除是否正确 必需 10 拉链表的状态断链 交叉链 开链 必需 11 代码的取值种类和代码的范围是否与源系统一致 12 特定字段的约束检验 如日期字段是否有进行格式化操作 有拼加前缀 字段是否需考虑出现空值情况的处理 13 表间关系所带来的字段检验 14 总分关系是否能保持 15 主外关系延续性 测试范围内的表 16 复杂算法的正确性 随着测试工作不断的深入 测试组会对质量组 运维组及其他组发现的 问题进行归纳总结 以不断完善测试测试点 测试案例的设计要根据脚本业务规则的不同 来选择相应的测试点进行 案例设计 4 4 数据准备数据准备 4 4 1 申请测试数据申请测试数据 在测试前首先保证有足够的测试数据 与设计确认是否已同步生产数据 或从ODS接口组加载测试数据到测试环境 包括加载的测试环境 库名及日 期 也可使用以下SQL语句查询 若在测试过程中发现所需源表不存在或数据为空或源表的业务日期不统 一 且该表涉及变更描述内容的情况 可联系设计人员或ODS接口组请求重 新加载数据 但实际申请测试数据流程可能较长 一般很难在测试计划内得 到解决 为了不影响测脚本的正常上线 可先通过建立空表或修改业务日期 或手工造数进行解决 待数据重新申请下来再进行验证 5 测试实施测试实施 5 1 规范性检查规范性检查 为了方便仓库统一管理 避免由开发人员的编写习惯等原因带来的潜在问 题和风险 项目组要求所有上线脚本必须通过规范性检查 目前仓库的规范性 检查 主要通过脚本自动检查 手工检查的方式实现 5 1 1 自动检查自动检查 编写自动检查脚本以便检查开发人员提交测试脚本的规范性 检查的指标 由项目组或者是客户制定 5 1 2 手动检查手动检查 由于部分规范化的检查暂未实现 为了规范化的检查程度达到更广 规范 检查脚本运行完毕后 根据规范性要求进行 手动检查 5 2 执行脚本执行脚本 1 脚本跑通检查 nohup perl 脚本名 源表数据日期 log 5 3 5 拉链检查 目标表为拉链表 拉链检查 目标表为拉链表 1 检查开链 断链和交叉链 无输出结果时通过 2 检查倒链 主要是检查是否存在开始日期小于和等结束日期的记录 无输出 结果时通过 6 缺陷管理缺陷管理 6 1 MQC 缺陷库缺陷库 Mercury Quality Center 的简称 是美科利公司开发的一个基于 Web 方式的 测试管理系统 可以系统的控制和管理应用程序测试流程的各个阶段 包括测试需求 计划 测试 执行测试及跟踪缺陷 从而保证应用系统测试的质量 采用 B S 模式 数据集中在后台的数据库中 便于共享 打开 IE 输入 URL http 128 32 96 172 8080 qcbin start a htm 进入到登陆页面 输入用户名及密码 通过身份认证后再选择域及项目 其中域选择 开发三部 项目选择 数据仓库应用支持 2008 测试项目 6 2 缺陷流程图缺陷流程图 注意 只有提出缺陷的测试人员或测试经理才能关闭缺陷 6 3 缺陷提交规范缺陷提交规范 6 3 1 新建缺陷新建缺陷 通过用例库中的用例去新建缺陷 具体如下 测试计划 链接的缺陷 新建缺陷 6 3 2 缺陷完善缺陷完善 a 主题 自动生成 在自动生成脚本名字其前方填写开发人员名字 在其后方 填写缺陷主要问题描述 b 缺陷状态 指缺陷通过一个跟踪修复过程的进展情况 包括 提出 处理 拒绝 待验证 重现 关闭 c 严重程度 是指因缺陷引起的故障对系统的影响程度 由提出人初步指定 缺陷修复人员负责确认 包括 严重 一般 轻微 d 紧急程度 指缺陷必须被修复的紧急程度 由提出人指定 包括 高 中 低 e 缺陷起源 指引起缺陷的起因 包括 需求 架构 设计 编码 环境 数 据 拒绝 f 缺陷描述 要求提出人描述的缺陷分类准确 叙述简洁 步骤清楚 有实例 易再现 复杂缺陷有据可查 截图或其它形式的附件 g 分析和修改内容 开发人员修复或拒绝修复缺陷时 需在 缺陷详细信息 模块中的 分析 和修改内容 中使用 添加注释 按钮详细填写修复的内容及拒绝的原因 其他 MQC 使用请参考附件 CC 目录 2480 MQC 相关资料 6 3 3 缺陷跟踪缺陷跟踪 缺陷提交完成后 系统会自动发邮件通知相关缺陷负责人 但由于实际工 作影响 缺陷负责人可能会忽略缺陷邮件提醒 故缺陷提出人要对缺陷负责人 进行友情提醒 以便及时解决问题 避免影响脚本上线进度 做到定期查看缺 陷状态 进入MQC缺陷管理页面 查看提交的缺陷状态 对状态为 待验证 的缺陷及时进行回归验证 如验证通过 关闭缺陷 否则 需要再重新打开缺陷 并通知缺陷负责人及时修改 对状态为 拒绝 或 挂起 的缺陷 需要和缺陷负责人进行确认 并让缺陷 负责人对缺陷做出注释 给出拒绝或挂起的理由 在脚本封版后 统计出状态为 挂起 拒绝 的缺陷 与脚本版本一 起提交 并让相关开发人员做好后续跟踪 7 测试后期测试后期 7 1 测试版本控制测试版本控制 7 1 1 测试版本对比测试版本对比 在脚本完成测试后 MQC上的问题都得到解决情况下 进行上线版本封 版 要保持封版的版本是最新的 以免版本产生混乱 故需对版本进行比对 7 1 2 测试版本输出测试版本输出 1 测试版本封版 在脚本完成测试后 MQC上的问题都得到解决情况下 进行上线版本封 版 封版脚本包括以下几个提交件 a 经测试的最新上线模型脚本 b 代码初始化脚本 c 物理模型建表语句及导数脚本 d 追数 修数脚本 e 上线模型脚本清单 f 上线遗留缺陷清单及相关风险提醒 提醒开发人员 质量组相关人员 进行跟踪 2 上线演练版本 版本封版完成后 需要在测试环境进行一次模型上线测试 以验证所封 版的脚本是否无错 对其它生产脚本有无影响 进而可以检验分析人员的 影 响性分析是否遗漏 3 上线版本 上线演练结束后 若对于除遗留缺陷未发现其他问题 可对版本进行封 版 提交上线