大连建设网中标公司,优化大师官方下载,wordpress滑动显示分类文章,磁力屋 最好用读完需要24分钟速读仅需 8 分钟00 引言1. 三个层次聊测试体系测试人员缺乏体系化思维#xff1f;新建产品团队或者新启项目#xff0c;如何搭建质量保障体系#xff1f;大家都接触过不计其数的测试、质量方面的文章或者培训课程#xff0c;内容不乏测试实践、技术相关… 读完需要24分钟速读仅需 8 分钟 00 引言1. 三个层次聊测试体系测试人员缺乏体系化思维新建产品团队或者新启项目如何搭建质量保障体系大家都接触过不计其数的测试、质量方面的文章或者培训课程内容不乏测试实践、技术相关但是却很难构建自己的测试体系。基于很多朋友类似的困惑结合本人多年的团队实践和咨询经验从基础、进阶和高级三个不同的层次来跟大家探讨测试体系化思维的构建。《构建测试的体系化思维基础篇》《构建测试的体系化思维进阶篇》本文《构建测试的体系化思维高级篇》待发布2. 基础篇内容回顾2022 年 1 月份发布了《构建测试的体系化思维基础篇》后文简称《基础篇》从测试的五个基本职责出发围绕这五个基本职责介绍了相应的实践活动和方法集。理解和澄清业务需求制定策略并设计测试实现和执行测试缺陷管理与分析质量反馈与风险识别3. 进阶篇内容概要本文为进阶篇将跳出测试从软件质量的角度来看体系化思维的构建。1从测试到质量跳出测试从质量维度来看测试的体系化建设。2质量保障与质量内建质量是产品与生俱来的质量内建才是保障质量的根本。3质量内建深入实践质量内建如何落地是大家最为关注的问题深入质量内建实践介绍供大家落地实践参考。 01 从测试到质量1. 为什么要从测试转变到质量在《基础篇》中提到的五个测试基本职责那是测试人员开展测试工作务必了解的方方面面是做好测试工作的基础。但是要做好软件产品的质量保障工作光从做好测试的角度考虑是远远不够的原因主要有两个方面软件质量不能通过测试来提高。著名质量管理专家戴明提到“质量没法检测出来软件产品开发出来后质量就已经在那了。”软件测试可以验证软件质量是否满足需求但是随着软件生态的复杂性和不确定性增加没有办法预知软件行为也就没法通过测试来验证软件质量的方方面面。因此测试是基本功但只关注测试是不够的。需要跳出测试将视野调整到软件开发全生命周期质量的角度关注质量的各个维度才能更好地建立体系化思维才能更好地做好软件产品的质量保障工作。在阅读后面内容之前我希望读者朋友们先花 10 秒钟思考以下问题问题跳出测试从软件质量的角度思考我们需要关注哪些方面这是一个老生常谈的问题答案似乎大家也都很清楚但现实中又是很容易被忽视、被误解的问题。2. 软件质量的定义在回答上面问题之前我们先来看看维基百科对软件质量的定义 ( https://en.wikipedia.org/wiki/Software_quality )。如下图所示维基百科对软件质量的定义包括两个方面软件功能质量基于功能需求规范看软件是否提供了相应的功能这是用户使用软件的角度是软件外部的质量。软件结构质量对支持功能需求交付的非功能需求的满足情况比如健壮性、可维护性等这是从软件内部结构来看是软件内部的质量。维基百科的这个定义跟咱平常提到的软件质量包含外部质量和内部质量是一致的。外部质量是从软件外部可感知的是从用户角度对软件感知到的使用质量内部质量则涉及到软件的内部形态包括技术架构和代码质量等是从团队开发人员的角度感知到的。相信大家对于外部质量好理解是用户角度能够感知到的质量。而内部质量往往很容易被忽视其实这也是因为人们普遍容易追求短期利益看不到内部质量给软件产品带来的长远影响这里想给大家看个非常熟悉的图以增强对内部质量的重视。不加整理的富含技术债的代码就如同图中杂乱无章缠绕在一起的电线严重影响着产品缺陷定位修复、后期功能扩展等。3. 容易忽视的质量影响因素理解了质量的定义在日常软件开发工作中有哪些因素是会影响到软件质量的呢其实影响的因素特别的多可能包括但不限于以下这些1需求分析过程仓促或者参与人员角色比较单一导致业务上下文了解不够关键场景缺乏考虑等2忙于交付更多的特性忽略了对代码质量的关注该重构的没有重构在原本不太健康的代码基础上继续增加更多的代码导致混乱筑起高高的技术债3没有足够的测试覆盖导致新增代码容易破坏已有功能4开发人员提交代码后就投入新代码的开发对所提交代码缺乏关注持续集成流水线上测试挂了不能及时修复可能影响后面的测试进度5大面积的重构发生在发布前夕无法全面回归带来很大的风险6项目初期只考虑少量用户的场景随着业务的发展系统功能难以扩展导致严重性能瓶颈7技术选型失误开发困难没有及时改进一错再错最后问题严重到无法弥补8第三方组件评估不够充分导致线上环境无法承载等9开发缺少对异常情况的处理测试过程缺乏探索只覆盖到主干路径边角用例可能引发问题10开发或者测试都只考虑当前功能模块缺乏更广范围的考虑11缺乏跨功能需求的关注导致严重的安全或者性能问题12对线上环境了解不够而且没有足够日志信息记录线上问题难以定位导致宕机时间过长13等更多…… 02 质量保障与质量内建1. 质量如何保障从质量维度来看体系化思维的构建而质量是产品与生俱来的做好软件产品的质量保障工作更为有效的方式就是要将质量构建到软件产品本身提高软件产品与生俱来的质量。这也就是质量内建Build Quality In的概念。这个还是太抽象为了更清楚的解释质量内建先来看两个概念暴露缺陷与预防缺陷。2. 暴露缺陷与预防缺陷“暴露缺陷”的概念众所周知就是软件所暴露出来的缺陷通常在测试或使用过程中被发现。如果能够全面统计一个软件产品的所有可能引起缺陷的地方我们可以说该软件存在缺陷的总量是一定的。当然现实情况是我们不可能全面考虑到所有的因素缺陷是很难穷尽的。如果这一定数量的缺陷中有一部分可以通过某些措施来预防那么软件在测试或最终用户使用过程中所暴露出来的缺陷数量就会减少这就是缺陷预防——减少暴露给用户的缺陷。软件开发过程是个持续递增的过程预防缺陷也不是一蹴而就的事情需要在整个软件开发过程持续的进行。当然尽早预防缺陷会更好这样可以显著减少缺陷修复的成本提高投入产出比。下图曲线非常清晰地展示了修复不同阶段暴露出来的缺陷所需成本的差异修复成本是随着软件开发周期显著增加的。3. 质量内建如何做将缺陷概念扩展为软件产品质量相关的所有问题那么做好了缺陷预防也就是做到了质量内建。前文提到过容易被忽视的质量影响因素要做好质量内建这些因素都是需要重点关注的。但是由于软件开发过程的复杂性要一次性做对所有事情、预防所有的缺陷是不可能的。因此质量内建并不是严格意义上的不能有任何缺陷暴露而是需要在软件开发生命周期中尽早地把事情做对并且通过持续的获取快速的反馈来纠偏。我们都知道那个有名的 PDCA 环也称“戴明环”将质量管理分为四个阶段即 Plan(计划)、Do(执行)、Check(检查) 和 Act(处理)。在质量管理活动中要求把各项工作按照作出计划、计划实施、检查实施效果然后将成功的纳入标准不成功的留待下一循环去解决。质量内建可以理解为在软件开发全生命周期中从需求到线上频繁地执行 PDCA 环小步前进持续反馈验证及时调整改进。如下图所示 03 质量内建深入实践前面主要从概念和理念层面介绍了质量和质量内建这些内容对构建体系化思维是至关重要的有助于拓宽视野形成全局观。但光有这些内容不够还得了解具体的落地实施方法。接下来就从质量内建相关实践来探讨质量内建在软件开发生命周期的落地实施方案。1. 质量内建的核心在介绍具体的质量内建实践之前还是需要从抽象层面来理解质量内建的核心其内容可以分为四个方面测试左移快速反馈测试右移全员参与1.1 测试左移传统软件开发会分成分析、设计、开发、测试、发布等几个相对独立的阶段而测试是其中发生在开发完成之后的一个阶段。测试左移是针对传统这种独立测试阶段来说的不再强调独立的测试阶段而是要将测试活动左移到软件开发生命周期的最早阶段最左边——需求阶段从需求阶段开始做好缺陷预防的工作。要特别提醒注意的是测试左移不是测试人员左移而是强调的测试活动左移左移到传统独立测试阶段左侧就叫左移不一定是左移到需求阶段。当然根据前面对质量内建的阐述理想情况下肯定是越左边越好。如果做不到彻底左移能移一步也是进步。测试人员的确需要左移参与相应的活动。但是如果测试人员参与需求阶段却没有起到澄清需求、验证需求有效性的作用那就不是有效的测试左移关键要看成效。不仅测试人员要左移开发等其他角色也需要左移。因为需求有效性的验证需要不同角色的经验需要来自不同视角的输入不同角色都有责任参与到每个环节的测试活动中来。只要能做到从需求阶段开始就有相应的测试活动不一定都是测试人员参与。这里强调的是测试活动要有哪个角色来做不是最关键的角色其实就是戴了一定帽子而已。我们知道有的团队是没有测试人员的但不代表这些团队没有测试活动。1.2 快速反馈快速反馈也就是频繁持续地反馈可以理解为一个持续测试的过程。通常快速反馈需要有自动化的支撑比如自动化测试、流水线上自动代码扫描等也可以是一些人工参与的实践环节比如手动测试、各类评审和验收等。通过这样的一些实践活动尽快地获取相应工作可能是需求分析、开发等的反馈根据反馈结果进行及时的修复、调整、或者优化。为了保障快速反馈/持续测试实践活动的有效开展通常需要增加质量门禁并确保质量门禁的严格执行。1.3 测试右移测试右移是跟测试左移对应的就是将测试活动从独立测试阶段右移到生产环境。但因为生产环境的特殊性测试右移又不是测试活动的简单右移而是通过一些实践活动获取生产环境下用户行为、日志等质量相关信息利用这些信息来给前期的需求、开发和测试工作提供反馈促进相应工作的优化改进以更好的做好质量内建。测试右移本身不能直接内建质量但是可以帮助更好地质量内建所以我认为测试右移也是质量内建不可或缺的核心内容之一。这部分的内容比较多之前有过详细的介绍此处不再赘述。欢迎参考文章《测试右移——生产环境下的 QA》阅读更为详细的内容。1.4 全员参与测试左移、快速反馈和测试右移都不是某个单一角色/人员可以做到的需要不同角色的不同技能和不同视角的输入质量人人有责需要全员参与并且能承担起质量职责才行。全员参与不仅是很多实践活动需要大家一起参与还有很重要的一点是团队内部需要有足够的沟通和信息共享。只有信息足够透明每个人都清楚质量目标、质量状态和风险才能真正发挥主人翁精神积极地参与才能发挥团队每个人最大的价值。一定要警惕团队“蘑菇种植”。这部分内容之前也有过非常多的分享欢迎参考《团队对质量负责“我”可以不负责》、《敏捷测试的指导性原则》、《说好的团队为质量负责呢》等文章。2. 质量内建典型实践综合来看质量内建的典型实践通常有但不限于下图这些不管是传统开发模式还是敏捷迭代式开发模式软件开发生命周期都会有需求分析、开发实现和线上使用三个阶段只是敏捷模式下需求和开发是迭代式进行在时间上不是界限清晰的阶段。这里为了描述方便暂且将这些实践分成三个阶段来描述事实上实践活动跟阶段也不是关联非常紧密的遵循测试左移、快速反馈、测试右移和全员参与这几个核心思想才是关键所在。2.1 需求分析这里强调四个我认为跟需求分析密切相关的典型质量内建实践分别是需求澄清、行为驱动开发BDD、实例化需求SbE和需求评审。需求澄清需求的理解和澄清作为测试基本职责之一在《基础篇》中有较为详细的介绍请移步参考。不过在这里需要补充的是不仅测试要参与需求澄清还需要其他相应的角色协同参与比如开发人员、技术负责人、技术架构师等。行为驱动开发BDD关于 BDD很多人误认为是一种测试方法但其实 BDD 主要是为了三方更好地对需求达成一致认识只不过通过 BDD 方式产生的需求能够很好地指导自动化测试的开展。更多详情请参考我之前的文章《说起 BDD你会想到什么》。实例化需求SbESbE 的核心思想跟 BDD 类似但强调了一点要将需求描述通过实例来说明以更好地发现漏掉的需求让需求更完整、更容易被多方理解和澄清。需求评审需要开发和测试跟业务分析人员一起讨论确认需求可能是正式的会议针对某个特性大块需求的评审也可以是针对单个需求条目或敏捷用户故事进行线下评审。如果前期需求澄清过程中对需求的讨论已经比较透彻这里的评审就会比较轻量级由测试人员开发按需参与自行安排时间评审即可。这些实践都是为了更好地在需求分析阶段让团队对需求达成一致的理解确保需求的质量减少后期因需求问题带来的返工和浪费。2.2 开发实现需求源头的质量控制好了接下来就是在开发实现阶段持续地通过快速反馈的方式确保每一步工作的质量下面的实践都是为此服务的技术方案讨论不是要介绍这个实践怎么做而是要提醒在做技术方案讨论的时候测试要尽量参与。一方面测试清楚了解技术方案才能更好地设计相应的测试策略更完备的进行测试另一方面测试基于自己对系统的了解可以给技术方案的讨论提供输入比如系统重点需要考虑和关注的问题等。可能有人会觉得测试技术水平跟不上参与价值不大但我想说的是不参与就不会有进步只要参与了就一定会有收获从长期来看不管是对个人还是对团队整体都是非常有价值的。需求条目启动也叫用户故事启动Story kickoff、开卡等。对于单个可开发需求在开发人员要开始编码前进行的再次澄清和确认主要是确认其中的验收标准是否不够完备、是否大家都理解一致了。形式要求尽量轻量级在开发人员电脑前完成即可需要业务分析、开发和测试共同参与时间一般不要超过 15 分钟。需求条目验收跟启动是配对的也叫用户故事验收Desk check/Shoulder check/Story signoff、结卡/验卡等。同样在开发机器前面完成一般由开发将功能演示给业务分析和测试人员大家确认需求中的正向路径是否都已经开发实现了。更多详情可参考文章《高效用户故事验收》。测试用例设计在《基础篇》有对测试用例设计作详细的介绍从质量内建的角度来看主要是想说测试用例设计尽量早点做而且对于用例设计的形式可以相对灵活些列举需要关注的测试点才是关键从快速反馈的角度不建议过于注重形式和流程。测试驱动开发TDD常见的有单元测试驱动开发UTDD和验收测试驱动开发ATDD通过先写测试的方式驱动设计的完备性。Thoughtworks 同事刘冉老师有多篇关于 TDD 的文章请移步他的网站「刘冉的思辨悟 ( http://liuranthinking.com )」查阅参考。代码评审Code review也叫代码回顾。有团队成员聚集在一起做回顾的也有独立线下评审的模式。Thoughtworks 同事伍斌道长的文章《Code Review: 超越“审、查、评”的代码回顾》有关于 code review 非常详细的讲解请移步参考。自动化回归测试根据测试分层理论自动化测试可能包括单元测试、接口集成测试和端到端测试。通常单元测试是开发人员编写而接口集成测试和端到端集成测试可以开发和测试协作完成。关于自动化测试相关文章比比皆是这里推荐如下内容供参考《精益测试》《微服务测试的思考与实践》《测试金字塔不是银弹》《一个遗留系统自动化测试的七年之痒》Thoughtworks 洞见自动化测试文集 ( https://insights.thoughtworks.cn/?s%25E8%2587%25AA%25E5%258A%25A8%25E5%258C%2596%25E6%25B5%258B%25E8%25AF%2595 )刘冉老师网站的自动化测试文集 ( http://liuranthinking.com/automatedtesting/ )单元测试评审单元测试评审一般发生在需求条目验收环节详情参考文章《QA 评审底层测试的价值》。持续集成持续集成CI概念大家并不陌生但是有效实施却不是那么容易。常见的反例有光有持续集成流水线但是流水线上啥也没有没有代码扫描、没有自动化测试、没有质量门禁流水线有接入代码扫描但是扫描出问题没有及时修复自动化测试没有在流水线上频繁执行或者执行失败不能及时修复代码没有频繁提交……更多内容推荐参考 Thoughtworks 洞见文章《持续集成理论和实践的新进展》和《对于持续集成实践的常见问题的解答》。自动化/持续部署自动化部署在提高效率的同时还可以减少手工部署引入的问题让部署能够更频繁更持续地发生。这部分内容可以参考 Thoughtworks 洞见文章《持续集成和交付流水线的反模式》。技术债管理还记得前面那个布满杂乱无章电线的图吗软件开发过程中引入的技术债如果没有得到有效管理软件内部也会乱成那个样子。关于技术债管理推荐 Thoughtworks 同事麻广广的文章《软件架构治理之技术债的前世今生》。探索式测试探索式测试有助于发现一些潜在的不易察觉的缺陷是非常推荐的一个实践。具体做法和建议在《基础篇》中对探索式测试有详细介绍。客户验收英文叫 Showcase就是给客户、业务方演示开发实现的特性。Showcase 也有很多常见误区请移步文章《敏捷实践 Showcase 的七宗罪》。缺陷分析缺陷分析对质量内建的帮助主要是通过分析找出问题根因在后续的开发工作中提前避免以预防更多的缺陷暴露。如何做好缺陷管理和分析请参考下列文章《软件缺陷的有效管理》《缺陷分析如何帮助质量内建》《都是脏数据惹的祸》质量状态报告和质量风险分析请参考《基础篇》中“测试职责之五质量反馈与风险识别”部分的介绍。回顾会议回顾会议通过总结和分析过去一段时间团队发生的事情是关于团队整体健康状态的。我之所以将回顾会议列为质量内建的典型实践是因为咱们前面讨论过了影响质量的因素涉及到方方面面自然就跟团队的健康有着很大的关系。利用好回顾会议这个实践及时发现问题并采取对应的改进举措将是非常有价值的。关于回顾会议的高效开展可以参考 Thoughtworks 洞见文章《高效回顾会议的七步议程》。2.3 线上使用软件产品发布到线上质量内建相关实践就都是跟测试右移有关的这是一个很大的主题之前有过系列文章的介绍相关实践可以参考下列文章《测试右移——生产环境下的 QA》《测试右移之日志收集与监控》《测试右移QA 与 Ops 通力合作打造反脆弱的软件系统》 04 写在最后测试基本职责是测试人员必备之基础技能但测试的体系化思维构建不能仅局限于测试工作本身当我们跳出测试从质量的角度来看又是另一番景象。希望本《进阶篇》能够帮助各位测试同仁从质量的角度拓宽视野增加大局观让质量保障工作做得更顺畅。
