谈谈需求的描述-用例（Use Case）

用例（Use Case）是一种描述系统需求的方法。运用用例这种方法来描述系统需求称之为用例建模。用例也是UML规范中的一种标准化的需求表达方式，其中比较有名的RUP（Rational Unified Process）就是以用例来驱动的。

值得一提的是，虽然RUP被认为是一种重量级的软件管理过程，而越来越多的软件开发开始采用敏捷方法来响应瞬息万变的需求变化。但是用例作为一种描述需求的方式，其理念和方法论对我们分析需求还是有一定的帮助。

从表达方式上看，用例相对时序图、流程图等需求表达方式，更加面向对象和面向设计。通常情况下，用例比较容易让没有受过专业培训的人员接受。用例可以作为一种跟用户或者行外人员陈述需求的方式。

用例是一种描述需求的方法，用例描述了在不同的条件下，系统对参与者的请求做出的响应。用例通常通过一个参与者（Actor）（ 谁？ ）向系统做出请求，系统根据参与者的请求（ 要做什么？ ），在不同的条件下，执行某一行为序列（ 系统怎么满足？ ）。每一个行为序列可以称之为一个场景（Scenario），一个用例包含多个场景。场景也可以称之为用例的一个实例（Instance）。

正式的用例应该包括：用例名、概述、范围、级别、主参与者、项目相关人员和利益、前置条件、最小保证、成功保证、触发事件、主成功场景、扩展场景和相关信息等等。

各个组成部分的意义如下：

用例可以用于不同的目的，如：

不同的编写目的导致了用例在编写过程中有可能出现不同的侧重点。

在不同的团队情况也可能导致用例书写的不一样。比如在一个大型的开发项目组里，就需要严格的按照用例范例进行描述，而在一个小型的沟通频繁的项目组里，则可以采用一种比较简单的描述方式。

上文提到的是比较常见的组成部分。事实上，用例的格式并没有硬性规定，在必要时可以增减里面的信息。具体用例需要包括哪些信息，有不同的流派。有兴趣可以查看相关资料，这里不展开讲。

一句话概括： 你的用例不是我的用例，只有适合的用例才是最好的 。

本文主要观点均来自于《编写有效用例》（Writing Effective Use Cases ）作者是 Alistair Cockburn。有兴趣的可以读一下原著。

用例用于表述需求，但是有两点要注意的：

用例名用于标识一个用例，便于汇总和阅读。

规则：使用主动语态的动宾短语来描述。

一般情况下，建议使用主动语态的动宾短语来描述用例的目标。如： “查找商品” 、 “加入购物车” 。在某些情况下，如需要更准确的表示出一个用例，可以加入定语进行修饰，如： “用户清除购物车” 、 “管理员清除购物车” 。

规则：以主参与者为对象进行描述。

用例的描述需要以主参与者为对象进行描述，如可以使用 “支付订单” （以主参与者为对象），而不是 “收取订单费用” (以系统为对象)。

用例的范围能让我们对系统的边界和讨论的需求有一个基础的语境，不同的设计范围可能会导致我们需要讨论的参与者、场景都会不一样。简单来讲，就是为我们讨论的系统划定一个范围确定我们讨论的界线。

例如我们要讨论一个用户的下单行为。如果以整个企业为范围，其项目的相关人员为用户、第三方服务者（如快递等）。但如果以系统为范围，其项目相关人员还应该包括企业内部的系统管理员、客服等。

所以，在编写用例时需要搞清楚，我们的用例的范围是什么，这样可以对用例讨论的问题达成一个共识。

在讨论用例的设计范围时，需要先确定系统的功能范围。Cockburn在《编写有效用例》里面推荐了一个确定功能范围的方式 “内/外列表” 。

确定功能范围的好处是显而易见。如，系统外部已经有了一个打印订单的系统，如果不明确区分系统的功能范围，部分开发人员有可能会对打印订单功能进行设计和实现。而事实上，这些功能是不需要设计的。

明确了功能范围后，还可以确认系统的执行人员。如上面的例子，打印订单系统将作为 “打印订单” 用例的辅助执行者。

设计范围是在功能范围确定了之后做的。设计范围指的是我们在编写用例时讨论问题的边界和对象。我们在用例里面说的范围（Scope）如果没有特殊说明指的就是设计范围（而不是功能范围）。

