如何构建质量保障体系？

 

质量保障体系定义

质量保障体系是企业内部系统的技术和管理手段，是有计划的、系统的企业活动，目的是满足业务发展需要，生产出满足质量目标的产品。即为了共同的目标，一群人一块儿做事。

 

 

 

体系的定义：

体系：泛指若干有关事务或某些意识按照一定的秩序和内部联系组合而成的整体，是不同系统组成的系统。

 

 

 

 

如何构建质量保障体系？

 

一、流程规范
流程：产品研发→运营&运维→售后服务

1.1 产品研发阶段，该阶段是测试人员的“主战场”

关键原则

• 各职能角色必须有Ower角色，PM、RD、QA、SRE
• 重评审和讨论，群策群力
  • 在大规模软件开发中超过50%的错误来自需求分析和技术设计阶段
  • 通过多方审查的机制保证过程质量、提高研发效率
• 前紧后松，提前应对风险。前置发现更多问题，使后面过程更顺畅
• 关键节点严格把控

规范制定和落地

• 项目开始：粗颗粒度的规范
• 项目过程中：先商讨解决方案，再逐步明确流程；规范先测试内部评审，再与协同方达成共识，最后按一定节奏推广
• 规范落地后：不断跟进执行情况，针对性的分析与改进，形成PDCA循环
  P： plan 计划
  D： do 执行
  C： check 检查
  A: Action 处理

规范如何呈现

要求

1. 通俗易懂
2. 关键字眼，需要字体颜色醒目或加粗
3. 存放位置，人人可访问

呈现方式

• 流程图
• 泳道图，工具：StarUML 、Rose、Visio等，纵向是部门职能，横向是岗位
• 

   

   

需求阶段

产品需求评审PRD 或 市场需求文档MRD

评审要点

• 完备性
  正常场景、异常场景是否都有考虑？
  UI设计 和 提示信息是否完整、友好？
• 易理解
  需求的表述是否具有二义性？
  流程类需求是否具有清晰的流程图？
  避免模糊描述：同线上逻辑、同已有逻辑、每种状态都需要处理（不说明有几种状态）
• 可行性
  需求中的功能是否具有可操作性，能否通过现有技术实现？
• 一致性
  是否与现有功能冲突？存在冲突时是否有兼容逻辑？
• 可测试性
  需求中的功能要求是否有对错判断？
  需求中的非功能要求是否具备验证的标准和方法？

常见误区
很多QA容易出现：弱化需求评审或技术设计评审，投入度较低，等其他需求测试完成再花精力去熟悉它，这样容易造成长期的恶性循环
改进：强化需求评审和技术设计评审环节，投入较多精力前置思考好一个需求的重点、难点、风险点，提前应对。

研发阶段

评审对象：技术设计评审

评审要点

• 正确性
  技术设计是否可以满足业务需求中的全部功能要求？
  对异常场景考虑是否充分？
• 可测性
  是否可测？
  预期结果是否稳定？
• 非功能性
  是否考虑了安全性、性能、稳定性、扩展性、可靠性等非功能质量属性？
• 兼容性
  对不同形态和版本的终端是否兼容？
  对上下游的服务和数据是否兼容
• 发布方案
  部署逻辑是否合理？
  是否需要对数据结构、缓存、各类配置进行操作？
  功能是否具备可回滚能力？
  灰度计划是否合理？
  对服务的关键业务指标和技术指标是否做了监控和报警配置？
  应急预案有哪些？如何应对？
  预计的发布时间如何安排？需要哪些人员协同？

测试阶段

评审对象：测试方案 和 用例设计

提高测试用例质量的方式
1. 尽量将测试用例模板标准化
2. 评审用例，评审时间不宜过早或过晚。一般提测前2天左右完成

评审要点

