Skip to content

Latest commit

 

History

History
306 lines (202 loc) · 11.8 KB

7测试技术.md

File metadata and controls

306 lines (202 loc) · 11.8 KB

测试技术

测试基本概念

软件测试含义

  • 在特定的条件下,系统或组件进行观察或记录结果,某些方面进行评估的过程
  • 分析软件缺陷(项目现有结果和应有结果之间的差异},并评估软件各项目特征的过程

软件缺陷

至少满足下列一个条件,称发生了一个软件缺陷

  • 未完成:软件未实现产品说明书要求的功能
  • 有错误:软件出现了产品说明书指明不能出现的错误
  • 画蛇添足:软件实现了产品说明书未提到的功能
  • 隐含需求未实现:软件未实现产品说明书虽未明确提及但应该实现的目标
  • 不好用:软件难以理解、不易使用、运行缓慢

特征

  • 看不到:缺陷不容易被看到
  • 看到但抓不到:发现了缺陷,但不易找到引发问题的原因

测试与质量保证

  • 软件测试人员的目标
    • 尽早找出软件缺陷,并确保缺陷得以修复
  • 软件质量保证人员的主要职责
    • 创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法

质量与可靠性

  • 功能性(functionality)
  • 可靠性(reliability)
  • 可用性(usability)
  • 效率(efficiency)
  • 可维护性(maintainability)
  • 可移植性(portability)

可靠性与质量区别:可靠性只是质量的一个方面,甚至不一定是最决定性的一个方面

软件调试与测试

  • 相同点:
    • 都包含有处理软件缺陷和查看代码的过程
  • 不同点:
    • 测试的目标是发现软件缺陷的存在
    • 调试的目标是定位与修复缺陷

测试用例

测试用例(test case):测试输入、执行条件,以及预期结果的集合,是为特定的目的开发的,例如执行特定的程序路径或验证与指定的需求相符合

软件测试目标

  • 确认系统满足其预期的使用和用户的需要
  • 确认解决了所需解决的问题(如实现商业规则和使用合适的系统假定)
  • 为测试的过程建立责任和可解释性
  • 便于及早发现软件和系统的异常
  • 及早提供软件和系统的性能评估
  • 为管理提供真实信息,以决定在当前状态下发布产品在商业上的风险
  • 鉴别出程序在功能等方面的异常集聚之处

软件测试基本原则

  • 穷尽测试是不可能的:决定哪些更重要
  • 测试无法显示潜在的软件缺陷:不能保证没有错误
  • 测试活动应尽早进行:越早发现修改成本越低
  • 软件缺陷具有群聚性:一个问题出错导致多个错误现象出现
  • 注意杀虫剂现象:用一样的测试用例是不可取的
  • 应尽量由独立的测试团队进行测试:自己测试自己是不可取的

测试的主要方法:star2:

黑盒测试(功能性测试):忽略系统或组件的内部机制,仅关注于那些特定输入响应及相应执行条件的输出测试

白盒测试(结构性测试):考虑系统或组件内部机制的测试(如分支测试、路径测试、语句测试等)

灰盒测试:黑盒和白盒测试混合方法

评估准则

  • 覆盖率
    • 覆盖率=测试集合T/测试需求集合TR
  • 故障插入
    • 在测试前被有意地插入一些故障到程序中
    • 发现率=发现的播入错误数/播入的总错误数
  • 变异分值
    • 程序进行两个或更多个变异,然后用同样的测试用例执行测试,可以评估这些测试用例探测程序变异间差异的能力,如错误的标识符或运算符等

白盒测试方法

把测试对象看做一个透明的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试

通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试

软件人员使用白盒测试方法,主要想对程序模块进行如下的检查:

  • 对程序模块的所有独立的执行路径至少测试一次
  • 对所有的逻辑判定,取“真”与取“假”的两种情况都至少测试一次
  • 在循环的边界和运行界限内执行循环体
  • 测试内部数据结构的有效性等

逻辑覆盖测试

逻辑覆盖:程序内部的逻辑结构为基础的设计测试用例的技术。属于白盒测试

  • 语句覆盖:语句覆盖就是设计若干个测试用例,运行被测程序,使得每一可执行语句至少执行一次
  • 分支覆盖:
    • 分支覆盖就是设计若干个测试用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次
    • 分支覆盖又称为判定覆盖
  • 条件覆盖:条件覆盖就是设计若干个测试用例,运行被测程序,使得程序中每个判断的每个条件的可能取值至少执行一次
  • 条件组合覆盖:条件组合覆盖就是设计足够的测试用例,运行被测程序,使得每个判断的所有可能的条件取值组合至少执行一次

控制流图覆盖测试

含义:将代码转变为控制流图,基于其进行测试的技术。它属于白盒测试

注意

  • 在选择或多分支结构中,分支的汇聚处应有一个汇聚结点
  • 边和结点圈定的区域叫做区域,当对区域计数时,图形外的区域也应记为一个区域
  • 如果判断中的条件表达式是由一个或多个逻辑运算符 (OR, AND, NAND, NOR) 连接的复合条件表达式,则需要改为一系列只有单个条件的嵌套的判断

节点覆盖

节点覆盖和语句覆盖是等价的

边覆盖

边覆盖包含节点覆盖,且边覆盖也可以实现分支覆盖

