敏捷测试分析和测试策略的制定

敏捷测试的分析与计划应该建立在测试左移的基础之上，即团队成员通过参与需求的定义和评审对产品和目标用户已经有了全面的了解，在此基础上进行测试需求的分析、测试风险分析、测试策略制定，并最终为每个迭代定义测试计划。

我们要关注项目上下文（所处的观景、所要满足的条件），并认识到上下文是会变化的，测试策略和方法要根据上下文来制定，并根据其变化及时调整、不断优化。上下文驱动的测试思维是主要的敏捷思维方式，也是敏捷开发模式下做好测试分析的基础。

软件测试的流派

软件测试的流派

上下文驱动测试流派 7 原则：

1. 任何实践活动的价值取决于它所处的上下文。
2. 只存在特定上下文中的优秀实践，而没有最佳实践。
3. 在一起工作的团队成员是项目上下文中非常重要的组成部分。
4. 项目经常按照难以预测的方式逐渐开展。
5. 产品是一种解决方案。如果提供的方案不能解决问题，那么产品就是无用的。
6. 好的软件测试是一个富有挑战性的智力过程。
7. 只有通过判断和集成，并在整个项目过程中大家持续协作并肩实践，我们才能在正确的时间做正确的事情，以有效地测试我们的产品。

启发式测试模型

启发式测试模型能策略（heuristic test strategy model，HTSM）用来进行测试分析并制定测试策略的工具。它侧重从质量标准、项目背景、产品元素 3 个方面考虑对项目所选择的测试技术、方法、工具的影响，每个方面都包含多项因素，即各种上下文因素。在此基础上制定策略并最终向用户交付满足其质量标准的产品。

启发式测试策略模型示意图

质量标准 - 启发式测试策略模型：

软件给谁用：当前用户构成是怎样的？用户画像是怎样的？根据年龄、职业、受教育程度等是如何分布的？为了哪些人会成为新用户？软件测试人员要站在用户角度想问题，分析、设计软件测试。

用户对质量有什么具体要求：ISO 25000 系列标准。

产品质量模型

基于这些特性，结合用户、业务和产品特点进行更深入的分析，以了解对质量的具体要求，以及哪些质量特性需要优先关注。

参照那些质量标准或行业规范，这个问题是需要认真解决的。

项目背景：

• 项目目标：测试是为了实现项目的目标。测试目标是在项目目标的基础上制定的。
• 交付物：在每次产品发布中，研发团队不但要交付相应版本的软件，而且要交付相关的文档。包括用户手册、管理员手册等。交付物也直接影响测试范围和测试工作。
• 质量标准：指当前项目（即敏捷中的每次迭代）对质量的具体要求。例如，这次迭代中实现的某个功能要求团队特别关注，而且另一个工具只是尝试，这样在功能测试项的优先级安排上，前一个功能的优先级要高得多。又如，这次迭代系统能支持的用户并发数要比上次迭代提高 30%，这就决定了性能测试验证的具体之指标值。
• 项目范围：在敏捷开发中，每次迭代的目标是产生一个可交付的软件，但不一定每次迭代后都必须交付或发布给用户，很多团队选择几次迭代发布一次。每个要发布的版本及其中每次迭代的用户故事列表就构成了项目范围，项目范围是决定测试范围的关键要素。
• 进度：项目（每次迭代）开始和结束日期，以及其间重要的里程碑等都会影响测试计划的指定。例如，每次迭代中，持续测试、用户故事验收测试及后续的端到端的验收测试都需要参考项目进度计划来制定。
• 可用的资源：每项测试活动都需要资源，而资源是有限的，清楚项目的预算和资源，包括可用的人员、工具和环境等，对测试人员的安排、测试环境的准备是有必要的。
• 项目类型：项目是长期性的产品还是一次性项目；项目是独立的还是多方合作的综合性集成项目；与相关方的合作方式是什么；项目是本地还是外包。
• 研发团队：是指研发团队的人员数量及技术水平；开发人员、测试人员、业务分析人员的相关经验如何；单元测试是否充分；代码评审效果以往表现如何；这些对测试策略、测试工作都有较大影响。
• 开发工具和编程语言：开发工具使用哪一款，对于不同的编程语言，使用其中一种还是用多种编程语言组合使用。开发工具和编程语言的选择对测试环境搭建、自动化测试实施等也有影响。

产品元素：

• 结构：软件系统的结构体现在层次性、组件化接口标准化等。基于这些信息，我们才能更有效地开展测试以及功能之间的交互测试。
• 功能：产品业务需求是通过软件功能承载的。同时，还需要了解系统功能之间的依赖关系、功能之间的交互作用等。基于这些信息，我们才能更有效地开展功能测试以及功能之间的交互测试。
• 数据：从测试覆盖来看，可以分为两部分。控制流：提现在代码逻辑覆盖、基本路径覆盖和业务流程覆盖上；数据流：则体现在业务数据的输入/输出、存储和恢复等方面的覆盖上。整个计算机系统就是在处理数据，因此，在许多时候，数据是测试研究的重要对象。
• 平台：软件运行的平台，包括操作系统、数据库、浏览器、虚拟机、云平台及平台参数的组合。是测试环境设置、兼容性测试重点考虑的因素。
• 操作：用户的行为、操作方式，一般是指产品提供的遥控器操作、用户界面触摸操作。对于触屏设备，是指手指的触摸方式。另外，还包括异常操作、恢复出厂设置等操作。
• 时间：在测试时应用系统或对时间敏感的应用系统，如在线视频系统、嵌入式系统、工业物联网等，需要特别关注时间。

