软件测试技术复习点

拜见老天師

已于 2024-01-06 21:00:22 修改

阅读量896

点赞数 20

分类专栏：课程学习相关文章标签：课程学习

于 2024-01-04 10:07:38 首次发布

本文链接：https://blog.csdn.net/m0_52078336/article/details/135379529

版权

课程学习相关专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1 术语含义（故障、错误、失效、测试用例）

故障（Fault）：故障是软件中的静态缺陷；

故障屏蔽：软件中的某个故障可能被其他一个或多个故障屏蔽；
错误（Error）：软件运行时的不正确状态，错误是故障的具体表现；
失效（Failure）：软件的表现不完全符合需求说明书，即实际结果或行为与期望结果或行为存在偏差；当故障执行时有可能会发生失效；
测试（Testing）
- 用于处理错误、故障和失效。
- 通过观察其执行来评估软件。
调试（Debugging）
- 对于给定的失效找出故障的过程。
测试用例（Test case）
- 输入：测试数据和操作步骤
- 输出：预期结果

2 V&V模型、RIPR模型、MDTD

2.1 验证和确认模型（V&V）

为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。

验证(Verification)，在软件开发过程的某个阶段，决定此时的产品是否满足前一个阶段所确定需求的过程。
（Are you building the product right?是否正确地构造软件？）
确认(Validation)，在软件开发结尾时，评估软件以保证所开发的软件和预期用途相符的过程。
（ Are you building the right product?是否构造正确的软件？）

2.2 RIPR模型

Four conditions necessary for a failure to be observed：

Reachability : The location or locations in the program that contain the fault must be reached
Infection : The state of the program must be incorrect
Propagation : The infected state must cause some output or final state of the program to be incorrect
Reveal : The tester must observe part of the incorrect portion of the program state

观察失效的四个必要条件：

可达性：必须到达程序中包含故障的一个或多个位置
感染：程序状态肯定不正确
传播：被感染的状态必然导致程序的某些输出或最终状态不正确
揭示：测试人员必须观察程序状态的不正确部分

前者是后者的必要条件

2.3 MDTD（Model-Driven Test Design）模型驱动的测试设计

Testing can be broken up into four general types of activities

Test Design
a) Criteria-based：Design test values to satisfy coverage criteria or other engineering goal
b) Human-based：Design test values based on domain knowledge of the program and human knowledge of testing
Test Automation：Embed test values into executable scripts
Test Execution：Run tests on the software and record the results
Test Evaluation：Evaluate results of testing, report to developers

测试可以分为四种一般类型的活动

测试设计
- 基于标准：设计测试值以满足覆盖标准或其他工程目标
- 以人为本：根据程序的领域知识和人类测试知识设计测试值
测试自动化：将测试值嵌入到可执行脚本中
测试执行：对软件进行测试并记录结果
测试评估：评估测试结果，向开发人员报告

test specs（测试规格）
refined requirements （细化要求）
Model-Driven Test Design（模型驱动的测试设计）

3 软件测试原则

应该尽早地和不断地进行软件测试；
测试用例应由测试输入条件和与之对应的预期输出结果组成，测试之前应根据测试要求正确选取需要执行的测试用例
程序员应该避免检查/测试自己的程序；
在设计测试用例时，应该包括合理的输入条件和不合理的输入条件；
充分注意程序测试中的群集现象（测试后程序中残余的错误数目与该程序已发现的错误数目成正比）；
严格执行测试计划，排除测试的随意性；
应对每一个测试结果做全面检查；
妥善保存测试计划、测试用例、出错统计和最终分析结果，为维护提供方便；
所有的测试应该追溯到用户需求；
测试应该从“小规模”开始，逐步向“大规模”即渐增式build测试

4 软件测试过程模型（V、W、H、建议模型）

4.1 V 模型

两个特点：
- 展示了动态测试的全过程，并定义了动态测试与开发之间的关系。
- 动态测试的行为与开发过程的行为相对应，测试基础是对应开发阶段的文档。
三个缺点：
- 测试与开发文档之间很少有完美的一对一关系。
- 完全没有提及静态测试，忽略了代码审查、需求规格说明审查等重要的测试手段。
- 软件测试时间经常由于前期开发阶段进度的拖延而被挤占，甚至取消，从而使得测试质量得不到保证。

4.2 W模型

