如何开展系统测试用例的设计?实际工作中大概是这样的:

  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应用程序的版本自动升级功能,其下列出“登陆版本服务器、检查版本更新情况、自动下载和安装新版本”几个子功能,如果一上来盲目套用测试设计方法,往往会有遗漏。不妨先思考下版本自动升级功能大概有哪些测试点:

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

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

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

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

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

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

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

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