当前位置：文档之家 › 基于故障模型的软件测试

基于故障模型的软件测试

  • 格式：pdf
  • 大小：154.28 KB
  • 文档页数：16

下载文档原格式

  / 16

合集下载

软件测试基于缺陷模式的软件测试

软件测试基于缺陷模式的软件测试

基于缺陷模式的软件测试
基于缺陷模式的软件测试概述 基于缺陷模式的软件测试指标分析 缺陷模式 基于缺陷模式的软件测试系统（DTS）
基于缺陷模式的软件测试指标分析
设P是待测程序，将缺陷模式M分成类 M={M1，M2，…Mn}，每类分成种 Mi={Mi1，Mi2，…，MiL},从P中计算出 和M相匹配的检查点的集合 IP={IP1,IP2,…,IPm},可以定义如下技术 指标：
基于缺陷模式的软件测试概述
缺陷模式必须满足下列几个条件： 1. 该模式下的缺陷是符合实际的。 2. 基于该模式的缺陷数目是可以容忍的。 3. 该模式下的缺陷是可以测试的。
基于缺陷模式的软件测试概述
基于模式的软件测试技术具有如下特点： 1. 针对性强：如果说某种模式的缺陷是经常发生的，
并且在被测软件中是存在的，则面向缺陷的测试可 以检测出此类缺陷。 2. 基于缺陷模式的软件测试技术往往能发现其他测试 技术难以发现的故障，如内存泄漏缺陷，空指针引 用缺陷。 3. 工具自动化程度高以及测试效率高。 4. 缺陷定位准确：对测试所发现的缺陷能够准确定位。 5. 易学、易使用：对一般的IT专业专科以上的毕业生， 该测试方法一般经过数天的培训即可掌握其使用方 法。
故障模式
1. 存储泄漏的故障模式（Memory Leak Fault MLF） 定义：内存泄漏故障（Memory Leak Faults）：
设在程序的某处申请了大小为M的空间，凡在程序结 束时M或者M的一部分没被释放、或者多次释放M或 M的一部分都是内存泄漏故障。
MLF有三种形式： 遗漏故障：是指申请的内存没有被释放。 不匹配故障：是指申请函数和释放函数不匹配。 不相等的释放错误：是指释放的空间和申请的空间大
小不一样。

故障模型在软件测试上的应用探讨

故障模型在软件测试上的应用探讨

陷 ， 以得 到 更 高的投 资回报 。 可 而在 实施 软件 测试 的过 程 中， 遇 到各 种难 以预 料 的软件 问题 。因此 ， 会 建立故 障模 型 ，
分 析 故 障 树 ， 行 软 件 测 试 用例 的 设 计 尤 为 关 键 。 进
关键 词 ： 件测 试 ； 障模 型 ； 障树 ； 软 故 故 测试 用例
故 障模 型是 测试 的基 础 。 是 一个 测试 方 法成 熟 的重 要标 也
志 。软 件 的 错 误表 现 为２ 方 面 ： 计 算 结 果 错 误 ； 系统 “ 个 ① ② 死
机 ” 导 致第 １ 错误 的故 障相 对来 说是 比较 容 易检测 的 。导致 。 类
的是 为了保 证软件 产 品的最 终质 量 。 般来 说软件 测试 应 由独 一 立的 产 品评测 中心 负责 ， 格 按 照软 件测 试 流 程 ， 定 测试 计 严 制
试方 案 、 方法 、 术和 策略 。 技 内容 包括 测试 目标 、 试环 境 、 入 测 输 数据 、 测试 步骤 、 预期结 果 、 测试 脚 本等 ， 形成 文档 。 并
（） １ 数组 越 界 故 障 的故 障模 型 （ Ｏ Ｆ 。设 某 数 组 定 义 为 ＯＢ）
Ａ ｒｙｍｉ— ｘ。 引ｍＡ ｒｙｉｔ ＜ ｎ ＞ ａ 都 是数 组越 界 故 ｒ ［ ｎ ｍａ］ ａ 若 ｒａ［ ￣Ｉｍｉ或ｉｍ ｘ ］ 障 ， Ｃ 中 ， ｉ０ ＞ ｍａ是 数组 越界 故 障。 在 “ 若 ＜ 或ｉ＝ ｘ （） ２ 存储 泄 漏 故 障模 型 （ Ｆ 。设 在程 序 的某 处 申请 了大 ＭＬ ） 小为Ｍ的空 间 ． 凡在 程序 结 束时 Ｍ或 者Ｍ的一 部 分没 有被 释放 ， 或者 多次 释放 Ｍ或Ｍ的一 部分 都是 内存 泄漏 故 障 。 Ｆ 种形 ＭＬ 有３