上下文中的产品元素

一切从用户角度出发，站在用户角度去思考产品功能特性，扮演用户角色进行测试。不要求打造更好的产品，而要打造更好的用户，即由原来关注如何提升产品质量转移到如何帮助用户完成目标，让用户获得成功。更关注用户的真实愿望，会主动和用户交流，聆听用户心声，挖掘用户真正的需求。

需求测试就是对原来抽象的业务需求的一种还原，通过还原来验证需求。一方面是用户故事的验收标准，需要场景去覆盖，尽可能捕获各种场景，覆盖验收标准。另一方面是需要有想象力，在测试设计、执行和学习中不断发现的场景，这样才能更好的完成敏捷测试。场景是敏捷测测试需求的灵魂。

业务分析

需求 3 个层次：

• 业务需求：为满足各种业务目标而对业务实际运行、操作的要求，是业务分析的主要对象，也是软件系统必须满足的、最基本的要求。
• 用户/利益相关者需求：用户/利益相关者都是服务于业务的，他们在业务中半夜着不同的角色，发挥不同的作用，自然对软件系统有着各自特定的需求。
• 系统功能和非系统功能性需求：为了满足上述两层需求，软件系统所具备的特性。

业务分析的核心还是业务实体关系图和业务流程图，前者更有利于弄清业务数据，后者有利于弄清业务活动、业务角色，以及他们之间的关系。

业务需求要素分析

用户需求：

• 用户细分：不同的用户群有不同的需求，创建细分用户群更加能够揭示用户的真正需求。
• 可行性和用户研究：包括问卷调查、卡片排序法、焦点小组、任务分析、用户测试等方式/工具来获取用户信息、了解用户行为等。
• 创建人物角色：基于上面的用户研究，从中提取可成为一些典型的虚拟人物，从而更好的展现用户使用产品的场景。

用户体验要素

5 层模型：

• 表现形式：所呈现的具体细节，用户感知体验主要来源于这一层。
• 框架层：信息设计、界面设计和空间布局，确定了在 UI 交互界面上交互元素的位置和排列方式。允许用户以不同的方式浏览，并帮助用户理解及使用。
• 结构层：确定元素之间的逻辑关系，包括系统各种特性和功能最合适的组合方式。例如，用户如何到达某个页面，以及处理完去哪里。框架是结构的具体表达方式，而结构层则用例设计、指引用户如何到达某个特定的页面。
• 范围层：定义软件的需求及其优先级，即特性和功能构成了系统的范围层。包括创建怎样的功能规格和内容需求，以及具体实现哪些功能。
• 战略层：实现产品目标，关注并考虑如何满足外部用户的业务需求，这是在设计用户体验过程中做出每一个决定的基础。产品目标：我们要通过这个产品得到什么；用户需求：我们的用户要通过这个产品得到什么。

注意事项：

1. 成功的界面设计可以让用户一眼就发现“最重要的东西”。
2. 帮助用户理解“他们在哪里”“他们能去哪里”“哪条路距离目标更近”，如借助图标、标签、排版和颜色等视觉需要进行指引。
3. 每个操作步骤都是合理的，当前步骤要自然延续上一个步骤中的任务。
4. 设计的一致性能避免用户出现困惑和焦虑
5. 一个产品的标准配色方案中所使用的颜色是为了他们在一起工作而专门挑选出来的，他们之间是互补而不是冲突的。
6. 不要使用非常相似但又不完全一样的风格，也不要使用过程与广泛和多样的风格，只有在你需要传达不同的信息时才使用不同的风格。
7. 遵循“使用用户语言”并且“保持一致性”的命名原则，同时避免“语义歧义或者不解”。
8. 提供的功能和内容越多，猜测就变得越不可靠，总有一部分用户会猜错的，好的产品经理会做“减法”。

软件测试就是在测试质量和测试效率之间的一种平衡艺术，即制定或选择更合适、更有效的测试方式、方法和技术等，其目的是以最低的时间或人力成本最大程度揭示产品的质量风险、尽快完成测试（即达到特定的测试目标）等。

测试方式：

• 手工方式与自动方式
• 主动方式与被动方式
• 静态方式与动态方式
• 探索式测试与基于脚本的测试
• 团队自己测试与众测、外包等的平衡

测试方法：

• 黑盒测试与白盒测试
• 基于数据流的方法与基于控制流的方法
• 完全组合测试方法与组合优化测试方法
• 错误猜测方法与形式化方法等平衡

测试过程：先测什么，后测什么，以及对测试阶段的不同划分等。