两个特点：
- W 是 V 的发展，强调测试应在整个开发周期进行。
- W 和 V 一样，开发行为与测试行为一一对应，但 W 并不主张动态测试必须要与开发阶段对应起来，W 也不限制动态测试行为必须严格地基于开发行为产生的单一文档
缺点：
- 在 W 模型中，需求、设计、编码等活动是串行的，测试和开发活动也保持一种线性的前后关系。只有上一个阶段完成之后，才能正式开始下一个阶段工作，从而无法支持迭代的开发模式。

4.3 H模型

将测试活动视为一个完全独立的活动，具有独立的包括测试准备活动和测试执行活动的流程。

只要测试准备就绪，就可以开始测试执行活动。在整个开发周期内，存在多个这样独立的测试流程。
体现“尽早准备、尽早执行”的思想，并且不同测试活动可以按照合理的顺序进行。

4.4 建议模型

5 软件评审

定义：

对所有人工静态分析技术和具体文档检查技术的通称
30％－70％的缺陷是通过软件评审发现
故召集有关人员就文档开评审会议用于提高质量. 1976年 IBM 开始采用软件评审方法，取得很好的效果

优点：

早发现错误早纠正，从而降低开发成本
除了开发人员参加外，用户也要参与，这样可以兼容各家之长，从不同的视角考虑问题
发现的缺陷较显见，而软件测试是从迹象判断缺陷存在（实际输出与预期输出不符），再根据各种现象分析，才能判断造成缺陷的原因，这是一个困难的过程
测试需对各个缺陷分别进行分析定位再纠正，而软件评审往往可以成批发现缺陷，同时也可以成批纠正缺陷，效率较高
测试时发现缺陷，程序人员往往急于纠正，而不能冷静考虑修正方案，会导致错上加错。而软件评审在早期，软件开发人员往往能够从容对待，全面衡量选择修改方案。

评审的一般过程：

计划：什么文档需要什么样的评审技术
概述：为参加评审的人提供所有必需信息
准备：集中学习评审对象并根据提供的基础文档检查评审对象，记录文档不足、问题或意见
评审会议：主持人，会议纪要
返工：在评审结果基础上修正故障
跟踪：项目经理、主持人或指定人来跟踪故障的修改

评审类型：

代码检查：
代码走查：不是简单的阅读程序，而是将参会人员“当作”计算机；
桌前检查：让程序员自己检查自己的程序；
同行评审：
非正式评审：不召开会议，只是彼此交换意见；

6 四种功能性测试用例设计方法（边界值、等价类、因果图、决策表）

6.1 功能性测试

基本观点：任何程序都可以看做是将输入定义域取值映射到输出值域的函数。
测试依据：软件的需求规格说明

6.2 边界值

一般边界值（单缺陷）：Min、Min+、Nom、Max-、Max；=> 4n + 1个测试用例

健壮性：Min-、Min、Min+、Nom、Max-、Max、Max+；

假设只使用 5 个变量，即单边界值的方式，那么

一般情况下，如果有 n 个变量，则有 $4 n + 1$ 个测试用例；
在最坏情况下：使用笛卡尔积的方式，就是 $5^n$ 个测试用例；

6.3 等价类

边界值测试既不能进行完备的测试，同时存在大量冗余。
等价类测试是把所有可能的输入数据，即程序的输入定义域划分成子集，然后从每一个子集中选取少数具有代表性的数据作为测试用例。
等价类测试也使用边界值测试的两个决定因素：即有效/无效值和单/多缺陷假设。
等价类的重要问题是构成集合的划分；
等价类测试的关键是选择确定等价类；

有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。

无效等价类：与有效等价类的定义恰巧相反，指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。

等价类划分的原则：

按区间划分：在输入条件规定了取值范围或值的个数的情况下, 可以确立一个有效等价类和两个无效等价类；
按数值集合划分：在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类
按限制条件或规则划分：规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

测试用例设计：

弱健壮等价类测试

对于有效等价类：每一个测试用例应该尽可能多的覆盖有效等价类；
对于无效等价类：每一个测试用例只覆盖一个无效等价类；

弱一般等价类：单缺陷

强一般等价类：多缺陷

弱健壮等价类：

强健壮等价类：

6.4 因果图

因果图方法最终生成的就是决策表，它适合于检查程序输入条件的各种组合情况，利用因果图生成测试用例的基本步骤如下：
分析软件规格说明描述中：