• 测试范围：测试用例是否覆盖了业务和技术需求？对于已有功能是否进行了必要的回归？
• 异常情况：用例是否考虑了非常规操作或其他异常情况？
• 易读性：测试用例是否包含前置条件、操作步骤、期望结果等必要信息？
• 非功能性设计：针对非功能性的需求和技术设计，测试用例是否设计充分？

测试执行阶段关注点

• 缺陷管理
• 测试总结与分析
• 测试报告编写

发布阶段注意点

• 事前：前置准备发布内容
• 事中：采用既定的发布策略，发布出现问题，应立即回滚，不要线上解决问题
• 事后：发布完成后观察线上日志，并进行线上回归。回归时避免写入操作。

线上回归完毕后，需持续关注各项指标，对告警及时响应

1.2 日常运营/运维阶段

运营活动

• 拉新
• 留存
• 促活

运维活动

• 容量规划与实施
• 服务集群维护
• 系统容错管理

产品研发阶段、日常运营/运维阶段、售后服务阶段 这三个阶段共同构成了整个业务流程，要做到全流程质量保障，需要具有全局思维。即积极影响产品研发阶段，推动流程规范的制定、建设和完善；对日常运维、运营阶段和售后服务阶段保持持续关注，定期收集这两个阶段中遇到的问题，做好协同和配合，思考在产品研发阶段如何预防或闭环解决这类问题。

 

二、测试技术

技术选型时考虑的因素

• 团队的诉求
  • 团队的质量方面遇到了怎样的痛点问题？
  • 是个别测试人员的问题还是团队整体的问题？
• 技术的特性
  
  • 基于痛点问题，有哪些可选的测试技术和工具？
  • 该测试技术解决了什么问题？有哪些优势和劣势？
  • 技术成熟度怎样？如果涉及工具，使用开源工具还是商业工具？
• 落地的成本
  
  • 进入该技术需要怎样的成本？
  • 职能分工：该技术的落地需要哪个团队来主导，哪些团队来参与？
  • 团队是否具备落地这项技术的能力？

常见痛点及选型分析

1. 如何更早发现问题？

动态测试技术

• 单元测试
• 集成测试
• 组件测试
• 契约测试
• 端到端的测试

局限性

• 发现问题的类别--不能发现文档类的问题
• 发现问题的时机--绝大多数情况下必须等到程序代码实现后才能进行
• 修复问题的成本--修复问题必须要修改代码，并进行回归验证

静态测试技术

• 人工静态技术
  
  • 代码走查 code review
  • 需求评审
  • 技术方案评审
  • 测试用例评审
• 自动静态技术
  
  • 静态代码检查，Sonar

问题类别

变量问题：未初始化、声明了未调用、类型不匹配等
冗余代码: 重复代码
空指针引用
死循环
缓冲区溢出
数组越界

2. 如何衡量测试的充分性？

业务层面：通过PRD编写测试用例，再通过多方review确保测试用例覆盖了所有业务功能点，因此用例的通过率就是功能点的覆盖率。如果用例执行通过，就说明测试覆盖率100%

贝壳：佩奇平台接口覆盖率上报

代码层面：行、路径、类、方法、接口覆盖率

3. 测试效果如何评估？

指标选择：梳理当前评测功能的效果衡量属性，属性需要可量化

权重设置：对衡量属性进行权重设置

指标打分：选取足够的数据量触发功能效果，再对衡量属性进行打分

效果输出：计算总得分，从而知道被测对象或系统的 效果值

4.如何提升测试效率？

• 人员：测试人员通过学习或经验的积累获得能力的提升、招聘能力更强的测试人员
• 时间：投入更多的个人时间，即加班，单看测试过程，效率未必提升，但从交付周期的视角去看，交付效率提升了
• 过程：
  • 针对测试对象进行可测试性改造，使测试过程更顺畅；
  • 严格遵守流程规范，减少返工和无效沟通；
  • 进行过程质量把控，当研发过程质量提升，测试时间将大大缩短。
