质量不止测试

Posted 2022-02-03 sysu_lluozh

从软件开发的整个生命周期关注：

• 需要左移：关注业务的真正价值，以业务价值驱动开发和测试
• 需要右移：关注和利用生产环境的数据和信息，对线上问题深入分析，以优化和改进上线前的开发和测试工作
• 需要关注整个交付过程：关注计划安排、团队协作

一、用业务价值驱动测试

业务价值可以简单理解为：

• 帮助企业盈利
• 满足企业业务发展要求
• 带来业务价值的产品需要满足用户需求、让用户使用方便

1.1 测试从哪些维度关注业务价值

• 终端用户角度出发

不能简单套用用例设计方法去机械地进行，而是要考虑用户可能的行为习惯、使用场景

例：app手机自动锁屏后自动充值选项再次加载一遍

还需要考虑终端用户的体验，比如页面的布局、配色、易操作性、页面加载时间等都是在测试过程中需要考虑的因素。这样有助于交付一个增强用户体验

需求分析、特性启动、用户故事评审、用例设计、故事验收和故事测试，都可以体现从终端用户角度考虑都价值

• 以业务为重点的测试

业务流程的合理性、流畅性和完整性，这就要求能够真正理解企业的业务，以业务为重点来测试

例：并未提供购物车功能，每次购物都需要搜索商品后下单

• 映射业务影响

综合企业多个业务来看业务的优先级，能够区分哪些是关键业务和外围业务，能理解每个业务对于企业的影响，给企业带来的价值

例：观看录播视频功能，制作视频不是当下关键业务，区分不同的优先级和策略

需要识别系统缺陷对业务带来的影响，包括可能影响到的用户数、具体的影响是什么、有没有可以绕过的方法不至于中断业务的开展

• 关联业务指标

在度量项目/产品的测试或质量时，不能仅局限于项目/产品范围，要跟企业的业务指标相关联，跟踪、量化测试活动对业务指标的影响

测试需要基于如何快速将产品投递到市场的战略，尽快让企业能够借助产品盈利

1.2 业务价值驱动的测试跟传统测试的对比

在以下几个维度的关注点不同：

1.3 如何阐明业务价值

业务价值可能比较抽象，跟具体的测试活动对应起来更是有难度

一个比较通用的流程如下图：

1.4 优化业务价值的测试实践

业务价值有效传递给团队，那么就需要在测试实践中关注业务价值，从而帮助优化业务价值

测试实践帮助优化业务价值如下：

• 共创测试方案

测试方案在创建之前，需要跟业务人员沟通清楚对应功能特性的业务目标、业务价值，需要跟开发人员沟通相应功能模块的技术风险，基于风险的测试才是最能体现价值的

• 测试左移

测试左移的目的是为了更早的澄清和确定需求，确保团队清晰一致的理解需求的业务价值

• 测试右移

利用对终端用户行为和生产环境数据的分析。帮助优化业务、优化质量内建过程，提高交付软件的质量

• 精益测试

精益测试要求测试能够做到恰到好处，减少浪费，从而加速软件开发流程，加速交付

• 渐进式的自动化测试

自动化测试要随着软件开发的进度渐进式的增加，不是等功能开发完成再来写，可以提高投资回报率(ROI)

• 测试资产的管理和复用

尽量复用原有的测试资产，不要重复造轮子

• 增强测试技术

采用智能测试技术和分析技术，提高测试的精准度和有效性

• 缺陷预防

利用对缺陷模式对分析，在软件开发生命周期每个环节更好对做相应的测试工作，帮忙有效的预防缺陷

• 持续改进

测试活动始终以目标驱动，实时度量，并持续改进

• 测试人员能力建设

加强测试人员对业务理解能力的培养，建立业务价值思维，提高业务敏感度

1.5 业务价值驱动型的测试人员

要做好业务价值驱动的测试，对测试人员的要求：

• 改变认知
• 领域知识
• 分析性思维
• 沟通和表达能力

1.6 小结

以业务价值驱动的测试，主要是思维方式的转变。各个环节要加强对业务对关注，将业务价值融入测试流程中，帮忙团队达成对业务价值对清晰理解，以实现真正对质量内建

