软件测试课件_第1页
软件测试课件_第2页
软件测试课件_第3页
软件测试课件_第4页
软件测试课件_第5页
已阅读5页,还剩326页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件测试概述1.1.1软件可靠性问题因软件设计故障与因计算机硬件设计故障而引发的系统失效的比例大约是:10:1运行软件的驻留故障密度(每千行代码的故障数目):

——要求很高的关键财务或财产软件为:每千行代码1~10个故障

——关键的生命软件为:每千行代码0.01~1个故障IEEE将软件可靠性定义为:系统在特定环境下,在给定的时间内无故障运行的概率。软件可靠性是对软件在设计、开发以及所预定的环境下具有能力的置信度的一个度量,是衡量软件质量的主要参数之一。而软件测试则是保证软件质量、提高软件可靠性的最重要手段。

1.1.2软件缺陷与故障1、软件缺陷和软件故障案例案例1美国迪斯尼公司的狮子王游戏软件bug兼容性问题案例2美国航天局火星登陆事故系统测试衔接问题

案例3跨世纪“千年虫”问题案例4爱国者导弹防御系统炸死自家人系统时钟误差积累

案例5Windows2000中文输入法漏洞案例6金山词霸bug

上述所有实例中的软件问题在软件工程或软件测试中都被称为软件缺陷或软件故障。

软件缺陷与故障(续)2、软件缺陷的定义(1)软件未达到产品说明书中已经标明的功能;(2)软件出现了产品说明书中指明不会出现的错误;(3)软件未达到产品说明书中虽未指出但应当达到的目标;

(4)软件功能超出了产品说明书中指明的范围;(5)软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不良。举例:计算器内的嵌入式软件软件缺陷与故障(续)3、软件缺陷的特征“看不到”——软件的特殊性决定了缺陷不易看到“看到但是抓不到”

——发现了缺陷,但不易找到问题发生的原因所在1.1.3软件缺陷产生的原因图1-1软件缺陷产生的原因分布其他10%软件产品说明书(需求)56%编写代码7%设计27%Return1.2软件测试基础理论1.2.1软件测试的定义1.2.2软件测试的基本理论1.2.3软件测试和缺陷修复的代价1.2.4软件测试技术概要Return1.2.1软件测试的定义1、软件测试的定义软件测试就是在软件投入运行前,对软件需求分析、设计规格说明和编码实现的最终审查,它是软件质量保证的关键步骤。通常对软件测试的定义有两种描述:定义1:软件测试是为了发现错误而执行程序的过程。定义2:软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例,并利用这些测试用例运行程序以及发现错误的过程,即执行测试步骤。软件测试的定义(续)测试:所谓测试的含义,首先是一项活动,在这项活动中某个系统或组成的部分将在特定的条件下运行,结果将被观察和记录,并对系统或组成部分进行评价。测试活动有两种结果:找出缺陷和故障,或显示软件执行正确。测试是一个或多个测试用例的集合。测试用例:所谓测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果;测试用例是执行测试的最小实体。测试步骤:测试步骤详细规定了如何设置、执行、评估特定的测试用例。软件测试的定义(续)2、软件测试的基本问题软件生命周期:一个软件生命周期包括制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护、软件停用等8个阶段。软件测试的对象:

——软件测试不等于程序测试。

——软件测试贯串于软件定义和开发的整个过程。

——软件开发过程中所产生的需求规格说明、概要设计规格说明、详细设计规格说明以及源程序都是软件测试的对象。软件测试的定义(续)2、软件测试的基本问题(续)软件测试在软件生命周期中横跨两个阶段:第一个阶段:单元测试阶段,即在每个模块编写出以后所做的必要测试。第二个阶段:综合测试阶段,即在完成单元测试后进行的测试,如集成测试、系统测试、验收测试。软件测试涉及的关键问题包括四个方面:(1)测试由谁来执行。(2)测试什么。(3)什么时候进行测试。(4)怎样进行测试。1.2.2软件测试的基本理论1、软件测试的目的(1)测试是程序的执行过程,目的在于发现错误;不能证明程序的正确性,除非仅处理有限种情况。(2)检查系统是否满足需求也是测试的期望目标。(3)一个好的测试用例在于发现了还未曾发现的错误;一次成功的测试则是发现了错误的测试。注意:测试无法说明错误不存在,只能说明软件错误已出现。软件测试的基本理论(续)2、软件测试的原则(1)尽早地和及时地测试;(2)测试用例应当由测试数据和与之对应的预期结果这两部分组成;(3)在程序提交测试后,应当由专门的测试人员进行测试;(4)测试用例应包括合理的输入条件和不合理的输入条件;(5)严格执行测试计划,排除测试的随意性;(6)充分注意测试当中的群体现象;(7)应对每一个测试结果做全面的检查;(8)保存测试计划、测试用例、出错统计和最终分析报告,为维护工作提供充分的资料。软件测试的基本理论(续)3、软件测试的分类软件测试按照不同的划分方法,有不同的分类:按照软件测试用例的设计方法而论,软件测试可以分为白盒测试法和黑盒测试法。按照软件测试的策略和过程来分类,软件测试可分为单元测试、集成测试、系统测试、验证测试和确认测试。软件测试的基本理论(续)4、测试信息流程测试信息流程如图1-2所示。测试过程中需要三类输入:软件配置、测试配置和测试工具。软件配置测试配置测试工具测试结果分析改正错误可靠性分析回归测试错误测试结果修正的软件测试结果预测的可靠性预期结果图1-2测试信息流程软件测试的基本理论(续)5、软件测试的周期性软件测试的周期性是“测试->改错->再测试->再改错”这样一个循环过程,如下图1-3所示。测试周期开发/改错改错测试周期改错串行方式开发者:…...开发者:并行方式测试者:开发/改错开发/改错最终回归测试回归测试1测试周期1……功能冻结代码冻结测试周期2图1-3软件测试的周期性软件测试的基本理论(续)6、测试停止的依据(标准)第一类标准:测试超过了预定时间,则停止测试。第二类标准:执行了所有的测试用例,但并没有发现故障,则停止测试。

第三类标准:使用特定的测试用例设计方案作为判断测试停止的基础。

第四类标准:正面指出停止测试的具体要求,即停止测试的标准可定义为查出某一预订数目的故障。

第五类标准:根据单位时间内查出故障的数量决定是否停止测试。

1.2.3软件测试和缺陷修复的代价软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中,都有可能产生和发现缺陷。随着整个开发过程的时间推移,更正缺陷或修复问题的费用呈几何级数增长。

图1-4软件缺陷在不同阶段发现时修复的费用示意图020406080100编制说明书设计阶段编写代码测试发布1.2.4软件测试技术概要软件测试的策略:就是测试将按照什么样的思路和方式进行。通常,软件测试要经过单元测试、集成测试、确认测试、系统测试以及验收测试。软件测试技术:(1)白盒测试和黑盒测试(2)静态测试和动态测试(3)传统测试方法和面向对象测试的方法(4)特定环境及应用的测试软件测试技术概要(续)软件测试技术的发展趋势:(1)软件验证技术(2)静态测试分析技术(3)测试数据的选择——主要对测试用例进行选择

