步骤里有失败项，测试运行却显示已经结束；用例这次执行通过了，工作项状态仍停在审核中。看到这些情况，先别急着改结果。Polarion里的步骤判定、测试记录结果和测试运行状态分别记录不同内容，用例工作项还有自己的流程。需要查清页面显示的是哪一项，再判断数据有没有写错，以及项目规则是否真正限制了状态转换。

　　一、Polarion如何设置测试运行的结果判定规则

　　设置前先约定通过、失败、阻塞的含义，再决定什么条件下允许结束测试运行。下面使用英文界面名称，具体选项以部署版本为准。

　　1、核对测试结果选项

　　①进入目标项目，打开【Administration】→【Testing】→【Test Results】，查看当前结果枚举。

　　②检查【ID】与【Name】，保留自动化接口已经使用的结果标识，按项目要求维护显示名称。

　　通过应代表预期结果得到满足；失败表示实际行为不符合预期；环境或前置条件导致无法继续时，可以使用项目定义的阻塞结果。不要把“没有执行”归到通过，也不要只为改变统计颜色修改枚举。

　　结果选项决定记录可以填写什么，不会仅因新增一个“通过”名称，就自动形成步骤汇总和结束运行的判定逻辑。

　　2、在工作流中限制结束条件

　　①打开【Administration】→【Testing】→【Test Run Workflow】，点击目标测试运行类型旁的【Edit】。

　　②点击对应结束动作旁的【Edit】，查看【Conditions】与【Functions】配置。

　　③需要自定义校验时，在【Conditions】中选择【ScriptCondition】，点击【+】，再通过【Edit】配置已部署脚本的【engine】和【script】参数。

　　例如项目要求“全部执行完成且没有失败项”才能结束，就需要条件校验同时检查未执行、失败及阻塞记录，按约定决定是否放行。已有条件能够满足时直接使用；采用脚本时，须先实现并验证脚本，填写脚本名称本身不会生成规则。

　　工作流条件负责限制动作能否执行，函数负责动作发生时的处理。两者应分开核对。

　　二、Polarion测试记录状态与执行结果不一致如何复核

　　找一条有争议的记录，从所属运行、步骤结果和总体结果往下查，比直接修改整批状态更容易定位。

　　1、确认查看的是同一次执行

　　①打开【Test Runs】，选择目标运行，进入【Test Records】。

　　②点击对应测试记录，核对【Executed】、【Executed By】及关联用例。

　　③存在参数化执行时，展开用例下的迭代记录，选择发生问题的那一行。

　　同一个用例可能在不同版本、环境或参数下多次执行。列表中的一次通过，不能用来解释另一条失败记录。复核时应同时确认项目、运行ID、用例及迭代，避免只按用例标题对照。

　　2、对照步骤判定与总体结果

　　①在测试记录中打开执行详情，逐项查看【Test Steps】里的结果及说明。

　　②对照总体【Result】，检查【Passed】、【Failed】或【Blocked】是否与执行证据相符。

　　步骤判定与总体结果分别保存，不宜假定任何导入或自定义流程都会自动把它们汇总一致。若某步失败、总体却通过，要查总体结果由谁填写、是否存在人工覆盖，以及接口是否只提交了总体结果。

　　不应为了消除页面差异，把有失败证据的步骤直接改成通过。

　　3、区分运行状态和用例工作项状态

　　①返回运行页面，查看【Test Run Status】，再进入【Test Records】核对结果分布。

　　②点击记录关联的用例，打开工作项，查看【Status】。

　　测试运行已经结束，可以同时保留失败记录，是否允许这样结束由工作流决定。用例工作项处于审核、批准等状态，则通常描述测试规格的生命周期，不能据此推断本次执行通过与否。

　　只有项目配置了明确的联动规则，才应期待这些状态随执行结果变化。

　　4、复核导入与接口写入

　　①打开【Administration】→【Testing】→【Test Results】，对照导入程序使用的结果ID。

　　②回到目标运行的【Test Records】，选择导入记录，检查结果、执行时间和备注。

　　使用REST导入时，请求被接受不代表导入已经成功，应继续核对任务最终状态和日志。直接创建Test Record与手工执行动作也有区别，例如缺陷创建和关联可能需要调用方单独处理，不能只因缺陷没有生成，就认定结果没有写入。

　　三、Polarion判定规则修改后如何验证

　　在测试项目中保留几组明确输入，检查规则是否按预期放行或拦截，再用于正式测试运行。

　　1、分别验证通过和未完成场景

　　①打开测试运行，点击【Execute Tests】，选择测试用例并点击【Start Test Case】。

　　②完成操作后选择【Passed】，再检查【Test Records】中的结果。

　　另建包含未执行项的运行，尝试结束动作。这样可以检查规则是否遗漏未执行记录，避免只统计“已有结果的用例”就允许结束。

　　2、用失败记录检查结束条件

　　①在测试用的执行表单中选择【Failed】或【Blocked】，填写对应执行说明。

　　②返回运行页面，通过【Test Run Status】尝试项目配置的结束动作。

　　预期拦截却仍能结束时，回到该运行类型的工作流检查条件。规则可能配在另一个类型或另一个动作上，不能只看配置页面里是否存在脚本。

　　3、核对结果复用的适用范围

　　①打开执行详情中的【Recent】，查看可复用的历史结果。

　　②对照本次测试对象、参数和步骤，再决定是否选择历史记录。

　　历史结果能够减少重复填写，但不能替代本次验证。尤其是预期结果已经修改的用例，应重新确认执行证据，避免把旧版本结论带入当前运行。

　　总结

　　一份测试报告里出现“已结束”和“存在失败”并不一定矛盾，真正需要交代清楚的是：这批测试按什么条件结束，失败项如何处理，哪些内容仍待验证。如果项目允许带着已评审的问题结束运行，就应让这项决定有对应记录，不能靠改成绿色表达放行。希望这些操作能帮到大家，减少执行人员与报告审核人员对状态含义的误解，也让后续复测能够找到准确对象。如有相关需求，欢迎交流咨询。