Use case和test case区别

tjmjf

最近看到很多文档提到use case和test case, 这2个有什么区别吗？

利勇lmm

user case和test case根本上的区别是什么？感觉和模糊，请再指导一下

dg129

谢谢

justfan2012

谢谢分享。

楠族开心果

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。
测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统的趋势。 　　要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。 　　既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

楠族开心果

Use Case（用例）是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。  
那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。（唔？Use Case也没什么特别的嘛！怎么这玩意儿会在开发中处于一个中心地位呢？）在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！好了，Use Case就吹到这儿，具体的使用还要在实践中去体会，“运用之妙，存乎一心” 也！  
对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case时，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

lyfeng

我们常说测试以需求为依据。那么我到底如何组织我们的测试是最接近需求呢。以下我提到一非常重要因素：UseCase----什么是UseCase呢？在UML的文档中，UseCase的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实UseCase就是对系统功能的描述而已，不过一个UseCase描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用UseCase来表达的，界面是在UseCase的辅助下设计的，很多类是根据UseCase来发现的，测试实例是根据UseCase来生成的，包括整个开发的管理和任务分配，也是依据UseCase来组织的。啊，UseCase，简直太重要了！

UseCase 由以下元素组成：名称、简单描述、事件流、关系、活动图和状态图、UseCase 图、特殊需求、前条件、后条件。

创建USE CASE的原则：1、用例是短文。2、用例可以是一个场景，包括动作和互交。3、用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。4、用例里不要有系统设计。5、用例里不要有界面设计。6、用例里不要有特性列表。7、用例里不要有测试。8、用例应该描述行为需求。9、用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。10、用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

总的来说：UseCase 是系统提供的功能块，换句话来说UseCase演示了人们如何使用系统。通过UseCase观察系统，能够将系统实现与系统目标分开，有助于了解最重要的部分――满足用户要求和期望，而不会沉浸于实现细节。通过UseCase 用户可以看到系统提供的功能，先确定系统范围再深入开展项目工作。

那么如何从UseCase 生成TestCase 呢？
从UseCase的角度来考虑TetsCase的设计，重点还是要从业务本身的角度来考虑，比如UseCase中的基本流和不同的备选流组成的不同的业务流程，都可以对应到单独的一个TC中去。但TestCase还会考虑来把用户不同情境的基本流/备选流进行细化组织。