基于故障模型的软件测试

格式：pdf
大小：154.28 KB
文档页数：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模型的软件质量与测试过程评估分析

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种类繁多等特点，相对非嵌入式软件开发和策略有很大不同，测试更复杂。

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

０引言
软件开发平台的集成化和软件开发技术的迅猛发展使得
析，现了以系统工程方法研究安全问题的系统性、确性和体准
预测性。障树分析法是把系统不希望发生的故障状态定义故为“ 顶事件” 通过分析寻找出导致顶事件故障发生的所有可，
Ｒｅｅｒｈｏｃｎｑｅｏｆｒｅｔｇｂｓｄｏａｌｔｅｎｌｓｓｓａｃｎｔｈｉｕｆｓｔｅｏｗａｅｔｓｉａｅｎｆｕｔｒｅａａｙｉｎ
ＺＨＵｎｐｎＹｕ — ｅｇ
（ｐｒｎｆｔｏｋｎｉｅｒｇＨｆｉｌｃｏｉＥｇｎｅｎｓｔｔ，Ｈｅｉ３０７ｈｎ）ＤｅａｔｔＮｅｒｇｎｅｉ，ｅｅＥｅｔｎｃｎｉｅｒｇＩｔｕｅｍｅｏｗＥｎｒｉｎｉｆ０３，Ｃｉｅ２ａ
维普资讯第２卷第 ຫໍສະໝຸດ 期９３Ｖｏ１２９．
ＮＯ．３１
计算机工程与设计
ＣｏｐｔｒＥｎｉｅｒｎｎｓｇｍｕｅｇｎｅｉｇａｄＤｅｉｎ
２０年７０８月
Ｊｌ０８ｕｙ２０
寻找每一个中间事件发生的所有可能原因，以此类推，至追直
踪到最后一级基本事件，即“ 事件 ” 也底。故障树分析法从具体故障结果出发，以分支结构和逐层细化的方式寻找出所有的直接和间接因素，最终分析结果其采用故障树图的图形化表示方法。障树图是一种逻辑因果故

基于模型的分时段软件测试工具TPT

基于模型的分时段软件测试工具TPTTPT是针对嵌入式系统的基于模型的测试工具，特别是针对控制系统的软件功能测试。

TPT支持所有的测试过程：包括测试建模、测试执行、测试评估以及测试报告的生成。

TPT软件由于首创地使用分时段测试（Time Partition Testing），使得控制系统的软件测试技术得以极大提升；同时由于TPT软件支持众多业内主流的工具平台和测试环境，能够更好地利用客户已有的投资，实现各种异构环境下的自动化测试；针对MATLAB/Simulink/Stateflow以及TargetLink，TPT提供了全方位的支持进行模型测试。

PikeTec公司是全球知名的基于模型的嵌入式系统测试工具TPT的软件供应商，总部位于德国柏林，其创始人均在戴姆勒公司拥有十多年的嵌入式软件开发经验。

TPT产品曾被评为2005年戴姆勒最佳创新软件，并在戴姆勒、大众、奥迪、保时捷、通用等汽车整车厂及多家零部件企业（如博世、大陆、海拉）中得到广泛应用，如戴姆勒的多个车型的混合动力车的动力总成、电池管理控制器的测试，博世的汽油机和柴油机控制系统测试等。

（请登录PikeTec的TPT产品了解更多产品详情。

）北汇信息作为PikeTec的中国合作伙伴，将帮助中国客户借助TPT提升嵌入式控制系统的开发效率。

分时段测试方法分时段测试（Time Partition Testing）是一种采用分时段对软件进行测试和验证的测试方法，主要被用于嵌入式系统中基于模型的模块测试、集成测试、系统测试和回归测试。

通常软件测试的一种分类是静态测试和动态测试。

静态测试是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。

静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。

基于故障注入的汽车功能安全测试方法浅析

基于故障注入的汽车功能安全测试方法浅析摘要: 故障注入是ISO26262功能安全标准强烈推荐的一种安全测试方法，但未详细阐述。

本文结合实际测试经验，详细介绍了故障注入的测试流程，并对故障类型的确认、测试环境的选择进行详细描述，对进行功能安全故障注入测试有一定的指导意义。