精准测试是一种软件测试分析技术，技术算法功和工具，自动建立黑盒测试用例和软件代码之间的可视化追溯，同时分析代码依赖性，从而基于影响的代码，精准选择受影响的测试（用例），以最大程度优化要执行的测试范围。

精准测试可以实现的功能：

• 统计测试用例的代码覆盖率
• 优化测试范围
• 迅速定位软件缺陷
• 分析和改进软件架构设计和代码架构

基本过程（实现原理）：

• 借助代码覆盖率分析技术，建立代码和测试使用例的映射关系，为每一个测试用例和代码方法/代码块建立对应关系。
• 对代码进行依赖分析，了解代码中类、方法和代码块之间的互相关联或调用关系。
• 拿到新的软件版本，与上一个软件版本进行代码差异（code diff）的比较，确定哪些代码被改动了。
• 基于代码和测试用例的映射关系和代码依赖关系，确定受影响的测试（用例），执行受影响的测试（用例）。

测试用例和代码的映射关系

测试用例和代码双向追溯

精准测试的核心是简历测试用例和代码之间的映射关系，通过记录每个测试用例在执行过程中对应的程序内部的执行细节，可以追踪到方法或代码块级别。

正向追溯：当测试用例在执行过程中发现软件缺陷时，可以直接定位到缺陷所在的代码块。包括系统测试中难以复现的缺陷，因此可以帮助开发人员快速修复缺陷。

反向追溯：可以进行软件不同版本之间的代码差异化分析，从而得到代码修改部分所影响的测试范围。以确定回归测试中包含的测试用例。如果新版本中有新增的代码，系统则会自动提示研发人员补充新的测试用例来覆盖。

探索式测试（Exploratory testing，ET）是一种软件测试风格（style），强调独立测试人员（Individual tester）的个人自由和职责，为了持续优化其工作的价值，将测试相关的学习、测试设计、测试执行和测试结果分析作为互相支持的活动，在整个项目过程中并行地执行。

探索式测试的要点：

• 探索是测试不是测试方法、测试技术，而是一种软件测试方式（非“探索性测试”），各种测试方法、测试技术依旧可以应用于探索式测试的方法中。
• 以人为本，强调测试人员的价值，给他们更大的自由发挥空间。
• 持续测试，测试设计、执行、学习和结果分析同时进行，没有明确的阶段划分。
• 持续优化测试工作
• 不只是一种辅助的测试方式，它可以贯穿整个项目生命周期

基于脚本的测试

基于脚本的测试（scripted testing，ST）。先完成测试脚本，在执行测试脚本，有明确的的阶段划分：前面阶段专注于测试脚本的设计与开发，后面阶段专注于测试脚本的执行。包括手工执行的测试用例和工具执行的自动化测试。

基于脚本的测试、探索式测试和 ad-hoc 测试的关系

敏捷拥抱探索式测试

从探索式测试角度重新理解软件测试

• 驱动价值或业务驱动：敏捷测试和探索式测试都强调做出对客户有价值的事情。
• 持续学习和改进：上下文驱动，不断学习，不断改进，精益求精。
• 以人为本：敏捷测试和探索式测试都强调人是最重要的，要挖掘每一个研发人员的潜力。
• 效率优先：更侧重效率，强调快速完成任务，持续工作，持续交付。
• 拥抱变化：更具有适应性，能够快速响应变化，认可“拥抱变化胜于遵循计划”这样的价值观。
• 关注产品本身：认可“可工作的产品胜于详尽的文档”这样的价值观。

SBTM 用于在探索式测试过程中的沟通会话（SESSION）。探索式测试可以看作“不断地问系统或质疑系统”的过程。

SBTM 一次完整的会话过程：

• 测试人员在一个不受打扰的时间段，针对一项清晰、具体的测试任务进行探索式测试，这个时间段通常是 90 分钟左右。
• 在测试结束后，测试人员提交形式简单的文字报告，即会话表（session sheet），并且尽快向测试负责人进行口头汇报（debriefing）。
• 会话要执行的具体测试任务需要书面描述，在 SBTM 中称之为章程（Charter）。
• 测试负责人可以是敏捷团队负责人、传统测试团队负责人，也可以是指定的资深测试人员。

SBTM 框架示意图

SBTM 主要元素之间的关系

首先，把测试计划中的测试目标分解为一系列清晰的、具体的测试子目标，每个测试子目标代表一个测试任务。一个特定的测试子目标，需要通过一个或几个具体会话来完成。每个会话中要执行的具体任务需要一个书面描述，就是测试章程。

测试计划分解为测试子目标示意图

• 新功能测试子目标：验证单个新的用户故事是否符合验收标准。
• 功能交互测试子目标：验证新的功能特性之间，以及与已有功能特性的交互是否正常，即包括对于某个 Epic 内功能之间的交互，又包括涉及多个 Epic 的面向业务的端到端的测试。
• 各类专项测试子目标：包括非功能性的，如验证被测系统的易用性、安全性和兼容性等。包括功能性的，如验证被测系统在边界状态、复杂网络环境等条件下的系统功能是否正常。