6. 测试数据管理规范

朴灿烈づ我的快乐病毒、 2024-04-18 11:54 52阅读 0赞

# 1. 前言 #

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

# 2. 环境概述 #

1.  环境介绍：
    
     环境按照测试流程中的测试种类，整个测试环境分为IX、SX、TX和Stage四种类别（X>0），其中IX、SX是用作接口测试、系统设计测试（功能测试）的环境，TX是性能测试环境，Stage测试环境是集成测试环境；回归测试贯穿于所有测试环节，当前测试环节在哪个环境，对应的回归验证就在哪个环境。
    
    <table> 
     <thead> 
      <tr> 
       <th>环境标签</th> 
       <th>对应测试环节</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>Ix，Sx</td> 
       <td>接口测试、功能测试</td> 
      </tr> 
      <tr> 
       <td>Tx</td> 
       <td>性能测试</td> 
      </tr> 
      <tr> 
       <td>Stage</td> 
       <td>系统测试</td> 
      </tr> 
     </tbody> 
    </table>
2.  基本流程  
    ![TestFlow][]

# 3. 数据源备份和restore #

1.  数据来源
    
    1.  初始化数据源
        
        1.  这里的数据源，是指初始化测试环境的基础数据；接口测试、性能测试需要批量造的数据不在这个范围之内。
        2.  从生产环境dump一份数据下来，作为测试数据源的一部分；鉴于对数据安全性的考虑，这部分数据需要经过脱敏处理，去除掉有关用户或者公司机密的关键性数据。
        3.  在这份数据的基础上，由测试人员再根据实际需要，额外增加一部分测试基础数据，这样整合成第一份初始化数据源。
    2.  数据源的持续更新
        
        1.  最初的初始化数据源具有时间局限性，但是功能是不断新增和迭代的，所以我们的初始化数据源需要持续更新，以满足测试需要。
        2.  我们在集成测试阶段，把集成测试的数据（Test Data）沉淀下来，作为最新的初始化数据源（Stage Sample DB）。
2.  数据restore流程
    
    1.  Restore流程：  
        ![Restore Flow][]
    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.  当前生产环境数据类型
        
        <table> 
         <thead> 
          <tr> 
           <th>类型</th> 
           <th>描述</th> 
          </tr> 
         </thead> 
         <tbody> 
          <tr> 
           <td>系统账号</td> 
           <td>1. 账号：包含各个子系统的登陆账号。 <br>2. 权限角色：各子系统的权限角色。</td> 
          </tr> 
          <tr> 
           <td>商品</td> 
           <td>1. 已经审核通过的商品。<br>2. 审核中的商品。</td> 
          </tr> 
          <tr> 
           <td>类目</td> 
           <td>包含前后端所有父子类目。</td> 
          </tr> 
          <tr> 
           <td>品牌</td> 
           <td>所有被测试商品和测试供应商用到的测试品牌。</td> 
          </tr> 
          <tr> 
           <td>供应商</td> 
           <td>境内贸易、境外贸易和一条开放平台的测试供应商。</td> 
          </tr> 
          <tr> 
           <td>系统工单</td> 
           <td>各子系统的工单。</td> 
          </tr> 
         </tbody> 
        </table>
    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.  哪些业务流程需要造数据，可以跟开发、其他测试人员多沟通，挖掘痛点难点。

[TestFlow]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c1092fda834f4b06b1dd225a0222a456.png
[Restore Flow]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a8c88948f3204d8db579ec6cea080694.png