哪些是原因（即输入条件或输入条件的等价类）
哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
分析软件规格说明描述中的语义，找出原因和结果之间的相互关系，根据这些关系，画出因果图。
由于语法或环境限制，有些原因与原因、结果与结果之间的组合情况不可能出现，为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。
把因果图转换为决策表。
把决策表的每一列拿出来作为依据，设计测试用例。

因果图基本符合：

Ci 表示原因，ei 表示结果；
0 表示状态不出现，1 表示状态出现；

原因和结果之间的关系包括：

恒等：原因和结果之间一对一的对应关系。若原因出现，则结果出现。若原因不出现，则结果也不出现。
非：原因和结果之间的一种否定关系。若原因出现，则结果不出现。若原因不出现，反而结果出现。
或(∨)：若几个原因中有一个出现，则结果出现，只有当这几个原因都不出现时，结果才不出现。
与(∧)：若几个原因都出现，则结果才出现。表示若几个原因中有一个不出现，结果就不出现。

因果图法的约束符号：

E(互斥)：表示a,b两个原因不会同时成立，两个中最多有一个可能成立。
I(包含)：表示a,b,c三个原因中至少有一个必须成立。
O(唯一)：表示a和b当中必须有一个，且仅有一个成立。
R(要求)：表示当a出现时，b必须也出现。不可能a出现，b不出现。
M(屏蔽)：表示a是1时，b必须是0。而当a为0时，b的值不定。

6.5 决策表

在所有功能测试方法中，基于决策表的测试方法是最严格的，因为决策表具有逻辑严格性.
决策表很适合描述不同条件集合下采取行动的若干组合的情况.

7 两种结构性测试用例设计方法（控制流、数据流）（所有的测试覆盖准则）

7.1 控制流/路径测试

结构性测试最著名的形式以决策到决策DD路径的结构为基础，指语句的一种序列

覆盖准则：

语句覆盖：选择足够的测试用例，使得程序中每个可执行语句至少执行一次；
分支覆盖：选择足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值
条件覆盖：选择足够的测试用例，使得程序中每个判定中每个条件的可能值至少满足一次
条件判定覆盖：选择足够的测试用例，使得程序中每个判定中的每个条件的所有可能(真/假)至少出现一次并且每个判定本身的结果(真/假)也至少出现一次
条件组合覆盖：选择足够的测试用例，使得程序中每个判定中条件的各种可能组合都至少出现一次，显然满足条件组合覆盖的测试用例一定满足“(判定)分支覆盖”、“分支条件覆盖”和“条件判定覆盖”
路径覆盖：设计足够的测试用例要求覆盖程序中所有可能的路径

基路径测试：所有的路径都可以由基路径组成，就像空间中的所有向量都可以由基向量组成；

圈数量： $V (G) ＝ e - n + 2 p$

**控制流图：**就是将源代码的各个控制语句转化为状态图；

7.2 数据流测试

数据流测试指关注变量接收值的点和使用或引用这些值的点的结构性测试方法。可以看作是一种路径测试，提供一组基本定义和一种统一的测试覆盖指标结构。

早期的数据流分析常集中于定义/引用异常的缺陷：

变量被定义，但是从来没有使用
所使用的变量没有被定义
变量在使用之前被定义两次

8 测试用例设计方法的评估（3个指标）

假设功能性测试技术M生成m个测试用例，并且根据标识被测单元中的s个元素的结构性测试指标S来跟踪这些测试用例，当执行m个测试用例时，会经过n个结构性测试元素：

方法M关于指标S的覆盖是n和s的比值C(M,S)
方法M关于指标S的冗余是m和s的比值R(M,S)
方法M关于指标S的净冗余是m和n的比值NR(M,S)

9 各种测试覆盖准则的关系（逻辑覆盖6个、控制流图覆盖5个、数据流图覆盖3个）

9.1 逻辑覆盖（6个）

语句覆盖：选择足够的测试用例，使得程序中每个可执行语句至少执行一次；
分支覆盖：选择足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值
条件覆盖：选择足够的测试用例，使得程序中每个判定中每个条件的可能值至少满足一次
条件判定覆盖：选择足够的测试用例，使得程序中每个判定中的每个条件的所有可能(真/假)至少出现一次并且每个判定本身的结果(真/假)也至少出现一次
条件组合覆盖：选择足够的测试用例，使得程序中每个判定中条件的各种可能组合都至少出现一次，显然满足条件组合覆盖的测试用例一定满足“(判定)分支覆盖”、“分支条件覆盖”和“条件判定覆盖”
路径覆盖：设计足够的测试用例要求覆盖程序中所有可能的路径