软件系统测试用例设计要注意的问题
作者:网络转载 发布时间:[ 2010/10/29 10:44:07 ] 推荐标签:
如何开展系统测试用例的设计?实际工作中大概是这样的:
1、分析需求。
2、划分测试模块。
3、针对各测试模块,依次开展测试设计。
流程本身好理解,同一份需求,不同的人设计出的用例质量可能差别很大。
近一个月连续组织或参与了多次测试用例评审,涉及多个产品,提出了一些意见,也反思了一下设计过程。偶有一些想法,暂且称之为“系统测试用例设计要注意的问题”,整理如下:
1、“分析需求”阶段
(1)理解需求。[1]理解需求要从理解商业模式(或者盈利模式)入手,只有站在这个高度才可能真正理解需求为什么要如此这般设计。比如XX产品的“隐藏拨号”功能,评审时有人是想不通为什么要这么设计,当提醒她盈利模式的时候问题变得豁然开朗。[2]理解需求要熟知产品功能的业务逻辑,再说电话功能,有一路通话、多路通话、电话会议等业务,这些业务有什么区别?如何开通?如何使用?[3]理解需求要弄清楚产品功能相关的业务背景知识,比如电话功能,要从技术上了解电话功能的实现原理。[4]理解需求要学会拿它与其它同类产品对比,或参考自己有使用经验的同类产品,通过对比或参照来启发自己理解需求的灵感和深度。
(2)分析需求。关键是把握需求中的关键点,比如:[1]哪些需求是产品特色、哪些需求是产品的主干功能、哪些需求是产品开发的难点?特色和主干功能是测试的重点,从技术实现上讲,开发难点往往是容易出纰漏的地方。[2]需求有无优先级区分?一般说,产品立项时会从开发实现先后顺序上对需求进行级别定义,测试时也需要据此对测试设计或测试执行的顺序进行级别区分。[3]不同的主干/分支/节点,可能在业务逻辑上有着紧密的关联,只是产品定义人员在规划功能列表时考虑问题的角度不同,但无论如何在需求分析阶段我们要能识别出来,以便于测试模块的划分。
(3)还原真实的需求。feature list的质量不总是如你所愿,我们需要在理解和分析需求的基础上学会还原真实的需求。[1]细化需求。总有一些功能设计过于粗燥,描述不构具体,虽然需求没写出来,但我们要有自己的一本明白帐。[2]拆分需求。有一些功能点被罗列在一个分支下,这可能让你觉得别扭,明明无关却被拼凑到一起,与其这样不如拆分开理解对待。[3]重组需求。业务逻辑上有着紧密关联的需求可能被分散到不同的分支,不如把它们合并到一起进行重组。[4]修正需求。错误的、不当的需求描述,需要进行修正。
2、“划分测试模块”阶段
需求有着自己的组织结构划分,测试同样也需要有模块划分,划分的原则有:
(1)减少用例设计冗余度。
(2)加强用例执行期间的关联度。
需求分析阶段我们提到“不同的主干/分支/节点,可能在业务逻辑上有着紧密的关联”,尽管我们会去还原真实的需求,但往往还是要保持需求的原样,在这种情况下我们可以通过测试模块划分的方法把它们重组到一起,避免重复的用例设计,也方便把用例执行期间的测试区域控制在一个尽可能小的范围内,避免来回重复切换影响操作效率。
3、“用例设计”阶段
这个阶段,用例设计的方法固然重要,但除了运用这些方法,我们更加不能忽略对于测试点的考虑。比如:XX应用程序的版本自动升级功能,其下列出“登陆版本服务器、检查版本更新情况、自动下载和安装新版本”几个子功能,如果一上来盲目套用测试设计方法,往往会有遗漏。不妨先思考下版本自动升级功能大概有哪些测试点:
* 取得更新功能的权限(要登陆才行)
* 更新检查功能(要实现如何判别有新版本发布)
* 从服务器取版本规则(当前所用版本比较低,已累计有多个新版本发布?取哪个?)
* 版本更新状态管理(已更新、取消更新, 版本存储等)
* 版本更新后原有版本的用户数据管理(注册数据,登陆配置,用户配置,用户数据/缓存数据)
* 更新后的版本标识正确性检查(版本号等软件产品标识)
* 安装更新包后如何处理安装包
* 安装更新包的过程是否产生垃圾文件
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11