敏捷测试左移之用户故事的测试

测试左移是指让测试尽早开始，把测试活动左移到需求分析阶段，目的是及时发现研发前期的错误，避免将错误带到后面的研发活动中。

可测试性是指一个系统能不能进行测试，包含：

可观察性 （Observability）：是指在有限的时间内使用输出描述系统当前状态的能力。系统具有可观察性意味着一定要有输出，没有输出就不能了解系统当前处于什么状态，也就不能确定系统行为表现是否正确。

可控制性 （Controllability）：是指在特定的合理操作情况下，整个配置空间操作或改变系统的能力，包括状态控制和输出控制。系统具有可控制性表明一定要有输入，只有通过输入才能控制系统。

可预见性 （Predictability）：在一定的输入条件下，输出的结果是可预测的，这样我们就可以给出系统的预期行为或预期结果。用于测试用例或自动化测试脚本的设计中。通过被测系统提供的接口对系统进行操作，并通过观察到的输出结果了解系统的状态是否符合预期。

人工智能软件的可测试性是一个挑战，因为缺乏可预见性，不太容易事先定义好 Test Oracle 来验证输出结果是否符合预期。

需求、设计和代码等不同层次的可测试性

需求的可测试性：在敏捷开发中用户故事的可测试性。用户故事中对需求的描述要做到清晰、准确，并且可以通过测试来验证。

设计的可测试性：通过设计来确保系统的特性具有可控制性、可观察性。包括系统架构的设计、UI 的设计、接口的设计等。

代码的可测试性：按照设计规范进行编程，包含以下两点。一方面，要保证设计中对可测试性的要求和设想得到实现，即遵循设计实现了系统的分层架构、模块之间的接口等。另一方面，需要遵循有助于提高单元测试性的代码规范，比如单一职责、依赖倒置等面向对象编程的代码设计原则。

用户故事的测试，应该以业务语言来描述，而不是使用技术语言。在开发设计编写代码前，先明确 （定义） 每个故事的验收标准，再基于用户故事的验收标准进行开发。

测试驱动开发 （test-driven Development，TDD）是指测试在前，开发在后的开发实践，提倡在编程之前，先写测试脚本或设计测试用例。有了 TDD，程序员就有底气进行设计或代码的快速重构，有利于快速迭代和持续交付。重构是指在不改变代码外在行为的前提下，对代码做出修改。

验收测试驱动开发 （ATDD）和单元测试驱动开发 （UTDD）都属于测试驱动开发 （TDD）思想指导下的优秀实践。

 验收测试驱动开发 （Acceptance test driven development，ATDD） 发生在业务层，在设计、写代码前就明确需求 （用户故事） 的验收标准。

单元测试驱动开发 （Unit test driven development，UTDD） 发生在代码层，在编码之前写单元测试脚本，然后编写代码直到单元测试通过。

行为驱动开发 （Behavior driven development，BDD） 相当于 ATDD 的实例化，以结构化的语言使验收标准更加明确化。

产品价值是软件研发的基础，用户只有认可产品的价值才会购买并使用它。敏捷团队应该是自组织、全功能型团队，产品价值分析是团队的重要任务。

理解用户真正想要什么进而交付满足需要的产品，并不是一件容易的事，也不要假设产品经理要求你实现的功能一定是客户真正想要的。在做产品之前，多问问为什么用户需要这个产品或某个功能特性，也许可以帮助团队纠正需求的偏差或者发现被忽略的隐性需求。

商业画布

它是一个适合敏捷的商业模式分析工具，可以帮助研发团队快速地对产品的价值和市场定位有一个整体的认识。商业模式描述了企业如何创造价值、传递价值和获取价值的基本原理。

分析过程：

1. 找到产品的目标客户群 （客户细分）
2. 分析客户的需求 （价值主张） 是什么
3. 探讨怎样才能获取到客户 （渠道）
4. 如何建立和维护客户关系以便留住客户 （客户关系）
5. 应该用什么样的方式实现盈利 （收入来源）
6. 发掘产品目前拥有什么样的核心资源，如资金、技术和人力等 （核心资源）
7. 列出必须要交付的业务功能 （关键业务活动）
8. 找出重要的合作伙伴 （关键合作伙伴）
9. 分析投入产出比是怎样的 （成本结构）

影响地图

用于业务分析的可视化工具。利用这个工具，研发团队从 「为什么要做这个产品或功能」 出发，与业务负责人一起讨论并制定一个产品功能要实现的业务目标。研发团队可以从中识别出产品需要设计那些功能特性，同时帮助实现业务目标。

