测试数据规范

界北鲲鹏

已于 2024-10-28 11:38:22 修改

阅读量904

点赞数

分类专栏：产品与项目文章标签：大数据压力测试矩阵

于 2021-02-27 12:13:34 首次发布

本文链接：https://blog.youkuaiyun.com/banrieen/article/details/114168219

版权

产品与项目专栏收录该内容

15 篇文章

订阅专栏

本文详述了测试环境数据的管理，包括数据源备份、恢复流程、测试数据管理和清理，强调数据独立性和安全性。此外，针对电商项目，提出了生产环境测试数据的管理方案，涵盖权限控制、角色管控、商品、类目、品牌、供应商和业务工单的数据管理，以及使用数据准备小工具简化复杂业务数据创建。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

请注意系统版本！

数据源备份和恢复

数据来源
- 初始化数据源
  
  这里的数据源，是指初始化测试环境的基础数据；接口测试、性能测试需要批量造的数据不在这个范围之内。
  
  从生产环境dump一份数据下来，作为测试数据源的一部分；鉴于对数据安全性的考虑，这部分数据需要经过脱敏处理，去除掉有关用户或者公司机密的关键性数据。
  在这份数据的基础上，由测试人员再根据实际需要，额外增加一部分测试基础数据，这样整合成第一份初始化数据源。
- 数据源的持续更新
  
  最初的初始化数据源具有时间局限性，但是功能是不断新增和迭代的，所以我们的初始化数据源需要持续更新，以满足测试需要。
  我们在集成测试阶段，把集成测试的数据（Test Data）沉淀下来，作为最新的初始化数据源（Stage Sample DB）。
数据restore流程

Restore流程：
3. 整体流向：

通过触发"xxx-sample-db-restore"，将生产环境的数据dump到Stage环境，形成restore数据源的一部分；
集成测试产生的Test Data沉淀到Stage环境，形成restore数据源；
通过定时任务触发"xxx-sample-db-backup"，将Stage的数据备份为restore数据源的数据备份；
通过触发"xxx-db-restore"，将步骤3中的数据源备份，restore到每一个测试环境。
从生产restore数据到stage（“xxx-sample-db-restore”），成本是restore后，当前库的数据会被初始化成跟生产库一样，持续更新的数据丢失。
流程步骤3在每天凌晨定时跑，将新产生的数据备份到restore数据源。

测试环境测试数据管理

基本原则
- 每个人的测试数据尽量独立，数据有自己的标签。
- 不随意修改他人的测试数据、不随意修改基础数据，不随意修改自己不太了解的数据，避免对他人测试造成影响。
- 需要修改他人数据时，要提前跟他人确认。
- 需要修改基础数据时，需要评估整体影响。
- Restore测试环境数据时，需要提前周知干系人restore计划时间，确认无误后进行，不允许私下操作。
数据清理
- 功能测试的数据一般不需要清理。
- 特殊测试完成后，如果留存的数据会对其他测试造成影响，应该及时清理。
- 自动化测试的数据应在设计时写好清理脚本。

生产环境测试数据
- 基本原则
  - 不允许修改生产环境的基础数据，不随意修改他人的测试数据。
  - 测试数据不允许暴露给真实用户。
  - 能清理的测试数据，需要及时清理。
  - 做好测试数据标签管理，减少对BI数据的影响。
  - 准确评估生产环境测试的范围，只做必要的测试，减少测试数据的产生。
  - 测试数据也要尽量贴近真实数据，不造无意义数据。

生产数据方案（以电商项目为例）

生产环境测试数据

基本原则
不允许修改生产环境的基础数据，不随意修改他人的测试数据。
测试数据不允许暴露给真实用户。
能清理的测试数据，需要及时清理。
做好测试数据标签管理，减少对BI数据的影响。
准确评估生产环境测试的范围，只做必要的测试，减少测试数据的产生。
测试数据也要尽量贴近真实数据，不造无意义数据。
生产数据方案（以电商项目为例）

当前生产环境数据类型

类型	描述
系统账号	1. 账号：包含各个子系统的登陆账号。 2. 权限角色：各子系统的权限角色。
商品	1. 已经审核通过的商品。 2. 审核中的商品。
类目	包含前后端所有父子类目。
品牌	所有被测试商品和测试供应商用到的测试品牌。
供应商	境内贸易、境外贸易和一条开放平台的测试供应商。
系统工单	各子系统的工单。

生产环境数据管理
- 测试账号管理
  - 个人账号
    - 存在的问题：研发、产品和测试的个人账号，权限过高会存在风险。
    - 方案：通过控制权限来限制访问，取消不必要的权限，有特殊需求发邮件申请。
  - 公共测试账号
    - 存在的问题：
      
      公用的测试账号往往是在特殊的组织架构下面(BD、编辑等)，系统中会根据组织架构露出这些测试账号，比如选择BD的地方会露出测试BD的账号。
      
      公用的测试账号往往权限会比较杂，出了问题也比较难追溯。
    - 方案：给公用的测试账号打标，小工具来控制账号的启用停用状态；测试时打开，测试完成时关闭。
  - 权限（角色）管控：
    - 线上用户权限管控：真实角色由专人负责新建和分配；
    - 测试人员权限管控：所有分配给测试的权限都集中在固定的角色中（测试角色），且由专人负责分配和收回。
- 商品数据管理；
  - 测试商品
    - 已经审核通过的商品：
      
      归档到confluence/文档库进行维护；
      
      商品置为不可见；
      
      测试商品命名时，加上测试两个字，易识别；
      
      测试商品统一维护到测试商品表；
    - 审核中的商品：
      
      测试完毕后，必须打回到测试供应商，待处理节点不能流转到真实审批人，会造成误解。
  - 测试类目
    - 前端所有父子测试类目测试完成后，设置为不启用状态。
    - 后端所有父子测试类目测试完成后，设置为隐藏。
  - 品牌
    - 存在的风险：目前测试品牌可以被供应商选择到。
    - 方案：测试完成后，把测试品牌的状态置为停用，供应商不可选择。
- 测试供应商
  - 目前测试供应商分为境内贸易、境外贸易和一条开放平台的测试供应商；数据独立，不需要做特殊剥离或清理。
- 业务工单数据管理；
  - 测试业务工单需要闭环（完成或关闭）。
  - 不能闭环的工单，需要流转到测试账号，不能流转到真实审批人，会造成误解。
  - 工单会作为绩效度量指标，为了不影响度量结果，可以给测试工单打测试标，用小工具或者定时任务来删除测试工单；或者在统计和度量的时候，过滤掉测试工单。