二、QA在生产环境做什么

2.1 一个生产环境bug的应对策略

遇到线上一个非常严重且昂贵的bug时，做为QA的解决办法：

• 瀑布式QA流程

瀑布式软件开发模式下，测试是计划驱动的，基本是根据需求文档进行验证，测试的目的是找到尽可能多的bug

对于线上bug通常的办法是加强在测试阶段的测试保证，除了验证系统功能跟需求文档的一致性外，可以增加一些ad hoc测试，确保发布到生产环境的系统尽量的稳定

• 敏捷QA流程

敏捷测试提倡尽早测试、频繁测试，QA要从需求阶段就开始介入，参与从需求到发布的整个生命周期中各个阶段

对于线上bug处理方式无非就是加强上线前各个阶段的测试，提高发布到生产环境的产品质量

除此之外，还有什么处理办法呢？

上面两种开发模式，QA的重点都是放在发布前的预生产环境的质量保障上，而较少考虑生产环境的系统质量。QA角色逐渐转变到需要分析软件产品在生产环境下的质量

这需要引入产品系统的监控，制定检测紧急错误的警报条件，持续质量问题的确定以及找出在生产环境下使用的度量以保证这种方式可行

2.2 生产环境的特点

分析一下生产环境有哪些特点：

1. 真实、不可破坏

   不可随意在生产环境做测试，尤其是破坏性的测试

2. 基础设施差异

   比预生产环境要复杂和健全的基础设施，可能会出现预生产环境不能预测到的缺陷和异常

3. 系统复杂度

   多个不同的系统继承，系统复杂性比预生产环境高很多

4. 数据复杂度

   通常不是一个数量级的数据，所以更容易引发性能问题、或者一些复杂的数据组合导致的问题

5. 用户行为千奇百怪

   生产环境的用户分布广泛，使用习惯各种各样，某些使用行为可能产生意想不到的问题

6. 访问受限

   生产环境对安全和稳定性要求更高，对于QA的访问受限导致对于生产环境的一些缺陷排除不便

7. 真实的用户反馈

   真实用户在生产环境上的使用可以提出一些真实而重要的反馈，但是开发团队往往不能直接接触终端用户

生产环境的这些特点决定了QA在生产环境并不是想做什么就能做到什么，原来预生产环境那套质量保障理论和方法都行不通

2.3 QA在生产环境可以做什么

要实现生产环境下的QA，有以下三个方向

1. 直接在生产环境测试

不是说不能随便去操作生产环境下的系统进行测试么？确实不能像在测试环境那样测试，有一些限制和特定的技术采用

• 对于只读操作和可隔离特性的测试

  在不影响真实用户体验的情况下，对某些功能进行只读操作，选择用户频率较低的时段进行

  对于某些特定的特性，如果方便隔离可以在生产环境利用独立的测试数据对其进行测试

• 蓝绿部署

  通过运行两个相同的生产环境”蓝环境”和”绿环境”来减少停机时间和风险的技术，虽然不算是真正意义的直接在生产环境，但是也是典型的实践之一

• 金丝雀发布

  常说的灰度发布，只有一套服务器，通过先部署新版本到其中部分服务器，并测试验证，没问题再推广部署到更多服务器的发布流程

1. 监控预警

通过监控的方式获取需要的信息，对异常情况进行预警：

• 日志

  日志就像飞机上的黑匣子，可以记录系统运行的各种信息，包括错误、异常和失败等。一旦程序出现问题，记录的这些信息可以用来分析问题的原因，同时可以利用记录的日志设置好预警，提前检测系统可能出现的问题

  生产环境下日志提供的监控和预警信息，有利于：

  • 阻止不良后果，避免大的损失
  • 发现潜在的性能问题
  • 指导预生产环境的测试

• 网站分析工具

  网站分析工具根据工具不同记录信息有所差别，但基本上记录的信息如：

  • 用户使用的操作系统，浏览器等信息
  • 用户行为习惯，包括使用的时间、关键路径、关键业务流程
  • 用户所在地区、语言等区域信息
  • 用户访问量，请求的响应时间，网站性能

