软件测试方法策略（精选12篇）
软件测试方法策略 篇1
0 引言
随着现代化软件开发技术的发展和软件功能需求的日益复杂,软件开发中出现错误或缺陷的机会越来越多。同时,市场对软件质量重要性的认识也逐渐增强,导致了软件测试在软件项目实施过程中的重要性日益突出,软件测试已成为软件开发的一个重要环节。
1 定义
软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程[1]。正确认识软件测试的定义是十分重要的,它决定了测试方案的设计。
2 软件测试方法
软件测试方法研究以最少的测试数据来测试出程序中更多的潜在错误,如何测试得彻底,如何设计测试数据是测试的关键技术[5]。从是否需要运行被测软件的角度,可分为静态测试和动态测试;从是否针对系统的内部结构和具体实现算法的角度来看,可分为白盒测试和黑盒测试。
(1)静态测试
静态测试在对软件代码进行分析、检查和测试时不实际运行被测试的程序,同时这种测试方法还可以用于对各种软件文档进行测试。例如对需求文档的验证和确认,系统设计文档的检查以及程序代码的检查。
(2)动态测试
动态测试就是通过运行软件来检验软件的动态行为和运行结果的正确性。动态测试的主要特征是计算机必须真正运行被测试的程序,通过输入测试数据,对其运行情况进行分析。
(3)黑盒测试(功能测试)
在黑盒测试或功能测试中,测试条件主要是基于程序或者系统的功能,测试人员不需要了解程序是如何运作,只是关注程序的功能是否与规格说明书所描述的一致。
(4)白盒测试(结构测试)
在此项测试中,测试条件是基于程序逻辑,测试人员查看程序或者系统的内部机构。测试人员需要了解内部程序结构和逻辑,关注生产出来的代码,而不需理会其功能是否与说明书上的功能相同。
3 软件测试步骤
一个大型软件系统通常由若干个子系统构成,每个子系统又由若干个模块构成。软件测试分以下几个步骤[2]:
(1)单元测试:又称模块测试。它是针对软件设计的最小单位———程序模块进行正确性检验的测试工作,其目的在于发现各模块内部可能存在的各种差错。
(2)集成测试:通常在单元测试的基础上,需要将所有模块按照设计要求组装成为系统,对与设计相关的软件体系结构的构造进行测试。
(3)确认测试:又称有效性测试。它的任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
(4)系统测试:是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起。
4 软件测试策略
为了检验开发的软件是否符合规格说明书的要求,测试活动可以采用各种不同的策略。这些策略的区别在于它们表明了不同的出发点、不同的思路以及采用不同的手段和方法[4]。但总的来说,遵循如图一展示的原则。
开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
单元测试常常是和代码编写工作同时进行的,在完成了程序编写、复查和语法正确性验证后,就应进行单元测试用例设计。
在单元测试时,如果模块不是独立的程序,需要设置一些辅助测试模块。辅助测试模块有两种:
(1)驱动模块(Drive)。用来模拟被测试模块的上一级模块,相当于被测模块的主程序。它接收数据,将相关数据传送给被测模块,启动被测模块,并打印出相应的结果。
(2)桩模块(Stub)。用来模拟被测模块工作过程中所调用的模块,它们一般只进行很少的数据处理。
驱动模块和桩模块都是额外的开销,虽然在单元测试中必须编写,但并不需要作为最终的产品提供给用户。被测模块、驱动模块和桩模块共同构成了一个如图二所示的单元测试环境[3]:
确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
系统测试是把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。
5 结束语
软件测试是所有工程学科的基本组成单元,是软件开发的重要部分。软件测试是为了发现故障而执行程序的过程,其目的是以尽可能少的时间和人力发现并改正软件中潜在的各种故障及缺陷。如何利用较少的测试用例,实现最大的测试覆盖,最大限度地发现软件瑕疵,是软件测试的目标之一;制定完善的测试计划、测试方案、结果分析、文档资料管理,亦是保证软件测试功效的前提。软件测试只能查找程序中的错误,不能证明程序中没有错误。
参考文献
[1]陆璐,王柏勇.软件自动化测试技术[M].北京:清华大学出版社,2006.
[2]郭群.软件测试设计技术[J].电脑知识与技术,2007,(17).
[3]Robert Culbertson Chris Brown Gary Cobb著.王海鹏译.快速测试[M].北京:人民邮电出版社,2004.
[4]DustinE,RashkaJ,PaulJ著.于秀山,胡兢玉等译.软件自动化测试:引入、管理与实施[M].北京:电子工业出版社,2003.
[5]黄爱明.国内软件测试现状及对策研究[J].中国管理信息化,2007.
软件测试方法策略 篇2
课件教学作为一种先进的教学手段和理念走入了课堂教学中，课件教学省时多变优势，加大课堂容量，增强信息反馈，提高了练习技能，把课堂空间真正还给了学生。上课时教师轻松，容易控制上课进程，在制作PPT的时候，有时候需要对PPT进行编辑，比如添加新的幻灯片，比如复制。移动已有的幻灯片，现在将介绍PPT插入、复制和移动幻灯片的方法。在幻灯片中插入图片和声音等对象。
ppt插入幻灯片简易操作：
① 新建幻灯片-功能区命令法。单击功能区上的“插入”，在展开的选项卡中选择“新幻灯片”。
② 新建幻灯片-快捷菜单命令法。选择一张幻灯片，然后单击鼠标右键，就会弹出一个快捷菜单，在快捷菜单中找到“新幻片灯”选项，点击即可。
ppt复制幻灯片简易操作：
① 复制幻灯片—功能区复制法。这个和上述增加幻灯片不同的是，它是点击功能区上的“编辑”键，在展开的菜单中选择复制。然后将鼠标的光标移到需要粘贴的位置，单击“粘贴”选项即可完成复制粘贴了。
② 复制幻灯片-快捷菜单法。选定所需要复制的幻灯片，然后单击鼠标右键，在弹出的快捷菜单中选择“复制”这一选项，接下来和上面的粘贴法一致即可。
ppt移动幻灯片简易操作：
① 移动幻灯片同样有三种方法，一是单击功能键上的“编辑”，在展开的选项卡中选择“剪切”，然后按照上述方法在所需的位置进行粘贴即可。② 选择所需要移动的幻灯片，然后单击鼠标右键，在弹出的快捷菜单中，选择“剪切”这一功能，然后再“粘贴”即可。
③ 直接选择幻灯片，鼠标拖至合适的地就松开即可。
PPT在幻灯片中插入声音简易操作：
① 在要出现声音的第一张幻灯片中单击主菜单“插入/影片中的声音/文件中的声音（或剪辑库中的声音等）”，选择一声音文件，在弹出的对话框“是否需要在幻灯片放映时自动播放声音”中选择“是”，在幻灯片上显示一喇叭图标。
② 右击该喇叭图标，选择“自定义动画”中的“多媒体设置”项，选择“按动画顺序播放”，播放时“继续幻灯片放映”，停止播放在“5张幻灯片后”。
③单击“其他选项”，选择“循环播放，直到停止”。
ppt灯片中插入图片简易操作：
① 打开PowerPoint软件，点击“插入”→“图片”→“新建相册”，在弹出的【相册】窗口中选择“文件/磁盘”，选择本地磁盘中需要批量插入的所有图片，点击“插入”。②
在新弹出来的【相册】窗口中，设置好各类参数，尤其重要的是“图片版式”和“相框形状”的设置，这里以将“图片版式”设置为“1张图片”，“相框形状”设置为“圆角矩形”为例。
面向对象软件测试方法研究 篇3
关键词：软件测试；面向对象；类测试
中图分类号：TP311 文献标识码：A 文章编号：1674-7712 （2013） 24-0000-01
面向对象软件测试技术是针对使用面向对象技术开发的软件而提出的一种测试技术。面向对象开发技术和传统开发技术相比有新的特点，使用面向对象技术开发的程序具有高质量、高效率、易扩展、易维护等优点，这也给它的测试技术带来新的挑战。面向对象软件测试与传统的软件测试相比，由于面向对象技术开发的软件会出现传统软件技术中不存在或者不突出的错误，使得传统的软件测试中次要方面成为了现在的主要问题，影响了软件测试的方法和内容，增加了软件测试的难度。
一、软件测试
（一）软件测试
软件测试是使用人工操作或者利用测试工具按照测试方案和流程对软件产品进行功能和性能方面的评估，检验软件产品是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。
（二）面向对象对软件测试的影响
面向对象软件具有抽象性、封装性、继承性和多态性等特点，这些特点对软件测试产生了不同的影响。面向对象程序中子类可以继承父类的功能，父类进行了充分测试后，子类也要设计相应的测试用例进行充分测试，对子类进行测试时不仅要测试子类中的方法，还要重新测试与子类中重定义方法相关的类。面向对象软件测试时，对象的状态通常是信息隐蔽的，测试人员需要在测试类中添加适当的信息来表明对象的实现方法及其内部状态。对于面向对象软件的多态性形成的动态绑定的测试使用传统的静态分析策略是不合适的，需要使用动态的测试标准来解决这个问题。
二、面向对象软件测试方法
面向对象软件测试方法是从传统的软件测试方法中演化而来的，有与传统的软件测试相类似之处，但由于面向对象的软件开发具有继承性和多态性等特点，为了支持和加强数据隐藏的特性，面向对象的软件测试必须向一个类的接口添加操作，所以说面向对象的软件测试方法更复杂一些。
（一）面向对象软件单元测试
面向对象软件单元测试主要是类测试，包括方法测试和对象测试。类是面向对象程序设计的基本单位，对象是类的具体实例，类测试是来验证类的实现和类的说明是否完全一致，如果类的实现是正确的，那么类的每一个具体实例的行为也将是正确的。
面向对象的类测试首先要确定测试方法，通常可以通过代码检查和执行测试用例两种方法来测试类的代码。代码检查方法容易受人为错误的影响，在代码量很大的情况下也会加大它的工作量，而编写一个好的测试用例需要很丰富的经验和较高的技巧。通过类实现的功能来分析所要编写的测试用例，然后根据类的边界值来扩充测试用例。构建测试用例一般是基于前置条件或后置条件，为所有可能出现的情况及情况的组合确定测试用例的需求，在这些可能出现的情况组合下，根据这些需求来构建测试用例，而且还要针对实际情况创建特定输入值的测试用例，并确定它们的正确输出。
测试驱动程序是一个运行测试用例并能够收集运行结果的程序。在面向对象的软件测试中，设计核心类的测试驱动程序十分重要，要求该程序必须思路严谨、结构简单清晰并易于维护。当确定了类的可执行测试用例，测试驱动程序就要创建类的实例来运行该测试用例，并给出测试用例运行的测试结果。
（二）面向对象软件集成测试
面向对象软件集成测试主要是类簇测试。面向对象软件是由若干对象组成的，这些对象互相协调合作来实现软件的功能，在面向对象的软件开发中，对象间的相互协调即对象的交互对于程序的正确性来说是非常重要的，对象的交互方式决定了程序能做什么，从而也就决定了程序是否正确。对象的交互测试是在对类的单独测试的基础上实现的，它来确保对象之间相互传递消息的正确性，它一般执行测试的是嵌入到应用程序中的交互对象。
在面向对象的软件测试当中，除了要考虑对象交互特征面之外，还需要具体的测试技术去实现测试的要求，目前常用的面向对象软件集成测试的方法有抽样测试和正交阵列测试。抽样测试提供了一种运算法则，不需要首先明确测试用例的总体，从一组可能的测试用例中选择测试序列；正交阵列测试是一种特殊的抽样方法，它通过定义一组交互对象的配对方式组合来进行测试，同时要尽量限制测试组合的配置数目，正交阵列测试系统就是挑选某个样本的特定测试技术。
（三）面向对象软件系统测试
在对面向对象软件进行系统测试时，要保证被测系统的完整性，搭建与真实用户实际使用环境相同的测试平台，并且需要参考面向对象分析的结果，对软件的架构进行验证，确保软件可以完全再现问题空间以及完整实现用户需求。系统测试不仅是要检测软件的整体功能行为表现，也是对软件设计开发的再确认，它针对的是非功能需求的测试，包括功能需求以外的所有需求以及注意事项等。系统测试是针对完整软件产品的测试，包括软件、软件运行所依赖的硬件、外设、数据、支撑软件及接口等，确保开发的软件与其依赖的各种资源能够协调运行，形成完整的软件产品。系统测试是软件测试过程中非常重要的阶段，它对测试技术的要求也是最高的。在进行面向对象软件的系统测试时，测试技术人员需要与软件的用户进行交流，根据用户提出的需求给出系统的修改建议，结合用户需求对被测试软件进行测试分析，根据分析结果建立测试用例。
三、结束语
面向对象的软件测试技术是面向对象软件开发中的重要组成部分，本文从面向对象软件的特点出发，分析了面向对象软件测试对传统软件测试的影响，介绍了面向对象软件测试的方法。
参考文献：
[1]王艳丽.面向对象软件簇级测试用例自动生成方法研究与实现[D].长春工业大学，2011.
软件测试方法策略 篇4
软件测试是软件开发过程中必不可少的过程,其目的在于找出软件中潜在的错误或缺陷。一般而言,软件测试根据软件开发过程中规格和结构设计的测试用例进行,输入数据并运行程序,测试输出结果与预期的区别,以发现软件的错漏之处。因此,软件测试贯穿着软件开发的全过程,对于规范化设计软件意义重大。为了能用更少的测试用例来达到最大覆盖、查缺的结果,软件测试需要选用科学合理的策略。
1 软件测试策略
在软件测试之前,首先需要确定的是测试策略,它是软件测试的模板。软件测试策略一般分为2种:传统测试策略、现代测试策略。
传统软件测试策略将软件测试置于软件开发的最后阶段,在软件设计完成后才开始进行测试,对软件测试的重视程度缺乏。这种传统策略的缺点在于可能会导致软件开发前期中产生的错误缺漏不能被及时发现,为软件测试增添压力,也不利于软件测试得出详细、全面的分析结果。传统软件测试策略遵循的瀑布模型如图1所示。
现代测试策略能更好地强调了软件测试的重要性和贯通性。它将软件测试贯穿于软件开发全过程中,根据每一阶段进行详细的分析记录,以实现软件测试功用的最大发挥。现代软件测试策略具体内容如下:第1步,确定测试目的。根据不同软件的特性和要求确定好测试目的,只有确定了目的,才能够更好地进行软件测试;第2步,确定测试对象及范围。对象包括整个系统、子系统、模块、某变量等,测试范围覆盖功能、性能、恢复性等方面,将软件测试集中于特定对象和范围,能够达到事半功倍的效果;第3步,选择、描述测试环境和方法。第4步,记录并跟踪测试过程,最后得出测试结果。现代软件测试策略遵循的是双V模型,如图2所示。
2 软件测试方法简述
软件测试的目的和对象众多,因此其方法和手段也具有多样性。本文将对其中较基本的几种软件测试方法进行简述。
2.1 静态测试与动态测试
软件测试按使用的测试技术不同可以分为静态测试和动态测试2个阶段。
其中,静态测试是以文档文件、源程序做结构分析、数据定义控制等为基础,对软件进行分析,在不实际运行被测试的软件的情况下,找寻软件的逻辑设计错误。静态测试可以分为静态分析和代码审查,代码审查是一种人工测试方法,包括代码评审和走查,它的运用是测试人员通过经验来阅读程序的代码,发现软件编码和运行上的缺陷、错误。它采用的具体方法主要有:检查分析文档资料、寻找逻辑错误、讨论分析决定、利用工具审查程序代码等。
动态测试则是基于测试用例,通过运行软件来检验被测系统的动态行为,以动态的运行进行测试分析。动态测试两要素分别是被测试程序和测试用例,它的适用范围主要在单元测试、集成测试、验收测试等阶段。
2.2 黑盒测试与白盒测试
黑盒测试更侧重用功能性,又称为功能测试,它是将被测对象视为封闭的黑盒,不考虑其内部程序和结构,基于规格说明书对程序接口运行动态测试的方法。它着眼于验证软件功能正确性,根据软件产品的功能设计规格求证是否符合软件预期功能性要求,主要试图发现几类错误:功能不正确或遗漏、界面错误、输入和输出错误等。白盒测试与黑盒测试相对,把测试对象看做一个打开的盒子,更侧重于软件结构性测试,又被称为结构性测试。在计算机上按照程序内部的逻辑结构及相关信息进行测试,求证内部操作的规范性,并扩大软件覆盖程度。白盒测试是对软件细致的检查,它在不同点检查程序状态,在细节上更为注意。白盒测试主要采用逻辑驱动、基路测试等方法,它是穷举路径测试,因此,这一方法需要一定的前提,即测试者需要了解检查程序内部结构和逻辑,以此为基础确定测试数据。
2.3 积极测试和消极测试
积极测试是以验证软件是否符合需求为目的,通过输入一个积极值(即有效值)的方法进行有效性设置,因为它是直接输入数值并期望得到有效测试的方法故又称为正向测试。消极测试与之相对,又称反向测试,其原理是输入消极值(即无效值),看是否能得出输入值无效的结果。积极测试在于检测软件系统是否能有效运行,消极测试则是要中断软件执行,测试软件是否限定在有效范围内运行。一般来说,消极测试的方法更为开放,因此其测试用例数量远超过积极测试,消极测试是一种非常开放的测试方法。一般来说,消极测试用例的数量要远远大于积极测试用例的数量。
3 测试方法的应用
3.1 单元测试
单元测试是针对模块进行检测,通过测试来求证模块功能性和正确性。模块是软件设计中最小的单位,由于它规模小,功能单一,逻辑简单,因此在测试中选用白盒法和黑盒法结合、一个为主、另一辅助的手段。测试者在了解模块说明和源程序的基础上,明确被测模块的I/O条件及其逻辑结构,然后通过白盒法,利用测试用例最大覆盖的进行检测,同时以黑盒法加以辅助,达到内外逻辑、结构都彻底检测的结果,使任何合理、不合理的输入都能得到正确响应。
3.2 集成测试
集成测试是针对组装起来的模块进行检测,以寻找接口的问题和缺漏。将模块按照设计要求进行组装然后检测能够发现跟接口相关的一些问题:如数据丢失、模块间有害影响、组合功能偏差等。集成检测在软件检测过程中介于单元测试和系统测试之间,它对软件结构性能的测试起着承上启下的重要作用,通常,集成检测阶段会采用黑盒法和白盒法结合的方法。
3.3 系统测试
系统测试阶段旨在检查系统是否符合软件需求,相较于前2个阶段更为复杂,这是因为软件开发过程中任何变动都会改变功能的增删,需要根据情况不断更改程序,而更改完的程序也可能因为一些问题会重新测试。系统测试需要检测软件功能、用户界面、安全性等方面,对全面性和客观性要求较高,因此,在系统测试阶段中采用的测试方法一般是黑盒方式。鉴于系统测试的特殊性,其测试应由独立测试小组来执行,针对系统测试中各单元模块,一般组合按照自下而上法、自上而下法、隔离测试法相结合的先后顺序进行检测。
3.4 验收测试
验收测试是由用户执行的体验测试,这一阶段和系统检测除了执行者外没有很大区别,验收测试的目的是向未来用户展示软件运行的能力和有效性,其主要任务是验证软件是否符合用户的要求和期待。
在这4个测试过程完成后,软件基本上能够满足开发要求,然后提交给开发部门进行调整补缺最后交给用户。
4 结语
软件测试密切关系到软件的质量和用户满意程度,对于软件开发具有至关重要的作用,其重要性在近些年越来越凸显,受到人们的重视。为了更好的适应软件开发的进步和发展,软件测试的策略和方法也应当向适应大规模、复杂软件的方向转变,通过不断在应用中总结经验进行完善,更好地在软件测试中选用科学、合理的策略方法。
摘要：软件测试是软件开发过程中十分重要的一环。文章基于软件测试的策略和方法,探讨其在软件开发过程中的应用,着重探讨如何使软件测试工作高效而可靠地运行。
软件测试做事方法总结 篇5
中医讲究望闻问切，我觉得我们做事的方式方法也可以按照这四点进行归纳。
望（细心观察、多留心）
1、看现象，特别是偶然问题，细心观察，留意步骤
a.对测试过程中只出现过一次的异常现象，可以先记录下来，或者与研发沟通，宁可错杀不可放过。b.对bug保持敏感度，相信自己的眼睛，针对偶然现象反复推敲，从自己的网络环境，拓扑结构入手，尝试复现。
c.低概率问题难以复现，需要先搭好抓包环境，遇到问题保存log，并记住时间点。
2、看用例，认真阅读，细心执行
a.测试过程用例在不断完善，执行用例要到位，认真阅读用例的预置条件、测试步骤、预期结果，有疑问要及时提出，用例结果要备注。b.执行用例的步骤不能遗落，结果要每条都对应。
c.预期结果不符要同需求、软件一起确认，并将结果告知三方。有变更时需要同步修改用例，并将bug提至mantis，评审bug时需要关注。
3、看mantis，经常查看mantis上bug状态
a.看自己的bug，对开发人员的备注多关注。研发人员备注的bug原因自己要搞懂。不清楚的一定要问。对概率问题研发备注未重现的，要问清楚log分析结果，是否需要协助重现等。
a.看别人提交的bug，一是避免bug重复提交，二是可以学习和思考，为什么别人可以发现这个bug，我没发现；或者我是不是也遇到同样问题，但是忽略了等等。b.评审过后的bug备注认真看。评审后的bug会备注一些专业意见可以学习，评审后的bug也会备注一些需要测试后续进行的工作要关注并执行。
4、看版本发布记录
a.版本发布后详细阅读版本发布记录，确认修改的每个点是否同计划一一对应，同研发确认是否修改点都一一列出。未列出的点会带来哪些影响。b.版本修改点影响范围是否列出，需重点测试模块是否有写明。
闻（认真倾听，反复思考）
1、听信息
a.项目前期反复讨论需求、方案时，是不是所有信息有掌握了，通过反复思考提出自己的意见或建议。
b.需求有变更时，要详细的了解清楚变更点。
c.认真倾听测试代表的版本计划，版本范围及版本测试中应重点关注的地方。
2、听经验
a.对自己不清楚的问题，认真听别人的分析讲解，从而思考从这个点拓展到面。b.Bug评审时认真听每个bug的分析情况，进而思考自己遇到这个问题如何处理，反思自己的测试方法。
c.听听别人同研发人员如何沟通，学学沟通方式和技巧，沟通的过程我要了解哪些信息，掌握哪些关键点和关键路径。
d.分享时听其他人的经验，进行借鉴。
问（不懂就问、不耻下问）
1、问bug a.遇到无法判断是不是bug的问题，问有经验的同事，问测试代表，问测试经理。b.遇到偶然问题，先问问其他同事是否也有遇到，可以一起思考一起找茬，尽快突破。c.同研发意见不一致时及时反馈测试代表，协商解决。
d.对研发备注的原因，大胆提出质疑，多问几个为什么，多对比，了解来龙去脉，不要被研发带偏。
e.Bug评审时需要测试人员跟踪压力的bug要多问，问问是否有可复现的路径，研发是否可以协助。
2、问方法
a.对自己无法解决的或者要花很长时间消化的，要多问，多学习，可以提高效率，避免不必要的时间浪费。
b.对自己不熟悉的模块，要多问经验丰富的同事，借鉴好的测试方法。
c.对流程不熟悉的，多问问研发人员，详细的了解流程，才能制定对应的测试方案。
切（找出问题、对症下药）
1、多看多听多问，相信大部分问题都能准确定位。针对少数不能定位的问题，bug评审给出结果，需要压力的进行压力，需要观察的进行观察。可以同研发人员一同协商制定方法。
2、已解决的问题也要多思考，解决这个问题是否会影响到其他模块，验证时要考虑全面。
基于多平台的计算机软件测试方法 篇6
关键词：多平台 计算机 软件 测试方法
中图分类号：TN791 文献标识码：A 文章编号：1674-098X（2015）07（a）-0059-01
近年来，我国的科学技术日新月异，计算机与互联网已经渗透到日常生活的方方面面，软件行业竞争呈现白日化状态，软件公司为了提升编写软件的质量，编写完成后会进行软件测试，达到最大程度降低软件的错误及漏洞，满足用户需求。然而，软件工程的复杂性日益增加，加上软件本身的特殊性，因而真正意义上的完美、无漏洞的软件是不存在的，软件测试除了检查错误，还能及时加以修复。而实际运用中依据软件的特点会选择多个平台进行软件测试，以达到软件质量的最优。
1 软件测试平台相关概念
1.1 软件测试平台的定义
软件测试平台的出现是在不断的探索过程中发现的，最初进行软件测试比较的繁琐，编写好软件程序之后，需要将对应的功能输入到软件上，使得对象的功能得以实现，经过一定时间的软件运行后得出测试结果，以此反推总结出软件所遇到的漏洞与问题[1]，此种方法有很大缺陷，只能就软件的相应功能加以测试，但是无法真正检测其他功能，检测效率较低，检测时间长，大大制约了软件开发的发展。
众所周知，一个软件所包含的功能众多，需要对所有的功能在测试中逐一进行检测，势必会大大增加软件开发的负担，此时需要一种能高质量、高效率的软件检测方法，经过多次反复的尝试，可以将输入指令、不同功能的检测，软件运行等多种功能集中于一个平台之上，在这个平台进行测试中所有的环节，这样就构成了一个完整的软件测试平台[2]。在进行软件检测过程中，通过软件测试平台，可以将所有功能依次检测，用轻松运用多种工具进行测试，高效、便捷深受软件开发人员的青睐。
1.2 软件测试平台的特点
软件测试平台的运行环境：在利用软件检测平台对软件进行检测中，为了确保不出现问题，需要创造一个良好的运行环境，有利于测试平台更加准确、快速，并及时的发现存在的问题加以修复，环境对于软件检测的顺利运行是不可或缺的一部分，需要注意起来。
软件在投入市场使用之前，必不可少的一环就是进行软件测试，当代是信息化时代，软件升级速度加快，所具有的功能更复杂、多样，这就给软件测试增加难度，对于软件测试平台的要求也更严格。在运用软件平台检测时候需要屏蔽检测一项功能的同时，对于其他功能不造成干扰，才能确保软件检测的准确性、稳定性[3]。随着软件技术的不断发展，软件监测平台的广泛运用能够极大提高检测效率，不必将功能与逻辑功能都分开检测，而可以直接对全部功能加以检测，降低软件自身的漏洞与存在问题发生率，确保软件的准确性。
1.3 较为常见的软件测试平台
随着软件行业的迅猛发展，软件测试平台为了满足软件行业的需求而经过不断的研发使得软件测试平台也日益增多，较为常见的如：PARASOFT ALM RUAN软件检测平台在集成化的测试平台中很受欢迎[4]，在进行软件测试之初，PARASOFT够公司已经在软件测试方面有一定的成就，这款平台是专门的为软件测试而研发的，对于软件的问题的检测会更加彻底，当前国际知名软件公司也一直在使用这个平台。
Test Center软件测试平台是备受青睐的一个平台，属于一个通用平台，各种不同类型的软件都可以进行测试，此平台有一定的随时运行的优势，主要用途是应对是软件测试开发的需要。在这个平台的运用中，能够使得软件开发的周期极大的缩短，大大提高软件开发的效率，它涉及到众多的模块，可以针对不同类型的软件加以测试。
2 基于多平台的计算机软件测试方法分析
2.1 多平台计算机软件测试方法分析
多个平台计算机对软件进行测试的时候，人们需要引起重视的是保持几个平台之间的协调性，测试平台所属的开发公司不同，使得人机交换界面、使用习惯等都大相径庭，此时将多个平台对一个软件测试，会出现许多配合相关的问题，因而实际测试过程中，需要根据软件本身的特点，而有的放矢的执行一个科学合理的测试方法。
先从测试软件的核心模块着手，将软件的主要功能认真的测试，对于测试平台的选择上没有什么特殊要求，若是有针对性的测试平台[5]，可以第一时间优先选择，就不用所有软件使用通用的测试平台，如此能极大提升测试效果，在进行测试中，一旦发现了存在的漏洞及时进行修改，之后在进行下一个平台的测试，只能软件比较稳定为止，如此的逐一的进行测试，不断的重复下去，将多个平台都检测没有问题后，软件测试全部工作才算顺利完成。
2.2 多平台计算机软件测试的必要性
实际生活中软件测试时候，软件公司会选用一定的软件测试平台进行测试，平台选择上不容小觑，恰当的平台选择，能极大提高软件测试的准确性、效率高。随着互联网与计算机的普及，软件行业成为“香饽饽”备受人们的关注，随之兴起的软件测试平台也迅猛发展，大致上可以分为专业型、全面型。专业型测试平台侧重的是针对软件某个功能加以测试，具有针对性因而这个功能可以细致的被找出可能存在的问题，缺点是如果软件中包含很多的功能，测试需要花费较多时间；全面型可以对软件中的全部功能加以测试，准确性难以保障；因而，应该实事求是，针对性的选择最佳的平台完成测试，才能达到事半功倍的效果。
3 结语
21世纪是信息时代，互联网与计算机的普及推动软件程序开发的异军崛起，对于软件的测试也是不可或缺的一环，基于多平台的技术算计软件检测中，应该恰当的运用合适的软件检测平台，才能最大限度降低软件中的问题与缺陷，以实现软件的稳定性。
参考文献
[1]徐曌.浅谈多平台的计算机软件测试[J].信息通信，2014（11）：135-135.
[2]易敏捷.基于多平台的计算机软件测试方法分析[J].科技传播，2013（20）：202-203.
[3] 付宇.基于多平台的计算机软件测试方法分析[J].电脑知识与技术，2014（9）：1981-1982.
[4]陈小辉.Web性能测试技术的研究与实践[D].华东师范大学，2010.
软件测试方法策略 篇7
软件测试是软件在投入运行之前, 对软件需求分析、设计规格说明和编码的最终复审, 是保障和提高软件质量的关键步骤和重要手段[4]。该课程涉及的基础知识较广, 对学生的学习基础要求高, 理论知识也相对枯燥。下面以软件测试中的“等价类黑盒测试法”一课为例, 在现有的教学资源环境下, 以讨论式教学法为主体, 将讲授法、案例法等教学方法综合运用到课堂中, 努力提高软件测试课堂教学效果。
一、讨论式教学法在软件测试课堂中运用实例
授课内容:等价类黑盒测试法。
教学目的:掌握等价类方法中类的划分, 会写测试用例。
教学重点:理解等价类测试法划分类的规则, 根据等价类表写测试用例。
教学难点:使用等价类划分法对类的划分。
教学方法:讲授、讨论式及案例教学法相结合, 用实例及讨论突破重点难点。
授课过程:
(一) 复习提问
1. 软件测试的方法分为哪二类?
2. 在软件测试中, 最重要的一项工作是什么?
3. 什么是测试用例, 测试用例的原则是什么?
此处提出三个问题, 一个问题是新授课涉及的、以往学过的基础内容;另两个问题则是上节的核心内容, 同时引出本节课学习的目标。复习的内容不能仅仅是上节学过的知识, 更要对新授课内容起到铺垫作用。
(二) 新课的问题导入:写出测试下面程序功能的测试用例
问题导入的目的是要说明“做事需要讲究方法”。我们可以写出测试用例, 但哪些是必需的、哪些是冗余的用例呢?一个看起来似乎很容易解决的问题, 学生的答案各不相同, 哪个是正确的答案?为什么是正确的?这大大地激发了学生的学习兴趣。以此给出本节课的学习内容和学习目标。
(三) 新课
1. 等价类划分法的含义。
2. 讲解基本概念:有效等价类、无效等价类, 正面测试用例、负面测试用例。
3. 例题:返回到新课导入的例子中, 对程序的输入进行等价类的划分。
4. 进一步引出:等价类测试法的关键是类的划分原则。
分析导入时的问题, 用讲授法讲解新授的理论知识, 并进一步通过例题加深理解。在这一过程中, 让学生体会到测试用例设计的不唯一性, 特别是无效等价类, 更依赖于人的经验和思维习惯。由此, 进一步思考等价类法中类的划分原则。
(四) 学生分组讨论:对等区间划分的原则
1. 如果某个输入条件规定了取值范围或值的个数, 则可确定一个有效等价类 (输入值或数在此范围内) 和两个无效等价类。
2. 如果规定了输入数据的一组值, 而且程序对不同的输入值作不同的处理, 则每个允许输入值是一个合理等价类。此外, 对这组值以外的所有值确立一个无效等价类。
3. 如果已划分的等价类中各元素在程序中的处理方式不同, 则应将此等价类进一步划分为更小的等价类。
4. 如果规定了输入数据必须遵循的规则, 可确定一个合理等价类 (符合规则) 和若干个不合理等价类 (从各种不同角度违反规则) 。
在这一环节中, 学生针对课件中的应用案例, 讨论各种情况下对等区间划分的原则, 并进一步总结归纳成规则。每组选出代表表述出各自总结的规则, 并写在黑板上, 再综合对比各组成果, 归纳成相应的规则, 最后, 由教师总结及补充, 归纳成完整的板书。经过充分的讨论, 学生不仅讨论了教材中提及的情况, 还进一步扩展讨论了软件测试时可能遇到的其他情况, 使学生的主动性和创造性都得到了发展。
(五) 实例练习
设有一个档案管理系统, 要求用户输入以年月表示的日期。假设日期限定在1990年1月—2049年12月, 并规定日期由6位数字字符组成, 前4位表示年, 后2位表示月。现用等价类划分法设计测试用例, 来测试程序的“日期检查功能”。
在深刻理解等价类的划分原则之后, 要将理论运用到解决问题的实践中去。此时, 在热烈的讨论氛围中, 学生希望能运用上面所学的知识, 各组独立完成测试用例设计, 再由教师评判打分, 击败对方。
(六) 总结测试用例设计的步骤
1. 划分等价类后, 在列出的等价表中, 为每一个等价类编号。
2. 设计一个测试用例, 使其尽可能多地覆盖尚未被覆盖过的有效等价类。重复这一步, 直到所有有效等价类被测试用例覆盖。
3. 设计一个测试用例, 使其只覆盖一个无效等价类。
事实上, 各组基本完成了任务, 不过在软件测试用例设计的步骤和细节处理上, 仍有不足。此时, 教师在点评的过程中讲解软件测试用例的设计步骤及规则, 让学生豁然开朗, 达到事半功倍的效果。在教师的引导下, 学生总结出设计测试用例的步骤。
(七) 总结与作业
1. 本节内容
(1) 理解基本概念:等价类划分法。
(2) 理解两对名词:有效类和无效类;正面测试用例和负面测试用例。
(3) 等价类的划分原则:对等价类划分的依据。
(4) 确定测试用例设计的步骤。
2. 作业
(1) 用等价类法写出测试城市电话号码是否输入正确的测试用例。
(2) 预习常与等价类法配合使用的边界值分析法。
最后, 利用大约五分钟的时间总结本节课的主要内容。黑板上重点内容一目了然, 这是在讲解过程中的板书。两项作业, 一项是对本节内容的实战练习, 另一项是对下次授课内容的预习。
二、运用讨论式教学法应注意的问题
在高校的软件测试教学中, 传统的讲授式教学方法仍然是让学生掌握基本的理论知识的最佳选择, 其地位无可取代。在本节课的学习中, 学生在教师讲授相关基础知识后, 才能有后面讨论的基础。在使用讨论式教学法的过程中, 教师通过精心准备的问题逐步引导学生自主进行辩论和思考, 帮助学生梳理出解答问题的不同路径, 进而使学生得出结论。我们将学生分组, 通过项目驱动教学, 引导学生主动思考, 系统探究知识原理、使用规则及注意事项等。在此过程中, 每个学生都自主思考, 通过激烈的、全神贯注的讨论, 提出问题和回答对方提问, 在争辩和讨论中加深理解。再通过教师的点评和讲解进一步理解掌握等价类法中类的划分方法, 并学会设计测试用例。讨论的方式使教学重点渐渐清晰明了, 各组讨论成果的展示和对比激发了学生的学习热情, 也能更好地理解教学重点和难点———划分类的原则, 最后通过实例归纳总结的测试用例的设计步骤, 使学生能够真正设计出符合测试要求的软件测试用例, 达到本节的教学目的。“总结和作业”环节是对本节内容的总结和巩固, 让学生在课后进一步消化理解, 为后面的学习打下坚实基础。
需要注意的是, 在课堂教学中, 无论是讲授法的导入, 还是讨论式教学的问题讨论, 都要注意引导学生主动思考的问题难度一定要适宜, 既不能过于简单, 要符合学习规律的认识梯度, 让学生感觉到挑战;也不能太难, 让大部分学生即使绞尽脑汁也无计可施。为调动班级整体的学习积极性, 课堂中的问题难度应根据实际授课内容按易、中、难设置, 让基础差的学生有会答的题目, 不失去听课的兴趣, 让基础好的学生也能感觉到充满挑战。
教学无止境, 它不仅仅是知识的更新, 更是对教学效果孜孜不倦的追求。在授课过程中, 教师只是引导者、组织者和合作者, 要突出学生的主体作用。从学生角度综合选择教学方法、设计教学过程、安排教学活动, 激发学生学习欲望, 调动学生的积极性, 引导学生主动思考, 使学生的主观能动性、观察力和创造力得到充分的发展。
参考文献
[1]蒋宗珍.大学课堂教学中讨论式教学的组织[J].重庆教育学院学报, 2011, (1) .
[2]梁中贤.高校讨论式教学之哲思[J].中国高等教育, 2011, (15/16) .
[3]王明莉.大学课堂讨论式教学法运用的策略研究[J].黑龙江高教研究, 2011, (11) .
软件测试方法策略 篇8
随着电子、电气、计算机、控制理论与控制工程等科学技术的发展, 飞机电子设备类型、数量和工作方式愈来愈多, 频率覆盖范围不断扩展, 发射功率愈来愈大, 接收灵敏度愈来愈高, 飞机机载设备与系统受电磁干扰的影响越来越大。电磁干扰不仅影响系统的正常工作, 而且还可能造成飞行事故[1,2,3]。飞机的电磁兼容性问题主要是由于机载设备间的相互干扰引起, 其中设备的传导干扰是主要的干扰方式。传导干扰主要是机载设备产生的干扰信号通过导电介质或公共电源线互相产生干扰。
为了考核机载设备的电磁兼容性能, 几乎所有的机载电子设备都要求必须通过国家军用标准规定的电磁兼容性试验测试。在GJB151A—1997[4]和GJB152A—1997[5]对设备或分系统的电磁兼容传导发射和敏感度试验要求和试验方法做出了明确的规定。在GJB 72A—2002[6]中对分系统和设备的关键性类别进行分类。
在很多情况下, 飞机上多个机载设备同时出现电磁兼容传导干扰故障, 无法满足GJB151A—1997中关于传导发射和传导敏感度试验要求。但是目前没有一个合理可行的电磁兼容传导干扰故障修复方法, 无法确定出现电磁兼容传导干扰的机载设备整改顺序优先级关系, 往往使电磁兼容整改工作耗时、反复和成本增加, 甚至导致飞机无法按时定型、批量生产。
2 传导发射及敏感度测试超标策略
2.1 传导发射测试超标策略
根据GJB151A—1997和GJB152A—1997中CE102测试项目要求和方法, 得到CE102的测试曲线和极限值曲线, 如图1所示。同时, 将所有机载设备CE102的测试曲线采用集合形式表达为Tce (f发射) ={Tce1 (f发射) , Tce2 (f发射) , …, Tcem (f发射) }。并将所有机载设备CE102的极限值曲线采用集合形式表达。
2.2 传导敏感度测试超标策略
根据GJB151A—1997和GJB152A—1997中CS114测试项目要求和方法, 得到CS114的测试曲线和极限值曲线, 如图2所示。与上节相似, 将CS114的极限值曲线Scs (f敏感度) 超过CE102测试曲线Tcs (f敏感度) 的部分称为传导敏感度超标区域, 所述传导敏感度超标区域如图2中的剖面线所示。
3 计算电磁兼容分类指标和权重
根据GJB 72A—2002中对分系统和设备的关键性类别分类原则, 列出m个机载设备电磁兼容分类指标EML={eml1, eml2, …, emlm}。
根据国军标GJB 72A—2002《电磁干扰和电磁兼容性术语》中2.1.56节, 分系统及设备的关键性类别之规定:所有安装在系统内的, 或与系统相关的分系统及设备均应划定为EMC关键类中的某一类。这些划分基于电磁干扰 (EMI) 可能造成的影响、故障率、或对于指派任务的降级程序。可分为以下三种:
(1) Ⅰ类这类电磁兼容问题可能导致寿命缩短、运载工具受损、任务中断、代价高昂的发射延迟或不可接受的系统效率下降;
(2) Ⅱ类这类电磁兼容问题可能导致运载工具故障、系统效率下降, 并导致任务无法完成;
(3) Ⅲ类这类电磁兼容问题可能引起噪声、轻微不适或性能降级, 但不会降低系统的预期有效性。
4 计算电磁兼容传导干扰权重期望
根据不同机载设备电磁兼容传导干扰权重期望值EEMC按照从大至小进行排序, 然后, 依据排序后的机载设备进行电磁兼容传导干扰故障修复。
5 实例
设定三个机载设备对整机电磁兼容性都会产生传导干扰, 在GJB151A和GJB152A中CE102、CS114电磁兼容试验中得到三个机载设备的测试曲线, 对超标部分进行量化处理和数据处理, 得到传导发射指标权重和传导敏感度指标权重。同时根据国军标GJB 72A—2002对分系统及设备的关键性类别之规定, 得到电磁兼容分类指标权重。综合传导发射指标权重、传导敏感度指标权重和电磁兼容分类指标权重, 即可得出机载设备电磁兼容传导干扰权重期望, 确定三个机载设备电磁兼容传导干扰故障修复顺序。如表1所示:
根据三个机载设备电磁兼容传导干扰权重期望值的大小, 对三个机载设备电磁兼容传导干扰故障修复顺序进行排序, 首先修复第三机载设备传导干扰故障, 其次修复第二机载设备传导干扰故障, 最后修复第一机载设备传导干扰故障。
6 结束语
本文提出了一种采用传导测试超标策略对传导干扰故障修复的优化方法, 该方法利用传导发射曲线和传导敏感度曲线分别与国军标要求进行对比, 并得到超标区域;采用面积积分对超标区域进行量化, 得到传导发射指标权重、传导敏感度指标权重;最后结合机载设备电磁兼容分类权重、传导发射指标权重、传导敏感度指标权重得到机载设备电磁兼容传导干扰权重期望。该方法依靠指标量化和权重分配提出一种将机载设备电磁兼容传导干扰故障与整机电磁兼容性联系在一起, 综合考虑各机载设备电磁兼容传导发射、传导敏感度、电磁兼容性分类等因素, 并进行指标量化和相应的权重分配, 得到机载设备传导干扰故障对整机电磁兼容性的影响程度, 确定机载设备电磁兼容传导干扰故障修复顺序的优先级, 为确定电磁兼容整改的先后顺序提供了依据。
摘要：为了量化分析机载设备传导干扰超标值对于整机电磁兼容性的影响程度, 本文重点研究如何利用传导测试超标策略对传导干扰故障的修复。通过联合测试系统、指标量化和权重分配, 将机载设备电磁兼容传导干扰故障与整机电磁兼容性联系在一起, 综合考虑各机载设备电磁兼容传导发射、传导敏感度、电磁兼容性分类等因素。本文优化了指标量化和相应的权重分配, 得到机载设备传导干扰故障对整机电磁兼容性的影响程度, 确定机载设备电磁兼容传导干扰故障修复顺序的优先级, 为确定电磁兼容整改的先后顺序提供了依据。
关键词：传导测试,传导干扰,故障修复,指标量化,重量分配
参考文献
软件测试方法概述 篇9
在开发软件的过程中, 人们使用了许多保证软件质量的方法分析、设计和实现软件, 但难免在工作中犯错误。这样, 在软件产品中就会隐藏许多错误和缺陷。对于规模大、复杂性高的软件更是如此。在这些错误中, 有些是致命的错误, 如果不排除, 就会导致生命与财产的重大损失。这种情况迫使人们必须认真计划、彻底地进行软件测试[3,6]。
为了保证软件的质量和可靠性, 应力求在分析、设计等各个开发阶段结束前, 对软件进行严格的技术评审。但由于人们能力的局限性, 审查不能发现所有的错误。而且在编码阶段还会引进大量的错误。这些错误和缺陷如果遗留到软件交付投入运行之时, 终将会暴露出来。但到那时, 不仅改正这些错误的代价更高, 而且往往造成很恶劣的后果。
软件测试就是在软件投入运行前, 对软件需求分析、设计规格说明和编码的最终审查, 是软件质量保证的关键步骤。如果给软件测试下定义, 可以这样讲:软件测试是为了发现错误而执行程序的过程。或者说, 软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例 (即输入数据和预期的结果) , 并利用这些测试用例去运行程序, 以发现错误的过程[1,2]。
软件测试在软件生存期中横跨两个阶段:通常在编写出每一个模块之后就对它做必要的测试 (称为单元测试) 。编码与单元测试属于软件生存期中的同一阶段。在结束这个阶段后, 对软件系统还要进行各种综合测试, 这是软件生存期的另一阶段, 即测试阶段。
现在, 软件开发机构将研制力量的40%以上投入到软件测试之中的事例越来越多。特殊情况下, 对于性命攸关的软件, 例如飞行控制、核反应堆监控软件等, 其测试费用甚至高达所有其他软件工程阶段费用的总和的3~5倍。
1 软件测试的目的和原则
基于不同的立场, 存在着两个不同的测试目的。从用户的角度出发, 普遍希望通过软件测试暴露软件中隐藏的错误和缺陷, 以考虑是否接受该产品。而从软件开发者的角度出发, 则希望测试成为表明软件产品中不存在错误的过程, 验证该软件已正确第实现了用户的要求, 确立人们对软件质量的信心。因此, 他们会选择那些导致程序失效概率小的测试用例, 回避那些易于暴露程序错误的测试用例。同时, 也不会着意去检测、排除程序中可能包含的副作用。显然, 这样的测试对完善和提高软件的质量毫无价值。因为在程序中存在着许多预料不到的问题, 可能会被疏漏, 许多隐藏的错误只有在特定的环境下才能暴露出来。如果不把着眼点放在尽可能查找错误这样一个基础上, 这些隐藏的错误和缺陷就查不出来, 会遗留到运行阶段中去。如果站在用户的角度, 替他们设想, 就应当把测试活动的目标对准揭露程序中的错误。在选取测试用例时, 考虑那些易于发现程序错误的数据。
有鉴于此, Grenford J.Myers就软件测试的目的提出以下观点:
(1) 测试是程序的执行过程, 目的在于发现错误;
(2) 一个好的测试用例在于能发现至今未发现的错误;
(3) 一个成功的测试用例是发现了至今未发现的错误的用例。
测试的目标是以最少的时间和人力找出软件中潜在的错误和缺陷。如果成功地实现了测试, 就能够发现软件中的错误。测试的附带收获是, 它能够证明软件的功能和性能与需求说明相符。此外, 实施测试收集到的测试结果数据为可靠性分析提供了依据[4,5]。
根据这样的测试目的, 软件测试的原则是:
(1) 应当把“尽早地和不断地进行软件测试 (Check early, check often) ”作为软件开发者的座右铭。
由于原始问题的复杂性, 软件的复杂性和抽象性, 软件开发各个阶段工作的多样性, 以及参加开发各种层次人员之间工作的配合关系等因素, 使得开发的每个环节都可能产生错误。所以不应该把软件测试仅仅看作是软件开发的一个独立阶段, 而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审, 这样才能在开发过程中尽早发现和预防错误, 把出现的错误克服在早期, 杜绝某些隐患, 提高软件质量。
(2) 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
测试以前应当根据测试的要求选择在测试过程中使用的测试用例。测试用例主要用来检查程序员编制的程序, 因此不但需要测试的输入数据, 而且需要针对这些输入数据的预期输出结果。如果对测试输入数据没有给出预期的输出结果, 那么就缺少了检验实测结果的基准, 就有可能把一个似是而非的错误结果当成正确结果。
(3) 程序员应避免检查自己的程序。
测试工作需要严格的作风、客观的态度和冷静的情绪。人们常由于各种原因具有一种不愿否定自己工作的心理, 认为揭露自己程序中的问题总不是一件愉快的事。这一心理状态就成为测试自己程序的障碍。另外, 程序员对软件规格说明理解错误而引入的错误更难发现。如果由别人来测试程序员编写的程序, 可能会更客观, 更有效, 并更容易取得成功。要注意的是, 这点不能与程序的调试相混淆。调试由程序员自己来做可能更有效[7,8]。
(4) 在设计测试用例时, 应当包括合理的输入条件和不合理的输入条件。
合理的输入条件是指能验证程序正确的输入条件, 而不合理的输入条件是指异常的, 临界的, 可能是引起问题异变的输入条件。在测试程序时, 人们常常过多地考虑合法的和期望的输入条件, 以检查它是否做了它应该做的事情, 而忽视了不合法的和预想不到的输入条件。事实上, 软件在投入运行后, 用户的使用往往不遵循事先的约定, 使用了一些意外的输入, 如用户在键盘上按错了键或打入了非法的命令, 如果开发的软件遇到这种情况时不能作出适当的反应, 给出相应的信息, 那么就容易产生故障, 轻则给出错误的结果, 重则导致软件失效。因此, 系统软件处理非法命令的能力也必须在测试时受到检验。用不合理输入条件测试程序时, 往往比用合理的输入条件进行测试能发现更多的错误。
(5) 充分注意测试中的群集现象。
测试时不要以为找到了几个错误问题就已解决, 不需要测试了。经验表明, 测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律, 应当对错误群集的程序进行重点测试, 以提高测试投资的效益。
在所测试程序段中, 若发现错误数目多, 则残存数目也较多。这种错误群集性现象, 已为许多程序的测试实践所证实。这种现象对测试很有用。如果发现某一程序模块似乎比其它程序模块有更多的错误倾向时, 则应当花费较多的时间和代价来测试这个程序模块。
(6) 严格执行测试计划, 排除测试的随意性。
测试计划应包括:所测试软件的功能, 输入和输出, 测试内容, 各项测试的进度安排, 资源要求, 测试资料, 测试工具, 测试用例的选择, 测试的控制方式和过程, 系统组装方式, 跟踪规程, 调试规程, 以及回归测试的规定等以及评价标准。
对测试计划, 要明确规定, 不要随意解释。
(7) 应当对每一个测试结果做全面检查。
这是一条最明显的原则, 但常常被忽视。有些错误的征兆在输出实测结果时已经明显地出现了, 但是如果不仔细地全面地检查测试结果, 就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义, 对实测的结果仔细分析检查, 抓住征候, 暴露错误。
(8) 妥善保存测试计划, 测试用例, 出错统计和最终分析报告, 为维护提供方便。
测试可以采用自顶向下或自底向上进行, 自顶向下测试先从全系统开始, 再测试每个子模块;自底向上测试先从子模块测试开始, 逐步测试各子模块的父模块, 最后进行全系统综合测试。模块测试的目的是验证是否和规格相符。
进行模块测试必须考虑两件事:测试用例的设计和测试模块的规模。测试用例可从规格或分析模块代码产生, 相应的测试策略分为黑盒测试和白盒测试, 并有两种方法和它们进行组合———非增量与增量测试。非增量测试分别对每个模块进行测试, 然后组装成系统, 不再进一步测试;而增量测试对每一个模块和被测试过的模块进行组合测试。增量测试能更早地检测出错误。自顶向下或自底向上测试它们均基于这样的假设:模块的调用关系为有向无环图。
线索测试是一种增量测试方法, 它的基础是从需求变化而来的系统验证图。另一种测试策略认为测试应从软件开发的早期开始。
2 测试标准
在对系统进行验证中, 规格作为对代码进行验证的标准。程序必须满足两种规格:一是需求标准, 它描述系统的自然功能 (What) ;二是设计标准, 它描述系统的逻辑 (How) 。因此, 需要发现两类错误:其一是功能错误, 它偏离了需求规格;其二是设计实现错误, 即逻辑错误。理想情况下, 需求规格是明晰的、完备的、简明的、可以理解的, 并且不存在二义性。但实际上, 需求规格几乎总是不完备的、模棱两可的、易于变化的。因此, 一个软件系统可以被验证 (满足需求规格) , 但仍存在不满足要求的部分, 因为规格本身是不完备的、模棱两可的、甚至是错误的。软件验证中的许多问题是因错误的规格引起的。并且由于代码的规模、复杂性, 以及软件本身的进化规律使得软件开发满足规格是困难的, 有时甚至是不可能的[9]。
3 验证
存在两种系统验证:一是系统发布前进行的;二是对系统进行维护时。系统验证一般是由与开发小组独立的小组完成的, 其中一至两人充当质量控制经理与组内其他人员独立。
尽管70%的精力花在对系统的维护上, 但系统的重新验证仍未被重视。有两个理由使得重新验证是必要的:一是修正错误;二是修改系统的能力。重新验证检验修正是否正确、修改是否实现, 以及修改是否对系统的其它方面产生影响。完善的文档、功能局部化以及良好的模块定义使得重新验证较为容易一些[10]。
4 黑盒测试
在黑盒测试 (或称功能测试) 中, 不考虑程序的内部结构和表现, 其目的是确定程序的输入与输出是否与其规格一致, 力图发现以下几类错误:
是否有不正确或遗漏了的功能?
在接口上, 输入能否正确地接受?能否正确地输出结果?
是否有数据结构错误或外部信息 (例如数据文件) 访问错误?
性能上是否能满足要求?
是否有初始化或终止性错误?
黑盒测试的主要缺点是依赖于规格的正确性 (实际情况并非如此) 和需要采用所有可能的输入作为测试用例才能保证模块的正确性。
5 白盒测试
在该方法对软件的过程性细节做细致检查, 对程序所有逻辑进行测试。通过在不同点检查程序的状态, 确定实际的状态是否与预期的状态一致。测试用例从程序的逻辑中产生。确定程序逻辑覆盖有几条原则, 其中之一是语句覆盖, 要求程序中的每条语句至少执行一次。这条原则是必要的, 但不充分, 因为部分错误并不能检测出来。
6 从上至下测试
从上至下测试从程序的顶点模块开始, 然后逐步对较低级的模块进行测试。为了模仿被测试模块的低级模块, 需要哑模块或桩子模块。
从上至下测试的主要好处就是排除了系统测试和集成, 它可以让人们看见系统的早期版本并证明系统的正确性。它的效果之一可以提高程序员的士气。
从上至下测试的主要缺点是需要桩子模块, 并且在桩子模块中的测试数据直到输入输出模块加入之前不能确定。某些模块的测试数据难以创建, 因为桩子模块不能模拟数据流使得模块之间的数据流不能组织成有向无环图。
7 从下至上测试
从下至上测试策略从程序的最低级模块 (不调用别的模块) 开始。为了模拟高一级的模块需要驱动模块。当对所有的低一级模块测试完毕才对高一级模块进行测试。
从下至上测试方法的优点之一是测试数据的建立不存在困难。尽管数据流不在有向无环图中, 但驱动模块模拟所有的调用参数, 如果关键模块位于调用模块的底部, 则从上至下测试方法更优。
从下至上测试的主要缺点是系统的早期版本直到最后模块测试完毕才产生, 并且设计和测试一个系统不能重叠进行, 因为不可在低级模块设计之前进行测试。S
摘要：软件测试是软件质量的重要保证, 对软件测试的目的、原则、标准做了简介, 同时介绍了几种常用的软件测试方法。
关键词：软件测试,需求分析,软件质量
参考文献
[1][美]Jeffrey Richter.Windows95Windows NT3.5高级编程技术[M].郑全战, 阿夏, 译.清华大学出版社, 1998年2月.
[2]郑人杰, 殷人昆, 陶永雷.实用软件工程[M].2版.清华大学出版社, 1997年4月.
[3][美]Allen G.Taylor.SQL使用指南[M].吴言, 李东, 等, 译.电子工业出版社, 1999年3月.
[4][美]James R.Groff&Paul N.Weinberg.关系数据库SQL使用指南[M].付增少, 彭振云, 等, 译.学苑出版社, 1999年10月.
[5]William Perry.Effective Methods for Software Testing[M].1998by John Wiley&Sons, Inc.
[6]Boris Beizer.Software Testing Techniques (Second Edition) [M].1999by International Thomson Computer Press.
[7]Brian Marick.The Craft of Software Testing—Subsystem Testing Including Object-based and Object-oriented Testing.PTR Prentice Hall, Englewood Cliffs, New Jersey07632.
[8]Richard E.Fairley.Tutorial:Static Analysis and Dynamic Testing of Computer Software.1978IEEE, Computer.
[9]Thomas Jaudon Ball.The Use of Control-flow and Control Dependence In Software Tools.1993University of Wisconsin Madison.
基于蚁群算法优化软件测试策略 篇10
随着计算机技术的日益成熟,硬件成本迅速降低,各种结构复杂、功能强大的计算机系统被广泛应用到航空航天、交通运输、核电能源和医疗卫生等安全关键领域,软件质量日益成为被关注的焦点。针对如何确保软件开发质量问题,虽然已经提出了许多技术和方法,但迄今为止,软件质量主要还是要靠软件测试来保证。软件测试是软件开发过程中一个十分重要并且成本昂贵的过程,如何优化软件测试过程,减少软件测试成本,提高测试效率的研究具有十分重要的意义。
目前, 软件测试过程的优化已经成为测试技术研究的一个重要方向,选择好的测试用例集不仅能减少软件测试的工作量,降低软件测试的成本,而且在不会降低软件测试质量的前提下,提高软件开发的速度,从而使系统及早投入使用,参与市场竞争。因此如何精选少量的测试用例,提高软件测试的缺陷检测能力,降低测试成本是软件测试优化研究中最关注的核心问题。
在软件测试优化的研究中,大多数关注软件测试策略及测试过程的一些基本性质,例如,测试用例的缺陷检测能力、测试数据的复杂性和测试成本等。而与之相反,如何设计并优化这些测试策略正逐渐引起人们的关注: 给定测试目标,例如:软件可靠性、覆盖水平等,如何设计、优化测试策略来实现这个目标。基于测试过程,利用随机过程、统计学原理、运筹以及决策理论,可以有效地减少测试用例数量,缩短测试持续期,是解决软件测试优化问题的有效途径。基于测试过程,文献[1,2,3]从控制论角度研究了测试数据的选择策略, 将软件测试处理成一个控制问题,对软件测试提出了Markov控制方法,将被测软件作为控制对象,软件测试策略作为相应的控制器,用动态规划方法较好地解决了测试资源受约束时的软件测试优化,并提出了适应测试策略、在线调整软件测试策略。文献[4]讨论了带操作剖面的软件测试优化问题。软件投放前,所有操作序列以一种控制行为被测试,其最优测试策略由一个非线性动态规划决定。文献[5]运用博弈理论, 分析软件测试的动态过程及其诸影响因素之间的关系,提出了一种新的软件测试过程博弈模型,并在此基础上对测试过程中的各方决策条件和博弈均衡条件进行了讨论,从理论上分析和解决“测试策略选择”和“何时停止测试”等问题。基于统计学原理,文献[6]提出了单风险序贯测试方法,从实质上看,该方法只是对概率序贯测试方法作了一定的改进,成效不显著。随后,文献[7]基于统计测试研究了安全攸关系统的软件可靠性演示问题,将测试处理成测试、分析和维修过程,用动态规划方法给出了在事先确定的时间内,以整个过程成功的概率最大为目标,如何选取测试行动的最优测试策略。近来,文献[8]在分析软件测试用例选择过程的动态现象时,将软件测试过程处理为线性动力系统,从理论上研究了软件测试的动态行为,利用形式化方法量化分析整个软件测试过程。 基于决策理论,文献[9]将软件测试过程看成一个Markov决策过程,基于交叉熵方法对软件测试进行优化,给出了一种启发式算法,获得最优测试剖面,优化整个测试过程。
在软件测试优化的研究中,尽管动态规划方法对于一些规模较小的问题能得到精确解,但随着问题规模的增加,动态规划方法却无能为力,这时只能通过启发式方法给出问题的最优(或渐近最优)解。另外,在实际应用中,这些模型的一些假定条件往往过于苛刻,不适用于软件测试实际过程,影响模型的实用性。作为软件测试优化启发式方法的重要补充,本文在文献[9]给出软件测试优化的Markov决策模型基础上,基于蚁群算法[10,11]提出了一种优化软件测试策略的启发式方法,利用该方法优化测试剖面,用于优化软件测试,可以有效地降低软件测试费用,提高软件测试效率。
1软件测试优化模型
为了更好地描述软件测试优化模型,这里采用文献[9]中给出的相关概念及记号。假定在整个软件测试过程中,将每个时间点(决策时刻) t(t=0,1,2,…)上软件剩余的缺陷数作为时刻t系统所处状态,则整个状态空间为s={st,t≥0}={M,…,1,0},将每个时间点t按着某种测试策略选取一个测试用例作为一次决策行动,各个时刻按不同测试策略选取测试用例的行动全体组成整个行动空间A={at,t≥0}={1,2,…,k},并且每个时间点t(t=0,1,2,…)上的状态st和所采用的行动at都会影响下一时间点t+1的状态st+1,因此整个测试过程形成一个Markov决策过程,如图1所示。
对于待测软件系统,假定软件最初具有M个软件缺陷,我们的目标是检测并排除所有的软件缺陷。为了便于用Markov决策过程来优化软件测试过程,不失一般性,作如下假设[9] :
(1) 软件在初始时刻(t=0)包含M个缺陷。
(2) 在每个决策时刻只采取一个行动,并且这个行动至多只能检测到一个软件缺陷。
(3) 如果在时刻t,系统状态st=j,则行动at应用到测试中以概率jθat检测到一个缺陷,下一时刻t+1的状态为st+1=j-1; 以概率1-jθat不能检测到缺陷,下一时刻t+1的状态与时刻t的状态相同st+1=st。其中θat可解释为由于行动at使得每个剩余软件缺陷被检测到的概率,称为缺陷检测率。
(4) 缺陷一旦被检测到, 缺陷就被认为已排除, 不再产生软件失效。
(5) st=0是一个吸收状态,它是一个目标状态。
(6) 在每个时刻t采取行动at,则不论是否检测到缺陷均会导致大小为C(st,at)的测试费用,在目标状态上采取任何行动的测试费用均记为0。
(7) 在每个时刻t可供选择的可行行动集为A(st), 则整个行动空间
由上面的假设,描述软件测试过程的Markov决策过程可定义为一个五元组{T,S,A,P,C},其中T={0,1,2,…}为决策时刻,S={M,…,1,0}为状态空间,A={1,2,…,K}为行动空间,P为转移概率矩阵,其元素满足Markov性:
P(st|s0:t-1,a0:t-1)=P(st|st-1,at-1) (1)
表示在时刻t-1采取行动at-1时,从状态st-1转移到状态st的概率, 其中记号s0:t-1表示s0,s1,…,st-1,记号s-1表示在起始时刻之前的状态,记为空集ϕ。C中的元素C(st-1,at-1)表示在状态st-1采取行动at-1时的测试费用。
定义一个测试策略π:S→A(S),Π为所有可能测试策略π的集合,即一个测试策略在每一个离散决策时刻t为决策者提供在哪个状态下应该采用哪个决策行动。
令随机变量St表示在时刻t所处状态, 则对于一个给定的测试策略π∈Π,则从起始时刻0到时刻t为止, 整个测试过程可由此Markov决策过程的一个历史来描述:
Ht={s0,a0,s1,a1,…,st,at,…} (2)
其中at表示在时刻t采取的行动,并且对于st∈S,有at=π(st)。记τ为从系统状态s0=M首次到达状态0时所采取测试行动的最小次数,即τ=min{t:st=0}, 则对于任意给定的策略π∈Π,从时刻0到时刻τ选取的行动构成测试用例序列的平均测试费用为:
软件测试优化问题就是找到一个最优(或近优)测试策略π*使得期望测试费用最小,即确定最优测试策略π*满足:
2基于蚁群算法优化软件测试
蚁群算法(ACO)是最新发展的一种模拟蚂蚁群体智能行动的仿生优化算法[10,11,12],是一种并行随机搜索算法,通过多个候选解组成群体的行进过程来搜索最优解。应用蚁群算法求解优化问题的基本思想是将所求问题的可行解转化为有向图上的可行路径,利用构造图把所求组合优化问题的可行解定义为“路径”,而路径的长度对应于所求问题的目标函数值,将组合优化问题的求解对应于有向图上的可行路径搜索问题。一般地,蚁群算法包括如下几步:
步骤1 初始化构造图参数和信息素矩阵。
步骤2 For蚂蚁m=1,2,…,n。
(a) 基于信息素τ和启发式信息η构造问题的解;
(b) 应用局部搜索算法提高解;
(c) 更新发现的最优解;
(d) 更新信息素。
步骤3 如果算法达到停止条件,停止算法运行,输出最优解;否则,转到步骤2。
蚁群算法虽然具有许多优点,但是由搜索初期信息素相对匮乏,导致算法的搜索效率降低,正反馈机制容易产生停滞早熟现象。为了克服蚁群算法的不足,针对Markov决策过程可以引入“策略迭代”或“值迭代”机制[12]以及“精英”机制,在增强局部详细搜索的能力同时增强其跳出局部最优的能力, 从而避免陷入局部最优,得到问题的最优解或近优解。应用蚁群算法到优化软件测试包括算法的初始化、测试策略生成与提高、信息素更新、测试剖面的更新与最优测试策略的生成等五个主要步骤,各步骤详细说明如下。
2.1算法初始化
设定蚂蚁数n,选择μ∈(0,1],对于每个蚂蚁i=1,2,…,n初始化信息素τ0(s,a)=1/|A(s)|,对于所有的s∈S,a∈A(s);初始化测试剖面p0(s,a)=1/|A(s)|对于所有的s∈S,a∈A(s)。
2.2测试策略生成与提高
在算法的每一次迭代k>1中, 每个蚂蚁对应于策略集Πk是一个策略π
每个蚂蚁生成随机平稳策略π
来获得相应的适应值Vi(s)。策略提高则是通过下式来更新策略函数:
算法停止当且仅当πi(s)=πi+1(s)=π*。策略迭代算法具有较快的收敛性,在较少的迭代次数中就能保证其收敛性[11]。
值迭代算法从任意选择的值函数V1(s),∀s∈S开始,通过迭代更新生成一系列的值函数Vi(s),i=1,2,…序列,其更新方式为:
直到max|Vi+1(s)-Vi(s)|小于某个事先给定的任意小的非负实数ε。
2.3信息素更新
大多数ACO方法中信息素的更新采用“精英”策略:仅仅采用当前迭代中最优测试序列来更新信息素。然而,这种策略并不一定是最优策略,实验结果表明这种策略并不适合于测试优化问题。这种“精英”机制仅仅适合于小状态问题,对于一些状态空间相对大的问题仅用最优测试序列来更新信息素往往具有较弱的收敛性。基于此,我们提出了采用一些较好的“精英”测试序列来更新信息素。根据各个蚂蚁的平均测试费用,选择较好的ρ个蚂蚁进行信息更新。
每个蚂蚁对于每个状态s∈S和行动a∈A(s)信息素初始化为均匀分布,即
其中Q为事先给定的常数。则合并各个蚂蚁的信息素为各个状态s∈S及该状态下的各个行动a∈A(s)的信息素τ
其中,常数μ∈(0,1]称为挥发因子[10]。
可以看出,这种信息素更新策略采用ρ个较好蚂蚁的路径使信息素具有正的增加。通过这种更新策略,在构造图中有“希望”边的信息素得到增加,这样就会使得蚂蚁在将来的遍历过程中使得这些边的遍历次数更多。
2.4测试剖面的更新
在各个状态s∈S下,各个行动a∈A(s)的选择概率即测试剖面初始化为均匀分布p
为了提高算法的性能,在测试剖面的更新中引入能见度ηk(s,a): 某些看起来“有希望”的边可以给予某种先验的优待。基于这种思想,则上面的测试剖面更新为:
其中ηk(s,a)>0为在状态s下行动a事先定义的值。最简单的方法是定义ηk(s,a)为:
其中实数l>0,α>0, 在实际应用中常选择α的值相对较小,如:α∈[0.1,0.5],其目的是通过能见度的值调节由信息素的值τk(s,a)控制的遍历过程过于偏于信息值较大的边。 注意到上面定义的能见度值ηk(s,a)总是正数。
2.5最优测试策略生成
在第k次迭代中生成的最优测试策略π
采用这种最优测试策略生成技术可保留整个迭代过程中生成的所有测试策略中最优者,使得算法在每一次迭代中信息素的更新不仅由当前生成的测试序列控制,而且也由前面生成的最优测试策略生成的测试序列控制, 这样使得生成的最优测试策略更接近于全局最优测试策略。
3实验分析
为了验证蚁群算法在软件测试中的效率,这里采用文献[9]的实验方法及例子,通过随机模拟方法将蚁群算法、交叉熵算法(CE)与随机测试策略三者作比较。在随机测试中,测试用例(或行动)是根据均匀分布随机地在测试用例集中选取,也就是说每一个可行的测试用例(行动)在测试中都以相同的机会被选取。在软件测试优化问题中,假定待测软件的参数(剩余缺陷数M, 各个行动缺陷检测率θat和不同状态下各个行动所需的测试成本C(s,a)已知,在实际应用中这些参数一般可以通过专家的经验或相关软件工程的方法估计出。并假定在各个状态下,每种行为均可采用。
3.1平均测试成本实验
假定初始缺陷数M=7,A={1,2,3,4,5,6},并且假定θ1=0.5,θ2=0.125,θ3=0.25,θ4=0.075,θ5=0.13,θ6=0.15,不同状态下采用不同行动的测试成本C(s,a)如表1所示。
由蚁群算法学习策略得到的优化测试剖面为:
采用以上由蚁群算法所得的测试剖面,与由交叉熵方法所得测试剖面和随机测试剖面的策略分别模拟运行10次,全部检测并排除7个软件缺陷时,三种测试策略的测试成本如图2所示。
10次模拟测试中蚁群算法学习策略的平均测试成本分别为 120.44,交叉熵方法的平均测试成本分别为 125.37,随机测试的平均测试成本为368.13。模拟结果表明:采用蚁群算法优化测试剖面测试并不能保证每次测试成本都比随机测试小,但其平均测试成本远远低于随机测试的平均成本。从这个角度来看,蚁群算法策略远优于随机测试策略,且蚁群算法策略与交叉熵方法策略相比在成本上仍较优。
3.2平均测试能力实验
假定初始缺陷数M=45,行动空间A={1,2},两种测试行动的缺陷检测率分别为θ1=0.025,θ2=0.01,假定在所有状态下采用这两种测试行动的成本都相同,均为2,即C(s,a)=2,(s=1,2,…,45,a=1,2)。
采用蚁群算法学习策略、交叉熵方法略和随机测试策略分别模拟测试6次,图3给出6次模拟测试中检测不同的缺陷数时所用测试用例的散点图,图4给出6次模拟测试中检测不同的缺陷数时所需平均测试用例数的曲线图。
模拟结果表明:初始阶段,三种测试策略缺陷检测能力相差不大,随着待测试软件中剩余缺陷越来越少,随机测试所需平均测试用例数要远高于蚁群算法,说明蚁群算法策略检测缺陷的能力要远高于随机测试策略,同时与交叉熵方法策略在检测缺陷的能力上相比较好。
4结语
本文给出的基于蚁群算法的软件测试优化策略是以仿生学为基础,在某些软件参数(如缺陷检测率)已知或已估计出的条件下,以最小化软件测试的平均费用为目标,运用蚁群算法搜索最优测试剖面,用于优化软件测试。 是一种带导向性的测试用例选择方法,具有较强的自我学习能力。模拟结果显示由蚁群算法学习策略所给出的测试剖面用于指导测试要明显优于随机测试策略, 检测和排除相同数目的软件缺陷,蚁群算法学习策略比随机测试策略能显著地减少测试用例数,降低测试成本,同时与其它测试策略相比具有一定的特点和优势。
参考文献
[1] Cai K Y. Optimal Software Testing and Adaptive Software Testing in the Context of Software Cybernetics[J].Information and Software Technology,2002,44(4):841-855.
[2] Cai K Y,Li Y C,Ning W Y.Optimal software testing in the setting of controlled Markov chains[J].European Journal of Operational Research,2005,162:552-579.
[3] Cai K Y,Chen T Y,Li Y C,et al.Adaptive Testing of Software Components[C]//Symposium on Applied Computing Proceedings of the 2005 ACM symposium on Applied computing,2005:1463-1469.
[4] Ozekici S,AltOnel I,Ozccelikyurek S. Testing of software with an operational profile[J].Naval Research Logistics,2000,47:620-634.
[5] 崔小乐,王轶辰,阮镰. 一种软件测试过程的博弈模型[J].北京航空航天大学学报,2004,30(8):797-802.
[6] Tal O,McCollin C,Bendell A. An Optimal Statistical Testing Policy for Software Reliability Demonstration of Safety-critical Systems[J].European Journal of Operational Research,2002,137:544-557.
[7] Tal O,McCollin C,Bendell A. Reliability demonstration for safety-critical systems[J].IEEE Trans. on Reliability, 2001,50(2):194-203.
[8] Cai K Y,Zhao D,Liu K.Software testing processes as a linear dynamic system[J].Information Sciences,2008,178:1558-1597.
[9] 张德平,聂长海,徐宝文. 基于Markov决策过程用交叉熵方法优化软件测试[J].软件学报,2008,19(10):2270-2279.
[10] Dorigo M,Maniezzo V,Colorni A.Ant system:optimization by a colony of cooperating agnts[J].IEEE Transaction on Systems, Man, and Cybernetics-Part B,1996,26(1):29-41.
[11] Gutjahr W J.A graph-based ant system and its convergence[J].Guture Generation Computer Systems, 2000,16(8):873-888.
软件测试方法策略 篇11
关键词：油气测试；深水测试；影响因素；策略
中图分类号： TQ023 文献标识码： A 文章编号： 1673-1069（2016）28-177-2
0 引言
随着地层的测量测试开发发展，深水勘探检测，成了影响其操作的一项重要环节。由于深层探测中，深井水的温度高于地层表面侦测温度，因此对系统所需要承受的风压以及海浪洋流问题等，都会形成严重的影响，而通过对所需要承受的影响的研究分析，在进行管道的设计制作上，就需要从流体力学以及管柱力学上进行合理的分析探究，为后续的发展以及压力建设提供有效保障，并分析测试管柱以及保证的处理方法，在实际使用过程中的安全持续保障。下面对其结构的影响因素以及应对策略进行简要分析。
1 深水测试多层管柱结构分析
在进行深水探测的过程中，为满足对基本的深水探测试水管柱系统的划分研究中，为满足基本的生产需求，就需要通过对上部连接接头在伸缩管道紧张程度上的评定，并依照相应的隔水管层分析，从而确保了对引导钻探器具的分析，并以此完成对循环流道在实际支撑体验中的控制管线分析，并以此实现对多个位置的检测执行。在进行循环流通系统的支撑检测中，其结构如图1所示。
对于深水测试管道的力学结构分析，需要对其半潜测试平台进行结构作业分析，并对其风与水的流体作用进行环境解析，并为后续的操作提供安全的控制操作范围。如图2所示，在平台升降补偿的以及系统的定位检测中，需要保持控制范围在实际随机作用操作环境下的柔性化结构设计，并为隔水管在深水系统测试中的任务满足。
对于结构的使用，还需要对其结构进行横向变形的综合处理分析，在尽量减小转动变化的前提下，实现对平台允许范围内的偏移量处理。对于测试管在水机使用的隔水处理上，放置运动的不良反应发生，并在实际的作业管道使用上，强化对基本的运输使用规格使用，并通过深水段的温度变化处理，保证对基本的应用结果分析，为海平面的常温处理提供管柱的力学结构信息，确保检测信息的精确性。
对于基本的地层管理学分析，而针对底层的管理，从基本的检测管理机制进行分析，即可保证对检测管道在不同环境下，对膨胀度以及螺旋弯曲度的使用效果，而对于温度的荷载变化，也可结合实际的流体摩擦阻力效益，实现对管柱在实际变化中的影响效益分析。对于测试管柱在应用理念上的保护执行，即可实现对压力记在工具寿命执行保障上的安全防护，并以此实现对深水检测信息的精确性保障。
2 现阶段深水测试管柱的力学行为研究情况
伴随着现代科学技术的不断发展，通过对体系和方法方针上的保护执行，对于流程设计以及保护处理效果上的执行保护问题，对于管道组合的执行力度等，也都能够更好地满足基本的效益执行，对于深水检测的条件研究，还需要满足以下几个特点，才能够进行管柱力学研究，并以此实现对不同阶段的实践执行，通过基本的初级阶段影响分析，从而实现在不同结构下的研究效果保持。
对浮体运动的实际影响，由于深水油气的开发，通常应用半潜式平台，并根据周围环境下的风浪情况，进行浮体运动分析，而在进行这一结构的运动模式分析上，还需要对半潜式作用平台进行调节分析，而其运动的通过执行表达，也可结合实际的补偿系统，完成对深水探测作业流向上的诊断表达，并为其后续的发展提供安全保障。其实际的浮体运动结构如图3所示。
对于深水测试的管柱力学研究上，结合陆地的管柱力学进行力学研究结构分析，并完成对封闭管柱连接结构的漂浮运动研究，对于隔水管在研究力学上的广泛性研究，可结合隔水管在连贯性连接上的流体调节，并为其后续的涡流振动效益，进行平台结构分析，实现在实际系统动力学分析上的执行表达。而对于深水测试的管柱和隔水管在双层管的相互作用研究上，可结合陆地管柱研究结果，实现对海洋环境在执行运动荷载作用上的实践调整，并为后续的作业提供信息检测保障。通过深水测试作业中的高压流体以及射孔冲击在载荷作用的影响研究，能够为今后在深水测试作业的工作中，提供更好的勘探数据。
3 深水测试管的柱力学发展方向分析
在进行目标诊断效果的管理研究中，需要结合对已知的系统化管理模式进行综合分析，并保证对管道助力在执行力上的实践执行。在进行理论依据解析分析上，可通过测试的管柱荷载情况进行分析，并完成对深水测试管在细长柔韧性的阶段分析，并以此完成对所承受的荷载特点，进行统计分析，保证深水段在底层段管理系统的实际执行保持，实现在位层移动场以及温度场在执行分层表达信息上的结构建设。
从现阶段的结构建设平台进行分析，并保证对原有因素上的执行调控分析，实现对系统动力学影响模型在使用效益上的表达调整，并为后续发展提供安全保障，因此其实际使用过程中，对执行深水在测试管柱的安全性以及可靠性分析上，都能够更为有效的保障其建设的安全可靠性。
针对研究的内容以及发展公益流程，可针对其实际的理论分析情况，完成对不同内容环境下的理论建设，而在这一方面的改良建设中，就需要对其内容进行多层面研究。其中，对于深水多层管柱的研究中，深水管柱主要在海洋和温度载荷以及流体多个层次上受到影响，而这一情况对于基本的数量和安防位置，都会产生直接的影响，这对于隔水管以及测试关注的随机碰撞管柱安全性，都可能导致诸多的影响因素发生。而对于深水测试工作的特殊型别，其安全性备受管理关注，如何在原有的框架上，实现对隔水管以及测试关注需求的建设，并依据相应的水位系统，实现对平台飘逸移动效益上的执行保护，是需要通货对浮体运动影响因素上的确定分析，并以此来完成对随机性的实践研究，并以此完成对悬挂结构的安全保护。对于封隔器在实际测试使用过程的类型参数，并实现对管柱尺寸和扣型在优化选择上的串联结构保护，以此来完成对整体管柱力学上的测试精确率调控分析。
对于深水油气在使用开发过程的安全执行流程，需要加强对基本原油服务理念上的，开发流程分析，对于模型的建立，还需要对计算方法以及系统的研究结果，保证对基本模型在精确率，可更好地满足基本的技术理论支持，而依据相应的深水气田保护作用，也可更进一步的完善对技术支持领域内信息保障。
参 考 文 献
浅谈软件测试方法 篇12
1.1 软件测试概念
软件测试的概念是, 在规定条件下对程序进行操作, 以发现程序错误, 衡量软件质量, 并对其是否能满足设计要求进行评估的过程。软件测试对软件正确性、完整性、安全性进行检测和纠错, 使用人工手动检测或自动检测方法对某段程序进行运行和测试。
1.2 软件测试活动的五个过程
(1) 标志测试条件和测试优先级。测试条件是对被测环境的具体描述, 可以采用表格、语言、图标等方式进行描述。 (2) 设计测试用例。测试用例的设计包括测试过程中能够用到的输入值、期望值, 以及运行过程中涉及的相关信息。 (3) 开发测试用例。开发是设计方案的具体实施, 包括测试脚本、测试输入、测试数据及期望输出。 (4) 执行测试用例。手动测试:将事先设计开发好的数据输入, 并观察结果、记录问题。自动测试:启动测试工具, 选择测试用例, 获取测试结果。 (5) 将测试结果与预期输出进行比较。对每个测试用例的输出和预期值进行比较分析, 判断软件程序运行是否符合要求。
2 软件测试类型
2.1 BVT (Build Verification Test) 。BVT是在检入代码并编译生成版本之后进行的测试类型, 主要用于检测新版本功能是否完整、特性是否正确。
2.2 Scenario Tests (基于用户实际应用场景的测试) 。在进行BVT功能测试的同时辅助模仿用户操作的真实环境, 提供完整的用户操作流程。
2.3 Smoke Test。当发现一个程序错误并由开发人员进行修改之后, 需要重新测试问题是否解决, 这种专门测试某个修改过的错误的测试就是Smoke Test。
2.4 Application Compatibility Test (兼容性测试) 。软件设计不仅要能在测试机上使用, 还要能在不同平台和系统中使用, 兼容性测试完成才能确保新软件能在不同环境下正常运行。
2.5 除了上述四种主要测试类型, 还有Functional Test (功能测试) 、Security Test (安全性测试) 、Stress Test (压力测试) 、Performance Test (性能测试) 、Regression Test (回归测试) 、Setup Upgrade Test (安装升级测试) 等类型测试, 此处不做赘述。
3 软件测试方法
软件测试方法多种多样, 根据是否需要执行被测软件分为静态测试和动态测试;根据测试针对角度不同分为白盒测试和黑盒测试。下面详细介绍这几种测试方法。
3.1 静态测试和动态测试
3.1.1 静态测试。
静态测试只检查程序代码、界面或文档中可能存在的Bug, 不运行被检测软件。它包括代码测试、界面测试、文档测试三部分。代码测试只检测代码逻辑是否符合标准;界面测试主要测试软件界面与用户需求界面是否一致;文档测试根据用户要求检测用户手册、需求说明文档。
3.1.2 动态测试。
与静态测试相对, 动态测试是通过运行软件来检测软件的功能、结果是否正确, 应用范围及频率远高于静态测试。动态测试在测试软件过程中分为几个阶段:单元测试:测试软件中的基本组成单元, 检测软件最基础的正确性;集成测试:首先进行组装测试, 对单元相互联系模块接口进行检测, 然后确认检测, 对组装测试结果进行进一步检测和确认;系统测试:对集成测试完成之后的软件进行软件系统正确性和功能性检测, 确保软件系统运行正常;验收测试:软件发布使用之前的最后一道检测, 也可以看做是用户的试用阶段测试;回归测试:在软件试用之后, 对试用阶段的问题进行修改和再检测。
3.2 白盒测试和黑盒测试
3.2.1 白盒测试
白盒测试是在了解程序内部结构和实现代码结果的基础上设计测试用例进行检测的方法。它针对软件结构或逻辑驱动进行测试, 仅检测每天程序是否按规定执行, 并不对其产生的功能进行检测。
白盒测试的主要测试方法有逻辑驱动测试和基本路经测试两种。其中逻辑驱动测试以程序内部逻辑结构为基础, 针对覆盖率进行测试, 包括语句覆盖、分支覆盖、条件覆盖、路径覆盖四部分。基本路经测试是根据程序运行流程图设计测试用例进行测试的方法, 它的测试步骤包括画控制流程图、计算程序圈复杂度、导出测试用例、准备测试用例, 期间涉及的测试工具主要是图形矩阵。
白盒测试虽然增大了检测代码覆盖率、发现代码中隐藏问题、提高了代码的正确性, 但是它仍具有很多缺陷, 测试路径复杂、不能检测软件设计的正确性、增大了系统开销等。
3.2.2 黑盒测试
黑盒测试将软件系统看做一个封闭的空间, 利用测试用例输入和输出检测软件功能是否正确。黑盒检测的目的是检测结果正确性、需求是否满足、边界条件、性能稳定性、压力承受力、错误恢复、安全性、兼容性。相比于白盒测试, 黑盒测试具有简单易行、不涉及内部结构、关注用户角度、测试方便等优点, 但是同时它的代码覆盖率低、自动化测试复用性低等缺点也限制了它的检测全面性。
4 结语
软件测试在软件设计开发过程中占有很大的比重, 任何软件的成功推行都必须有完整的测试体系来确保软件的运行正确性和功能完整性, 是软件系统的强有力的保障。
参考文献
【软件测试方法策略】推荐阅读：
软件测试管理方法05-20
软件测试方法概述09-04
Web软件测试方法05-13
软件测试概论和方法05-20
软件测试教学方法08-24
软件测试做事方法总结09-25
软件测试分析方法研究10-17
计算机软件测试方法07-26
基于模块化设计的嵌入式软件测试方法07-17
测试软件测试11-17