史上最详细测试用例设计实践
步骤1：用例划分
1.按系统模块划分
2.按性质分类划分
3.按关联紧密程度划分
1.按系统模块划分
一般设计比较好的系统软件，都会把功能进行分类，并以模块的方式布局在用户界面上，如图：【目标管理】，【课程管理】，【学员管理】，大模块下再分小模块，比如【课程管理】模块又分【课程列表】，【项目资源管理】。
用例划分：针对每个模块、子模块或子模块的模块设计用例
优点：容易展开，简单明了
缺点：
1.业务逻辑容易被忽视。模块与模块之间往往是关联的。
2.容易忽略非UI功能的测试，比如安装测试
举例：数据库审计系统，【规则模块】，【对象模块】
【规则模块】：存放规则，比如操作表名xx的规则
【对象模块】：存放对象，比如表名对象，操作方式对象
关联：规则引用对象
业务流程：客户操作->产生浏览数据->系统捕获数据->检测操作对象与规则引用的对象->如果对象匹配则触发规则并执行规则中指定的动作
单独测两个模块可能都没问题，但是结合起来，在【对象模块】中把【规则模块】中规则正在引用的对象删除，那结果会咋样？难说吧
2.按性质分类划分
用例划分：兼容性测试，压力测试，安装测试，容量测试，可靠性…
好处：对按模块划分的有效补充。
3.按关联紧密程度划分
用例划分：也是按模块划分，区别是把关联比较紧密的模块归到某个模块
好处：有利于任务分配，减少人力资源的重复投入
举例：手机在线教育APP应用，打开应用有我的课程，我的笔记，我的问题等模块，其中，我的笔记，笔记记录来自课程模块，观看课件学习时进行提交的。
如果按模块来，测试我的笔记的人需要去观看课件并提交笔记，而测试课件观看的人又要测提交笔记，很明显的，“提交笔记”重复投入了劳力。如果把提交笔记归到我的笔记模块，这样按模块分配用例，分配给同一个人去测，这就减少了交叉，减少重复的劳动
步骤2：用例设计
1、设计思想
2、用例编写
1、设计思想
a)测试点来源与定位
来源
测试点来源：一、显式需求二、隐式需求。一个需求点可以对应多个测试点
定位测试点
测试点其实也就是测试目的。用例定义了“怎么测”，而测试点则定义了“为何测”，所以，设计前必须明白测试点是什么，且一个用例仅对应一个测试点。
理由：便于统计，测试用例对整个测试过程的质量控制和评估有很重要的意义：
一、测试需求覆盖率分析。如果一个用例包含几个测试点，那么不利于需求覆盖分析
二、用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多，那么你做的用例成功率还有什么意义？
三、缺陷分析。如果用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候如果有指定回归用例，那用例中那些些与缺陷不相关的测试点也可能也被回归，增加工作量。
以下3点想法帮助你更好的定位测试点
1.站在用户使用角度来考虑，看你定位的“测试点”是否有实际意义
2.考虑你定位的“测试点”的完成能否标志着用户实际业务流程的一个阶段性结束？
3.考虑你定位的“测试点”的完成，是否可以为其他用户或业务提供输入数据，以供完成下面的工作？
综合2-3点：划清界线，点到即止
例子：QQ邮箱注册
如上图，单独把任意一个选框拿出来并为其设计一个用例，站在用户角度来看，都无实际意义。用户关注的是我填写完资料并点击注册，能生成一个可用帐号，为登录功能提供输入数据。所以设计用例时，这里的测试目的应该定位为帐号注册，而不是某个选框的特性测试。那输入框的特性，比如上述咋办？这个就是方法问题了， 类似这样的，可以考虑用场景法来设计。
举例：音乐台音乐短片扑克牌花式技巧演示"五个窍门”视频播放
操作流程：点击扑克牌花式技巧演示"五个窍门”视频连接，自动打开视频播放界面，边缓冲，以边播放，播放完成，出现上述界面，给出“重播”按钮提示。
不考虑试测试点粒度和分割(1条用例)：
1.点击视频连接--打开视频播放界面
2.查看打开的播放器界面--一边进行视频缓冲，一边自动播放缓冲好的视频部分
3.等待播放结束，查看播放器界面--出现重播按钮和推荐短片
4.点击重播按钮--重新播放已缓冲完成的视频
考虑试测试点粒度和分割(2条用例)：
用例1：在线视频播放功能
1.点击视频连接--打开视频播放界面
2.查看打开的播放器界面--视频以边缓冲，一边自动播放
3.等待播放结束，查看播放器界面--出现重播按钮和推荐短片
用例2：视频重播功能
1.打开视频进行播放直到播放结束，查看播放器界面--出现重播按钮和推荐短片
2.点击重播按钮--重新播放打开的视频
这里用例操作过程似乎有点冗余，但是从测试目的考虑是允许的：对用例2来说，步骤1可看成是为测试重播而必须经过的一条路线，不是测试重点，而对用例1而言，用例2中的步骤1则是测试重点。进一步，结束播放时的画面还有推荐视频。对这个设计用例，模仿用例2也显得很容易，思路清晰。
举例：在线教育系统，手机端离线视频学习
操作流程：网络连接下，下载课件视频，网络断开下，查看打开视频学习，提交离线笔记，新增待同步学识记录。网络连接，点击同步学识记录按钮进行服务端与手机端的同步。
从以上3点想法来考虑，可定位以下两个测试点：
1.保存离线笔记
2.同步离线笔记
可能有人会觉得，以上2个测试点也可以合并在一起。对的，但是你再结合一个用例对应一个测试点就好理解为何不合并了。
备注：用例是死的，人是活的，例中所举的例子都存在一定的冗余，执行的时候可以考虑执适当的用例执行顺序来减少操作冗余。
举例：教师端学员信息修改
点击修改，弹出修改界面，继续点击单位，出现如图界面
点击修改界面中的【单位】设置框，弹出的是一个单位搜索和选择对话框，如果不独立出来，对搜索框的准确性验证也加到修改功能的用例里，用例会显得庞大，而且测试点不单一，咋办？
单独出来，目的就是对其搜索或展示数据(单位)准确性，找不到单位联系客服等功能验证，比如，是否错乱，是否少了等进行验证，是有意义的，因为这个测试点的输出数据为这个资料修改模块提供了输入数据，使其可往下执行。而修改中则仅关注单位选择作用。
b）分离测试数据与测试逻辑（步骤）
方法：将用例中的一些输入、输出等作为参数，数据则单独列出，在执行时选择相应的数据执行。
理由：为什么要参数化？
a、没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大，不利于测试员理解，导致难以控制和执行；
b、通过将用例参数化，可以简化用例，使测试用例逻辑清晰，数据不逻辑的关系明了，易于理解；
c、有利于提高测试用例的重用；
选择参数化内容
测试用例中需要通过使用不同数据来重复执行测试的部分；
包括：
a、输入（数据或操作等）
b、输出（结果数据或预期结果等）
举例
例一：系统登陆
测试数据
当然，这里的案例也存在不妥的地方，也就说包含了多个测试点，另外，要是再加个验证码，那就更不妥了。。。
c)依据业务逻辑进行设计
（关于业务逻辑的详细说明可参考另一文档）
举例说明什么是业务逻辑：
网上购物
业务流程：用户登录-选择商品-结算-下订单-付款-确认收货，这是一个流程
业务规则：当用户下单付款后必须通知卖家，有顾客光临
业务实体：订单信息，包含购买物品，买家，金额等
业务实体完整性：如：订单信息中，买家不可少，物品id不能为空
根据上述，可以得出优先级：业务流程>业务规则>实体完整性
当然这顺序不是绝对的。
思想：
根据80/20原则，百分之80的用户只使用了产品20%的核心功能，测试要多站在用户角度进行模拟测试，有些测试站在测试的角度看是有意义的，站在用户的角度看却没多大意义，因为有些类似边界值的数据用户极少或根本不会用。（注意我这里的用词），所以要保证基本的核心功能可用。这样写出来的用例优先级也比较好分，一目了然
