功能测试用例

从单元测试开始，经过集成测试、系统测试，一直到最后的验收测试，功能测试始终都会涉及到，而且功能测试几乎是系统测试的核心内容，因此功能测试用例编写的是否成功，决定着最后测试结果的成败。

功能测试关注的是系统功能是否正确实现，其主要依据文档是需求分析文档，集成测试中相关的功能测试会涉及概要设计和详细设计文档。

在目前的大多数测试工作中，测试人员的分工还不像开发人员分工那样明确，经常是测试经理不但要编写测试计划和设计测试，还要执行具体的测试工作，尤其在功能测试过程中，编写测试用例和执行测试用例的经常是一个人。因此针对功能测试，本着提高效率的宗旨，提出下面的编写原则：

1、  用例应该编写的少而精：建议越少越好，但是功能用例的覆盖面应该是全部的功能需求，这是针对目前大多数企业提供的测试资源较少提出的一个原则，目前的大多数公司没有能力给测试用例足够的编写时间，是少的用例节省时间便于执行和维护，随着企业软件开发过程的规范化，测试人员分工会更加明确，这个时候需要编写较为全面的功能测试用例，由专门的测试员执行；

2、  尽量包括更多的测试内容：比如一些易用性测试、健壮性、界面测试，都可以包含在功能测试中，这用做不但可以减少测试次数，更能提高测试效率，同时把相关联的测试用例一起执行，会发现更多的缺陷。

本小节主要介绍功能测试用例的基本编写方法和一些功能测试用例的编写实例。

10.2.1.1功能测试用例设计基本方法

功能测试的用例设计方法常见的有等价类划分、边界值分析、因果图、比较法和错误推测法，这些方法在测试书籍、网上文章中都可以找到，在这里就不重复了。本节给大家介绍一种比较新的用例设计方法：使用用例场景来设计测试用例。

用例场景来设计法的重要概念是测试点：在系统的用例模型描述中应明确指出每个用例模型的优先级和用例工作流程，每个用例模型为一个测试点，用例模型中每个测试需求至少应编写两个测试用例。这个概念经常被误解和误用，请大家注意。

用例场景的定义：用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

为什么引入用例场景？

现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易得到理解和执行。

用例场景示例：

下图中经过用例的每条不同路径都反映了基本流和备选流，备选流用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）。

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

注：为方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情况。

测试用例：

生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。

测试用例例子：

假定上图描述的用例对备选流3规定如下：

“如果在上述步骤2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤2‘输入提款金额’，此时银行客户可以输入新的提款金额。”

据此，可以开始确定需要用来执行备选流3的测试用例：

注：由于没有提供其他信息，以上显示的测试用例都非常简单。测试用例很少如此简单。

10.2.1.2功能用例编写策略

    功能用例的编写策略一般是这样的：

    1)首先确定测试点和其自有工作流程。

    2)按业务（系统测试）或功能（单元和集成测试）将测试点进行编号和排序。

    3)使用用例场景方法确定测试用例。

    要点：使用场景，类似于白盒测试的基本路径法。能清晰的描述出系统的功能或业务流程，将测试用例的实际测试效果提升到最大。又因描述出各测试点之间的关系从而降低测试用例的设计难度和复杂度。

10.2.1.3功能用例编写例子

下面是一个由用例生成测试用例的更符合实际情况的例子。

一台ATM机器的主角和用例。下表包含了上图中提款用例的基本流和某些备用流：