通常从下面几个方面评价测试用例的质量:检测软件缺陷的有效性、测试用例的可重用性、测试用例的经济性、测试用例的可维护性(4)集成化测试——研究如何实现软件测试的自动化过程以及相关的一系列内容。Return1.3软件开发过程1.3.1软件产品的组成1.3.2软件开发项目组1.3.3软件开发模式Return1.3.1软件产品的组成1、软件产品需要各种开发投入

图1-5获得软件产品的工作示意图产品说明书、产品审查、设计文档、进度计划、上一版本信息反馈、商业竞争对手的同类软件产品情况、客户调查、易用性数据、观察与感受说明书开发过程软件产品的组成(续)2、客户需求客户需求包括对客户调查所收集的详细信息、以前软件的使用情况及存在的问题、竞争对手的软件产品信息等等。通过分析客户需求,可以确定将要开发的软件产品应该具有哪些功能。3、产品说明产品说明书的作用就是对客户需求信息进行综合描述,并包括用户没有提出、但软件产品本身必须要实现的要求,从而针对产品进行定义并确定其功能。软件产品的组成(续)4、设计文档构架。即产生描述软件整体设计的文档,包括软件所有主要部分的描述以及相互间的交互方式。数据流示意图。表示数据在程序中如何流动的正规示意图。通常由圆圈和线条组成,所以也称为泡泡图。状态变化示意图。将软件分解为基本状态或者条件的另一种正规示意图,表示不同状态之间的变化的方式。流程图。用图形描述程序逻辑的最常用方式之一。根据详细的流程图编写程序代码简单方便。注释代码。代码注释是便于维护代码的程序员掌握代码的内容和执行方式。软件产品的组成(续)5、测试文档一般测试文档所包含的内容:测试计划。描述用于验证软件是否符合产品说明书和客户需求的整体方案。测试用例。依据测试的项目,并描述验证软件的详细步骤。软件测试报告。描述依据测试用例找出的问题,通常提交测试报告。归纳、统计和总结。采用图表、表格和报告等形式来描述整个测试过程。

软件产品的组成(续)6、开发进度表软件项目的开发进度通常使用Gantt图表来进行描述。7、软件产品组成部分(1)程序代码(2)帮助文件(3)用户手册(4)样本和示例(5)标签(6)产品支持信息(7)图表和标志(8)错误信息(9)广告与宣传材料(10)软件的安装(11)软件说明文件(12)测试错误提示信息

1.3.2软件开发项目组项目管理经理:全程负责整个软件项目的开发。

系统设计师:设计整个系统构架或软件构思。

程序员:负责设计、编写程序,并修改软件中的缺陷。

软件测试员/测试师:负责找出并报告软件产品的问题,与开发组密切合作,进行测试并报告发现的问题。

技术制作、用户助手、用户培训员、手册编写和文件档案专员:负责编写软件产品附带的文件和联机文档。结构管理和制作人员:负责将程序员编写的全部文档资料合并成一个软件包。1.3.3软件开发模式1、大棒开发法源于能量爆发创造宇宙,万物都由能量和物质积聚而成的理论,但如果不是遵循某种正确的排列和组合,形成的将不是预先期望的事物。大棒模式与上述理论一样:一大堆能量(这里指开发软件所需的人力和物力)放在一起,巨大的能量进行释放,通常的结果可能是产生了优秀的软件产品或成为一堆“废品”(不成功的软件)。优点:思路简单,通常可能是开发者的“突发奇想”缺点:开发过程是非工程化的,随意性大关于测试:有的较简单,有的则非常困难软件开发模式(续)2、边写边改法采用边写边改法的软件开发通常只是有了比较粗略的想法就开始进行简单的设计、然后进行较长的反复编写、测试与修复这样一个循环的过程。在认为无法更精细的描述软件产品要求时,就发布产品。优点:能够较为迅速的展现成果,适合需要快速制作而且用完就扔的小项目,如示范程序、演示程序等。缺点:其编码和测试可能将是长期的循环往复的过程。软件开发模式(续)产品说明书代码编制、测试、修复

最终产品图1-6边写边改开发模式软件开发模式(续)3、瀑布法瀑布模式是将软件生命周期的各项活动,规定为按照固定顺序相连的若干个阶段性工作,形如瀑布流水,最终得到软件产品。

优点:易于理解;调研开发的阶段性;强调早期计划及需求调查;确定何时能够交付产品及何时进行评审与测试。缺点:需求调查分析只进行一次,不能适应需求变化;顺序的开发流程,使得开发中的经验教训不能反馈到该项目的开发中去;不能反映出软件开发过程的反复与迭代性;没有包含任何类型的风险评估;开发中出现的问题直到开发后期才能够显露,因此失去及早纠正的机会。软件开发模式(续)问题定义分析研究需求分析软件设计编码测试维护定义阶段开发阶段维护阶段图1-7瀑布开发模式软件开发模式(续)4、快速原型法

根据客户需求在较短的时间内解决用户最迫切解决的问题,完成可演示的产品。这个产品只实现最重要功能,在得到用户的更加明确的需求之后,原型将丢弃。需求分析原型开发原型评价最终设计系统实现用户反馈图1-8快速原型开发模式软件开发模式(续)5、螺旋模式法螺旋模式是瀑布模式与边写边改演化模式相结合,并加入风险评估所建立的软件开发模式。

主要思想是在开始时不必详细定义所有细节,而是从小开始,定义重要功能,尽量实现,接受客户反馈,进入下一阶段,并重复上述过程,直到获得最终产品。

每一螺旋(开发阶段)包括5个步骤:①确定目标,选择方案和限制条件。②对方案风险进行评估,并能解决风险。③进行本阶段的开发和测试。④计划下一阶段。⑤确定进入下阶段的方法。优点:严格的全过程风险管理;强调各开发阶段的质量;提供机会评估项目是否有价值继续下去。软件开发模式(续)图1-9螺旋开发模式详细设计风险分析评估方案累计成本提交线制定计划原型1原型2原型3可运行原型风险分析风险分析需求计划开发计划集成与测试软件需求软件产品设计需求确定设计确定实现编码单元测试集成测试验收测试1.4软件开发与软件测试的关系1、测试与开发各阶段的关系Return图1-10

软件测试与软件开发过程的关系需求分析说明书详细设计说明书源程序代码单元测试集成测试确认测试概要设计说明书软件开发与软件测试的关系(续)测试在开发阶段的作用:项目规划阶段:负责从单元测试到系统测试的整个测试阶段的监控。需求分析阶段:确定测试需求分析、系统测试计划的制定,评审后成为管理项目。详细设计和概要设计阶段:确保集成测试计划和单元测试计划完成。编码阶段:由开发人员进行自己负责部分的测试代码。在项目较大时,由专人进行编码阶段的测试任务。测试阶段(单元、集成、系统测试):依据测试代码进行测试,并提交相应的测试状态报告和测试结束报告。软件开发与软件测试的关系(续)图1-11软件测试与软件开发的并行性需求分析需求评审概要设计详细设计概要设计评审单元测试编码设计走查编码走查各子模块有效性测试集成测试测试计划测试过程测试评审…………**项目阶段任务的里程碑********2、测试与开发的并行性软件开发与软件测试的关系(续)图1-12完整的开发流程项目规划项目需求分析项目概要分析项目详细分析代码编写测试代码编写测试需求分析系统测试计划集成测试计划单元测试计划产品发布系统测试集成测试单元测试3、完整的软件开发流程1.5软件测试过程1.5.1制定测试计划1.5.2测试执行过程Return1.5.1制定测试计划1、制定计划本阶段的主要工作内容

