1、案例描述
测试团队目前面临一个非常严峻的问题：测试用例得不到有效执行的问题。
导致此问题的主要原因在于当前的测试用例可用性较差，针对系统原有功能的测试用例主要存在以下三个问题：
第一，存在较多冗余的测试用例，在测试执行过程中执行此类用例浪费时间而且没有价值；
第二，存在较多与当前系统实现不一致的用例，此类用例严重误导测试执行人员，并容易造成新加入项目的测试人员对系统理解的混乱；
第三，存在一些重复的测试用例，此类用例的反复执行虽然可能可以确保某一功能实现的正确性，但确可能造成严重的资源浪费，特别是当此类功能并非系统的主要功能时这样的时间浪费在项目时间非常紧迫的情况下是非常不值得的。
虽然一再要求测试人员及时更新测试用例，一再强调测试用例的重要性，但仍存在大量的测试用例未能得到有效的维护。
2、案例分析
相信每一个做测试的都清楚的知道测试用例对于测试工作的重要性，但是由于主观或客观的种种因素导致很多测试人员或测试组对测试用例的编写/维护不够重视，那么为了让我们的测试用例能够真正的发挥其作用，我们就在此再次重申一下测试用例编写及维护的意义，以及测试用例维护需要注意的问题。
我们先说一下测试用例编写及维护的意义。
首先，在测试过程中测试用例可以帮你理清头绪，从而让你能够进行比较系统的测试，避免在测试过程中产生遗漏；
其次，便于bug的记录及重现，从而方便与开发人员的沟通交流；
第三，确保对系统功能的全覆盖测试，同时方便将系统使用过程中或测试执行过程偶然遇到的一些问题添加到测试用例中，从而避免以后同样的问题再次发生；
第四，在测试时间紧迫的情况下，测试用例可以帮你分清重点（前提当然是测试用例中有标注重要程度和优先级），以确保在紧急情况对重点功能的保障；
最后，测试用例执行情况的记录可以方便测试经理或项目经理及时了解测试进度，以及方便对测试人员的工作效率进行考核。
基于测试用例的上述作用那就要求测试用例必须与产品功能/特性保持一致，而由于我们的产品在不断地升级/完善，为了确保测试用例与产品的功能/特性的变化保持一致，那就需要我们的测试用例也要不断地更新完善，只有及时进行测试用例的维护才能确保测试用例的完整性和有效性。
如果不能及时对测试用例进行维护，那将会使其成为一堆废纸，而由于系统需求与设计的不断变更，将导致新加入的测试工程师或对系统不是很了解的测试人员在执行测试用例时不知所措，开发人员在多次被无效的缺陷打扰后，进而导致开发人员对测试人员的信任度严重降低，这对于系统测试工作的推进及合作是非常不利的。
测试用例的维护是一个不间断的过程，维护的主要内容包括以下几个方面：
（1）删除过时的测试用例因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个功能被取消了，原来针对此功能的测试就无法完成对新功能的测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。
（2）改进不受控制的测试用例随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。
（3）删除冗余的测试用例如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。
（4）增添新的测试用例如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
（5）测试用例需要经常的按其逻辑性对其顺序进行整理，杂乱无章也不利于测试人员的执行，带有一定的逻辑性顺序，可方便测试人员的执行，极大地提高了工作效率。
3、解决过程
通过上述分析我们可以看到及时有效地维护测试用例可以最大限度的实现测试用例的重复使用，同时可以最大可能确保测试用例的完整性和有效性。而一份完整、有效地测试用例可以很好的发挥其测试指导的功能，实现其帮助新加入项目人员快速学习了解系统使用的功能，同时还可以缩短用例的编写时间，从而有效提高测试工作的效率。
基于上述因素的考虑，以及测试组目前已积累了不少测试用例，但长期无人维护，因此现在我们正尝试着在每一个项目的测试计划中安排用例的编写及更新的时间，在每一个项目的测试过程中完成新增功能的用例编写同时，逐步完成早期被复用的用例的更新完善，要求做到被复用的用例至少与当前项目的规格是保持一致的；而对于早期用例与早期版本的相关性则尝试通过技术支持组在做外部技术支持的过程中逐步进行更新完善；当然为了能较好的执行用例的及时更新完善还需要以下配套措施：
（1）为每个项目组成员指定负责更新完善的某一模块的测试用例，用例的更新完善做为工作内容安排进工作计划，各LTM在制定周计划时考虑用例完善的时间（可以利用固定加班时间完成用例的编写），尽量避免由于时间不够导致的用例更新完善的时间被延后，同时鉴于测试用例编写的工作是可以进行基本的预估的，因此用例编写及维护工作完成的及时性将作为个人工作绩效考核的参考依据；
（2）要求每个项目组成员在执行用例的过程中发现当前用例与实际实现/规格不一致时，要主动进行确认，若确认后发现确实是用例的问题，可进行用例的修改，修改完成后要求填上自己的大名，同时邮件通知组内其他人员，以便LTM进行用例更新完善有效性的统计，此统计数据将会作为个人工作绩效考核的参考依据；（注：此处的用例有效性包括：所修改的用例修改是否正确、新增的用例是否有助于覆盖当前业务功能的所有逻辑、新增用例是否有助于发现当前系统中的更多bug）
（3）为了使测试用例尽可能全面覆盖其对应的系统规格及系统实现，无论是新增的测试用例还是维护的测试用例都需要经过组内人员的共同讨论评审。一个人对整个系统/某个功能的理解及经验始终是有限的。测试用例的评审的主要目的就是集众人的经验及认识于一体，对测试用例进行查漏补缺，使得测试用例的有效性进一步提升。因此就要求所有参与评审的人员都要贡献出自己的智慧、积极主动的参与到评审中。同样为了使用例评审能真正发挥其作用，用例的编写/维护人员就需要提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及参与人员，而参与评审的人员在评审之前至少简读一遍用例，在会议进行中，会议主持者/会议记录人需记录评审过程中每一个建议/问题以及建议/问题的提出人，而每一个建议/问题都应该有相应的解决方案，只有这样才能真正提高测试用例的有效性。通过用例评审会议的会议纪要考核每一个参与人员对用例评审的积极性，同时此类数据可作为个人工作绩效考核的参考依据；
（4）为了确保测试用例的正确性及完整性，无论是新增的测试用例还是更新完善的测试用例都需要经过组内资深人员参与的评审，而作为用例编写者/用例的更新人需要负责发起用例的评审，对于当前进行中的项目，用例在完成组内评审后还需进行项目组内的评审，只有经过评审的并且所有参与评审人员达成共识的测试用例才是有效的可用的用例，才是可以指导测试工作顺利进行的测试用例，因此对于当前进行中的项目的测试用例的评审可以利用常规的工作时间进行，从而确保用例的及时评审测试工作的及时进行，而对于一些早期维护用例的评审建议安排常规加班时间进行，从而确保当前测试工作的正常进行，尽可能减少用例评审对当前测试工作的冲击。
4、解决结果
希望通过上述努力能使我们的测试用例逐步完善，同时测试人员养成及时更新维护用例的习惯，从而有效地改善我们测试用例的可用性，实现其指导测试的作用，并帮助新人快速学习了解系统的应用，从而有效地提高测试人员的工作效率，同时尽可能通过用例的有效复用缩短项目的测试周期，并提供项目的测试质量。