关键词：功能安全、故障注入、FTTI序言随着汽车四化的快速发展，汽车的安全性也越来越重要，汽车功能安全标准ISO26262[1]制定了一套安全分析及设计方法论来降低系统性失效和随机硬件失效的风险到可接受水平，其中V模型右半部分的各个测试阶段都规定了需要采用故障注入的测试方法来验证相关项的设计是否满足安全要求，但未详细阐述具体的测试流程及方法。

1故障注入测试的定义因电子电气系统在正常运行时不能触发安全机制，为此ISO26262标准针对功能安全等级为ASIL C/D的相关项，在软件单元验证、软件集成验证、嵌入式软件测试、系统集成测试、整车安全确认测试等阶段，都强烈推荐采用故障注入测试方法来提高安全要求的测试覆盖率，此外故障注入测试还可用于故障容错时间FTTI的确定[2]。

标准中对故障注入测试的定义如下：评估要素内故障影响的方法，该方法通过注入故障、错误、或失效从而通过观测点对注入后的响应进行观测。

从定义中可以看出根据要素不同的抽象层级，根据安全分析，故障注入不一定是要注入故障异常的根本原因，可以在故障传播路径上注入错误，甚至是失效。

2 故障注入的测试流程根据故障注入测试的定义，故障注入测试的第一步是根据测试目的确定测试的对象。

比如如果是验证硬件安全机制的有效性，则需要对硬件进行测试；如果是确定安全目标的FTTI时间，则需要在安全机制未激活的情况下，对实车进行故障注入测试。

第二步是根据测试对象的安全分析报告，确定故障类型，常用的安全分析方法有FTA、FMEA、HAZOP等。

第三步是在考虑可行性及可观测性后，根据测试对象的故障类型及功能安全要求设计测试场景，并完成测试场景评审。

一种基于故障模型的代码静态测试方法研究

法。依据该算法开发自动化测试．具，出实验结果和对比分析，Ｙ－给并指出下一步的研究方向。关键词：障模型；件测试；语法树；制流图；态测试故软控静
中图分类号：Ｐ０．Ｔ３２８文献标识码：Ａｄｉ０３６／．ｓｎ１０ — ７．０１０．２ｏ：１．９９ｊｉ．０６２５２１．２０ｌｓ４
ＳｔｉｅｅｔｎｅｈｏｏｕｔＭｏｌａｔｃＤｔｃｉｇＭｔｄｆｒＦａｌｄｅ
ＸＩＹｕｈｉ，ＬＩＭｉｇＷＡＮｎＡ。ｕｎ，Ｌｉ，ＷＡＮＧｎ．ａＨｏｇｙｎ
（．ｅａｔｅｔｆｎｏｔｎＥｇｎｅｉｇｏＡｍｒｄＦｒｅｓｔｔ，ｅｉｇ１０７，ｈａ１ＤｐｒｎｏＩｆｒｉｎｉｒｒｏｅｏｃｓｎｔｕｅＢｉｎ００２Ｃｉ；ｍｍａｏｅｎｆＩｉｊｎ
２１年第２期０１
文章编号：０６２７（０）２０７－４１０ — ５２１０－０７０４１
计算机与现代化ＪＳＡＪＹＩＮＡＨＡＩＵＮＩＵＸＡＤＩＵ
总第１６期８
一
种基于故障模型的代码静态测试方法研究
ｌｓｕｓｔａｎｄｙａｃａｌｓｓＴｈｅｅｏｅ，ａｓｃ￣ｓａｉｎｌｓｓｍｅｈｄｉａｎｔｍｐｅｎｔｏｅｔｓｉｇＴｈａｒｄｉｃｓｅｓｆｓｈｎｍｉｎａｙｉ．ｒｆｒｐｅｉｔｔａａｙｉｔｏｓｔｋｅｏｉｌｍｅｄｅｔｎ．ｃｃｅｐｐｅ甲兵工程学院信息工程系，京１０７；．１装北００２２国家海洋局，京１０６）北０８０

基于软件故障注入的嵌入式系统鲁棒性测试

