6. 测试数据管理规范

1. 前言

• 本章节是以当前项目举例说明的，可能涉及到一些具体的业务数据，列位看官可以根据例子抽象出自己需要的内容进行参考。

2. 环境概述

1. 环境介绍：

   ​ 环境按照测试流程中的测试种类，整个测试环境分为IX、SX、TX和Stage四种类别（X>0），其中IX、SX是用作接口测试、系统设计测试（功能测试）的环境，TX是性能测试环境，Stage测试环境是集成测试环境；回归测试贯穿于所有测试环节，当前测试环节在哪个环境，对应的回归验证就在哪个环境。

   环境标签	对应测试环节
   Ix，Sx	接口测试、功能测试
   Tx	性能测试
   Stage	系统测试

2. 基本流程
   

3. 数据源备份和restore

1. 数据来源

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

2. 数据restore流程

   1. Restore流程：
      

   2. 解释下整体流向：

      1. 通过触发"xxx-sample-db-restore"，将生产环境的数据dump到Stage环境，形成restore数据源的一部分；
      2. 集成测试产生的Test Data沉淀到Stage环境，形成restore数据源；
      3. 通过定时任务触发"xxx-sample-db-backup"，将Stage的数据备份为restore数据源的数据备份；
      4. 通过触发"xxx-db-restore"，将步骤3中的数据源备份，restore到每一个测试环境。

   3. 从生产restore数据到stage（“xxx-sample-db-restore”），成本是restore后，当前库的数据会被初始化成跟生产库一样，持续更新的数据丢失。

   4. 流程步骤3在每天凌晨定时跑，将新产生的数据备份到restore数据源。

4. 测试环境测试数据管理

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

5. 生产环境测试数据

1. 基本原则

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

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

   1. 当前生产环境数据类型

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

   2. 生产环境数据管理

      1. 测试账号管理

         1. 账号
            1. 个人账号
               • 存在的问题：研发、产品和测试的个人账号，权限过高会存在风险。
               • 方案：通过控制权限来限制访问，取消不必要的权限，有特殊需求发邮件申请。
            2. 公共测试账号
               • 存在的问题：
                 1. 公用的测试账号往往是在特殊的组织架构下面(BD、编辑等)，系统中会根据组织架构露出这些测试账号，比如选择BD的地方会露出测试BD的账号。
                 2. 公用的测试账号往往权限会比较杂，出了问题也比较难追溯。
               • 方案：给公用的测试账号打标，小工具来控制账号的启用停用状态；测试时打开，测试完成时关闭。
         2. 权限（角色）管控：
            1. 线上用户权限管控：真实角色由专人负责新建和分配；
            2. 测试人员权限管控：所有分配给测试的权限都集中在固定的角色中（测试角色），且由专人负责分配和收回。

      2. 商品数据管理；

         1. 测试商品

            1. 已经审核通过的商品；
               • 归档到confluence/文档库进行维护；
               • 商品置为不可见；
               • 测试商品命名时，加上测试两个字，易识别；
               • 测试商品统一维护到测试商品表；
            2. 审核中的商品。
               • 测试完毕后，必须打回到测试供应商，待处理节点不能流转到真实审批人，会造成误解。

         2. 测试类目

            1. 前端所有父子测试类目测试完成后，设置为不启用状态。
            2. 后端所有父子测试类目测试完成后，设置为隐藏。

         3. 品牌

            • 存在的风险：目前测试品牌可以被供应商选择到。
            • 方案：测试完成后，把测试品牌的状态置为停用，供应商不可选择。

      3. 测试供应商

         ​ 目前测试供应商分为境内贸易、境外贸易和一条开放平台的测试供应商；数据独立，不需要做特殊剥离或清理。

      4. 业务工单数据管理；

         1. 测试业务工单需要闭环（完成或关闭）。
         2. 不能闭环的工单，需要流转到测试账号，不能流转到真实审批人，会造成误解。
         3. 工单会作为绩效度量指标，为了不影响度量结果，可以给测试工单打测试标，用小工具或者定时任务来删除测试工单；或者在统计和度量的时候，过滤掉测试工单。

6. 数据准备小工具

1. 背景：某些业务数据的产生流程长，操作多，规则复杂，对于不熟悉这块的同学，或者开发人员，想要这样的测试数据很困难，QA内部开发一些数据准备小工具，可以快速创建复杂的业务数据。
2. 哪些业务流程需要造数据，可以跟开发、其他测试人员多沟通，挖掘痛点难点。