敏捷测试浅谈

发表于 更新于 分类于
本文字数： 2.8k 阅读时长 ≈ 9 分钟
全是套路。

下周要给同事分享关于敏捷测试的session，简单介绍敏捷测试的概念和实践，虽然没有多少人听😂，不过准备的过程中自己还是挺有收获的，所以先用这篇博客总结下。

是什么：敏捷测试的道与术

首先，我们知道，「敏捷测试」是一种项目实践，说白了就是方法，即「术」；那在谈论「术」之前，我们应当知道它所遵循的方法论和道理，即「道」，很明显，从字面上就可以看出，这个「道」就是「敏捷」。
所以我们得先搞清楚「敏捷」这个概念是怎么来的，又是怎么衍生出现在的敏捷开发和敏捷测试的。

Scrum&极限编程(80-90s)

所谓「实践出真知」，「道」也是从「术」中来的，在敏捷这个概念出现之前，已经有一些早期的敏捷实践在流行，比如 Scrum 和 极限编程 。

  • Scrum ：80s-90s诞生，一种敏捷项目的管理方法，提出了迭代、站会、IPM、Retro、User Story这些实践，并引入PO(Product Owner)、SM(Scrum Master)角色。
  • 极限编程：全称为Extreme Programming，缩写为XP，80s后期诞生，一种软件开发方法，对测试高度重视，提出了测试驱动开发(TDD)、结对编程、重构、持续集成等实践。

Agile(2001)

因势所趋，基于以上实践，有17个志同道合的人聚在一起，开了一个研讨会，根据这些实践的共性，比如轻量级、快速迭代等等，决定使用「敏捷」(即Agile)作为这些共性的总称，并提出了部分 敏捷宣言与原则 ，后来在Wiki上将其开发完善，「敏捷」这个概念及其代表的方法论就此诞生。
再然后，更多有相似想法的人又形成了 敏捷联盟 ，是一个促进和研究敏捷方法的非营利组织。

Scrum&敏捷开发&敏捷测试(Now)

即然有了方法论，那更多的敏捷实践也就应运而生了，比如「敏捷开发」和「敏捷测试」。

  • 敏捷开发 ：事实上，上文中的「极限编程」就是现在「敏捷开发」的前身，「敏捷开发」在「极限编程」的基础上进行了完善和扩充，引入了更多开发实践，我并不是开发，所以具体又多了哪些实践就无法娓娓道来了。
  • 敏捷测试：在「极限编程」中，只提出了单元测试和验收测试的实践，不够满足测试需求，所以之后又根据Scrum的项目管理模式，尝试将测试深入到软件开发的每个步骤，进而提出了更多优秀的测试实践，具体是什么实践，下文中会详细介绍。

到这里，敏捷测试的概念已经很明显了： 敏捷测试就是遵循敏捷方法论的测试实践 ，其实这个定义也可以通用到敏捷开发身上。

现在的敏捷项目，多是以Scrum作为项目管理方式，开启迭代、组织每日站会、迭代计划等会议，并以用户故事卡为交付单位进行日常开发工作，然后用「敏捷开发」和「敏捷测试」的实践保证项目交付效率和产品质量，需要注意的是，「敏捷开发」和「敏捷测试」并不能独立于彼此存在，两者是相互依赖、相辅相成的关系，所以脱离「敏捷开发」来谈「敏捷测试」，无异于纸上谈兵，是完全行不通的。

为什么：敏捷测试与传统软件测试的区别

之前「有幸」参加过几次传统软件项目，包括毕业前实习的时候也是，在我看来他们有以下区别：

传统测试与敏捷测试

不难看出，两者的核心不同，传统测试以「质量检测」为核心，目标是为了发现更多的bug；敏捷测试则以「质量内建」为核心，目标在于预防缺陷：

质量内建

软件的缺陷暴露的越晚，修复的成本就越高；前期对缺陷预防的少，后期发现的缺陷就会多；前期做好了缺陷预防，后面暴露的缺陷就会减少。因此，我们需要提前预防缺陷，而不是等开发完成了才发现很多的问题，这就是 「质量内建」 。

怎么做：敏捷测试策略

俗话说「先把事情做对，再把事情做好。」，怎样才能做好敏捷测试呢？答案是通过敏捷测试策略。
敏捷测试策略 是一系列敏捷测试实(tao)践(lu)的集合，在项目刚开始的Inception阶段，由QA主导，团队成员一起讨论输出，输出结果可以用任意的方式记录，文档、脑图都行，关键是要在团队内达成共识。

之前也有写过 一篇文章 来介绍测试策略，里面列出了一些实践，但没有按照敏捷项目的流程进行分类，事实上，所有的敏捷测试实践都可以按照引入时间的不同分为三类：测试左移、持续测试、测试右移。

测试左移

测试左移 是说测试在项目开始早期介入(其实做敏捷测试策略这个实践本身，就已经算是测试左移了)，可以是需求分析阶段，也可以是更早的inception阶段。

左移的测试人员可以做的事情有：和团队一起挖掘需求、分析需求、澄清需求、评审需求、参与技术方案讨论等，主要目的是利用测试人员独有的视角和对系统的了解，在各个环节进行必要的输入，确保团队对于需求理解的一致性，确保团队能够做正确的事情。

以下是在此阶段可以引入的测试实践。

环境策略

所谓「打工人欲善其事，必先利其器」。

稳定的环境是高效开发和测试的先决条件，所以在项目开始开发之前就应该配置好各种环境以及流水线等基础设施，比如：

  • DEV环境：Dev自测和联调使用。
  • QA环境：QA日常测试使用。
  • UAT环境：用户验收测试。
  • Staging环境：模拟的Prod环境，有时也用UAT环境代替。
  • 其他环境：按照项目开发/测试需求准备安全环境、性能环境等等。
  • 搭建CI：代码持续集成/部署，保证产品稳定交付。

测试四象限

利用测试四象限，可以在项目开始前期，帮我们确定做什么测试的问题，比如测功能、组件、性能、可靠性等等。

测试四象限

测试金字塔

利用测试金字塔原则，将上边确定好的测试方法，结合项目架构，进行测试分层，确保覆盖全面：

测试金字塔
之前有写过 一篇文章 详细介绍。

测试矩阵

确定了测试方法和测试分层，我们还需要考虑一些细节，比如用什么工具来做这些测试、在哪个环境运行、还有需要集成到CI吗等等问题，这个时候，就可以利用测试矩阵来生成细化方案：

测试矩阵
将确定要做的测试方法放在首行，纵向则陈列各种测试细节，这样清晰明了，更容易和团队达成一致。之前博主也写过 一篇文章 介绍测试矩阵，但那时举的例子比较简单，现在就更加全面了。

持续测试

持续测试 是指在项目开发过程中，进行持续的功能测试，也包括性能、安全等的内建；形式可以是静态分析、评审，也可以是动态的测试，包括手动执行的各种测试，以及集成流水线上持续执行的自动化测试。

事实上，也就是以用户故事为一个单位，敏捷团队日常进行的一些测试实践，比如KickOff、TDD、DeskCheck等等。

测试四象限

详细可以看我 之前的文章。

测试右移

测试右移 是指在项目进行一段时间、或者上线后，进行的一些测试管理和测试总结的相关实践，比如 BugBash 、Bug管理、BugReport、ShowCase等等，又比如根据项目风险随时调整测试策略、上线前的测试计划、以及自动化代码的重构、数据分析……每一个实践都可以拉出来细细讨论。

好了，以上就是所有关于敏捷测试的简单介绍，总之，全是套路，以后有什么新的套路我也会更新在这里，但是这个分类和规律是不变的。

参考文章