• 环境维护：确保测试环境稳定，且尽可能仿真生成环境
• 测试技术
  
  • 自动化测试技术
    
    • 效率高
    • 精确
    • 可重复
    • 整体速度快
  • 持续集成与持续交付
• 精准测试
  
  • 在不降低质量标准的前提下，探寻缩减测试范围、减少测试独占时长的方法
• 自动化测试的收益分析
  
  • ROI = 自动化提升的效率/自动化产生的成本 = （手工用例执行的时间 - 自动化用例执行时间）* 自动化用例的有效执行次数 / 自动化用例编写和维护的总成本

5. 专项测试技术

• 如何找出系统性能瓶颈？--全链路压力测试

微服务架构下，单服务接口性能测试很难模拟出接近生产环境的场景和数据规模，因为整个集群和系统的性能取决于接口的短板效应，短板的接口在正常的流量下，是不会显现出来的。

• 如何避免系统被攻击？--安全测试

渗透测试，以成功入侵系统，证明系统存在安全问题为出发点，以攻击者的角度来看待和思考问题

在常规的测试过程中加入安全测试的元素，比如针对日志信息进行脱敏、对接口中的关键数据进行脱敏、避免被爬虫等。

安全类测试工具：SQLmap、Burp Suite 、Wireshark等

• 如何测试“流程”？--灾难恢复测试

DiRT (Disaster Recovery Testing)灾难恢复测试 是通过对系统故障进行预案和演练，看看各团队如何协同响应。通过演练暴露问题，不断推动系统、工具、流程、人员能力的提升。

 

三、CI/CD

用途

1. 明确各种"类生产环境"在交付流程中的位置和用途差异点，保证他们的稳定可用
2. 将各种测试技术和自动化技术集成起来，使代码提交后能 自动构建、部署、测试，生成工具链

区别
CI 持续集成：技术操作
CD 持续交付：业务行为

测试环境特点

• 整个团队共用一套测试环境
• 

   

   

• 每个测试人员一套完整的测试环境
• 

   

   

• 服务级复用的虚拟化技术，基于消息路由的控制，实现集群中部分服务复用，比如司南的泳道环境
• 

   

   

各种环境

• 测试环境，新功能测试
• 预发布环境
  • 发布顺序测试
  • 回归测试
  • 特殊内容测试（支付场景等）
• 生产环境，测试右移
  • 线上回归
    • 已有功能checklist
    • 新上线功能验收
  • 业务逻辑灰度
  • A/B 测试
    • 两个版本分别部署在不用的服务器上并开放给不同的用户使用，用于手机用户反馈或行为数据来辅助产品功能设计
    • eg1：对比两种营销策略对用户留存的影响
    • eg2: 不必两种推荐算法的优劣
  • 线上监控
• 其他常见环境
  • 本地环境
  • 研发环境
  • 用户验收环境

构建持续交互工具链需要考虑哪些内容？

• 基础设施盘点
  • 如何做代码和配置的管理？
  • 各个环境如何管理？
  • 构建部署在多大程度上实现了自动化？
  • 测试阶段如何流转？
  • 有怎样的质量目标？
  • 各种类型自动化测试的建设情况？
  • 如何感知关键节点的变更和反馈？
• 组织支持
  
  • 需要各部门管理层支持
  • 需要一线员工强烈的改进意愿
• 关键过程自动化
  
  • 引入合适的工具或自建工具来完成，
  • 例如针对api的自动化、selenium进行端到端测试
  • 切记不可重复造轮子，尽量与其他团队共建，否则太容易与其他团队形成对比局面，最终拖垮整个工具链的建设
• 工具整合
  
  • 对上述工具或自动化设施进行整合，实现“链”的效果

 

四、度量与运营
“你如果无法度量它，就无法管理它”

概念
度量：量化指标, 度量的内容：质量、效率、价值
运营：通过干预，提升指标，运营手段：跟踪、复盘、改进

质量度量的核心指标

