文章目录
1、测试用例的基本要素
回顾测试用例的概念：测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
评价测试用例的标准
1.用例表达清楚，无二义性
2.用例可操作性强
3.用例的输入与输出明确
4.一条用例只有一个预期结果
5.用例的可维护性好
6.用例对需求的覆盖率高
测试用例给我们带来的好处：
1.衡量测试需求的覆盖率
2.复用性，可以用于回归测试(回归测试的时候可以拿之前的测试用例进行测试)
3.使得工作重复，是自动化测试的依据
4.防止遗漏测试需求
5.积累测试的方法思路以供后续借鉴
测试用例给我们带来的困扰：测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
但能帮我们解决如下问题：不知道是否较全面的测试了所有功能，测试的覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余测试影响测试效率
2、测试用例的设计方法
2.1 基于需求设计测试用例
基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；
在分析测试需求时，一般分为功能测试需求和非功能测试需求
2.1.1 功能需求测试分析
对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面
- 系统各个功能界面的验证
- 借助业务把功能串起来进行测试
- 功能的一致性，交互性（多功能互操作）的测试
- 系统的不同输入，结果输出的业务数据测试
- 功能的错误操作，异常操作的测试（属于负面测试)
- 功能实现用到的算法验证，有时需要用运代码评审
- 用户操作的易用性，用户体验，往往结合功能测试同时验证
针对具体的需求，可以根据业务分类，用户角色（图书管理系统）或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。
下面对一个简单的日历系统进行分析
对日历根据界面的功能布局分析出的功能框图如下：
也可以采用思维导图的方式，更为方便，有效，只管的呈现测试需求的分析结果，可以更好的支持测试分析思路的连贯性
下面以我们常用的百度云盘手机端为例进行**分析功能** 
在进行需求分析的时候，我们还要考虑业务规则如，上传文件的大小有没有限制；一次性崔铎上传多少数量的文件，比如小于100个；文件夹最多有多少层等等
2.1.2 非功能需求测试分析
非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战
这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。
（1）纯客户端软件，比如字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
（2）企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（微信，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。
（3）外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。
此外，对于大型企业级应用系统，由于应用模式，系统架构的不同（分布式，微服务等），我们必须结合架构 和应用模式来具体分析非功能性测试需求，特别是可扩展性，可靠性，安全性等。技术架构对功能的影响小， 但是非功能性测试就要深入架构分析，才能更好的把我测试范围和测试方法。
百度云盘非功能测试的例子
2.2 具体的设计方法
2.2.1 等价类
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
- 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
- 无效等价类：根据需求说明书，不满足需求的集合。
以用户填写用户名为例：
用户名必填，用户名的长度为6至15之间，包括6和15，输入的字符类型A-Z,不区分大小写
有效等价类：6 ~ 15个小写字母 ，6 ~ 15个大写字母，6 ~ 15个大小写混合字母
无效等价类：小于6个字母，大于15个字母，6 ~ 15个非字母型字符，数字+字母混合，数字+特殊字符混合，非字母型字符+字母
2.2.2 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界
日常语言中的"边界"漏洞 考完试发成绩了，老师布置寒假作业：超过60分的，所有题目抄写1遍，低于60分的，所有题目抄写3遍。于是小明就没有写作业，因为他刚好60分
1.输入框长度为1-11，取边界值为：1、11、12、0
2.运动员的参赛项目为1-3项，取边界值为：0项、1项、3项、4项
3.查询面页面有999行，每50行为一页，取边界值为：输出0行、1行、50行、51行、999行
在实际的测试设计中，会将等价类和边界值结合起来使用，边界值的两边和中间都要进行取值，例如：
以注册邮箱的软件需求为例子
用户名要求长度为6-15位
边界值上点为：5，6，15，16 ，但实际为5，6，10，15，16
2.2.3 错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
案例：
以注册为例
1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文
2.2.4 场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
案例：以注册为例
想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景
1、用户激活后再次点击邮件激活链接？
2、已注册用户再次注册？
2.2.5 因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
因果图的需要掌握的基本知识
恒等
如果原因为真，那么结果必定为真。 例如：动物园运来大熊猫，动物园一定有大熊猫
与
只有2个原因都为真，那么结果为真 例如：重庆小伙，必须有车且有房
或
2个原因中有一个为真时，结果就为真。 例如：重庆小伙，你有车或者有房
非
只有原因为假，结果才为真。 例如：你不好好学习，找到好工作
因果图法设计测试用例的基本步骤
1)分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入或输入条件的等价类，结果是输出条件。给每个原因和结果并赋予一个标识符，根据这些关系，画出因果图。
2)因果图上用一些记号表明约束条件或限制条件。
3)对需求加以分析并把它们表示为因果图之间的关系图。
4)把因果图转换成判定表。
5)将判定表的每一列作为依据，设计测试用例。
案例：
假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠”。
-
对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：
输入：订单已提交、金额大于300、有红包。
输出：优惠、不优惠。 -
然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。
(1)订单已提交，订单金额大于300元，则优惠。
(2)订单已提交，订单金额小于等于300元，无红包，不优惠
(3)订单已提交，有红包，则优惠。
(4)订单已提交，订单金额大于300元，有红包，则优惠。
(5)订单未提交，不优惠。 -
为了方便画出因果图和判定表，需要对所有输入和输出编号，现在编号如下。
1：订单已提交。
2：订单金额大于300元。
3：有红包
21：优惠
22：不优惠 -
画因果图
-
画判定表：有3个条件,输出有2个取值，所以表的列数为2x2x2=8
-
最终的测试用例
1，2，3，4，5（包含6，7，8）
2.2.6 正交排列
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
3、测试用例的粒度
粒度：指测试用例编写的详细程度
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数
据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。
(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例