下面来看一个例子，ECom公司打算做一个ESys的系统，系统里面包括了ESubSys等多个子系统。

如果以ECom为设计范围来讨论用例，我们关心的是用户对公司的需求是什么，公司以什么样的形式满足用户的请求。如果有外部公司，则还要考虑外部公司与公司之间往来的业务是什么。

如果以ESys为设计范围来讨论用例，我们更关心用户向系统发起的请求和系统对请求的响应。同时，如果以ESys做范围的时候，企业内部的员工也成了用例的执行者，我们还应该考虑员工对系统的请求。

确定用例范围，能很好的对其我们要讨论的问题是什么，界定我们讨论问题的范围，给用例一个语言环境。

规则：设计范围是一个简单的专有名称。

用例的范围应该是一个简单的专用名词，简单说明一下用例讨论的范围界线。如，上面的例子中范围可以直接用 “ECom” 、 “ESys” 、 “ESubSys” 来表示。

主执行者是系统相关人员中，请求系统做出响应的人或物。主执行者是对系统请求的发起者，可是 主执行者可以不是直接 *** 作系统的相关人员 。

其中一种情况下是主执行者通过另一个系统 *** 作相关人员对系统进行 *** 作。如，客户致电客服查询异常订单的场景。客户并没有直接通过系统进行查询。

另一种情况是定时触发任务。如客户希望系统定时执行一个任务，那么最终执行系统的相关人员是系统本身。

虽然识别出主执行者很重要，可是在有些时候 主执行者也没那么重要 。

在编写用例时，识别出主执行者，可以从执行者角度出发，充分梳理系统需求。我们还可以主执行者的特点来设计系统的交互。如下表，主执行者概括表：

在多数情况下，我们开始编写用例开始后，主执行者就变得没那么重要了。例如，当我们在设计查询订单用例时，无论是管理员、经理、客服甚至是其他的公司职位，在查询订单这个用例上并没有特别的差异。这个时候，主执行者具体是谁已经不重要了。

规则：用例的主执行者可以是执行者或者执行者角色。

在上述情况下，我们会将部分主执行者一般化的方式，创建一个 “角色-执行者对应表” 。在上述用例里，我们将管理员、经理等一般化为一个 *** 作角色——订单管理者。我们在描写用例时，以角色作为主执行者即可。

概述主要用于描述用例的目标，也就是用户需要完成的目标。

规则：使用自然语言描述。

尽量使用自然的语言阐述用户要完成目标时，用户会做什么事情。

规则：描述用例实现什么，而不描述系统步骤。

只需要讲清楚用例需要完成的事情即可，这里不需要描述系统步骤或者用户的具体 *** 作流程。

如： “用户选择一件需要购买的商品后，可以将商品加入购物车，然后在购物车里面提交订单。用户也可以不需要加入购物车，直接购买选中的商品。” 概述并不需要描述具体的系统 *** 作，在这里并没有描述 “点击加入购物车按钮” 等系统的 *** 作细节。

项目的相关人员是指对系统有特定利益的参与者。相关人员不一定是人，也可以是一个外部系统、一个组织等。

所以能成为项目相关人员的有可能是：

主执行者

主执行者是发起执行用例的相关人员。

辅助执行者

辅助执行者是为被设计的系统执行服务的的外部执行人员。辅助执行者可以是另外一个系统、也可以是一个人或组织。如，一台打印机，为系统打印各种票据。再如，快递公司，为系统提供快递服务，并提供物流信息。

内部执行者

内部执行者是在系统内部关注系统利益的相关人员。

被设计的系统

被设计的系统本身有时候对自己也是有特定利益的。

对于相关人员，有几点需要说明：

规则：相关人员和利益用以对应列表的方式书写。

使用" <相关人员>：<利益> "的方式，描写相关人员和其关注的利益。

在编写用例过程中，我们有时会具体描述一个用户的需求（如用户购买商品），有时候会描述一个系统的具体功能（如用户登陆），有时候会描述一个流程（如购买商品并获得商品的流程）。在编写用例的时候，知道用例所处的位置，对我们编写和理解用例有很大的帮助。

我们将用例级别从总到分划分成了三个层次：概要、用户目标、子功能。

用户目标是指主执行者使用系统期望获得的目标。用户目标是我们编写用例的重点。用户目标描述了主执行者通过系统 “做一件什么事” ，以及做完这件事后 “用户能获取什么利益” 。

