【测试开发】用例篇

博客主页：敲代码的布莱恩特
欢迎点赞收藏留言欢迎讨论！
本文由 【敲代码的布莱恩特】 原创，首发于 CSDN
由于博主是在学小白一枚，难免会有错误，有任何问题欢迎评论区留言指出，感激不尽！
精品专栏（不定时更新）【JavaSE】 【Java数据结构】【LeetCode】

测试用例的基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合
这组集合包含：
测试环境、操作步骤、测试数据、预期结果等要素。

评价测试用例的标准：对比好坏代码的评价标准

• 用例表达清楚，无二义性。。
• 用例可操作性强。
• 用例的输入与输出明确。一条用例只有一个预期结果。
• 用例的可维护性好。
• 用例对需求的覆盖率高，
• 暴露程序Bug的能力强力。

用例的基本要素可以参见如下例子：

测试用例的给我们带来的好处

• 测试执行者的依据
• 使得工作可重复，自动化测试的基础
• 评估需求覆盖率
• 用例的复用
• 积累测试的方法思路以供后续借鉴

1. 使用中带来困扰
   测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
2. 解决如下问题：
   不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率

测试用例的设计方法

测试用例的总体设计方法

基于需求的设计方法

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也就越多。

案例：
以注册为例

1. 校验中特殊字符空格的处理?
2. 密码校验中的大小写？
3. 姓名中的特殊字符？
4. 密码发送是否明文?

测试用例的有效性

测试用例对应的功能已删除，不可操作了

微信刚出来时与QQ可互发消息，下一个版本后就不可以发消息。

执行一条测试用例未发现BUG，实际该处有BUG

苹果7手机微信添加了mobile单车小程序，扫码不能开锁，只能使用mobile APP开锁，测试用例未涉及到苹果7微信小程序扫码开锁。

执行一条测试用例发现了BUG

苹果7手机微信添加了mobile单车小程序，用例已写到了苹果7微信添加mobile小程序扫码开锁，问题被发现

执行一条测试用例未发现BUG，实际该处BUG已修改

苹果7手机微信添加了mobile单车小程序扫码开锁，可以正常开锁

测试用例的粒度和评价

测试用例的粒度

粒度：指测试用例编写的详细程度。

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。

而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

(2)测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

主要考虑可以参考如下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

测试用例的评价

测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

评审分为正式和非正式评审。

同行评审
用户检查
项目组评审

（1）测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。

（3）由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。

面试案例

某公司招聘测试工程师时，有一道这样的笔试题：
”某手机软件有用TF卡导出数据的功能，请写出测试此功能点的思路”

考虑方向	检查点	测试思路描述
正向	导出数据正确性	导出数据，验证数据正确性
逆向	导出数据有效性	无数据时，导出功能是否正确
边界容量	TF卡空间不足	只能容纳部分数据
边界容量	TF卡容量已满
容错	TF卡写保护
容错	TF卡无法识别
容错	人为中断	导出时拔掉TF卡
容错	导出时断电、关机等	再开机后检查能否正确导出
性能	连续多次导出	脚本实现，大量导出，查看数据是否正确
性能	检查导出速度
兼容性	不同品牌和容量
兼容性	不同分区格式FAT,FAT32，NTFS	不使用手机自带的T卡格式化功能