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

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

　　* 取得更新功能的权限（要登陆才行）

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

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

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

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

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

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

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

　　。。。。。。？

　　把测试点想清楚了，再开始用例设计，针对这些测试点，采用合适的设计方法逐个覆盖。

　　系统测试用例设计的经验太少，认识不够，留下一时之想法待日后印证和改进。

注：本文出自nucboy的51Testing软件测试博客：http://www.51testing.com/?14167