用户目标应该是主执行者一次执行系统获取利益的过程。所以，不是一次执行所能完成的目标，或者用户不能获得利益的需求不能称为用户目标。

如，购买一个商品的流程，这个从下订单到快递需要几天的过程，所以不能称为一个用户目标。再如，用户登陆，用户登陆并不能获取什么利益，所以也不能称为一个用户目标。用户下单这个 *** 作，可以作为一个用户目标。

概要层次可以包含多个用户目标，概要目标执行周期比用户目标更长，可以是一个几天、几个月甚至更长的过程。概要目标有三个目的：

子功能层次是用户目标在执行过程中会执行到的目标。如，一次登陆，一次订单打印等。也有可能存在多个用户目标共用一个子功能，如查找商品、查找订单等。

子功能用例的存在是为了用户目标用例增加可读性而存在的。在实际编写过程中， 不到迫不得已，不要设计子功能层出用例 。

规则：层次只有三个选项：概要、用户目标、子功能。

用例的层次只能是概要、用户目标、子功能三个之中的一个层次。

前置条件是我们在用例执行之前期望必须成功的条件。在用例编写过程中，可以不对该条件进行检查和讨论。如， “下订单” 必须依赖于 “用户已经登陆” 这个前置条件。

规则：前置条件必须是用例执行前我们期望一定成功的条件。

要预防将那些并不是必须条件的条件写入前置条件。如，取消订单并不依赖于用户下单成功，事实上，用户可以将下单不成功（例如支付失败）的订单取消掉。而订单下单是否成功这个条件是需要在用例里面对这个条件进行检查并执行不通过动作的。

最小保证是用例执行无论是否成功都会被执行的保证。虽然，用例无论执行成功与否，最小保证总会被执行。但是，最小保证更多的是为用例执行失败情况下，为用例相关人员提供的利益保证。最小保证可以有多个。

一个常见的最小保证例子是 “系统将用户执行记录日志” ，就算用例执行失败，用户的 *** 作也将会被记录到日志里面。

成功保证是指用例执行成功后，用户所能得到的利益保证。相关人员的利益能否得到保证，是用例执行成功的判定条件。成功保证可以有多个。

例如，在下订单用例中，用户下单成功后，必须保证 “订单被创建，并提交到后台处理。”

触发事件是指用例启动的事件，用例将通过触发事件，开始一步一步执行。

规则：触发事件是跟系统交互的第一个 *** 作。

以用户下单用例为例子，用户决定要购买商品后，在系统中查找商品并下单。那么 “用户决定要购买商品” 并不能作为用例的触发事件，事实上，用户更系统的交互是从 “查找商品” 开始的，所以 “用户查找商品” 才是用例的触发事件。

我们讨论用户跟系统交互时，还应该注意我们讨论的系统的范围。特别是当主执行者不是直接 *** 作软件系统的场景时，更应该明确系统范围。如， “用户致电客户经理下单” 这样的场景下，我们的系统范围并不能限定在软件系统范围内，这是系统范围是公司。所以， “用户致电客户经理” 跟我们系统交互的第一步，所以可以成为 “触发事件” 。

主成功场景是用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合。

主成功场景应该包括以下信息：

执行步骤应该有一些简单的规则：

规则：使用简单语法。

使用简单语法结构：

例如：

规则：准确描述执行者之间的切换。

执行步骤需要准确描述步骤执行过程中，执行者之间的切换。如， “用户致电客户代表” ，我们可以知道步骤已经从用户切换到了客户代表。

但是，有时候在执行者明确的情况下，也有可能不会出现在句子中。如， “用户输入密码” ，我们也可以知道这个步骤的执行者已经从用户切换到了系统。我们不必使用 “用户向系统输入密码” 这种冗余的描述方式。

规则：从系统外去描述步骤。

不应该从系统内部，或者全部以系统角度去考虑而已。而应该从系统外去描述步骤。

如果从系统内部去描述步骤，可能会写成：

如果在系统外部去描述步骤，则表述成：

规则：显示过程向前推移。

一些小的步骤只能完成少数工作，有时候这些工作并不能很好的描述过程在向前推移。如， “用户点击了确定按钮” 。这个步骤并不能很好的描述过程在向前推移，用户的真实目的是登陆系统，随着用户登陆系统，用例步骤可以继续往下执行。

规则：显示执行者的意图，而不是动作。