——对需求规格说明书的仔细研究

——将要测试的产品分解成可独立测试的单元

——为每个测试单元确定采用的测试技术

——为测试的下一个阶段及其活动制定计划制定计划包括:(1)概要测试计划(2)详细测试计划制定测试计划(续)2、测试大纲(用例)

测试大纲是软件测试的依据,包括测试项目、测试步骤、测试完成的标准。测试大纲的本质

——从测试的角度对被测对象的功能和各种特性的细化和展开。测试大纲的好处

——保证测试功能不被遗漏,也不被重复测试

——合理安排测试人员——使得软件测试不依赖于个人制定测试计划(续)3、软件测试报告软件测试报告是软件测试过程中最重要的文档,它的内容包括:记录问题发生的环境——如:各种资源的配置情况记录问题的再现步骤记录问题性质的说明记录问题的处理进程——问题处理进程从一定角度上反映测试的进程和被测软件的质量状况以及改善过程。1.5.2测试执行过程1、测试执行过程的三个阶段(1)初测期——测试主要功能和关键的执行路径,排除主要障碍。(2)细测期——依据测试计划和测试大纲、测试用例,逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等;预期可发现大量不同性质、不同严重程度的错误和问题。(3)回归测试期——系统已达到稳定,在一轮测试中发现的错误已十分有限;复查已知错误的纠正情况,确认未引发任何新的错误时,终结回归测试。测试执行过程(续)图1-13三个测试期阶段图示初测期功能冻结代码冻结回归测试期细测期02040608010012014016012345678910111213141516171819出错数时间测试执行过程(续)2、集成测试过程中的两个重要里程碑在集成测试过程中的两个重要的里程碑是功能冻结和代码冻结的确定。这两个里程碑界定出回归测试期的起止界限。功能冻结(Function/FeatureFreeze)——经过测试,符合设计要求,确认系统功能和其他特性均不再做任何改变。代码冻结(CodeFreeze)——理论上,在无错误时冻结程序代码,但实际上,代码冻结只标志系统的当前版本的质量已达到预期的要求,冻结程序的源代码,不再对其做任何修改。这个里程碑是设置在软件通过最终回归测试之后。1.6软件质量保证概要1.6.1软件质量管理1.6.2软件能力成熟度模型1.6.3ISO9000标准简介Return1.6.1软件质量管理1、质量与质量管理的概念质量:是“反映实体满足明确和隐含需要的能力和特性综合”。因此,质量是一种需要,“是一组固有特性满足要求的程度”。质量管理:质量管理是指以组织为质量中心、企业全员参与为基础,为追求客户满意和组织所有受益者满意而建立和形成的一整套质量方针、目标和体系。质量管理通过质量策划设定组织的质量目标,并规定必要的过程和相关资源;通过质量控制监视内部质量过程,排除质量控制过程中可能存在的缺陷隐患;通过质量改进提高内部的质量管理能力,改善组织内部的质量过程;通过质量保证提供足够的信任证据,表明组织有能力满足客户的质量要求。软件质量管理(续)质量管理体系:它是质量管理的运作实体,由组织结构、程序、过程、资源4个基本部分组成。质量策划:它是“确定质量以及采用质量管理体系要素和要求的活动”,包括产品策划、质量管理体系管理和运作策划、编制质量计划。质量控制:为达到质量要求所采取的作业技术和活动。质量控制的对象是过程。

质量保证:是为了提供足够的信任证据,证明组织有关的各类实体有能力满足质量要求所实施并在必要时进行证实的有计划、有系统的活动。质量改进:是为了向组织的所有受益者提供更多的收益所采用的提高质量过程和效率的各种措施。软件质量管理(续)质量管理的发展阶段(1)产品质量检验阶段:这个时期特征是对产品的质量进行检验。产品质量的检验只是一种事后的检查,不能预防不合格品的产生。(2)统计质量管理阶段:它是运用概率论和数理统计的原理,提出控制生产过程,预防不合格产品的思想和方法。即通过小部分样品测试,推测和控制全体产品或工艺过程的质量状况。

(3)全面质量管理阶段:从以质量管理专业人员为核心进行质量管理,发展到管理者推动、组织各部门的人员都来进行学习和实行质量管理。

软件质量管理(续)从质量管理理论的发展历史可以看出:

——质量管理从单纯的对产品质量进行检验发展到对产品形成过程进行控制

——控制方法从静态发展到动态的、持续的过程改进质量管理理论发展到今天:

——其核心思想已表现为对过程的策划、控制和过程能力的持续改进

软件质量管理(续)2、软件质量管理内容软件质量:是软件产品的特性可以满足用户的功能、性能需求的能力。软件的质量管理:是软件组织在软件产品生产中的质量策划、质量控制、质量保证和质量改进等等与质量有关的相互协调的活动。软件质量管理的内容包括:(1)软件质量策划(2)软件组织的质量过程(3)软件质量控制与质量保证(4)软件质量的度量和验证(5)软件质量改进1.6.2软件能力成熟度模型软件能力成熟度模型(CMM,CapabilityMaturityModel):

——是软件行业标准模型,用来定义和评价软件企业开发过程的成熟度,提供如何做才能够提高软件质量的指导。CMM的基本原理:

——CMM将软件组织的过程能力成熟度分为5个级别,每一个级别定义一组过程能力目标,并描述要达到这些目标应该采取的各种实践活动。CMM的主要作用:——提供了一个软件过程改进的框架。根据CMM模型,软件开发者(机构或组织)能够大幅度的提高按计划、高效率、低成本的提交有质量保证的软件产品的能力。软件能力成熟度模型(续)1、CMM的基本过程概念过程:为达到目的而执行的所有步骤的系列。软件过程:开发和维护软件及其相关产品的一组活动、方法、实践和改革。软件过程结构:对组织标准软件过程的一种高级别描述,它描述组织标准软件过程内部的过程元素之间的顺序、接口、内部依赖等关系,以及与外部过程之间的接口和依赖关系。软件过程元素:用于描述软件过程的基本元素,每一个过程元素包含一组定义的、有限的、封闭的相关任务。软件过程定义:CMM中过程定义的基本概念是定义组织的标准软件过程。软件能力成熟度模型(续)2、CMM的5个分级标准优化级(5)已管理级(4)已定义级(3)可重复级(2)初始级(1)标准一致的过程不断改进过程可预测的过程有纪律的过程图1-14软件过程成熟度的5个等级软件能力成熟度模型(续)CMM的分级结构和其主要特征:初始级:其特点是软件过程无秩序,有时甚至是混乱的。可重复级:已建立了基本的项目管理过程,可用于对成本、进度和功能特性进行跟踪。已定义级:用于管理的、工程的软件过程均已实现文档化、标准化,并形成了整个软件组织的标准软件过程。管理级:软件过程和产品质量有详细的度量标准,软件过程和产品质量得到了定量的认证和控制。优化级:通过对来自过程、新概念和新技术等方面各种有用信息的定量分析,能够不断地、持续性地对过程进行改进。软件能力成熟度模型(续)除第一级外,CMM的每一级是按照完全相同的内部结构构成的。成熟度等级为顶层,不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期的程度。在每个成熟度级别中(第1级除外),包含了实现这一级目标的若干关键过程域(KPA)。每一级的每个关键过程域进一步包含若干关键实践(KeyPractice,KP)。无论哪一个KPA,其实践都统一按5个公共特性进行组织,即每一个KPA都包含5类KP,使整个软件过程改进工作自上而下形成一种有规律的步骤。软件能力成熟度模型(续)关键过程域:是指一系列相互关联的操作活动,这些活动反映了一个软件组织改进软件过程时必须集中力量改进的几个方面。目标:是指某个关键过程域中的关键实践,它表示每一个关键过程域的范围、边界和意图。公共特性:为了完成关键过程域中的实践活动,CMM将其活动分为具有公共特性的5个部分,包括执行约定、执行能力、实施活动、度量和分析以及验收实施。这些部分的特性有效地指定了一个关键区域的实现范围、结构要求和实施内容。关键实践:关键实践就是一些主要实践活动。每个关键过程域最终由关键实践所组成,通过实现这些关键实践来达到关键过程域的目标。1.6.3ISO9000标准简介ISO9000标准——是为制造行业制定的质量管理和质量评判的一系列标准

——定义了一套基本达标的做法,有助于企业能够一致地交付符合客户质量要求的产品(或服务)ISO9000标准的目标——在于开发过程,而不是产品——关心的是进行工作的组织方式,而不是工作成果ISO9000只决定过程的要求是什么,而不管如何达到。即:ISO9000指出要做什么,但不指出怎样做。ISO9000标准简介(续)1、ISO9000标准的构成2000版的ISO9000系列标准主要由下列标准构成:ISO9000:2000《质量管理体系:基础和术语》ISO9000:2000《质量管理体系:要求》ISO9000:2000《质量管理体系:业绩改进指南》2、ISO9000标准的要求3、ISO9000质量管理的原则1.7软件测试职业1.7.1对软件测试的误解1.7.2软件测试职业和职位1.7.3软件测试职业素质1.7.4软件测试人才的现状Return1.7.1对软件测试的误解如果发布的软件有质量问题,那是软件测试人员的错。软件测试技术要求不高,至少比编程容易多了。软件测试随便找一个能力差的人就能做。有时间就多测试一些,来不及就少测试一些。软件测试是测试人员的事,与开发人员无关。设计-实现-测试,软件测试事开发后期的一个阶段。1.7.2软件测试职业和职位软件测试员

软件测试工程师/程序分析员

高级软件测试工程师/程序分析员软件测试组负责人

软件测试/编程负责人

软件测试/质量保证/项目经理

1.7.3软件测试职业素质软件测试员的目标:

——发现潜在的软件缺陷软件测试员应具备的素质:①具有探索精神②具有创造性③坚持不懈精神④故障排除专家⑤判断准确⑥追求完美⑦沟通能力1.7.4软件测试人才的现状1、软件测试人员的合理比例在软件产业发达的国家:软件测试在人员配备和资金投入方面占据相当的比重。微软为打造Windows2000,1700多个开发人员,以及3200个测试人员,开发和测试人员之比约为三比五。HP公司的测试人员和开发人员的比例为一比一,这是很多先进软件企业通常的人员配比。在国内:企业往往忽视软件测试,很多企业都没有软件测试部门,甚至不设置软件测试的岗位,造成产品质量得不到保证。测试人员大都不到开发人员的5%,随着产业和企业的发展,企业必然需要大量的测试人员。软件测试人才的现状(续)2、软件测试人才紧缺软件测试人才需求快速增长,体现在:(1)中国软件产业正在快速增长,需要大量软件相关人才;(2)软件企业的发展要求测试人才达到一个合适的比例。近一两年软件企业开始认识到软件测试对于提高软件质量的重要性,开始重视软件测试,但由于历史的原因,找不到合适的软件测试人员。软件测试人才的现状(续)3、三个招聘案慧谷-博为峰软件测试工作室曾经接受企业委托,招聘二十名软件测试工程师,结果收到的简历不到十份,合格的只有三份,最后录用的只有一人;而招聘一名程序员就会收到六十多份简历。上海一位软件企业的副总裁说,他们曾招聘8名基于Unix操作系统的测试工程师,但是半年多招不到合适的人。微软亚洲工程院院长张宏江博士最近告诉媒体:“过去两三个月,我最主要的精力都花在雇人上。遗憾的是,1万多名应聘者中,居然找不到足够合适的人。”

微软最紧缺的人才包括软件测试人员、软件项目管理员、软件架构师,1万多名应聘者中最后合格的只有50多人。作业布置P36习题与思考第2题、第3题、第4题

软件测试策略与过程2.1软件测试的复杂性分析1、无法对程序进行完全测试(1)测试所需要的输入量太大(2)测试的输出结果太多(3)软件实现的途径太多(4)软件规格说明没有一个客观标准2、测试无法显示潜在的软件缺陷和故障

——通过软件测试只能报告软件已被发现的缺陷和故障,无法报告隐藏的软件故障。3、存在的故障现象与发现的故障数量成正比

——结论:应当对故障集中的程序段进行重点测试Return软件测试的复杂性分析(续)

4、不能修复所有的软件故障——原因:没有足够的进行修复;修复的风险较大;不值得修复;可不算做故障的一些缺陷;“杀虫剂现象”。

——结论:关键是要进行正确的判断、合理的取舍,根据风险分析决定哪些故障必须修复,哪些故障可以不修复。

5、软件测试的代价

——工作原则:就是如何将无边无际的可能性减小到一个可以控制的范围,以及如何针对软件风险做出恰当选择,去粗存精,找到最佳的测试量,使得测试工作量不多也不少,既能达到测试的目的,又能较为经济。