基于故障注入的应用软件可靠性测试

基于故障注入的应用软件可靠性测试

基于故障注入的应用软件可靠性测试姜文;刘立康【摘要】随着计算机技术的发展, 云计算技术在各行各业的应用普及, 基于云计算的应用软件的种类也越来越多.基于云环境的软件可靠性测试有许多问题和技术需要研究和探讨.在可靠性测试技术中, 故障注入技术应用十分广泛.结合一个云化通讯软件实例叙述了采用故障注入技术在云环境开展可靠性测试工作的全过程.叙述了可靠性测试过程以及各个角色在测试过程中的职责和任务;叙述了云环境的层级结构、私有云环境的部署和软件产品的安装;叙述了云环境中故障注入方法和可靠性测试环境的构建;详细叙述了该软件实例的测试用例设计、可靠性测试流程和编写自动化测试脚本;最后给出了测试结果分析.工作实践表明, 做好软件可靠性测试工作可以提高软件产品的质量, 提高上线后软件产品的可靠性, 从而更好地满足客户对软件产品的需求.%With the development of computer technology, cloud computing technology is widely used in all walks of life, and there are more and more kinds of cloud-based application software.Software reliability testing based on cloud environment has many problems and technologies needed to be studied and discussed.Fault injection technology is widely used in reliability testing.The whole process of reliability test in cloud environment using fault injection technology is described with an example of cloud-based communication software.We describe the process of reliability testing and the duties and tasks of characters in the testing process;describe the hierarchy of the cloud environment, the deployment of private cloud and the installation of software products;describe the fault injection method in cloudenvironment and the reliability test environment construction;describe the software instance of test case design, reliability, test process and writing automation test scripts in detail.The test analysis is also given atlast.Practice shows that doing well in software reliability test can improve the quality of software products and the reliability of the software product after launch, better meeting customer demand for software products.【期刊名称】《计算机技术与发展》【年(卷),期】2019(029)002【总页数】6页(P23-28)【关键词】可靠性;故障注入;可靠性测试;云环境;容错能力【作者】姜文;刘立康【作者单位】西安电子科技大学通信工程学院, 陕西西安 710071;西安电子科技大学通信工程学院, 陕西西安 710071【正文语种】中文【中图分类】TP311.50 引言随着计算机技术的发展，云计算技术在各行各业的应用普及，基于云计算的应用软件的种类也越来越多。

基于Gompertz模型的软件质量与测试过程评估分析

基于Gompertz模型的软件质量与测试过程评估分析

SYS PRACTICE 系统实践摘要：软件产品的缺陷可通过软件测试发现，软件测试直接影响软件质量，为更好开展软件测试，必须设法满足软件产品质量与测试过程的定量度量与预测需求。

基于此，论文将围绕基于模型的软件质量与测试过程评估开展研究，模型参数估计采用非线性回归最小二乘法，以此定量预估软件产品质量和测试过程，为测试活动的更好开展提供支持。

关键词：Gompertz模型；软件质量；软件测试；软件缺陷；过程评估一、研究思路结合相关研究和实践可以了解到，软件测试的最终目的是通过有限的物力、人力，高质量、高效率的完成测试。

对于软件测试来说，过度的测试将引发资源浪费问题，而不充分的测试则会引发很多问题。

