测试用例心得
测试人员最熟悉的是用例了。为什么写用例呢？用例中有哪些规律可循呢？下面分享几点自己心得。书写测试用例目的，是为了能有依有据的验证需求，侧重于用户使用过程中的涉及到的需求点，非验证
此段代码，简而言之，避免以下误区：
【过于关心bug数目】bug是验证需求过程中的产物，非目标，不能说 验证中发现bug越多，QA业绩就好
【设计过于复杂用例】用例目的，验证『实际用户使用过程』是否有问题，提前扫雷，避免上线后用户使用
出现问题；不要跑偏至『找出这部分代码所有错误』
【代码依据需求来实现】1.我们让它做的它必须会做。2.我们不让它做的它必须不会做
一、测试前的准备：
1.了解同类竞品
2.仔细阅读PRD、交互、视觉图
二、case设计
1.拆分功能点
1）基本功能，主要指app是否覆盖所有功能
分清模块→ 考虑自己写出初步checklist，避免漏测
考虑横竖屏切换，不过很多app现在只支持竖屏
各类元素：btn、link、下拉框、输入框、弹框
2）系统交互:电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等
3）测试小点：流程中衔接点到底显示什么、流程中断后显示什么、意外掉线—>重登—>页面如何显示
比如【使用工具】xmind
①尽量画出每个分支一个方块（操作/结果）+一个菱形（条件）≈一块#拆分成功能点#
②尽量画出可能的流程
③流向明确，分清先后
④明确每个判断的真假条件
⑤更具体描述操作步骤
⑥考虑配置和环境的影响
及时记录不明确点 # 比如流程中衔接点到底显示什么、流程中断后显示什么、意外掉线—>重登—>页面如
何显示#
4）描述准确、无歧义
描述只对应1种执行，尽量避免一条描述中包含多种执行情况
比如页面有弹框+蒙层，用例描述『返回操作』的用例涉及以下3种操作
① 点击弹框『取消』or『返回』btn
② 点击蒙层
③ 手机物理返回键
2.功能的场景
基于场景的测试用例生成和维护
1）任何功能，保证基本流和备选流
①基本流，是正常流程（基线baseline）
②备选流，是异常情况/包括不限于失败情况
③场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景
【举个栗子】开户流程设置交易密码
正常场景：弹出设置交易密码框后，输入符合要求的+输入两次一致密码
弹出设置交易密码框后，点击返回，返回弹出框前页面
备选场景：弹出设置交易密码框后，点击手机物理返回键，返回弹出前页面
异常场景：弹出设置交易密码框后，账号掉线，输入符合要求的密码后 → 进入登录页 →登录成功后，返
回交易密码框页面。此时页面提示账号重新登录的信息应该消失
推测场景：弹出设置交易密码框后，输入符合要求的密码 → 确定交易密码框，点击返回后 → 弹出退出框
→ 取消框，继续流程 ，
【问题1】观察返回哪个页面？此时应该在确认交易密码框
【问题2】此时是否清空输入呢，一般产品需求没有说明此点，常识中清空和不清空都有一定合理性，『是
否清空』需要及时和产品确认
【心得】这是实际测试时发现的，开发实现是：确认框处返回 →取消返回→返回至 设置交易密码框。。。
和正常流程背离。实际上，产品需求文档粒度达不到这么细，QA在实际测试中可以积累更多测试点。QA觉
得测试到某点好像不对，但需求没有定、也木有对应用例时，容易放过，上线后存在功能隐患。
2）用户场景中，基本流下+多个备选流组合—>筛选并合并重复场景—>固定场景（基本流+备选流）
3）经验+探索用例
3.外场（网络兼容性）
网络切换，网络信号强，弱下的app运行情况
4.性能
稳定性，兼用型（android碎片化是个难题，bug也多，ios相对bug少），app运行的内存消耗和cpu消耗，
app后台长时间运行的耗流量，耗电量。
推荐testin这个第三方平台，对android兼用性测试比较有帮助。
5.用例优先级和复用率
设计用例=公共case+半公共case+专项case
6. 易用性
面是否吸引人、容易理解。界面整洁、简单。无错别字。点击范围确定等。这部分测试中，如果测试认为
有不合理的地方通常会提交需求bug。
三、实际现状
1.实际用例设计现状
1）阅读需求—>拆分需求点 —> 离散用例点
2）阅读需求和实际测试，人思维是连续。导致设计和回想需求，都是很痛苦过程，遗漏或者反馈阅读片
面需求，导致用例冗余或者缺失
2.调整方法--设计场景
如果基于场景作为设计用例切入点，则
若first time 就基于用户的使用场景进行推演，将各种用户路径绘制成一幅完整的业务流程图（想象用户
角度实际操作），这幅图中可能有若干个开始结点和若干个结束结点（每个结点可以是程序的某个状态，
流程中的某个步骤，网站的某个页面，等等），那么从每个开始结点到每个结束结点间的所有路径，就
是所有可能的场景了
3.用例场景
1）在图中找出强连通分量，把强连通分量当做一个节点处理
2）组成一幅新的图
3）在新图中找出起点和终点
4）对每对起点和终点都寻找存在多少条路径并记录
设计思路：1⃣谁 2⃣做什么 3⃣结果是什么，进行排列组合
四、测试用例_高质量进阶
1.如何编写高质量的测试用例
1）高质量的标准：
1、 覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑）
2、 覆盖到所有的典型用户场景
3、 覆盖到所有的需求点
4、 测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短
5、 没有冗余的用例
6、 测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚
7、易读性，非书写者也能读懂，并100%执行
2）我们应该 to do
1、优先完成业务逻辑图，需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，并且自
己能够理解为什么这样处理
2、根据自己的理解分析每个逻辑的处理是否完善，是否有没有覆盖到的地方，并提交缺陷预防bug
3、根据逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖
4、编写逻辑用例的过程中思考如何去改进该用例的测试过程，比如：接口测试，自动化测试，脚本。并且，
能够及时让研发提供对应的接口和调试方法
5、用例要按照10分钟原则，即保证10分钟内能够执行完成
6、包含测试数据，达到最大执行力，无须另外造数据
【举个栗子】比如以下用例严格来说是错误的
输入正确的用户名
输入正确的密码
点击登录
登录成功
因为用户名和密码，执行者还需要造数据，所以不合适，可以修改为：
注册成功一个账号
输入正确的用户名: admin
输入正确的密码:123456
点击登录
登录成功，跳转到主页，url为:http://www.XXX.com,看到用户名显示:oooo
含有测试数据的用例，能更大程度上提高覆盖率（使用最少case达到覆盖目的）
【举个栗子】比如最常见最熟悉的输入框测试，需求『测试一个输入框，要求长度是6到12位字母或者数字』
，测试思路有
输入1到5位数字；输入1到5位小写字母 ；输入1到5位大写字母
一条case平价代替：『输入Aa812』
输入12位小写字母；输入12位大写字母 ；输入12位数字 ；输入12位，包含数字、大小写字母
一条case平价代替：『输入12位aaaaaaaZ8888』
那我想请教一下：
输入1到5位数字；输入1到5位小写字母 ；输入1到5位大写字母
一条case平价代替：『输入Aa812』
输入12位小写字母；输入12位大写字母 ；输入12位数字 ；输入12位，包含数字、大小写字母
一条case平价代替：『输入12位aaaaaaaZ8888』
那我是放到一条用例中，还是我要分四条用例来体现？ :victory:
页:
[1]
