在Polarion软件中进行测试管理的时候，测试人员不能仅仅把测试用例看作是一份简单的“测试步骤清单”，更重要的事情是，需要把测试用例、原始需求、测试计划、实际执行结果以及缺陷记录等内容都串联在同一条链路当中；由于建立了这种链路，管理层在后续工作中才能够清楚地了解到哪些需求已经设计了对应的测试，哪些需求目前还没有被测试覆盖，以及哪些测试的失败会直接对哪些需求产生波及；Polarion QA主要被用于测试用例的设计、测试活动的协调以及测试过程的跟踪，同时Polarion ALM也比较看重在统一的环境里面去把需求、开发和测试工作一起管起来。

　　一、Polarion测试用例怎么管理

　　测试用例的管理工作，首先需要解决“用例放在哪、用什么结构去放、怎么去执行、怎么把结果留下来”这几个基础问题；测试人员如果只是单纯地创建了Test Case其实还不够，要是分类方式、填写的字段以及执行记录没有做好统一，那么到了后期，团队就会很难去统计测试的覆盖率以及整体的测试进度。

　　1、把测试用例的分类建立起来

　　测试人员可以根据【功能模块】、【需求层级】、【测试类型】以及【版本范围】这些维度，来对测试用例进行归类；举个例子，像登录模块、权限模块、数据导入模块这几个部分，大家可以分别去建立测试文档或者测试集合；而功能测试、回归测试、接口测试、安全测试这些不同的类型，则可以通过设置字段来进行区分。

　　2、对测试用例的字段进行规范

　　一条看起来比较完整的测试用例，通常都需要包含【用例标题】【前置条件】【测试步骤】【预期结果】【优先级】【测试类型】【适用版本】【负责人】这些基本的内容；如果身处的项目对合规性的要求比较高，测试人员也可以在里面增加验证方法、验证环境、关联的标准条款以及自动化状态等字段。

　　3、做好测试步骤和预期结果的维护

　　测试人员在写测试步骤的时候，必须保证它是能够被实际执行的，大家不要只写一句“检查功能是否正常”这样的话；比较稳妥的写法是，每一步都只写一个动作，并且让每一步都拥有明确的输入内容、操作过程以及预期结果；比如说，输入账号、输入密码、点击登录按钮、检查页面有没有发生跳转以及此时的权限状态。

　　二、Polarion测试用例和需求之间如何关联

　　把测试用例和需求关联在一起，这是做需求覆盖分析时非常基础的一步；如果没有建立关联，测试用例就只是孤立地存在着；而如果有关联、但是把关系的类型选错了，追溯矩阵最后可能也会统计不出数据；Polarion所采用的追溯模型，非常强调对工件类型和关系类型的明确定义，这主要是为了给影响分析、覆盖分析、测试追溯以及进度监控提供数据支撑。

　　1、把关联关系的类型确定下来

　　行业内常见的做法是，让测试用例通过【verifies】或者【tested by】这两种关系去和需求进行关联；在实际的项目中，链接的具体名称可能会有所不同，大家需要以当前Polarion项目的具体配置为准；这里的关键在于，团队内部必须把标准统一起来，不能出现有的人用验证关系、有的人却用普通关联关系的情况。

　　2、选择从需求侧或者测试用例侧来建立链接

　　测试人员可以从需求条目里面点进去，在【Linked Work Items】中添加测试用例，当然也可以从测试用例这一侧，反向地去关联对应的需求；这两种方式都是可以的，重点在于保证连接的方向和关系的类型没有出错。

　　3、利用追溯矩阵来检查覆盖的情况

　　在关联工作完成之后，大家需要通过追溯矩阵或者相关的报表，来检查需求的覆盖情况；这里常见需要检查的项目包括：有哪些需求到现在还没有编写测试用例，有哪些测试用例其实没有关联任何需求，有哪些高优先级的需求仅仅被一条很弱的测试给覆盖了，以及有哪些测试的失败会波及到那些已经审批通过的需求。

　　三、测试用例和需求关联之后的日常维护工作

　　测试用例和需求之间的关联，并不是关联完一次之后就不用管了；后续的需求变更、版本切换、测试用例的重复利用以及缺陷的修复，都会对这个关联关系产生影响；如果大家维护得不好，这条追溯链用不了多久就会失去真实性。

　　1、需求变更之后要同步去检查测试用例

　　当需求的内容发生修改之后，测试人员要同步去检查之前关联的测试用例是不是还依然有效；比如说，需求里新增加了一段异常处理的逻辑，那么原来的测试用例就必须要补充上异常场景；而如果需求删除了某项功能，相关的测试用例也需要被标记成废弃，或者去调整它所适用的版本。

　　2、测试失败之后要记得关联缺陷和需求

　　在执行测试计划的过程中，如果测试用例执行失败了，测试人员应当把这个失败的结果关联到对应的缺陷上，同时，它和需求之间的验证关系也必须保留着；这样到了后面，大家才能够看得很清楚：到底是哪一个需求对应的测试死掉了，失败的具体原因是什么，以及缺陷在修复之后有没有进行重新验证。

　　3、定期对无效的关联进行清理

　　伴随着版本的不断迭代，测试用例有可能会被复制、废弃或者拆分，而需求同样也有可能被合并或者取消掉；因此，项目组在平时应该定期去筛选出那些没有关联需求的测试用例、没有测试覆盖的需求，以及那些关联到了已废弃需求上的测试用例。

　　总结

　　Polarion测试用例管理的核心难点，其实就是把测试用例的分类、字段、步骤、执行结果以及缺陷记录等内容统一地管起来；在测试用例和需求进行关联的时候，大家需要使用项目组所认可的验证关系，并且要通过追溯矩阵去检查覆盖的情况；在后续面对需求变更、测试失败以及版本迭代的时候，大家还要持续地去维护这种关联关系；只有做到了这一步，Polarion里面的测试用例才不会只是一份死板的测试文档，而是能够真正地去支撑需求验证、质量跟踪以及项目交付判断的管理对象。