如软件测试不足，软件隐藏错误催生的风险将由用户承担，如过度开展软件测试，很多宝贵的资源则会浪费。

因此，在软件测试的实践中，必须把握好软件测试的尺度，这种尺度的掌握需得到科学定义的定量描述工具支持，以此保证软件产品经理能够做出正确判断。

为实现软件测试尺度的定量描述，国内外相关学者开展大量研究，如基于软件缺陷进行度量、基于软件过程能力度指数控制图进行度量、基于软件缺陷状态跟踪图进行度量，但这类研究多围绕测试数据的定性判断展开，缺乏定量层面的研究。

因此，本文基于已有的测试数据，采用模型，定量分析和预测软件测试过程，以此定量评估软件产品质量，为测试任务是否应结束提供科学的判断依据[1]。

二、建模机理结合日常的软件测试实践进行分析可以发现，在软件测试的初始环节，由于不熟悉测试环境，测试人员一般仅开展基本功能测试，这种情况下软件测试日均发现的缺陷数减少，软件缺陷数增长在这一环节也较为缓慢。

随着逐渐进入状态，测试人员可实现对测试环境的熟练掌握，受不断增多的日均发现软件缺陷数影响，存在增长速度迅速加快的发现软件缺陷数。

随着软件测试的不断推进，受隐藏加深的软件缺陷影响，难度加大的测试使得一个缺陷发现需要执行较多的测试用例，这一过程中虽然缺陷数仍属于增长状态，但增长速度极慢，而对于有限的软件中隐藏缺陷来说，发现缺陷数的无限增长也会在这种情况下受到限制。

基于模型的软件可靠性研究

基于模型的软件可靠性研究

基于模型的软件可靠性研究随着计算机技术的不断发展，软件已经成为了现代人们生活和工作中必不可少的一部分。

然而，随着软件规模的不断扩大，软件可靠性问题也变得越来越重要。

因此，研究基于模型的软件可靠性研究成为了当前重要的研究方向。

一、软件可靠性的概念软件可靠性是指软件在特定的条件下，能够执行其规定的功能，而不出现故障，并在规定的时间内为用户提供正确的结果的能力。

软件可靠性与软件质量密切相关，也是软件质量的重要组成部分。

二、基于模型的软件可靠性研究方法基于模型的软件可靠性研究方法是一种比较常用的软件可靠性研究方法，其本质是建立数学模型，通过分析模型，预测软件在实际使用过程中的可靠性。

目前，基于模型的软件可靠性研究方法包括三种主要方法：可靠性建模法、可靠性测试法和可靠性分析法。

1、可靠性建模法可靠性建模法是一种通过建立可靠性模型来预测软件可靠性的方法。

可靠性模型可以是概率模型、统计模型或者物理模型等。

其中，概率模型是一种用于计算软件可靠性的常用模型，其基本思想是将软件可靠性问题转化为概率问题，通过计算概率来预测软件可靠性。

2、可靠性测试法可靠性测试法是一种通过执行一系列测试用例来评估软件可靠性的方法。

可靠性测试法主要包括两种方法：基于故障注入的可靠性测试和基于负载的可靠性测试。

其中，基于故障注入的可靠性测试是一种在软件中人为地注入故障，然后通过对故障进行分析，评估软件可靠性的方法。

基于负载的可靠性测试是一种在不同的负载条件下测试软件的可靠性，并通过负载试验结果预测软件在不同负载下的可靠性。

3、可靠性分析法可靠性分析法是一种通过数据分析来预测软件可靠性的方法。

可靠性分析法主要包括两种方法：失效率分析法和故障树分析法。

失效率分析法是一种用于分析软件失效率的方法，其基本思想是通过对软件运行时的失效率进行统计分析，从而评估软件的可靠性。

故障树分析法是一种用于分析软件故障的方法，其基本思想是将软件故障看作是故障树的叶子节点，通过对故障树进行分析，找出造成软件故障的根本原因，最终评估软件的可靠性。

软件测试过程与测试模型

软件测试过程与测试模型