执行者通常是通过 *** 作系统执行一个动作的，在描写用例时，容易将用户动作和执行者的意图搞混。

例如：

1 系统要求用户输入身份信息

2 用户输入用户名密码

3 用户点击确定按钮

4 系统确认用户身份信息

……

用例过多描述了系统 *** 作界面和用户的动作，如 “要求用户输入身份信息” ，这个并执行者的意图，而只是一个交互动作。

我们可以缩减描述用户动作的步骤，将用例改成：

规则：包含合理的活动集。

描述步骤的时候，并不一定要求每个步骤之包括一个活动。根据需要可以将部分活动集合在一个步骤里面。

如:

这个步骤也可以描述成两个步骤：

用例的描述方式以简单，有效为主，有时候并不拘泥于具体的方式。事实上很多开发团队都形成了自己的用例编写规范。

规则：步骤描述成功的场景，而不要体现可能的失败。

主成功场景的步骤描述的是成功的步骤。例如:

如果这样编写步骤，我们将要继续考虑 “如果判断正确……” ， “如果判断失败……” 。但是在主成功场景的步骤中，是不体现失败的步骤的。所以，需要将步骤改成

如果如果系统验证失败怎么办？这部分信息放到扩展里面描述。下文会详细说明，这里不展开。

规则：当步骤不连续执行是，可以加入时间限制。

多数情况下，步骤是一步接一步执行的。可在某些时候，可以这样描述：

规则：一个步骤可以涉及多个相关人员。

我们有时候需要通过一个系统向另一个系统发起一个执行动作，可以写成：

规则：可以反复执行一个或多个步骤。

有时用户会反复执行其中一个或多个步骤，这时候需要在步骤中增加一定的描述。如：

扩展是主成功场景的分支，是指主成功场景在一些其他条件下会完成的不同动作。 请注意，使用“扩展”而非“异常”或“错误”，事实上扩展包括了成功和失败两种可能的条件 。其基本的逻辑是，在执行主成功场景时，如果系统……（检测到意外），那么，……（做一些事情）。

常见的有可能出现扩展的场景如下：

在这些场景出现后，我们应该在扩展中描述这些场景处理方式，然后回到主成功场景或者退出用例。

扩展是针对主成功场景的，所以我们写编写扩展的时候，需要用编号来表明扩展的对应关系：

主成功场景如下：

扩展如下：

如果是每个步骤都可能会触发的扩展，可以用”“号来表示，如：

或者如果是某些步骤触发的共有条件，可以加上步骤来表示，如：

规则：从系统检测到的角度去描述扩展条件。

扩展条件应该是系统能检测到的条件，而不是发生了什么。如，用户忘记密码了，系统不可能检测到用户是否密码或者是其他的什么原因。从系统检测到的角度去描述，系统只能检测到用户输入错误的密码或者用户输入超时。

规则：合理化合并扩展条件。

扩展条件事实上无需枚举出所有的可能出现的场景，和合理的范围内，我们可以将一些扩展条件合并成等价项。判断等价项，有两个标准：

例如，用户输入密码的步骤里面，用户可以忘记密码输入错误，也可以手误输入错误或者其他的可能性，这些条件都是系统不可以检测的条件。首先，将这些条件转换成系统可以测试的条件：密码输入错误。转换后，所有条件就可以合并成一个了。

在来看一下系统可以完成的条件，如，密码输入错误、用户名错误、用户名不存在等，我们系统的处理都是 “提示用户名或密码错误或不存在” 。这时候可以将条件合并成 “系统检测到用户名或密码输入错误” 。

还有一种情况，如果在低层级（如子功能级别）用例已经完整描述了扩展，那么在其高级别（如用户目标级别）用例，可以不用重复冗余描述。比如，在子功能级别用例 “保存数据” 里面已经完整描述了保存过程中可能出现的各种扩展条件，那么在其上级用例里就可以不用描述了。

--

用例还能以用例图的方式来表示。本文主要是通过用例的关注点和用例的组成来探讨一下一种需求的描述方式，所以就不对用例图召开介绍了。有兴趣的读者可以自行参考其他资料了解。

在敏捷开发越来越受到推崇的今天，用例这种相对较“重”的需求分析和表达模式越来越少的被人使用。当是我们通过研究用例的关注点和分析方式，其很多思想还是可以借鉴到我们日常的需求分析当中的。

