软件测试(三)——软件测试用例篇

在熟悉了业务之后,往往会分配来写测试用例,并且在日常测试中,有时也需要补充测试用例到现有的案例库中。本文我们将解决以下问题:

  • 测试用例的基本要素
  • 测试用例的设计方法
  • 基于需求的设计方法
- 等价类  
- 边界值   
- 因果图   
- 正交排列   
- 场景设计法   
- 错误猜测法
  • 测试用例的有效性
  • 测试用例的粒度和评价

测试用例的基本要素

回顾测试用例的概念:
测试用例 (Test Case) 是为了实施测试而向被测试的系统提供的一组集合, 这组集合包含: 测试环境、操作步骤、测试数据、预期结果等要素。
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

  • 评价测试用例的标准:对比好坏用例的评价标准
  • 用例表达清楚,无二义性。
  • 用例可操作性强。
  • 用例的输入与输出明确。一条用例只有一个预期结果。
  • 用例的可维护性好。
  • 用例对需求的覆盖率高。

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

测试执行者的依据
使得工作可重复, 自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴
使用中带来困扰
测试用例的设计是费时费力的工作,往往设计测试用例所花费的时间比执行所花费的时间还多
解决如下问题
不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗 余测试影响测试效率

测试用例的设计方法

基于需求进行测试用例的设计

基于需求设计测试用例是测试设计和开发测试用例的基础,第一步就要分析测试需求,验证需求是否正 确、完整、无二义性,并且逻辑自洽。在需求正确的基础上细化测试需求,从测试需求提炼出一个个测 试点或者测试项,然后根据每一个测试点进行测试用例的设计;
在分析测试需求时,一般分为功能测试需求和非功能测试需求

功能需求测试分析

对于功能测试中,可以借助功能框图来帮助我们进行测试的需求分析。概括起来,功能测试需求包括以 下,通常包括以下几个方面。
(1)系统各个功能界面的验证
(2)借助业务把功能串起来进行测试
(3)功能的一致性,交互性(多功能互操作)的测试
(4)系统的不同输入,结果输出的业务数据测试。
(5)功能的错误操作,异常操作的测试(属于负面测试)
(6)功能实现用到的算法验证,有时需要用运代码评审
(7)用户操作的易用性,用户体验,往往结合功能测试同时验证。
针对具体的需求,可以根据业务分类,用户角色(餐厅的会员系统)或者用户操作区域等将系统的功能 分解成若干个功能模块,然后按照功能模块分别进行测试需求分析。按照功能模块划分,业务模块划分 是最常见的做法。
下面对一个简单的日历系统的需求进行分析

日历

对日历根据web界面的功能布局分析出的功能框图如下:
功能布局分析出的功能框图](https://img-blog.csdnimg.cn/e34aa1a6427b4b1a8b42cb5899b4cfc6.png)

也可以采用思维导图的方式,更为方便,有效,只管的呈现测试需求的分析结果,可以更好的支持测试
分析思路的连贯性。
下面以我们常用的百度云盘手机端为例进行分析功能

百度云盘手机端为例进行分析功能

在进行需求分析的时候,我们还要考虑业务规则如,上传文件的大小有没有限制;一次性崔铎上传多少 数量的文件,比如小于100个;文件夹最多有多少层等等;

非功能需求测试分析

非功能测试需求主要涉及性能,安全性,可靠性,兼容性,易维护性和可移植性等。从测试需求分

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

王嘻嘻-

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值