软件产品的组成（续）
4、设计文档
构架。即产生描述软件整体设计的文档，包括软件 所有主要部分的描述以及相互间的交互方式。
数据流示意图。表示数据在程序中如何流动的正规 示意图。通常由圆圈和线条组成，所以也称为泡 泡图。
状态变化示意图。将软件分解为基本状态或者条件 的另一种正规示意图，表示不同状态之间的变化 的方式。
• 概要设计。这个阶段的主要任务是解决系统”怎么做” 的问题。概要设计决定软件系统的总体结构即模块结构 ，并给出模块的相互调用关系、模块间传递的数据及每 个模块的功能说明。这个阶段的文档资料是软件结构图 和模块功能说明。
• 详细设计。这个阶段的任务是把每个模块内部过程的描述 具体化，也就是回答”应该怎样具体地实现这个系统”。该阶 段的任务并不是编写程序，而是设计出程序的详细规格说明书 。该规格说明书类似于其他工程领域使用的工程蓝图。
归纳、统计和总结。采用图表、表格和报告等 形式来描述整个测试过程。
软件产品的组成（续）
6、开发进度表 软件项目的开发进度通常使用Gantt图表来进行 描述。
7、软件产品组成的其他部分 （1）程序代码 （2）帮助文件 （3）用户手册 （4）样本和示例 （5）标签 （6）产品支持信
息 （7）图表和标志 （8）错误信息 （9）广告与宣
传材料
2.1.2 软件开发项目组
• 项目管理经理：全程负责整个软件项目的开发。 • 系统设计师：设计整个系统构架或软件构思。 • 程序员：负责设计、编写程序，并修改软件中的缺陷。 • 软件测试员/测试师：负责找出并报告软件产品的问题，
与开发组密切合作，进行测试并报告发现的问题。 • 技术制作、用户助手、用户培训员、手册编写和文件档
优点：能够较为迅速的展现成果，适合需要快速 制作而且用完就扔的小项目，如示范程序、演 示程序等。

总结软件故障模型（简要）

功能测试软件故障模型1 1.理解故障模型测试的目标就是要发现错误，因此在编写测试用例的时候也要遵循这个目标，尽量在软件的最薄弱环节多编写测试用例。

接下来介绍什么是软件的薄弱环节，缺陷一般隐藏在什么地方，如何有效地找出这些缺陷。

优秀的软件测试人员可以很快地找到解决办法。

虽然测试时有很多单个输入变量、多个输入变量的组合，但是优秀的软件测试人员不会依靠运气，他们有着丰富的经验和直觉，可以从中找到哪些是要进行测试的，哪些不需要测试，那些操作可能会引起软件失效。

把这些测试人员的经验和直觉尽量归纳和固化，以形成一些故障模型fault model。

2.常见功能性测试故障模型1输入非法数据a.如何发现错误输入类型：键入无效的类型常会产生错误信息。

例如必须输入整型，而输入了实型或字符型。

输入长度：对于字符型，键入太多的字符常会引出错误信息。

边界值：输入边界值或超过边界值的数据，例如，边界值为4，可以输入4及4以上的数值。

b.方法小结应用场合：GUI的输入测试方法：分别从输入数据的类型、输入数据的长度、输入数据的边界值等方面进行考虑。

测试信息的检查：除了考虑输入非法数据，还要留意错误信息本身，特别注意以下几点：错误信息和错误要一致，防止A的错误提示显示给了错误B，B的错误提示信息给了错误C。

错误信息的内容是空，用户不知道为什么出错。

显示的错误信息是给开发人员调试使用的，例如Error 5-unknown data，开发人员可以通过该提示信息很容易地找到错误类型，但是用户根本不明白，不知道做错了什么。

测试知识储备：牢记基本数据类型的边界值。

2输入默认值a.如何发现错误查找选项按钮、配置面板、安装屏幕等。

这种屏幕上显示的数据常在应用程序的许多地方用到。

查阅源代码的数据声明部分如果可以得到。

确定了要测试的数据，可以通过以下操作来强制使用或不使用默认值：接受软件显示的默认值。

