目录
一、测试用例的基本要素
1.测试用例的概念
测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
评价测试用例的标准：对比好坏用例的评价标准
- 用例表达清楚，无二异性
- 用例可操作性强
- 用例的输入与输出明确。一条用例只有一个预期结果
- 用例的可维护性好
- 用例对需求的覆盖率高
2.测试用例的好处
- 测试执行者的依据
- 使得工作可重复，自动化测试的基础
- 评估需求覆盖率
- 用例的复用
- 基类测试的方法思路以供后续借鉴
3.使用中带来的困扰
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间多
4.解决如下问题
- 不知道是否较全面的测试了所有功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施
- 存在大量冗余测试影响测试效率
二、测试用例的设计方法
1.基于需求进行测试用例的设计
从整体角度设计分析测试用例：基于需求
用户需求（整理出软件需求）——产品设计文档（产品经理）——开发——测试——上线
（1）验证需求的正确性和合理性
（2）分析需求，细化需求，从需求中分解出测试项，根据测试项找出功能，进行测试用例的编写
基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。
在分析测试需求时，一般分为功能测试需求和非公能测试需求
功能需求测试分析
对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来。功能测试需求包括以下几个方面：
（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要用代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证
针对具体的需求，可以根据业务分类，用户角色或者用户操作区域等系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。
下面对一个简单的日历系统的需求进行分析。
对日历根据web界面的功能布局分析出的功能框图如下：
也可以采用思维导图的方式，更为方便，有效，只管呈现测试需求的分析结果，可以更好的支持测试分析思路的连贯性。
非功能需求测试分析
非公能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非公能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。
这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。
（1）纯客户端软件，比如字处理软件（Word，PPT），媒体（音频/视频），播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
纯客户端软件对兼容性，稳定性和可移植性有一定的要求。
（2）企业内部的客户端/服务端（C/S）应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性好。但是从整体上看，对性能，安全性，兼容性要求不高。
（3）外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统功能需求外，对系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。
2.具体的设计方法
等价类
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的尽量多的功能覆盖，解决了不能穷举测试的问题。
- 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
- 无效等价类：根据需求说明书，不满足需求的集合
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他设计方法和补充。
通俗来讲，具有某种共同特征的数据集合进行划分！
等价类思想设计测试用例步骤
1.充分理解需求
2.划分有效等价类，无效等价类
3.从有效等价类中抽取其中一个数据进行设计测试用例；从无效等价类中抽取其中一个进行测试用例设计
边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
案例：购买3000元以内的华为只能是手机
价格：<=3000
等价类：
有效等价类：小于3000
无效等价类：大于3000
边界值：2999 3000 3001
边界点
上点：边界上的点
内点：边界内的点
离点：边界值附近的点（闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点）
边界值设计测试用例步骤
1.充分理解需求
2.找边界点
3.针对边界点设计测试用例
错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的对被测试软件的需求理解以及设计实现的细节把握，还有个人经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
如：1.验证码大小写不区分
2.空格搜索，把输入的搜索信息前后空格忽略
场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务的感觉，从而避免陷入功能细节忽视业务流程药典的错误倾向。
案例：
ATM机取款场景
功能点：插卡——输入密码——输入钱数——取款
具体功能点：：
（1）插卡：插反，插错卡，注销，消磁，冻结，有不良记录的卡
（2）输入密码：密码错误，密码输入正确，密码三次错误，第一次密码错，第二次密码对，前两次密码错，第三次密码对
（3）输入钱数：钱数<=银行卡余额，输入钱数>=银行卡余额，输入的不是整百，ATM机余额不足，超过每次取款限额，超过每次取款最大上限，超过每次取款最大次数
（4）取款：确认取款钱数后，ATM机吐出对应钱数，ATM机吐钞规则，操作超时，长时间不吐钱
（5）其他：ATM机断网，断电，出现故障，超时，所有的操作如果超时，那么会出现吞卡
因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件，程序的输出又依赖于输入条件的各种情况
因果图需要掌握的基本知识
-
恒等
恒等：如果原因为真，那么结果必定为真。例如：动物园运来大熊猫，动物园一定有大熊猫
- 与
只有两个原因都为真，那么结果为真
- 或
两个原因中只有一个为真时，结果就为真
- 非
只有原因为假，结果才为真。例如：你不好好学习，找到好工作
因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入与输出，会耗费大量时间
因果图法设计测试用例步骤
1.分析出所有的输入和输出
2.找出输入和输出之间的关系
3.画因果图
5.针对因果图设计测试用例
正交排列
因果法设计用例太多怎么办？
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的实验。
因素：在一项试验中，凡是要考察的变量称为因素（变量）
水平（位级）：在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成
行数：正交表中行的个数，即试验的次数，用N代表
因素数：正交表中列的个数，用C代表
水平数：任何单个因素能够取得的值的最大个数
正交表的表示形式：L=行数（水平数*因素数）L=N（TC）
正交表的两条性质：
每一列中各数字出现的次数都一样多
任何两列中的各有序数对出现的次数都一样多
正交排列设计测试用例的步骤
1.有哪些因素（变量）
2.每个因素有哪几个水平（变量的取值）
3.选择一个合适的正交表
4.把变量的值映射到表中
5.把每一行的各因素水平的组合作为一个测试用例
6.加上你认为可疑且没有在表中出现的用例组合
3.测试用例的有效性？
（1）测试用例对应的功能已删除，不可操作了
（2）执行一条测试用例未发现BUG，实际该处有BUG
（3）执行一条测试用例发现了BUG
（4）执行一条测试用例未发现BUG，实际该处BUG已修复
三、测试用例的粒度
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
粒度：指测试用例编写的详细程度
测试用例可以写的很简单，也可以写的很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等。
（1）测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
（2）测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况，测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容：
- 产品的质量要求
- 项目对用例的要求
- 测试时间和资源是否充分
1464
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
