用例设计
2024-05-14 10:50:12 0 举报
AI智能生成
用例设计是一个系统化的过程,用于描述和定义系统或软件的功能需求。这些需求通常来自于用户或客户的期望,并通过用例场景来详细说明。用例描述了用户如何与系统进行交互,以及系统对这些交互的反应。这些用例是软件设计的基础,它们为开发人员提供了关于系统如何工作的详细信息。一份完整的用例文档通常包括用例名称、编号、描述、参与者、前置条件、后置条件、基本事件流、替代事件流、异常事件流等。
作者其他创作
大纲/内容
随机测试、任意测试
发散测试
无方法、无规则、随意
覆盖不充分,完全
穷举测试
完备的测试是不可能的
时间成本
不可能做到全部
目的:
输出:测试用例,指导执行(在第一轮的时候,有多少用例就要执行多少条,就需要经过评审,确定有效的)
人:进度、成本、质量===工作量
尽可能设计少的测试用例,达到对需求的充分覆盖
目标
用例生成过程中,没用到任何方法
套方法,理解有限
用例生成过程中,灵活运用,任何方法都可以,达到(红色)目的
方法
状态转换
N-switch
多用于电商
修改
流程分析(场景法)
主要是来测流程的
基于个人经验
错误推测
新增、删除、修改、查询
输入输出
等价类
等价是什么意思?
输入
不同的子集(类);任意值(代表值);
输出
达到同样的效果输出
证实(达到需求规格里的功能要求)
证伪(发现更多的错误)
等价类有哪些类组成
等价类=有效等价类+无效等价类
有效类:针对需求,满足需求规格,合法
无效类:针对需求:不满足需求规格,不合法
测试用例:数据包含:有效数据,无效数据
软件:针对有效数据,做相应的处理;13;针对无效的数据,做相应的处理
无效值钱:用例当中更多地是针对无效类的用例
如何划分等价类?与集合的关系?
有效类
无效类:尽可能的无交集
所有类并集:满足符合最开始的需求
冗余
如何做
找:输入条件(输出条件)
针对输入条件,划分等价类,给等价类不同的编号(独立)
逻辑测试用例
物理测试用例
1:N,针对有效等价类设计测试用例,尽可能的覆盖多个有效类,13;直到所有的有效类覆盖完成
1:1,针对无效类,设计一条设计用例,只覆盖一个无效类,13;知道所有的无效类覆盖完成
测试数据构造
测试
主力
开发
协助
DBA
测试环境
开发环境
测试环境
用户环境(生产环境)
特性
干净
必须
无毒
软件&工具
独立
一般指的是数据库
开发用自己的
测试用自己的
冲突
稳定性
边界值
测试数据
特殊值
如:6-18位字符,可以使字母,数字下划线,必须以字母开头
优先测上点和离点,如果说时间允许可以测内点,时间不允许,可以不用测内点
需要关心三个点
上点
离点
内点
上点和离点不可能同时有效
分支主题
分类法
多条件(数据)组合
判定表
因果图
解决输入输出的关系,
输入与输入,输出与输出之间的约束
正交实验
全单值
基本组合
两两组合(pair-wise)
全对偶
组合技术
认识
多条件
每1个条件都会有多种输入
输出:每一个条件的每一种输入,尽可能的全部组合,就是全覆盖;在逻辑处理上达到全覆盖,
不同的输入组合系统可能会产生不同的处理结果
全单值(单一组合)
多条件:每个条件有多种或1种取值
只需要满足:每个条件的取值,只要取到1次即可,(直到所有的取值完成)
优点:简单明了
缺点:可能会遗漏某些特定的组合
解决方案:补充相关的业务,相关的组合用例
基本组合(一般组合)
相当于以你选择的一条用例为基础,保持一个条件不变,去取另一个条件的值
以选择的1条用例为基本,修改任意的取值,直到所有的取值完成(做加法)
特点:与选择的基本组合有关
判定表
定义
最严格 、最具逻辑性: 13;把复杂的逻辑关系和多条件组合情况 ,13;表达的比较明确
实质: 把输入中所有可能的情况进行组合,13;并汇总所对应的操作结果。 13;各种组合类型的全值组合。
需求
手机是否通讯
是否欠费
是否停机
是否通讯
酒店住宿系统13;支持:提前预订 和 会员卡办理 ;13;如果房间提前预订,并且已支付定金;13;或 持有酒店会员卡;13;可以优先办理酒店房间入住
下一天函数:要求输入年月日,13;系统显示当前输入的下一天
解答
列出:所有的条件桩 和 动作桩(条件项,动作项)
计算规则的个数
填充 条件项 和 动作项 到判定表
合并\化简规则(业务处理来的)
合并规则
两条或两条以上规则有相同的操作,13;且条件项之间存在较为类似的关系,13;需要进行规则的合并,用—代替
不推荐合并:在数据逻辑上是可以的,13;在业务逻辑上不确定。
优缺点
优点:
充分考虑输入条件间的组合,13;对组合情况,覆盖充分;13;把复杂的问题按各种可能的情况一一列举出来,13;进行全部罗列13;简明易于理解
每个用例覆盖多种输入情况,13;有利于提高测试效率
对输入条件间的约束关系做了考虑,13;避免了无效用例
缺点
输入较多时,判定表规模非常大
合并有可能存在着漏测的风险
是一个全值组合;会产生冗余用例
不能表达重复执行的动作
适用范围
输入输出比较多,13;输入之间和输出之间相互制约的条件比较多的情况 。
正交试验
在大量的试验数据中,挑选部分的,有代表性的点来组合覆盖 ,以达到试验目的
用例集数量不太多,达到效果是一样的
缺点:如果系统找不到相应的正交表,可能没办法借用这个方法
正交表
行数:表示用例个数
列数:表头的列表示条件数(因子)
每列的数据:每个条件的取值(水平)
L9(3^4)四个条件,三个取值;表示9=4*(3-1)+1,表示三水平四因子
所有条件的取值分布是均匀的,对于很多重要的没有覆盖到的,还是应该补充
任意两个条件的配对组合分布也是均匀的
写出了全真的测试用例,不要忘了去补充全假的测试用例,13;写出了全假的测试用例,不要忘了去补充全真的测试用例
pair-wise
全对偶
状态转换(迁移)
N-switch覆盖:
N从0开始取值
0-switch
1-switch
去覆盖被测对象的各种状态的N+1次 连续状态转换序列
用这个方法,需要明确:1被测对象有哪些状态(状态有一个起止节点(状态));13;有限的状态之内,避免陷入循环
2:任意的起始状态,它所需要转换的事件,以事件驱动
3:状态间通过事件触发转换后的下一个状态(输出)
怎么做(HOW)
根据需求,列出状态以及事件,起止点;(确定被测对象以及其所有的事件)
划出:状态转换图
以图转表(列出测试条件)13;确定N-switch覆盖度
根据测试条件,设计用例13;(不同的人可能会设计不同条数的用例,根据实际情况选取)
流程分析(场景分析)
用户场景的三个要素
用户场景一定是真是存在的
场景涉及到不同的人,角色相关
涉及到先后顺序,与结果的不同
测试重点
业务流程
至于:流程中间单个功能是否正确,不太关心(先测功能,再测流程)
怎么做(how)
确定用户场景
主要场景(成功的场景)
(基本流)
所有的输入都是正确的,完成相应的业务,输出正确的结果
扩展场景(失败的或者是特殊的场景)
备选流
输入的错误操作或是其他情况,能够完成相应的业务,输入正确
异常流
输入的错误操作,不能完成相应的业务
流程图
建议:图文分开、以备注的方式
根据流程图设计测试用例,覆盖流程、路径
所有的基本流,构成1条测试用例
1个基本流+1个备选流,构成1条测试用例
直到所有的场景覆盖完
识别测试路径
因果图
因果图
定义
由图转表
从需求中找出因(输入条件)和13;果(输出或程序状态的变化),13;通过分析输入条件之间的关系(组合、约束),13;以及输入和输出之间的关系,绘制出因果图,13;通过因果图转化成判定表的方法
需求
如果输入的第一个字符必须是#或*,13;第二个字符必须是1个数字,则进行文件修改;13;如果输入的第一个字符不是#或*,则提示为N;13;如果第二个字符不是数字,则提示为M;
有一个处理单价为:1.5元的饮料的自动售货机软件;13;若投入1.5元,按下可乐,雪碧,红牛按钮,13;相应的饮料会出来;13;若投入2元,则送出饮料的时候,退还5角钱;13;若投入不足1.5元,提示:金额不足,请继续投币;13;若饮料不够,退还金额;13;若没有零钱,退还金额,不送出相应的饮料;
步骤
找出原因和结果,并给出标识符
找出原因与原因之间的关系,13;原因与结果之间的关系,生成因果图
由图转换成表
生在用例
符号和关系
E: <=1; 最多1个1,可以全为0; 13; 或:I:>=1; 至少有1 个1;13; O:有且只能为1;13; R:要求:a要求b;如果a为1,则b必须为1;13; 即:b为a的前导条件; a要成功,b必须成功; 13;M: 两个结果不能同时发生;13; a要为1,则b必须为0;
输入 和 输出
CI 和 EI
输入 和输入
组合
约束
和判定表关系
无本质差别
复杂
简单
适用范围
输入条件过多,存在着一定关系(因果)
0 条评论
下一页