【摘要】开发和维护测试用例是软件测试过程中的重要步骤之一，也是衡量软件测试质量的核心影响因素。本文从开发、执行和维护几方面对测试用例管理过程进行分析，提出了测试用例开发、维护的相关原则。
【关键词】软件测试；测试用例
1.测试用例开发
1.1 测试用例编写依据
一般说来，测试需求就是为了达到测试目标，项目中需要测试什么。测试过程中所有活动都可以追溯到测试需求。例如，制定测试计划时，需要明确以下基本要素：首先需要明确测试需求，也就是测试的目标内容；然后才能决定怎么测，即采用什么测试方法；再评估需要多少测试时间，需要多少测试人员，也就是测试的进度安排；最后明确测试的环境是什么。此外，还包括其他因素，例如测试中需要的技能、工具以及相应的专业背景知识，测试中可能遇到的风险等，以上所有的内容结合起来就构成了测试计划的基本要素。制定测试计划的重要依据就是测试需求，而测试计划中的所有内容都可以追溯到测试需求，所以说测试需求是测试计划的基础与重点。同样的，测试方案、用例、内容都要以测试需求为基础。
测试需求是从软件需求映射而来，所以其详细程度与软件需求的详细程度有密切关系。在编写时，在保证与软件需求一致的前提下，力求表达准确详细，避免测试的遗漏与误解。
测试用例的编写应该覆盖所有的测试需求，而测试需求是由软件需求转换而来，因此所有测试用例的执行结果最终都会追溯到软件需求，因此测试用例的编写依据主要是软件需求。此外，还应遵守相关的编写规则、规范等。
1.2 测试用例开发原则
测试用例的设计原则包括：
（1）依据原则：测试用例编写的主要依据为项目提供的需求说明书和相关技术规范文档；
（2）全覆盖原则：对于需求说明书和相关技术规范中要求的主要功能点进行全覆盖测试，要求所有功能均能正常实现；
（3）规范原则：所有测试案例的编写要求规范，对于所有被测的功能点，应用程序均应该按照需求说明书和相关技术规范中的给定形式，在规定的边界值范围内使用相应的工具、资源和数据执行其功能；
（4）全面原则：测试不仅仅针对系统功能特性进行测试，对系统的其他质量特性也进行全面的测试与评估。
测试用例编写应该满足的具体量化要求包括如下几点：
（1）用户经常使用、关系到系统核心功能、优先级别较高的功能点，测试用例应该达到100%覆盖率；
（2）针对各个系统端到端的功能以及与其它系统的接口的测试应该达到100%覆盖率；
（3）测试用例包括正常输入和正常业务流程测试，也包括对非法数据输入和异常处理的测试，且对系统非正常操作的测试用例应占到总数的20%—30%；
（4）测试用例中包括中文特性及系统本地化测试，如中文信息的显示、录入、查询、打印和报表显示测试等。
2.测试用例执行
2.1 测试用例对测试需求的覆盖
首先看一下什么是测试需求覆盖。测试需求来源于软件需求，与软件需求的关系是一对一，或者是多对一。如果一个软件需求可以转换为一个或者多个测试需求，那么测试需求已经覆盖了全部的软件需求，可以说测试需求的覆盖率为100%。但是这不能说明测试需求的覆盖程度达到了100%。因为一般的软件需求只明确了显性的功能与特性，而隐性的功能与特性（没有被明确指出但是却应该具有的功能和特性）并没有在需求中直接体现。这部分需求也应该成为测试需求，因此在进行测试需求分析时，要同时分析软件的显性和隐性需求，或者根据实际测试中发现的缺陷，对测试需求进行补充或优化，并更新测试用例，以此来提高测试需求的覆盖程度。
好的测试用例集应该覆盖全部的测试需求。以系统功能举例说来，测试用例包括功能点和业务流程。对于功能点，设计的测试用例需要覆盖全部需求中的功能点，除了正常情况的测试用例，还应设计异常情况的测试用例，且异常情况测试用例占整个测试用例集的20%—30%。同样的，业务流程的测试用例也包含正常流程和异常流程。
2.2 测试用例执行结果分析
测试用例执行结果可以从覆盖率、执行率、通过率等几个方面进行分析和考察。测试用例覆盖率是指测试用例覆盖的功能与测试需求功能的比值；测试用例执行率是指已执行的测试用例数与测试用例总数的比值；测试用例通过率是指成功执行的测试用例数与测试用例总数的比值。
测试用例的覆盖率需要达到100%，也就是说，测试用例必须覆盖全部的测试需求，否则测试用例的设计则是不全面的，无法保证测试质量，需要补充或者重新设计相应测试用例。测试用例执行率是衡量测试效率的因素，一般说来，在测试完成时测试用例的执行率也需要达到100%，也可能因为某些特殊原因导致测试中断而没有全部执行测试用例，可针对具体的情况进行分析。测试用例通过率是衡量用例本身设计质量和被测软件质量的因素，对于未能成功执行的测试用例，要分析是用例设计错误还是被测软件错误，导致用例无法顺利执行。
3.测试用例维护
软件产品的版本是随着软件的升级而不断变化的，而每一次版本的变化都会对测试用例集产生影响，所以测试用例集也需要不断地变更和维护，使之与产品的变化保持一致。以下原因可能导致测试用例变更：
（1）软件需求变更：软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理方法，同样变更的测试用例也需要执行变更管理流程。
（2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试用力也要进行变更。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，而在测试执行过程中被发现，这时需要补充测试用例。
（3）测试用例遗漏：在测试过程中，发现测试用例未覆盖全部需求，需要补充相应的测试用例。
（4）软件发布后，用户反馈的缺陷：表明测试不全面，存在尚未发现的缺陷，需要补充或者修改测试用例。
对于提供软件服务的产品，其多个版本常常共存，而对应的测试用例也是共存的，而且测试用例需要专人定期维护，并遵循以下原则：
（1）及时删除过时的测试用例
需求变更可能导致原有部分测试用例不再适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试用例也不再需要。所以随着需求的每一次变更，都要删除那些不再使用的测试用例。
（2）及时删除冗余的测试用例
在设计测试用例时，可能存在两个或者多个用例测试相同内容，降低回归测试效率，所以要定期整理测试用例集，及时删除冗余的测试用例。
（3）增加新的测试用例
由于需求变更、用例遗漏或者版本发布后发现缺陷等原因，原有的测试用例集没有完全覆盖软件需求，需要增加新的测试用例。
（4）改进测试用例
随着开发工作进行，测试用例不断增加，可能会出现一些对输入或者运行状态比较敏感的测试用例。这些用例难以重用，影响回归测试的效率，需要进行改进，使之可重用可控制。
总之，测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程。
4.总结
测试用例管理是软件测试过程中的重要内容，测试用例的好坏对软件测试质量有着重要的影响。本文介绍了测试用例的开发、执行及维护等管理过程，为测试过程中的用例设计提出相关建议，同时也希望从测试用例设计的角度为软件开发提供参考。