基于软件故障注入的嵌入式系统鲁棒性测试王立荣【摘要】To study the robustness of the evaluation of embedded systems and software-based fault injection testing of embedded systems for the purpose of robustness. Test the robustness of the embedded system and software faults related concepts were introduced into the technical principles, The Linux operating system kernel function tests, for example, parameters of the system through the API interface fault injection analysis, based on GDB tools to implement software fault injection method robustness fault injection testing. Completed a corresponding API interface, Linux operating system fault injection test cases and test results are given. To test the robustness of embedded systems to provide a more intuitive and effective way.%以研究对嵌入式系统鲁棒性进行评价和基于软件故障注入技术的嵌入式系统鲁棒性测试为目的。

对嵌入式系统鲁棒性测试的相关概念以及软件故障注入技术原理进行了介绍，以Linux操作系统内核函数测试为例，通过对系统API参数的故障注入接口进行分析，提出基于GDB工具的软件故障注入方法来实现系统鲁棒性故障注入测试。

基于模型的测试用例生成方法

计算机测量与控制．２０２１．２９（１２）　犆狅犿狆狌狋犲狉犕犲犪狊狌狉犲犿犲狀狋牔犆狅狀狋狉狅犾　·２２　·收稿日期：２０２１０６２６；　修回日期：２０２１０８０３。

作者简介：蒲卿路（１９９６），男，四川成都人，硕士，主要从事软件测试与测试开发方向的研究。

引用格式：蒲卿路，王月波，刘　涛，等．基于模型的测试用例生成方法［Ｊ］．计算机测量与控制，２０２１，２９（１２）：２２２６，３２．文章编号：１６７１４５９８（２０２１）１２００２２０５ＤＯＩ：１０．１６５２６／ｊ．ｃｎｋｉ．１１－４７６２／ｔｐ．２０２１．１２．００５中图分类号：ＴＰ３１９文献标识码：Ａ基于模型的测试用例生成方法蒲卿路，王月波，刘　涛，孙　云，李继秀（西南电子技术研究所，成都　６１００３６）摘要：在大量软件出现的今天，除开软件的功能是否完善外，对软件本身提出了更高的安全性和稳定性要求；一款软件在上线前需要进行大量的测试，以便提升软件的质量；由于开发人员参与了软件的研发及上线流程，导致了看待软件问题的局限性，而测试人员在编写测试用例时，往往由于依据文档的不一致性，使得测试用例的价值大打折扣；并且在实际软件的开发流程中，测试环节与开发严重脱节；往往只是为了出相应的测试报告而去测试，偏离了测试的初衷；针对以上问题，提出基于模型的用例生成方法，能够基于工作流程图、判定表、状态转换等多种测试方法，并在该方法中应用边界值与等价类的思想，够贯穿整个软件研发的生命周期，在软件研发初期就能够参与测试，提出设计方案的不足；并且能够自动生成测试用例，提高测试人员的效率。

