【软件测试】测试用例设计要点总结


考试题型

  • 简答题 (共 4 题,每题 5 分,共 20 分)
  • 等价类划分 (16 分)
  • 边界值分析 (13 分)
  • 判定表驱动 (22 分)
  • 逻辑覆盖 (12 分)
  • 基本路径测试 (17 分)
  • 注意事项:
    • 尽快检查在线测试是否存在误判情况
    • 核对实验成绩及扣分情况
    • 注意答题顺序 (建议按难易程度+分值)
    • 不可使用铅笔绘图 (因果图和程序控制流程图)
    • 测试用例中每个输入条件都必须有具体确定的数值
    • 表头中标注编号的部分只给出编号除了逻辑覆盖法的条件覆盖以外,其他测试至多有一种无效情况存在(null也所做一种)

简答题

【 互操作性(交互)和共存性(影响)之间的区别和联系 】软件质量分析

  • 互操作性:与一个或多个规定系统交互的能力;共存性:公共环境中和其他独立软件共存的能力

  • 共同点:

    • 都关注系统或组件如何与其他系统或组件交互。
    • 都需要针对性测试。
    • 都与系统或组件的兼容性密切相关。
  • 区别:

    • 互操作性侧重于不同系统或组件之间的信息交换和利用,强调的是软件在不同环境下能否顺利与其他系统协作。
    • 共存性侧重于系统能否和其他系统同时存在并正常运行,主要看新引入的软件是否会影响到已存在系统的正常运行,或者已存在的系统是否会影响新引入软件的正常运行。
  • 软件质量模型:McCall 模型 (1979年)、ISO/IEC 9126-1991 模型、新的ISO/IEC 9126 模型、ISO/IEC 25010-2011 模型
    在这里插入图片描述

【 手工测试与自动化测试 】软件测试的分类

  • 软件测试的分类
    • 测试执行方式:静态测试、动态测试
    • 测试对象:黑盒测试、白盒测试
    • 测试过程:单元测试、集成测试、系统测试、验收测试
    • 测试目的:功能测试、健壮性测试、性能测试、安全性测试、兼容性测试、易用性测试
    • 测试执行手段:手工测试、自动化测试
      在这里插入图片描述
  • 手工测试与自动化测试
    • 手工测试:
      • 优点:①执行测试成本较低;②人工对比更具智能化
      • 缺点:①执行效率低、精确度无法保证;②不可复用
    • 自动化测试:
      • 优点:①执行测试快速、可靠;②支持反复测试、可程序化;③支持人工无法胜任的测试类型,如性能测试、安全性测试等
      • 缺点:①商业软件普遍成本偏高,不适用于中小型企业;②精确度依照测试脚本的指令执行,不够灵活、智能
        在这里插入图片描述

【 因果图分析法确定中间结果的一般原则 】因果分析法设计要点

  • 为了实现问题简化,原因只描述输入条件的有效等价类;原因和结果尽可能描述为逻辑值形式
  • 为了确保测试的充分性,复合输入条件需拆分为简单条件
  • 分析思路:从结果入手,分析结果与原因间存在的关系
  • 结果分析顺序:
    • 若结果间不存在递进关系,则一般从最简单的开始分析
    • 若结果间存在递进关系,则必须按顺序进行分析
  • 中间结果的确定:
    • 原本拆分的输入条件,需通过中间结果合并描述其逻辑关系
    • 多个输入条件间存在紧密依赖关系,考虑增加中间结果
    • 一个结果与多个原因间存在关系,不是纯粹的与/或关系,需要增加中间结果
    • 某输出以某输入作为前提条件,为了后续分析的顺利进行,必须增加中间结果
  • 原因间约束的确定:
    • 需从最终用户角度出发,考虑对用户输入的限制
    • 重点关注互斥、包含和唯一关系
      在这里插入图片描述

【 逻辑覆盖法与基本路径测试法 】

  • 逻辑覆盖法
    • 优点:①依据真值表,节省测试工作工时;②六种覆盖准则,可适用于不同的应用场景
    • 缺点:①六种覆盖准则较为相似,易混淆 ;②无法兼顾效率及有效性;③未实现循环等复杂情况的真正简化
  • 基本路径测试法
    • 优点:①测试数据基于单缺陷假设,提高了测试有效性;②将循环等复杂情况简化为与嵌套型分支结构相似的复杂度,提高了测试效率
    • 缺点:①依据程序控制流程图和独立路径分析设计测试用例,设计过程较为复杂
      在这里插入图片描述

