软件工程技术--第七章软件测试

叫我王同学

已于 2022-11-11 15:17:53 修改

阅读量947

点赞数 1

分类专栏：软件工程技术文章标签：软件工程测试工具压力测试

于 2022-11-09 10:50:37 首次发布

本文链接：https://blog.csdn.net/qq_44985444/article/details/127765043

版权

软件工程技术专栏收录该内容

7 篇文章 12 订阅

订阅专栏

第七章软件测试

本章要点

掌握软件测试的目标与原则；
理解软件测试方法；
掌握等价类划分法、边界值分析法、错误推测法等黑盒法测试用例的设计；
熟悉逻辑覆盖法等白盒法测试用例的设计；
理解软件测试的过程；
了解软件测试工具；
了解软件调试概念。

软件测试

在开发软件的过程中，我们使用了保证软件质量的方法分析、设计和实现软件，但难免还会在工作中犯错误。这样，在软件产品中就会隐藏着许多错误和缺陷。特别是对于规模大、复杂性高的软件更是如此。在这些错误中，有些是致命性的错误如果不排除，就会导致生命与财产的重大损失。

软件测试人员

测试工具软件开发工程师(Software Development Engineer in Test，简称SDE/T)负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。
软件测试工程师(Software Test Engineer ，简称STE)负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误(Bug)，决定软件是否具有稳定性，并写出相应的测试规范和测试案例

7.1软件测试概述

1、软件测试的目标

软件测试的目的是为了发现软件产品中存在的软件缺陷，进而保证软件产品的质量。软件测试是软件开发过程中的一个重要阶段，是软件产品正式投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试的结果也是分析软件可靠性的重要依据。
测试阶段的根本目标是以最少的人力、物力和时间，尽可能多地发现并排除软件中潜在的错误，最终把一个高质量的软件系统交给用户使用。

2、软件测试的原则

在软件测试中，应注意以下指导原则：
1. 所有测试都应追溯到需求。
2. 坚持“尽早地和不断地进行软件测试”。
3. 测试用例应由输入数据和预期的输出结果两部分组成。
4. 程序员应避免测试自己的程序。杀虫剂现象
5. 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
6. 充分注意测试中的群集现象。 二八定律
7. 严格执行测试计划，排除测试的随意性。
8. 应当对每个测试结果做全面检查。
9. 在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。
10. 应长期保留所有测试用例。回归测试

3、软件测试模型

软件测试模型是指软件测试全部过程、活动或任务的结构框架。通常情况下，一个软件测试模型应该阐明的问题有：测试的时间、测试的步骤、如何对测试进行计划、不同阶段的测试中应该关注的测试对象、测试过程中应该考虑哪些问题、测试需要达到的目标。
一个好的软件测试模型可以简化测试的工作，加速软件开发的进程。
常用的软件测试过程模型有V模型、W模型和=H模型。
V模型
- V模型是最具代表意义的测试模型，它是软件开发中瀑布模型的变种。
- V模型的重要意义在于它非常明确地表明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程的各阶段的对应关系，即反映了测试活动与分析和设计活动的对应关系。
- 从V模型的示意图可以看出，它从左到右描述了基本的开发过程和测试行为。
- 左起从上往下，描述的是开发过程的各阶段，与此对应的是右侧依次上升的部分，即与开发过程各阶段对应的测试过程的各个阶段。
- 不难发现，在V模型中，测试工作在编码之后才能进行，所以在软件开发早期各个阶段引入的错误不能及时被发现。
- 尤其是需求阶段的错误只有到最后的验收测试才能被识别。
- 对分析、设计阶段产生的错误不能及时发现并改正的缺点会对后期的修复工作带来诸多不便，造成更多资源的浪费和时间的延迟。
W模型
- 它在V模型的基础上，增加了软件开发阶段中应同步进行的测试活动。
- W模型由两个分别代表开发过程和测试过程的V模型组成。
- W模型的最大优势在于，测试活动可以与开发活动并行进行，这样有利于及早地发现错误，但是W模型也有一定的局限性。
- 在W模型中，需求、设计、编码等活动依然是依次进行的，只有上一阶段完全结束，才有可能开始下一阶段的工作。
- 与迭代的开发模型相比，这种线性的开发模型在灵活性和对环境的适应性上有很大差距。
H模型
- H模型强调测试的独立性和灵活性。
- 在H模型中，软件测试活动完全独立，它贯穿于整个软件产品的生命周期，与其他流程并行进行。
- 当软件测试人员认为测试准备完成，即某个测试点准备就绪时，就可以从测试准备阶段进入到测试执行阶段。