从 4 个方面 「why → who → how → what」 举例：

why：为什么要这个功能？例如 「分销功能」 是为了实现课程推广的列表，从而提高销售额。实现什么样的业绩目标？设定业务目标应该是明确、清晰、可衡量的，并且是可以实现的。

who：那些角色会影响目标的达成？这些角色既可以帮助我们实现目标，又可能阻碍目标的实现。在此案例 （在线教育 App） 中，识别出影响目标的角色，包括 App 用户、市场推广人员、课程审核人员和课程讲师等。

how：需要什么样的方式影响上述角色的行为来达成目标？既包含生产促进目标达成的正面行为，又包含消除阻碍目标达成的负面行为。

what：对于每一种影响方式，需要采取哪些具体方案。

用户故事地图

用户故事地图 （User story mapping） 一种生成用户故事的团队协作沟通的新方法。用于解决以下问题：

• 团队协作产生用户故事
• 系统化地呈现软件要提供的全部功能
• 识别出要交付的最小化可行性产品 （Minimum viable product，MVP）。目的是以最小的投入快速交付对用户有价值的软件。这一点对于敏捷开发尤为重要，它可以很好的服务于迭代增量开发。
• 呈现不同颗粒度的用户故事之间的关系 （Epic（大的用户故事集） 和用户故事）
• 识别用户故事的优先级

用户故事地图需要敏捷团队成员共同完成，可以采用大家坐在一起进行 「头脑风暴」 的方式。

在一个软件产品中，不同用户角色对应不同的用户故事地图。例如，对于在线教育 App，还可以给 「课程讲师」 这个角色制作一个用户故事地图。

需求评审通用标准：

• 可测试性
• 可行性 （能够实现）
• 易修改性 （文档容易维护）
• 正确性：需求定义是否符合软件标准、规范的要求；每个需求定义是否合理并经得起推敲；是否所有的功能都有明确的目的；是否存在对用户无意义的功能；采用的算法和规则是否科学、成熟和可靠；那些证据说明用户提供的规则是正确的。
• 易理解性
• 一致性：所定义的需求内容前后是否存在冲突和矛盾；是否使用了标准术语和统一形式；使用的术语是否是唯一的；所规定的的操作模式、算法和数据格式等是否相互兼容。
• 可追溯性：来自哪项具体的业务；由哪个用户提出来；是否可以根据上下文找到所需要的依据或支持数据；后续的功能变更是否能找到其最初定义的功能；功能的限制条件是否可以找到其存在的理由。

用户故事的评审

当一个用户故事太大，有时候就称为 Epic（史诗，大的用户故事）。

完成 Epic 的评审，就可以进入用户故事的评审。用户故事的评审相对具体、有标准。

INVEST 评审标准：

• Independent - 独立的
• Negotiable - 可协商的
• Valuable - 有价值的
• Estimable - 可估算的
• Sized appropriately or small - 大小合适的
• Testable - 可测试的

用户故事 3C 原则：

• Card（卡片）：一张卡片书写一个用户故事，卡片的空间很有限，可以促进用户故事简洁，捕获需求的精髓或目的。
• Conversation（会话）：类似 「可协商」，强调需求的细节是在开发团队、产品负责人及利益相关者之间的会话中暴露和沟通的。用户故事仅作为建立这个会话的一个承诺。
• Confirmation（确认）：用户故事还要包含满足 「条」 形式的确认信息。

设计评审的价值和重要性

1. 更好的确保软件设计的可测试性，包括系统功能、性能、安全性和可靠性等。
2. 能够提前发现设计上的缺陷，避免直到系统测试时才发现问题，大大降低了系统的质量风险、项目管理风险和软件研发成本。
3. 更好地了解系统是如何实现的，以及由哪些组件、服务构成，更深入地了解系统架构、关键组件和关键接口等，有助于实现分层测试、面向接口的测试，从而提高测试方案、测试设计的有效性和效率。

系统架构及评审

系统架构包含：

1. 性能：一般在设计上会考虑分层架构，分布式架构，（文件） 系统缓存机制，轮询式任务分配，数据服务器和应用服务器分离，数据分片和数据读写分离，以及 CDN 等措施。
2. 安全性：数据和系统的分离，将系统权限和数据权限分别设置，以及基于角色的访问控制设计等都可以提高系统的安全性。
3. 可靠性：采用多节点分布体系架构，这样单个节点失效就不会造成整个系统失效，从而确保系统的可靠性。
4. 可扩展性：区分可变和不可变业务，采用多层分布体系架构，基于不同的组件或层次为不同的业务提供开放的服务接口 （API、SDK），并尽可能简化架构，降低模块间的耦合性等。

