测试模型（精选11篇）
测试模型 篇1
0 引言
软件测试在软件开发中占有非常重要的位置。然而为缩短产品的开发周期,各商家又不得不从测试环节中节省时间。所以如何在确保软件质量的前提下缩短测试周期便成了各测试领域专家研究的重点。
随着UML 2.0 Testing Profile的发布,模型驱动测试作为一种全新的测试思想已由前期的理论探索论证转入了发展与实践阶段。模型驱动测试就是通过对SUT的功能与系统结构进行分析,然后结合测试策略构建起全面、清晰的测试模型,最后通过测试模型自动生成测试用例驱动测试人员完成SUT的测试。模型驱动测试的优点主要有两方面:
(1)测试模型为用户提供了更加清晰、准确和系统地测试设计;
(2)减少了测试用例的维护工作,实现了测试资源的重利用,有效缩短了测试周期。
1 基于模型驱动的测试架构
1.1 测试架构
MDT-TA(Model Drive Testing Testing Architecture)的系统结构如图一所示,该系统将所有模块分成三层。
(1)模型处理层---核心层
该层是整个测试架构中的核心层。在本层中提供可视化的建模工具来支持系统设计建模和测试设计建模。当系统模型设计完成后,“模型转换器”就可以根据模型转换算法自动将系统模型转换成测试模型。
(2)测试用例抽象层
为了增加本测试架构的扩展性,在本测试架构中提炼出了测试用例抽象层。该层根据已建立的测试模型和测试策略,自动生成测试逻辑和测试数据池,而不直接生成具体的测试用例脚本。具体的实现与执行将由测试人员根据系统的要求在第三层的用例实现与执行层进行适配。
(3)测试用例实现与执行层
有了测试逻辑和测试数据后,系统就可以根据SUT的特性选用一种最合适的测试语言生成具体的测试脚本实施测试。本层的功能就是用测试数据实例化测试逻辑从而形成测试用例,然后生成测试脚本。
1.2 模型自动转换技术
在文献[2]中描述“软件的测试内容与方法由被测系统决定”,文献[3]中则称“测试模型与系统设计模型之间有一种天然的联系”,由此可见测试设计模型与系统设计模型之间存在着一种强关联。本文的模型转换技术就是通过解析系统设计模型与测试设计模型之间的关联关系来实现从UML模型到U2TP模型的自动转换。图二展示了设计模型与测试活动的对应关系。
在UML建模语言中,用例是用来描述业务功能的,它的执行有明确的前因和后果事件,一般由几个有序的步骤来完成。由用例组合而成的用例图明确地划定了系统所能提供的服务(即系统功能),而系统序列图(用例描述中步骤的体现)则清晰地描述出了每一个功能的详细操作步骤和激励。本文的模型转换技术就是通过分析用例图和系统序列图来构建系统测试模型,其构建过程如图三所示。
生成测试系统模型的过程如下:
(1)根据用例图分析出所有的参与者;
(2)根据用例描述图分析出参与者的活动和系统活动;
(3)根据参与者活动和系统活动的基本流程和备选流程生成系统测试模型。
下面通过ATM系统的实现用例来演示模型转换技术,图四和表一分别为ATM机系统的用例图和用例描述表。
模型转换器通过扫描分析系统设计模型的MOF文件,得到当前系统的参与者和系统活动。然后将系统活动集转换成测试模型中的状态图,同时将参与者的活动转换成激励,每一状态迁移时输出的信息作为测试结果仲裁的输入。基于用例图自动生成的ATM系统测试模型如图五所示。在生成的测试模型中存在两个激励和三个观察点,通过对激励点的不同组合就可以完成对ATM系统查询功能的系统测试。
1.3 测试逻辑自动生成技术
为了实现与平台无关和提高系统的可扩展性,本文提出了“测试逻辑”的概念,其定义如下:
(1)有特定的测试目的且在当前测试中是唯一的;
(2)不含测试数据;
(3)是一系列有序的测试步骤集合。
测试模型生成测试逻辑的过程可以根据测试策略选用不同的算法来实现。本文结合深度优先算法和广度优先算法,从测试模型状态图的初始状态开始遍历,将遍历过程中产生的每一条完整的状态转换路径都记录下来,这样每一条完整的路径就是一个测试逻辑。算法描述如下:
第一步:检查出当前状态图的所有回路并在相应的节点做上标记;
第二步:采用深度优先算法打上一级步骤编号;
第三步:采用广度优先算法打上二级步骤编号;
第四步:根据编号生成测试逻辑。
1.4 测试数据自动生成技术
测试数据的好坏直接决定了测试用例的质量。测试数据如果过多,则会加重对测试资源的消耗(包括人力资源);如果过少,又有可能导致覆盖不全面,容易造成漏测。本文的测试数据自动生成技术是针对系统测试用例而提出的,所以它只关注激励数据而不关注程序实现本身。算法描述如下:
第一步:获取测试模型中的所有激励(即标识为“IN”的变量)与约束,约束即密码不能为空且为6位数字,不能以0开头。
第二步:根据激励的合法性约束划分出有效等价类和无效等价类的边界,如表二所示。
第三步(可选):如果激励的约束中确定了值的范围、个数或者先后顺序,则标识该激励的边界值,如表三所示。
第四步:根据Pair Wise算法,生成有效等价类解集和无效等价类解集。在生成的测试数据中,根据测试策略中的权值表(该表从XML模板文件中读取,表中的权值因测试的目的不同而判定每一级的条件不同。例如在性能测试策略中,靠近阀值或极限值的数据优先级别为最高;而在基本功能测试中,为上点、离点或内点的数据的优先级要高于阀值)设定每一个测试数据的优先级,如表四所示。
2 结论与展望
目前基于MDT-TA指导开发的全流程测试管理与执行工具Test Studio已进入用户体验阶段。从用户反馈的结果看,一方面证实了本架构在实现测试前移、缩短开发周期和降低维护成本的优势;另一方面也暴露出了本架构的不足之处:
(1)只能证实,不能证伪。如果系统设计模型错误,则测试模型无法自动检测出系统设计模型的错误。
(2)当前的UML语义还不足以完全地支撑测试模型中需要的信息。
(3)生成的U2TP测试模型可以非常方便地生成TTCN测试用例,但JAVA、C++语言的支持不够。U2TP模型中的部份概念无法直接转换成对应的JAVA或C++代码。
因此,下一步需要研究的重点主要是下面几个方向:
(1)研究测试设计模型的自动测试技术;
(2)扩展UML和U2TP语义,使其满足测试建模的需要;
(3)研究将状态图、类图生成测试模型的算法,使当前的测试模型不仅仅覆盖系统测试,而且还可以覆盖集成测试和单元测试;
(4)扩展测试逻辑和测试数据自动生成算法。
参考文献
[1]林宏,曾一.基于UML的面向对象软件测试框架[J].重庆大学学报,2003,26(28).
测试模型 篇2
Information Systems Penetration Testing Principle And
Model Analysis
姜志坤
摘 要：信息化是当今世界发展的大趋势，是推动经济社会变革的重要力量。大力推进信息化，是覆盖我国现代化建设全局的战略举措，是贯彻落实科学发展观，全面建设小康社会、构建社会主义和谐社会和建设创新型国家的迫切需要和必然选择。如何以信息化提升综合国力，如何在信息化快速发展的同时确保国家信息安全，这已经成为各国政府关心的热点问题。信息安全已经从国家政治、经济、军事、文化等领域普及到社会团体、企业，直到普通百姓，信息安全已经成为维护国家安全和社会稳定的一个重要因素。随着国家信息安全测评工作的推进和深化，对信息系统安全测试的要求也逐步提高，渗透测试作为信息系统安全测试的一项高级别和高难度的测试项目，在信息安全测评中逐渐受到高度重视并得到推广应用。本文通过对目前渗透测试的过程和原理做了详细的分析, 并提出了测试方法和测试模型。
关键字：信息安全 渗透测试 测试项目 测试模型
1.渗透测试概述
作为网络安全防范的一种新技术，对于网络安全组织具有实际应用价值。但要找到一家合适的具有授权资质的公司实施渗透测试并不容易。
近来防御黑客与病毒的攻击已经成为一种非常困难的工作。保护自己的信息系统不受恶意攻击者的破坏，维护系统安全已经成了企业里非常重要的工作。以金融业为例，某银行部署了多台防火墙，购买入侵检测系统、网络安全审计系统等，也定期进行漏洞扫描，应该很安全，但黑客入侵、储户数据遭窃、网站遭受攻击等安全事件仍层出不穷，也许被黑客入侵的机率只有0.001%，但发生后就是100%。
（一）渗透测试（Penetration Testing）网络定义
定义一：渗透测试是一个在评估目标主机和网络的安全性时模仿黑客特定攻击行为的过程。详细地说，是指安全工程师尽可能完整地模拟黑客使用的漏洞发现技术和攻击手段，对目标的安全性作深入的探测，发现系统最脆弱环节的过程。
全的认知程度，使所有成员意识到自己的岗位在整个组织的安全中不可或缺的地位，有助于整体安全意识的提升。
（六）渗透测试的作用
渗透测试的作用一方面在于，解释所用测试设备在测试过程中所得到的结果。即使您对信息系统进行漏洞扫描。但也并不能全面地了解漏洞扫描得到的结果，更别提另外进行测试，并证实漏洞扫描系统所得报告的准确性了。
（七）怎么进行渗透测试
除了找到合适工具以及具备资质的组织进行渗透测试外，还应该准确确定测试范围。攻击者会借助社会工程学、偷窃、贿赂或者破门而入等手法，获得有关信息。真正的攻击者是不会仅仅满足于攻击某个企业网络的。通过该网络再攻击其它公司往往是黑客的惯用伎俩。攻击者甚至会通过这种方法进入企业的ISP。
为了从渗透测试上获得最大价值，应该向测试组织提供尽可能详细的信息。同时签署保密协议，这样，您就可以更放心地共享策略、程序及有关网络的其它关键信息。
还要确定被测信息系统，哪些系统需要测试。虽然你不想漏掉可能会受到攻击的某个系统，但可能仍想分阶段把渗透测试外包出去，以便每个阶段专注于网络的不同部分；同样您也可以作为一个大的信息系统来测试，对各个子系统进行关联分析，从而有效地降低系统被攻破的风险。
2.渗透测试原理 2.1 渗透测试原理
渗透测试就是利用网络安全扫描器、专用安全测试工具和富有经验的安全工程师的人工经验对网络中的核心服务器及重要的网络设备，包括服务器、网络设备、防火墙等进行非破坏性质的模拟黑客攻击，侵入系统并获取机密信息并将入侵的过程和细节产生报告给用户。
2.2 渗透测试过程
在一个实际的渗透测试过程中，渗透测试项目的实施一般分为三个阶段：前期准备阶段、渗透测试阶段、后期总结阶段。
（一）前期准备阶段 1）委托书确认
签署授权委托书，并同意测试工程师实施渗透测试。
3.渗透测试分类及方法 3.1测试分类
（一）按信息获取方式分类
从渗透的前期资料准备和信息获得来看，渗透测试/攻击可分为以下3类。1）黑盒（Black Box）渗透
黑盒（Black Box）渗透测试通常是从目标网络的外部进行渗透模拟的，这意味着，除了被测试目标的已知公开信息外，不提供任何其他信息。渗透者完全处于对目标网络系统一无所知的状态，只能通过Web、E-mail等网络对外公开提供的各种服务器，进行扫描探测，从而获得公开的信息，以决定渗透的方案与步骤。
通常来说，黑盒渗透测试用于模拟来自网络外部的攻击行为。2）白盒（White Box）渗透
白盒（White Box）渗透测试与黑盒渗透测试相反，渗透测试者可以通过正常渠道，向请求测试的机构获得目标网络系统的各种资料，包括网络拓扑结构、用户账号、操作系统、服务器类型、网络设备、代码片断等信息。
渗透者可从目标网络系统外部或内部两个地点，进行渗透模拟测试，但是通常而言，这类测试是模拟网络内部人员的越权操作。
3）灰盒（Gray Box）渗透
灰盒（Gray Box）渗透测试介于以上两者之间。
（二）按目标对象分类
从渗透模拟攻击的对象来看，渗透测试又可分为以下几种。1）主机操作系统渗透
对目标网络中的Windows、Linux、UNIX等不同操作系统主机进行渗透测试。本书重点讲述的是对Windows主机操作系统的渗透。
2）数据库系统渗透
对MS-SQL、Oracle、MySQL等数据库系统进行渗透测试，这通常是对网站的入侵渗透过程而言的。
3）网站程序渗透
渗透的目标网络系统都对外提供了Web网页、E-mail邮箱等网络程序应用服务，这是渗透者打开内部渗透通道的重要途径。
1）相关边缘信息收集
在这一步骤中，攻击者会通过网络搜索、实地了解等各种方法，充分地利用网络搜索和社会工程学，采集攻击目标的相关信息。
获取的信息内容和方式包括目标网络系统中的一些边缘信息，如目标网络系统公司的结构、各部门职能、重要机构分支，以及内部员工账号组成、身份识别方式、邮件联系地址、QQ或MSN号码、各种社交网络账号与信息、管理员的网络习惯等。
2）网络信息收集
在这一步骤中，要收集目标网络的各种网络信息，所使用的手段包括Google Hacking、WHOIS查询、DNS域名查询和网络扫描器等。
最终的目的是要描绘出目标网络拓朴结构、公司网络所在区域，子公司IP地址分布，VPN接入地址、各种重要服务器的分布、网络连接设备等信息。
3）端口/服务信息收集
在这一步骤中，利用各种通用的端口服务扫描工具，扫描目标网络中对外提供服务的服务器，查询服务器上开放的各种服务，例如，Web、FTP、MySQL、SNMP等服务。
4）漏洞扫描
在上面的步骤中，获得目标网络各服务器开放的服务之后，即可对这些服务进行重点扫描，扫出其所存在的漏洞。
例如：针对操作系统漏洞扫描的工具有X-Scan、ISS、Nessus、SSS、Retina等；针对Web网页服务的扫描工具有SQL扫描器、文件PHP包含扫描器、上传漏洞扫描工具，以及各种专业全面的扫描系统，如AppScan、Acunetix Web Vulnerability Scanner等（见图3-1）；针对数据库的扫描工具有Shadow Database Scanner、NGSSQuirreL，以及SQL空口令扫描器等。
另外，许多入侵者或渗透测试员也有自己的专用扫描器，其使用更加个性化。
（三）纵向提升权限
通过上面的步骤，攻击者可能已成功入侵目标网络系统对外的服务器，或者内部某台主机，此时需要完全获得主机的最高控制权。
虽然此时攻击者已获得了主机的一些控制权限，但是对于进一步的渗透攻击来说还是不够。例如，攻击者入侵了某台Web服务器，上传了Webshell控制网站服务器，然而却没有足够的权限安装各种木马后门，或者运行一些系统命令，此时攻击者就需要提升自己的权限。
纵向权限提升按入侵方式来分，主要可分为以下两类。1）Webshell提权
Webshell提权是渗透入侵中经常遇到的一种情况，攻击者常常会通过Web网站脚本途径入侵网站服务器，并上传Webshell。通过Webshell对主机进行操作时获得的控制权限往往是继承了Web账号权限的，完全不足以对目标主机进行系统级的控制操作。因此攻击者常常会采用各种手段，提升Webshell的操作权限。
2）账号提权
账在权限提升过程中，攻击者通过扫描或密码破解等方式，可能会获取目标主机的系统登录账号，或数据库访问账号等。不过这些账号通常是权限不足，在进行进一步的渗透测试时，可能会没有足够的权限打开一些密码存储文件，无权安装嗅探工具，甚至没有权限执行一些很基本的命令，这时必须进行提权，以获取更高级别的账号控制权。
在进行纵向提权操作步骤中，所采用的提权手段是相似的，都是利用目标主机系统上的系统或软件漏洞进行提权。具体的提权手段包括系统或软件的本地溢出攻击、密码破解、服务替换等，这在Webshell提权中体现得尤为明显。
需要说明的是，如果攻击者采用远程溢出，或者通过木马诈骗运行等方式入侵控制主机，获得的将是最高的系统权限，此时无须进行纵向提权的步骤。
（四）开辟连接通道，突破内网环境限制
在对内网进行渗透入侵之前，攻击者还需要突破各种网络环境限制，例如，内部网络作为Vlan划分隔离，或者在网关设置了防火墙无法进行连接等。
其中最重要的一点就是，如何利用已控制的主机，连接攻击其他内部主机。由于目标网络内的主机是无法直接进行连接的，因此攻击者往往会使用代理反弹连接到外部主机，会将已入侵的主机作为跳板，利用远程终端进行连接入侵控制。
在此过程中，涉及的攻击手段更加多样，如防火墙杀毒软件的突破、代理的建立、账号后门的隐藏破解、3389远程终端的开启和连接等。
图4-1 渗透测试模型
4.2 模型分析
渗透测试模型从信息收集到结果报告的生成过程是全自动的，无人干预，在此过程中，信息收集的结果筛选和各模块之间的参数传递是一个实现上的难题；另外，漏洞及漏洞利用程序的及时更新也是渗透测试软件的一个关键技术。
（一）信息收集的结果筛选和各模块之间的参数传递
参考文献
浅析软件测试中故障模型的建立 篇3
关键词：测试用例；故障模型；软件测试
中图分类号：TP311 文献标识码：A文章编号：1009-3044(2007)11-21632-02
Analysis of software testing based on fault model
YUAN Min,WANG Zhi-gang,LI Qiong
(College of Math and Computer Science, Hunan Normal University, Changsha 410081,China)
Abstract:With the high development of software,software testing becomes more and more important, There are many types of software faults with very high flexibility in software testing ,so the design for test case becomes most important. In this thesis,it aims at the indeterminacy of software test case,through at the building of fault model, makes use of the principle of FTA,designs test case for fault model adjudging software.
Key words:Software Testing;Fault Model;Test Case
1 软件测试
计算机的广泛应用,软件的复杂性和规模的不断扩大,使计算机软件质量问题日益受到关注。软件测试是提高软件质量的有效手段之一, 软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误。在软件测试过程中最关键的环节是软件测试用例的设计[1]。
测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例
确定测试用例之所以很重要，原因有以下几方面。
(1)测试用例构成了设计和制定测试过程的基础;
(2)测试的“深度”与测试用例的数量成正比。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程也就越有信心。
判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和执行的测试用例的数量为依据的;
(3)测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排;
(4)测试设计和开发的类型以及所需的资源主要都受控于测试用例。
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例:一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错的提示文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、邏辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。
能发现到目前为止没有发现的缺陷的用例是好的用例；
作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。
测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
测试的目的是尽可能发现程序中存在的缺陷，需要在 给定的资源条件下尽可能达成目标，因此必须在测试计划阶段明确测试的目 标，一切围绕测试的目标进行。
除了资源上的约束外，测试用例的详细程度也需要根据需要确定。
测试用例不应该包含实际的数据；
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。测试用例中包含输入数据会带来维护、与测试环境同步之类的问题。
测试用例中不需要明显的验证手段；
很多测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统提示“订货成功”， 显然不是一个完整的用例，系统输出的“订货成功”就并不一定作为唯一的验证手段。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。
2 故障模型的建立
从大体方面来说，软件错误主要有五类，即疏忽错误、运行错误、清晰（或模糊）错误、速度错误和能力错误。不同的软件测试方法针对不同类型的错误，其查错效率不同。经验正，发现运行错误比发现忽略错误有效得多。具体来说，如果从软件错误性质的角度来划分软件错误的类型，主要有软件结构错误、数据错误、软件实现和编码错误、软件集成错误、软件系统结构错误和测试定义与测试执行错误[2]。对科学计算程序而言，最重要的是结构错误和数据错误。
软件测试可以看作是对错误空间的搜索，即要在数以百万计甚至更多的输入及其状态组合中，尽可能寻找更多的错误的状态及其组合。如果要确保每一个目标组合都被测试，那么测试必须是系统的；而且最终要定位错误，所以测试必须是集中的；最后因为测试需要使用大量的测试用例和大量的重复性测试，用人工测试几乎难以胜任，因此测试又是自动的。要满足上述三个测试条件必须建立故障模型[3]。
故障模型是测试的基础,也是一个测试方法成熟的重要标志。软件的错误表现为2个方面：（1）计算结果错误；（2）系统“死机”。导致第1类错误的故障相对来说是比较容易检测的。导致系统死机的故障其后果是严重的，这类故障由于一般其检测概率较小，也往往难以检测。死循环故障是最常见的能引起系统死机的故障，但这种故障由于其复杂性难以对其模型化，同时在许多情况下,死循环故障也比较容易暴露。对C++中几种能导致系统死机的典型故障进行了分析，这种故障的检测其意义重大,将这些典型的故障组合在一起，就构成了面向软件系统死机故障的故障模型。
故障模型是和语言本身相关的，不同的语言有着不同的故障模型。下面几种基于错误检测的故障模型是以JAVA和C++语言环境为背景。是软件中实实在在存在的故障，一旦这种故障发生，必能导致该软件发生错误，此类故障是应该尽量避免的[4]。
（1）数组越界故障的故障模型（OOBF）：设某数组定义为Array[min-max],若引用Array[i]且I
（2）存储泄漏故障模型（MLF）：设在程序的某处申请了大小为M的空间，凡在程序结束时M或者M的一部分没有被释放，或者多次释放M或M的一部分都是内存泄漏故障。MLF有3种形式（遗漏故障，不匹配故障，不相等的释放错误）使用未初始化变量故障模型（UVF）：存在一个路径，在该路经上使用前没有被赋初值的变量是使用未初始化变量故障。
（3）非法类型转换故障（long to short ,float to integer）：凡是类型转换可能导致错误的计算都是非法类型转换故障
（4）死码故障（DCF）：凡是程序中存在但没有任何用途的代码称为死码故障
（5）空指针使用故障（NPDF）：引用空指针或给空指针赋值的都是空指针使用故障
（6）资源泄漏故障（RLF）：在Java语言中，凡不能保证资源完全回收的计算都是资源泄漏故障，分为四种情况，简单泄漏；异常泄漏；交叉函数的情况和“静态”情况
（7）数据溢出故障（DOF）：凡是可能导致数据溢出的计算都是数据溢出故障
（8）非法计算类故障（ILCF）：指计算机不允许的计算
在软件中还存在另外一类故障，称之为安全漏洞，由于此类漏洞的存在，可能为人为攻击提供方便，一旦攻击成功，系统可能发生瘫痪，所造成的危害性更大，这种基于全漏洞的故障有以下几种故障模型。
（1）竞争条件（Race Condition）漏洞模型
当两个不同的函数共同对一个文件操作时，操作过程中存在一个时间差，利用这个时间差更改文件的某些属性可能导致后续的操作失败
（2）风险操作—随机数（Risky Operation-Weak Random Number）漏洞模型
当程序中用到随机函数如rand( ),random( )等时，由于这些随机函数的值是可以预测的，一旦使用随机数的值作为与文件操作或某些安全有关的操作时，将会存在安全问题。
（3）缓冲区溢出（Buffer Overflow）漏洞模型
当程序要在一个缓冲区内存储比该缓冲大小还要多的数据时，即会产生缓冲区溢出漏洞。
（4）被感染数据（Tainted Data）漏洞模型
当程序从外部获得数据时，它必须验证这些数据是否在程序的需求说明所规定的范围之内，否则，即是被感染的数据。
3 测试用例设计
基于故障模型的软件测试用例设计的难点是,引起故障发生的参数多,故障判决条件复杂,要保障测试的充分性,测试用例数量庞大,有时甚至达到无法忍受的程度。利用故障树分析(failure tree analysis , FTA) 原理结合测试用例设计等价类划分原则,对故障模型判决软件进行测试用例的设计,既可以提高测试的充分性,又能大大减少测试用例的数量。所设计的测试用例辅助设计软件在很大程度上提高了软件测试的自动化水平。
故障分析(FTA)是以故障树作为模型对系统经可靠性分析的一种方法。故障树分析把系统最不希望发生的故障状态作为逻辑分析的目标，在故障树中称为顶事件，继而找出导致这一故障状态发生的所有可能直接原因，在故障树中称为中间事件。再跟踪找出导致这些中间故障事件发生的所有可能直接原因。直追尋到引起中间事件发生的全部部件状态，在故障树中称为底事件。用相应的代表符号及逻辑们把顶事件、中间事件、底事件连接成树形逻辑图，责成此树形逻辑图为故障树。故障树是一种特殊的倒立树状逻辑因果关系图，它用事件符号、逻辑门符号和转移符号描述系统中各种事件之间的因果关系。
在进行测试用例设计时,可采用FTA 原理建立测试用例设计树，同时运用等价类划分方法进行测试用例设计。运用FTA 原理进行的测试用例设计，是根据故障判决模式画出故障树，将该树作为测试用例设计树，然后运用故障树原理获得该树的最小割集，将此最小割集作为软件测试用例设计的依据。软件测试用例设计树的建立步骤如下。
步骤1：对故障模式进行分析,确保对故障模式的理解准确无误；
步骤2：将故障模式作为顶事件,用矩形表示,如图1 所示；
步骤3：建树：将故障模式写在顶部矩形符号内，将引起故障发生的全部必要而又充分的直接故障参数类或参数置于相应的矩形符号或圆形符号中画出第二排，再根据故障模式与它们的逻辑关系用适当的逻辑门联结顶事件和这些直接故障参数类或参数。遵循此规则对参数类的判决也按此步骤进行，直到所有最低一排都是参数为止。这样,，就建立了一棵以给定顶事件为“根”，故障参数类为“节”，故障参数为“叶”的倒置的n级软件测试用例设计树[5]。
利用故障树分析原理中最小割集的求解方法,获得软件测试用例设计树的最小割集。此集合中的每个元素就是一个测试用例。
根据测试用例设计树中的逻辑“或门”会增加割集的数目，逻辑“与门”会增大割集容量的道理，从测试用例设计树的顶事件开始，把故障模式换成参数或参数类,参数类换成参数，遇到“与门”将输入的参数或参数类横向并列写出，遇到“或门”则将输入参数类或参数竖向串列写出，直到把全部逻辑门都置换成参数的矩阵为止。矩阵的每一行就代表一个割集，整个矩阵代表故障树的全部割集，再删去非最小割集，剩下的就是欲求的最小割集。最小割集中的每一个元素，就是一个测试用例。
4 结论
本文对软件测试方法及用例作了一定的介绍，针对软件的故障的五花八门，介绍了数种不同的软件故障模型，鉴于软件测试的复杂性和测试用例的重要性及其难以确定性，运用FTA 原理建立基于故障模型的软件测试用例，实验证明，通过此方法设计的测试用例充分、合理,在测试中能发现被测软件的重要缺陷，为委托部门避免重大损失，有效地提高被测软件的质量。
参考文献：
[1]郑人杰.计算机软件测试技术[M].北京：清华大学出版社，1992:25-28.
[2]Simeon Ntafos.On Random and Partition Testing[C].In:Software Engineering Notes,Proceedings of International Symposium on Software Tseting and Analysis,1998;23(2);42-48
[3]Musa JD.lannino A,Okumoto K.Software reliability measurement prediction application[M].McGraw-Hill,1987.ISBN 0-07-044093-X.
[4]Voas J.PIE:A dynamic failure-based technique.IEEE Transactions on software Engineering [A].1992,18(8):717-727.
[5]陆廷孝,郑鹏洲,何国伟,等.可靠性设计与分析[M].北京: 国防工业出版社,1995:159–183.
系统时钟序列的均匀测试模型 篇4
在密码学研究中, 测试生成序列的随机性是一项重要的工作, 也是一项较难的工作。而序列的这种随机特性也表现为0, 1符号在序列中的分布均匀性。常见的统计测试方法有频率测试, 扑克测试, 游程测试等, 但是即使通过众多测试的序列也不一定具有优越的随机特性。本文正是利用数学理论构造了3个测试, 并基于系统时钟生成的序列来进行了相关的实验。
1 背景应用知识
1.1 计算机浮点数系统
记浮点数为x=±βj×W, 浮点数系统为F, 这里j为基β的阶, 又称为阶码, W为尾数。F的特征主要依赖于4个参数, 不妨记为F (β, t, m, M) , 简记为F。其中β是正整数, 称为基。t是正整数, 表示浮点数尾数W的数位, 记W=±0.d1d2, …dt。一般地, 浮点数系统F (β, t, m, M) 在实数轴上是一个不等距离散点的有限集, 也称为浮点数集。但当参数取某些特殊值时, 所表示的点是均匀分布的, 我们在此研究问题的思想是通过构造均匀离散浮点数集来测试二进制序列的伪随机性。
1.2 FIPS 140-1随机性统计测试
由某个生成器输出的长为20000比特的单比特串应接受下列测试:
(1) 单比特测试。s中1的个数应满足9654
(2) 扑克测试。对于m=4, 计算由式所定义的统计量X。若1.03
(3) 游程测试。分别计s中长度为i的1游程个数为Bi, 0游程个数为Gi, 其中1≤i≤6 (为达到测试目的, 长度大于6的游程均按长度6处理) 。若Bi和Gi的12个值满足下列条件, 则该生成器通过游程测试:
n0[1], n1[1]:2267-2733;n0[2], n1[2]:1079-1421;
n0[3], n1[3]:502-748;n0[4], n1[4]:223-402;
n0[5], n1[5]:90-223;n0[6], n1[6]:90-223;
其中n0[i]表示序列中长度为i的0游程的个数;n1[i]表示序列中长度为i的1游程的个数。i=1, 2, 3, 4, 5, 6。
(iv) 长游程测试:通过长游程测试意味着s中不存在长度大于等于34的游程。
上述测试均为基本测试, 当我们选择输出的序列通过上述全部基本测试时, 我们就认为该序列具有良好的伪随机性, 这种伪随即序列在分布上应该均匀。但我们不能说满足上述测试的序列就是随机序列, 因为还有很多其它要求更加严格的测试需要进行。
2 均匀测试模型
2.1 均匀分布检验模型
在数学分形思想中, 分形集是指对象整体和对象局部之间存在着自相似性。对于这种对象我们就可以从通过研究局部特征来反映整体特征。为了方便实验的设计, 我们选定m=M=0, β=2, t=8此时浮点数系统表示的就是一些均匀的离散点列。下面我们分3步来进行模型的构建和测试。
第一步:建立0, 1序列和[0, 1) 区间的一一对应关系。
对于任意一个0, 1二进制随机序列, 设0, 1总个数为s。按每k个分为一段, 当s不能被k整除时, 则将末尾序列舍去, 以下均假定s为k的倍数。这样对分得的sk段按如下方式建立0, 1序列到十进制小数的映射:
(1) 将长度为k的序列段看作一无符号二进制数, 然后将小数点左移k位。得一二进制小数。
k个 (2) 将此二进制小数化为十进制小数。如转化为十进制小数。
按照上述方式我们就能将上述这段序列转化为十进制小数, 令。假设这m段对应的小数分别为:ak1, i=1a2, …, am。显然我们建立了一个从长度为s的序列到[0, l (k) ]的映射。当k=2时, l (k) =0.75, k=3时, l (k) =0.875…当k=8时, l (k) =0.9961。因此当k足够大时我们就能建立随机序列与[0, 1) 区间之间的对应关系。如果序列中0, 1分布足够均匀, 那么段与段之间也应表现得足够均匀, 即点列a1, a2, …, am在[0, 1) 上也应是均匀分布的, 如果序列的0, 1分布不够均匀, 那么它对应的点列在[0, 1) 上分布也不均匀。这样我们就能通过检验点列a1, a2, …, am在[0, 1) 上是否分布均匀来判断序列的统计特性。
第二步:利用FIPS 140-1随机性统计测试验证基于系统时钟序列的伪随机性。
通过实验发现, 50组测试统计量结果均满足前面提出的精确界, 因此我们可以作出该生成序列满足一定伪随机特性的结论, 即随机性良好。但我们不能说这就是随机序列。表1列出其中的5组测试结果如下 (游程检验中只给出了1游程的情况) :
第三步:基于分形思想建立均匀模型并测试
均匀实验设计中一般将[0, 1) 区间分段进行检验, 考虑各个区间段上的所捕获的点的个数。为了避免出现某个区间的可表示点数偏多, 一般将所考虑的区间2t等分 (t为正整数) 。并记每个区间所得点个数分别为x1, x2…x2t。如果序列均匀, 那么在各个区间上点的个数接近平均值。如果序列不均匀, 那么各个区间上点的个数相差会比较大。
为了提供判别均匀性质的标准, 记。其中表示样本均值, S表示样本方差。Q称为相对偏移值。S反映了样本整体上的数据差距, 而Q则反映了所获样本的最大数与最小数的偏差情况。Q值越大, 显然均匀性越差, 表示某个区间所获点数太多或太少。我们将通过Q的值来考查均匀性。
取定k=8, t=3, l (k) =0.9961。则浮点数集共可以表示256个点, 若将区间分成[0, 0.125) , [0.125, 0.25) , [0.25, 0.375) , [0.375, 0.5) , [0.5, 0.625) , [0.625.0.75) , [0.75, 0.875) , [0.875, 1) 8份, 平均每个区间就包含32个点。序列长度选用25600。实验结果如下表2 (仅列出10组) :
实验发现, 方差值较小时, 对应的Q值也较小;方差大时, Q值也大。但是两者并不存在某种线性关系。总体上看, 实验效果很差, 表明序列均匀性没有预想的好 (20组实验数据中满足Q要求的只有3组) 。
2.2 χ2分布检验模型
记号同模型1中相同。在此忽略0, 1序列之间的统计依赖关系, 利用概率论的知识来建立模型。
如果长度为s的0, 1序列中的0, 1分布均匀, 那么它对应的点列记为L, L为[0, 1) 上的均匀分布。将区间[0, 1) n (应等同于前面的2t) 等分, 那么每个区间上点的个数实际上为一个随机变量。分别记为X1, X2, …, Xn, 且随机变量X1, X2, …, Xn的分布相同。由概率论知识, 任给一个随机序列, 我们都能够得到X1, X2, …, Xn的一组观察值x1, x2, …, xn且满足关系式:。又由于X1, X2, …, Xn同分布, 我们可以将x1, x2, …, xn看i=1作X1的n个样本点。根据密码学知识和概率论知识建立如下测试模型:
n (1) 类扑克测试:所使用的统计量为, 它近似地服从自由度为n-1的χ2分布。
下面基于系统时钟生成长度为s=10000的序列, 这里取k=4, 则序列被分为份, m=2500。取n=8, 于是, 它近似服从自由度为7的χ2分布。我们做了50组实验, 发现, 当取显著性水平α=0.2 (置信区间为[0, 9.803]) 时有20组数据不能通过测试 (理论上应该有10组左右) 。当取显著性水平α=0.1 (置信区间为[0, 12.017]) 时有13组数据不能通过测试 (理论上应该有5组左右) 。当取显著性水平α=0.05 (置信区间为[0, 14.067]) 时有8组数据不能通过测试 (理论上应该有2.5组左右) 。同样存在实际试验数据和理论值相差比较大, 从实验结果上看, 存在基于系统时钟生成的随机序列还存在一定的缺陷的可能性。实验结果列入下表3 (仅列出其中的5组) :
(2) 频率测试:使用统计量此统计量近似服从自由度为1的χ2分布。我们基于m系统时钟生成长度为10000的序列, 这里取k=4, 则序列被分为份, m=2500取n=8, 于是频率测试中的统计量为，Y1近似服从自由度为1的χ2分布。
我们做了50组实验, 取显著性水平α=0.05 (置信区间为[0, 3.841]) 时有30组不能通过测试。显著性水平α=0.01 (置信区间为[0, 6.635]) 时有25组数据不能通过测试。通过频率测试, 我们能看到基于系统时钟生成的序列并不随机, 在随机性上存在一定的缺陷。
3 实验数据分析
在模型一中, 我们利用了分行的思想通过测量分段后的局部均匀性来考查序列的整体特性。测量结果显示和值均比较大。但是FIPS 140-1随机性统计测试结果和模型本身都具有相当的可说服性。分析可能是以下结果造成的:
(1) 系统时钟本身存在缺陷
系统时钟序列是基于时间生成的, 由时间的连续性可以预想序列符号之间的统计相关性很强, 序列的均匀特性依赖于这种相关性。这样就使得在整体上可以表现较好的均匀性, 当进行分段后由于破坏了这种相关性而不能体现这种均匀性。
(2) 取得的分段序列长度不够长
由于长度太短的序列不能充分考虑统计关系, 使得在使用统计量的时候不能很好地显示统计效果, 这样也就不能按照预想的效果得到结果, 下一步的工作可以考虑将整体序列的长度和分段序列的长度都相应加强。
(3) 均匀测试量建立不够科学
由于考虑因素有可能不够全面, 也会造成实验数据不够理想。
在模型二中, 我们通过忽略序列之间的统计相关性, 利用概率论的知识来建立模型的, 但同样出现了理论和实际数值存在差异的现象。对于类频数测试和类扑克测试模型测分析如下:
(1) 我们建立模型的前提是忽略序列段与段之间的相关性, 也就是忽略了马氏效应。这样使得模型不够精确。而且这种依赖性的消弱带来的结果可能是非常糟糕的。
(2) 理论上的概率分布有可能与实际情况的分布相差较大, 这样将其他区间的取值归结为首个区间的取值, 也会造成理论与实际数据的巨大误差。
更深入的工作需要针对上述的情况进行有针对的排除, 包括如何更好地处理序列之间的连续相关性, 还有如何处理区间分段和取值问题。
参考文献
[1]郑慧晓, 陈绍林, 莫忠息, 等.数值计算方法[M].武汉:武汉大学出版社, 2002.
[2]A.J.Menezes, P.C.Van Oorschot, S.A.Vanstone.应用密码学手册[M].胡磊, 王鹏, 译.北京:电子工业出版社, 2005.
[3]李水根.分形[M].北京:高等教育出版社, 2006.
测试模型 篇5
PSM模型(价格敏感测试模型)由Van Westendrop在70年代创建，适合测试新产品/服务的价格，其特点是只考虑价格和质量的权衡，所有价格测试过程完全基于被访者的自然反应，不涉及竞争对手的对比。通过PSM模型，不仅可以得出最优价格，而且可以得出合理的价格区间。
PSM模型应用的前提是，在测试前需要让被访者充分理解产品的概念或定位，并给出一个价格梯度表，其价格范围尽可能涵盖所有可能的价格点，一般而言，最低价格和最高价格，往往要求低于或高出可能的市场价格的三倍以上。
PSM模型的具体操作方法是，询问被访者4个问题，从而得到4个价格：
1、什么样的价格您认为太便宜，以至于怀疑其质量较差，而不会去购买?(最低价格：太便宜)
2、什么样的价格您认为比较便宜，感觉物有所值，会去购买?(较低价格：经济实惠)
3、什么样的价格您认为较高，但仍可接受，会去购买?(较高价格：有点贵)
4、什么样的价格您认为太高，以至于不能接受，肯定会放弃购买?(最高价格：太贵了)
统计分析时，最低价格、较低价格的百分比进行向下累计统计，即认为10元钱便宜的被访者，同样会认为8元钱便宜;最高价格、较高价格的百分比进行向上累计统计，即认为20元钱贵的被访者，同样会认为25元钱贵。这四条累计百分比的价格曲线会交叉在一起，其中“太便宜”和“有点贵”价格曲线的交叉点为价格区间的下限、“经济实惠”和“太贵了”价格曲线的交叉点为价格区间的上限;“太便宜”和“太贵了”价格曲线的交叉点为最优价格;“经济实惠”和“有点贵”价格曲线的交叉点为次优价格。
市场研究公司应用PSM模型时，通常有访问员辅助进行调查，能够较为顺利地进行数据收集。而网络调研问卷是被访者独自填答，若应用PSM模型，应该如何操作呢?如果仍采用传统的操作方式，是否还是适合呢?
笔者从开始，在不同研究项目中应用了PSM模型，对操作方式进行了改进;也借用了PSM模型的研究思路，在类似定价的研究中进行了尝试，现与大家共同讨论可行性。
应用一、量子统计工具的定价研究
量子统计工具上线前，曾采用传统的PSM模型操作方法，进行了调研，当时在题干中说明了量子统计工具的主要功能，并给出了价格梯度1~50元/月，请用户手动填写四个价格。最终计算得到最优价格是10.8元，与产品经理设想的10元/月非常吻合，首次在网络问卷中尝试此方法，得到较好效果。
但处理数据阶段耗费了大量时间，主要是用户手动填写会有很多“意外”发生，集中于用户填写的数字格式不正确(调研问卷系统不完善造成)，比如数字带单位、数字超过给定的范围、数字漏点小数点、大写数字等情况。
由此，开始考虑是否能对PSM模型的操作方式进行改进，以便更适合网络调研。改进的主要方向是将原有的数字填写题改为单选矩阵题，对于选项的设置，尝试了两种形式：单点数值、区间数值。
应用二、卖家对工具套餐的定价研究
调研显示，卖家在卖家服务市场倾向选择使用工具套餐，一方面信任官方的推荐，认为官方会根据工具的应用量、工具的搭配合理性等方面进行研究，推出最适合卖家发展需要的工具套餐;另一方面工具套餐比单个购买这些工具价格要优惠很多，
笔者研究工具套餐的定价时，采用了PSM模型的改进形式，用单选矩阵题收集信息，并且选项采用了单点数值的方式。最终得到结果如下图：
分析可知，工具套餐(包含八个功能)的价格区间在31~47元/月之间，最优价格为40元/月。单点数值的好处是，用户选择时比较容易理解;计算结果时，也能够根据交叉点的位置，确定具体的值。但单点的数值需要恰到好处，否则容易引起偏差，比如用户原本接受的最低价格是15元，而单点设置的数值是10元、20元，这就使得用户无法快速选出符合自己意愿的选项，纠结于“是再降低一下自己的标准，还是提高一下自己的标准”。
应用三、买家对二手笔记本电脑附加联保的定价研究
二手笔记本市场推出附加6个月全国联保服务时，需要对这个售后服务定价，采用了PSM模型的改进形式。
考虑到需要在题干中强调“是对附加服务的价格进行选择”，没有使用单选矩阵题，而是直接采用了四道单选题进行尝试，虽然题目之间在空间上有了距离，缺少了填答思路“环环相扣”的连贯性，但题目的表达更加清晰明确了;选项采用的是区间数值的方式。最终得到结果如下图：
区间数值的好处是，选项覆盖了完整的数据范围;但这种方式得到的结果，会随着区间间距的大小而变化，如果间距较大，可能会产生较大的偏差。所以应用此种方式时，需要考虑如果产生如同间距大小的误差是否可以接受，如果不能接受，则需要缩小间距增加选项，或改换成其它方式。
另外，区间数值的交叉点不易确定具体的值，分析时要格外注意。
此方法得到的答案更强调趋势，对认知用户的价格敏感度提供参考，当要求确定价格的具体数值时，应进一步结合业务的实际需要，产出最终价格。
应用四、买家对促销优惠折扣的接受范围研究
PSM模型只能用于新产品的定价吗?是否可以借用其研究思路对其他类似问题进行研究呢?在研究买家可接受的折扣范围时，笔者借用了PSM模型的研究思路。题目如下：
题干中同样讲述了前提条件“当商品原价是市场价的情况下”，并通过四个类似PSM模型中的问题，采用单选矩阵题，收集4个折扣值。原本这道题目的选项是单点数值，主要预设用户想到折扣的时候，基本会直接从整数折扣考虑，所以单点数值设置成1~9的整数，不会造成用户选择上的纠结。
但问卷定稿时，这道题的选项采用了单点数值与区间数值结合的方式，主要是为了节省题目的展现空间，想让用户更快速地做出选择;同时产品经理也从业务角度出发，提出用户对4、5折、6、7折的区分不会很大。所以，设置选项时将4、5折，6、7折分别合并在一起。最终得到结果如下图：
从结果来看，如此设置并不成功，因为价格上下限的值，正好在区间数值与单点数值之间，如何确定这两个值呢?是3.8~7.7折吗?恐怕不同的分析思路会得到不同的结果。后续如果改进，最好采用1-9的单点数值作为选项，再尝试一次，应该能得到更理想的结果。
小结：
测试模型 篇6
【关键词】STC89C52；压力传感器；A/D转换器；桥梁荷载力
1.引言
国际上许多国家，在货物公路运输过程中，普遍存在超载现象。超限的车辆会造成道路损坏严重，也造成交通事故频频发生。为了实现对桥梁的实时检测，有必要依靠嵌入式技术发展成果应用到桥梁建造上，来彻底杜绝道路严重损坏及交通事故的频繁发生。设计基于单片机的桥梁荷载力测试实验模型电路，利用安装在桥梁下面的应变传感器测量车辆经过桥面引起的桥梁应变张力，通过积分运算消除车辆振动对计算结果的影响，得到桥梁的荷载值。理论和试验室结果证明该方法可以较准确的进行高速动态超重车辆的检测。由于利用该方法的动态称重测量系统不要进行地面开挖，建造成本较低，具有很强的可移动性，能实现24小时不间断检测，具有很好的实用前景。
2.理论推导
（1）桥梁荷载测试装置的工作原理
当被称物体放置在模拟桥梁上时，其重量便通过桥墩传递到压力传感器，传感器随之产生力-电效应，将物体的重量转换成与被称物体重量成一定函数关系（一般成正比关系）的电信号（电压或电流等）。此信号由放大电路进行放大、经滤波后再由模/数（A/D）器进行转换，数字信号再送到微处器的CPU处理，CPU不断扫描键盘和各种功能开关，根据键盘输入内容和各种功能开关的状态进行必要的判断、分析、由仪表的软件来控制各种运算。运算结果送到内存贮器，需要显示时，CPU发出指令，从内存贮器中读出送到显示器显示。
（2）荷载测量方法
经过实际调查，本设计方案将采用简支梁作为桥梁模型。车辆通过桥面时，简化为间距为Ls的两个点力以速度c匀速通过桥面，F表示前轴，R表示后轴，如图1所示。
此处： 是桥上x点处在t时刻的桥梁位移；ρ是单位桥梁密度；C是粘性衰减系数；E桥梁材料的杨氏系数；I是桥梁横截面的惯性矩；L是桥梁的长度； 代表车辆通过时前后轴对桥面产生的压力；c是车辆通过桥面的速度； 是单位冲激函数。
基于模型假设，动态位移， 可以被描述为：
此处：i是模态数， 是第i模态形状函数； 是第 i 模态的幅值函数。把式（2）代入式（1）：
对方程（3）左右两边都乘以模态形状函数 π，并 在区间[0，L]上对方程中变量 x 进行积分，得：
（4）
此处： 是第 n 模态的频率； 是第n模态的衰减比率；Mn是第n模态的模态质量。基于桥梁假设，桥梁的模型参数可以通过下面式子计算：
式中：S——传感器及其测量电路的灵敏度（即被测量X转换成电压U的转换系数）
K——放大器的放大倍数
——A/D转换器满量程输入电压
——A/D转换器满量程输出数字
而被测量X总是以其测量数字N和测量单位x1表示
就可以使A/D转换结果D与被测量x的数值N相等，即D=N，在这种情况下将A/D转换结果作为被测量的数值传送到显示器显示出来。
3.电路设计
本系统由、数据采集部分、声光报警部分、数据显示部分、键盘部分和电源等部分，其中，控制器部分采用STC89C52实现，数据采集部分由压力传感器、信号放大电路、A/D转换器构成，系统设计原理如图2示。
（1）数据采集部分电路设计
数据采集部分电路由传感器、信号放大电路和A/D转换器组成。A/D转换器采用24位HX711芯片。HX711与单片机的接口电路接线图如图3示。
（2）显示电路与STC89C52单片机接口电路设计
显示电路采用LCD12864。LCD12864与单片机的接口电路设计如图4示。
4.软件设计
本设计采用C语言编程，编译环境为keil UV4。根据系统的控制任务，软件设计主要由主程序、初始化程序、显示子程序、数据采集子程序和延时程序等组成。
在芯片上电后，初始化程序将单片机中程序存储器单元清零，P3.0引脚置成低电平，防止错误报警。主程序设计流程图如图5所示。
5.结论
灰盒测试模型的应用与研究 篇7
灰盒测试, 是介于单纯的白盒测试与黑盒测试之间的, 虽然不象白盒那样详细、完整, 但是如果每次都通过白盒测试来操作, 效率会很低, 因此需要采取这样的一种灰盒的方法。黑盒测试和白盒测试都有其相对的局限性, 大型面向对象系统全面、彻底的测试是单纯采取任何一种方式都无法实现对。灰盒测试是把黑盒和白盒的测试要素结合起来, 同时注重软件系统的内部实现以及系统的外部特性, 既顾及到了系统的客户端功能、架构和环境, 也对单纯黑、白盒测试的局限性做了弥补。
二、灰盒测试模型
1. 提出模型
软件开发过程中软件测试是非常重要组成部分。软件测试就是在软件在正式使用前, 对需求分析、设计规格说明和编码的最终审核, 是软件质量的重要保障环节。软件测试是为了发现程序错误的过程。软件测试在软件生存期中横跨两个阶段:对每个编写完成的模块都要进行单元测试。编码和单元测试是在软件开发的同一个阶段完成的。软件系统在这个阶段结束后对还要进行各种综合测试, 这是软件生存期的另一个独立阶段, 即测试阶段。
传统的编程技术是面向过程的, 而当今计算机软件领域的一项主流技术是面向对象技术已经成为。分析、设计、编码和测试等阶段是传统软件开发的主要过程。相应的面向对象软件开发过程也可分为面向对象分析 (OOA) 、面向对象设计 (OOD) 、面向对象编程 (OOP) 和面向对象测试 (OOT) 等阶段。分析和设计重点的改变以及编程技术的变化会对测试产生深刻的影响。因此从过程式的开发方式转变为面向对象的开发方式, 必然带来测试模型的一些改变。
根据面向对象系统的特点并结合过程式软件测试模型的结构, 本文提出了一种灰盒测试模型, 如图1所示:
2. 分析模型
灰盒测试模型包含四个主要的测试阶段, 下面将分别对其进行分析, 其它实施步骤以及辅助阶段将通过实例说明。
(1) 审查代码阶段
审查代码 (Review Code) 是软件开发中常用的手段, 它比QA测试更容易发现和架构以及时序相关的一些较难发现的问题。审查代码主要是对代码的设计一致性、标准遵循性、逻辑表达正确性以及结构合理性实施检查, 是以发现模块的内部错误为目的。面向对象程序是以类为单位展开审查代码的, 需要考虑到对象、消息、接口、类、继承、多态等特点。
灰盒测试中非常重要的一个阶段就是审查代码, 据统计, 软件中40%~70%的错误可通过审查代码来发现。但如果程序本身设计与需求不符, 这些错误是无法通过审查代码发现的。
(2) 功能测试阶段
系统的内部编码问题已基本通过审查代码排除, 即可对产品的各功能进行验证, 根据功能测试用例, 按照用户要求的功能逐项测试。审查代码和功能测试是相辅相承的。在审查代码的基础上进行的功能测试, 即使测试人员理解了系统的内部结构, 又通过系统的外部运行现象来对内部的程序结构实施验证。功能缺失/失效、系统/产品挂起或崩溃、用户界面的友好性缺陷等都是功能测试关注的问题。
功能测试的驱动是必须通过测试用例的。测试的管理工具是用来记录软件的功能分类的, 而对应的每个对应的功能下面则应该记录详细的测试用例。对于一些功能比较复杂、专业性又比较强的面向对象系统, 应该把测试用例在功能测试开始阶段之前设计好, 这样既可以避免测试的盲目性, 同时又可以提高测试的效率。
整个测试用例的集合应该覆盖软件系统的全部功能, 同时还要考虑到尝尝被程序员忽略的系统边界值和系统非法值。测试用例的编写要根据实际的模版来编写, 并详细记录对应的模块以及测试版本、用力类别等有用信息。
(3) 覆盖测试阶段
覆盖测试是在功能测试之后开始的, 因为这时软件系统集成完毕, 已经可以基本排除存在于接口方面的错误。在测试模型中, 覆盖测试要生成覆盖率的统计文件, 也就是用白盒测试工具, 来运行设计好的测试用例。覆盖测试是用来衡量测试质量的一个非常重要的指标。是否在对一个软件产品进行种类繁多的测试之后, 我们就能对软件的质量产生充足的信心呢?这就需要我们来考察测试的方法。如果测试仅覆盖了一小部分代码, 那么无论测试多少次, 软件质量我们也是无法确信的。相反, 如果绝大多数编写的代码都受到了测试的覆盖, 那么我们就可以对软件的质量充满信心。
覆盖测试正常可分为五种方式, 分别是覆盖判定-条件、覆盖条件、覆盖分支、覆盖语句以及覆盖路径。但笔者在该项目中, 只采用了两种方式, 就是覆盖语句和覆盖分支。覆盖语句是指程序中所有语句都要执行一次以上;覆盖分支是指程序中所有的分支判断都必须执行一次。为了解决程序的功能覆盖程度, 那就必须对语句的覆盖率以及分支的覆盖率进行一次完整的统计, 同时, 在对未覆盖的部分代码进行二次审查, 对功能映射代码, 就可以让测试人员更加深刻的理解代码。, 因为功能和代码模块在面向对象的程序中完全对应相当的困难, 所以程序功能覆盖的标准使用以覆盖分析为统计的方法就可以较好的解决问题。
覆盖测试相比其他方法是比较耗费人力物力的, 之所以该模型要引入覆盖测试, 就是为了对审查代码和功能测试的结构进行更详细的确认。
(4) 回归测试阶段
回归测试是软件开发过程中的一个组成环节, 在整个软件测试过程中都占有极大的工作比重, 回归测试会反复出现在软件开发的各个阶段。回归测试是指对修改过旧代码再次进行测试, 从而去确认此次修改不会产生新的错误或者致使其他未修改的代码产生新的错误。全自动的回归测试也能够大幅的降低系统测试、维护升级等阶段的成本。由于大型系统本身的开发过程都是渐进式的, 即系统原型开发完成后, 才会分阶段、分模块的实施软件开发, 系统的开发过程都是周期性的。因此, 灰盒模型中相关阶段的的回归测试策略都需要在上述基础上进行相应的调整, 以适应开发过程中可能存在的需求调整以及对系统的重新设计。
三、模型应用实例
1. 测试流程
之前笔者有幸参加了一些基于大型面向对象系统的第三方测试项目中, 多次采用了上述设计的灰盒测试模型, 在经过了大约一年的测试后, 灰盒测试模型的有效性已经得到了充分的验证。当然在实施过程中还需要根据实际情况来制定相应的更加细化的策略。
图2就是一个使用了灰盒测试模型的实例。以下的流程图只针对该实例其中的1个子系统, 共包含361个文件, 约8万多行代码。
2. 测试配置
在灰盒测试模型运行的不同阶段, 配置了相应的测试文档及测试工具, 如表1所示。通过这些测试文档和测试工具的使用, 可以提高测试人员的工作效率, 减少测试工作量。
3. 测试结果分析
在灰盒测试模型运行的不同阶段, 不少的软件问题被发现, 下表就将软件问题的分布情况进行了罗列, 如表2所示。
通过表2中可以看出:问题被发现最多的阶段就是功能测试和审查代码, 审查代码发现的都是代码的内部错误, 而功能测试发现的均是系统的功能性错误, 这两种问题的类型刚好形成互补。然而覆盖测试则是对前两个阶段的一种补充, 发现的都是前两个阶段遗漏的问题。而在回归测试的时候, 发现的问题就主要集中在已经修改过的代码部分, 不过这是阶段发现的问题数量已经开始大幅减少。
四、结论
本文提出了一个基于面向对象系统的灰盒测试模型, 并用实例的测试项目中应用了该模型, 从而提高了被测系统的质量, 确保了系统的安全性和可靠性。该项目验证了灰盒测试模型的有效性。同时通过在实例中描述的测试过程的细节, 类似的测试项目也可以参考该模型。
摘要：灰盒测试是黑盒测试和白盒测试的完美结合。本文结合实际工程项目, 给出了一个灰盒测试模型, 并将该模型在大型面向对象系统的测试中进行了应用, 从而对模型的有效性做了验证。
基于模型的软件测试技术探析 篇8
目前, 我国软件质量测试研究中, 对软件质量测评模型与测试数据自动生成方法的研究, 已经成软件工程领域的研究热点。基于模型的软件测试方式是软件编码阶段的主要测试方法, 通过故障排除法, 检测软件质量, 具有运行速度快, 效率高、检测性能佳等特点。但是也存在误报、漏报和故障机理等程序问题。笔者通过分析国内外软件质量相关技术现状, 对基于模型的软件测试技术特点和存在的主要问题进行了分析, 阐述了基于模型的软件测试流程。
1 国内外软件质量相关技术现状
近几年, 国家对软件安全问题越来越重视, 不少高校和国家研究机构从事软件测试研究, 通过借鉴国外先进理论和引进技术, 结合我国软件质量问题, 基于模型的软件测试技术得到了快速发展并应用到实际测试中。但是还是远远落后于国外软件测试技术, 一方面, 在欧美发达国家, 软件测试工作是一个非常独立的职业, 是软件质量控制必不可少的环节;在我国, 很多软件企业软件测试工作只停留在单元测试, 功能测试等环节, 甚至根本不进行质量测试, 专业的测试工作人员所占比例小;另一方面, 我国软件产业质量较低, 软件测试标准化、规范化操作尚未形成, 而软件测试的通用化、网络化和智能化水平与国外相比, 更是相差甚远。
2 模型的软件测试技术特点
2.1 软件测试评价一体化
基于模型的软件测试技术根据被测试应用程序的分析设计模型, 自动生成测试模型、产生测试用例和进行测试结果评价。
2.2 软件测试自动化水平及测试效率高
基于模型的软件测试在测试过程中, 首先提高了软件测试效率, 减少了测试人员的工作量;其次在软件成本降低的同时, 软件产品质量提高了;最后, 可以随时生成各种统计数据, 提高高层监控整个软件测试过程的能力。
2.3 有效解决了测试失效辨识问题
基于模型的软件测试技术是对其他软件测试技术的有效补充, 往往能发现其他测试技术难以发现的故障, 尤其是对逻辑复杂故障测试效果好, 保障了软件质量。
3 模型的软件测试存在的主要问题
模型的软件测试工作是一项具体且全面的工作过程。首先, 工作人员方面, 不仅需要测试人员具备一定的理论基础, 还要掌握相关工具使用方法。其次, 在实际应用过程中, 我们发现基于模型的软件测试技术存在不少软件质量问题, 尚不能取代已有的其他测试技术, 还需从事此行业的工作人员进一步研究和实践, 更好的补充其他测试技术不足之处。以下简述了存在的几个主要问题并进行了简要分析。
3.1 误报问题
误报问题是系统没有发生故障而报警, 误报信息是模型的软件测试技术普遍存在的问题。这是由于一些故障的发生和确定是在动态的信息执行中形成的, 而基于模型的软件测试技术大多是静态分析技术, 误报问题在静态分析的测试工具工作中是不可避免的。以下以OCL在建模的进程调度系统中的静态模型为例, 见图1。
上图是对系统的静态描述, 虽然可以形成所需模型, 但是显然对该系统的描述还是不精确的。我们知道, 处在就绪状态的进程和等待进入就绪状态的进程集合之间是不相交的, 而系统中始终只能有一个处于活动状态的进程, 活动进程与前两个进程也不会发生集合。这样, 静态图的生成并不是准确的, 误报问题由此产生。现在不少高校和研究所将动态测试与静态测试进行互配测试, 以期解决测试中的误报问题。
3.2 漏报问题
漏报是指系统发生了故障而没有报警, 是系统故障中又一常见问题。基于模型的软件测试是由模型定义和模型检测算法进行软件质量测试的, 由于模型定义和模型检测算法在具体软件模型检测中存在差异, 漏报问题也是不可避免。
我们知道, 由于模型定义是由故障本身及所用工具决定的, 而软件模型多种多样, 测试工具因模型变化, 具体的模型所用的检测工具在设计过程中从检测的效率性和降低软件复杂性出发, 都会设计形成自己认为最简便合理的检测算法, 这样就形成了软件检测中普遍存在漏报问题, 即使是相同的模型, 由于检测工具的差异, 导致检测故障结果也存在差异性。
3.3 人员问题
软件模型的设计、定义和操作是由编程人员完成的, 编程人员个人的操作技术和工作素质也会对基于模型的软件测试结果产生影响。如:工作中, 由于编程工作人员具有较强的个体性, 对于不同的软件模型设计, 也会出现操作失误, 理解错误、遗漏失误等问题。
例如:某UML活动图生成测试用例中, 采用语言开发数据类软件故障测试结果, 见表1。
通过测试, 我们发现由于操作失误和遗漏造成的错误分别占32%和56%, 忽略其他技术性测试错误, 由于操作失误和遗漏占总数的大约90%。因此, 加大对编程人员素质培训和奖励机制是有必要的, 如创造良好的工作环境, 进行定期的培训学习等等。另外, 针对不同软件个体性的问题, 可以从单一问题中进行总结, 找到共性, 进行研究改革, 以期解决各类故障模型问题。
4 基于模型的软件测试流程
基于模型的软件测试过程中从源代码输入开始, 经历创建模型 (进行预编译、词法分析、语法分析与语义处理等) 、生成测试用例 (控制流图生成) 和故障扫描 (集成测试、单元测试、验收测试、系统测试扫描) 等几个步骤, 最后生成测试报告 (故障报表) 。监测流程, 见图2。
基于模型的软件测试是根据需求、规格说明、进行概要设计、详细设计, 通过预编译、词法分析、语法分析与语义处理等工具创建一个我们需要的机器可读的模型, 该模型表述了需求所表述的所有可能行为。模型设计时, 建模人员要抓住待测试的某一方面, 即系统要测试的关键部分进行。进行预编译和语法分析生成语法树, 通过语义处理, 生成控制流程图和变量的定义使用链, 以便进行后续操作, 查找其他故障。然而合理建模还是存在不少问题, 尤其需要建模工作者从实际出发, 合理建模。具体措施如下:模型建立前, 工作人员要参考大量相关的书籍和具有可靠性分析的应用文章, 为建模做好基础工作。重点培养建模人员创新精神, 不断接受新技术, 新方法, 并且进行自我创新。提高建模人员合作意识, 培养团队协作精神。
建模工作中, 创建模型的工作量和回报率是对等的。软件需求分析、设计和最后人工确认故障需要工作人员进行综合把握, 工作量非常大。通过将这些非形式化的内容转化为所需求的模型, 很容易发现需求中遗漏的错误。通过分析模型, 得到关于需求的反馈, 自动生成测试用例, 包括提供给待测试系统的输入以及期望的输出。生成测试用例可以被反复执行以重现bug, 让失败的结果作为有效的反馈给模型或者需求, 找到问题所在, 然后重新生成测试用例, 最后为了将误报降到最低, 使用人工对生成的故障进行判定。
5 结语
总之, 基于模型的软件测试技术已经在我国市场上开始应用, 它以高效率、高质量和后期维护方便等优势, 越来越受到软件测试人员的青睐。虽然在具体的应用过程中也存在很多问题, 但是随着软件类型的迅速增多, 模型的软件测试方法也会逐步成熟, 得到更好更快的发展, 进一步提高我国软件工程质量。
摘要：近年来, 随着科技信息的快速发展, 软件的功能性和复杂性增强, 软件测试与可靠性评估的难度逐步加大。笔者主要分析了现在广泛应用的面向对象软件开发技术和软件自动化测试技术的现状, 总结了基于模型的软件测试特点及不足, 并简单介绍了基于模型的软件测试流程。
关键词：软件产业,模型,测试流程
参考文献
[1]颜炯, 王戟, 陈火旺.基于模型的软件测试综述[J].计算机科学, 2004 (2) .
[2]张琛, 段振华.应用UML2.0模型的测试用例生成方法[J].西安交通大学学报, 2011 (8) .
[3]王佳新, 杨东凯, 杨芳.TMS320C54x DSP软件测试方法研究[J].计算机工程与设计, 2009 (16) .
测试模型 篇9
伴随着计算机的普及和网络的迅速发展,计算机应用已经遍布各个角落,与此同时各行各业对软件需求也越来越多,对软件的健壮性、功能性等提出了更高的标准。计算机系统日益复杂,软件规模也在迅速膨胀,必然使得缺陷出现的可能性大大增加,暴露出的问题自然也逐渐增多,再加上当前的软件开发和运行环境的开放性、多变性、动态性等,使得软件隐藏了许多未知隐患。例如,阿丽亚娜5型运载火箭发射失败,北京奥运会售票官网一度瘫痪都是由软件故障引起的。
网络的迅速发展,已经成为一个庞大的资源共享库,每时每刻传递着巨大信息量。通过HTML、XML、CGI等WEB技术,越来越多基于网络环境的Web应用系统被创建起来。网络技术、分布式计算技术、面向对象技术三者进一步的融合发展, 网络应用正朝着SOA(Service-Oriented Architecture,面向服务的体系结构)发展。Webservice正是这种原则的体现,它为因特网上的分布式计算提出了一种基于XML等开发标准的、松散耦合的、跨语音、跨平台的新型软件构件。软件测试一直以来都是保证软件质量的重要手段,对于测试方法、技术的研究一直都没有停止过。
1基于模型的测试
软件测试的目的是用最少的时间和人力找出软件开发各个阶段潜在的各种错误和缺陷。从证实方面说是为了证明软件不存在错误的过程,证伪方面说是发现软件中错误而执行程序的过程。测试对象包括程序、需求分析、概要分析、详细分析、 交付件、设计文档、源代码等。
社会对软件需求越来越多,规模也越来越大,对软件安全性、可靠性、实时性等也提出更高的要求。最初软件测试方法日益不能跟上软件增长,伴随着面向模型的开发技术发展以及软件自动化测试技术进步,基于模型的软件测试(Model-Based Software Testing)技术得到了广泛的重视和应用。所谓基于模型的软件测试就是对应用程序的某个被测功能或者多个待测试功能进行分析,得到应用程序的规格说明书,根据这个说明书设计出模型,以模型为依据根据某种配对原则生成测试用例, 最终对测试结果进行评估。基于模型的软件测试的出现大大提高了自动化测试技术的效率和测试水平,提高了测试用例的重复使用率。目前已经出现了多种测试模型:UML模型、有限状态机模型、文法模型、马尔科夫链模型等。
2Webservice技术
Webservice技术标准复杂,网络的分布性和多变性就决定了传统的测试方法并不能完全的满足其测试需求。Webservice作为Web应用的一种得到了很多行业的关注和支持,如何保证其可靠性成为学术界的讨论研究焦点。
Webservice各种角色在交互中必然牵扯到一系列标准和协议,通常描述Webservice=SOAP++WSDL+UDDI。其中SOAP (Simple Object Access Protocol)协议是Webservice的主体,它通过HTTP或者SMTP等应用层协议进行通讯,自身使用XML文件来描述程序的函数方法和参数信息,从而完成不同主机的异构系统间的计算服务处理。WSDL(Web Service Description Language)也是一个XML文档,它通过HTTP向公众发布, 公告客户端程序关于某个具体的Webservice服务的URL信息、 方法的命名,参数,返回值等。UDDI是一种目录服务,它集描述 ( Universal Description )、 检索 ( Discovery )、 集成 (Integration)为一体,通过这个目录对Webservice进行注册和查找,在互联网上发布自己所提供的服务。
3树模型测试方案
树型结构是一类重要的非线性数据结构,它是以分支关系定义的层次结构,不仅在计算机领域,在其他非计算机领域同样得到了广泛的应用。
本文采用ewind Design Space工具进行建模并生成用例,它是一个MBT工具,并应用算法固化的测试设计方法,其具有与模型分离的生成策略控制能力,适配敏捷测试的能力,算法固化经典的测试设计方法,自动根据模型生成用例包括文本用例和自动化用例。
分类树是某种业务行为的因子的约束组合,Root节点下分类节点是相互组合的,每个分类节点下类节点(叶子)是相互互斥的,即一个用例中一个分类节点下面的取值只会出现一个, 类节点下面还需考虑不同分类,则需在类节点下继续增加该类取值的不同分类。流程图和分类树设计完成后,定义用例生成策略,将确定同一个模型生成用例的覆盖深度。树的叶子节点便是用例的影响因子,依据语句控制和生成策略对因子进行组合便生成测试用例,用例的生成基于黑盒测试方法中的等价类划分。图3为用于生成用例的分类树,虚线表示省略,根据实际需求可能有多个分类点。
4实施方案
Soap UI是一个开源的Webservice测试工具,一个完整的自动化测试解决方案,通过soap/http的检测、调用,对Webservice进行功能测试、负载测试、可靠性测试等。相比较其他工具, Soap UI提供了较为领先的技术以及对标准的良好支持,一直都是从业者的首选工具。
选取网上提供火车时刻表服务的WSDL进行测试,结果如下表。
根据以上数据可以明显的看出用例的覆盖率大多维持在80%上下,可以满足正常的测试需求。实际测试工作中,并不要求也没有明确的说明用例覆盖率一定要达到100%,而是根据具体的软件需求和实际出发来确定覆盖率。实际上包括我实习的一段时间亲身经历,几乎都将用例覆盖率保持在80%左右。
5总结
测试模型 篇10
关键词：测试性,模型,设计分析
随着武器装备功能性能日益提高和结构复杂度的不断增加, 可靠性、测试性、维修性、保障性、安全性等“五性”工作作为武器装备质量特性的重要组成部分, 在产品设计中越来越受到重视。“五性”工作的共同目标是提供装备的完好性、任务成功性和安全性, 减少维修人力及其他保障资源的要求, 降低寿命周期费用。
测试性是产品能及时准确地确定其状态 (可工作、不可工作或性能下降) 并隔离其内部故障的一种设计特性。测试性水平的高低直接影响到系统维修性指标的实现。测试性模型是分析、评价产品测试性, 进行测试点优化和诊断策略优化的重要工具。随着计算机辅助软件的发展, 通过测试性建模软件可快速、方便的建立模型, 有效的对产品测试性设计进行分析。
本文结合武器装备的研制过程, 以测试性建模软件TADS为例, 对测试性概念以及基于模型的测试性设计分析方法进行一些介绍和探讨。
1 测试性相关概念
1.1 测试性要求
测试性要求可分为定性和定量要求两类。
测试性定性要求反映了那些无法或难以定量描述的设计要求, 从多方面规定了设计时应注意采取的技术途径和设计措施, 以方便测试和保证测试性定量指标的实现, 如产品的结构层次划分、机内自测试 (BIT) 、故障信息记录与报告、对中央测试系统的支持、测试点、外部测试设备兼容性等。
测试性定量要求主要包括以下三个方面:
(1) 故障检测率 (FDR) , 定义为用规定的方法正确检测到的故障数与故障总数之比。
(2) 故障隔离率 (FIR) , 定义为用规定的方法将检测到的故障正确隔离到不大于规定模糊度的故障数与检测到的故障数之比。
(3) 虚警率 (FAR) , 定义为规定的时间内发生的虚警次数与故障指示总数之比。
1.2 诊断方案
诊断是检测和隔离故障的过程, 通过对产品施加激励以产生可测量的响应, 进而确定产品是否发生故障并查明故障的原因。常用的诊断技术包括机内测试、自动测试、人工测试等。
诊断方案是对产品诊断的总体构想, 包括诊断对象、范围、功能、要求、方法、维修级别、诊断要求和诊断能力。诊断方案的确定, 应考虑产品的使用要求和维修体制等多方面要素。
2 基于模型的测试性分析方法
2.1 测试性模型
测试性模型是为了分析、评定设备测试性而建立的物理模型和数学模型。通过测试性模型, 可以为测试性分配、预计和评价, 以及进行测试点优化和诊断策略设计提供依据。
测试性模型按照形式、用途不同, 有多种分类。其中, 基于多信号流的相关性模型是进行测试性预计、测试性设计分析的重要模型。相关性模型描述产品组成的单元结构、功能、故障模式、故障与产品测试之间的关系。
相关性模型的建模方法可以通过人工绘制图示模型和相关性矩阵进行计算分析, 但对于复杂系统或设备, 交联关系复杂, 计算工作量剧增。使用商业化的工具软件可以加快建模过程, 同时简化测试性设计分析工作。目前, 常用的测试性设计分析软件有TEAMS、e Xprss、TADS等。
2.2 基于模型的测试性设计分析流程
(1) 在产品FMECA基础上, 进行故障模式与测试方法分析;
(2) 然后根据产品设计信息以及FMECA结果, 使用工具软件进行建模;
(3) 通过测试性模型, 进行故障检测率和故障隔离率初步预计;
(4) 通过调整、优化测试点信息, 优化测试性设计。最终反作用于产品设计。
2.3 不同阶段测试性建模的要求
测试性模型的建模工作应尽早开展, 随着产品设计的深入, 进行迭代工作, 不断细化模型。
方案设计阶段, 在缺少详细故障模式信息的情况下, 测试性模型主要反映产品结构、功能、故障与测试之间关系, 用于优选诊断方案和测试性分配和预计。
在工程研制阶段, 在故障模式信息已经具备的情况下, 可以细化产品故障模式与测试之间的关联模型, 用于优选测试点和诊断策略。
3 测试性建模及设计改进
3.1 建模前准备工作
测试性建模前的一个重要准备工作是进行故障模式与测试方法分析。故障模式与测试方法分析是在产品FMECA基础上, 收集和分析与故障检测、故障隔离相关的测试性信息, 形成《FMECA----测试性信息分析表》。
在分析的过程中应注意以下问题:
(1) 分析的深度和范围决定于测试性要求、维修级别、产品的复杂程度, 对于基层级和中继级均有测试要求的设备, 分析深度要达到内场可更换单元 (SRU) ;
(2) 分析工作是逐步深入和细化的过程, 在不同研制阶段分析的重点有所不同;
(3) 可参照GJB/Z 1391-2006《故障模式、影响及危害性分析指南》和相关文件提供的程序和方法, 进行功能和硬件的故障模式与测试方法分析;
(4) 注意收集和分析检测参数、测试点、检测隔离方法等测试性资料, 如BIT检测、自动测试设备检测和人工检测等。
3.2 测试性建模过程
本文以TADS软件为例, 描述测试性建模的过程。
3.2.1 建立层次化的产品结构
TADS软件支持系统、分系统、子系统、LRU、SRU等多个层次, 可根据产品自身特点, 建立层次化的产品结构。
3.2.2 完善模块信息, 建立SRU级连线
根据产品自身的交联关系特点, 定义LRU、SRU的端口, 不同的端口可用于通过不同类型的信号。然后将LRU、SRU间的端口使用连线进行连接, 故障模式可以通过相应的端口在SRU之间传播。
3.2.3 添加故障模式
根据之前《FMECA----测试性信息分析表》的内容, 在SRU级模块节点下添加故障模式, 并完善故障模式的基本信息, 如定义故障模式, 添加失效率参数等。
3.2.4 建立故障模式之间、故障模式与端口之间连线
根据产品功能原理、工作运行方式等信息, 建立SRU内故障模式间, 以及故障模式到SRU端口间的连线。故障模式间的连线可以反映故障模式间的传导关系。
3.2.5 细化模型
根据产品和故障模式的自身特点, 在故障模式内设置信号的阻隔和转换。
3.2.6 增加测试点
在确定SRU模块间故障模式的传递关系后, 根据《FMECA----测试性信息分析表》中测试方法情况设置测试点。测试点是产品中可执行测试的位置, 一个测试点可以有多种测试方法。
3.2.7 模型修正
模型的构建是由简到繁、逐步完善的过程, 随着对产品认识的深入不断的完善模型, 尽量准确的反映现实产品的工作情况。
3.3 测试性预计
建立测试性模型后, 可以根据模型进行测试性预计工作。使用TADS软件建立的相关性模型, 其本质是通过图形化的建模界面建立模型, 通过软件自动建立的故障模式与检测方法的相关性矩阵。根据此相关性矩阵可简便的计算出故障检测率和故障隔离率。
通过TADS软件中定量分析功能, 选择适当的分析层次和检测方法, 可以得到特点检测方法的故障检测率和故障隔离率。
3.4 测试性设计分析和改进
除了测试性指标, TADS软件可以进行定性分析, 以便进行测试性设计分析和优化改进工作。
TADS的定性分析功能, 主要得到以下分析结果:
a.未检测到的故障模式;
b.故障模式模糊组;
c.冗余的测试项目;
当故障检测率不满足要求时, 可以查询未检测到的故障模式清单, 对未能检测的故障模式的失效率和增加该故障模式测试的难易程度进行权衡, 选择实现难度最小, 同时提高检测率指标最明显的故障模式, 在适当的位置新增测试点, 以提高故障检测率。
当故障隔离率不满足要求时, 与上述提高检测率方法类似, 查询故障模式模糊组, 在适当的位置新增测试点来检测隔离故障。
根据定性分析中冗余的测试项目可以对测试点进行优化。如果某冗余测试点中测试方法自身设计硬件BIT检测电路, 且测试电路自身失效率较大, 则可以进行考虑删除该测试点。
4 一些注意问题
测试性模型是测试性预计、测试性设计分析等工作基础, 其真实性、准确性直接影响后续测试性分析工作。测试性建模过程中需要注意一些问题:
4.1 可靠性预计值要准确
FMECA分析中, LRU、SRU故障模式的失效率计算依据元器件的失效率。如果元器件的失效率预计偏差较大, 会导致最终测试性分析的结果偏差较大。
4.2 测试方法尽量细化
故障模式的检测方法要分类清楚, 并且符合实际情况。如果一个故障模式有多种检测方法, 要将多种检测方法分别列出。TADS软件进行测试性指标分析时支持特定的检测方式, 将检测方法细化有利于后续设计分析。
5 总结
测试性是设计出来的。测试性模型是分析、评价产品测试性的有效手段。使用测试性模型进行设计分析, 可以发现产品设计缺陷, 通过采取有效的措施改进, 在进度和费用约束下满足测试性要求。
受限于模型的准确性、有效性, 通过模型分析计算的测试性指标不能作为考核产品测试性要求的手段。但是, 掌握基于模型的测试性设计分析方法, 可以快速有效的进行测试性设计、分析、改进工作, 提高产品的测试性水平。
参考文献
[1]石君友.测试性设计分析与验证[M].北京:国防工业出版社, 2011.
[2]田仲, 石君友.系统测试性设计、分析与验证[M].北京:北京航空航天大学出版社, 2003.
测试模型 篇11
关键词：灰系统,灰预测,GM(1,1)模型,过程控制,性能测试
1 引言
自灰色预测模型[1]提出以来,就一直有在过程控制中应用的研究报道[2,3,4,5]。在20世纪90年代,甚至有灰色预测控制器的新产品面世[6]。尽管曾有专家非常看好灰色预测控制器应用推广前景,但后来的发展证明:已开发的灰色预测控制器还是存在着应用缺陷,尚未具有取代传统PID调节器的实力。为了更好地认清灰色预测模型用于过程控制时的限制条件和应用问题,有必要展开对灰色预测模型的动态特性测试和性能分析。
一个典型的灰色预测控制系统如图1所示。这种基本的灰色预测控制方法可简述为:用灰色预测模型去预测被控量y而得到z,反馈控制器所依据将是新的偏差e=r-z。最常用的灰色预测模型是单变量一阶灰色预测模型GM1(,1)。在应用中需要设定的参数有,采样周期h、建模维数n和预测步长k。
文献[7]指出:“灰色预测方法有理论依据和实用价值。但是灰色预测方法也存在一定的局限性,仅适用于原始数据非负、符合或基本符合指数规律变化且变化速度不是很快的场合”。
文献[8]指出:“在灰色预测控制中,预测步长对控制性能的影响较为显著。以系统阶跃响应为例,当采用大的预测步长时,控制器输出较为保守,能防止系统产生较大的超调,但响应速度慢、上升时间长。当预测步长小时,控制器输出变化剧烈,系统响应速度加快,上升时间短,但超调增大”。
文献[9]指出:“灰色预测的GM1(,)1模型的预测精度与建模维数有关。仿真结果表明,对波动较大的工业过程来说,维数大并不一定对控制有利。因为,老信息太多往往会淹没新信息的特点,使预测对系统的波动反映迟缓.跟踪性变差。当然,若要突出其滤波作用,维数可取大点。综合考虑,建模维数一般取为n=5为宜”。
文献[1 0]指出:“当系统进入稳态后,GM1(,)1的输入序列各值将全部相等,白化方程的参数a=0,这将导致预测值失准,反而使本应处于稳态的系统趋于发散”。
还有,采样周期的选取将直接影响灰色预测的精度。采样周期过大时,灰色预测误差的急速增长有可能恶化控制系统的动态性能,甚至破坏系统的稳定性。
对于上述对灰色预测模型性能的评价观点,这里将不从理论方法的角度深入讨论他们是否成立,而想通过专门设计的性能测试试验来求证。为此,在以下展开的测试试验中特别设计了负信号、非指数规律信号和快变信号输入测试,预测步长对预测精度的影响测试,建模维数对预测精度的影响测试,对白化方程的参数a的观测试验,以及采样周期的选取对预测精度的影响测试项目。最后,综合分析了所得到的灰色预测模型用于过程控制的测试结果,归纳了灰色预测模型用于过程控制的限制条件和动态特性特点。
2 灰色预测模型性能测试试验设计
专为测试灰色预测模型性能的试验系统设计如图2所示。其中,测试信号发生模块可产生所需的负信号、非指数规律信号、指数规律信号和快变信号等信号(y(t)、y(t+kh));数据采集模块负责采集灰色预测模型所需的序列数据(y(t-(n-)1h)、y(t-(n-2)h)、……、y(t));灰色预测模型模块可对测试信号进行标准的灰色预测GM(1,1)运算并输出预测值z(t+kh)及模型参数值a,灰色预测模型自身的三个参数(采样周期h、建模维数n和预测步长k)是可以调整的;响应曲线绘制模块用来实现预测响应、预测误差及模型参数变化曲线的绘制和显示。
灰色预测特性测试信号采用以下四种:
(1)负信号(正弦信号)
测试用的负信号是利用正弦函数产生的,如式1所示。其中,角频率为ω。这是一种正负交替的周期信号。
(2)非指数规律信号
利用式2所示的函数产生测试用的非指数规律信号。为保证信号的非负性,加上了2这个静态偏置数。
(3)指数规律信号和快速变化信号
利用如式3所示指数函数产生测试用的指数规律信号和快速变化信号。用式3产生的信号,其动态变化规律是指数规律,其变化率在初始时刻最大,可用式4算出。当需要指数规律信号时,令时间常数T=1即可。当需要快速变化信号时,可通过调整时间常数T来调整变化率的大小,T越小,变化率越大。
3 灰色预测模型性能测试响应
采用上述的测试系统和测试信号,通过MATLAB编程方法可进行所需的灰色预测模型特性测试。所获得的试验响应结果和初步分析如下。
1)负信号测试试验
当选用式1产生的正弦波作测试信号时,灰色预测模型的试验响应如图3所示。图中展示有三条曲线,分别是输入信号的当前值y(t)、k步后的值y(t+kh)和灰色预测值z(t+kh)。遵从系统分析的单因素试验法则,取预测步长k=0。根据灰色预测原理及算法,既使取预测步长k=0,灰色预测值z(t+kh)表示的是对当前值的预测,它也是根据n步前的初值y(t-(n-1)h)推算出来的。因此,取k=0,照样能体现灰色预测模型特性,而且可避开灰色预测步长变化因素带来的影响。下述的试验项目中,除预测步长影响试验项目外,都采取了k=0的处理,这样就符合了单因素试验法则,使试验数据更有说服力。由图3可见,在正弦波的过零处,输入信号的当前值曲线y(t)和k步后的值曲线y(t+kh)重合在一起,但灰色预测模型的输出曲线z(t+kh)出现了异常的尖脉冲。这部分证实了灰色预测模型不能用于负输入数据的说法。但是,更确切地说,应当是灰色预测模型不适于用于具有从正到负的过零变化的输入数据。
2)非指数规律信号试验
当测试信号是式2描述的非负的非指数规律信号时,灰色预测模型的试验响应如图4所示。可见预测曲线和实际曲线重合,这说明对于非指数规律信号,灰色预测模型能很好地跟踪和预测。所以,那种认为灰色预测模型仅适用于符合指数规律变化信号的观点是不能确立的。但是,当把图4所示响应时系统所用的采样周期值增大10倍后,就得到了如图5所示的响应。这时,灰色预测模型对当前值的预测就有了明显的偏差。可以注意到,在正弦波的波峰和波谷处的预测误差明显偏大。这又说明灰色预测模型对于不符合指数规律变化的信号,相比指数规律变化的信号,其预测误差可能会大许多。
当测试信号是式3描述的信号时,分别取T=1秒、T=05.秒、T=0.3333秒,据式4可得到等差变化的信号最大变化率:1、2、3(1/秒)。进行试验后可得如图6所示的灰色预测模型的响应。可见,灰色预测模型的预测误差和输入信号的变化率成正比,输入变化越快,预测误差越大。不过,这个误差受采样周期选值的影响很大。见图7和图8。当T=05.秒时,选较小的采样周期h=0.0 5秒时,预测误差还不明显。但是,选采样周期h=0.1秒时,在最大变化率信号处(初始时刻)的预测误差就太大了(注意图中那条严重上翘的曲线)。所以,可以推断,在采样周期不变的前提下,灰色预测模型所能适用的输入信号的变化率有一个上限。当输入信号
3)快速变化信号试验
为便于研究预测模型参数对预测精度的影响,不妨定义灰色预测模型的预测误差ε(t)如式5所示。
的变化率超过这个上限后,就会产生不能容忍的预测误差。
4)趋于不变信号试验
当输入信号趋于稳态,不再变化时,灰色预测模型的响应有可能出现发散振荡的不稳定状况,如图9所示。理论分析表明[10]:当输入信号趋于稳态时,灰色预测模型的参数a将收敛于0,而灰色预测模型输出的计算式中有项,于是可能出现被零除的数值不稳定情况。事实上,在图9所示动态过程中,还可观察到参数a的收敛过程,见图10。其收敛值约为1.1e-016。这个试验证实了灰色预测模型不能处理输入信号趋于不变的工况。而在过程控制中,使被控量趋于不变恰恰是控制的主要目标。特别是在用有限位长的单片机实现灰色预测模型计算时,小于一个量化单位的数值就被圆整为零,所以在灰色预测模型在实际中应用时更容易发生被零除的事故。
5)预测步长影响试验
在建模维数和采样周期不变的前提下,分别令预测步长为等差递进的三个数值来进行试验,可得到如图11所示的预测误差响应曲线。很明显,预测误差随预测步长的增大而增大,并且增大的速度不是等差的,而是越来越快。
6)建模维数影响试验
在预测步长和采样周期不变的前提下,分别令建模维数为等差递进的三个数值来进行试验,可得到如图1 2所示的预测误差响应曲线。很明显,预测误差随建模维数的增大而增大,并且增大的速度基本上是按算术级数的。
7)采样周期影响试验
在预测步长和建模维数不变的前提下,分别令采样周期为等差递进的三个数值来进行试验,可得到如图13所示的预测误差响应曲线。可见,预测误差随采样周期的增大而增大,并且增大的速度基本上是等差的。但是,从图4、图5、图7和图8所示的试验结果看,预测误差随采样周期的线性变化关系还不一定总是成立。在非指数规律信号输入时,或是在快变信号输入时,采样周期的增大也存在一个上限,超过了这个上限值,预测误差就可能急速增长。因此,更全面的推论或许可表述为:在预测步长和建模维数及采样周期的设定初值相对于输入信号的变化规律和频带宽度都较为适合的前提下,预测误差随采样周期的正比例变化;若其他参数无限制,则存在一个采样周期的安全设置的上限值。
4 结束语
综上所述,针对过程控制应用背景,灰色预测模型有如下七种特性:1)不适用于从正到负或从负到零的过零变化输入数据序列;2)对于不符合指数规律变化的信号也能适用,但相比指数规律变化信号的预测误差可能会大许多;3)在采样周期不变的前提下,所能适用的输入信号的变化率有一个上限,否则可能产生较大的预测误差;4)当输入信号趋于稳态时,灰色预测模型的参数将a收敛于0,于是可能出现被零除的数值不稳定情况;5)预测误差将随预测步长的增大而快速增大;6)预测误差将随建模维数的增大而线性增大;7)在其他参数较适合的前提下,预测误差随采样周期的增大而线性增大,否则存在一个安全上限值。
以上观点是依据实验研究方法得出的。若从理论角度论证,还有待研究。部分论述结果见文献[11]。
参考文献
[1]邓聚龙.灰色预测与决策[M].武汉:华中工学院出版社,1986.
[2]黄春岑,于向军,吕震中.基于灰色预测PID球磨机负荷控制[J].自动化仪表,2007,28(3):62-64.
[3]胡兆庆,毛承雄,陆继明.基于灰色预测的发电机励磁控制系统[J].电力系统及其自动化学报,2002,14(1):30-33.
[4]程启明,闵乐聪,李芹,王志萍.火电厂钢球磨煤机负荷的灰色PID控制系统研究[J].热能动力工程,2009,24(5):630-634.
[5]付建强,周志锋.灰色预测PID在水压控制系统中的应用[J].电子科技,2006,(10):45-47.
[6]李学文.新型工业过程自动控制调节器--灰色预测控制器[J].中国仪器仪表,1994,(5):28.
[7]吉培荣,胡翔勇,熊冬青.对灰色预测模型的分析与评价[J].水电能源科学,1999,17(2):42-44
[8]周自强,陈绍炳,谭浩艺,章毅.过热汽温非线性灰色预测控制研究[J].浙江电力,2009,(1):1-4.
[9]毕效辉,姚琼荟.灰色预测在过程控制中的应用[J].西南工学院学报,1997,12(3):11-16.
[10]刘宪林,杨建,王明东.励磁控制系统灰色预测PID控制仿真研究[J].郑州大学学报(工学版),2006,27(2):70-72.
【测试模型】推荐阅读：
性能测试模型07-29
统一测试模型08-22
软件测试改进模型研究05-10
不同函数模型测试题四道08-30
布线测试之进场测试05-12
软件测试中回归测试08-18
模型组织07-14
提升模型07-15
稳态模型07-17
演示模型07-17