软件测试与验证

date
Sep 9, 2024
slug
test
status
Published
tags
ECNU
summary
type
Post

Effective and Systematic Software Testing

揭示缺陷实现缺陷预防是软件测试的最终目标。 达到期望的覆盖度要求是软件测试的主要目标之一
软件包括文档、数据、程序，这些都可以使用静态测试方法

Key Definitions

  • Software Defect (软件缺陷)
    • 存在于软件 (文档、数据、程序) 之中的那些不希望或不可接受的偏差
    • Bug是口语化的缺陷
    • 软件中一定存在缺陷
    • 有缺陷并不一定产生故障
    • 静态的，It‘s just there
  • Software Fault (软件故障)
    • 软件运行过程中出现的一种不希望或不可接受的内部状态
    • 内部状态：由所有程序变量的当前值和程序指针构成的集合
    • 故障是缺陷激活的结果
    • 如果缺陷被激活，软件内部就可能会出现故障
    • 软件故障如果没有适当的处理措施的话，很可能会导致软件失效
    • 有故障也并不一定会失效
    • 产生故障一定意味着软件存在缺陷
    • 动态的，跑了才知道
notion image
  • Software Failure (软件失效)
    • 软件运行时产生的一种不希望或不可接受的外部行为结果 (系统崩溃，闪退，结果不正确……)
    • 产生失效一定意味着软件有故障
      • ① 外部可见的软件失效是测试中推断软件中存在缺陷的基本方法
      ② 没有失效并不代表软件中不存在缺陷
  • Software Error (软件错误)
    • 在软件生存期内的不希望或者不可接受的人为错误
    • 软件缺陷本质上是研发人员在软件研发过程中所犯错误在软件中的可视化结果
    • 比如开发人员对需求理解不到位，或者是程序语言对这个知识理解不到位，技术不到位。可视化就是落点在软件当中，它就变成了一个缺陷。比如说如果我们的程序员没有理解到内存泄露这个问题，那么他在写程序的时候可能就会出现了长周期对象引这个引用短周期对象这样的一个缺陷。
人有问题（软件错误）→人写的有问题（软件缺陷）→ 可能产生软件故障（内部状态与正确的不一致，infected）→ 可能产生软件失效propagated

Test Case

四个组成部分：Prefix Values、Test Case Values、Expected Values和Postfix Values
Test Case Values : 测试输入 Expected Results : 预期输出 Prefix Values : 测试前给软件的输入，让软件转移到可以接受测试输入的状态 Postfix Values : 测试后需要给软件的输入，有两种 a) Verification Values : 为了查看测试结果必须的输入，比如点击xxx b) Exit Commands : 让软件退出或者转移到一个稳定状态
notion image

RIP model

  • Reachability：包含缺陷的程序代码可达
  • Infection：执行缺陷代码之后，程序状态错误（正确代码和缺陷代码下运行的内部状态不一样）
  • Propagation：Infected State让程序的输出是错误的
notion image
notion image
路径上的数据可能有不同的排列组合。比如if i>10这条路径，可能需要测试8、10、15等不同数据

软件测试挑战

充分性问题

由于无法穷举被测软件完整的输入空间，各种软件动态测试方法本质上都是围绕 “如何构造测试集合以使其展现的部分行为能够高效有效地反映软件的整体行为”而展开。判断测试集合在软件上的表现是否能够充分反映该软件的总体表现，在测试领域中叫充分性问题。
notion image
语句覆盖、分支覆盖是最低要求，都满足并不能说明代码没问题

先验问题 (测试预言)