用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。

元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。

角色之间的关系

角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

用例之间的关系：

包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML11中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML13以后的版本中用例之间是包含和扩展这两种关系。

泛化关系：代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。

用例的泛化、包含、扩展关系的比较。一般来说可以使用“is a”和“has a”来判断使用那种关系。泛化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。

用例之间的关系举例

包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

扩展：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导出、打印和查询相对独立，而且为查询添加了新行为。

泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。

将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。

用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测

测试用例组成元素

(1) 用例ID；

(2) 用例名称；

(3) 测试目的；

(4) 测试级别；

(5) 参考信息；

(6) 测试环境；

(7) 前提条件；

(8) 测试步骤；

(9) 预期结果；

(10) 设计人员。

测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。

要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项 *** 作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

(参考信息：百度百科)

可以通过判定某个控件是否存在再进行下一步 *** 作。比如：通常登录界面都有登录、注册按钮，帐号、密码框。

if not selfdriverfind_element_by_name("登录"):

#滑动界面

else:

#登录 *** 作

问题一：如何才能写好一个软件的测试用例 写好一个软件的测试用例的建议有：

1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。

2、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。

3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可 *** 作性。

4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。

5、测试用例级别要划分清楚，这样在测试执行时有主次之分。

6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。

问题二：如何写好一份测试用例 写好一个软件的测试用例的建议有： 1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。

问题三：写测试用例应该怎么写？我想知道具体的模式。谢谢！ 假设一下吧。现在要求你测试一下百度知道的提交回答功能。

用例编号：提交问题001（编号通常会根据功能或模块编写）

测试目的：验证当用户回答完问题后，可以正常提交答案。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）

测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。

重要级别：像提交回答这条用例，多数会被列为最高级别用例，因为是最基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）

*** 作步骤：1、将光标点入“我来帮他解答”下的输入栏。

2、输入想提交的答案

3、点击提交回答

4、验证提交后答案是否能显示到当前问题下

（输入数据多数时候是合并到 *** 作步骤中的，比如这条里的输入数据就是“答案”）

预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的答案可以正确显示……

问题四：编写测试用例有哪些方法？ 你好！

1等价类

2边界值

3错误推测

4因果图

5判定表

6正交实验

7功能图

等等，个人感觉前三个最常用了，正交表偶尔用下！

复杂业务可能会用到因果图！

你可以参考： 360doc/shtml

问题五：如何高效编写测试用例 测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。

测试用例(Test Case)目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

测试用例编写准备

1

从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；

2

根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。

测试用例制定的原则

1测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。

2测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。

用例覆盖

1正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

2容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品 *** 作一点也不懂的客户，在进行任意 *** 作。

3完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。

4接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

5压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。

6性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。

7可理解（ *** 作）性：理解和使用该系统的难易程度（界面友好性）。

8可移植性：在不同 *** 作系统及硬件配置情况下的运行性。

测试方法

1边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。

2等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

3错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

测试用例的填写

1一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中， *** 作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。

问题六：如何编写一个完整全面的测试用例 一、编写测试用例的原则

测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。测试用例编写应该遵循的原则：

1、测试用例要达到最大覆盖软件系统的功能点。测试工程师应该测试计划编写完成之后，在开发阶段编写测试用例，参考需求规格说明书和软件功能点对每个功能点进行 *** 作上的细化，尽可能趋向最大需求覆盖率。

2、测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。

3、 测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力等。

4、 测试用例的管理。使用测试用例管理系统对测试用例进行管理。

一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性，而一个成功的测试案例能够发现某个尚未发现的错误，通常一个好的测试案例有以下特性：

1、具有高的发现错误的概率

2、没有冗余测试和冗余的步骤

3、测试是“最佳类别”

4、既不太简单也不太复杂

5、案例是可重用和易于跟踪的

6、确保系统能够满足功能需求

测试用例不可能设计得天衣无缝，也不可能完全满足软件需求的覆盖率，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试。

二、如何编写测试用例

测试用例的信息有很多，可以根据实际的情况进行增删，一般来说一个优秀的测试用例应该包含以下信息：

1、产品相关信息

（1）软件产品或项目的名称

（2）软件产品或项目的版本

（3）功能模块名

（4）功能描述

（5）测试平台

这些信息建议可以在测试案例手工选择。

2、基本记录信息

（1）测试用例入库者

