测试用例设计实现

我们都知道一般黑盒的测试用例的设计方法主要有边界值分析,等价类划分,因果图分析和错误推测法.
用例划分：针对每个模块、子模块或子模块的模块设计用例
优点：容易展开，简单明了
缺点：
1.业务逻辑容易被忽视。模块与模块之间往往是关联的。
2.容易忽略非UI功能的测试，比如安装测试

举例：数据库审计系统，【规则模块】，【对象模块】
【规则模块】：存放规则，比如操作表名xx的规则
【对象模块】：存放对象，比如表名对象，操作方式对象

关联：规则引用对象
业务流程：客户操作->产生浏览数据->系统捕获数据->检测操作对象与规则引用的对象->如果对象匹配则触发规则并执行规则中指定的动作

单独测两个模块可能都没问题，但是结合起来，在【对象模块】中把【规则模块】中规则正在引用的对象删除，那结果会咋样？难说吧

2.按性质分类划分
用例划分：兼容性测试，压力测试，安装测试，容量测试，可靠性…
好处：对按模块划分的有效补充。

3.按关联紧密程度划分
用例划分：也是按模块划分，区别是把关联比较紧密的模块归到某个模块
好处：有利于任务分配，减少人力资源的重复投入

举例：手机在线教育APP应用，打开应用有 我的课程，我的笔记，我的问题等模块，其中，我的笔记，笔记记录来自课程模块，观看课件学习时进行提交的。
如果按模块来，测试我的笔记的人需要去观看课件并提交笔记，而测试课件观看的人又要测提交笔记，很明显的，“提交笔记”重复投入了劳力。如果把提交笔记归到我的笔记模块，这样按模块分配用例，分配给同一个人去测，这就减少了交叉，减少重复的劳动

步骤2：用例设计
1、设计思想
2、用例编写

1、设计思想
a) 测试点来源与定位
来源
测试点来源：一、显式需求 二、隐式需求。一个需求点可以对应多个测试点

定位测试点
测试点其实也就是测试目的。用例定义了“怎么测”，而测试点则定义了“为何测”，所以，设计前必须明白测试点是什么，且一个用例仅对应一个测试点。

理由：便于统计，测试用例对整个测试过程的质量控制和评估有很重要的意义：
一、测试需求覆盖率分析。如果一个用例包含几个测试点，那么不利于需求覆盖分析
二、用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多，那么你做的用例成功率还有什么意义？
三、缺陷分析。如果用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候如果有指定回归用例，那用例中那些些与缺陷不相关的测试点也可能也被回归，增加工作量。

以下3点想法帮助你更好的定位测试点
1.站在用户使用角度来考虑，看你定位的“测试点”是否有实际意义
2.考虑你定位的“测试点”的完成能否标志着用户实际业务流程的一个阶段性结束？
3.考虑你定位的“测试点”的完成，是否可以为其他用户或业务提供输入数据，以供完成下面的工作？
综合2-3点：划清界线，点到即止