步骤1：用例划分
1.按系统模块划分
2.按性质分类划分
3.按关联紧密程度划分
1.按系统模块划分
一般设计比较好的系统软件，都会把功能进行分类，并以模块的方式布局在用户界面上，如图：【目标管理】，【课程管理】，【学员管理】，大模块下再分小模块，比如【课程管理】模块又分【课程列表】，【项目资源管理】。
用例划分：针对每个模块、子模块或子模块的模块设计用例
优点：容易展开，简单明了
缺点：
1.业务逻辑容易被忽视。模块与模块之间往往是关联的。
2.容易忽略非UI功能的测试，比如安装测试
举例：数据库审计系统，【规则模块】，【对象模块】
【规则模块】：存放规则，比如操作表名xx的规则
【对象模块】：存放对象，比如表名对象，操作方式对象
关联：规则引用对象
业务流程：客户操作->产生浏览数据->系统捕获数据->检测操作对象与规则引用的对象->如果对象匹配则触发规则并执行规则中指定的动作
单独测两个模块可能都没问题，但是结合起来，在【对象模块】中把【规则模块】中规则正在引用的对象删除，那结果会咋样？难说吧
2.按性质分类划分
用例划分：兼容性测试，压力测试，安装测试，容量测试，可靠性…
好处：对按模块划分的有效补充。
3.按关联紧密程度划分
用例划分：也是按模块划分，区别是把关联比较紧密的模块归到某个模块
好处：有利于任务分配，减少人力资源的重复投入
如果按模块来，测试我的笔记的人需要去观看课件并提交笔记，而测试课件观看的人又要测提交笔记，很明显的，“提交笔记”重复投入了劳力。如果把提交笔记归到我的笔记模块，这样按模块分配用例，分配给同一个人去测，这就减少了交叉，减少重复的劳动
步骤2：用例设计
1、设计思想
2、用例编写
1、设计思想
a)测试点来源与定位
来源
测试点来源：一、显式需求二、隐式需求。一个需求点可以对应多个测试点
定位测试点
测试点其实也就是测试目的。用例定义了“怎么测”，而测试点则定义了“为何测”，所以，设计前必须明白测试点是什么，且一个用例仅对应一个测试点。
理由：便于统计，测试用例对整个测试过程的质量控制和评估有很重要的意义：
一、测试需求覆盖率分析。如果一个用例包含几个测试点，那么不利于需求覆盖分析
二、用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多，那么你做的用例成功率还有什么意义？
三、缺陷分析。如果用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候如果有指定回归用例，那用例中那些些与缺陷不相关的测试点也可能也被回归，增加工作量。
以下3点想法帮助你更好的定位测试点
1.站在用户使用角度来考虑，看你定位的“测试点”是否有实际意义
2.考虑你定位的“测试点”的完成能否标志着用户实际业务流程的一个阶段性结束？
3.考虑你定位的“测试点”的完成，是否可以为其他用户或业务提供输入数据，以供完成下面的工作？
综合2-3点：划清界线，点到即止
例子：QQ邮箱注册
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