7.2软件测试的分类

软件测试可以从不同的角度划分为多种类型
- 按照时间阶段：单元测试、集成测试、系统测试、验收测试。
- 按照是否运行程序：静态测试、动态测试。
- 按照是否查看源码：黑盒测试、白盒测试。
- 按照质量因素：功能测试、可靠性测试、可用性测试、性能测试、安全性测试。

7.3软件测试方法

静态测试
- 静态测试包括代码检查、静态结构分析、代码质量度量等，是指不在计算机上执行被测试软件，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。经验表明，人工测试能有效发现30%～70%的逻辑设计错误和编码错误。
  - 人工测试：是指不依靠计算机而靠人工审查程序或评审软件。人工审查程序的重点是对编码质量的检查，而软件审查除了审查编码还要对各阶段的软件产品（各种文档）进行复查。人工检测可以发现计算机不易发现的错误，特别是软件总体设计和详细设计阶段的错误。
  - 计算机辅助静态分析：指不需要执行所测试的程序，而只是通过扫描程序正文，对程序的数据流和控制流等信息进行分析，找出系统的缺陷，得出测试报告。
- 审查和走查是静态测试的常用形式。审查是指通过阅读并讨论各种设计文档以及程序代码，来检查其是否有错。
- 审查的工作可以独自进行，也可以通过会议的形式将相关的人员召集起来共同发现并纠正错误。
- 而走查的对象只是代码，不包括设计文档。代码走查以小组会议的形式进行，相关测试人员提供所需的测试用例，参会人员模拟计算机，跟踪程序的执行过程，对其逻辑和功能提出各种疑问，并通过讨论发现问题。
- 静态测试的效率比较高，而且要求测试人员具有丰富的经验。
动态测试
- 动态测试是真正运行被测程序，在执行过程中，通过输入有效的测试用例，对输入与输出的对应关系进行分析，以达到检测的目的。通常意义上的测试大多是指动态测试。设计高效、合理的测试用例是动态测试的关键。动态测试中有两种非常流行的测试技术：黑盒测试、白盒测试。
- 黑盒测试里，测试人员把被测试的软件系统看成是一个黑盒子，并不需要关心盒子的内部结构和内部特性，而只关注软件产品的输入数据和输出结果，从而检查软件产品是否符合它的功能说明。
- 白盒测试关注软件产品的内部细节和逻辑结构，即把被测的程序看成是一个透明的盒子。
- 不论是黑盒测试还是白盒测试，它们都可以发现被测系统的问题。
- 由于它们侧重的角度不同，所以发现的问题也不尽相同。
- 一般在软件测试的过程中，既要用到黑盒测试，又要用到白盒测试。
  - 大的功能模块采用黑盒测试
  - 小的构件采用白盒测试。
- 可以说，黑盒测试和白盒测试都是基于用例的测试方法，因为它们都通过运行测试用例来发现问题。

策略种类	黑盒测试	白盒测试
测试对象	程序的功能	程序的结构
测试要求	逐一验证程序的功能	程序的每一组成部分至少被测试一次
采用技术	`等价类划分法`、边界值分析法、错误推测法、因果图法。	`逻辑覆盖测试方法`、基本路径测试方法。