路径覆盖

路径覆盖测试就是设计足够的测试用例,覆盖程序中所有可能的路径

基本路径测试

基本路径测试方法把覆盖的路径数压缩到一定限度内,程序中的循环体最多只执行一次

它是在程序控制流图的基础上,分析控制构造的环路复杂性,导出基本可执行路径集合,设计测试用例的方法。设计出的测试用例要保证在测试中,程序的每一个可执行语句至少要执行一次

程序环路复杂性

程序的环路复杂性给出了程序基本路径集中的独立路径条数,这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界

从控制流图来看,一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径

计算公式 $$ V(G)=e-n+2\e为图中边的数目,n为节点数目 $$ 确定线性独立路径的基本集合

  • 从源节点(控制流图的入口点)开始,一直走到汇节点(控制流图的出口点)。该路径作为基线路径。
  • 接下来,重新回溯基线路径,依次“翻转”在判断节点上原来选择的路径。即当遇到节点的出度大于等于2 时,必须选择不同的边。
  • 重复以上过程,直到得到的路径数目等于V(G)

导出测试用例

导出测试用例,确保基本路径集中的每一条路径的执行

根据判断结点给出的条件,选择适当的数据以保证某一条路径可以被测试到 — 用逻辑覆盖方法

每个测试用例执行之后,与预期结果进行比较。如果所有测试用例都执行完毕,则可以确信程序中所有的可执行语句至少被执行了一次

必须注意,一些独立的路径(如例中的路径1),往往不是完全孤立的,有时它是程序正常的控制流的一部分,这时,这些路径的测试可以是另一条路径测试的一部分

黑盒测试

含义

测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明

又名功能测试或数据驱动测试

目的

  • 是否有不正确或遗漏了的功能?
  • 在接口上,输入能否正确地接受? 能否输出正确的结果?
  • 是否有数据结构错误或外部信息(例如数据文件)访问错误?
  • 性能上是否能够满足要求?
  • 是否有初始化或终止性错误?

不可能所有可能的输入条件和输出条件中确定测试数据

  • 等价类划分
  • 边界值分析
  • 状态测试

等价类划分

含义

等价类划分方法把所有可能的输入数据,即程序的输入域划分成若干部分,然后从每一部分中选取少数有代表性的数据做为测试用例

步骤

  • 对输入域进行建模
  • 对参数进行等价类划分
  • 对参数进行恰当的组合

等价类

含义

  • 指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试

两种划分

  • 有效等价类:是指对于程序的规格说明来说,是合理的,有意义的输入数据构成的集合
  • 无效等价类:是指对于程序的规格说明来说,是不合理的,无意义的输入数据构成的集合

边界值分析方法

原因

人们从长期的测试工作经验得知,大量的错误是发生在输入或输出范围的边界上,而不是在输入范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误

例子:大于号“>”错写成大于等于号“≥”

边界值:对输入等价类和输出等价类而言,稍高于其边界值及稍低于其边界值的一些特定情况

边界选取:应当选取正好等于,刚刚大于,或刚刚小于边界的值做为测试数据,而不是选取等价类中的典型值或任意值做为测试数据

状态测试

  • 必要性
    • 由于在黑盒测试阶段,程序内部的逻辑结构是无从得知的,因此只能通过对状态的测试间接地加以验证。
  • 含义
    • 一种基于模型的测试,是指用状态图来描述时间序列(别称为用例场景),由此产生测试用例。
  • 步骤
    • 建立状态转换图
    • 根据状态转换图设计测试用例

静态分析方法

不实际运行程序,通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术

作用

  • 通过对代码标准及质量的监控提高代码可靠性
  • 尽可能早地通过对源代码的检查发现缺陷
  • 组织代码审核定位易产生错误的模块

非常有效的质量保证手段

通用评审过程

评审过程就是执行静态分析的过程

  1. 计划
  2. 概述
  3. 准备
  4. 评审会议
  5. 返工
  6. 跟踪

静态分析主要内容

  • 检查需求
  • 检查设计
  • 检查代码

静态分析类型

  • 同事审查
    • 非正式的评审
    • 适用于初次审查
  • 走查
    • 开发组内部进行的
    • 由本模块的开发者进行讲解、回答问题并记录
  • 审查
    • 开发组、测试组和相关人员(QA、产品经理等)联合进行
    • 以会议的形式,制定目标、流程、规则和结果报告

静态分析有效

必须引入“别人”的眼睛

根据团队及项目的实际情况,设计合理的实施办法

有准备地进行:应该有包含所有关注要点的Checklist

把握会议时间

  • 每次以2小时为限
  • 可以进行多次

小结

  • 软件测试含义
    • 对系统或组件进行观察或记录结果,进行某些方面进行评估的过程
    • 分析软件缺陷:项目现有结果和应有结果之间的差异
  • 白盒测试和黑盒测试两大类
    • 白盒测试
      • 逻辑覆盖测试
        • 语句覆盖、分支覆盖、条件覆盖、条件组合覆盖
      • 控制流图覆盖测试
        • 节点覆盖、边覆盖、基本路径测试
    • 黑盒测试
      • 最常见的方法是等价类划分方法和边界值分析方法
      • 此外还需要针对软件进行状态测试
  • 静态分析要遵循一定的评审过程
    • 主要形式有同事审查、走查和审查