（2）测试用例入库时间

（3）测试用例更新者

（4）测试用例更新时间

这些信息建议可以由测试案例自动生成。

3、测试用例的属性

（1）测试用例ID：测试用例的ID（由案例管理系统自动生成，方便跟踪管理）

（2）测试用例名称：测试用例的名称

（3）测试功能点：测试的功能检查点

（4）测试目的：该测试功能点的测试目的

（5）测试级别：主路径测试、烟雾测试、基本功能测试、详细功能测试。

下面对这几个测试级别进行说明：

A、主路径测试：对照需求中重要模块和功能的最主要功能路径，主路径测试为设计探针模块，快速检查程序的可测试性（可测试性还包括安装测试是否成功）的主要依据的测试案例

B、烟雾测试：对照需求中所有模块的主要功能路径，主路径测试案例为烟雾测试案例的子集，烟雾测试为做回归测试的主要依据的测试案例。

C、基本功能测试：对照需求和总体设计中所有模块和功能的基本功能路径，基本功能测试为测试软件产品的非重要级别模块，书写完全的自动测试脚本的主要依据。

D、详细功能测试：对照总体设计中所有模块和功能的功能路径，测试各个模块及功能各个层次，各种类型。详细功能测试案例为对重点模块，易发生错误的模块的主要依据。

（6）测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。

（7）预置条件：对测试的特殊条件或配置进行说明

（8）测试步骤：详细描述测试过程，案例的 *** 作步骤建议少于15个。

（9）预期结果：预期的测试结果

三、测试用例设计过程

对一个全新的产品来说，首先需要了解的是产品需求文档和产品模块之间的关系。然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例，这个时>>

问题七：如何编写单元测试用例 一、 单元测试的概念

单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。

测试的覆盖种类

1语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。

2判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。

3条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。

4判定――条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。

5条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。

6路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。

二、开始测试前的准备

在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。穷举测试是不可能的。所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。

三、开始测试

基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。

函数说明 ：当i_flag=0；返回 i_count+100

当i_flag=1；返回 i_count 10

否则 返回 i_count 20

输入参数：int i_count ，

int i_flag

输出参数： int i_return;

代码：

1 int Test(int i_count, int i_flag)

2 {

3 int i_temp = 0;

4 while (i_count>0)

5 {

6 if (0 == i_flag)

7 {

8 i_temp = i_count + 100;

9 break;

10 }

11 else

12 {

13 if (1 == i_flag)

14 {

15 i_temp = i_temp + 10;

16 }

17 else

18 {

19 i_temp = i_temp + 20;

20 }

21 }

22 i_count--;

23 }

21 }

22 i_count--;

23 }

24 return i_temp;

25 }

1画出程序控制流程图

圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。让我们看程序中；第2行，第3行是按顺序执行下来的。直到第4行才出现了循环 *** 作。而2，3行没有什么判断，选择等分支 *** 作，所以我们把2，3，4全部合并成一个结点。其他的也是照这个规则合并，然后就有了上面的流程图。

2计算圈复杂度

有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。

这里有有了一个新概念――圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少>>

问题八：如何写好测试用例的设计心得 先分测试类型，再根据数据流设计测试模块，整理好测试检查点，最后设计点诡异的测试用例

问题九：测试用例如何写 用例1，输入正确的手机号码，点击获取验证码 预期结果：手机收到验证码

用例2，输入错误的手机号码，点击获取验证码 预期结果：提示输入正确的手机号码

用例3，输入英文字母，点击获取验证码 预期结果：提示输入正确的手机号码

用例4，输入特殊字符，点击获取验证码 预期结果：提示输入正确的手机号码

用例5，输入超长字符，点击获取验证码 预期结果：提示输入正确的手机号码

用例6，输入正确的验证码，点击确定 预期结果：验证通过

用例7，输入错误的验证码，点击确定 预期结果：验证不通过，提示验证码错误

用例8，输入特殊字符的验证码，点击确定 预期结果：验证不通过，提示验证码错误

用例8，输入超长的验证码，点击确定 预期结果：验证不通过，提示验证码错误

纯手打，忘采纳，可以联系854155141继续沟通。

以上就是关于谈谈需求的描述-用例（Use Case）全部的内容，包括:谈谈需求的描述-用例（Use Case）、用例图的作用、测试用例是什么它是由哪些基本元素组成的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！