有时软件需要用户输入一个值，如果没有输入任何值，软件就可能失效。

考虑故障相关的软件可靠性增长模型研究

过程 （ ＮＨＰ ） 的 考 虑 故 障 相 关 性 、 试 环 境 和运 行 环 境 差 别 的模 型 ． 两 组 失 效 数 据 上 的 实 验 分 析 表 明 ： 这 两 Ｐ中 测 在 对 组 失 效 数 据 ， 中提 出 的模 型 比其 他 一 些 非 齐 次 泊 松 过 程 类 模 型 的 拟 合 效 果 和 预 测 效 果 更 好 ． 文 关 键 词 软 件 可靠 性 增 长 模 型 ； 障 相 关 性 ； 试 环 境 ； 行 环 境 故 测 运
维普资讯
第 ３
报
Ｖｏ ．３ Ｎｏ １ １ Ｏ ． Ｏ ０ｃ ． ２ ０ ｔ ０７
２０ ０ ７年 １ Ｏ月
ＣＨＩ ＮＥＳ ＯＵ ＲＮＡ Ｌ ＯＦ ＣＯＭ ＰＵＴＥＲＳ ＥＪ
考 虑 故 障相 关 的 软 件 可 靠 性增 长模 型 研 究
中 图 法分 类 号 Ｔ ３１ Ｐ １
Ｓ ｕ ｙ ｏ ｏ ｔ ｒ ｌａ ｌｔ ｏ ｈ Ｍ ｏ ｌＣｏ ｉ ｅ ｉ ｉｕ ｅ Ｄｅ ｅ ｅ ｃ ｔ ｄ ｎ Ｓ ｆ ｗａ ｅ Ｒｅ ｉ ｂｉｉｙ Ｇｒ ｗｔ ｄｅ ｎｓｄ ｒ ｎｇ Ｆａ ｌ ｒ ｐ ｎｄ ｎ ｙ
Ｚ ＡＯ ｇ ＺＨ ＡＮＧ — ＧＵ ｏＣｈ ｎ Ｈ Ｊｎ ｉ Ｒｕ— Ｂｏ Ｇｕ — ａ ｇ —
（ ｃ ｏ ｌ ｆ Ｃ ｍｐ ｔｒＳ ｉｎ ｅ ｎ ｅｈ ｏ ｏ ｙ，Ｈａ ｂｎ Ｅｎ ｉｅ ｒｎ ｉｅ ｓｔ Ｓ ｈ ｏ ｏ ｕｅ ｃ ｃ ｄ Ｔ ｃ ｎ ｌｇ ｏ ｅ ａ ｒ ｉ ｇ ｎ ｅ ｉ ｇ Ｕｎｖ ｒｉ ｙ，Ｈａ ｂｎ １ ０ ０ ） ｒ ｉ ５ ０ １
Ａｂ ｔａ ｔ Ｓ ｆｗａ ｅ ｒ ｌ ｂ ｌ ｙｇ ｏ ｈ ｍｏ ｅ Ｓ ｓｒ ｃ ｏ ｔ ｒ ｅｉ ｉ ｔ ｒ ｗｔ ｄ ｌ（ ＲＧＭ ） ｉ ｏ ｅｏ ｈ ｍ ｐ ｒａ ｔｔ ｏ ｓｔ ｖ ｌ ａ ｅ ａ ｉ ｓ ｎ ｆｔ ｅ ｉ ｏ ｔ ｎ ｏ ｌ ｏ ｅ ａｕ ｔ

基于故障模型嵌入式软件缺陷分类论文

基于故障模型的嵌入式软件缺陷分类研究摘要：针对嵌入式软件的特点，通过对现有一些软件缺陷分类方法进行研究分析，本文提出了一种基于故障模型的缺陷分类方法，这种方法在软件测试中能有效的发现一些极易疏忽的软件故障。

