目录
1. 测试用例的基本要素
测试用例的概念：
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
评价测试用例的标准：对比好坏代码的评价标准
用例表达清楚，无二义性
用例可操作性强
用例的输入与输出明确，一条用例只有一个预期结果
用例的可维护性好
用例对需求的覆盖率高
暴露程序Bug的能力强
用例的基本要素可以参见如下例子：
| 测试用例 ecsp-439: 单位用户注册成功 | |
| 步骤动作: | 期望的结果: |
| 进入注册页面，选择注册 | 系统展现注册页面 |
| 输入符合要求的单位名称、单位邮箱、密码、确认密码、 组织机构代码、验证码，并确认同意《用户注册协议》， 提交注册信息 | 系统进行注册操作，发送激活邮件。注册成 功后，跳转到注册成功页面，并提示用户进 行激活操作 |
| 进入注册用的邮箱，进行激活操作 | 激活成功 |
| 用注册的邮箱和密码，进行登录操作 | 登录成功，系统展示欢迎页面 |
| 测试方式 | 手工 |
| 重要性 | 重要 |
| 测试环境 | CHROME,IE10+ |
| 测试前提 | 系统运行正常，邮件服务器已开启 |
| 功能模块 | 注册登录 |
2. 测试用例的给我们带来的好处
a) 测试执行者的依据
b) 使得工作可重复，自动化测试的基础
c) 评估需求覆盖率
d) 用例的复用
e) 积累测试的方法思路以供后续借鉴
使用中带来困扰 :
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
解决如下问题：
不知道是否较全面的测试了所有功能,测试的覆盖率无法衡量,对新版本的重复测试很难实施,存在大量冗余测试影响,测试效率
3. 测试用例的设计方法
3.1 测试用例的总体设计方法
基于需求的设计
RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题
（1）验证需求是否正确、完整、无二义性，并且逻辑一致
（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求
3.2 具体的设计方法
3.2.2 等价类
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用 例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能 穷举测试的问题
有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是 否实现了规格说明中所规定的功能和性能
无效等价类：根据需求说明书，不满足需求的集合
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充
3.2.3 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界
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五个长度的字符的输入值
3.2.4 因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图 法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输 入条件的各种情况
因果图的需要掌握的基本知识
a) 恒等
恒等：如果原因为真，那么结果必定为真。 例如：动物园运来大熊猫，动物园一定有大熊猫
b) 与
只有2个原因都为真，那么结果为真。 例如：北京姑娘，必须有车且有房
c) 或
2个原因中有一个为真时，结果就为真。 例如：长沙姑娘，你有车或者有房
d) 非
只有原因为假，结果才为真。 例如：你不好好学习，找到好工作
因果图法设计测试用例的步骤如下:
(1)分析所有可能的输入和可能的输出
(2)找出输入与输出之间的对应关系
(3)画出因果图
(4)把因果图转换成判定表
(5)把判定表对应到每一个测试用例
3.2.5 正交排列
因果法设计用例太多怎么办？
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验 因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找 出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验
a) 因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
b) 水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）
c) 正交表的构成：
行数(Runs)：正交表中的行的个数，即试验的次数,用N代表
因素数(Factors)：正交表中列的个数，用C代表
水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平 数”，用T代表
d) 正交表的表示形式： L=行数(水平数*因素数) L=N(TC)
e) 正交表的两条性质：
每一列中各数字出现的次数都一样多
任何两列所构成的各有序数对出现的次数都一样多
f) 正交法设计测试用例的步骤：
1、有哪些因素（变量）
2、每个因素有哪几个水平（变量的取值）
3、选择一个合适的正交表
4、把变量的值映射到表中
5、把每一行的各因素水平的组合作为一个测试用例
6、加上你认为可疑且没有在表中出现的用例组合
发散一下：实际工作中这种做法会不会常见？在那种项目中需要这样做？实际中我们会怎么做？
不常见
科学实验性更需要
实际中可能会看代码或者想象可能的代码来减少用例
3.2.6 场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向
3.2.7 错误猜测法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多
4. 什么是测试用例的有效性？
a) 测试用例对应的功能已删除，不可操作了
微信刚出来时与QQ可互发消息，下一个版本后就不可以发消息。
b) 执行一条测试用例未发现BUG，实际该处有BUG
苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程 序扫码开锁。
c) 执行一条测试用例发现了BUG
苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现
d) 执行一条测试用例未发现BUG，实际该处BUG已修改
苹果7手机微信添加了mobile单车小程序扫码开锁，可以正常开锁
5. 测试用例的粒度和评价
5.1 测试用例的粒度
粒度：指测试用例编写的详细程度。
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等
(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维
(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是 把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试 的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例
主要考虑可以参考如下内容：
产品的质量要求
项目对用例的要求
测试时间和资源是否充分
但是不管用例怎么简化，都不应该省略
5.2 测试用例的评价
测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例 的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审
同行评审
用户检查
项目组评审
（1）测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审， 应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例
（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了
(3) 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出
如有错误还请各位小伙伴批评指正
最后美图收尾嘻嘻~~(星之守护者 金克斯)
932
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
