测试用例的基本要素
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合
这组集合包含：
测试环境、操作步骤、测试数据、预期结果等要素。
评价测试用例的标准：对比好坏代码的评价标准
- 用例表达清楚，无二义性。。
- 用例可操作性强。
- 用例的输入与输出明确。一条用例只有一个预期结果。
- 用例的可维护性好。
- 用例对需求的覆盖率高，
- 暴露程序Bug的能力强力。
用例的基本要素可以参见如下例子：
测试用例的给我们带来的好处
测试执行者的依据
使得工作可重复，自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴
使用中带来困扰
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
解决如下问题：
不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率
测试用例的设计方法
测试用例的总体设计方法
基于需求的设计方法
RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为 它使测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。
（1）验证需求是否正确、完整、无二义性，并且逻辑一致。
（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求
案例1：
用户需求:
购买3000块钱以内的华为智能手机
测试用例：
1.价格<=3000元
2.品牌为华为
3.智能手机
4.手机功能验证：
4-1.打电话
4-2.接电话
4-3.发短信
4-4.收短信
…
案例2：
软件需求：
1.1.1.1.5.3 事件流
1.若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2.每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。
测试用例：
1-1、未收到邮件，登录时输入电子邮件及密码后，再次发送激活邮件
1-2、已收到邮件，登录时输入电子邮件及密码后，不发送激活邮件
2-1、收到邮件，24小时内进行激活
2-2、收到邮件，24小时后链接过期进行激活。
2-3、收到邮件，已激活，24小时后链接过期，再次点击激活？
页面检查：
1、收到激活邮件
2、邮件内容正确
3、激活URl正确，可激活
4、再次激活提示已激活
5、过期激活提示已过期
具体的设计方法
等价类
超市买水果
有效等价类：苹果、桃子、梨
无效等价类：青菜、米、饮料，…
边界值
因果图
因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
因果图需要掌握的基本知识
- 恒等
- 与
或
非
因果图法设计测试用例的步骤如下：
(1)分析所有可能的输入和可能的输出。
(2)找出输入与输出之间的对应关系。
(3)画出因果图。
(4)把因果图转换成判定表。
(5)把判定表对应到每一个测试用例。
案例：
步骤如下：
场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。
错误猜测法
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。
案例：
以注册为例
- 校验中特殊字符空格的处理?
- 密码校验中的大小写？
- 姓名中的特殊字符？
- 密码发送是否明文?
测试用例的有效性
测试用例对应的功能已删除，不可操作了
微信刚出来时与QQ可互发消息，下一个版本后就不可以发消息。
执行一条测试用例未发现BUG，实际该处有BUG
苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程序扫码开锁。
执行一条测试用例发现了BUG
苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现
执行一条测试用例未发现BUG，实际该处BUG已修改
苹果7手机微信添加了mobile单车小程序扫码开锁，可以正常开锁
测试用例的粒度和评价
测试用例的粒度
粒度：指测试用例编写的详细程度。
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。
而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。
(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容：
产品的质量要求
项目对用例的要求
测试时间和资源是否充分
测试用例的评价
测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。
评审分为正式和非正式评审。
同行评审
用户检查
项目组评审
（1）测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
（3）由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。
面试案例
某公司招聘测试工程师时，有一道这样的笔试题：
”某手机软件有用TF卡导出数据的功能，请写出测试此功能点的思路”
