迭代越快，交付越乱——问题到底出在哪一步？

文章主旨：

禅道通过“构建”功能，把开发完成到正式发布之间的可测试代码包作为业务层面的测试单位，明确测试范围并关联需求与Bug，从而打通研发与测试之间的信息断层，提升交付质量与协作效率。

关键要点：

1. 软件开发中常见问题是交付包内容不清晰、测试范围不明确，导致返工、遗漏和反复沟通。
2. 禅道“构建”指开发过程中产生的潜在待测试代码包，代表当前进度下已完成的部分内容，核心作用是明确测试范畴。
3. 构建不同于Git Tag：Git Tag是代码层面标记，禅道构建是业务层面的测试单位，可关联完成的需求、产生的Bug和解决的Bug。
4. 构建对开发是交付节点，对测试是工作清单，对项目经理是进度可视化抓手，填补“开发完成”到“正式发布”之间的管理空白。
5. 跨迭代场景可使用“集成构建”，将多个迭代构建中完成的需求和解决的Bug打包进行集成测试，适用于阶段性测试、多分支并行和Bug回归验证等场景。

内容结构：

1. 背景问题：交付包内容不清晰，测试范围不明确

软件开发中，交付包内容不清晰会导致测试范围模糊，随着项目规模和节奏提升，问题会被放大，表现为返工、遗漏和沟通拉扯。团队之间缺少一个准确传递“这次到底有什么”的载体。

2. 什么是构建？

在禅道中，“构建”对应软件配置管理中的Build，指开发过程中产生的一个潜在待测试代码包。它未必包含一次发布的所有内容，仅代表当前进度下完成的部分内容。通俗地说，开发完成一些需求和Bug后，把当前已完成内容打包，这个包就是“构建”。其主要作用是明确测试范畴，方便测试与开发互动，并解决不同版本发布和Bug修复等问题。

3. 为什么团队需要重视构建？

原文提出，不能仅用Git打Tag替代构建。Git Tag是代码层面标记，而禅道构建是业务层面的测试单位。一个构建下关联了什么需求、解决了什么Bug、产生了什么新Bug，这些信息才是测试人员真正需要的。随着产品变大、模块增多，一次发布可能涉及多个团队和模块，构建可帮助圈定测试范围，避免关键内容遗漏。

4. 引入构建能给团队带来什么改变？

• 对开发：构建是一个交付节点。每完成一批需求或修复一批Bug，打Tag、建构建，意味着一次明确产出，进度可拆成小块，风险也被切小。
• 对测试：构建是一份工作清单。测什么、不测什么、测的是哪份代码，构建页面清楚呈现；关联需求和Bug后可提交测试、创建测试单，围绕圈定范围执行测试用例，让缺陷尽量在构建阶段被圈定。
• 对项目经理或团队负责人：构建是进度可视化抓手。已通过测试、等待测试、未解决Bug等数据直接决定能否发布、何时发布，而不是依赖口头汇报。

5. 三步上手：从创建构建到提交测试

1. 创建构建：开发团队完成需求或解决Bug后，可在代码版本库创建Tag，项目负责人在禅道「执行-构建」中创建构建记录，填写所属产品、应用、版本库地址。若关联多个产品或分支，可下拉切换。
2. 关联需求和Bug：构建创建后，可关联三个维度：完成的需求、产生的Bug、解决的Bug。关联后，测试人员打开构建详情即可明确测试范围，开发也不易被追问Bug是否修复。
3. 提交测试：点击「提交测试」跳转到测试单创建页面。系统可列出此前构建的测试报告供参考。测试单创建后，测试人员可在「项目/执行→测试→测试单列表」中查看待测构建。

6. 跨迭代怎么办？集成构建上场

单一构建解决一次迭代的问题，真实项目更复杂。若一个项目下有三个迭代，每个迭代各有构建，集成测试阶段需要把多个迭代内容打包一起测，这时可使用“集成构建”。在项目下创建构建时选择「集成构建」类型，关联多个包含构建，相关构建下的需求、Bug会自动汇聚到集成构建中，其他操作与单一构建一致。集成构建解决的是阶段性验证和最终全局验证问题，减少逐迭代翻找和整合的琐碎流程。

7. 落地实操：适用场景

• 场景一：迭代开发中的阶段性测试。迭代中期，开发完成部分需求后创建构建并提交测试，测试人员基于关联需求测试，及时反馈问题，保障迭代结束交付高质量版本。
• 场景二：多分支并行开发的版本管理。团队同时维护稳定版和开发版等分支时，可通过构建清晰区分不同分支代码包，针对每个分支创建独立构建，避免版本混淆；发布新版本时可用集成构建整合多个分支变更并全面测试。
• 场景三：Bug修复验证与回归测试。上线后发现关键Bug，开发修复后创建包含所有修复的构建，测试人员针对构建中“解决的Bug”进行验证，并按需执行回归测试，确保Bug已修复且未引入新问题。

8. 打通研发测试断层，让交付更有质量

禅道“构建”功能本质上是在测试策略和发布流程这两个容易出问题的环节上，给团队提供可落地的抓手。软件工程中的很多难题，往往不是靠花哨工具解决，而是把基础环节做到位。分而测之是效率策略，最终验证是质量兜底，禅道构建功能帮助团队让这两件事更可控。

9. Q&A摘要

• 构建的理解及其与项目、任务的关系：构建是开发过程中的可测试版本，下面关联已完成研发需求和已修复Bug；测试单提交给测试负责人后，不合适的内容可由测试负责人修改；测试类型、参与人等为非必填。
• 创建测试单可以不关联构建吗？构建必须关联，否则逻辑走不通；测试单基于构建版本进行测试，没有构建版本则测试和测试报告缺少基础。
• 项目下创建的构建和在执行下创建的构建有区别吗？没有区别，只是展示维度不同，执行下创建的构建也会同步到项目下。
• 什么时候创建构建？一般是提测前创建构建版本，创建测试单时关联构建，发布时关联多个已测试完的构建。
• 构建与发布的关系和区别：一次发布可以包含多个构建；构建更偏向内测小版本，发布是需求开发完成并测试通过后对外发布或上线。
• 为什么关联完成的需求时，还能关联评审中等状态的需求？完成的需求一般指阶段为研发完毕的需求；激活、评审中状态下的需求阶段都可能是研发完毕，只有草稿阶段不可关联到构建的已完成需求下。

文章总结：

禅道“构建”功能通过把基础环节做到位，明确测试范畴并支撑集成验证，帮助团队打通研发测试断层，让交付更可控、更有质量。