测试用例，就是针对特定的功能点、场景，来设计用来验证功能点和场景正确性的、可执行的、可验证的过程。
功能测试，是针对软件需求的功能测试。对软件需求测试之前，就需要把具体的软件需求做条目化处理，一般是树形结构。树形结构的每一个节点，就是一个需求项。
对于每一个需求项，就需要细分功能点。所谓的功能点，就是这个需求具体实现了哪些功能，从测试的角度，就是哪些功能需要被验证。
功能点的集合，就是测试大纲。
有了功能点之后，我们就可以根据功能点来设计测试用例。那么测试用例包括什么内容？
测试用例的步骤描述包括：前提条件、测试步骤。步骤又分成具体的操作、相关步骤的数据、预期结果。
我们可以看到，在很多成熟的测试管理软件中，已经把测试数据从测试步骤描述中分离出来，这样我们就可以编写更细致的测试用例。
从早期的测试用例来看，一般是不包含具体的数据，比如“输入正确的手机号”，“输入错误的手机号”，类似的描述信息，这样带来的问题是测试用例的颗粒度比较大。例如，这个功能点需要验证手机号的有效性，“无效的手机号”，就显得太粗了，因为无效的手机号包括了很多种情况，比如长度错误、格式错误等等。
测试用例的数据与步骤描述分离，能够把相同执行步骤的测试用例，通过使用不同的测试数据，很容易的区分开来，也很容易把测试用例“精确化”，使得测试工程师集中精力于通过测试数据的设计，实现测试用例设计。
测试用例的属性包括：
用例属性，一般包括：测试用例的创建人、测试用例的创建时间、测试用例的名称、测试用例关联的缺陷编号、测试用例的描述（即这个测试用例的目的是什么，或者相关的功能点描述）。
测试用例具有执行历史，也就是这个测试用例被执行了多少次，什么时候执行的、谁执行的、执行的结果是通过还是失败。
下面谈一下测试用例设计。我们知道，测试的目标是发现缺陷，因此能够发现缺陷的测试用例才是好的测试用例。
问题在于，功能点很多，每个功能点都对应了很多个测试用例，这样就会出现一个问题：测试用例膨胀。膨胀的测试用例，会导致测试用例的数量很多，带来的后果是执行成本非常高，还不一定能够发现缺陷。
因此，我们还需要使用尽可能的在不降低覆盖率的情况下，减少测试用例的个数。
我们先说一下测试用例设计方法。常规的测试用例设计方法，有边界值、等价类、错误推断、因果图、场景法等方法，具体的方法本身我们不在这里讨论，只是大概的介绍一下，在什么时候来使用什么方法。
边界值和等价类。这两个往往是一起来使用的，能够达到比较好的效果。边界值，我们采用各个功能点表述的边界，即可以容易的找到。等价类，在输入数据比较小的情况下还是比较有效的，当输入的参数个数很多，就需要做笛卡尔积正交，这样就产生非常多的测试用例，使用不当，比如：输入参数有10个，每个输入参数有3个选项，那么，测试用例有1000个，造成测试用例膨胀。
错误推断法，其实更多时候是在测试过程中，临时增加测试用例的方法。比如，你发现一个特殊的边界条件，501，那么这个边界值，可能不只是在你测试的这个功能点会出现，在其他的地方也会出现，因此可以增加测试用例来测试特殊的边界。错误推断法，更容易发现某一类问题。比如，一个子系统不支持按钮级别的权限控制，那么可以推定，几乎所有的子系统都存在这个问题。再比如，一个下拉列表，当它的选项超过50个，按照设计会有一个快速检索的功能，如果没有，就是一个bug。那么，这个选项数据，在其他界面出现的时候，基本上也存在缺少快速检索功能。
场景法。首先，我们说，什么是场景。场景其实就是一个功能在不同的环境下，有不同的表现。比如，复制粘贴这个功能，在word里面，可以粘贴纯文本、也可以粘贴带格式的问题、图片、图表，这样就产生了大量的场景。不同的场景，可以对应一个或者多个测试用例。那么场景一般情况下，就是针对功能点做场景分析。大多数的功能点，具有的场景一般只有一个，特殊情况下可能有很多。
另一种情况，就是这个功能本身就是一个流程，那么我们可以把一个流程的分支，作为一个场景。场景之下，每一组数据，都可以作为一个测试用例。
流程测试用例。我们知道功能其实有多个维度，比如当功能或者单个页面、单个交易的问题，以测试数据组合为目标。流程类的功能，以流程测试为核心，辅助以数据来设计测试用例。
sales@spasvo.com
