1、 测试用例组织管理及维护
2、 测试执行的组织管理
经常性要写重复的用例，用例重用性不高，或差别很小但又不完全一样，还是要重写，且过程管理也乱
Codes 按产品型公司和项目型公司两种不同的方式来实现用例重用，也就是两库定位、需求驱动目录、同步机制、场景用例，以及它们对不同业务场景的支撑，再加迭代执行，形成一个环环相扣的完整体系
1、 产品型公司
有些公司做产品，理所当然用产品用例库 更合适，因为就算有定制的项目分支，公共的需求和用例是一样的，用例管理也需要用代码的分支来管理更恰 当，Codes 中的同步，就如同代码和合并，如果只有公共用例库，同步就有问题。
2、 项目型公司
有些公司只做项目，也就是项目导向，只需要从公共用例库导入公共用例到项目中即可，且项目有有共性的用例 可以推到公共用例库，每个项目的需求不一样，只需要重用与业务无关的公共用例就可以了。
核心设计理念：用例即代码，库即分支
Codes 平台中 “产品用例库” 和 “公共用例库” 的并存设计，其本质是将测试用例视为与代码同等的核心资产，并借鉴了代码版本管理（如 Git）的思想来进行用例的生命周期管理。这种模式颠覆了传统用例库单一的 “存储” 功能，构建了一个可流动、可协同、可演进的测试资产协作体系。
1. 产品用例库：项目的 “主干”（Master/Trunk）
内容：不仅包含测试用例，还按照需求结构进行目录组织（即 “左别的目录是按需求来建的”），使用例与业务需求天然映射，形成 “需求 ⇌ 用例” 的实时追踪矩阵。
定位：作为产品的核心基线，保存所有通用的、标准化的需求与用例资产，代表产品的主干发展脉络。
核心价值：它是产品型团队的核心资产库，确保所有项目分支拥有统一的产品灵魂。
2. 公共用例库：组织的 “公共组件库”（Shared Library）
内容：存放与具体业务逻辑解耦的、高度通用的基础用例（例如：登录验证、权限校验、通用 UI 组件操作、网络异常处理等）。
定位：作为组织级的可复用资产库，独立于任何单一产品线。
核心价值：它是项目型团队快速启动新项目的 “启动器”，也是整个组织测试经验沉淀与共享的 “知识库”
两个库并非孤立，而是通过灵活的同步机制协同工作，这正是整个模式的精髓。
双向同步，类似 “代码合并”：产品用例库与具体项目用例库之间支持双向同步。产品基线的更新（如新需求）可以 “合并” 到项目分支；项目中的优秀定制实践也可以 “反向合并” 回产品库，使主干持续演进。
选择性继承，类似 “按需拉取”：项目库可以从产品库或公共库中，按需求目录或模块有选择地拉取用例，而非全量复制。这避免了项目 “臃肿”，实现按需装配。
同步时有变更自动保存历史版本：任何同步操作引发的用例变更，系统都会自动记录历史版本，确保变更可追溯、可回滚。
产品用例库按需求来建目录，是以上所有协同能够高效、有序进行的关键设计。
清晰的逻辑单元：每一个需求及其附带的用例集，成为一个独立的、可识别、可追溯的逻辑单元，使同步操作可以精确到 “某个需求” 层面。
精准的同步粒度：产品更新时，只需同步变更的需求目录；项目定制时，也只需新增或修改自己独有的需求目录。这使得 “合并” 操作清晰可控，大大降低了冲突风险。
天然的追踪矩阵：构建了 “需求 ⇌ 用例” 的实时映射，方便进行覆盖率分析和影响范围评估，让 “测试左移”（需求阶段介入测试）有了具体载体。
在基础用例之上，系统支持构建 “场景用例” ，这是一种高阶的用例组织与复用形式。
定义：将多个已有的、具备独立功能的单一用例，按照特定的业务执行顺序（如 “先登录 → 再搜索商品 → 然后加入购物车 → 最后下单支付”）进行组合与编排，形成一个模拟真实业务流程的 “测试剧本”。
核心价值：
资产复用最大化：同一个基础登录用例，可以被编排进 “下单场景”、“退款场景”、“修改信息场景” 等多个业务场景中，无需重复编写。
聚焦业务流验证：测试设计从点（功能）上升到线（流程），更关注数据流转和系统间交互，能有效发现流程中的集成问题。
降低维护成本：当某个基础功能（如登录）的用例发生变更时，所有引用它的场景用例将自动继承更新，维护工作聚焦于一点。
提升测试设计效率：测试人员可以像搭积木一样，快速组合出覆盖各种业务路径的复杂场景，尤其适合回归测试和冒烟测试。
组织方式：场景用例可以独立组织，也可以关联到其覆盖的核心需求目录下，实现 “从需求到原子用例，再到业务流程场景” 的多维度覆盖。
*把多个单一用例编排组合为业务场景，也是 Codes 复用用例的另一种方式，且按业务场景来管理，一目了然。除了单一的功能用例，还有不同的业务场景，特别是流程类功能测试，有了场景不怕漏了，还便于管理。 *
脑图用例保持脑图的简洁，不用指定特殊的格式，保持脑图的本真用法
叶子节点是用例，其他作为模快。脑图也是以文件来维护，只是转标准用例后，两边双向同步
标准用例也可显示为脑图视图
此模式最大的优势，在于能用一套机制，完美适配两种截然不同的公司业务模式：
场景一：产品型公司（有定制项目分支）
痛点：需要维护产品核心基线，同时管理多个客户的不同定制版本。若只有单一公共库，定制差异无法管理，同步困难。
Codes 的解决方案（主干 - 分支模型）：
使用 产品用例库 作为 “主干”，保存标准需求与用例。
为每个定制项目创建独立的 项目用例库 作为 “分支”。
产品基线更新时，像代码合并一样，将变更同步到各项目分支。
项目特有的定制需求和用例，只存在于其自己的项目库分支中，与主干和其他分支隔离，互不干扰。
场景用例支持：主干中的核心业务场景用例，可作为标准同步到各分支；分支也可以编排自己独有的定制场景，而不会影响产品基线。
价值：清晰管理 “共性” 与 “个性”，使产品演进与项目定制并行不悖。
场景二：项目型公司（以项目交付为导向）
痛点：每个新项目都要从零编写基础用例，效率低；项目间缺乏资产复用与沉淀。
Codes 的解决方案（资产库 - 使用项目模型）：
将 公共用例库 作为组织级资产库，沉淀所有项目的通用测试资产。
新项目启动时，从公共用例库按需导入（拉取）基础用例，快速搭建测试框架。
项目完成后，将其中共性的、有价值的用例反向推送（沉淀）到公共用例库，丰富组织资产。
场景用例支持：公共用例库可以沉淀经典业务场景模板（如 “电商标准下单流程”），新项目直接导入并稍作适配即可使用，极大加速测试准备。
价值：实现测试资产的 “共享→使用→沉淀” 闭环，显著降低新项目启动成本，并让组织能力持续积累。
这是整个用例管理体系从 “设计” 走向 “执行” 的关键。Codes 以迭代作为核心组织单元，将测试计划、分配、执行、跟踪与度量整合为一条清晰的闭环流程，解决了传统测试计划中 “执行人靠口头约定”、“进度不透明” 等痛点。
状态驱动：迭代设有 “提交测试 → 测试中 → 测试完成” 三个关键状态。状态切换时，系统会自动通知相关人员（如提测通知、完成报告），使测试进度与研发节奏同步。
信息聚合：迭代下集中管理该轮测试涉及的所有需求、用例、缺陷和交付物，所有活动可追溯，确保团队信息对齐。
测试经理可按顺序完成四步，实现高效分工与执行：
执行成本：每个用例都设有 “执行成本”（即预估执行用时），用以科学衡量工作量，避免仅以用例数量论英雄。
工时统计：系统可基于执行成本，自动统计每位测试人员、每个迭代的实际执行工时，为工作量评估和效能分析提供客观数据。
迭代有三个测试相关的状态：设置迭代为提交测试状态时，将整个迭代的下的需求，和待处理的缺陷提测，会自动给测试人员发通知；然后设置迭代为测试中，表示在进行测试了，设置迭代为测试完成也会给项目全员发通知和迭代报告。交付物放迭代下含测试在内的一切文档。详见。《记 Codes 研发管理平台——多事项闭环迭代的创新实现》。
现实中在某一轮测试中一定是不同的人执行不同的用例，然后测试经理能需要知道整体的测试进度和每个人的测试进度。而传统的测试计划有一个很大的弊端：计划下只分配了用例，没法指定执行人。可能执行人是通过口头约定，口口相传不方便管理；也可能不同人建不同的测试计划，这增加了工作负担，同时没法查看整体进度。
如下图所示，第一步先分配用例，第二步分配执行人，第三步执行用例。另外还可在不同的视图间切换。
还可以在执行人、状态、类别、优先级、需求和脑图视图间切换。下图为脑视图。
如果是回归测试或是对测试用例很熟，可以批量快速执行，如下图所示，左边的树上显示当前执行人所分配用例对应的需求，及各需求下用例数和执行数，如执行完会一个勾。当然也可导出后线下执行再同步到线上。
也就是要执行哪些用例。迭代下，分解需求为用例时，会自动把所分解的用例自动分配到当前迭代下，其他用例需要手动来分配。如下图所示：
上图中 “分配” 表示把勾选的用例分配到迭代下，可跨页选；“全部分配” 表示把当前查询到的所有用例分配到迭代下；最后一个按钮表示把左则需求树上所勾选的需求下的用例分配到当前迭代下。
另外，测试用例如何计算执行工时,全网只有 Codes 有解决办法。每个用例有执行成本，也就是执行用时，通过执行成本可以统计到执行用例用时情况，用例个数的多少不代表执行用例工作量。
也就是执行用例的人员分工。左边的树显示当前迭代下所有用例对应的需求，且树上各节点上显示用例数和已分配执行人的用例数，如已分完会显示一个勾。分配执行人时，可手动一个一个勾选用例后再分配到执行人，也可在左边树上直接勾需求后把需求下的用例分配给某个执行人
除了上面的快速执行外，我们再来看看用例的常规执行
常规执行会一个一个弹窗显示用例明细，左则显示当前执行人所分配用例对应的需求，及各需求下用例数和执行数，如执行完显示一个打勾。如下图所示：
如果只用脑图用例，直接把脑图文件分到一个或多个迭代下，然后直接在脑图中执行用例，只是在执行前先切换到在哪个迭代下执行即可，从用例管理中心脑图维护中进入。可以导入 Xmind ，也可直接在 web 编写脑图。
“产品用例库” 与 “公共用例库” 并存，以需求为目录结构，通过双向同步机制协同，叠加 “场景用例” 实现业务流程编排，再以 “迭代” 为单元完成测试执行的组织、分配、跟踪与工时统计——这四层设计环环相扣，共同构建了一个从资产沉淀、设计复用到执行落地的完整测试管理闭环.。
它将用例管理从静态文档维护，提升到了 *动态资产协同、业务场景建模与精细化执行管理 *的层面。这套体系的核心价值在于：
让测试用例不再是静态的文档，而是像代码一样可分支、可合并、可复用、可编排、可执行、可度量的活资产。
它是支撑规模化、差异化、复杂化敏捷测试的坚实基础，使测试资产真正成为企业可以持续积累、灵活组合并高效执行的 核心智力资本。