关键词：模型测试；边界值与等价类；工作流；判定表；状态转换图犝狊犲犆犪狊犲犌犲狀犲狉犪狋犻狅狀犕犲狋犺狅犱犅犪狊犲犱狅狀犕狅犱犲犾犜犲狊狋犻狀犵ＰＵＱｉｎｇｌｕ，ＷＡＮＧＹｕｅｂｏ，ＬＩＵＴａｏ，ＳＵＮＹｕｎ，ＬＩＪｉｘｉｕ（ＳｏｕｔｈｗｅｓｔＣｈｉｎａＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｏｎｉｃＴｅｃｈｎｏｌｏｇｙ，Ｃｈｅｎｇｄｕ　６１００３６，Ｃｈｉｎａ）犃犫狊狋狉犪犮狋：Ｗｉｔｈｔｈｅｅｍｅｒｇｅｎｃｅｏｆａｌａｒｇｅｎｕｍｂｅｒｏｆｓｏｆｔｗａｒｅ，ｉｎａｄｄｉｔｉｏｎｔｏｗｈｅｔｈｅｒｔｈｅｆｕｎｃｔｉｏｎｓｏｆｔｈｅｓｏｆｔｗａｒｅａｒｅｐｅｒｆｅｃｔ，ｈｉｇｈｅｒｓｅｃｕｒｉｔｙａｎｄｓｔａｂｉｌｉｔｙｒｅｑｕｉｒｅｍｅｎｔｓａｒｅｐｕｔｆｏｒｗａｒｄｔｏｔｈｅｓｏｆｔｗａｒｅｉｔｓｅｌｆ．Ａｐｉｅｃｅｏｆｓｏｆｔｗａｒｅｎｅｅｄｓｔｏｂｅｔｅｓｔｅｄａｌｏｔｂｅｆｏｒｅｉｔｇｏｅｓｌｉｖｅｉｎｏｒｄｅｒｔｏｉｍｐｒｏｖｅｔｈｅｑｕａｌｉｔｙｏｆｔｈｅｓｏｆｔｗａｒｅ．Ａｓｄｅｖｅｌｏｐｅｒｓｐａｒｔｉｃｉｐａｔｅｉｎｔｈｅｓｏｆｔｗａｒｅｄｅｖｅｌｏｐｍｅｎｔａｎｄｏｎｌｉｎｅｐｒｏｃｅｓｓ，ｉｔｌｅａｄｓｔｏｌｉｍｉｔａｔｉｏｎｓｉｎｖｉｅｗｉｎｇｓｏｆｔｗａｒｅｉｓｓｕｅｓ．Ｗｈｅｎｔｅｓｔｅｒｓｗｒｉｔｅｔｅｓｔｃａｓｅｓ，ｔｈｅｖａｌｕｅｏｆｔｅｓｔｃａｓｅｓｉｓｏｆｔｅｎｃｏｍｐｒｏｍｉｓｅｄｄｕｅｔｏｔｈｅｉｎｃｏｎｓｉｓｔｅｎｃｙｏｆｔｈｅｂａｓｉｓｄｏｃｕｍｅｎｔｓ．Ａｎｄｉｎｔｈｅａｃｔｕａｌｓｏｆｔｗａｒｅｄｅｖｅｌｏｐｍｅｎｔｐｒｏｃｅｓｓ，ｔｈｅｔｅｓｔｌｉｎｋｉｓｓｅｒｉｏｕｓｌｙｏｕｔｏｆｔｏｕｃｈｗｉｔｈｔｈｅｄｅｖｅｌｏｐｍｅｎｔ．Ｉｔｉｓｏｆｔｅｎｊｕｓｔｔｏｔｅｓｔｆｏｒｔｈｅｃｏｒｒｅｓｐｏｎｄｉｎｇｔｅｓｔｒｅｐｏｒｔ，ｗｈｉｃｈｄｅｖｉａｔｅｓｆｒｏｍｔｈｅｏｒｉｇｉｎａｌｉｎｔｅｎｔｉｏｎｏｆｔｈｅｔｅｓｔ．Ｉｎｒｅｓｐｏｎｓｅｔｏｔｈｅａｂｏｖｅｐｒｏｂｌｅｍｓ，ｔｈｅｍｏｄｅｌ－ｂａｓｅｄｕｓｅｃａｓｅｇｅｎｅｒａｔｉｏｎｍｅｔｈｏｄｐｒｏｐｏｓｅｄｉｎｔｈｉｓａｒｔｉｃｌｅｃａｎｂｅｂａｓｅｄｏｎａｖａｒｉｅｔｙｏｆｔｅｓｔｍｅｔｈｏｄｓｓｕｃｈａｓｗｏｒｋｆｌｏｗｃｈａｒｔｓ，ｄｅｃｉｓｉｏｎｔａｂｌｅｓ，ａｎｄｓｔａｔｅｔｒａｎｓｉｔｉｏｎｓ，ａｎｄｔｈｅｉｄｅａｏｆｂｏｕｎｄａｒｙｖａｌｕｅｓａｎｄｅｑｕｉｖａｌｅｎｃｅｃｌａｓｓｅｓｉｓａｐｐｌｉｅｄｉｎｔｈｉｓｍｅｔｈｏｄ，ｗｈｉｃｈｃａｎｒｕｎｔｈｒｏｕｇｈｔｈｅｅｎｔｉｒｅｓｏｆｔｗａｒｅＲ＆Ｄｌｉｆｅｃｙｃｌｅ，ｙｏｕｃａｎｐａｒｔｉｃｉｐａｔｅｉｎｔｅｓｔｉｎｇａｔｔｈｅｅａｒｌｙｓｔａｇｅｏｆｓｏｆｔｗａｒｅＲ＆Ｄ，ａｎｄｐｒｏｐｏｓｅｄｅｆｉｃｉｅｎｃｉｅｓｉｎｔｈｅｄｅｓｉｇｎｐｌａｎ．Ａｎｄｃａｎａｕｔｏｍａｔｉｃａｌｌｙｇｅｎｅｒａｔｅｔｅｓｔｃａｓｅｓｔｏｉｍｐｒｏｖｅｔｈｅｅｆｆｉｃｉｅｎｃｙｏｆｔｅｓｔｅｒｓ．犓犲狔狑狅狉犱狊：ｍｏｄｅｌｔｅｓｔｉｎｇ；ｂｏｕｎｄａｒｙｖａｌｕｅａｎｄｅｑｕｉｖａｌｅｎｃｅｃｌａｓｓ；ｗｏｒｋｆｌｏｗ；ｄｅｃｉｓｉｏｎｔａｂｌｅ；ｓｔａｔｅｔｒａｎｓｉｔｉｏｎｄｉａｇｒａｍ０　引言目前，随着科技的进步，软件的发展。