组件评审包含：

1. UI 层：检查是否采用了类似 GWT 的 WEB2.0 用户界面框架，从而能够支持 Firefox、IE、Safari、Google Chrome 等浏览器的最新版本，以及是否适用于基于 JQuery Mobile 的的移动设备、WebDAV 和 DIFS 协议等。
2. API 层：检查是否支持 OASIS 开放标准的 CMIS 协议，即是否允许 Web 协议互连，并控制各种文件档管理系统和存储库；检查是否支持 OpenAPI 标准，能否通过 Web 服务 （SOAP） 和 REST 提供完整的、开放的 API，从而实现与第 3 方应用程序的集成；检查是否提供了用于 Java、.NET 和 PHP 等二次开发的 SDK。
3. 安全层：设计用户身份的验证，以及注册用户和未注册用户访问权限的管理、安全控制等。
4. 存储模块：检查是否足够安全、可靠和开放
5. 其他组件：例如，检查搜索引擎、目录和单元数据等组件是否合理。

接口定义的评审：

• 接口定义：RESTful、UTF-8、GET/POST
• 接口性能：JSON/XML、Memcache
• 安全性：签名机制、访问授权机制、数据传输加密、客户端身份验证和时间戳验证。

设计的可测试性：

1. 测试驱动设计方法：比如先确定验收测试用例，再设计具体的功能。先确定功能、可靠性等测试用例，在考虑如何实现架构设计，以满足不同特性的需求。
2. 选用开放、现金而成熟的设计模式和框架：在一定程度上能保证系统结构的低耦合性、单一的依赖关系，具有较高的可测试性。
3. 可控制性设计：包括业务流程、模块、场景、全局变量、接口等的可控制性能设计。即在外部提供适当的方法、途径，直接或间接地控制相应的模块、全局变量和接口等。
4. 数据显示与控制分离：通过分层，增加了系统的可观察性和可控性。通过对接口调用，分别完成相应的业务逻辑、数据处理等的测试。
5. 遵守设计原则：如接口隔离原则，并对模块，尽量分解到相对应稳定、规模合适的程度，以确保模块的独立性和稳定性，有助于独立开展对模块的测试活动。
6. 设计易理解性：包括明确的设计标准、规范的设计文档、明确的接口及其参数的定义，使设计有据可依，层次清晰，设计文档易读。

行为驱动开发 （Behavior-driven Development，BDD）是一个过程，旨在通过改善工程师和业务人员之间的沟通来促进开发项目的交付。BDD 确保所有的开发项目始终关注。要交付产品的实际业务需要，即满足用户的所有需求。

GWT 格式的自然语言：

• Given：给定什么上下文/条件 AND/OR 其他条件
• When：当什么事件 AND/OR 其他事件被触发
• Then：产生什么结果 AND/OR 其他结果

BDD 和测试

BDD（行为驱动开发） 可以看作 ATDD（验收测试开发） 的实例化，即 BDD 是通过上述 GWT 格式描述的具体场景来建立 ATDD 中的验收标准。

BDD 和 ATDD 都是业务层上的实践 （TDD - 测试驱动开发）：首先编写验收测试用例，然后驱动产品的设计与代码，以此表征软件功能特性被正确实现。

UTDD（单元测试驱动开发） 是在代码层次上，先编写单元测试脚本，在没有开发代码的情况下运行测试脚本自然会失败，再开发并修复代码直到测试能够通过。

首先在业务层面为用户故事添加场景化的验收标准，并在此基础上生成验收测试用例。随后，工程师编写代码来实现这个用户故事。但先要开发能够验证所实现的功能的单元测试脚本。再开发代码让其测试通过，需要时通过重构代码改善质量，重构后的代码也必须通过单元测试。

BDD 实践下的用户故事验收：

1. 业务负责人 （产品经理） 和敏捷团队沟通业务目标及功能特性。
2. 业务分析人员、开发人员和测试人员协作编写用户故事。
3. 建立用户场景，以指导研发人员编写产品代码及自动化测试代码。
4. 测试人员着手执行不能自动化的部分。
5. 提交用户故事验收测试报告，即提供质量反馈。

BDD 自动化测试框架的特点

BDD 实例示例