很多团队把ALM用起来以后，最先乱掉的往往不是执行本身，而是Test Plan和Test Lab的边界没有先定清。按OpenText ALM当前官方说明，Test Plan的职责是按功能拆出测试主题、测试用例、步骤和配置，并建立需求覆盖；Test Lab的职责则是把已经设计好的测试按版本、周期和目标拉进测试集执行，同一个测试被加入测试集后，会以test instance的形式存在。先把这两层分开，后面目录、批量执行和结果回看才不容易打架。

　　一、ALM测试管理怎么搭

　　ALM里的测试管理，不适合一上来就先建很多测试集，更稳的顺序是先搭Test Plan，再进Test Lab。因为官方对Test Plan的定义很明确，它本来就是按功能把应用拆成不同testing area，再在其下继续放测试和步骤。

　　1、先按业务功能建测试主题

　　在【Test Plan】里先建subject folder，也就是测试主题目录。官方写到，subject是把同一测试领域的测试收在一起的文件夹，而且一个系统通常需要先按功能拆层级，再往下放测试。这样做的好处，是先把功能边界定住，不让测试树一开始就变成按人名或按时间随手堆。

　　2、再在主题下建测试用例

　　目录有了以后，再在对应文件夹下用【New Test】建测试。官方说明里提到，测试在这一层要先定义名称、状态、设计人等基础信息，随后再补设计步骤，所以这一层更适合管用例资产，不适合直接塞执行批次。

　　3、步骤和配置分开管

　　ALM不只支持test steps，还支持test configuration。官方文档说明，配置可以让同一个测试在不同数据集或运行环境下复用，而且还能把需求覆盖细到具体配置级别。也就是说，遇到同一流程多环境复测时，优先补配置，不要急着复制出一串几乎相同的测试。

　　4、需求覆盖尽量在计划层完成

　　官方在Test Plan说明里明确要求，把测试和需求树建立coverage关系；Requirements模块也支持直接把需求转换成测试主题、测试、步骤，转换后会自动建立coverage。这样搭起来的测试树，后面看覆盖率和缺口会直接很多。

　　二、ALM测试计划与测试集怎么组织

　　Test Plan管的是测试资产，Test Lab管的是测试执行，这个边界不要混。官方对test set的说明很清楚，它是为特定测试目标挑出来的一组测试，而不是新的用例仓库。

　　1、测试计划按功能，测试集按版本和周期

　　Test Plan里的树建议长期按功能域、子模块、场景类型组织。到了【Test Lab】，再按版本、里程碑、迭代、回归轮次去建test set folder。官方示例里就给出了Release 10.5和Cycle 1这样的目录组织方式，这种分法最适合执行管理。

　　2、一个测试集只收一个执行目标

　　官方定义里，test set是为specific test goals服务的一组测试。所以新功能冒烟、版本回归、补丁验证、环境验收，最好拆成不同测试集，不要把所有目标都塞进一个大集合里。测试集一旦目标太杂，后面看通过率、失败分布和重跑范围都会很乱。

　　3、加入测试集的是实例，不是复制新用例

　　ALM里把测试加入测试集以后，进入的是test instance。官方说明还提到，一个test instance绑定具体test configuration，这意味着同一条测试可以在不同测试集里多次出现，用于不同场景执行，但源用例仍然留在Test Plan里统一维护。

　　4、批量编排优先从计划树或需求树选

　　在Test Lab里加测试时，官方支持从【Test Plan Tree】直接选，也支持从【Requirements Tree】把覆盖相应需求的测试拉进来。对团队来说，前者更适合按模块组批次，后者更适合按需求范围组批次，两种入口最好固定一种主用法，避免同类执行批次来源不一。

　　三、ALM层级边界怎么定

　　很多团队不是不会建树，而是建到后面Test Plan和Test Lab各管一半，边界越来越模糊。要把后续维护成本压下来，最关键的是先把层级职责定死。

　　1、计划层只管资产，不管轮次

　　测试主题、测试、步骤、配置、需求覆盖这些都留在Test Plan。凡是会跨版本长期复用的内容，都不要挪去Test Lab管。这样以后改步骤、补参数、修覆盖关系，只改一处就够。

　　2、执行层只管批次，不改源用例结构

　　Test Lab更适合管理发布节奏、执行顺序和实例状态。官方说明里，test set tree本来就是分层组织执行过程的地方，所以它的目录应围绕发布和周期展开，而不是再复制一份功能树。

　　3、复制测试集可以有，复制测试树要慎用

　　官方支持跨项目复制测试和测试集，也支持复制test instance，但运行历史不会跟着复制，复制后的实例默认为No Run。也就是说，复制更适合拿来复用批次骨架，不适合当成日常维护主方式，否则历史和口径会越来越散。

　　4、先定命名规则再大批量建

　　功能树可以按模块名加场景名命名，测试集树则统一按版本加周期加目标命名。这样同一眼看过去，就能分清哪个是长期资产，哪个是本轮执行。虽然这一步是管理做法，但它正好顺着官方对Test Plan和Test Lab的职责拆分来定，后面最省事。

　　总结

　　ALM测试管理怎么搭，关键不是先建多少测试集，而是先把Test Plan里的功能树、用例、步骤、配置和需求覆盖搭稳。ALM测试计划与测试集怎么组织，重点也不是两边都建成同一棵树，而是让Test Plan长期管测试资产，让Test Lab专门管版本批次和执行实例。这样搭下来，覆盖关系清楚，执行层也不会越做越乱。