软件测试的复杂性分析(续)软件缺陷故障数量测试工作量测试中测试后测试费用遗漏缺陷数目优化测试量图2-1测试工作量和软件缺陷数量之间的关系2.2软件测试方法与策略2.2.1静态测试与动态测试2.2.2黑盒测试与白盒测试2.2.3软件测试过程Return软件测试策略什么是软件测试策略?——是为软件工程过程定义的一个软件测试的模板,也就是把特定的测试用例方法放置进去的一系列步骤。软件测试策略包含的特征:(1)测试从模块层开始,然后扩大延伸到整个基于计算机的系统集合中。(2)不同的测试技术适用于不同的时间点。(3)测试是由软件的开发人员和(对于大型系统而言)独立的测试组来管理的。(4)测试和调试是不同的活动,但是调试必须能够适应任何的测试策略。软件测试充分性准则对任何软件都存在有限的充分测试集合。如果一个软件系统在一个测试数据集合上的测试是充分的,那么再多测试一些数据也应该是充分的。这一特性称为单调性。即使对软件所有成分都进行了充分的测试,也并不表明整个软件的测试已经充分了。这一特性称为非复合性。即使对软件系统整体的测试是充分的,也并不意味软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。软件测试的充分性应该与软件的需求和软件的实现都相关。软件越复杂,需要的测试数据就越多。这一特性称为复杂性。测试得越多,进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。2.2.1静态测试与动态测试1、静态测试静态测试不实际运行软件,主要是对软件的编程格式、结构等方面进行评估。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行,也可以借助软件工具自动进行。静态测试方法也可利用计算机作为对被测程序进行特性分析的工具,但与人工测试方式有着根本区别。另一方面,因它并不真正运行被测程序,只进行特性分析,这又与动态方法不同。所以,静态方法常常称为“分析”,静态测试是对被测程序进行特性分析方法的总称。静态测试与动态测试(续)

代码检查代码检查包括代码走查、桌面检查、代码审查等,主要检查代码和设计的一致性,代码对标准的遵循、可读性,代码的逻辑表达的正确性,代码结构的合理性等方面。代码检查的具体内容:变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等。代码检查的优点:在实际使用中,代码检查比动态测试更有效率,能快速找到缺陷,发现30%~70%的逻辑设计和编码缺陷;代码检查看到的是问题本身而非征兆。代码检查的缺点:非常耗费时间,而且代码检查需要知识和经验的积累。静态测试与动态测试(续)

静态结构分析静态结构分析主要是以图形的方式表现程序的内部结构。例如函数调用关系图、函数内部控制流图。其中:

——函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系;——控制流图显示一个函数的逻辑结构,由许多节点组成,一个节点代表一条语句或数条语句,连接结点的叫边,边表示节点间的控制流向。静态测试与动态测试(续)

代码质量度量软件质量包括六个方面:功能性、可靠性、易用性、效率、可维护性和可移植性。软件的质量是软件属性的各种标准度量的组合。针对软件的可维护性,目前业界主要存在三种度量参数:Line复杂度、Halstead复杂度和McCabe复杂度。其中Line复杂度以代码的行数作为计算的基准。Halstead以程序中使用到的运算符与运算元数量作为计数目标(直接测量指标),然后可以据以计算出程序容量、工作量等。McCabe复杂度一般称为圈复杂度,它将软件的流程图转化为有向图,然后以图论来衡量软件的质量。静态测试与动态测试(续)静态测试阶段的任务:(1)检查算法的逻辑正确性。(2)检查模块接口的正确性。(3)检查输入参数是否有合法性检查。(4)检查调用其他模块的接口是否正确。(5)检查是否设置了适当的出错处理。(6)检查表达式、语句是否正确,是否含有二义性。(7)检查常量或全局变量使用是否正确。(8)检查标识符的使用是否规范、一致。(9)检查程序风格的一致性、规范性。(10)检查代码是否可以优化,算法效率是否最高。(11)检查代码注释是否完整,是否正确反映了代码的功能。静态测试与动态测试(续)静态测试可以完成以下工作:(1)发现下列程序的错误:错用局部变量和全局变量;未定义的变量、不匹配的参数;不适当的循环嵌套或分支嵌套、死循环、不允许的递归;调用不存在的子程序,遗漏标号或代码。(2)找出以下问题的根源:从未使用过的变量;不会执行到的代码、从未使用过的标号;潜在的死循环。(3)提供程序缺陷的间接信息:所用变量和常量的交叉应用表;是否违背编码规则;标识符的使用方法和过程的调用层次。(4)为进一步查找做好准备。(5)选择测试用例。(6)进行符号测试。静态测试与动态测试(续)2、动态测试动态方法的主要特征是:——计算机必须真正运行被测试的程序,通过输入测试用例,对其运行情况即输入与输出的对应关系进行分析,以达到检测的目的。动态测试包括:(1)功能确认与接口测试(2)覆盖率分析(3)性能分析(4)内存分析2.2.2黑盒测试和白盒测试若测试规划是基于产品的功能,目的是检查程序各个功能是否能够实现,并检查其中的功能错误,则这种测试方法称为黑盒测试(Black-boxTesting)方法。

——黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它是一种从用户观点出发的测试,一般被用来确认软件功能的正确性和可操作性。若测试规划基于产品的内部结构进行测试,检查内部操作是否按规定执行,软件各个部分功能是否得到充分使用,则这种测试方法称为白盒测试(White-boxTesting)方法。——白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试,一般用来分析程序的内部结构。

黑盒测试和白盒测试(续)白盒测试黑盒测试两种测试方法从完全不同的角度出发,反映了测试思路的两方面情况,适用于不同的测试阶段。黑盒测试和白盒测试(续)1、黑盒测试黑盒测试的基本观点是:任何程序都可以看作是从输入定义域映射到输出值域的函数过程,被测程序被认为是一个打不开的黑盒子,黑盒中的内容(实现过程)完全不知道,只明确要做到什么。黑盒测试主要根据规格说明书设计测试用例,并不涉及程序内部构造和内部特性,只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试的特点:(1)黑盒测试与软件的具体实现过程无关,在软件实现的过程发生变化时,测试用例仍然可以使用。(2)黑盒测试用例的设计可以和软件实现同时进行,这样能够压缩总的开发时间。黑盒测试和白盒测试(续)输入输出黑盒测试是在程序接口进行测试,它只是检查程序功能是否按照规格说明书的规定正常使用。也被称为用户测试。黑盒测试和白盒测试(续)黑盒测试主要是为了发现以下几类错误:是否有不正确或遗漏了的功能?在接口上,输入能否正确地接受?能否输出正确的结果?是否有数据结构错误或外部信息访问错误?性能上是否能够满足要求?是否有初始化或终止性错误?黑盒测试的难点:在哪个层次上进行测试?黑盒测试的具体技术方法:边界值分析法等价类划分法因果图法决策表法黑盒测试和白盒测试(续)2、白盒测试白盒测试将被测程序看作一个打开的盒子,测试者能够看到被测源程序,可以分析被测程序的内部结构,此时测试的焦点集中在根据其内部结构设计测试用例。白盒测试要求是对某些程序的结构特性做到一定程度的覆盖,或者说这种测试是“基于覆盖率的测试”。通常的程序结构覆盖有:语句覆盖判定覆盖条件覆盖判定/条件覆盖路径覆盖黑盒测试和白盒测试(续)白盒测试需要完全了解程序结构和处理过程,它按照程序内部逻辑测试程序,检验程序中每条通路是否按预定要求正确工作。也被称为程序员测试。应用程序黑盒测试和白盒测试(续)?X=2

y=2xY=4X=2Y=4未知等式与已知等式黑盒白盒3、黑盒测试法和白盒测试法的比较黑盒测试和白盒测试(续)黑盒测试:

——以用户的观点,从输入数据与输出数据的对应关系,即根据程序外部特性进行测试,而不考虑内部结构及工作情况。

——黑盒测试技术注重于软件的信息域(范围),通过划分程序的输入和输出域来确定测试用例。

——若外部特性本身存在问题或规格说明的规定有误,则应用黑盒测试方法是不能发现问题的。白盒测试:

——只根据程序的内部结构进行测试。

——测试用例的设计要保证测试时程序的所有语句至少执行一次,而且要检查所有的逻辑条件。

——如果程序的结构本身有问题,比如说程序逻辑有错误或者有遗漏,那也是无法发现的。黑盒测试和白盒测试(续)项目黑盒测试法白盒测试法规划方面功能的测试结构的测试优点方面能确保从用户的角度出发进行测试能对程序内部的特定部位进行覆盖测试缺点方面无法测试程序内部特定部位;当规格说明有误,则不能发现问题无法检查程序的外部特性;无法对未实现规格说明的程序内部欠缺部分进行测试应用范围边界分析法等价类划分法决策表测试语句覆盖,判定覆盖,条件覆盖,判定/条件覆盖,路径覆盖,循环覆盖,模块接口测试2.2.3软件测试过程单元测试单元测试单元测试集成测试集成测试确认测试系统测试*这三个测试可能交叉与前后互换被测模块被测模块被测模块设计信息单元软件需求其它元素用户信息其它元素*…*验收测试*交付用户…图2-2软件测试的过程流程软件测试过程(续)单元测试:针对每个单元的测试,

以确保每个模块能正常工作为目标。集成测试:对已测试过的模块进行组装,进行集成测试。目的在于检验与软件设计相关的程序结构问题。确认(有效性)测试:是检验所开发的软件能否满足所有功能和性能需求的最后手段。系统测试:检验软件产品能否与系统的其他部分(比如,硬件、数据库及操作人员)协调工作。验收(用户)测试:检验软件产品质量的最后一道工序。主要突出用户的作用,同时软件开发人员也应有一定程度的参与。一个实用软件测试过程一种简单实用的软件测试过程模型POCERM。测试过程中必需的基本测试活动及其产生的结果:拟定软件测试计划(Plans)编制软件测试大纲(Outlines)设计和生成测试用例(testCasegeneration)实施测试(Execution)生成软件测试报告(softwaretestingReports)软件问题报告SPR(SoftwareProblemReport)测试结果报告(testresultReports)一个实用软件测试过程(续)基本特性:(1)计划性:任务人员设备时间相关...(2)平行性:开发编码||测试再测试(3)完整性:计划+大纲+用例+SPRs+...(4)重用性:测试再测试回归测试升级多平台…(5)可重复性:SPRs用例大纲再现Bugs(6)周期性:testcycles,regression,update(7)可管理性:wellstructuredandorganizedQEgroup+wellplannedandpreparedtask测试阶段测试过程的三个主要的测试活动(计划、准备和实施)可被分成五个阶段:Theplanningandcontrolphase-计划和控制阶段Thepreparationphase-准备阶段Thespecificationphase-规范阶段Theexecutionphase-实施执行阶段Thecompletionphase-完成(收尾)阶段测试的五个阶段Plan&ControlCSEPP&CPreparationSpecificationExecutionCompletion计划与控制阶段它是整个测试过程中最重要的阶段,为实现可管理且高质量的测试过程提供基础。本阶段的主要工作内容:(1)拟定测试计划(2)论证那些使开发过程难于管理和控制的因素(3)明确软件产品的最重要部分(风险评估)准备阶段开始本阶段的前提条件:—完成测试计划的拟定。—需求规格说明书(第一版)的确定。本阶段的主要工作内容:—对需求规格说明书的仔细研究。—将要测试的产品分解成可独立测试的单元。—为每个测试单元确定采用的测试技术。—为测试的下一个阶段及其活动制定计划。规范阶段本阶段的主要工作内容:—编写测试大纲/测试用例,测试脚本—搭建测试环境(测试数据库,软件环境,硬件环境)测试用例描述的内容:—输入—执行过程—预期输出实施执行阶段根据测试大纲/测试用例/测试脚本进行测试(1)根据测试大纲/测试用例进行测试,找出预期的测试结果和实际测试结果之间的差异(2)填写软件问题报告(3)确定造成这些差异的原因:产品有缺陷?规格说明书有缺陷?测试环境和测试下属部件有缺陷?测试用例设计不合理?测试报告——与管理层进行沟通的方式已测试部分占产品多大的百分比?还有什么工作要做?找到了多少个问题或不足?测试的发展趋势如何?测试可以结束了吗?完成阶段本阶段的主要工作内容:—选择和保留测试大纲、测试用例、测试结果、测试工具。—提交最终报告。收尾工作的意义和重要性:—产品如果升级或功能变更,或维护,只要对保留下来的相关测试数只要作相应调整,就能够进行新的测试。2.3单元测试2.3.1单元测试的主要任务2.3.2单元测试的执行过程Return2.3.1单元测试的主要任务单元测试针对每个程序的模块,主要测试5个方面的问题:——模块接口、局部数据结构、边界条件、独立的路径和错误处理。模块模块接口局部数据结构路径测试出错处理边界条件单元测试的主要任务(续)模块接口这是对模块接口进行的测试,检查进出程序单元的数据流是否正确。模块接口测试必须在任何其它测试之前进行。模块接口测试至少需要如下的测试项目:(1)调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配;(2)所测模块调用子模块时,它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配;(3)是否修改了只做输入用的形式参数;(4)调用标准函数的参数在个数、属性、顺序上是否正确;(5)全局变量的定义在各模块中是否一致。单元测试的主要任务(续)局部数据结构在模块工作过程中,必须测试模块内部的数据能否保持完整性,包括内部数据的内容、形式及相互关系不发生错误。对于局部数据结构,应该在单元测试中注意发现以下几类错误:(1)不正确的或不一致的类型说明。(2)错误的初始化或默认值。(3)错误的变量名,如拼写错误或书写错误。(4)下溢、上溢或者地址错误。单元测试的主要任务(续)路径测试在单元测试中,最主要的测试是针对路径的测试。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。常见的错误有:误解的或不正确的算术优先级;混合模式的运算;错误的初始化;精确度不够精确;表达式的不正确符号表示。针对判定和条件覆盖,测试用例还要能够发现如下错误:不同数据类型的比较;不正确的逻辑操作或优先级;应当相等的地方由于精确度的错误而不能相等;不正确的判定或不正确的变量;不正确的或不存在的循环终止;当遇到分支循环时不能退出;不适当地修改循环变量。单元测试的主要任务(续)边界条件边界测试是单元测试的最后一步,必须采用边界值分析方法来设计测试用例,认真仔细地测试为限制数据处理而设置的边界处,看模块是否能够正常工作。一些可能与边界有关的数据类型如数值、字符、位置、数量、尺寸等,还要注意这些边界的首个、最后一个、最大值、最小值、最长、最短、最高、最低等特征。在边界条件测试中,应设计测试用例检查以下情况:(1)在n次循环的第0次、1次、n次是否有错误。(2)运算或判断中取最大值、最小值时是否有错误。(3)数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。单元测试的主要任务(续)出错处理测试出错处理的重点是模块在工作中发生了错误,其中的出错处理设施是否有效。检验程序中的出错处理可能面对的情况有:(1)对运行发生的错误描述难以理解。(2)所报告的错误与实际遇到的错误不一致。(3)出错后,在错误处理之前就引起系统的干预。(4)例外条件的处理不正确。(5)提供的错误信息不足,以至于无法找到错误的原因。2.3.2单元测试的执行过程何时进行单元测试?单元测试常常是和代码编写工作同时进行的,在完成了程序编写、复查和语法正确性验证后,就应进行单元测试用例设计。在单元测试时,如果模块不是独立的程序,需要设置一些辅助测试模块。辅助测试模块有两种:(1)驱动模块(Drive)用来模拟被测试模块的上一级模块,相当于被测模块的主程序。它接收数据,将相关数据传送给被测模块,启动被测模块,并打印出相应的结果。(2)桩模块(Stub)用来模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。驱动模块和桩模块都是额外的开销,虽然在单元测试中必须编写,但并不需要作为最终的产品提供给用户。单元测试的执行过程(续)被测模块、驱动模块和桩模块共同构成了一个如下图所示的单元测试的测试环境:测试用例被测模块驱动模块测试结果桩模块1桩模块2桩模块3桩模块n桩模块…2.4集成测试2.4.1非增量式测试2.4.2增量式测试2.4.3不同集成测试方法的比较2.4.4回归测试Return2.4.1非增量式测试非增量式测试是采用一步到位的方法来构造测试:

——对所有模块进行个别的单元测试后,按照程序结构图将各模块连接起来,把连接后的程序当作一个整体进行测试。

实例采用非增量式测试方法进行集成测试非增量式测试的缺点:

——当一次集成的模块较多时,非增量式测试容易出现混乱,因为测试时可能发现了许多故障,为每一个故障定位和纠正非常困难,并且在修正一个故障的同时,可能又引入了新的故障,新旧故障混杂,很难判定出错的具体原因和位置。非增量式测试(续)AS3S4S5d2Cd4Ed5Fd1Bs1d3s2DABCDEFABCDEF(1)程序结构图(3)集成测试示意图(2)单元测试示意图2.4.2增量式测试增量式测试的集成是逐步实现的:——逐次将未曾集成测试的模块和已经集成测试的模块(或子系统)结合成程序包,再将这些模块集成为较大系统,在集成的过程中边连接边测试,以发现连接过程中产生的问题。按照不同的实施次序,增量式集成测试又可以分为三种不同的方法:(1)自顶向下增量式测试(2)自底向上增量式测试(3)混合增量式测试自顶向下增量式测试自顶向下增量式测试表示逐步集成和逐步测试是按照结构图自上而下进行的,即模块集成的顺序是首先集成主控模块(主程序),然后依照控制层次结构向下进行集成。从属于主控模块的按深度优先方式(纵向)或者广度优先方式(横向)集成到结构中去。深度优先方式的集成:——首先集成在结构中的一个主控路径下的所有模块,主控路径的选择是任意的。

广度优先方式的集成:——首先沿着水平方向,把每一层中所有直接隶属于上一层的模块集成起来,直到底层。自顶向下增量式测试(续)集成测试的整个过程由3个步骤完成:(1)主控模块作为测试驱动器。(2)根据集成的方式(深度或广度),下层的桩模块一次一次地被替换为真正的模块。(3)在每个模块被集成时,都必须进行单元测试。重复第2步,直到整个系统被测试完成。

实例按照广度优先方式进行集成测试实例按照深度优先方式进行集成测试自顶向下增量式测试(续)ABCDEFAS1S2S3ABCDS4S5ABCDEF(1)(2)(3)广度优先方式自顶向下增量式测试(续)ABCDEFAS1S2S3ABS2S3EABCS3E(1)(2)(3)深度优先方式(4)自底向上增量式测试自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的,即从程序模块结构的最底层模块开始集成和测试。由于是从最底层开始集成,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经集成并测试完成,所以不再需要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。实例采用自底向上增量式测试方法进行集成测试自底向上增量式测试(续)ABCDEFd2Cd1Ed3Fd4BEd5FDABCDEF混合增量式测试混合增量式测试是把自顶向下测试和自底向上测试这两种方式结合起来进行集成和测试。这样可以兼具两者的优点,而摒弃其缺点。常见的两种混合增量式测试方式:(1)衍变的自顶向下的增量式测试:基本思想是强化对输入/输出模块和引入新算法模块的测试,并自底向上集成为功能相对完整且相对独立的子系统,然后由主模块开始自顶向下进行增量式测试。(2)自底向上-自顶向下的增量式测试:首先对含读操作的子系统自底向上直至根节点模块进行集成和测试,然后对含写操作的子系统做自顶向下的集成与测试。2.4.3不同集成测试方法的比较1、非增量式测试与增量式测试的比较非增量式测试的方法是先分散测试,然后集中起来再一次完成集成测试。假如在模块的接口处存在错误,只会在最后的集成测试时一下子暴露出来。增量式测试是逐步集成和逐步测试的方法,把可能出现的差错分散暴露出来,便于找出问题和修改。而且一些模块在逐步集成的测试中,得到了较多次的考验,因此,可能会取得较好的测试效果。

结论:增量式测试要比非增量式测试具有一定的优越性。不同集成测试方法的比较(续)2、自顶向下与自底向上增量式测试的比较自顶向下增量式测试:——主要优点在于它可以自然的做到逐步求精,一开始就能让测试者看到系统的框架。——主要缺点是需要提供桩模块,并且在输入/输出模块接入系统以前,在桩模块中表示测试数据有一定困难。自底向上增量式测试:——优点在于,由于驱动模块模拟了所有调用参数,即使数据流并未构成有向的非环状图,生成测试数据也无困难。

——主要缺点在于,直到最后一个模块被加进去之后才能看到整个程序(系统)的框架。2.4.4回归测试什么是回归测试?——在集成测试策略的环境中,回归测试是对某些已经进行过的测试的某些子集再重新进行一遍,以保证上述改变不会传播无法预料的副作用或引发新的问题。——在更广的环境里,回归测试就是用来保证(由于测试或其他原因的)改动不会带来不可预料的行为或另外的错误。回归测试可以通过重新执行所有的测试用例的一个子集人工地进行,也可以使用自动化的捕获回放工具来进行。回归测试集包括三种不同类型的测试用例:(1)能够测试软件的所有功能的代表性测试用例(2)专门针对可能会被修改而影响软件功能的附加测试(3)针对修改过的软件成分的测试2.5确认测试1、确认测试的准则确认测试也称为合格性测试,是检验所开发的软件是否能按用户提出的要求进行。软件确认要通过一系列证明软件功能和要求一致的黑盒测试来完成。经过确认测试,应该为已开发的软件给出结论性评价:(1)经过检验的软件的功能、性能及其他要求均已满足需求规格说明书的规定,则可被认为是合格的软件。(2)经过检验发现与需求说明书有相当的偏离,得到一个各项缺陷清单。Return确认测试(续)2、配置审查的内容确认测试过程的重要环节就是配置审查工作。其目的在于确保已开发软件的所有文件资料均已编写齐全,并得到分类编目,足以支持运行以后的软件维护工作。配置审查的文件资料包括用户所需的以下资料:(1)用户手册(2)操作手册(3)设计资料——如:设计说明书、源程序以及测试资料(测试说明书、测试报告)等2.6系统测试为什么要进行系统测试?

