测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 　　
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 　　
不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。 　　随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。 　　
要使终用户对软件感到满意，有力的举措是对终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。 　　
既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选适合或关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。 　　
确定测试用例之所以很重要，原因有以下几方面。 　　
测试用例构成了设计和制定测试过程的基础。 测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也越有信心。 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。 测试设计和开发的类型以及所需的资源主要都受控于测试用例。 测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。佳方案是为每个测试需求至少编制两个测试用例： 　　?一个测试用例用于证明该需求已经满足，通常称作正面测试用例； ?另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的小实体。简单地说，测试用例是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

 

测试用例的粒度：每个测试用例所覆盖的测试范围或者期望结果的多少。

 

 

测试用例的特征

  1.有可能抓住错误的；

 2.不是重复的、多余的；

  3.一组相似测试用例中有效的；

  4.既不是太简单，也不是太复杂；

 5.有效的，可执行的，有期望结果。

 

 

测试用例组成元素

  1.用例ID Test Case ID      

  2.用例名称 Test Case Name

  3.测试目的 Test Objective

  4.测试级别 Test Level (Test Phase， ST， SIT， UAT…)

  5.参考信息

  6.测试环境 Test Environment

  7.前提条件 Prerequisites/Dependencies/Assumptions

  8.测试步骤 Test Steps/test script

  9.预期结果 Expected Result

  10.设计人员 Designer

11.执行人员 Tester

12.实际的结果/测试的结果 Actual Result/Test result

可能还有

13. 相关的需求和功能模块，需求描述 requirement description

14. 测试数据 Test Data

15. 测试结果的状态（反应测试是否成功） Test case status (passed， failed， hold， attention; also case use colors)

 

测试用例的组织方式

 

 

 

Test case ID
 Test case description
 Test steps
 Expected result
 Actual result
 Tester
 status
 
CR001
 Test user login with right user and password
 1，

2，

3，
 …should…
 
 Tester1
 passed
 
CR002
 Test user login with wrong password
 1，

2，

3，
 …shoud…
 
 Tester2
 failed
 
CR003
 Test user logout
 1，

2，

3，
 …shoud…
 
 Tester2
 hold
 

 

 

测试用例设计原则

  1.测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

  2.测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

  3.测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

===============================================================

测试用例的特点：

完整
完整性是对测试用例基本的要求，尤其是一些基本功能项上，如果有遗漏，那将是不可原谅的。完整性还体现在中断测试、临界测试、压力测试、性能测试等方面，这方面测试用例也要能够涉及到。
准确
   测试者按照测试用例的输入一步步测试完成后，要能够根据测试用例描述的输出得出正确的结论，不能出现模糊不清的语言。
简洁 
好的测试用例每一步都应该有响应的作用，有很强的针对性，不应该出现一些冗繁无用的操作步骤。测试用例不应该太简单，也不能够太过复杂，大操作步骤好控制在10-15步之间。
清晰  
清晰包括描述清晰，步骤条理清晰，测试层次清晰(由简而繁，从基本功能测试到破坏性测试)。清晰简洁对测试用例编写者的逻辑思维和文字表达能力提出了较高的要求。
可维护性
由于软件开发过程中需求变更等原因的影响，常常需要对测试用例进行修改、增加、删除等，以便测试用例符合相应测试要求。测试用例应具备这方面的功能

适当性
测试例应该适合特定的测试环境以及符合整个团队的测试水平，如纯英语环境下的测试用例好使用英文编写。
可复用性
要求不同测试者在同样测试环境下使用同样测试用例都能得出相同结论。
其他
如可追朔性、可移植性也是对编写测试用例的一个要求