黑盒测试法
- 黑盒法又称功能测试或数据驱动测试，该方法把被测试对象看成一个不透明的“黑盒子”，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口（界面）处进行测试，依据需求说明书，检查程序是否满足功能要求，是否能很好地接收数据，并产生正确的输出。
- 通过黑盒测试主要发现以下错误：
  - 是否有不正确或遗漏了的功能。
  - 界面是否有错，能否正确地接受输入数据，能否产生正确的输出信息。
  - 是否有数据结构或外部数据库访问错误。
  - 性能是否满足要求。
  - 是否有初始化或终止性错误。

7.4测试用例的设计

1、黑盒技术

常用的黑盒测试技术有等价类划分、边界值分析、错误推测法、因果图等。

等价划分法
- 基本思想：把所有可能的输入或输出数据（有效的和无效的）划分成若干个等价的子集，称为等价类，使得每个子集中的一个典型值在测试中的作用与这一子集中所有其他值的作用相同，可从每个子集中选取一组数据来测试程序，这种方法称等价类划分法。
- 等价类可分为有效等价类和无效等价类两种。前者主要用来检验程序是否实现了规格说明中的功能；后者主要用来检验程序否做了规格说明以外的事情。
- 在划分等价类时，有一些可供遵循的原则：
  - 如果输入条件规定了取值范围或个数，则可确定一个有效等价类和两个无效等价类。
  - 如果输入条件规定了输入值的集合或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。
  - 如果输入条件是布尔表达式，则可以分为一个有效等价类和一个无效等价类。
  - 如果输入条件是一组值，且程序对不同的值有不同的处理方式，则每个允许的输入值对应一个有效等价类，所有不允许的输入值的集合为一个无效等价类。
  - 如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类（符合规则）和若干个无效的等价类（从不同的角度违反规则）
- 采用这一技术要注意两点：
  - 划分等价类不仅要考虑代表“有效”输入值的有效等价类，还需考虑代表 “无效”输入值的无效等价类。
  - 每一无效等价类至少要用一个测试用例，不然就可能漏掉某一类错误，但允许若干有效等价类合用同一个测试用例，以便进一步减少测试的次数。
- 划分好等价类后，就可以设计测试用例了。设计测试用例的步骤可以归结为以下3步。
  1. 对每个输入和外部条件进行等价类划分，画出等价类表，并为每个等价类进行编号。
  2. 设计一个测试用例，使其尽可能多地覆盖有效等价类，重复这一步，直到所有的有效等价类被覆盖。
  3. 为每一个无效等价类设计一个测试用例。
=边界值分析法
- 边界值分析是一种补充等价类划分法的测试用例设计技术。边界值分析就是测试边界线数据。使用边界值分析法设计测试用例时，应考虑选取正好等于、刚刚大于和刚刚小于边界的值作为测试数据，这样发现程序中错误的概率较大。
错误推测法
- 错误推测法是根据经验来设计测试用例以找出可能存在但尚未发现的错误的方法。
- 错误推测法的基本思想是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例。
因果图法
- 因果图法用于检查程序输入条件的各种组合情况。等价类划分法和边界值分析法都侧重考虑输入数据，而因果图法主要考虑输入数据之间的联系。该方法能够生成没有重复的且发现错误能力强的测试用例，而且对输入输出数据同时进行分析。

2、白盒技术

白盒测试关注软件产品的内部细节和逻辑结构，即把被测的程序看成是一个透明的盒子
白盒测试方法有逻辑覆盖测试方法、基本路径测试方法。