——由于软件只是计算机系统中的一个组成部分,软件开发完成之后,最终还要和系统中的硬件系统、某些支持软件、数据信息等其他部分配套运行。因此,在投入运行前要完成系统测试,以保证各组成部分不仅能单独的得到检验,而且在系统各部分协调工作的环境下也能正常工作。尽管每一个检验有特定的目标,然而所有的检测工作都要验证系统中每个部分均已得到正确的集成,并能完成指定的功能。严格的说,系统测试超出了软件工程范围。通常这项工作并不由系统开发人员或系统开发组织来承担,而是由软件用户或软件开发机构委托独立测试机构来完成。

Return恢复测试恢复测试是通过各种手段,强制性地使软件出错,使其不能正常工作,进而检验系统的恢复能力。恢复测试包含的内容:

——如果系统恢复是自动的(由系统自身完成),则应该检验:重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。

——如果这一恢复需要人为干预,则应考虑平均修复时间是否在限定的、可以接受的范围之内。安全测试安全测试的目的在于验证安装在系统内的保护机制能否在实际中保护系统且不受非法入侵,不受各种非法干扰。在安全测试中,测试者扮演着试图攻击系统的个人角色:—尝试去通过外部的手段来获取系统的密码—使用可以瓦解任何防守的客户软件来攻击系统—把系统“瘫痪”,使得其他用户无法访问—有目的地引发系统错误,期望在恢复过程中侵入系统—通过浏览非保密的数据,从中找到进入系统的钥匙系统的安全测试要设置一些测试用例试图突破系统的安全保密措施,检验系统是否有安全保密的漏洞。强度测试从本质上来说,强度测试(也称压力测试-StreeTesting)的目的是要检测非正常的情形,测试是想要破坏程序。强度测试需要在反常规数据量、频率或资源的方式下运行系统,以检验系统能力的最高实际限度。举例:—如果正常的中断频率为每秒5次,强度测试设计为每秒50次中断。—把输入数据的量提高一个数量级来测试输入功能会如何响应。—若某系统正常运行可支持200个终端并行工作,强度测试则检验1000个终端并行工作的情况。—运行大量的消耗内存或其他系统资源的测试实例。性能测试性能测试用来测试软件在系统集成中的运行性能,特别是针对实时系统和嵌入式系统,仅提供符合功能需求但不符合性能需求的软件是不能被接受的。性能测试可以在测试过程的任意阶段进行,但只有当整个系统的所有成分都集成在一起后,才能检查一个系统的真正性能。性能测试常常和强度(压力)测试结合起来进行,而且常常需要硬件和软件测试设备,这就是说,常常有必要在一种苛刻的环境中衡量资源的使用(比如,处理器周期)。正确性测试正确性测试检查软件的功能是否符合规格说明。正确性测试的方法:

——枚举法,即构造一些合理输入,检查是否得到期望的输出。测试时应尽量设法减少枚举的次数,关键在于寻找等价区间,因为在等价区间中,只需用任意值测试一次即可。——边界值测试,即采用定义域或者等价区间的边界值进行测试。因为程序设计容易疏忽边界情况,程序也容易在边界值处出错。

可靠性测试可靠性测试是从验证的角度出发,检验系统的可靠性是否达到预期的目标,同时给出当前系统可能的可靠性增长情况。对可靠性性测试来说,最关键的测试数据包括失效间隔时间,失效修复时间,失效数量,失效级别等。根据获得的测试数据,应用可靠性模型,可以得到系统的失效率及可靠性增长趋势。可靠性指标有时很难测试,通常采用平均无故障时间或系统投入运行后出现的故障不能大于多少数量这些指标来对可靠性进行评估。兼容性测试软件兼容性测试是检测各软件之间能否正确地交互和共享信息,其目标是保证软件按照用户期望的方式进行交互,使用其它软件检查软件操作的过程。兼容性的测试通常需要解决以下问题:(1)新开发的软件需要与哪种操作系统、Web浏览器和应用软件保持兼容,如果要测试的软件是一个平台,那么要求应用程序能在其上运行。(2)应该遵守哪种定义软件之间交互的标准或者规范。(3)软件使用何种数据与其它平台、与新的软件进行交互和共享信息。兼容性测试(续)软件兼容的实例:从Web页面剪切文字,然后在文字处理程序中打开的文档中粘贴。从电子表格程序保存账目数据,然后在另一个完全不同的电子表格程序中读入这些数据。使图形处理软件在同一操作系统下的不同版本正常工作。使文字处理程序从联系人管理程序中读取姓名和地址,打印个性化的邀请函和信封。升级到新的数据库程序,读入现存所有数据库,并能够像老版本一样对其中的数据进行处理。兼容性测试(续)兼容性通常有4种——向前兼容与向后兼容、不同版本间的兼容、标准和规范、数据共享兼容(1)向前兼容和向后兼容向前兼容是指可以使用软件的未来版本,向后兼容是指可以使用软件的以前版本。并非所有的软件都要求向前兼容和向后兼容,这是软件设计者需要决定的产品特性。使用文本文件可以对向前兼容和向后兼容作一个简单的演示:在Windows98上用Notepad创建的文本文件,它可以向后兼容MS-DOS1.0后的所有版本,它还可以向前兼容Windows2000甚至以后的版本。兼容性测试(续)在Windows98上运行的NotepadMYDATE.TXT在MS-DOS1.0上运行的Edit.exe在Windows3.1上运行的Notepad在Windows95上运行的Notepad向后兼容在Windows2000上运行的WordPad在未来操作系统上运行的未知软件向前兼容兼容性测试(续)

(2)不同版本间的兼容不同版本间的兼容是指要实现测试平台和应用软件多个版本之间能够正常工作。举例:现在要测试一个流行的操作系统的新版本,当前操作系统上可能有数几十上百万现有程序,则新操作系统的目标是与它们百分之百兼容。因为不可能在一个操作系统上测试所有的软件程序,因此需要决定哪些是最重要的、必须进行的。对于测试新应用软件也一样,需要决定在哪个平台版本上测试,以及和什么应用程序一起测试。兼容性测试(续)

(3)标准和规范适用于软件平台的标准和规范有两个级别——高级标准和低级标准。高级标准是产品应当普遍遵守的,例如软件能在何种操作系统上运行?是互联网上的程序吗?它运行于何种浏览器?每一项问题都关系到平台,假若应用程序声明与某个平台兼容,就必须最受关于该平台的标准和规范。低级标准是对产品开发细节的描述,从某种意义上说,低级标准比高级标准更加重要。兼容性测试(续)

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论