前言：
虽然网上有很多关于这方面的文章和文档。因此这个专题，我将从零开始系统介绍怎么进行系统测试用例的设计。希望对测试员或其它测试相关人员起一个指引作用。
一、测试用例的基本概念
对于基本理论、基本概念的重要性，我已经在反复在各类测试文章或内部培训会上提到过。所以在开篇之前，我还是先从测试用例的基本概念谈起。
1、什么是测试用例？
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实某个功能是否满足某个特定需求。通俗来讲，测试用例就是通过说明测试执行的前置条件，执行的操作步骤，以及每个步骤对应的预期结果，来验证某个程序或者某个功能是否满足某个指定的测试需求。
2、测试用例里面包含哪些内容？
强调下，这里说的测试用例主要指软件（系统）功能测试用例。通常用例的内容包括测试目标（目的），需求标示（一般同需求文档中的需求编号对应），预置条件（如需要的网络配置、环境配置等），输入数据（如测试用到的账号等数据），测试步骤，预期结果，通过标准（什么情况下该用例执行成功）等。
3、不同的测试类型，用例内容也不同
根据测试的类型不同，用例的内容往往也不一样。如：界面测试一般为内容检查清单（也是我们说的checklist），单元测试为依据Junit等框架编写的特定代码。
4、设计测试用例的用途？
我相信大家都比较清楚测试用例的设计用途，但我认为还是有必要把它的用途尽可能详细的列出来：
帮助我们科学有序的执行测试，尽可能发现软件（系统）中的缺陷；
便于重复执行测试，以便重现缺陷（在向开发描述bug时非常重要）；
回归测试时，验证缺陷是否被修复；
避免无序的测试，提高测试执行效率；
便于计算工作量，使测试更能按照时间计划进行；
使得测试过程更方便管理，包括跟踪测试进度，执行情况等；
方便测试结束后提取基本测试用例，以便后面进行复用，提高工作效率。
正因为测试用例有上面这么多用途，所以科学合理的设计测试用例，对我们的软件测试质量起到至关重要的作用。
二、测试用例的依据有哪些？
测试用例的设计的依据主要为用户（或市场）需求说明、软件（系统）需求规格说明书、以及各种规范（如行业规范、通用规范(标准)等）等。在设计具体测试执行步骤时，还要加入概要设计、详细设计、数据库设计等文档（前提是这些文档能正确满足用户的需求，可能情况下做好这些文档的测试和评审）。
测试用例设计的首要任务是分解测试需求点，针对每个需求点设计相应的用例，以确保覆盖到每一条需求。
对于测试依据，往往一些测试员可能会受相当一部分敏捷开发或开发流程不规范的公司影响，从而造成一些错误的理解：
测试用例设计的依据决不是软件的本身。即用完成后的软件来设计用例是错误的做法，这样可能会导致测试得出的结果与用户期望的结果有较大的出入。
软件需求规格说明书不能保证都是正确的，往往因为每个人对用户需求的不同理解造成不同的结果。所以如果有需求评审这个环节，那认真对待它，当理解有出入时大胆提出来。
用户和软件需求只是测试依据的一部分（也是最重要的部分），依据还应该包括行业标准（如金融、银行、通信的业内标准规范）、通用标准规范（如ISO规范、国家法律法规）等。
在敏捷开发情况下，可能你的依据只会是UI设计原型，功能说明文档等，这种情况下，如果可能，应该尽可能的从需求设计人员口中了解更多的细节。
三、测试用例常用的设计方法介绍
要使自己的测试用例尽可能科学合理，发现更多的缺陷，离不开方法的使用。下面我讲对常用的测试方法做下介绍。
1、等价类划分法
等价划分某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中一个的输入不会导致问题发生，那么我们假定集合中其它输入条件进行测试也不可能发现错误，这就是等价类划分法。
通常等价类划分法，分为有效等价类和无效等价类：有效等价类，即对于程序的需求说明来说是合理的，有意义的输入数据所构成的集合，利用它可以检验程序是否实现了预期的功能和性能；无效等价类，则是对于程序的需求说明来说是不合理的，没有意义的输入数据所构成的集合，利用它可以检验程序对于无效数据的处理能力。
确立等价类的原则有：
如果输入条件规定了取值范围，或者值的个数，则可以确立一个有效等价类和两个无效等价类。例如，用户名输入规定长度在6~12个字符之间，那有效等价类应为大于等于6，小于等于12的字符长度的字符串；两个无效等价为小于6个字符和大于12个字符的字符串。
如果输入条件是一个布尔量（即条件为输入布尔值true，或者1），则可以确立一个有效等价类和一个无效等价类。
如果规定了输入数据的一组值，而且程序要对每一个输入值分别进行处理，这时要对每一个规定的输入值确立一个有效等价类，而对于这组值之外的所有值确立一个无效等价类 。如ATM机只支持100、300、500、1000、2000的正整数取款，那么这些数字都是一个有效等价类，而(-∞,100)、(100,300)、(300,500)、(500,1000)、(1000,2000)、(2000, +∞)这些都是无效等价类。当然，现实中的取款机还支持手动输入100的整数取款，这里我们不作讨论。
如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（即遵守规则的数据）和若干无效等价类（从不同角度违反规则的数据）。如： 注册时输入用户密码，要求密码必须是由数字或字母组成，那有效等价类为“密码是数字和字母的组合” ，无效等价类为“密码包括中文”、“密码包括其它符号”等。
如果确知已划分的等价类中的各元素在程序中的处理方式不同，则应进一步划分成更小的等价类 。
2、边界值分析法
边值分析方法的理论基础，是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其它的取值导致程序错误的可能性也很小。边界值使用条件包括：输入条件明确了一个值的取值范围，或是规定了值的个数，或输入条件明确了一个有序集合。
确立边界值也有一些原则：
如果输入条件或输出条件规定了值的范围并且有效条件包括了值的边界，可分别对边界和略超出边界取值，例如，用户名输入字符串规定长度在6~12个字符之间，假如输入字符的长度用X表示，那字符串可输入长度范围是6<=X<=12，边界值取为：5、6、12、13。
如果输入条件或输出条件规定了值的范围并且有效条件不包括值的边界，可分别对边界和略处于边界内取值，如用户名可输入字符串长度X范围为6
如果输入或输出域是个有序的集合（如顺序文件、表格等），应注意选取有序集的第一个和最后一个元素以及集合外但靠近集合的元素作为边界，例如：输入文件名介于fname0101~fname0120之间，边界值取为fname0100，fname0101，fname0120，fname0121。
因果图判定表法
因果图（Cause-Effect Graphing）提供了一个把规格转化为判定表的系统化方法，从该图中可以产生测试数据。其中，原因表示输入条件，结果是对输入执行一系列计算后得到的输出。 因果图方法最终生成的是判定表。它适合于检查软件输入条件的各种组合情况。如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这时就需要利用因果图。
首先来看下因果中用到的符号和约束含义：
在因果图中，我们用“0” 来 表示“不出现”，用“1”来表示“出现”，用C1、C2、C3表示原因，E1表示结果。那么：
“恒等”：C1为1，则E1为1；否则C1为0，E1也为0。
“非”： C1为1，则E1为0；否则C1为0，则E1为1。
“或”： C1、C2、C3一个以上为1，则E1为1；C1、C2、C3都为0，则E1为0。
“与”： C1、C2、C3都为1，则E1为1；C1、C2、C3一个以上为0，则E1为0。
E 约束（异）— 排斥，即a、b不能同时为1。
I 约束（或）— 包容，a、b 不能同时为0。
O 约束（惟一）— 选一,a、b中仅有一个为1。
R 约束（要求）— 需要,a为1时，b必须为1。
M 约束（强制）— 屏蔽，若a为1时，则b强制为0。
在前面我们知道因果图的使用范围，符号及约束说明后，下面介绍一下因果图判定表生成测试用例的基本步骤：
（1）分析软件规格说明描述中，哪些是原因 (即输入条件或输入条件的等价类)，哪些是结果 (即输出条件)，并给每个原因和结果赋予一个标识符。
（2）分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系? 根据这些关系，画出因果图。
（3）由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。
（4）把因果图转换成判定表。
（5）把判定表的每一列拿出来作为依据，设计测试用例。
下面根据上面的步骤，还是用网上自动售货机购买啤酒和橙汁举例说明测试步骤。具体的需求是：有一个处理单价为5角钱的饮料自动售货机软件，若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。”
首先分析这一段说明，列出原因和结果：
分析原因（条件）:
1.售货机有零钱找
2.投入1元硬币
3. 投入5角硬币
4. 押下橙汁按钮
5. 押下啤酒按钮
建立中间结点，表示处理中间状态
11. 投入1元硬币且押下饮料按钮
12. 押下〖橙汁〗或〖啤酒〗的按钮
13. 应当找5角零钱并且售货机有零钱找
14. 钱已付清
分析结果：
21. 售货机〖零钱找完〗灯亮
22. 退还1元硬币
23. 退还5角硬币
24. 送出橙汁饮料
25. 送出啤酒饮料
(2) 画出因果图。所有原因结点列在左边，所有结果结点列在右边。
(3) 由于 2 与 3 ，4 与 5 不能同时发生，分别加上约束条件E。
(4) 生成完整的因果图。
(5) 转换成判定表，并设计测试用例。
上面实例的因果图为：
转为为判定表（判定表是一个表格，分为四个部分，其左部是条件或数组元素的名称，右上部是所有条件的组合，左下部是处理中活动的名称，右下部标明条件组合和相应的活动的对应关系）为：
判定表说明：
网上提供的判定表有误，如果你看过，仔细点肯定能发现。上表为我修改后的正确判定表。
上面有5个条件，则共有2的5次方种组合。
注意利用二分法把所有可能组合的情况列出来，请仔细观察上面1和0的组合规律。
判定表中灰色表示的是不可能出现的情况。
以上判定表已经出来了，那相信你可以根据它很好的编写测试用例了。
4、场景分析法
当软件中用户操作步骤较多，而用户的不同操作导致程序的不同处理结果，因果图/判定表法就不能有效进行用例设计。这时可以用到场景法，即基于用户对事件的触发，对事件流进行分析。场景法包括了基本流，描述用户操作的成功场景；备选流，描述用户操作的其它可能结果，常常是非期望结果。所以我们的用例场景应该是描述开始到结束的所有基本流和备选流。
5、错误猜想法
人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而针对性地编写检查这些错误的例子，这就是错误猜想法。 错误猜想法的基本想法是，列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。错误猜想法只能作为测试设计的补充而不能单独用来设计测试用例，否则可能会造成测试的不充分。
要做好错误猜想法，必须要有较深的测试经验积累，较强的第六感，对问题的敏锐性、以及直觉性，就如侦探判案，根据经验做大胆的假设，最后去求证线索。
四、测试用例设计方法的选择
测试用例设计方法繁多，除了上面提到的常用用例设计方法外，还有状态分解法、流程分析法、正交实验法、输入域测试法、输出域覆盖法等。而每个公司因为所测项目业务不同，情况不同，需要选择不同的用例设计方法集。
在这里我要强调一点，测试用例应该带入自己的思想，这样能使你在做测试时有一个清晰的思路，也能让别人更清楚你用例设计的思路。这样在进行用例评审时也不用一一做检查，只要大家了解你的测试用例设计思路，那评审时的主要工作就只检查你是否有遗漏测试点。
五、怎么编写有效的测试用例？
在上面，我们已经介绍了测试的方法，方法的选择等。那是否我们了解了这些就能编写出有效的测试用例呢？那不见得，下面针对用例编写规范等说明怎么编写出一套有效的测试用例：
测试用例的易测性。首先保证用例的简洁性，简洁性的衡量方法就是执行测试花费的时间长短以及在测试过程中是否能保持整个测试的纯净（没有必要把用例写成用户使用说明书）。其次保证用例的正确性，正确性意味着测试人员根据测试用例进行的测试获得，这要求测试员必须正确理解需求。
使用合理的语言。测试人员该做什么，系统输出什么应该写得很清楚明白，也就是说首先要分清楚测试用例的输入和预期输出。一种最好的避免含义混淆的方法是在操作步骤中采用动词+名词的结构，动词总是测试人员要做得事情，名词总是测试人员操作的对象、事物。将同一个事物命名为同一个名称，不管这个事物是否通过不同的方式出现。优秀的软件测试用例，理想情况是每个对计算机操作熟悉的人都能执行。
控制测试用例的长度。在Step-by-step用例中一个比较好的长度是不多于15步，要达到：执行每个测试用例花费更少的时间；测试人员很少犯错误、丢失步骤或需要帮助；测试经理能够准确地估计测试的时间；测试结果更容易跟踪 。
使用用例编写模板。通过模板让编写测试用例更方便，提高测试用例的组织性、标准、格式统一美观。样更有助于测试人员寻找信息。
测试用例依赖关系。具有依赖关系的测试用例是一些需要依靠先前的测试用例执行结果来执行的用例。应考虑是否真的需要其它的测试的结果作为数据输入，如果是，那么测试必需是累积的，应尽量避免这种情况。要保持测试用例依赖关系的正确性和一致性，并以合理的顺序来安排测试用例的顺序 。
六、测试用例的管理
你是不是在每次在用例编写后就放任不管，束之高阁了呢？如果是这样，那我认为这是一种对资源的浪费。我们在每次做完测试后，应该尽可能从用例集中提取出基本测试用例集，以便后面项目测试中直接复制使用，这提高了测试用例的复用率，同时也大大提高了我们的工作效率。
如果测试的是一个持续改进的项目，那我们在测试执行后应补充（修正）用例，以便用于后续版本的执行。否则经过多伦测试后，用例仍然与第一个版本保持不变，可能会造成大量失效，导致不可执行而丢弃掉。
我们要跟踪分析测试用例的设计效率，持续改进我们的用例设计方法集。这样才能使我们的测试质量更高，尽可能的消除上线后可能出现的严重故障。测试用例设计效率计算公式为：DE=(TDFT/NTC)×100% 其中:TDFT=测试过程中发现的全部缺陷,NTC=运行的测试用例数。
总结：
这里虽我然讲的是功能测试用例的设计思路和方法，但也同样适用于其它类型的测试用例设计。设计一个成功高效的测试用例集是一个非常具有挑战性的工作，需要我们不断的探究和学习。如果你将来或者现在有一些更好的建议，也希望拿出来给大家进行分享。我始终认为知识需要通过传播和交流，才能获得跨越式的提高。
小编还整理了一些学习资料，需要学习资料的小伙伴，可以招呼我一声！
