第一篇:基于模型的软件测试技术探析论文
摘 要:近年来,随着科技信息的快速发展,软件的功能性和复杂性增强,软件测试与可靠性评估的难度逐步加大。笔者主要分析了现在广泛应用的面向对象软件开发技术和软件自动化测试技术的现状,总结了基于模型的软件测试特点及不足,并简单介绍了基于模型的软件测试流程。
关键词:软件产业;模型;测试流程
软件产业在国家信息化,工业化进程中发挥越来越重要的作用,是推动我国经济社会发展的基础性、战略性和先导性产业。保障软件质量,维护国家和社会信息安全已是国家必须解决的重点问题。进行软件测试是保证软件质量的关键阶段,是保证软件生存期的重要步骤。软件测试,即在软件正式投入运行前,对软件需求分析、设计规格说明和编码进行最终复审的活动。其目的是为了检验软件系统是否满足需求并针对发现的问题进行改进。目前,我国软件质量测试研究中,对软件质量测评模型与测试数据自动生成方法的研究,已经成软件工程领域的研究热点。基于模型的软件测试方式是软件编码阶段的主要测试方法,通过故障排除法,检测软件质量,具有运行速度快,效率高、检测性能佳等特点。但是也存在误报、漏报和故障机理等程序问题。笔者通过分析国内外软件质量相关技术现状,对基于模型的软件测试技术特点和存在的主要问题进行了分析,阐述了基于模型的软件测试流程。国内外软件质量相关技术现状
近几年,国家对软件安全问题越来越重视,不少高校和国家研究机构从事软件测试研究,通过借鉴国外先进理论和引进技术,结合我国软件质量问题,基于模型的软件测试技术得到了快速发展并应用到实际测试中。但是还是远远落后于国外软件测试技术,一方面,在欧美发达国家,软件测试工作是一个非常独立的职业,是软件质量控制必不可少的环节;在我国,很多软件企业软件测试工作只停留在单元测试,功能测试等环节,甚至根本不进行质量测试,专业的测试工作人员所占比例小;另一方面,我国软件产业质量较低,软件测试标准化、规范化操作尚未形成,而软件测试的通用化、网络化和智能化水平与国外相比,更是相差甚远。模型的软件测试技术特点
2.1 软件测试评价一体化
基于模型的软件测试技术根据被测试应用程序的分析设计模型,自动生成测试模型、产生测试用例和进行测试结果评价。
2.2 软件测试自动化水平及测试效率高
基于模型的软件测试在测试过程中,首先提高了软件测试效率,减少了测试人员的工作量;其次在软件成本降低的同时,软件产品质量提高了;最后,可以随时生成各种统计数据,提高高层监控整个软件测试过程的能力。
2.3 有效解决了测试失效辨识问题
基于模型的软件测试技术是对其他软件测试技术的有效补充,往往能发现其他测试技术难以发现的故障,尤其是对逻辑复杂故障测试效果好,保障了软件质量。模型的软件测试存在的主要问题
模型的软件测试工作是一项具体且全面的工作过程。首先,工作人员方面,不仅需要测试人员具备一定的理论基础,还要掌握相关工具使用方法。其次,在实际应用过程中,我们发现基于模型的软件测试技术存在不少软件质量问题,尚不能取代已有的其他测试技术,还需从事此行业的工作人员进一步研究和实践,更好的补充其他测试技术不足之处。以下简述了存在的几个主要问题并进行了简要分析。
3.1 误报问题
误报问题是系统没有发生故障而报警,误报信息是模型的软件测试技术普遍存在的问题。这是由于一些故障的发生和确定是在动态的信息执行中形成的,而基于模型的软件测试技术大多是静态分析技术,误报问题在静态分析的测试工具工作中是不可避免的。以下以OCL在建模的进程调度系统中的静态模型为例,见图1。图1 静态模型 上图是对系统的静态描述,虽然可以形成所需模型,但是显然对该系统的描述还是不精确的。我们知道,处在就绪状态的进程和等待进入就绪状态的进程集合之间是不相交的,而系统中始终只能有一个处于活动状态的进程,活动进程与前两个进程也不会发生集合。这样,静态图的生成并不是准确的,误报问题由此产生。现在不少高校和研究所将动态测试与静态测试进行互配测试,以期解决测试中的误报问题。
3.2 漏报问题
漏报是指系统发生了故障而没有报警,是系统故障中又一常见问题。基于模型的软件测试是由模型定义和模型检测算法进行软件质量测试的,由于模型定义和模型检测算法在具体软件模型检测中存在差异,漏报问题也是不可避免。我们知道,由于模型定义是由故障本身及所用工具决定的,而软件模型多种多样,测试工具因模型变化,具体的模型所用的检测工具在设计过程中从检测的效率性和降低软件复杂性出发,都会设计形成自己认为最简便合理的检测算法,这样就形成了软件检测中普遍存在漏报问题,即使是相同的模型,由于检测工具的差异,导致检测故障结果也存在差异性。
第二篇:软件测试技术与管理方法探讨论文
1自动化测试
传统的测试已经无法满足测试的需要,自动化测试应运而生,自动化测试是指在预设条件下运行,包括正常条件和异常条件,自动化主要研究的是自动化框架测试、自动化测试脚本技术、自动化用例生成。通过资料了解,C-ATFM模型。该模型基于C语言,面向对象集成环境,采用源码嵌入有效的分析软件的代码、词法、语法、策略、指令。并且随着软件工程及软件测试的发展,自动化的机器测试发展更有前景。
2下面简介软件测试的过程
2.1模块测试
模块测试主要针对软件设计中的程序模块,通过测试技术测试程序块是否正确,模块测试的主要目的是测试程序内部的错误,根据程序设计的结构检查代码和程序是否合理,是否符合设计思路和理念,是否能够正常运行。
2.2组装测试
在模块的基础上,需要将所有模块的功能全部测试完成后组装成为系统,组装测试的目的在于,连接所有模块之后,模块之间的接口、触发器是否能正常运行,并且计算显示的数据是否正确,模块之间的功能是否互相冲突,是否达到预期的目的和结果显示,是否构成正确的、预期的数据结构。不同模块之间的误差有多少,有多少可以解决,有多少不能解决。
2.3确认测试
确认测试的目的是验证软件的功能和特性是否达到预期的愿望,是否能按照预期的组织结构、系统结构、用例分析和时序分析运作,并且进行验收测试和安装测试。
2.4系统测试
系统测试是确认软件是否与硬件互相支持,是否能满足软件使用者对软件的需求和操作简便的愿望,比如说查询模块运行完后界面中查询条件应该为查询之间输入的查询条件。系统测试保证了系统的正常运行,另外很重要的就是权限测试,系统在研发之初定义的权限信息和权限功能是否实现,是否发现软件成品与软件定义不符合或者矛盾。
3软件测试技术的地位
一个成功的测试用例在于发现了至今尚未发现的缺陷。其实,软件编程的过程也会出现一些不可避免的错误,例如:对于用户需求的错误分析和编程出现的一些语法错误,如果软件与发票费用相关更是与测试密不可分。软件不断地接近成熟和完成以及投入使用阶段,软件测试工程师必须更加谨慎的检测每一部分程序,一段程序的完成,测试工作量占有总工作量40%以上,这就给我们说明:测试是软件开发成功的重要组成部分。
第三篇:测试技术论文
虚拟仪器技术就是利用高性能的模块化硬件,结合高效灵活的软件来完成各种测试、测量和自动化的应用。灵活高效的软件能帮助您创建完全自定义的用户界面,模块化的硬件能方便地提供全方位的系统集成,标准的软硬件平台能满足对同步和定时应用的需求。这也正是NI近30年来始终引领测试测量行业发展趋势的原因所在。只有同时拥有高效的软件、模块化I/O硬件和用于集成的软硬件平台这三大组成部分,才能充分发挥虚拟仪器技术性能高、扩展性强、开发时间少,以及出色的集成这四大优势。
虚拟仪器技术的三大组成部分:
1.高效的软件
软件是虚拟仪器技术中最重要的部份。使用正确的软件工具并通过设计或调用特定的程序模块,工程师和科学家们可以高效地创建自己的应用以及友好的人机交互界面。提供的行业标准图形化编程软件——LabVIEW,不仅能轻松方便地完成与各种软硬件的连接,更能提供强大的后续数据处理能力,设置数据处理、转换、存储的方式,并将结果显示给用户。此外,还提供了更多交互式的测量工具和更高层的系统管理软件工具,例如连接设计与测试的交互式软件SignalExpress、用于传统C语言的LabWindows/CVI、针对微软Visual Studio的Measurement Studio等等,均可满足客户对高性能应用的需求。
有了功能强大的软件,您就可以在仪器中创建智能性和决策功能,从而发挥虚拟仪器技术在测试应用中的强大优势。
2.模块化的I/O硬件
面对如今日益复杂的测试测量应用,已经提供了全方位的软硬件的解决方案。无论您是使用PCI, PXI, PCMCIA, USB或者是1394总线,都能提供相应的模块化的硬件产品,产品种类从数据采集、信号条理、声音和振动测量、视觉、运动、仪器控制、分布式I/O到CAN接口等工业通讯,应有尽有。高性能的硬件产品结合灵活的开发软件,可以为负责测试和设计工作的工程师们创建完全自定义的测量系统,满足各种独特的应用要求。
3.用于集成的软硬件平台
专为测试任务设计的PXI硬件平台,已经成为当今测试、测量和自动化应用的标准平台,它的开放式构架、灵活性和PC技术的成本优势为测量和自动化行业带来了一场翻天覆地的改革。
PXI作为一种专为工业数据采集与自动化应用度身定制的模块化仪器平台,内建有高端的定时和触发总线,再配以各类模块化的I/O硬件和相应的测试测量开发软件,您就可以建立完全自定义的测试测量解决方案。无论是面对简单的数据采集应用,还是高端的混合信号同步采集,借助PXI高性能的硬件平台,您都能应付自如。这就是虚拟仪器技术带给您的无可比拟的优势。
虚拟仪器技术的四大优势:
性能高
虚拟仪器技术是在PC技术的基础上发展起来的,所以完全“继承”了以现成即用的PC技术为主导的最新商业技术的优点,包括功能超卓的处理器和文件I/O,使您在数据高速导入磁盘的同时就能实时地进行复杂的分析。此外,不断发展的因特网和越来越快的计算机网络使得虚拟仪器技术展现其更强大的优势。
扩展性强
这些软硬件工具使得工程师和科学家们不再圈囿于当前的技术中。得益于软件的灵活性,只需更新您的计算机或测量硬件,就能以最少的硬件投资和极少的、甚至无需软件上的升级即可改进您的整个系统。在利用最新科技的时候,您可以把它们集成到现有的测量设备,最终以较少的成本加速产品上市的时间。
开发时间少
在驱动和应用两个层面上,NI高效的软件构架能与计算机、仪器仪表和通讯方面的最新技术结合在一起。设计这一软件构架的初衷就是为了方便用户的操作,同时还提供了灵活性和强大的功能,使您轻松地配置、创建、发布、维护和修改高性能、低成本的测量和控制解决方案。
无缝集成虚拟仪器技术从本质上说是一个集成的软硬件概念。随着产品在功能上不断地趋于复杂,工程师们通常需要集成多个测量设备来满足完整的测试需求,而连接和集成这些不同设备总是要耗费大量的时间。虚拟仪器软件平台为所有的I/O设备提供了标准的接口,帮助用户轻松地将多个测量设备集成到单个系统,减少了任务的复杂性。
应用实例
阿尔卡特美国公司是全球领先的世界上电信设备制造商领导者之一。位于加州佩塔卢马的接入部,开发Litespan接入平台一种光纤数字环路载波(DLC)。DLC能够将电话公司中心机房普通铜线上的电话业务传递到更远的地方。通过LabVIEW,在相对短的时间内开发了一个全面测试方案。同时测试对每个信道单元的16个ANSI要求的环路和4条ISDN线路的一个信道单元进行测试时,每项测试所花费的时间为12分钟。由于一些信道单元需要测试某个温度范围内的状况,因而整个测试需要几天的时间。
Allen Klein美国阿尔卡特公司Litespan硬件质量部的一位工程师,在程序中增加了一项功能,使得测试可以全天进行,甚至在周末也行。这项功能极大地扩展丰富了测试平台,提高了测试效率。
虚拟仪器技术是测试技术和计算机技术相结合的产物,是两门学科最新技术的结晶,融合了测试理论、仪器原理和技术、计算机接口技术、高速总线技术以及图形软件编程技术于一体。
虚拟仪器是由计算机硬件资源和用于数字分析与处理、过程通讯以及图形界面的软件组成的测控系统,它把仪器生产厂家定义仪器功能的方式转变为由用户自己定义仪器功能,也就是说传统测试中使用厂家生产的仪器,仪器的性能及功能在出厂时已被厂家定义,用户只能根据自己的要求和需要选择和使用;而虚拟仪器是在一定的硬件基础上,用户可根据测试的需求,编写软件定义自己的仪器功能。同样的硬件配置可开发出不同的仪器,例如在仪器面板上显示采集信号在时域的波形,那么该仪器为虚拟示波器;如果在程序中对采集信号进行FFT变换,那么该仪器就是虚拟频谱分析仪。笔者则用LabWindows/CVI来开发虚拟经纱张力测试仪,用来测试织机在工作时经纱张力的变化情况。经纱张力传感器
织机在织造过程中,经纱动态张力对织造的,顺利进行有着很大的影响,张力过大,易引起断头,影响织造效率;张力不足易造成梭口不清,形成三跳疵点,使布面及纹路不够清晰。当经纱穿过轴时,经纱对两侧传力杆有压力,通过传力杆将压力传给弹性梁,使之产生应变,利用应变片将其应变转化为电阻的变化,然后再通过转化电路将电阻的变化转化为电压的变化,测量出电压值,根据传感器的标定就可求出相应的经纱张力。虚拟经纱张力测试仪系统
2.1 系统结构
虚拟经纱张力测试仪的测试系统由传感器、数据采集卡、接口总线、硬件驱动程序和开发的测试软件构成,数据采集卡采用6024E,LabWindows/CVI平台开发测试软件,在Windows98操作系统下运行。
2.2 信号采集
由于要测出经纱张力与主轴转角的关系,所以用了3个传感器。传感器1是经纱张力传
感器,把经纱张力物理信号转化为电信号;传感器2是光电脉冲传感器,用来测量主轴转角;传感器3是霍尔传感器,将霍尔电压作为测量触发信号。各个传感器输出的信号都要经过一个信号调理电路对信号进行处理(如滤波、放大等),从混合信号中取出待测的有用信号,送人数据采集卡,并要适合数据采集卡的电压范围,通过总线结构送进计算机进行处理。数据采集借助软件来控制整个DAQ系统,包括采集原始数据、分析数据等,调理后的信号经多路开关在软件设定采样率的控制下,巡回采集并放大,再经采样与保持及A/D转换器单元被量化成数字信号,成为计算机可以处理的信号,由虚拟仪器软件对测试信号进行计算、分析、显示,并储存结果。虚拟经纱张力测试仪的设计
3.1 经纱张力测试仪的面板结构
虚拟经纱张力测试仪的面板右边的七个文本框输入内容,是用户根据实际测量的需求以及与采集卡的连接通道在开始测试前设定的。测量时,打开测试仪器开关,仪器就可以工作;按下采集数据,稍等几秒,面板上就会显示出经纱张力的波形图。保存数据就是对测量的原始数据、信号处理后的数据以及需要提供给用户的数据存取;读数据是读取事先已经测量的数据,然后在仪器面板上绘出曲线,这有利于事后分析;关闭仪器则退出测试状态。
3.2 虚拟经纱张力测试仪的软件
面板上的数据采集、关闭仪器、保存数据等命令按钮通过回调函数来实现各自的功能,整个源代码中数据采集的回调函数caiji是程序的关键。虚拟经纱张力测试仪的应用
用所设计的虚拟经纱张力测试仪系统对YC—425型喷气织机测试,织机主轴每转一转,经纱张力周期变化一次,在0°附近,经纱张力最大,有利于打纬,最小张力出现在280°附近。在理论上来讲,下一个最大值出现在开口满开的位置,且一般只有两个峰值,在曲线上除了打纬点外,还有两个峰值,这说明在后梁装有张力缓解机构。最小张力也就是经纱的上机张力曲线的重复性不很好,说明织机工作状况不够稳定。结束语
虚拟仪器是今后仪器仪表、测试控制研究与发展的方向,用NI公司的LabWindows/CVI作为平台,比常用的面向对象软件编程难度大大降低,使得软件开发效率高,界面友好,功能强大,且扩展性好,对采集到的数据可用于高级分析库进行信号处理,也可以为了使所得测试曲线符合实际情况,进行拟合处理。总之,虚拟仪器有强大的功能,它强调“软件就是仪器”,用软件代替硬件,易开发、易调试,可有效节约资金。
第四篇:《软件测试技术》课程总结报告
《软件测试技术》课程总结报告
班级:姓名:学号:
一、课程概述
二、课程实训项目
三、课程知识点总结
四、收获和体会
第五篇:软件测试技术面试总结
软件测试就是为了发现程序中的错误而分析和执行程序的过程。——概念
+基本知识+软件开发过程-定义-计划-实现-稳定化-部署
+软件开发模型(四种典型的模型)
+瀑布模型
-概述:包括计划,需求分析,设计,编码,测试,运行维护六个阶段。六个阶段自上而下、相互衔接,以固定的次序进行。
-特点:1.阶段的顺序性和依赖性;2.文档驱动; 3.推迟实现的观点;4.质量保证。-缺点:不适合需求模糊的系统
+原型模型-概述:先建立一个能够反映用户需求的原型系统,使得用户和开发者可以对目标系统的概貌进行评价和判断,然后对原型系统进行反复的扩充、改进、求精,最终建立符合用户需求的目标系统。
-特点:1.快速开发工具;2.循环; 3.低成本。
-分类:按照对原型的处理方式,可以分为渐进型和抛弃型。
+增量模型
-概述:在增量模型中每个阶段都生成软件的一个可发布版本,阶段交错进行,版本逐渐完善。
-同原型模型的最大区别在于,在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。+螺旋模型
-概述:适用于大型软件的开发,它将瀑布模型和快速原型模型结合起来,并加入了风险分析。
-特点:1.每个阶段都包括制定计划,风险分析,实施工程,评审四个阶段;
2.开发过程迭代进行,每迭代一次螺旋线增一周,工程前进一个层次,系统生成一个新版本,投入新的时间成本,最终得到客户满意的版本。
-软件测试从需求开始:现代的软件测试将测试渗入到软件开发的各个阶段,即使瀑布模型,表面看测试工作是在测试阶段开始的,事实上,在计划、需求、设计阶段,测试人员便已经开始了他们的工作,如:了解软件需求,编写测试计划,搭建测试环境。
-测试用例
-三要素:前提条件和操作步骤、预期结果、实际结果。
-必须以需求为依据。
-软件测试分类
-是否关注软件结构和算法
-黑盒测试:基于软件需求的测试方法。
-白盒测试:基于软件内部设计和程序实现的测试方法。
-是否执行被测试软件
-动态测试:在测试过程中执行被测试软件的测试方法。
-静态测试:------------不----------------------。
-基于不同的测试阶段:
-单元测试:主要测试软件的单元模块,需要编写额外的测试驱动程序,采用白盒测试的方法,一般由 开发人员完成。
-集成测试:将一些“构件”集成在一起时测试他们是否能正常运行,构件可以是程序模块,也可以是
客户机-服务器程序等,需要编写测试仿真程序,采用白盒和黑盒相结合的方式,通常由 开发人员承担。
-系统测试:测试软件系统是否符合所有的需求,包括功能性测试和非功能性测试。一般由
独立的测试
人员完成,通常采用黑盒测试方法。
-验收测试:(α、β)与系统测试类似,但由客户或最终用户执行,测试软件是否符合需求规格说明书。
-回归测试:指在软件开发过程中,每次错误被修正后或软件的功能、环境发生变化后进行的测试。
-软件测试的三个步骤:
-测试计划:测试人员首先对需求进行分析,最终定义一个测试集合,通过刻画和定义测试发现需求中的问题,然后根据软件需求同测试主管制定并确认“测试计划”。
-测试设计和开发:软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动 程序的开发。
-执行测试:需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果,必要时进行回归测试。
-测试工程师的能力要求:
+5C
-Controlled /kEn'trEuld/ 接受管理,有条理的-Competent /'kCmpitEnt/了解正确的测试技术
-Critical /'kritikEl/专注于发现问题
-Comprehensive /.kCmpri'hensiv/ 注意细节
-Considerate /kEn'sidErit/能够和开发人员很好的交谈
+职业素质-责任心-学习能力-怀疑精神-沟通能力-专注力-洞察力-团队精神-注重积累 +制定测试计划的五个步骤:-分析和测试软件需求-定义测试策略
-定义测试环境
-定义测试管理
-编写和审核测试计划
如果在需求分析阶段发现并结果问题需要花费$1,则在设计阶段解决同样的问题需花费$5,在编码阶段需$10,交付后解决同样的问题需花费$200。——越早测试越好-在需求分析过程中测试人员需要进行如下工作:
1)理解需求,参与审核需求文档;
2)理解项目的目标、限制,了解用户的应用背景;
3)编写测试计划;
4)准备测试资源。
+需求测试
-需求测试测试的对象是主意而不是代码,针对文档进行测试。
+好的需求文档的特征-具有清晰的格式和文档结构-需求的内容正确-需求的内容完整-需求具有可行性需求的必要性
-对不同的需求优先等级进行定义-描述明确-可证性和可测试性-可修改性-可追踪-需求文档被及时更新
+需求测试内容
-需求文档是否符合公司的格式要求
-是否正确
-要保证需求文档中所描述的内容是真实可靠的-这是“真正的”需求吗?描述的产品是否是要开发的产品?
-需求是否完备?第一个发布的版本是否需要更多的功能?列出的需求可以减少一部分?-需求是否兼容?需求有可能是矛盾的。
-需求是否可实现?如:需求设想的设备是否比实际运行的要快?需求要求的内存、I/0设备是否太多?
需求的输入或输出设备要求的分辨率是否要求过高?
-需求是否合理?在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。
-需求是否可测?对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。+需求测试方法-复查review-走查walkthrough-审查inspection
+测试策略的内容
-确定测试范围 软件是无法被完全测试的-确定测试方法 不同的系统需要不同的测试方法
-定义测试标准 入口标准,暂停和继续的标准,出口标准等
+软件测试结束的标准
-基于测试用例的使用规则
1)构造测试用例(由相关人员进行评审)
2)执行测试用例中,当测试用例的不通过率达到20%则拒绝继续测试,待开发人员修正软件后再继续。
3)当功能性测试用例通过率达到100%,非功能性测试用例通过率达到90%时,允许正常结束。
-基于“测试期缺陷密度”规则
--------------含义:对软件测试一个CPU小时发现的缺陷数,比较适用于系统测试-基于“运行期缺陷密度”规则
--------------含义:把软件运行一个CPU小时发现的缺陷数,比较适用于验收测试注:一个阶段的出口标准!=下一个阶段的入口标准
系统测试结束的标准!=软件的发布标准
发布标准!=软件0缺陷
-选择测试工具 是否需要,需要什么工具,怎么获取
-降低软件测试代价是企业普遍关注的问题,可通过
a.减少冗余和无价值的测试;
b.减少测试阶段(万般无奈下)
+测试环境
-基本内容:设备环境、软件环境、数据环境
-需考虑的因素-计算机平台-操作系统-浏览器-软件支持平台-外围设备-网络环境-其他专用设备
-搭建测试环境时的配置原则:-使用的频度或范围-实效的可能性-最大限度的模拟真实环境 +测试管理 由于测试工程中设计的人员、活动、工具是很多的,在制定测试计划时需要对这些因素进行管理
-选择缺陷管理工具和测试管理工具
-定义工作进度
-建立风险管理计划
+可能遇到的风险
·由于设计、编码阶段出现大量质量问题,导致测试工作量时间增加
·开始测试时所需的硬件、软件没有准备好
·未能完成对测试人员的技术培训
·测试时的人力资源安排不足
·测试过程中,发生了大量的需求变更
·测试过程中,项目的开发计划被大幅度调整
·不能及时准备好测试所需的环境
·不能及时准备好测试数据
+风险管理的过程
·识别风险
·评估风险
·制定对策
·跟踪风险
+测试设计与开发
+总体设计
-投入产出:测试设计的输入是测试计划,输出是评审过的测试用例集合-定义设计目标遵循的原则
-清楚地说明没项测试的目标
-使每项测试的目标单一,可以对应到规格说明书中的一项需求
-只说明测试应该完成什么工作,而不说明如何完成-流程:总体设计-开发测试用例-评审测试用例
I.定义设计目标
II.定义输入说明
III.定义测试环境和配置
IV.测试设计文档
V.开发测试用例
+测试用例
-概念:为特定目标开发的测试输入、执行条件和预期结果的集合。
+好的测试用例:
-容易发现软件的错误
-精确的重复某测试失败的情景,可重复性
-清晰的定义一个或多个期望的结果
-没有冗余
+测试用例的作用
-指导测试的实施
-作为编写测试脚本的“设计规格说明书”
-评估测试标准的度量基准
-分析缺陷的标准
+白盒测试用例设计
+设计方法
+逻辑覆盖法
-语句覆盖
-判定覆盖
-条件覆盖
-判定-条件覆盖
-条件组合覆盖
-路经覆盖
-基本路经法
+辅助模块设计
-驱动模块:相当于被测程序的主程序。接受测试数据,把这些数据传给被测模块然后输出实际测试结果。
-桩模块:用于调用被测模块调用的子模块。可以做少量的数据操作,不需要把子模块的所有功能都带进来,但不容许什么都不做。
+黑盒测试用例设计
-等价类划分法
-边界值法——“缺陷遗漏在角落里,聚集在边界上。”
-因果图法弥补等价类和边界值法的不足
-错误推测法
-测试用例的管理可以通过配置管理工具cvs,vss,ClearCase等实现,以保证测试是可重复的。+常见错误分析
-用户界面问题
·输入无合法性检查和值域检查。
·界面信息不能及时更新,不能正确反映数据状态,甚至对用户产生误导。
·表达不清或过于模糊的信息提示。
·要求用户输入多余的本来系统可以自己得到的数据。
·为了得到某个设置或对话框用户必须做许多冗余的操作,如对话框嵌套太多。·不能记忆用户的设置或操作习惯,使每次进入系统用户都需重新操作一次初始环境。·不经用户确认就对系统或数据进行了重大修改。
-形象类问题
·不符合用户的操作习惯。如,快捷键定义不科学不实用,甚至无快捷键。
·不够专业,缺乏基本知识。
·界面中英文混杂,甚至拼写错误。
·说明书或帮助的排版格式不专业:中英文不对应,标点的半全角问题,没有排版准则。·界面元素参差不齐,文字不能完全显示。
-稳定性问题
·不可重现的死机,或不断申请但不能完全释放资源,使系统性能越来越低。
·主系统和子系统使用了相同的临界资源而相互不知道。如:使用相同的类名或临时文件名、使用同样的数据库字段名或登陆帐号。
·不能重现的错误,许多与代码中的未初始化变量有关,有些与系统不检查异常情况(网络中断、内存申请
不成功、长时间无响应等)有关。
-其他问题
·运行时不检查内存、硬盘空间、数据库等。
·无根据的假设用户环境:硬件/网络情况;有些动态库;假设网络随时都是联通的。·提供的版本带病毒。
·提供错误的版本给测试组或测试用户,或程序员与测试组使用不同版本。
·用户现场开放和修改,又没有记录和保留。
·版本中部分内容或接口倒退,或出现版本管理混乱。
·有些选项永远都是灰的,或有些在该变灰时没变灰。
+测试用例的评审
-测试或测试组件完全针对的是需求中列出的功能吗?
-测试组件是否覆盖了所有的需求?
-有冗余的吗?
-每个测试步骤都有清楚描述的预期结果吗?
+优先级
+3级
优先级1:此测试用例必须执行-2:有时间就执行-3:可以不执行
+5级
1:此测试必须通过,否则产品发布存在危险2:在发布前必须执行3:时间允许就执行4:此测试可以在下一次发布或发布后短期内执行5:可以不测试