用于判断测试用例在软件上的表现是否正确（符合期望）的标准，在测试领域中叫先验规则（测试断言）。先验规则并不总是直观存在，如何获得完备的先验规则就是先验问题。
  • Differential Testing (差分测试) 通过比较两个或多个系统在相同输入下的输出，来发现它们之间的差异。如果这些系统在相同输入下产生不同的输出，那么就可能存在错误或不一致性。例如, 对编译器的测试
  • Metamorphic Testing (蜕变测试) 利用种子测试输入与其对应的变异的测试输入，两者在测试输出上所满足的特定关系（称为蜕变关系）来检测软件缺陷。例如，即使不知道sin 7 = ？也可以利用sin (x + 2𝜋) = sin x ，检测sine算法的实现是否存在缺陷
  • Property-based Testing (基于属性的测试) 通过定义和验证程序的属性（Properties）, 使用随机或基于某种策略生成的测试用例验证程序是否满足定义的属性, 如果测试过程中某个测试用例违反了属性，那么就发现了程序中的潜在缺陷。例如, Listing1.6
Verification（代码设计要求） is not validation（用户需求）

Testing Process

notion image
notion image

Specification-based Test Modeling

notion image
To identify parameters (被测因素) that should be considered during testing • Inputs • Outputs • Relationships between inputs and outputs • Domain rules: class state ( e.g.§2.4.12)
Inputs
notion image
Outputs
被测代码的返回值 被测代码的输出参数（C/C++） 被测代码内部改写的成员变量和全局变量 被测代码进行的文件更新、数据库更新、消息队列更新

Partition Testing

  • 等价划分是一种经典的分而治之的测试设计方法
  • 对分析得到的每个被测因素的输入域以预期结果相同为等价划分原则， 划分为不同的等价类集合，划分需满足
      1. 划分覆盖整个待测试域（domain）
      1. 各个划分部分之间没有交集（理想情况）
      1. 以被测因素的约束为标准，划分需包括 a) 有效等价类：符合约束的等价类 b) 无效等价类：不符合约束的所有其它可能存在的情况
等价划分启发式规则
  • 如果某个输入条件规定值的范围，可以确定一个有效等价类和两个无效等价类
  • 如果输入条件规定了一个输入值的集合，可以确定一个有效等价类和一个无效等价类
  • 如果输入条件是一个布尔表达式的条件，可以确定一个有效等价类和一个无效等价类
  • 如果输入条件定义了一个“必须”的情况，比如”标识的第一字符必须是字母”那么可以确定一个有效等价类和一个无效等价类。
  • 如果有理由确信，某一等价类中的各元素在程序中的处理有区别，那就把这个等价类分成更小的等价类

Boundary Testing

边界值
任何值得测试的范围的临界点，通常指等价类的边界，可分为
  1. 边界值：明确地定义在规格说明书中
  1. 次边界：隐含在软件中必须经过分析才能获得
  1. 仅物理量适用，逻辑变量慎重
测试设计思想 取边界点附近的值作为测试用例的输入，可参考如下的设计原则 如果输入条件定义了数值区间(a,b)，那么测试用例应包括a、b、稍微比a 大、稍微比b大、稍微比a小和稍微比b小等几种情况. 举个例子，如果a,b 是整数, 除在a,b之间取正常点外，a,b,a-1,b-1,a+1,b+1都应被测试

Combination Strategies

  1. All Combination Coverage(ACoC): 全组合值覆盖
  1. Each Choice Coverage(ECC)：单值覆盖
  1. Pair-Wise Coverage(PWC)：全对偶值覆盖
  1. T-Wise Coverage(TWC): 全T值覆盖
  1. Base Choice Coverage(BCC): 基本值覆盖
  1. Multiple Base Choices Coverage(MBCC):多基本值覆盖
实际使用5和6
假设第个Parameter的划分数为，表示Parameter的数量

全组合值覆盖

单值覆盖

全对偶值覆盖

notion image

全T值覆盖

假设T=3

基本值覆盖

每个特征一个基本值
一次针对一个被测特征，用其非基本值替代基本值，其余被测特征仍取基本值

多基本值覆盖

每个特征标注了多个基本值，使用多基本值组合
假设第个Parameter有个基本值
 
If you have any questions, please contact me.