• 滞后性指标（关注交付质量）

  • 线上故障：线上故障数、故障级别、线上故障恢复时长、线上缺陷数
  • 服务稳定性：服务可用性、错误类型分布、错误数量、错误率、报警数
  • 服务可用性：度量线上服务的性能，接口响应时间、慢响应率、慢sql、最大qps
  • 服务安全性：安全漏洞严重问题数

• 引领性指标（关注过程质量）

  • 需求质量
    • 需求评审打回次数
    • 需求变更次数
    • 需求插入次数
    • 需求质量bug数
  • 开发质量
    
    • 提测质量
    • 冒烟用例通过率
    • 代码质量
    • 千行代码bug率
    • bug工时比
  • 测试质量
    
    • 测试覆盖率
    • 有效bug率
    • 整体漏测率
    • bug收敛情况
  • 发布质量
    
    • 构建失败率
    • 发布回滚率
    • 非发布时间发布次数

 

质量度量指标需符合SMART原则

• 具体的 specific
• 可度量 measurable
• 可达到 attainable
• 与其他目标有相关性 relevant
• 有明确的截止期限 time-bound

 

质量运营 PDCA

• 制定改进计划 Plan
  
  • 质量痛点驱动
  • 质量目标驱动
• 实施落地计划 Do
  
  • 数据收集和聚合
• 复盘和反馈 Check
  
  • 书面总结报告
  • 复盘总结会
• 改进和推广 Action

效率度量指标

• 交付周期比、工时比
• 累计流量图
• 

   

   

• 黑线代表不同时间点，需求评审完成进入开发阶段的需求个数；
  红线代表开发人员提交给测试人员进行测试的需求个数；
  绿线代表测试人员完成测试，等待发布到生产环境的需求个数。
  同一时刻，和弦和红线的差值表示待开发任务的“堆积”，
  红线和绿线的差值表示待测试任务的堆积，反映了交互过程中开发和测试效率瓶颈
• 吞吐率
  吞吐率是单个阶段的效率衡量，它表示单位时间内，团队能交付多少产出
  因为产品交付过程是以需求为单位进行价值传递，所以各个阶段可以以需求个数来作为度量单位，并且需要拉长周期来统计吞吐率，比如一个月或一个季度等

 

效率痛点分析

5 why 分析法：对一个问题点连续以 至少 5个为什么来自问，以追究其根本原因

测试资源不足、测试效率不高问题分析框架

• 人数比例概况了解：RD：QA=10:1，当测试人员数量极少时，效率很难提升上去，因为一个人需要兼顾的东西太多，很难面面俱到，切换成本非常高
• 测试团队自身效率分析
  
  • 测试团队视角
  • 测试人员视角
  • 项目组视角

价值度量指标

• 业务价值
  
  • 营收增长情况
  • 订单量增长情况
  • DAU增长情况
  • 用户停留时长情况
  • 用户转化率情况
• 技术价值
  
  • qps增长情况
  • 可用性增长情况
  • 响应时间减少情况
  • 故障恢复时间降低情况

价值闭环运营

在需求评审的准入条件中加入价值衡量环节，需求发布后跟进复盘需求的价值达成情况

价值衡量包含的内容

• 预期目标
• 衡量周期
• 收益获取方式

 

五、组织保障

产品质量离不开组织中每个参与部门的协作；

从构建质量保障体系上升到 树立“质量文化”

多部门角色协作常见问题

