点这里👇星标关注，获取最新资讯！
彭锦，中航信重庆分公司，高级软件工程师、 研发效能（DevOps）技术工程师（中级）学员
摘要
在软件开发过程中，需求是指对系统功能、性能和其他特性的描述。实际开发中，团队往往会先得到巨大的需求开发团队得到准确的需求说明对于项目的成功至关重要。然而，传统的需求文档往往过于抽象，难以理解和执行；相较而言，需求场景化，更加能够激发参与和深度讨论，也就是通过实例来引发需求共鸣。因此，需要一种可执行的需求说明方法，该方法强调的是需求说明不仅简短，而且也需要在计算机上以一种固定的格式发布成可执行的文档。可执行需求说明提炼方法有助于缩小干系人希望软件能做什么（什么）和该软件的确能做什么（如何）之间的差距。对应到测试V模型上，在顶端需求也可以使用BDD的方式以之对应，并能在功能完成后对需求自动化验证。
一、背景
在软件开发的复杂环境中，确保需求被准确理解并有效执行是项目成功的关键。然而，传统需求文档往往过于抽象和静态，难以适应快速变化的项目需求，导致开发团队在理解和执行过程中频繁遇到障碍。这种需求与实现之间的鸿沟不仅增加了项目的风险，也降低了交付效率和质量。
随着DevOps理念的普及，软件开发团队对更加灵活、高效的需求管理方法产生了迫切需求。我们希望找到一种方式，能够直接将需求转化为可执行的形式，从而在开发过程中持续验证和确保需求的正确性。这一需求推动了可执行需求说明，尤其是与行为驱动开发（BDD）方法的结合，为解决上述问题提供了新的思路。
BDD通过用户故事和场景驱动开发，将需求转化为可执行的测试案例，使得开发团队能够在早期阶段就验证需求的实现情况。这种方法不仅促进了团队成员之间的有效沟通，还通过自动化验证手段，降低了人为错误的风险，提高了软件交付的可靠性和效率。
二、故事粒度
1.拆解主角
在《用户故事地图》的指引下，我们倡导一种高效而协同的决策模式，即组建一个跨部门的小型“探索团队”。这个小组由2至4名成员构成，核心成员包括产品负责人、用户体验设计师（设计师）、资深技术人员。每位成员均需具备卓越的沟通与协作能力，共同编织产品的未来蓝图。
这个团队应该由一个对业务愿景、战略以及产品服务的市场有深度理解的产品负责人主导。这个核心团队应该有这样的人，他理解用户，可以自如地和用户合作，力求了解他们的工作方式，并且可以开发简单的UI原型。这个团队也应该包括一个来自开发团队的资深工程师。这个人需要理解系统目前的架构，知道哪些新的技术方案可以用来解决目前的难题。
探索团队应从探索阶段就开始介入，终止于“故事工作坊”以完成最后一次讨论。在故事工作坊中，除了探索团队成员之外，还要纳入测试人员等，共同定义最佳的开发和测试用时。探索团队通过用户故事的一系列方式，抽丝剥茧般梳理和评定用户故事，将故事拆分为大小合适的模块。这些模块，将最终流入开发流程中。
2.故事拆分
探索团队的核心使命之一在于精准拆分用户故事，确保每个模块都能在1至3天内完成开发与测试。这一粒度控制不仅提升了开发效率，也增强了项目的可控性与灵活性。
面对庞大的“史诗故事”，团队从三个维度进行精准切割：首先，从用户角度出发，确保每个模块都能满足用户的特定需求；其次，从开发视角审视，确保模块规模适中，便于快速迭代与测试；最后，从业务战略层面考量，确保每个模块的完成都能为业务目标的实现贡献力量。
3.故事聚合
有时候，我们的需求池中会充斥大量的小需求，它们细碎而不值得大动干戈，但堆积太多又不知如何处理。此时，我们需要“聚合”，将那些细碎的小故事聚合为“主题”。“主题”用以归类故事，收集需要下个版本发布、同一功能的不同版块、以某种其他方式关联的一堆故事。内容不多时候，我会直接根据需要将一堆小故事聚合在一个卡片中。当然这种故事很多时候，也可以采用以下方法：
准备阶段：利用便签记录每一项需求，邀请对项目系统有深刻理解的项目成员参与。
空间布置：选择一面宽敞的墙作为工作区域，为团队提供一个直观、开放的讨论环境。
分组讨论：每位成员分配一定数量的故事卡片，通过个人思考与小组讨论相结合的方式，将相似或相关联的卡片归类放置。在归类过程中，鼓励成员保持安静，专注于分类本身，避免即时交流带来的干扰。
共识达成：最后，团队成员汇聚一堂，就不同分类的卡片进行深入讨论，达成共识。每个分类最终都将获得一个精炼而具体的大标题，作为该“主题”的核心概述。
三、需求实例比
在软件开发过程中，深入挖掘并清晰整理需求是确保项目成功的基础。通过实例化的方式举例，能够显著提升需求的一致性和可理解性。
按接触法举例：从用户日常接触的场景出发，模拟用户的实际操作流程，捕捉真实需求。
按数据规格举例：运用边界值分析或等价类划分等测试技术，设计覆盖全面且典型的实例，以验证需求的准确性和完整性。
按业务规则举例：根据业务场景构建需求实例，确保每个实例都符合实际业务逻辑和流程。通过模拟不同业务场景下的操作，发现潜在的需求漏洞。
按权限举例：根据用户权限的不同，设计不同角色的操作实例，确保系统能够正确区分并处理不同角色的权限需求。
按正反来举例：同时考虑正例和反例（异常或错误处理），通过对比分析，全面覆盖需求的各种可能情况，提高系统的健壮性和可靠性。
2.需求实例化工作坊
为了更好地推进需求实例化工作，可以组织专门的需求实例化工作坊。一般我们认为可以遵循如下流程：
明确目标与优先级：由产品负责人（PO）介绍本次工作坊的目标、需要完成的实例故事及优先级排序。
故事讲述与理解：PO详细讲述每个故事，团队成员根据接口文档初稿和建模初稿进行理解，并可进行领域建模、流程建模、边界划分或状态机建模的讲解，以促进团队对需求的深入理解。
实例化讨论：团队成员根据故事内容，共同讨论并形成实例。实例描述需包含前置条件、输入、输出等内容，确保实例的完整性和可测性。边界划分，和今天讨论的范围相关的概念、流程是什么？
可测性验证：验证实例的可测性，讨论如何将实例转化为可执行的测试用例。确保每个实例都具备明确的验证标准和测试方法。实例化，今天需要讨论那些规则，这些规则如何使用Given、When、Then的形式进行描述？
总结与反馈：工作坊结束时，对讨论结果进行总结，并收集团队成员的反馈意见，以便后续优化和改进。
3.实例化需求
实例化需求，它是一组方法，它以一种对开发团队有所帮助的方式（理想情况下表现为可执行的测试）描述计算机系统的功能和行为，让不懂技术的利益相关者也可以理解，即使客户的需求在不断变化，它也具有很好的可维护性，可以保持需求的相关性，从而帮助团队交付正确的软件产品。
在实践过程中，应注重以下几点：
通过实例深度剖析与澄清需求，确保每一个细节都被准确捕捉和理解。
将这些实例无缝转化为具体的测试用例，为后续的自动化测试奠定坚实基础。
最终，依托全面的测试来验证需求的实现情况，确保软件产品精准满足既定需求。
四、行为驱动开发BDD
行为驱动开发（BDD）作为测试驱动开发（TDD）的进化形式，强调与业务人员的紧密合作，通过共享语言和理解，共同推动软件开发的进程。它不仅关注软件功能的正确性，还致力于确保团队内部对业务逻辑的一致认知。
1.BDD理念和原则
BDD深深植根于敏捷开发的土壤中，其特点与敏捷测试的理念不谋而合：
不可分割性：BDD不能孤立存在，它是敏捷开发整体流程中的一个关键环节，而非单一的测试类型或方法。
全员参与：在BDD中，测试不再是测试人员的专属职责，而是整个团队的活动。通过跨职能合作，促进对需求的全面理解和共识。
敏捷共生：脱离敏捷开发的上下文讨论BDD是徒劳的，二者相辅相成，共同推动项目的快速迭代与持续优化。
BDD还强调“预防胜于治疗”的原则，即在早期发现并修复缺陷，以最小化修复成本。通过共同构建测试用例，团队成员能够更深入地理解业务需求，确保软件功能既符合技术标准又贴近用户期望。“Test early, test often, test first”不仅是敏捷测试的核心，也是BDD实践的精髓所在。它鼓励团队在开发初期就引入测试，通过频繁的反馈循环来确保软件质量。
2. BDD研发过程
BDD融合了敏捷与精益的最佳实践，旨在帮助研发团队更好地理解产品需求，并在开发过程中不断验证和调整。其核心在于将业务需求转化为可执行的测试场景，从而指导软件的设计和实现。BDD并不是一种软件研发方法，把现有的工作方法融合起来，让软件研发团队更加高效的工作，从而减轻因软件产品计划延误或功能缺失带来的压力。其大致可分为6步：
明确产品愿景：确立产品的长远目标和核心价值，为整个开发过程提供方向指引。
细化业务目标与软件需求：将产品愿景分解为具体的业务目标和软件需求，确保团队对开发目标有清晰的认识。
共同梳理用户故事与验收条件：产品负责人（PO）、需求分析师、开发人员和测试人员紧密合作，通过用户故事的形式描述业务需求，并明确每个故事的验收条件。
编写可运行的验收测试：开发人员利用BDD工具（如Cucumber、SpecFlow等），将用户故事及其验收条件转化为可执行的自动化测试脚本。
执行验收测试：通过运行自动化测试脚本，验证软件是否满足用户故事的验收条件。测试可以覆盖UI层的端到端测试，也可以针对特定接口进行测试。
实时反馈与调整：产品负责人通过查看验收测试报告，及时了解软件研发进度和质量状况。根据反馈，团队可以对产品特性进行调整，确保最终交付的软件产品既符合业务需求又具备高质量的用户体验。
五、自动化验证
自动化验证是软件开发生命周期中不可或缺的一环，它通过将繁琐的人工验证过程转化为高效的机器执行，从而显著节省人力成本、缩短验证周期，并提升验证的准确性和一致性。
1.自动化功能验证范围:
敏捷验证四象从另一方面来说是一个通用的软件验证策略，可以帮助我们理解哪些验证适合自动化验证。 通常面向业务的验证中，功能验证、用户故事验证、原型、仿真验证涉及的范围可以纳入自动化功能验证的范围。以业务价值驱动帮助我们制定自动化功能验证策略，设计自动化功能验证用例。
2.自动化功能验证特点：
从终端用户角度设计创建自动化功能验证方案
以业务为重点进行自动化功能验证
映射业务影响，区分关键业务和外围业务，自动化功能验证重点关注关键业务
3.自动化功能验证实践要点:
共同创建验证方案：验证方案在创建之前，团队成员对对应功能特性的业务目标、业务价值达成共识。
验证左移：自动化验证要随着软件开发的进度渐进式的增加，而不是等功能开发完成再来写，让一开始就有自动化验证帮助提供反馈。
渐进式的自动化验证：自动化验证要随着软件开发的进度渐进式的增加，而不是等功能开发完成再来写，让一开始就有自动化验证帮助提供反馈。
验证右移：验证右移利用对终端用户行为和生产环境数据的分析，帮助优化业务、优化自动化功能验证质量。
验证资产的管理和复用：验证资产跟产品代码一起用版本控制工具管理，尽量复用原有验证资产，不要重复造轮子。这样可以提高验证效率，加速价值交付流程。
集体代码所有制：验证代码不应该是“二等公民”，团队应该共享自动化验证用例的维护职责。
人员能力建设：加强项目成员人员对于业务理解能力的培养，建立业务价值思维，提高业务敏感度，将有利于更好的理解业务价值，编写有价值的自动化功能验证用例。
4.BDD测试工具
Cucumber是BDD模式下实现可执行规范（Executable Specifications)的开源工具，不仅为自动化验收测试提供了强有力的支持，更在团队沟通、协作方面发挥了巨大作用。通过Feature文件和Step Definitions的结合，Cucumber构建了一个统一、高效的交流平台，使得业务、开发和测试人员能够使用统一的Domain Specific Language（领域特定语言）进行沟通，极大地提升了沟通效率和效果。
Features：用于描述软件的功能需求，以Feature为单位组织，每个Feature包含多个Scenario（场景），每个Scenario又由一系列Given、When、Then等步骤组成，清晰地定义了验证的场景和流程。
Step Definitions：对应于Features中定义的每个步骤，使用正则表达式匹配步骤描述，并编写相应的执行脚本（支持Ruby、JavaScript、Java等多种语言）。通过Step Definitions，Cucumber能够将自然语言描述的验证需求转化为可执行的测试代码，实现自动化验证。
六、总结
本文深入探讨了自动化验证在软件开发中的重要性及其实现策略。通过明确自动化功能验证的范围、特点和实践要点，本文为提升软件验证效率和质量提供了有力指导。同时，引入BDD测试工具Cucumber，展示了其在促进团队沟通、提升验证效率方面的独特优势，推动自动化验证在软件开发中的广泛应用，助力企业快速交付高质量软件产品。
参考文献
END