• 用户反馈

  为了更好的利用用户反馈问题，需要一个严格的Triage的过程，对所有反馈进行分类并相应处理。用户反馈可以总结为下面几类：

  • 缺陷

    根据优先级和严重程度，安排相应对修复计划并对其进行修复，同时需要对修复的缺陷增加(自动化)测试

    对于概率性的缺陷，根因可能隐藏比较深，可以添加日志对相关功能进行监控和预警，利用日志协助找到问题根因并进行修复

  • 抱怨

    由于行为习惯、网络环境等差异，总会有各种抱怨，一般以非功能性对问题居多，比如易用性、性能、可维护性、可扩展性等。当然也可能是某个功能设计的不能满足真实的用户需求

    需要对所有抱怨进行分类，确定是非功能缺陷还是新的需求

  • 建议

    一般用户很难提到好的建议，要想收集到有价值的信息，需要提前设计好问卷进行调查，有针对性的去收集

    常用来收集用户反馈的实践有：

    • Beta测试

      很多有前瞻性的网站或应用会发布新功能给特定用户组(Beta用户)，收集用户使用新功能的统计数据

    • AB测试

      同时发布两个不同版本的系统到生产环境，并将用户引导到两个版本，统计使用每个版本的用户数据

    • 观测的需求

      发布一个简单的功能，或发布一个MVP版本，观察用户使用情况，从而引出并收集到用户的真实需求

2.4 生产环境下QA的特点

1. 不同于预生产环境的QA

   不是简单的去测试生产环境的系统，而是通过设置监控条件，收集用户使用系统的反馈，对反馈进行分析并改进

   QA在整个过程中主要充当分析者和协调者对角色：

   • 跟开发人员一起讨论监控标准，把日志标准化的要求融入到软件开发流程中，确保日志能够记录到真正需要记录的信息
   • 跟运维团队一起分析收集到的统计数据，指导和优化各个阶段的测试，以预防和减少系统在生产环境下的缺陷
   • 跟业务分析人员一起分析和梳理从生产环境收集到的需求相关的反馈，提炼出合理的需求，优化业务价值

2. 不能独立存在
   生产环境下的QA所设置的监控标准是根据系统的行为特点和在预生产环境下的表现来定义的，生产环境下各项反馈的分析结果反过来又影响着预生产环境的QA过程，而且这两者是相辅相成的

3. 有别于运维人员的工作
   QA有着独特的思维模式和视角，能够帮助更好的分析生产环境下收集到的各种反馈，并且结合对于系统的了解，能够将这些反馈更好的应用到日常的开发工作中

2.5 生产环境下QA在项目中的实践

生产环境下的QA在项目上的实践主要是三部分内容，如：

2.5.1 日志分析和优化

项目中使用的日志分析工具是Splunk，关于日志的分析和优化可以做如下工作：

• 分析生产环境的错误日志
  专人负责错误日志的分析，解决修复优先级高的问题

• 监控测试环境的错误日志
  把生产环境错误日志的分析方法应用于测试环境，尽量把环境无关由功能引起的错误找出来尽早修复

• 利用日志监控不同功能的性能
  在Splunk中设置有专门的统计和监控系统性能的Dashboard，定期拿出潜在的存在性能问题的功能模块

• 日志记录标准化
  通过对生产环境错误日志的分析，发现日志记录存在如下问题

  1. 存储位置不统一，造成分析成本增加
  2. 记录格式不一致，导致排查错误日志工作增加难度
  3. 日志级别定义混乱，导致非错误级别日志记成错误日志

2.5.2 Google Analytics数据分析

用来统计网站使用情况的工具

• 操作系统和浏览器使用情况分析
• 用户真实行为分析，及时调整测试根据
• 提炼关键业务场景，增加测试覆盖
• 发现用户较少使用的功能，优化业务流程
• 分析用户地区分布和使用时间段分布，合理安排定时任务运行实践
• 监控系统性能变化趋势，规避性能风险
• 确保GA能够统计到所有需要统计的功能

2.5.3 用户反馈的收集和分析

不能直接接触到系统终端用户，接受反馈的是客户的Ops团队，可以通过以下几个途径去协助分析和梳理用户反馈：