• PM常见问题

  • 需求文档质量差
    
    • 事前：
      
      • PRD在需求评审前2天发出来，以方便相关方提前阅读并提出问题；
      • 针对不合理的地方，以书面形式与该需求关联起来，比如录入缺陷系统、形成需求文档的评论和批注等；
      • 需求评审前，PM需要与主要开发人员进行预沟通，确保需求文档中方案的可行性
    • 事中：
      
      • 评审中不针对细节进行讲解和探讨，评审时间控制在1小时内；
      • 参与方应尽可能都在场，避免因为信息不对称造成其他问题。
      • 评审中的问题应以书面形式记录下来。
    • 事后：
      
      • 针对参与方提出的需求问题进行修改，产品经理修改完毕后，形成需求文档终稿；
      • 在此之后，需求文档的修改视为需求变更，需要发送邮件申请变更
      • 临时需求多，倒排项目多
      • 定期与PM针对项目规划进行沟通，了解阶段性规划（季度和月度）
      • 重点项目的预期上线时间点，提前管理好时间
      • 在合理的范围内引导PM把需求均匀分布，避免出现一段时间忙、一段时间闲的情况

RD常见问题

• 协同项目易出问题
• 多人负责等同于没人负责
• 借鉴RASCI工具的思想，有且仅有一个人为整个项目的完成负责，在各子方向需求的PM、RD、QA中也推选一个主R，职责是在该职责角色内起到横向主导作用。在整个项目过程中，分职能主R向项目主R虚线汇报，形成RASCI矩阵
• R：负责Responsible, 对项目或任务的完成负责的人
• A: 批准（Accountable）项目关键决策的批准人
• S：支持（Supportive）为项目完成提供支持的人
• C: 咨询（Consulted）为项目提供数据或信息的人
• I：知情（Informed）需要了解项目相关情况的人

QA常见问题

• 有规范执行效果不好
  
  • Q:推动别人做事，心里负担大。
  • A:需要给相关QA进行规范的宣导和心理建设（项目规范是对事不对人的，正适合纠正不规范行为。规范是保障质量的必要手段，严格执行规范是在降低线上风险，本质上是在帮助协同方，不应该也没必要存在心理压力和负担）
  • Q:为了避免麻烦，因为出现不符合预期的情况时，按规范执行通常需要执行额外的动作，比如重新提测和验收、频繁周知、规范宣导等
  • A:需要宣导规范在效率提升方面的意义（单独一个Case，规范也许会降低效率，但长远看，规范确保事情正确的发生，既保质又提效，且规范可以传承，反复使用）。另外可以看下非预期情况下QA额外付出的成本是否有优化的空间
• 做测试而不是做质量保障
  
  • 测试是一种被动方法，它通过多种检测和调查技术来找到潜藏着产品中的缺陷，作为开发工作完成后的验证或校验工作，这种情况较低效
  • 质量保障是一种主动方法，它通过测试左移，将测试活动构建于整个业务流程过程中，预防为主，防治结合，通过体系化手段提升过程质量和交付质量

客服常见问题

• 充当传话筒
  
  • 产品功能熟悉
    
    • 有新功能上线时，提前同步客服人员进行学习和熟悉，针对可能产生客诉的地方进行预演和话术应对；
    • 由于客服人员流动性强，应将产品功能操作手册及相关话术沉淀狭隘，用于定期的培训。
  • 问题排查：
    
    • 提供给客服人员对基本功能或问题的排查步骤，或提供一些系统和工具供其自助使用。

六、质量文化建设

文化是组织成员表现出来的共同的信念、价值观、态度、制度和行为模式。

文化不是纸面上写了什么，喊了什么口号，而是大家信仰什么，比如日常如何思考、如何做事

为什么要建立质量文化？

在大多数质量保障体系推行过程中更多关注的是可见的质量标准、要求、操作程序等，这些内容给人的感觉是“组织要求我做好质量”，而忽略了不可见的质量意识、质量行为等精神层面的东西，这些内容给人的感觉是“我要为组织做好质量”，是主动的、自发的。

如何推行质量文化建设？

• 领导重视。只有上行才能下效
• 激励制度
• 文化触达：
  
  • 会议中宣导质量相关建设；
  • 针对质量方面的GoodCase 和 BadCase进行信息触达，比如业务内部博客、阶段性的质量报告等

• • 阶段性的质量报告等