【 单元测试的任务及采用方法 】单元测试的目标和方法

  • 目标:单元模块被正确编码
  • 任务:
    • 模块接口:检查模块单元数据输入和输出是否正确
    • 局部数据结构:检查模块内部内部数据的完整性和正确性【代码检查法、静态结构分析法】
    • 错误处理:模块中发生错误,系统的出错处理是否有效【错误推测法】
    • 边界条件:采用边界值分析方法,发现在边界发生的错误【边界分析法】
    • 独立执行路径:测试独立路径,发现计算、判定和控制流错误【基本路径检测法、逻辑覆盖法】在这里插入图片描述

(一) 等价类划分

1.1 划分等价类

  • 等价类设计允许适度冗余;
  • 输入条件包含复合情况需拆分;
  • 用于验证系统功能正确性的有效等价类允许合并;
  • 分析等价类时需注意隐含条件;
  • 有效等价类和无效等价类需分别顺序编号;
  • 输出域不为海量数据时,无需分析等价类;
  • 输入条件间存在依赖关系时只需在测试用例设计过程中有所体现,等价类设计时作为独 立条件分析。

等价类的划分原则

  • 按区间划分:1个有效等价类,2个无效等价类【单个值(可加可减)、日期】
  • 按数值划分:1个有效等价类,n个无效等价类【对每个值分别进行处理】
  • 按输入集合划分:1个有效等价类,1个无效【不对每个值分别进行处理(集合)】
  • 按限制条件划分:1个有效等价类,1个无效等价类【逻辑值:要求必须填写(填写/不填写)】
  • 按限制规则划分:1个有效等价类,若干个无效等价类(最低限制)【≈按限制条件划分】
  • 有效等价类:照搬题目需求
  • 无效等价类要求:
    • 拆分到底
    • 允许适度冗余(不早于当前请假日期 => 早于当前请假日期 + 等于当前请假日期)

1.2 设计测试用例

  • 预期输出需与题目规则要求完全一致;
  • 一个测试用例最多只能覆盖一个无效等价类;
  • 对于验证健壮性的测试用例,覆盖等价类编号只需突出无效等价类即可;
  • 测试用例设计需同时兼顾输入和输出等价类的覆盖。
  • 有效等价类:尽可能多的覆盖尚未覆盖的有效等价类(尽可能少的测试用例来覆盖 => 1个)
  • 无效等价类:仅覆盖一个无效等价类

(二) 边界值分析

2.1 列出边界值分析表

  • 只需为与数值区间范围时间有关的等价类分析边界值;
  • 七点法代表一种选值的思想,不需要硬凑七个数据,需具体问题具体分析;
  • 若为无界区间[a,+∞] ,则右边界选择一个足够大的数代替无穷大即可;需选择固定取值作为测试用例的正常值。

七点法:略低于最小值、最小值、略高于最小值、正常值、略低于最大值、最大值、略高于最大值
边界值的处理(依赖关系):Eg:结束日期=>开始日期,以开始日期的正常值作为条件(最小边界值)
正常值加下划线

2.2 设计测试用例

  • 所有测试用例的数据均应取自边界值分析表;
  • 一个测试用例最多只能覆盖一个边界值,其余均取正常值;
  • 与数值无关的等价类在测试用例设计过程中随意选取合法有效输入即可。

(三) 因果图分析

3.1 确定原因和结果

  • 原因:输入条件的有效等价类(一般规则)【照搬需求( 等价类划分的有效等价类)】
  • 结果:预期输出
  • 注意事项:
    • 原因和结果均以逻辑值形式给出;
    • 建议以有效等价类形式描述原因;
    • 为了确保测试的充分性,复合条件需拆分为简单条件 (关系表达式);
      • 与、或是否拆分
      • 相反条件进行测试
      • 基本路径测试法的流程图核对:原因+结果(白盒测试)
    • 原因和结果的编号及描述需做到规范准确。

