数据项目中的测试战术与测试工具

随着科学的进步、技术的不断更新，世界已全面进入数字化和智能化时代。2021年3月，国家“十四五”规划的正式发布，进一步催化了各大小企业争分夺秒的进行数字化转型、大数据赋能业务、数智化创新等举措，为的就是不久的将来企业紧跟时代发展不被科技进步所淘汰。
近年来，数据仓库、数据平台、数据中台的建设爆炸式增长，相关的技术与架构也纷纷涌跃与各大社区或公众号，本文从测试视角，总结分享一些在数据项目中积累的战术（策略）与武器（工具）。
在分享测试战术之前，先简单介绍一下数据项目的数据分层架构。

数据分层架构

数据分层架构并没有固定的标准，行业内数据分层通常是分为三个层：ODS(Operation Data Store) - DW（DataWarehousel） - ADS(Data Warehouse Service)。

数据分层案例

• ODS数据运营层：即原始数据层，与业务系统基本同构，目的是保留历史，解耦业务数据库，这样整个数据平台只需要访问一次业务数据库即可。ODS 层有些时候会细分为两层，一个 STG 数据缓冲层，存原始数据，一个 ODS，存简单清洗的数据。
• DWD数据仓库层：由下到上为 DWD(Data Warehouse Detail) -> DWB(Data Warehouse Base) -> DWS(Data Warehouse Service) 。
  • DWD明细数据层，对数据进行清洗、代码统一、字段统一、格式统一、简单映射等工作，是为后续的处理提供统一、标准的数据。
  • DWB基础数据层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
  • DWS服务数据层，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表
• ADS数据服务层：主要是提供给数据产品和数据分析使用的数据，包括前端报表、分析图表、KPI、仪表盘等分析，面向最终结果用户。

测试战术与装备

战术一：依照数据分层架构，由底上向逐层验证。（复杂问题简单化）

无论你是数仓项目、还是在数据平台类项目上，数据的完整链路非常长，从最底层的ODS到最上层的ADS，经过了很多步的数据转换与逻辑处理，如果不进行分层验证，那么，端对端的测试复杂度非常高；而且，发现问题后，Debug的难度和时间成本也较高。
目前不少数据测试团队栽倒在此环节，还停留在只做端对端测试，测试痛苦且效率低下。

分层验证

战术二：依照精准定位+全量捕漏，精准造测试数据验证，生产全量数据探查。

在测试环节，面对单步任务处理逻辑，由于数据场景较多，测试难度不小。所以，更需要精准构造每一条测试数据来完成场景覆盖。避免多余场景数据造成干扰、防止数据混乱导致场景遗漏，数据场景清淅、易于精准定位问题、提高效率。
大数据时代下，面对真实环境的数据体量大、数据多样、数据质量差等现状，过去的测试环境构建测试数据变更更加困难，而且总有意想不到的数据情况在生产，所以一定要尽早上线验证探查。

战术三：依照数据开发生命周期，每一环节进行质量检验。

无论你是瀑布开发还是敏捷开发方式，在整个开发生命周期展开验证、形成闭环。

• 瀑布团队：需求阶段 -> 架构设计 -> 开发阶段 -> 测试阶段 -> 生产线上。
  • 需求阶段：对需求进行评审，从数据质量的六个维度（完整性、一致性、准确性、唯一性、及时性、有效性）评审需求文档中是否存在不符合项，从需求的价值角度评审是否合理，从覆盖场景角度评审是否有遗漏或不符合场景等，从数据安全、性能等非功能性方面评审是否有不符合项。
  • 架构设计：参加架构设计评审会议，对于数据分层架构评审需要关注是否数据结构清晰、是否方便数据血缘追踪、是否把复杂问题简单化（比如，把复杂的任务拆解成多步骤、每一层处理单步，便于维护数据准确性，也易于定位或修复问题）、是否能屏蔽业务的影响（比如，改一处需求，指标维度变更还得重新接入数据）。
  • 开发阶段：提前编写测试用例（构建测试数据、数据即用例），与开发人员提前对齐目标结果。代码开发完成后，及时用准备好的测试数据进行验证。
  • 测试阶段：更多的是进行探索式测试，减少重复测试(比如，开发阶段的测试数据以及环境都没有差异，无需重复测试），如QA环境有脱敏生产数据，重点进行数据探查验证（参见：《一定要做数据探查》）
  • 生产线上：生产环境下的QA，数据结果探查验证、特别是要持续关注监控与日志，及时发现问题、及时与业务侧收集反馈等。
• 敏捷团队：敏捷开发方式下的测试实践之前分享太多次，这里不再详细赘述。（可参见：《数据中台测试实践分享》
  数据项目测试活动

战术四：依照效能提升，提前预防、自动化装备

• 前面提到的从开发生命周期出发，每个阶段进行安排相关就及时验证，实际上就是为了预防缺陷遗漏到后面。越早发现问题，修复成本越低。
• 除了提前参与、提前验证、预防缺陷，还需要通过测试执行效率的提升来加强质量保障。数据类项目的测试用例即为测试数据，那么，测试数据构造自动化、每一层任务的测试验证自动化、数据探查自动化，一方面解决了人为执行可能出错的问题，二来自动化替代人工效率提高。
• 工具推荐，对于测试数据构造工具有：Datafaker、DbSchema、Online test data generator等；ETL测试工具有：RightData、QuerySurge等；数据质量检查工具：great_expectations、mobyDQ、DataQuality、GriFFin、Qualitis等。

工具推荐

赠送利器Easy SQL

在项目实践过程中，即便应用了以上测试工具加持，团队依然会遇到各种困扰。

• 构造测试数据工具只支持按定义规则批量生成数据，无法做到精准构造每步处理逻辑覆盖所有测试场景的最小集；而且定义每个字段规则时、字段与字段之间以及表与表之间都有复杂的约束或关联时，构建数据复杂度依然很高。
  【期望】期望能在Excel或Json文件中，直接在单元格填上数据即用例，即代表是测试数据已准备，这样多好。
• 测试环境中构造数据时，数据表有上百个Schema，每次通过构造工具创建数据时，需要对这上百个字段进行构造。
  【期望】只构造与任务处理逻辑相关的字段数据、没参与逻辑处理的字段不用构造、减少繁杂提高效率。
• 测试环境的维护总是需要花大量时间，不论是由于构造数据出问题还是处理逻辑有Bug，都会造成测试环境留下脏数据，如果不及时处理，会影响测试的正确性，造成不必要的浪费。
  【期望】希望能像UT一样不需要一个真实环境，就能对每一步数据处理任务进行自动化测试，开发人员或测试人员只负责MOCK测试数据与结果数据（比如：用简单的Excel填数据），程序能自动比对预期的结果和实际运行结果。
• ...等等
  推荐一款利器：开源工具Easy SQL，Easy SQL 旨在简化数据 ETL 开发过程，帮助数据团队提升研发效能。它自带的Test SQL框架就是以上期望的方式，大大提升了测试效率。 附Easy SQL Git地址。

Easy SQL Test ETL Test ETL中测试用例