在ALM Soft这款软件里面，关于测试用例方面的管理工作，其实不单单是把那些测试的步骤给填进去；更关键的任务在于，要把项目里的要求、测试的条目、最后测出来的结果、还有发现的错误记录，全部都紧密地结合在一起，这样在项目快结束的时候，人员才能看明白哪些要求是已经测过的，哪些地方还没有被测试照顾到，以及哪些毛病需要退回到开发人员那里去重新弄。要是测试的条目只是乱七八糟地堆在系统里面，虽然短时间之内还能勉强应付着使用，但是日子一旦长了，就会遇到找不到条目、来回重复编写、弄不清到底有没有把要求都测完之类的问题。

　　一、ALM Soft测试用例怎么管理

　　1、按部分建立测试用例目录

　　在正式对测试条目进行管理之前，操作人员通常需要先按照系统的不同部分或者业务的具体流程，把目录给搭建起来；比如可以分成用户管理、权限管理、报表生成、接口对接、数据同步这些地方；目录的分层不应该弄得太零碎，同时也不要把所有的测试条目都塞在同一个层级里面；比较稳妥的做法是，先建立好各个部分的目录，然后把具体的功能条目放到对应的目录底下去，这样以后在查找和维护的时候，条理就会显得相对清楚一些。

　　2、规范填写测试用例内容

　　每一个测试条目在填写的时候，里面最起码要把条目叫什么名字、提前需要满足的条件、具体的操作步骤、输入进去的数据、预想会发生的结果、还有重要程度都写明白；条目的名字不能取得太敷衍，像“测试登录”或者“测试导出”这种话就太宽泛了，可以改写成“输入正确的账号密码时用户能够成功登录”，或者“在导出销售报表的时候能够生成Excel文件”；写出来的步骤必须能让别的人照着去操作，预想的结果也要写得清清楚楚，不能随便写个“显示正常”或者“功能可以用”就应付过去了。

　　3、维护测试用例状态

　　测试条目被建立出来之后，工作人员还要跟着项目的实际进度去更改它的状态，比如把它标成草稿、等着评审、已经通过、需要修改、或者已经不用了这些字样；当客户的要求发生改变以后，跟这个要求有关系的测试条目也必须赶紧去更新，不能一直死板地用以前的老版本；对于那些重复的、没有效果的、或者是很长时间都不用一次的条目，管理人员应当定期去清理一下，或者直接把它们标记成作废，省得测试库里面的东西越堆越多、越变越乱。

　　二、ALM Soft测试用例和需求怎么关联

　　1、从需求条目创建关联用例

　　一种比较不容易出错的办法，是人员先点进具体的某一条要求里面，然后再去新建或者关联对应的测试条目；通过这种方式，系统就能够直接把这个测试条目是为了检查哪一条具体要求给记录下来；比方说，要求的内容是“用户能靠着账号和密码登录进系统”，那么做出来的测试条目就可以把登录成功、密码填错、账号根本不存在、账号被锁死这些不同的情况都包含进去；把这些东西连接好之后，后面去查看要求的覆盖情况时，结果就会显得比较直观。

　　2、在测试用例中选择对应需求

　　要是那些测试条目早就提前被写好了，人员也可以在条目的详细界面里去寻找用来连接需求的空格，接着再把对应的要求条目勾选上；在挑选的时候需要多加注意，不要只是连接到那些大目录上去，而是要尽量连接到非常具体的某一个要求上面；比如不要光是连着“用户管理”这四个字，而应该具体连到“用户登录”、“修改密码”或者“给角色授权”这种可以实际去验证的要求点上面。

　　3、检查需求覆盖关系

　　等连接的工作全部做完之后，人员必须要去检查一遍要求的覆盖情况；这里面要重点去看哪些要求已经有了对应的测试条目，哪些要求到现在还没有被测试给包含进去，以及哪些条目是找不到对应要求的；要是发现某一个要求下面连一个测试条目都没有，这就说明在后面的验证阶段很有可能会被漏掉；而要是发现某一个测试条目对不上任何要求，人员也要去判断一下这个条目是不是多余出来的，或者是之前的要求没有补充完整。

　　三、ALM Soft测试用例管理要注意什么

　　1、不要一个用例覆盖太多需求

　　有的人为了自己图省事，总是喜欢把好多个功能都塞进同一个测试条目里面去写；就拿一个条目来说，里面要是同时去测登录、修改密码、还有退出系统，这样看起来好像步骤挺长、挺完整的，但实际上真出了问题，人员很难搞清楚这到底是在验证哪一条要求；比较合适的做法是，按照不同的功能点把条目给拆开，让每一个条目都能对着一个清清楚楚的验证目标。

　　2、需求变更后同步更新用例

　　当项目的要求发生改变以后，测试的条目也必须要跟着做出调整；打个比方，要是要求里面新增加了一条需要验证码校验的规则，那么以前写好的登录条目就必须要加上关于验证码的操作步骤，以及最后预想会出来的结果；如果人员只去改了要求却不把条目也改掉，那么在执行测试的时候，大家还是会按照以前的旧逻辑去操作，测出来的结果就会跟实际上做出来的真实功能对不上。

　　3、测试执行后及时关联缺陷

　　在进行测试的整个过程中，一旦发现了毛病，人员就应该把这个毛病给连到对应的测试条目和要求条目上面去；这样一来，后面大家就能看得很明白，这个毛病是从哪条要求里出来的、是被哪一个条目给抓到的、以及现在到底有没有被修好；要是把毛病只是单独放在一个地方记录，不跟要求和条目挂钩的话，后面等项目结束了想要回头总结，或者去统计质量情况的时候，工作就会变得非常艰难。

　　总结

　　关于ALM Soft里面测试条目的管理重点，总结起来就是先按照不同部分把目录给分清楚，接着再去规规矩矩地把条目的名称、步骤、预想结果还有状态给填好；在把测试条目和项目要求做连接的时候，既可以从要求条目出发去新建条目，也可以在条目的详细内容里去挑选对应的要求，最核心的地方就是要连到具体能操作的要求点上；在这之后，人员还要定期去查看连接的关系是不是完整，并且对要求的改变、作废的条目还有测出来的毛病进行及时的处理，免得测试库越用越乱。