测试用例就是将测试系统的操作步骤用文档的形式描述出来，让软件测试的行为具体化，来核实软件产品是否满足项目需求。测试用例是执行测试的依据。
测试用例的设计和编制在软件测试活动中非常重要，也是测试人员必须要掌握的一项基本能力。
以下是测试用例的主要作用：
(1) 测试用例是设计和制定测试过程的基础，方便理清测试思路，避免盲目测试并提高测试效率
(2) 测试人员可以根据测试用例提前准备测试数据
(3) 根据测试用例可以更准确地估计测试周期各连续阶段的时间安排，便于把控测试的工作进度
(4) 测试用例有助于准确评估测试工作量
(5) 编写的测试用例可形成文档沉淀，便于组织测试工作，降低测试的交接成本
一份优秀的测试用例可以帮助测试人员在最短的时间内完成测试，发现软件系统的缺陷，保障软件测试质量稳定。
用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
角色之间的关系
角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系：
包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML11中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML13以后的版本中用例之间是包含和扩展这两种关系。
泛化关系：代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。
用例的泛化、包含、扩展关系的比较。一般来说可以使用“is a”和“has a”来判断使用那种关系。泛化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。
用例之间的关系举例
包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
扩展：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导出、打印和查询相对独立，而且为查询添加了新行为。
泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。
将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。
用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。
简单来说，测试用例就是指导如何做测试的文档，该文档主要记录需要验证被测软件的是否满足需求。
测试用例的主要作用如下：
（1）在技术上将需求转化为具体可验证的指标
（2）以文档的形式记录软件可能存在的问题
（3）防止测试过程的活动出现遗漏，提高工作效率
（4）测试工作量的展示
一份优秀的测试用例可以最大限度地减少产品bug，提高产品质量。
以下是几点编写测试用例的思路：
（1）常规思考，设身处地的从用户角度出发；
（2）测试理论方法的支撑，如观察法、等价类、边界值、因果图等；
（3）产品的熟悉和经验的积累
场景是根据需要虚拟出的一个景象，可以有很多元素组成，比如到公园的场景，那么就有树，有花，有草，有人在休息，有动物在跑。
用例是对系统功能的描述。系统在使用中可能出现很多种情况，那么也就存在很多种不同的场景，
比如一个场景，10个人在干A ，20个人在做B，5个人在弄C。
另一个场景，50个人在干A ，20个人在做D，5个人在弄F，6个人在弄B。
一个用例可以包含多个场景。
用例设计方法有10种：
等价类。
边界值类。
判定表。
正交实验。
流程分析。
状态迁移。
因果图。
输入域覆盖。
输出域覆盖。
异常分析。
等价类。
优点：
简单、高效。
快速评估测试用例的数量:最少用例数=功能数(输入数+1)。
缺点：
只考虑了独立输入的有效和无效，没有考虑输入之间的组合。
数据随机选取，不一 定发现bug。
适用范围：
只要存在输入的功能。
用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。
每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么。
从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
发展历史:
在1986年，Ivar Jacobson，UML和瑞理统一过程的重要贡献者，提出了用例的概念。
Jacobson的思想很有影响力，也很有发展力。之后在这个科目上又有很多贡献，在定义用例是什么和怎么有效的书写用例方面最重要，最有影响力也最全面的，是Alistair Cockburn，他写的书籍是《编写有效用例》。
用例迅速成为获取功能需求最常用的手段。用例最初是和面向对象一同提出的。但是它不止局限于面向对象系统，因为用例实质上不是面向对象。
软件测试用例就是指导你对软件执行操作，帮助你证明软件功能或发现软件缺陷的一种说明。
他的形式一般是这样的
假设一下吧。现在要求你测试一下百度知道的提交回答功能。
用例编号：提交问题001（编号通常会根据功能或模块编写）
测试目的：验证当用户回答完问题后，可以正常提交答案。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）
测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。
重要级别：像提交回答这条用例，多数会被列为最高级别用例，因为是最基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。
预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）
操作步骤：1、将光标点入“我来帮他解答”下的输入栏。
2、输入想提交的答案
3、点击提交回答
4、验证提交后答案是否能显示到当前问题下
（输入数据多数时候是合并到操作步骤中的，比如这条里的输入数据就是“答案”）
预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的答案可以正确显示……
其中所有的标题 为软件测试用例需要包含属性。冒号后面是对这一条用例的具体描述。
以上就是关于测试说的用例是什么全部的内容，包括:测试说的用例是什么、用例图的作用、测试用例的作用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
