软件系统测试用例设计,软件系统测试用例设计要注意的问题

软件系统测试用例设计要注意的问题

发表于：2010-10-29来源：作者：点击数：

软件系统 测试用例 设计要注意的问题 软件测试 如何开展 系统测试 用例的设计?实际工作中大概是这样的： 1、分析需求。 2、划分测试模块。 3、针对各测试模块，依次开展测试设计。 流程本身好理解，同一份需求，不同的人设计出的用例 质量 可能差别很大。 最

软件系统

如何开展

1、分析需求。

2、划分测试模块。

3、针对各测试模块，依次开展

流程本身好理解，同一份需求，不同的人设计出的用例

最近一个月连续组织或参与了多次测试用例评审，涉及多个产品，提出了一些意见，也反思了一下设计过程。偶有一些想法，暂且称之为“系统

1、“分析需求”阶段

(1)理解需求。[1]理解需求要从理解商业模式(或者盈利模式)入手，只有站在这个高度才可能真正理解需求为什么要如此这般设计。比如XX产品的“隐藏拨号”功能，评审时有人就是想不通为什么要这么设计，当提醒她盈利模式的时候问题变得豁然开朗。[2]理解需求要熟知产品功能的业务逻辑，再说电话功能，有一路通话、多路通话、电话会议等业务，这些业务有什么区别?如何开通?如何使用?[3]理解需求要弄清楚产品功能相关的业务背景

(2)分析需求。关键是把握需求中的关键点，比如：[1]哪些需求是产品特色、哪些需求是产品的主干功能、哪些需求是产品

(3)还原真实的需求。feature list的质量不总是如你所愿，我们需要在理解和分析需求的基础上学会还原真实的需求。[1]细化需求。总有一些功能设计过于粗燥，描述不构具体，虽然需求没写出来，但我们要有自己的一本明白帐。[2]拆分需求。有一些功能点被罗列在一个分支下，这可能让你觉得别扭，明明无关却被拼凑到一起，与其这样不如拆分开理解对待。[3]重组需求。业务逻辑上有着紧密关联的需求可能被分散到不同的分支，不如把它们合并到一起进行重组。[4]修正需求。错误的、不当的需求描述，需要进行修正。

2、“划分测试模块”阶段

需求有着自己的组织结构划分，测试同样也需要有模块划分，划分的原则有：

(1)减少用例设计冗余度。

(2)加强用例执行期间的关联度。

需求分析阶段我们提到“不同的主干/分支/节点，可能在业务逻辑上有着紧密的关联”，尽管我们会去还原真实的需求，但往往还是要保持需求的原样，在这种情况下我们可以通过测试模块划分的方法把它们重组到一起，避免重复的用例设计，也方便把用例执行期间的测试区域控制在一个尽可能小的范围内，避免来回重复切换影响操作效率。

3、“用例设计”阶段

这个阶段，用例设计的方法固然重要，但除了运用这些方法，我们更加不能忽略对于测试点的考虑。比如：XX应用程序的版本自动升级功能，其下列出“登陆版本

* 取得更新功能的权限(要登陆才行)

* 更新检查功能(要实现如何判别有新版本发布)

* 从服务器取版本规则(当前所用版本比较低，已累计有多个新版本发布?取哪个?)

* 版本更新状态管理(已更新、取消更新， 版本存储等)

* 版本更新后原有版本的用户数据管理(注册数据，登陆配置，用户配置，用户数据/缓存数据)

* 更新后的版本标识正确性检查(版本号等软件产品标识)

* 安装更新包后如何处理安装包

* 安装更新包的过程是否产生垃圾文件