关键词：嵌入式；软件缺陷；故障模型；缺陷分类中图分类号：tp311.52 文献标识码：a文章编号：1007-9599 (2011) 24-0000-01embedded software defect classification study based on fault modelyou wenlin(302 design and research institute,guiyang550009,china) abstract:aiming at the characteristics of embedded software,based on existing software defect classification method to carry on the research analysis,this paper presents a method based on fault model of the defect classification method,this method in software testing can effectively find some very easy to neglect software fault.keywords:embedded;software defect;fault model;defect classification一、引言在嵌入式领域目标系统的应用系统日益复杂，开发技术日新月异，同时硬件发展的日益稳定，而软件缺陷问题却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。

但由于嵌入式系统具有实时性、内存不丰富、i/o 通道少，cpu种类繁多等特点，相对非嵌入式软件开发和策略有很大不同，测试更复杂。

基于故障树分析法的软件测试技术研究


０ 引 言
软 件 开 发 平 台 的集 成 化 和 软 件 开 发 技 术 的 迅 猛 发 展 使 得
析 ， 现 了 以 系 统 工 程 方 法 研 究 安 全 问题 的系 统 性 、 确 性 和 体 准
预测性 。 障树分析法 是把系统 不希望发 生的故障状态 定义 故 为“ 顶事 件” 通过分析 寻找 出导致 顶事件故 障发生 的所 有可 ，
Ｒｅ ｅ ｒ ｈ ｏ ｃ ｎ ｑ ｅｏ ｆ ｒ ｅ ｔ ｇｂ ｓ ｄ ｏ ａ ｌ ｔｅ ｎ ｌ ｓｓ ｓ ａ ｃ ｎｔ ｈ ｉ ｕ ｆｓ ｔ ｅ ｏ ｗａ ｅｔｓｉ ａ ｅ ｎ ｆｕ ｔ ｒ ｅａ ａｙ ｉ ｎ
ＺＨＵ ｎ ｐ ｎ Ｙｕ — ｅ ｇ
（ ｐ ｒ ｎ ｆ ｔ ｏｋ ｎｉｅｒ ｇ Ｈ ｆｉ ｌｃ ｏ ｉ Ｅ ｇｎ ｅ ｎ ｓｔｔ，Ｈｅ ｉ ３ ０ ７ ｈｎ） Ｄｅａｔ ｔ Ｎｅ ｒ ｇｎ ｅｉ ， ｅｅ Ｅｅｔ ｎｃ ｎ ｉｅｒ ｇＩ ｔｕｅ ｍｅ ｏ ｗ Ｅ ｎ ｒ ｉ ｎｉ ｆ ０ ３ ，Ｃ ｉ ｅ２ ａ
维普资讯 第 ２ 卷 第 ຫໍສະໝຸດ 期 ９ ３Ｖｏ１２９ ．
Ｎ Ｏ． ３ １
计 算 机 工 程 与设 计
Ｃｏ ｐ ｔ ｒＥｎ ｉ ｅ ｒ ｎ ｎ ｓｇ ｍ ｕ ｅ ｇ ｎ ｅ ｉ ｇ ａ ｄ Ｄｅ ｉ ｎ
２０ 年 ７ ０８ 月
Ｊ ｌ ０ ８ ｕｙ２ ０
寻找每一个 中间事件发 生的所 有可 能原 因， 以此类 推， 至追 直
踪 到 最 后 一 级 基 本 事 件 ， 即“ 事 件 ” 也 底 。 故 障 树 分 析 法 从 具 体 故 障 结 果 出 发 ，以分 支 结 构 和 逐 层 细 化 的方 式 寻 找 出所 有 的直 接 和 间 接 因 素 ， 最 终 分 析 结 果 其 采 用 故 障 树 图 的 图形 化 表 示 方 法 。 障 树 图是 一 种 逻 辑 因果 故
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

