1. 前言

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

2. 环境概述

环境介绍：

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

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

基本流程

3. 数据源备份和restore

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

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

5. 生产环境测试数据

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

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

当前生产环境数据类型

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

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

6. 数据准备小工具

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

6. 测试数据管理规范相关推荐

CFDA《药品数据管理规范》疑难点解读
CFDA审核查验中心在国庆前一天发布了<药品数据管理规范>征求意见稿,引起业内关注.通读这篇规范,大致内容与WHO之前发布了<数据与记录管理规范指南>一样,相对来说,已经写得足 ...
界面设计与测试的规范
作者:flowingice 我在工作中总结了一些有关界面设计与测试的规范,与大家共享. 界面设计与测试规则界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象.而且设计良好的界面能够 ...
测试工作规范及岗位职责
测试工作规范及岗位职责 1组织结构 1.1岗位职责输入&输出 2.1.1测试进入标准 2.1.2测试退出标准 2.1.3测试输入文件 2.1.4测试输出文件 3测试流程 4BUG流程 5流程 ...
手机APP测试流程规范模板
一.流程图二.测试周期 9.25-10.5 1.测试资源测试任务开始前,检查各项测试资源. 1.1.产品功能需求文档 1)产品原型图 2)产品效果图 3)行为统计分析定义文档 4)测试设备(And ...
测试流程规范（三十二条）-升级版
测试流程规范 1.需求创建:项目和需求均需要求产品在PMP/行云里创建相应的项目及需求任务信息: 2.需求确认:同产品,开发以及相关人员确认需求(需求评审必须三方达成一致): 3.需求排期:项目和需求 ...
测试数据管理：测试数据和设计方法是什么？如何管理
测试数据设计与管理指南在目前信息与技术革命性增长史上,测试者通常在软件测试生命周期中经历大量的测试数据消耗. 测试人员不仅收集/维护现有来源的数据,而且还生成大量测试数据,以确保其在实际使用中提供产 ...
ORAN专题系列-19：5G O-RAN FrontHaul前传接口M Plane互操作性测试IOT规范
前言: 在<ORAN专题系列-18:5G O-RAN FrontHaul前传接口互操作性测试规范IOT概述与总体架构>阐述了5G O-RAN FrontHaul前传接口互操作性测试规范IO ...
JUnit测试命名规范
1.测试类的命名定义规范测试类的命名规则是:Test+被测试的业务.Test+被测试的接口.Test+被测试的类类的名字必须由大写字母开头而单词中的其他字母均为小写:如果类名称由多个单词组成,则每 ...
项目测试流程规范（不同公司流程规范不一样，仅供参考）
前言:结合公司的项目情况制定合理的测试流程,提高测试效率和产品质量.核心还是要加强项目成员之间的沟通,在保障研发效率的前提下提高产品质量. 一.测试流程图上述流程图为项目的测试流程图,每家公司用的项 ...

6. 测试数据管理规范

1. 前言

2. 环境概述

3. 数据源备份和restore

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

5. 生产环境测试数据

6. 数据准备小工具

6. 测试数据管理规范相关推荐

最新文章

热门文章