用例设计
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;并汇总所对应的操作结果。 \t13;各种组合类型的全值组合。
定义
是否欠费
是否停机
是否通讯
手机是否通讯
酒店住宿系统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
正交试验
1：尽可能达到：条件的取值分布个数是均匀的13;2：尽可能达到：任意两个条件（取值）之间的配对 （有序对）分布也是均匀的==各条件之间取值，至少出现一次‘
组合技术
N从0开始取值
0-switch
1-switch
去覆盖被测对象的各种状态的N+1次 连续状态转换序列
用这个方法，需要明确：1被测对象有哪些状态（状态有一个起止节点（状态））；13;有限的状态之内，避免陷入循环
2：任意的起始状态，它所需要转换的事件，以事件驱动
3：状态间通过事件触发转换后的下一个状态（输出）
N-switch覆盖：
根据需求，列出状态以及事件，起止点；（确定被测对象以及其所有的事件）
划出：状态转换图
以图转表（列出测试条件）13;确定N-switch覆盖度
根据测试条件，设计用例13;（不同的人可能会设计不同条数的用例，根据实际情况选取）
怎么做（HOW）
状态转换（迁移）
用户场景一定是真是存在的
场景涉及到不同的人，角色相关
涉及到先后顺序，与结果的不同
用户场景的三个要素
业务流程
至于：流程中间单个功能是否正确，不太关心（先测功能，再测流程）
测试重点
（基本流）
所有的输入都是正确的，完成相应的业务，输出正确的结果
主要场景（成功的场景）
输入的错误操作或是其他情况，能够完成相应的业务，输入正确
备选流
输入的错误操作，不能完成相应的业务
异常流
扩展场景（失败的或者是特殊的场景）
确定用户场景
建议：图文分开、以备注的方式
流程图
所有的基本流，构成1条测试用例
1个基本流+1个备选流，构成1条测试用例
直到所有的场景覆盖完
识别测试路径
根据流程图设计测试用例，覆盖流程、路径
怎么做（how）
流程分析（场景分析）
由图转表
从需求中找出因（输入条件）和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;原因与结果之间的关系，生成因果图
由图转换成表
生在用例
步骤
\tE： <=1; 最多1个1，可以全为0； 13; 或：I：>=1; 至少有1 个1；13; O：有且只能为1；13; R：要求：ａ要求ｂ；如果ａ为１，则ｂ必须为１；13; 即：ｂ为ａ的前导条件； ａ要成功，ｂ必须成功； 13;Ｍ： 两个结果不能同时发生；13; ａ要为１，则ｂ必须为０；
CI 和 EI
输入 和 输出
组合
约束
输入 和输入
符号和关系
无本质差别
复杂
简单
和判定表关系
输入条件过多，存在着一定关系（因果）
方法
用例设计
0 条评论
回复 删除
下一页