逻辑覆盖法
- 逻辑覆盖法以程序内在的逻辑结构为基础，根据程序的流程图设计测试用例。它是一系列测试过程的总称。
- 第一步：绘制出程序流程图。
- 第二步：设计测试用例
  1. 语句覆盖
    - 基本思想：设计若干个测试用例，运行被测试的程序，使程序中的每个可执行语句至少执行一次。
  2. 分支覆盖（判定覆盖）
    - 基本思想：使每个判断的取真分支和取假分支至少执行一次。
  3. 条件覆盖
    - 基本思想：是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。
  4. 分支–条件覆盖
    - 分支—条件覆盖就是要同时满足分支覆盖和条件覆盖的要求。其用例取分支覆盖的用例和条件覆盖的用例的并集即可。
  5. 条件组合覆盖
    - 基本思想：使每个判断语句的所有逻辑条件的可能取值组合至少执行一次。
  6. 路径覆盖
    - 基本思想：覆盖被测试程序中的所有可能的路径。
- 一般情况下，这6种覆盖法的覆盖率是不一样的，其中路径覆盖的覆盖率最高，语句覆盖的覆盖率最低。

3、综合测试策略

前面介绍的软件测试方法，各有所长。每种方法都能设计出一组有用的测试用例，用这组用例可能容易发现某种类型的错误，但可能不易发现另一种类型的错误。
因此，对软件系统进行实际测试时，应该联合使用各种测试方法，形成综合策略。通常是先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。具体方法如下：
- 在任何情况下都应该使用边界值分析方法。
- 用等价类划分法补充测试用例。
- 用错误推测法补充测试用例。
- 对照程序逻辑，检查已经设计出的测试用例的逻辑覆盖程度，如果没有达到所要求的覆盖标准，则应当再补充一些测试用例。
- 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

4、测试实例分析

下面给出一个三角形分类程序的测试方案的设计。程序的功能是，读入三个整数值代表三角形的三条边的长度，程序判断这三个值能否构成三角形，如果能够，则输出三角形是等边、等腰或任意三角形的分类信息。
综合使用边界值分析、等价类划分和错误推测等技术为此程序设计测试用例。
第一步：确定测试策略。因为在本例中对被测程序已有明确的要求，即：判断能否构成三角形，如能构成，则再判断能构成等边、等腰或任意三角形哪一种。因此，可首先运用黑盒测试法设计测试用例，然后再用白盒测试法验证其完整性，必要时再补充测试用例。
第二步：在黑盒测试中首先要用等价类划分法划分输入等价类，然后用边值分析法和错误推测法作补充。

7.5软件测试步骤

对于大型的软件系统，测试基本上由单元测试、集成测试、确认测试和系统测试四个步骤组成。
单元测试又称模块测试，主要是检查每个程序模块是否正确实现了规定的功能。
集成测试又称组装测试，主要检查概要设计中模块接口设计问题。
确认测试主要检查已实现的软件是否满足需求说明书中确定的各种需求。
系统测试是综合检验软件与整个计算机系统的测试。
测试的每个过程都可以采用灵活的测试方法和测试策略，通常在单元测试中采用白盒测试方法，而在其他测试中主要采用黑盒测试方法。

单元测试
- 单元测试是对软件设计的最小单位——程序模块的测试，也是对程序模块进行正确性检验的测试，其目的在于发现各模块内部可能存在的各种差错。通常单元测试可以放在编码阶段，程序员在编写完成一个模块且无编译错误后就可以进行，主要是检查模块是否实现了详细设计说明书规定的模块功能和算法。
- 单元测试需要从程序的内部结构出发设计测试用例，通常采用白盒测试方法，以路径覆盖为最佳测试准则。多个模块可以并行独立地进行单元测试。
- 单元测试的内容：模块接口测试、局部数据结构测试、重要路径测试、错误处理测试、边界测试。
- 单元测试的步骤：配置测试环境、编写测试数据、进行多个单元的并行测试。
集成测试
- 集成测试也称组装测试或联调，是在单元测试的基础上，将所有模块按照软件设计要求组装成系统并进行测试的过程。组装测试主要通过检查模块间的结构和通信发现软件设计阶段产生的错误，通常采用黑盒测试方法。
- 在组装测试过程中，需要考虑如下几个问题：
  - 数据穿越模块接口是否会丢失。
  - 一个模块的功能是否会对另一个模块的功能产生不利的影响。
  - 各个子功能组合起来，能否达到预期要求的父功能。
  - 全局数据结构是否有问题。
  - 单个模块的误差累积起来，是否会放大，以至于达到不能接受的程度。
