1.什么是测试用例？
（1）测试用列（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
（2）测试用列（Test Case）是在测试过程中很重要的一类文档，它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。
（3）测试用列（Test Case）是设计一种情况，软件在这种情况下能够正常或异常运行并达到预期结果；而程序如果在这种情况下不能正常运行，那则可能是一个软件缺陷。

2.测试用例的要素
（1）测试用例的标题、测试思路、预设条件、步骤、预期输出
（2）常见的8要素：用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤、预期结果、实际结果、备注。
一个好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

评价测试用例的标准：
用例表达清楚，无二义性
用例可操作性强
永猎的输入与输出明确，一条用例只有一个预期结果
用例的可维护性好
用例对需求的覆盖率高
暴露程序bug的能力强

3.测试用例的好处
它是测试执行者的依据
它使得工作可重复，自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴
4.测试用例的设计方法
4.1 总体的设计方法
基于需求的设计
基于需求的测试方法RBT（Requirements-Based Testing）是基于需求的测试方法，会使得测试更加有效，它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，它关注以下问题：

验证需求是否正确、完整、无二义性，并且逻辑一致
要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合要求
4.2具体的设计方法

<1>等价类：
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类找那个选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

有效等价类
对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明书中所规定的功能和性能

无效等价类
根据需求说明书，不满足需求的集合

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
<2>边界值：
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分的补充，这种情况下，其测试用例来自等价类的边界。

例：针对6-15位长度设计测试用例。
有效等价类：6 < x < 15
无效等价类：x < 6 || x > 15
边界值：5，6，15，16
完整的测试用例：5，6，10，15，16

在有效等价类中任选一个值代表这个等价类。
为什么6和15不能代表等价类？
边界值法要和等价类法结合使用，是互补的，边界值是等价类的一种补充。有效等价类的选取时，不选边界值，边界值单独写。
为什么不用3和4作为边界值？
3和4可以代表小于边界的类，但不能代表等于边界的类，5可以代表等于边界的类，也可以代表小于边界的类

数据是有区间的：取边界值的时候要注意是否包含边界值，注意开区间和闭区间
[1,50] 边界值：0,1,50，51
(1,50) 边界值 ：1,2,49,50
[1,50) 边界值：0,1,49,50

<3>因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

恒等

恒等：如果原因为真，那么结果必定为真

与

与：只有两个原因都为真，结果才为真

或

2个原因中有一个为真，结果就为真

非

只有原因为假，结果才为真
因果图设计测试用例的步骤：

分析所有可能的输入和输出

找出输入与输出之间的对应关系
画出因果图
把因果图转换成判定表
把判定对应到每一个测试用例
因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但对于比较复杂的输入和输出，会耗费大量的时间
<4>正交排列
目的：正交法是为了减少用例数目，ongoing尽量少的用例覆盖输入的两两组合。
定义：正交试验设计是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合，正交试验设计是一种基于正交表的、高效率、快速、经济的是试验。

正交表中的有关概念：
因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
水平（位级）(Level)：在实验范围内，因素被考察的值称为水平（变量的取值）
行数（Runs）：正交表中的行的个数，及试验的次数，用N表示
因素数（Factors）：正交表中列的个数，用C代表
水平数（Levels）：任何单个因素能够取得的值的最大个数。
正交表中包含的值为从0到“水平数-1”，或从1到“水平数”，用T代表
正交表的表示形式：
L=行数（水平数*因素数）
L=N(TC)
L 6（25）：代表有6次试验，5代表有5列，有5个考察的因素，2代表每个因素有2种水平，也就是2种取值

正交表的两条性质：

每一列中各数字出现的次数都一样多
任何两列所构成的各有序数对出现的次数都一样多
<5>场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的场景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。
用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

<6>错误猜想法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。基于经验和直觉，找出程序中你认为可能出现的错误，有针对性的设计测试用例。

5.测试用例的有效性
可以正常的发现有BUG的程序，或正常的验证程序是正确的。

6.测试用例的粒度和评价
测试用例的粒度：是指测试用例编写的详细程度。
测试用例可以写得和简单，也可以写的很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，复杂的测试用例会指定输入的每项数，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等。

大多数的测试团队编写的测试用例的粒度介于两者之间，如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果，应该根据项目的时机情况、测试资源情况来决定设计出怎样粒度的测试用例。
可以考虑以下的内容：
产品的质量要求
项目对用例的要求
测试时间和资源是否充分
测试用例的评价：
评审分为正式和非正式评审。
同行评审
用户评审
项目组的评审

7.通用测试用例八要素
　　1、用例编号；
　　2、测试项目；
　　3、测试标题；
　　4、重要级别；
　　5、预置条件；
　　6、测试输入；
　　7、操作步骤；
　　8、预期输出。