• 跟Ops和业务的定期沟通会议
  QA定期跟客户的Ops和业务人员沟通，了解用户对于现有系统的反馈，找出测试中需要重视的功能特性

• 培训Ops人员
  收集到的用户反馈进行分析和分类，将分析结果跟现有的测试覆盖情况进行对比，找出测试过程的薄弱环节

• 调查和跟踪生产环境bug
  针对生产环境bug负责跟踪修复和验证

• 协助梳理业务需求
  收集用户第一手需求信息

2.6 总结

• QA将工作范围扩大到从需求到生产环境，增加更多的反馈来源
• 提供更多评估和提高系统质量的选项
• 必须先做好预生产环境的质量保障，并适用于持续交付实践的组织

三、深入分析生产环境上的缺陷

利用生产环境下的缺陷数据，对其进行深入分析，根据分析的结果来指导软件开发过程

3.1 利用5WHY法分析缺陷

• 5Why分析法

  对一个问题点连续以5个为什么来提问，对其进行深入分析

• 分析根因

  缺陷深入分析的第一步就是找到引起缺陷的根本原因，其原因有以下这些方面：

  • 需求缺失或者需求不清晰
  • 设计问题
  • 编码错误
  • 测试不足
  • 环境相关(硬件、软件、配置等)

• 定位阶段

  找到根因后，基于软件开发生命周期同样利用5Why分析法，从而定位引发问题的薄弱环节，找出是哪个环节

3.2 缺陷分析是为了更好地预防缺陷

分析缺陷的根因，找出引起缺陷的薄弱环节，这不是目标。在找出根因和薄弱环节之后，更关键的是进一步确定改进措施、定义改进项

改进项的执行需要把职责落实到人，需要有人来负责这个事情的发生，并且后续还需要持续检查改进项的执行情况，以及通过统计缺陷重复发生情况来验证改进项的适用性，这样就可以较为有效地减少同类问题再次发生的可能性，帮助做到缺陷预防

通过缺陷分析来预防缺陷只是实践之一，还有非常关键的正向实践不可忽视，比如：测试左移、每个环节的持续测试等

四、大规模团队QA的合作

大团队中，QA都被分散在每个特性小组，如果没有及时沟通，将会造成信息不对称，要补救所花费的额外经历是比较大的

另一方面，QA在特性小组基本都是单兵作战，沟通协作不够的话对于自身的成长也不是很有利

在项目组内部成立QA社区

1. 知识共享

   • 集体参加用户故事的启动和验收

   • 集体参加各种的特性启动会议

   • 定期沟通例会

     每周一次的定期沟通例会，要求所有QA务必参加。例会上每个QA给大家介绍自己组内的特性上下文，更新状态，把遇到的困难、可能的风险等拿出来跟大家一起讨论，找到解决方案或规避举措

     对一些需要QA社区一起完成的事情，找到专人负责推进，下次例会的时候检查执行情况

   • QA内部功能演示

     共享组内新开发功能特性。不仅锻炼了QA做好功能演示的能力，同时也给其他小组的QA共享了业务信息

2. 能力共建

   QA社区还有一个更重要的任务是QA的能力建设，主要有以下几个方面：

   • 明确目标

     结合技术发展趋势，确定季度或者半年的能力提升重点

   • 项目实践为基础

     以满足项目需求为主，在做好项目质量改进的过程中，提升自己的能力

   • 技术调研及分享

     针对某个新实践的相关方案和技术调研，对于一些趋势性的技术的了解和学习

   • 社区外的连接

     需要加强跟项目上其他角色的沟通和讨论，定期开放例会邀请非QA角色参加，把QA社区内的成功在项目级别上进行分享

五、团队为质量负责

大家对质量的理解不一致，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责

5.1 质量是什么

1. 外部质量

   外部质量就是软件呈现给用户的外部形态，是否有缺陷、是否稳定、是否有性能问题等，也就是最终用户在软件使用过程中的各种体验，包括软件可学习、高效、不易出错、有难忘等特性，都属于外部质量范畴

