在Jama Connect里，测试不是一上来先建测试计划，而是先把测试用例作为item建出来，再把它们组织进测试计划、测试组和测试周期。官方帮助把这条链路写得很清楚：测试用例先创建并直接关联到要验证的需求，再创建测试计划，把测试用例加入计划并按组组织，之后在测试计划里创建一个或多个测试周期，系统会为周期里的每个测试用例自动生成test run，测试结果再回卷到test case status。

　　一、Jama Connect测试用例怎么建

　　Jama Connect里的测试用例，本质上还是item，只是这个item type被组织管理员配置成了“Use as Test Case”。官方文档明确说明，任何item type都可以被设置成Test Case；一旦被设置成Test Case，它就会具备test steps和test case status字段，并且可以在测试计划里被使用。

　　1、先把测试用例类型定义清楚

　　如果你们组织还没把item type配成测试用例，后面就算名字叫“测试用例”，它也进不了测试流程。比较稳的做法，是先由组织管理员确认一个或少量几个item type被设为Test Case。官方还特别给了best practice，item type越少，整体越容易管理，所以这里不要一开始就拆出太多测试用例类型。

　　2、测试用例本身按普通item去创建

　　官方帮助明确写到，测试用例的创建方式和其他item一样，都是在Jama Connect结构里创建和组织。也就是说，日常建测试用例时，不需要先跳进测试计划里建，先在项目结构里把test case item建出来，再考虑后续复用和执行会更稳。

　　3、每条测试用例尽量只表达一个清晰验证点

　　官方把test case定义为“用于验证某个产品特性或系统的一组具体测试”，并且强调它有自己的test steps和status。落地时更稳的做法，是让每条测试用例围绕一个明确验证目标写步骤，不要把多个功能点塞进同一条test case，不然后续test run结果和追踪关系都会变得很难解释。这里“单一验证点更稳”是基于官方测试对象和结果回卷逻辑作出的实践建议。

　　4、测试用例建好后要直接连需求

　　官方测试流程页明确写到，第一步就是创建test cases，并把它们直接关联到被验证的requirements；执行后，Jama Connect还会自动建立test case到test run的trace，并在Trace View里显示。也就是说，测试用例不是独立资产，真正有价值的是它和需求、执行结果之间的链路。

　　5、需要复用时优先考虑放进测试用例库

　　官方帮助说明，测试用例既可以直接组织在项目里，也可以组织在test case library中以便复用，并且还可以跨项目复用。对团队来说，如果有大量通用回归用例、平台级验证用例或跨版本共用用例，这一层最好尽早收口，不要每个项目各自复制一份。

　　二、Jama Connect测试资产如何组织

　　Jama Connect的测试资产组织，不是把所有测试用例扔进一个大目录就结束了。官方测试模型已经把对象层级拆开：测试用例是item，测试计划也是item，测试组是测试计划里的组织方式，测试周期则是把测试用例转换成待执行test runs的执行容器。这里最关键的一点是，test group本身不是item，没有item type，也没有全局ID或唯一ID。

　　1、先把测试用例按项目结构组织

　　官方items文档说明，项目结构里可以用component、set、folder这些容器来管理item；而测试用例本身也是在这套结构里被创建和组织的。实际落地时，最稳的第一层组织通常还是先按产品模块、子系统、能力域或版本范围，把test cases放进清晰的component或folder结构里。

　　2、测试计划单独承载“怎么测”

　　官方明确把Test Plan定义为记录整体验证或确认策略的item，它的详情页也分成Overview、Test Cases、Test Runs三个视图。也就是说，测试计划不适合拿来替代测试用例仓库，它更适合承载测试目标、测试范围、入口出口条件和这轮执行准备怎么组织。

　　3、测试组用来做计划内分桶，不要拿它当长期主结构

　　官方说明里，test group是测试计划中组织并可选分配test cases的方式，一个test case在同一个test plan里只能出现在一个group中；而且group可以按产品某个方面、测试地点、特定测试人员等维度来组织。因为test group不是item，所以更适合作为“某个计划里的执行分桶”，而不是整个组织的长期测试资产主结构。

　　4、测试周期用来承载“这一轮怎么跑”

　　官方Add a test cycle文档写得很清楚，创建test cycle时要从test plan的groups里选范围，保存后系统会为关联test case自动创建test runs。换句话说，cycle更像一轮执行批次，不适合作为长期归档测试资产的第一层目录。实际组织时，让plan管策略，让group管计划内分桶，让cycle管执行轮次，会更清楚。

　　5、测试资产组织优先按“可复用结构”，执行再按“计划和周期”展开

　　结合官方模型，更稳的做法通常是：长期资产层面按component、set、folder和test case library去收口，保证test case可复用；执行层面再通过plan、group、cycle去组合当次测试范围。这样既不会把资产和执行混在一起，也能保住跨项目复用能力。这一组织建议是基于官方对象职责作出的归纳。

　　三、Jama Connect测试资产落地时怎么收口

　　如果团队刚开始搭测试体系，最容易犯的错通常有两个。一个是item type设计过多，导致维护成本上升；另一个是把test groups当成长期结构，结果到后面很难复用。官方文档实际上已经给了比较明确的边界，所以落地时照着边界收口，会省很多后续整理成本。

　　1、测试用例类型不要拆太多

　　官方明确建议item types越少越容易管理，而且item type还是全组织级别可用、不能按单个项目单独定制的。也就是说，测试用例类型一旦拆多了，不是影响一个项目，而是会影响整个组织的测试建模口径。

　　2、项目结构负责沉淀，测试计划负责执行

　　官方测试流程把test case创建和test plan创建分成两个连续步骤，本身就说明两者不是同一层对象。前者更适合做长期沉淀，后者更适合围绕某次验证活动组织执行。把这条线分清，资产复用和测试执行都会顺很多。

　　3、组内组织尽量围绕执行口径

　　官方Add test cases to a plan文档举得很直白，group可以按产品某个方面、测试地点或某个测试人员来组织。也就是说，group最适合服务执行安排和视图清晰度，而不是承担长期建模职责。

　　4、结果追踪回到test run和trace上看

　　官方说明中，test run是执行记录，和test case、test cycle、test group、test plan都会自动建立关联；test run结果还会回卷到test case status。对治理来说，真正该盯的是test case到需求的关联，以及test run到执行结果的闭环，而不是只看树里放了多少测试项。

　　总结

　　Jama Connect测试用例怎么建，最稳的顺序是先由组织管理员定义少量清晰的Test Case item type，再按普通item的方式把测试用例建在项目结构或测试用例库里，并直接关联到要验证的需求。Jama Connect测试资产如何组织，最适合的分层则是：长期资产按component、set、folder和library来沉淀，执行层再通过test plan、test group和test cycle组合出当次测试范围。把资产层和执行层分开以后，测试用例既能复用，测试活动也不会越做越乱。