测试用例心得

心得"/>

测试用例心得

测试人员最熟悉的是用例了。为什么写用例呢？用例中有哪些规律可循呢？下面分享几点自己心得。

     书写测试用例目的，是为了能有依有据的验证需求，侧重于用户使用过程中的涉及到的需求点，非验证此段代码，简而言之，避免以下误区：

【过于关心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为:,看到用户名显示:oooo

含有测试数据的用例，能更大程度上提高覆盖率（使用最少case达到覆盖目的）

【举个栗子】比如最常见最熟悉的输入框测试，需求『测试一个输入框，要求长度是6到12位字母或者数字』，测试思路有

输入1到5位数字；输入1到5位小写字母 ；输入1到5位大写字母

一条case平价代替：『输入Aa812』

输入12位小写字母；输入12位大写字母 ；输入12位数字 ；输入12位，包含数字、大小写字母

一条case平价代替：『输入12位aaaaaaaZ8888』

作者：李睿怡

文／siyu8023（简书作者）
原文链接：
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。