2. 内部质量

   内部质量就是指软件系统内部的质量状态，包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性。内部质量主要从开发人员角度来看，也称为代码质量

   内部质量不会被最终用户感知到，容易被忽略，但是内部质量会影响外部质量

3. 内建质量

   质量不能被检测出来，要提高软件产品的内、外部质量，都需要通过质量内建的方式，做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试：

   • 自动化测试

     从多个层次(单元、组建、端到端等) 写自动化测试，并将其做为部署流水线的一部分来执行，每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时，都需要执行这些测试

   • 手动测试

     手动测试也是很关键的部分，如需求验证、演示、可用性测试和探索性测试等，在整个项目过程中都应该持之以恒的做下去

   质量内建不仅要考虑功能测试，对于非功能测试同样是需要做到内建的，比如安全内建、持续性能测试等

   质量内建虽然和内、外部质量不在一个维度，但也是体现质量好坏的一个方面，因此也要把它做为衡量质量的一个维度，测试或使用过程中发现的缺陷数量可以做为度量标准

   可以从三个维度度量软件产品的质量：

   • 外部质量：用户反馈、用户报告的问题数量
   • 内部质量：代码评审、结对编程、静态代码质量检查
   • 内建质量：测试环境、生产环境缺陷

5.2 容易忽视的质量

广义的质量其实包括软件产品交付流程中的方方面面

下面列举一些项目对质量关注欠缺的内容：

• 需求分析过程仓促，或者参与人员角色单一，导致业务上下文了解不够，关键场景缺乏考虑
• 忙于交付更多的feature，忽略了对代码质量的关注
• 没有足够的测试覆盖，导致新增代码容易破坏已有功能
• 大面积的重构发生在release前夕，无法全面回归，带来很大的风险
• 项目初期只考虑少量用户的场景，功能难以扩展，导致严重性能瓶颈
• 技术选型失误，开发困难
• 第三方组件评估不够充分
• 缺乏对异常情况的处理，测试过程缺乏探索，只覆盖到主干路径，边角case可能引起问题
• 只考虑当前功能模块，缺乏更广范围的考虑
• 对线上环节不了解，而且没有足够对日志信息记录，线上问题难以定位

5.3 谁该为质量负责

• BA：业务分析师

  BA视角的质量，主要是需求分析的准确性和清晰度，帮助团队对需求有一致对认识，从用户旅程的角度关注给最终用户的产品是否真的带来了价值

• Dev：开发人员

  Dev视角的质量不仅是按照需求实现功能的开发，还要把功能高效交付给最终用户

• QA：质量分析师

  唯一一个全流程都要参与的角色，从需求到上线后的支持，每个环节都不可缺

  清晰理解需求、制定质量保障策略、做好各个环节的测试工作(手动、自动化、探索式、跨功能、非功能测试以及生产环节的QA等)、关注项目整体质量状态、及时反馈质量信息给团队、识别业务风险和优先级、帮助优化业务价值

5.4 敏捷团队是否需要专职QA

没必要纠结是否需要专职QA，因为QA在团队所需要做的事情始终都是要做的，不管是不是有专职QA。而且术业有专攻，肯定是专业的QA会做的更好。如果没有专职QA，对团队其他角色的要求就高很多，不是每个团队都可以做到

5.5 整体对质量负责的团队有哪些特征

清晰的质量目标、注意容易忽视的质量、团队成员的充分合作。能够整体对质量负责的团队有如下特征

• 信息共享
• 反馈机制
• 回顾会议
• 仪式感
• 团队活动

5.6 责任流程模型

责任流程模型，从上到下需要经历几种不同的心理状态：否认、指责、辩解、羞愧、放弃、义务，然后才能到达最上层的责任，才能赔偿责任感

5.7 培养责任感的三把钥匙

培养责任感的三把钥匙：动机、意识、面对

5.8 小结

质量不仅是某个角色的事情，团队每个成员都撇不开质量这个话题

六、职业发展之路

测试人员的职业发展，与整个行业和领域趋势都脱不开的关系。软件测试领域新的关键趋势主要体现在以下几个方面：

• AI的发展与软件测试
• 敏捷与DevOps
• 自动化测试
• 环境与数据
• 成本与效能

