从单元测试开始，经过集成测试、系统测试，一直到最后的验收测试，功能测试始终都会涉及到，而且功能测试几乎是系统测试的核心内容，因此功能测试用例编写的是否成功，决定着最后测试结果的成败。
功能测试关注的是系统功能是否正确实现，其主要依据文档是需求分析文档，集成测试中相关的功能测试会涉及概要设计和详细设计文档。
在目前的大多数测试工作中，测试人员的分工还不像开发人员分工那样明确，经常是测试经理不但要编写测试计划和设计测试，还要执行具体的测试工作，尤其在功能测试过程中，编写测试用例和执行测试用例的经常是一个人。因此针对功能测试，本着提高效率的宗旨，提出下面的编写原则：
1、用例应该编写的少而精：建议越少越好，但是功能用例的覆盖面应该是全部的功能需求，这是针对目前大多数企业提供的测试资源较少提出的一个原则，目前的大多数公司没有能力给测试用例足够的编写时间，是少的用例节省时间便于执行和维护，随着企业软件开发过程的规范化，测试人员分工会更加明确，这个时候需要编写较为全面的功能测试用例，由专门的测试员执行；
2、尽量包括更多的测试内容：比如一些易用性测试、健壮性、界面测试，都可以包含在功能测试中，这用做不但可以减少测试次数，更能提高测试效率，同时把相关联的测试用例一起执行，会发现更多的缺陷。
本小节主要介绍功能测试用例的基本编写方法和一些功能测试用例的编写实例。
10.2.1.1功能测试用例设计基本方法
功能测试的用例设计方法常见的有等价类划分、边界值分析、因果图、比较法和错误推测法，这些方法在测试书籍、网上文章中都可以找到，在这里就不重复了。本节给大家介绍一种比较新的用例设计方法：使用用例场景来设计测试用例。
用例场景来设计法的重要概念是测试点：在系统的用例模型描述中应明确指出每个用例模型的优先级和用例工作流程，每个用例模型为一个测试点，用例模型中每个测试需求至少应编写两个测试用例。这个概念经常被误解和误用，请大家注意。
用例场景的定义：用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
为什么引入用例场景？
现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，可以生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易得到理解和执行。
用例场景示例：
下图中经过用例的每条不同路径都反映了基本流和备选流，备选流用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流1和3），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和4）。
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景1 基本流
场景2 基本流 备选流1
场景3 基本流 备选流1 备选流2
场景4 基本流 备选流3
场景5 基本流 备选流3 备选流1
场景6 基本流 备选流3 备选流1 备选流2
场景7 基本流 备选流4
场景8 基本流 备选流3 备选流4
注：为方便起见，场景5、6和8只描述了备选流3指示的循环执行一次的情况。