8.具体分析通用测试用例八要素
　　1、用例编号
　　一般是数字和字符组合成的字符串，可以包括（下划线、单词缩写、数字等等），但是需要注意的是，尽量不要写汉语拼音，因为拼音的意义可能有好几种，有可能会导致乱码；
　　用例编号具有唯一性和易识别性。（ 比如说我们唯一标识一个人：中国-上海市-xx区xx号-xx楼–xx室-xxx.这样标识的话就具有唯一性了。)
　　不同阶段的测试用例的用例编号有不同的规则：
　　（1）系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
　　（2）集成测试用例：产品编号-IT-系统测试项名-系统测试子项名-XXX
　　（3）单元测试用例：产品编号-UT-系统测试项名-系统测试子项名-XXX
　　**其中产品编号也叫项目标识，每个公司都有若干不同的项目或者产品，如何来区分它们呢？这就需要有产品编号了，每个公司都有自己的一套定义产品编号的规则，并且每个现有产品的编号已经制定好了，直接拿过来用就可以了。
　　产品编号后的ST、IT、UT分别对应系统测试阶段、集成测试阶段、单元测试阶段。实际工作中有些公司会将产品编号以及测试阶段省略。
　　测试阶段后面就是测试项目名了，对应的是较大较系统的测试点。
　　测试项目名后面就是测试子项目名，有些测试是没有子项目名的，只有当测试项力度比较大的时候才会有成都市子项 （比如说：我们要测试用户能否成功登录这个功能，那我们就可以分为很多个子项，qq登录、邮箱登录等等）。
　　测试子项名后面就是具体的用例编号了，可以是数字：01、001、002等等。
　　2、测试项目
　　测试项目对应的就是测试用例中的子项名。
　　（1）系统测试用例：对应一个功能点（功能测试）、性能指标（性能测试）、界面中控件（GUI测试）等等。
　　（2）集成测试用例：对应集成后的模块功能或者接口功能。
　　（3）单元测试用例：对应函数名。
　　3、测试标题
　　测试标题考虑的是如何来完成测试项目，或者说从哪个角度来对测试项目进行测试，有的公司也取名为测试目的。
　　测试标题一定要简单、概要；体现测试的出发点和关注点。
　　4、重要级别
　　用例的重要级别一般分成三个级别：高、中、低。
　　高级别：对应保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例；
　　中级别：对应重要程度介于高和低之间的测试用例；
　　低级别：对应实际使用频率不高，对系统业务功能影响比较大的模块或功能的测试用例。
　　举个手机的例子：
　　（1）高级别需求：正常通话功能、短信功能；
　　（2）中级别需求：拍照、联系人、MP3；
　　（3）低级别需求：计步、收音机等等。
　　还需注意的是：针对正常情况的测试用例的重要级别比针对异常情况的测试用例的重要级别要高。
　　5、预置条件
　　测试用例在执行前需要满足一些前提条件，否则测试用例是无法执行的，这些前提条件就是预置条件。
　　预置条件分为两种情况：
　　（1）环境的设置。
　　例如：测试word打开文件的功能，预置条件就是：需要提前准备被打开的文件；
　　例如：登录成功的预置条件就是：该用户名已经注册过了。
　　例如：购买商品成功的预置条件就是：后台已经配置好商品、发货区域、以及支付方式了。
　　（2）先要运行的其他用例，有些操作系统会比较复杂，如果都是从最开始的操作开始会导致用例写起来比较麻烦，这样可以在预置条件中设定要先运行的测试用例，后面的用例只需要写后续的操作就可以了。
　　例如：对自动取款机进行测试，有针对的输入账户信息的测试，有对输入取钱金额的测试，后者的预置条件就可以写成输入正确账户信息的测试用例。
　　注：具体预置条件的设置不同的公司会有自己的规定，比如有的公司是不允许第二种情况出现的。
　　6、测试输入
　　用例执行过程中需要加工的外部信息，根据软件测试用例的具体情况，有手工输入、文件、数据库记录等。
　　禁止过多描述性语言，若为文件，会有提示选择路径，最好写具体，让别人易懂易操作。
　　7、操作步骤
　　明确描述测试执行过程中具体的操作步骤，以方便测试执行人员可以根据该操作步骤完成测试用例执行。
　　8、预期输出
　　预期输出是测试用例中非常重要的一部分，预期输出可以检验被测对象是否正常工作，如果我们的预期输出写的不完整不全面，整个测试用例就会受到影响。
　　我们在写预期输出的时候可以从以下三个方面来考虑：
　　（1）界面显示：在操作步骤完成之后，界面会有显示；比如说我们测试用户登录功能，界面可能会显示登录成功或者登录失败。
　　（2）数据库的变化：在操作步骤完成之后，数据库中的记录会发生相应的变化，比如删除功能的测试，点击删除后，数据库中该记录会被删除。
　　（3）相关信息的变化：在操作步骤执行完成后，一些和被测对象相关的信息会发生变化，比如：注销功能的测试，点击注销后，以前能访问的页面将无法再访问。

9.测试用例的编写流程
需求分析、提取测试点、测试用例的编写、测试用例评审。

10.测试用例有什么作用?
  1.在测试实施过程中可以避免盲目测试并提高测试效率；
  2.使软件测试的实施重点突出，明确测试目的；
  3.用例的通用化和复用化使测试在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期；
  4.有利于改进测试工作，通过用例执行结果得知系统不稳定模块，为往后的测试工作改进提供依据；
  5.测试用例是测试工作的见证，有了测试用例，就知道哪些功能被覆盖到，哪些功能没有覆盖；
 
总结：
编写测试用例的时候，要分为正向、逆向、考虑边界条件、容错、性能、安全、兼容等方面考虑。