【例 6-2】 下列程序结构： …;str=malloc(10);…;delete(str);… 即是第 II 类 Memory leak 故障。 （3） pointer 是用 new 分配的变量，若存在 Pi 且在 Pi 上只存在一个 delete (pointer)，则是正确的。反之，如果存在两个或两个以上 delete (str)，或者无 delete (pointer)，或者存 在一个或一个以上的 free (pointer)，则是 III 类 Memory leak 故障。 【例 6-3】 下列程序结构： …;str=new(10);…;free(str);… 即是第 III 类 Memory leak 故障。 （4）pointer 是用 new[ ]分配的变量，若存在 Pi 且在 Pi 上只存在一个 delete[]，则是正确的。反之，如果用 delete 或用 free 释放的则是 IV 类 Memory leak 故障。 【例 6-4】 下列程序结构： …;class A { }; t=new A[10]; …;delete t;… 即是第 IV 类 Memory leak 故障。 （5）多余的 delete 和 free 是 V 类 Memory leak 故障。 【例 6-5】 下列程序结构： …;char *str=”abc”,…free(str);… 即是第 V 类 Memory leak 故障。 （6）当申请内存的 pointer 发生变化后，用 delete 和 free 释放变化后的 pointer 是 VI 类 Memory leak 故障。 【例 6-6】 下列程序结构： …;char *p=malloc(10);…;++p;…;free(p); 即是第 VI 类 Memory leak 故障。 （7) 如果在构造函数中有申请内存的操作、且在其它函数中出现对象的拷贝，如果无拷贝构造函数，则会产生析构函数对内存会出现重复释放的错误。该类错误称为第 VII 类 Memory leak 故障。 【例 6-7】 下列程序： class base { public: char *p; public: base() { p=new char[strlen("default value")+1]; strcpy(p,"default value"); printf("base constructor is calling\n"); }
} 由于在主程序中有语句 b=a 的操作，如果没有对“=”运算符的重载定义，则当程序执行析构函数时，对指针*p 就执行了两次释放操作，可能会造成死机。 （9）在“=”重载操作中，如果涉及到指针操作，则必须判断两个对象是否为同一个对象，否则当进行释放指针的操作时，就可能产生错误。该类错误称为第 IX 类 Memory leak 故障。 【例 6-9】 下列程序： class MyString { public: char *mChars; MyString() { mChars=new char[strlen("default value")+1]; strcpy(mChars,"default value"); } MyString& operator= (const MyString& rhs); }; MyString& MyString::operator= (const MyString& rhs) { if (rhs.mChars != NULL) { delete[] mChars; mChars = new char [strlen (rhs.mChars)+1]; strcpy (mChars, rhs.mChars); } else { mChars = NULL; } return *this; } int main(int argc, char* argv[]) { MyString a; printf("a.mChars is %s\n",a.mChars); a=a; printf("a.mChars is %s\n",a.mChars); return 0; } 如果在上面的程序中，缺少 if(&rhs==this) return *this，则会产生指针将被释放两次，造成错误。 MLF 故障是在 C++中是非常危险的， 若在某个函数中有 MLF 故障， 则当多次运行该函数时， 由于申请的内存没有释放， 可能会造成内存空间不足而造成系统死机或异常退出。 2．数组越界故障的故障模型（ OOBF） 定义 6.2：数组越界故障：设某数组定义为 Array[min~max]，若引用 Array[i]且 i<min 或 i>max 都是数组越界故障。在 C++中，若 i<0 或 i 砿 ax 是数组越界故障。 （1）对程序中任何出现 Array[i]的地方，都要判断 i 的范围，可能有三种情况： · 若 i 是在数组定义的范围内，则是正确的； · 若 i 是在数组定义的范围外，则是 OBAF；
【例 6-10】 对下列程序结构： #define N 10 …… int data[N]; for (i = 0; i<=N; ++i) { int x = new_data(i); data[i] = foo(x); } 程序中的 data[i]就会产生越界错误。 【例 6-11】 对下列程序结构： int search_slots(int port) { int i = 0; while (++i<port) { if (slot_table[i]>port) return slot_tabe[i]; } return 0; } 除非能够确定 port 小于 slot_table[ ]的范围，否则这是一个故障。 · 若 i 是不确定的，则 Array[i]是否是 OBAF 也是不确定的； （2）字符串拷贝过程中存在的数组越界故障：字符串拷贝的一般形式为： copy(dest,source) 如果 source 的空间大小大于 dest 的空间大小，则是数组越界故障。否则，则是正确的。在 C++中，字符串拷贝的函数可能引起的故障有： 表 6.1 可能产生数组越界的函数
基于故障模型的软件测试（ １ ）
一种测试理论是否成熟的重要标志是测试对象是否有比较好的故障模型，故障模型必须满足下列几个条件： （1）该模型下的故障是符合实际的。也就是说，该模型下所定义的故障在实际工程中是大量存在的。 （2）基于该模型的故障数目是可以容忍的，一般来讲，故障个数跟系统的规模成线性关系。 （3）该模型下的故障是可以测试的。存在一个算法，该算法是可以检测这些故障的。 由于软件的复杂性和软件缺陷的复杂性，自软件测试技术诞生以来，虽然有很多科学家在软件的故障模型方面做了大量的工作，但收效甚微。这在很大程度上影响了软件测试 技术的发展与进步。进入二十一世纪以来，随着社会对软件测试技术的需求越来越大，软件的质量越来越受到重视，软件的测试理论也得到快速发展。其中之一就是软件测试 故障模型的研究取得了重要进展。目前市场上已有多个基于故障模型的软件测试系统。基于故障的测试的好处在于： （1）针对性强：如果说某种模型的故障是经常发生的，并且在被测软件中是存在的，则面向故障的测试可以检测出此类故障。而不会像白盒测试和黑盒测试那样的不确定性。 （2）有些故障一次性测试是检测不出来的，这种故障用白盒测试和黑盒测试这两种方法是检测不出来的。例如，存储器泄露故障、空指针引用故障等。 （3）可以避免对其它测试方法对“小概率”检测效率比较低的情况。 6.1 基于错误检测的故障模型 故障模型是和语言本身相关的，不同的语言有着不同的故障模型。本节以 C++和 JAVA 语言为背景来描述其故障模型。这些故障模型是从大量工程实践中总结出来的，有 很强的工程背景。 1．存储泄漏的故障模型（MLF） 定义 6.1：内存泄漏故障（Memory Leak Faults）：设在程序的某处申请了大小为 M 的空间，凡在程序结束时 M 或者 M 的一部分没被释放、或者多次释放 M 或 M 的一部分都 是内存泄漏故障。 MLF 有三种形式： · 遗漏故障：是指申请的内存没有被释放。 · 不匹配故障：是指申请函数和释放函数不匹配。 · 不相等的释放错误：是指释放的空间和申请的空间大小不一样。 在 C++中，MLF 的表现形式为： （1）在完整路径 Pi 申请内存，但在 Pi 上无任何内存释放函数，则是第 I 类 Memory leak 故障。 【例 6-1】 下列程序： 1 2 3 4 5 6 7 8 9 10 11 12 13 } 在程序的第 2 行，给变量 new_entry 分配了内存，当程序在第 8 行返回时并没有释放该内存，即是第 I 类 MLF 故障。 （2） pointer 是用 malloc 分配的变量，若存在 Pi 且在 Pi 上只存在一个 free (pointer)，则是正确的。反之，如果存在两个或两个以上 free (pointer)，或者无 free (pointer)，或者 存在一个或一个以上的 delete (pointer)，则都是 II 类 Memory leak 故障。 } new_entry->next = entry->next; entry->next = new_entry; return new_entry; listrec *add_list_entry (listrec *entry, int value) { listrec *new_entry = (listrec*) malloc (sizeof (listrec) ); if (!new_entry) { return NULL; } new_entry->value = value; if (!entry) { return NULL;
基于故障模型的软件测试（ ２ ）
【例 6-8】 下列程序： class base { public: char *p; base() { p=new char[strlen("default value")+1]; strcpy(p,"default value"s) { p=new char[strlen(s)+1]; strcpy(p,s); } ~base() { if(p) { delete[] p; p=NULL;}} }; int main(int argc, char* argv[]) { base a,b; b=a; return 0;