使用故障注入技术测试软件可靠性

使用故障注入技术测试软件可靠性在软件开发过程中，保证软件的可靠性是一个至关重要的任务。

为了确保软件在各种情况下都能正常运行，开发人员需要进行全面而严格的测试。

故障注入技术是一种有效的测试方法，可帮助发现并解决软件中的缺陷。

本文将探讨故障注入技术的原理、步骤和应用，并分析其在测试软件可靠性方面的优势和限制。

一、故障注入技术简介故障注入技术是一种通过人工方式向软件中注入故障的方法，以验证软件对异常情况的响应能力。

通过在软件中插入故障，可以模拟现实环境中可能发生的错误或故障，从而评估软件的可靠性和鲁棒性。

二、故障注入技术的步骤故障注入技术通常包含以下几个步骤：1. 故障模型定义：首先，需要定义一组故障模型，即确定要注入的故障类型。

常见的故障类型包括输入错误、资源耗尽、内存泄漏等。

2. 故障注入点选择：根据软件的结构和功能，选择注入故障的合适位置。

这些位置应该是可能引发软件故障的关键点，例如参数输入、数据传输和算法处理等。

3. 故障注入方法选择：根据故障模型的定义，选择合适的故障注入方法。

常用的方法包括修改参数值、模拟资源耗尽和模拟网络延迟等。

4. 故障影响评估：在注入故障后，评估软件的响应和恢复能力。

通过分析软件的输出、日志和错误报告，确定故障的影响范围和持续时间。

5. 故障修复和验证：在评估故障影响后，开发人员需要修复发现的故障，并进行验证。

修复过程通常包括代码修改、逻辑重构和性能优化等。

三、故障注入技术的应用故障注入技术可以广泛应用于软件开发的各个阶段，包括需求分析、设计、编码和测试等。

它可以帮助开发人员发现和解决软件中的潜在缺陷，并改进软件的可靠性和鲁棒性。

1. 需求分析阶段：通过注入故障，可以验证软件是否满足了各种异常情况下的需求。

例如，在电子商务网站的需求分析中，可以注入网络连接异常、订单处理错误等故障，以测试系统对这些情况的处理能力。

2. 设计阶段：在设计软件架构和模块时，可以通过故障注入技术评估设计的健壮性。

软件功能性测试21种故障模型

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

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

把这些测试人员的经历和直觉尽量归纳和固化，就形成了一些故障模型。

故障模型指明了故障是如何以及为什么会在软件执行时引起软件失效。

在测试过程中，我们可以按照这些故障模型所提供的缺陷类型和寻找该类缺陷的方法找到尽量多的缺陷。

---------------------------------------------------------------------------------------------------1、输入非法数据1.1 缺陷产生原因开发人员通常用以下3种技术来处理非法输入：◆防止不正确的输入进入被测软件。

过滤掉不正确的输入，只允许合法输入通过界面。

◆输入了不正确的数据后，软件提示错误信息，拒绝不正确的输入。

◆允许不正确的输入进入系统并进展处理，软件失效时调用异常处理程序，显示一些错误信息。

可见开发人员除了编写主要的功能代码外，还必须编写对非法输入的检查代码，这些代码经常被遗忘，或者编写完这局部代码后，开发人员很少认真检查，导致处理非法输入经常出错。

