不管在传统软件公司还是互联网公司，测试用例的设计和编写一直是测试人员一个非常重要的基本工作。
开发一个软件产品，会发布多个版本，伴随着测试用例(Test case)的不断维护， 使测试用例不断完善并与产品功能、特性(features)的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。
一、为什么要使用测试用例
1、理清思路，避免遗漏
如果我们测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
2、跟踪测试进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。
3、历史参考
在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
4、重复性
我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
5、测试确认
在少数高风险的测试中，必须证明确实执行了计划执行的测试。
软件产品的版本是随着软件的升级而不断变化的，而每一次版本的变化都会对测试用例集产生影响，所以测试用例集也需要不断地变更和维护，使之与产品的变化保持一致。
根据产品特性和测试用例一致性，分下面几种情况分别处理：
1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case，也就意味着当前修改的test case，对目前和以前的版本都有效。
2. 原有产品特性发生了变化，不是new feature， 而是enhanced features(功能增强)， 这时候原有的 test case 只对先前版本有效，而对新的版本无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效。
3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive(无效)。
4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。
这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case 的完整性、有效性!
以下原因可能导致测试用例变更：
1）软件需求变更：软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理方法，同样变更的测试用例也需要执行变更管理流程。
2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试用力也要进行变更。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，而在测试执行过程中被发现，这时需要补充测试用例。
3）测试用例遗漏：在测试过程中，发现测试用例未覆盖全部需求，需要补充相应的测试用例。
4）软件发布后，用户反馈的缺陷：表明测试不全面，存在尚未发现的缺陷，需要补充或者修改测试用例。
对于提供软件服务的产品，其多个版本常常共存，而对应的测试用例也是共存的，而且测试用例需要专人定期维护。
并遵循以下原则：
1）及时删除过时的测试用例
需求变更可能导致原有部分测试用例不再适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试用例也不再需要。所以随着需求的每一次变更，都要删除那些不再使用的测试用例。
2）及时删除冗余的测试用例
在设计测试用例时，可能存在两个或者多个用例测试相同内容，降低回归测试效率，所以要定期整理测试用例集，及时删除冗余的测试用例。
3）增加新的测试用例
由于需求变更、用例遗漏或者版本发布后发现缺陷等原因，原有的测试用例集没有完全覆盖软件需求，需要增加新的测试用例。
4）改进测试用例
随着开发工作进行，测试用例不断增加，某些用例随着系统输入和当前状态的变化而变得不再适用，这些用例难以重用，影响回归测试的效率，需要进行改进，使之可重用可控制。
总结：
测试用例的目的对新人来说，提高了新人的测试效率。假如一款产品停止维护了，那么所有的测试用例随之失效，到此测试用例的生命周期结束。而新起一款产品，新的生命周期又开始了。所以，测试用例伴随着整个产品的生命周期。
总之，测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程。
欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ 群： 755431660