很多团队在用ALM提缺陷时，问题往往不在“有没有提”，而在“提得能不能直接流转”。OpenText ALM的【Defects】模块本身就是用来创建和跟踪缺陷的，既支持在缺陷模块里新建，也支持在测试执行过程中直接提交；如果缺陷是在测试集运行时提交，系统还会自动把这条缺陷和对应的运行、发布与周期信息关联起来。

　　一、ALM缺陷怎么提

　　缺陷提得顺不顺，核心不是把字段填满，而是让开发、测试和负责人一眼就知道这条问题是什么、能不能复现、该归谁、什么时候要处理。ALM官方创建入口很明确，从【Defects】模块点击【New Defect】就能进入新缺陷窗口，后面所有质量都取决于字段内容本身。

　　1、先从正确入口新建缺陷

　　在【Defects】模块点击【New Defect】新建，是最稳妥的常规做法。如果你是在测试执行里发现问题再提缺陷，ALM会自动把新缺陷和测试运行、关联的发布与周期挂上关系，后面回查来源会轻松很多。

　　2、先把摘要和现象写到能被快速判断

　　【Summary】是缺陷摘要，【Description】是详细说明，官方还提供【Find Similar Defects】来帮助你在新建时查重，避免同一问题被多人重复提交。更实用的写法是，摘要直接写出功能点加异常现象，详细说明里再补触发步骤、实际结果、期望结果和影响范围，这样triage时不用来回追问。

　　3、把发现信息一次补齐

　　ALM缺陷字段里本来就有【Detected By】、【Detected on Date】、【Detected in Version】、【Detected in Release】、【Detected in Cycle】、【Detected on Environment】和【Reproducible】这些信息，其中【Detected By】是必填系统字段，【Severity】也是必填系统字段。【Reproducible】默认是Y，适合直接用来区分稳定复现和偶发现象。

　　4、提完后别停在新建状态

　　ALM缺陷状态本身支持New、Open、Fixed、Closed、Rejected和Reopen。更稳的流程是，新缺陷先由测试提交，评审后再改成Open并指派【Assigned To】，同时补上【Target Release】和【Target Cycle】；这样开发知道谁来修，版本负责人也知道这条缺陷准备落到哪一版。

　　二、ALM缺陷字段严重度优先级怎么定

　　在ALM里，【Severity】和【Priority】是两个独立字段，典型取值都可以是1-Low到5-Urgent；其中【Severity】来自严重度自定义列表，【Priority】来自优先级自定义列表。官方还给了项目脚本示例，说明系统完全可以根据【Severity】自动回填【Priority】，这也说明两者应该分开治理，而不是混着用。

　　1、严重度先看影响，不先看排期

　　更稳的定法是，把【Severity】理解成问题本身有多重。只要是核心流程阻断、数据错误、结果不可信、权限或安全风险，这类就该往高严重度走；如果只是界面错字、样式偏差、低频边角问题，严重度就不该抬得太高。这样定，后面统计缺陷质量和风险分布才有意义。

　　2、优先级再看先修谁

　　【Priority】更适合表达修复顺序。哪怕两条缺陷严重度一样，如果一条压在本期上线主路径上，另一条落在低频功能里，它们的优先级就不该一样。一个实用原则是，优先级跟当前发布目标、业务窗口、客户影响和修复时机绑定，而不是只看技术影响。

　　3、给团队一张统一判断表

　　比较好落地的做法是这样分。

　　1级严重度，系统基本可用，问题影响小，通常配1级到2级优先级。

　　2级严重度，功能受影响但有绕行方案，通常配2级到3级优先级。

　　3级严重度，主流程受损或结果明显异常，需要结合当前版本窗口决定是否提到高优。

　　4级严重度，关键能力明显失效，通常应该进入高优先级。

　　5级严重度，业务阻断、数据风险或紧急线上事故，优先级原则上直接拉到最高。

　　这种分法不是ALM强制定义，但和ALM把严重度、优先级分成两套列表，以及支持用脚本按严重度联动优先级的机制是吻合的。

　　4、不要让严重度和优先级永远相等

　　很多团队最常见的错误，就是Severity填4，Priority也顺手填4，最后两个字段失去意义。更好的做法是让严重度描述问题本身，让优先级描述当前处理顺序；必要时还可以像官方脚本示例那样，在项目工作流里规定高严重度自动把优先级提到最高，减少人工判断漂移。

　　三、ALM缺陷流转为什么总是反复

　　缺陷在ALM里来回打回，通常不是因为系统难用，而是前面字段规则没定好。ALM既支持缺陷和需求、测试、测试集、运行、运行步骤互相关联，也支持按状态持续更新；如果摘要含糊、复现信息不全、版本字段空着、状态切换没有口径，后面就很容易出现Reopen反复增加的情况。

　　1、先把新建口径固定住

　　至少要让摘要、详细说明、复现性、发现版本、发现环境、严重度成为团队默认必看项。官方字段里这些信息本来就都有，只要新建时就填清，后面沟通成本会明显下降。

　　2、再把状态切换条件说清

　　ALM的状态并不复杂，但如果团队没约定，New、Open、Fixed、Closed、Rejected、Reopen很容易乱跳。比较稳的做法是，新提缺陷先进New，评审通过再进Open，开发修完进Fixed，测试验证通过再进Closed，验证失败才回Reopen。这样每一步都有人负责，字段也能跟着补齐。

　　3、让版本和周期字段真正参与管理

　　【Target Release】和【Target Cycle】不是装饰字段。官方说明里已经写明，缺陷可以指定目标发布和目标周期，测试执行里发现的问题还会自动继承关联的发布与周期。把这两个字段用起来后，版本负责人才能真正按发布窗口拉缺陷清单，而不是靠人肉翻表。

　　4、能自动化的判断尽量别手工反复改

　　如果你们团队已经有比较明确的严重度和优先级关系，直接用项目脚本做联动会更稳。官方示例已经给出按【Severity】更新【Priority】的写法，这说明ALM本身就支持把这类规则固化进工作流里，减少同一类缺陷在不同人手里被判成不同等级。

　　总结

　　ALM缺陷怎么提，关键不是把单子建出来，而是让【Summary】、【Description】、复现信息、版本周期和指派信息一次到位。ALM缺陷字段严重度优先级怎么定，关键也不是两个字段填得越高越好，而是让【Severity】回到问题影响，让【Priority】回到处理顺序。把这两层分开，再把状态流转和字段联动规则定住，ALM里的缺陷管理才会真正顺起来。