1.2 如何发现这类问题进展测试时从输入值的属性出发，一般考虑以下三点：◆输入类型：键入无效的类型常会产生错误信息。

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

◆边界值：输入边界值或超过边界值的数据。

1.3 测试方法小结◆应用场合：GUI的输入。

◆测试方法：分别从输入数据的类型、长度、边界值等方面进展考虑。

◆测试信息检查：●错误信息和错误要一致。

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

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

软件测试中的故障注入与压力测试

软件测试中的故障注入与压力测试软件测试是确保软件质量和可靠性的关键环节之一。

在测试过程中，故障注入和压力测试是常用的方法。

本文将介绍故障注入和压力测试的概念、目的、方法以及应用场景。

一、故障注入故障注入是一种在软件开发过程中故意引入错误的测试方法。

其目的是评估软件系统在出现故障时的表现和可靠性。

故障注入的主要步骤包括：1. 错误模型定义：根据软件系统的特点和需求，定义适合的错误模型，如内存泄漏、逻辑错误等。

2. 错误注入技术：通过编程技术或工具，在软件系统中故意引入错误，如修改代码、插入错误处理逻辑等。

3. 故障检测与恢复：在系统测试阶段，通过监控和记录系统的运行情况，及时发现故障并进行恢复。

故障注入能够帮助开发人员评估软件系统的强健性和可靠性。

通过在早期引入错误，可以及时发现和解决潜在的问题，提升系统的稳定性和性能。

二、压力测试压力测试是一种测试方法，通过在软件系统中模拟高并发、大数据量等情况，评估系统在压力下的性能和可靠性。

压力测试的主要目的是确定系统的瓶颈和性能极限，并提供相关数据给开发人员优化系统。

压力测试的基本流程如下：1. 场景设计：根据系统的使用情况和运行环境，设计适合的场景，包括并发用户数、请求模式等。

2. 测试执行：通过自动化工具或脚本，模拟并发用户发送请求，监测系统的响应速度、吞吐量等性能指标。

3. 数据分析：根据测试结果，分析系统的性能表现，找出瓶颈和性能问题，并给出优化建议。

压力测试可以帮助开发人员了解系统在高负载情况下的表现，提前发现和解决性能问题，确保软件系统在使用过程中的可靠性和稳定性。

三、故障注入与压力测试的应用场景1. 软件开发过程中：在软件开发过程中，通过故障注入和压力测试，可以提前发现系统的潜在问题，降低后期维护成本。

2. 系统上线前：在系统上线前进行故障注入和压力测试，可以评估系统在真实环境中的性能表现，并发现和解决潜在的问题。

3. 系统升级或扩展：当系统进行升级或扩展时，通过故障注入和压力测试，可以评估系统是否能够满足新的需求，并检测系统的性能瓶颈。

基于故障模型的软件测试

【例 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 可能产生数组越界的函数
void setp(char *s) { if(p!=NULL) delete []p; p=new char[strlen(s)+1]; strcpy(p,s); } ~base() { if(p) { delete[] p; p=NULL; }}
}; class derive: public base { public: derive() {} derive(derive &a) printf("derive copy constructor is calling\n"); }; int main(int argc, char* argv[]) { derive c; c.setp("this is c")பைடு நூலகம் derive b(c); printf("c : %s\n",c.p); printf("b : %s\n",b.p); return 0; } 由于在主程序中有语句 b=c，如果缺少拷贝构造函数 base(base& a)，则当程序执行析构函数时，对指针*p 就执行了两次释放操作，可能会造成死机。（8）如果在构造函数中有申请内存的操作，且在其它程序中有两个对象直接或间接的赋值操作，如果没有对“=”运算符进行重载定义，则会产生两次释放同一个内存操作错误。该类错误称为第 VIII 类 Memory leak 故障。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
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;

基于故障模型的软件测试

合集下载

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

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

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

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

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

软件测试过程与测试模型

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

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

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

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

基于模型的分时段软件测试工具TPT

基于故障注入的汽车功能安全测试方法浅析

一种基于故障模型的代码静态测试方法研究

基于软件故障注入的嵌入式系统鲁棒性测试

基于模型的测试用例生成方法

使用故障注入技术测试软件可靠性

软件功能性测试21种故障模型

软件测试中的故障注入与压力测试

基于故障模型的软件测试

文档推荐

最新文档