- 把多个模块组装成系统，通常有两种方式：非渐增式组装和渐增式组装。
  1. 非渐增式组装方式
    - 也称整体拼装。即将单元测试后的模块按照系统总体结构图一次性集成起来，然后进行全程序测试。其优点是效率高，缺点是发现错误难以诊断定位，所以又称“莽撞测试”，只适宜小规模的系统。
  2. 渐增式组装方式
    - 也称增殖式方式。从一个模块开始，测试一次添加一个模块，边组装边测试，以发现与接口相联系的问题，直至所有模块全部集成到程序中。该方式适合于大规模的系统。
    - 渐增式组装方式有两种：自顶向下组装和自底向上组装。
确认测试
- 确认测试也称有效性测试，目的是确认组装完毕的软件是否满足软件需求规格说明书的要求。典型的确认测试通常包括有效性测试和软件配置审查等内容，测试结束后，软件就要交付验收了。
- 1.有效性测试 2.软件配置审查 3.α测试β测试 4.验收测试
系统测试
- 系统测试是把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。其目的是检查软件能否与系统的其余部分协调运行，并且实现软件需求规格说明书的要求。系统测试是验收测试的一部分，应由用户单位组织实施。软件开发单位应该为系统测试创造良好的条件，负责回答和解决测试中可能发现的一切质量问题。
- 常见的系统测试主要有以下几方面。
  1. 恢复测试：主要检查系统的容错能力。当系统出现错误时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统能否尽快恢复。
  2. 安全测试：主要检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线，检验系统预防机制的漏洞。
  3. 强度测试：主要检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。如运行一些超过正常输入量或需要最大存储空间的测试用例。
  4. 性能测试：主要检查软件在集成的系统中的运行性能。它对实时系统和嵌入式系统尤为重要。性能测试常与强度测试相结合进行。经常需要其他软硬件的配套支持。

7.6软件调试

调试的目的和步骤
- 软件测试的目的是尽可能多地发现程序中的错误，而调试则是指成功的测试之后才开始的工作。调试的目的是根据测试时发现的错误，找出错误的原因和具体位置，并改正错误，因此，调试也称为纠错或排错。
调试过程
- 在测试发现错误后排除错误的过程
调试策略
- 调试是技巧性很强的工作，调试的关键在于推断程序内部的错误位置及原因。调试工作的困难与人的心理因素和技术因素都有关系，而心理因素的影响常常高于技术手段而占主导地位。
- 常用调试策略：
  - 蛮干法：运行跟踪，在程序中加载大量输出语句，在产性的大量信息中找到错误线索。
  - 试探法：凭借经验猜想故障的位置，然后使用适当的调试技术。
  - 回溯法：检查错误症状，确定最先发现症状的地方，然后沿着源程序的控制流往回追踪程序代码，直到找出错误根源或确定故障范围为止。
调试原则
- 由于调试工作有查错和排错两项任务，因此调试原则也分成两组：
  1. 查错原则
    - 注重用头脑去分析思考与错误征兆有关的信息。
    - 避免用试探法，最多只能把它当作最后手段。
    - 调试工具不能代替人的思考，只能把它当作辅助手段来使用。
    - 避开死胡同。
  2. 排错原则
    - 注意错误的群集现象，在错误近邻检查。
    - 采用回归测试，避免因修改引起的新错误。
    - 不能只修改错误的表现，要找到错误的本质并修改。
    - 要修改源代码，而不要修改目标代码。