3.2 确定原因和结果之间的逻辑关系

  • 不可使用铅笔绘制因果图;
  • 分析问题的一般方式为:从结果入手,分析结果和原因间存在怎样的关系;
  • 如果结果间存在递进关系或者嵌套关系,则必须按输入顺序进行分析;
  • 中间结果的确定:多个输入条件间存在更为紧密的关系;
  • 某输出以某输入作为前提条件 (注意需求中的描述) ,为了后续分析的顺利进行,必须 增加中间结果。

3.3 在因果图上使用标准的符号标明约束条件

  • 原因间约束的确定:需从最终用户角度出发,考虑对用户输入的限制。
  • E(互斥)、I(包含)、O(唯一)、R(要求)、M(屏蔽)
    在这里插入图片描述

(四) 判定表驱动

4.1 将因果图转换为判定表

  • 对于不合理规则,根据题目要求确定是否列出;
  • 中间结果无需列出,条件桩动作桩只需列出原因结果的编号即可;
  • 为了减少规则及测试用例数量,应尽可能进行合并化简;
  • 避免重复合并及遗漏合并现象发生,建议按输入条件的顺序进行合并。
  • 判定表驱动法考虑排列组合问题。
  • 合并化简注意事项:
    • 对于输入条件过多的情况,可以一开始就考虑合并化简;
    • 合并化简的前提为动作项相同;
    • 必须通过“-”表示条件无关或者条件不适用。
  • 列出所有条件桩动作桩
  • 确定规则总数
  • 填入条件项动作项
  • 对相似规则进行合并化简
  • 与关系:按顺序操作
  • 或关系:互斥关系,笛卡尔乘积(测试用例)

4.2 设计测试用例

  • 测试用例中每个输入条件都必须有具体确定的数值,不可用“-”或“取值无关”表示;
  • 测试用例若为空,则任何信息均不填写,不可用“为空”或“NULL”表示。

(五) 逻辑覆盖

  • 基本设计思路:
    • 按照“分类设计**,严卡概念**”的基本思想开展测试设计任务;(不同覆盖概念)
      • 判定覆盖:先给出语句覆盖,缺哪个补哪个(一般情况:判定覆盖 = 语句覆盖)
      • 条件覆盖:尽可能少的测试用例(尽可能同真同假)
      • 判定条件覆盖
    • 合理利用真值表,先确定判断或条件的取值,然后选择测试数据;
    • 先设计覆盖率低的测试用例,然后对照覆盖率高的要求,查缺补漏;
    • 避免出现冗余或遗漏。
      在这里插入图片描述
  • 注意事项:
    • 真值表中必须通过“-”表示条件不适用;
    • 逻辑覆盖分析中只考虑判定间的嵌套关系,不考虑条件间的逻辑关系;
    • 对于真值表中验证不到的输入条件,测试用例中必须给出具体且有效的数据;
    • 覆盖路径只需给出编号即可。

(六) 基本路径测试

6.1 画出程序控制流程图

  • 复合条件下判定结点必须拆分为简单条件 (关系表达式);
  • 适当合并处理结点;
  • 根据情况适当增加汇合点 (分支结构结束、程序出口等)。
  • 绘图结束后,确认以下内容:
    • 需保证每个条件结点出度等于 2;
    • 图的绘制保证单入口单出口;
    • 避免出现交叉线导致区域无法准确识别;
    • 在图中需标出区域,注意 1 个开放区域;
    • 汇合点必须给出编号。

6.2 计算程序环路复杂性

  • 三个公式必须给出完整计算过程和结果。
    • V(G) = 区域数
    • V(G) = E - N + 2
    • V(G) = P + 1
  • 由于程序流程图中已标出条件结点的序号,则公式 P+1 可用于检验其他公式结果是否一致, 以及绘图是否正确。

6.3 确定独立路径集合

  • 独立路径数≤环路复杂性:若程序控制流程图中存在局部连锁结构(存在或关系,且不在最后◇),则独立路径数<环路复杂性;
  • 基本路径覆盖需保证程序控制流程图中所有结点和控制流线(弧)的覆盖;
  • 独立路径列举过程中避免出现冗余或遗漏;
  • 独立路径需排除不合理情况。
  • 同一入口,同一出口

6.4 设计测试用例

  • 测试用例中每个输入条件都必须有具体确定的数值,即使覆盖的独立路径未验证到某个 输入条件;
  • 覆盖独立路径只需给出编号即可。

猜你喜欢

转载自blog.csdn.net/Lenhart001/article/details/131196780