在这样的趋势下，测试人员的职业发展之路有什么变化呢？测试人员的技术发展方向有哪些呢？

6.1 技术方向

基于前面提到的新趋势，测试人员的职责由单一的测试软件系统变得更加多样化，因此测试人员的职业发展技术方向有：

1. 敏捷测试专家
   • 领域测试能力(IoT、智能服务、区块链等)
   • 自动化测试能力(测试分层的思想、接口测试、单元测试、持续集成)
   • 沟通协调能力
2. 高级测试开发专家
   • 高级自动化测试
   • 白盒测试
   • 开发和平台构建能力
   • AI应用的基础算法应用
3. 专项测试专家
   • 安全测试
   • 性能测试
   • 测试数据和测试环境的管理
4. QAOps专家
   • 基础设施相关技术
   • 日志管理、监控、分析技术
   • 用户行为分析
   • 生产环境信息优化软件研发

6.2 管理方向

测试人员直接相关的管理岗位大体如下：

1. 测试组长
   • 任务优先级识别能力
   • 培养团队成员的能力
   • 沟通协调能力
2. 测试经理
   • 技术洞察力
   • 风险识别能力
   • 培养团队成员的能力
   • 沟通协调能力
3. 项目测试负责人
   • 技术洞察力
   • 风险识别能力
   • 沟通协调能力
4. 测试总监

6.3 易转型方向

根据测试人员的职业特点，以下两个岗位是比较适合转型的方向：

1. 项目经理
2. 产品经理

6.4 三个转变

测试人员要培养技能，需要实现下面三个转变：

1. 对测试对认知

   测试活动不仅是验证系统功功能，可以更加多样化

   测试人员不是质量的把关着，好的质量意味着交付更多的价值，而不是没有缺陷这么简单

2. 对技术的关注

   要把视野扩展到软件开发过程中各个环节接触到的领域知识和不同类型的技术

3. 测试不可以独立存在

   需要跟不同的角色更多的沟通和合作

   测试人员对于系统所采用的技术架构、技术方案的设计思路都需要有所了解，从而更好的理解开发的工作、理解架构演进对于测试的了影响，更好的开展测试工作

七、团队转型

如何实现测试的顺利转型，已经成为备受关注的主题

7.1 转型给测试带来的挑战

转型让测试人员打散到研发团队，通常使得测试人员茫然无措，测试转型面临的挑战主要有：

• 归属感
• 职责定位
• 团队协作
• 能力建设

7.2 测试转型的道法术器

测试转型想要顺畅进行，要从以下几个层面去实现转变，称为测试转型的道法术器

• 测试转型之器

  工具实践层面：自动化回归测试的组织实践更优

• 测试转型之术

  流程策略层面：测试左移到需求分析阶段，并且全流程介入更优

• 测试转型之法

  组织沟通层面：测试开发融合的产品线的组织沟通方式更值得提倡

• 测试转型之道

  文化认知层面：关注交付价值的团队一定带来更大的价值交付

7.3 测试人员的能力提升

从组织角度和个人成长角度探讨

• 组织角度

  从组织的角度，测试负责人需要承担起测试人员能力建设的职责，可以从下面三个方面开展能力建设

  1. 构建测试胜任模型

     测试必备技能、进阶技能和高阶技能

  2. 测试人员梯队建设

     遵循知识→ 经验 → 能力的提升路径，鼓励测试人员

  

  1. 构建测试社区

• 个人成长角度

  当有明确的目标需要去解决某个问题的时候，学习的效率会加倍的提升，效果会更好。因此，找到提升的目标，以目标驱动去学习，从海量的知识里找到自己当下需要的部分，并且进行提炼加工，应用于实际工作中，这是最佳学习路径

  目标可以来自于三个方面：

  1. 项目需求

  项目可能正在转向微服务技术架构，需要针对性地开展微服务测试；项目可能需要加强自动化测试，需要自动化测试技能

  1. 技术趋势

  社区技术和目前前沿技术

  1. 领导者的建议

  作为领导者更清楚组织的发展需求，可以跟自己的领导去寻求建议，确定学习发展的目标