软件测试技术的研究现状肖思博.docx

软件测试技术的研究现状肖思博.docx

《软件测试技术的研究现状肖思博.docx》由会员分享，可在线阅读，更多相关《软件测试技术的研究现状肖思博.docx（14页珍藏版）》请在冰豆网上搜索。

软件测试技术的研究现状肖思博

中南林业科技大学

计算机与信息工程学院

《软件工程》论文

题目

学生姓名

指导教师

学院

专业班级

完成时间

软件测试技术的研究现状

肖思博（20072101）

辛动军

计算机与信息工程学院

2007级通信工程*班

2010年11月5日

软件测试技术的研究现状

摘要

人们总是喜欢定过高目标，而恰当的定目标是非常重要的。

如果我们的目标是证明程序没错，那我们肯定会选择出错率极低的数据来测试；相反，如果我们是要证明程序有错，那我们就会去找出错率高的数据来测试。

后者会比前者搜集更多的数据来测试。

目录

第一章引言

第二章软件测试的概述

2.1软件测试的定义

2.2软件测试的发展史

2.3软件测试的国内外现状

2.4软件测试的发展趋势

第三章软件测试的流程

3.1流程概述

3.2测试流程

第四章软件测试的分类和方法

4.1软件测试的分类

4.2黑盒测试方法列举

第一章引言

开始论文之前，我们先来探讨下测试的定义。

程序测试很糟糕的一个主要原因是程序员最初就下错了定义。

他们也许说：

“测试就是证明错误不存在。

”或者“测试目的就是标明程序功能实现正确。

”或者“测试就是证明程序可以做它应该做的事”。

这些定义实在是与实际的南辕北辙。

测试应该是试图证明程序中存在错误，测试出越多错误越好。

正确理解测试的定义可以帮助你提高测试的工作效率。

人们总是喜欢定过高目标，而恰当的定目标是非常重要的。

如果我们的目标是证明程序没错，那我们肯定会选择出错率极低的数据来测试；相反，如果我们是要证明程序有错，那我们就会去找出错率高的数据来测试。

后者会比前者搜集更多的数据来测试。

测试的定义有很多暗示性的东西。

比如说，它暗示了测试是一个破环性的程序，甚至是个残酷的程序，这正解释了为什么许多人觉得测试很难。

我们多数人都希望事情圆满，而不是撕裂它，让它支离破碎。

这也可以区分出，哪些人适合做测试，哪些人不适合。

测试定义的另一种补充解释是分析“成功的”和“不成功的”的用法——实际上，项目经理们经常把没发现错误的测试程序称作“成功的”，那些发现错误的测试程序反而被称为“不成功的”。

这当然又是完全搞反了。

尽管如此，人们的思维仍然难以令找到错误的测试程序作为“成功的”。

想象一个病人去看医生，检查的结果的完全健康，事实上病人却病着，那这个医生当然会被责“无能”。

我们应该把程序当作一个病人，把测试人员当作医生，那样，找出的问题越多，就越“成功”。

第三个关于测试定义的问题是诸如“测试就是证明程序可以做它应该做的事”类的想法。

难道“程序可以做它应该做的事”就没错误了么？

那如果程序不但做了应该做的事情，还做了不该做的事情呢？

作为总结，测试是一个破坏性的程序，以找错误为目的。

当然，你最终还是希望通过测试来建立信心，证明程序做它该做的，绝不做它不该做的，但是这个目标最好建立在勤勤恳恳找错误的基础上面。

假如程序员十分肯定自己的代码是“完美无缺的”，那你应该尽量找出问题，证明它并非完美，而不是盲目的听从。

可见测试就是生活的一种写照，生活中的测试就是不断段纠错，完善人生的过程。

第二章软件测试的概述

2.1软件测试的定义

上面我们讨论了软件测试的定义问题，现在给出软件测试的准确定义。

软件测试是为了发现错误而执行程序甚至不用执行程序的过程。

它不仅是软件开发阶段的有机组成部分，而且在整个软件工程（即软件定义、设计和开发过程）中占据相当大的比重。

软件测试是软件质量保证的关键环节，直接影响着软件的质量评估。

软件测试不仅要讲究策略，更要讲究时效性。

验收测试作为软件测试过程的最后一个环节，对软件质量、软件的可交付性和软件项目的实施周期起到"一锤定音"的作用。

可见软件测试的目的是

（1）为了寻找错误，并尽可能地为修正错误提供更多的信息

（2）为了证明软件有错误，而不证明软件没有错误

（3）通过软件测试来检查系统是否满足需求，这也是测试的期望目标。

那么为了能够成功的实施测试，发现软件中的错误，软件测试应该遵循一些原则：

1.）测试应该基于用户需求

2.）测试设计是关键。

测试时间和资源是有限的，要避免冗余的测试和考虑到尽可能全面的情况。

3.）应该尽早和不断的测试。

4.）序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

5.）对测试错误结果要有一个确认的过程

6.）要有合理的测试计划，不要希望在极短的时间内完成一个高水平的测试。

7.）要注意回归测试的关联性，尽可能避免引入新的错误。

8.）妥善保存测试过程文档，测试的重现性往往要靠测试文档。

2.2软件测试的发展史

软件测试是伴随着软件的产生而产生的。

早期的软件测试较为狭隘，测试相当于“调试”，由开发人员自己完成这部分工作。

通常是形成代码、产品基本完成时才进行测试，对测试的投入非常的少。

直到1957年，软件测试才成为一种发现软件缺陷的活动。

由于缺乏软件工程的概念，测试仍旧是开发之后的事情。

1972年在北卡罗来纳大学举行了首次软件测试正式会议，1975年JohnGoodEnough和SusanGerhart在IEEE上发表了“TowardaTheoryofTestDataSelection”（测试数据选择原理）的文章，软件测试才被确定为一种研究方向。

1979年，GlenfordMyers的《TheArtofSoftwareTesting》（软件测试艺术）是测试领域的第一本重要专著。

在这本书中，Myers以及其同事们将软件测试定义为“测试是为发现错误而执行的一个程序或者系统的过程”。

到了20世纪80年代，软件测试不再单纯是发现错误的过程，而且包含了软件质量评价的内容。

包含IEEE（InstituteofElectricalandElectronicEngineers）标准、美国ANSI（AmericanNationalStandardInstitute）标准以及ISO（InternationalStandardOrganization）国际标准在内的各类标准相继被制定。

1983年，BillHetzel在《CompleteGuideofSoftwareTesting》（《软件测试完全指南》）中指出“测试是以评价一个程序或系统属性为目标的任何一种活动，测试是对软件质量的度量”。

20世纪90年代，测试工具开始盛行。

2002年，Rick何和Stefan在《SystematicSoftwareTesting》（《系统的软件测试》）一书中将测试定义为“测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程”。

最近20年来，软件测试技术随着计算机和软件技术的飞速发展取得了很大突破，包括V模型、W模型在内的测试模型被相继总结出来。

同时，TMM（TestingMaturityModel）概念的出现标志着测试过程的改进。

在单元测试、自动化测试、负载压力测试以及测试管理方面涌现了大量优秀的软件测试工具。

然而软件测试技术仍旧是落后于软件开发技术的发展速度，这使得软件测试面临着很大的挑战，主要体现在以下几方面：

1.软件测试在国防现代化、社会信息化和国民经济化领域中的作用越来越重要，由此产生的测试任务越来越繁重。

2.软件规模越来越大，功能越来越复杂，如何进行充分有效的测试成为难题。

3.面向对象的开发技术越来越普及，而面向对象的测试技术却刚刚起步。

4.对于分布式系统整体性能还不能进行很好的测试。

5.实时系统来说，缺乏有效的测试手段。

6.随着安全问题的日益突出，信息系统的安全性如何进行安全有效的测试与评估，成为世界性的难题。

2.3软件测试的国内外现状

软件测试在软件较发达的国家（比如美国），已经发展成为一个独立的产业，主要体现在以下几个方面：

1.软件测试在软件公司占有重要地位。

在微软，一个项目组中测试工程师要远比编码工程师多，同样花在测试的时间也比花在编码的时间多。

2.软件测试理论研究蓬勃发展。

每年举办各种各样的测试技术年会，发表了大量的软件测试研究论文，引领软件测试理论研究的国际潮流。

3.软件测试市场繁荣。

美国有一些专业公司开发软件测试标准与测试工具，MICompuware、MaCabe、Rational等都是著名的软件测试工具提供商，它们出品的测试工具已经占领了国际市场。

我国的测试技术起步于“六五”，随着软件工程的研究而逐步发展起来。

1990年国家级的中国软件评测中心成立，测试服务逐步开展起来。

由于起步晚，因此无论在软件测试理论研究还是测试实践上，都和发达国家有较大的差距。

主要体现在对软件产品化测试的技术研究还较为贫乏，从业人员少，测试服务没有形成足够的规模等方面。

但是，随着我国软件产业的蓬勃发展及对软件质量的重视，软件测试也越来越被人们所看重，软件测试正逐步成为一个新兴的产业。

我国正迈入测试时代，主要体现在以下几个方面：

1.我国著名软件公司都已经或着手建立独立的专职软件测试队伍。

当然人员规模及比例无法和国外大公司相比，但毕竟在公司内部贯彻了独立的测试的意识。

2.国家人事部和信产部2003关于职业资格认证第一次在我国有了“软件评测师”的称号，这是国家对软件测试职业的高度重视与认可。

3.在信产部关于计算机系统集成资质以及信息工程系统工程监理资质的认证中，软件测试能力已经被定为评价公司技术能力的一项重要指标。

4.2001年，信产部发布的部长5号令，实行了软件产品登记认证制度，规定凡是在我国境内销售的产品必须到信产部备案登记，且要经过登记测试。

5.自2001年起，国家质检总局和信产部都通过测试对软件产品进行质量监督抽查。

6.国家各部委、各行业正在通过测试规范行业的健康发展，通过测试把不符合行业标准要求的软件拒之门外，对行业信息化的健康发展起了促进作用。

7.用户对软件质量要求越来越高，信息系统验收不再走过场，而要通过第三方测试机构的严格测试来判定。

8.“以测代评”正在成为我国科技心爱你灌木则有支持的一项重要举措，如国家“863”计划对数据库管理系统、操作系统、办公软件、ERP等项目的经费支持，都是通过第三方测试机构科学客观的测试结果来决定的。

9.软件测试正成为部分软件学院的一门独立课程，对我国软件测试人才的培养起到作用。

10.第三方测试机构得到了蓬勃发展。

近两年全国各地新成立的软件测试机构有十多家，测试服务体系已经基本确立。

由上可见，我国的软件测试行业正处在一个快速成长的阶段。

随着时间推移，我们与发达国家的差距必然会逐步缩小。

2.4软件测试的发展趋势

分析现今国内外的测试发展，可以看出有以下趋势：

测试工作将近一步前移，不仅仅是单元测试、集成测试、系统测试和验收测试，对需求的精确性和完整性的测试技术、对系统设计的测试技术将成为新的研究热点。

软件架构师、开发工程师、QA人员和测试工程师将进行更好的融合，他们之间是伙伴而非对立的关系，因为他们的工作相互促进相互借鉴。

同时测试工程师也会尽早的介入整个工程，在软件定义阶段就要开发相应的测试方法，是的每一个需求定义都是可以测试的。

测试职业将得到充分的尊重。

开发与测试人员既是矛盾体也是统一体。

以前“没能力做开发就去测试”的观点已经被现在“只有高水平的开发者才能胜任测试工作”的观点所替代。

设置独立的软件测试部门将成为越来越多的软件公司的共识。

测试部门将和开发、QA一样作为一个重要的独立部门存在。

测试外包服务将快速增长。

软件测试外包将会和软件开发外包一样，成为全球化的一种趋势，可以利用职业测试专家队伍与机构为自己的产品进行测试，节省测试费用。

第三章软件测试的流程

3.1流程概述

一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：

需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.

在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

说明：

1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。

在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。

2．以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。

这就和我们国家提出建设有中国特色的社会主义国家一样，之所以有中国特色，那是因为国情不一样。

所以在实际测试过程中也要做到具体问题具体分析，具体解决。

3.2测试流程

需求分析

 需求分析（RequirmentAnalyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。

可能有些人认为测试需求分析无关紧要，这种想法是很不对的。

需求分析不但重要，而且至关重要！

 一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

 其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。

比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。

那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！

 既然谈了需求分析，那么我们根据什么来分析呢？

总不能凭空设想吧。

 总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

测试计划

测试计划（TestPlan）一般由测试负责人来编写。

测试计划的依据主要是项目开发计划和测试需求分析结果而制定。

测试计划一般包括以下一些方面：

 1． 测试背景

a. 软件项目介绍；

b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2． 测试依据

a. 软件需求文档；

b. 软件规格书；

c. 软件设计文档；

d. 其他，如参考产品等。

3． 测试资源

a. 测试设备需求；

b. 测试人员需求；

c. 测试环境需求；

d. 其他。

4． 测试策略

a. 采取测试方法；

b. 搭建哪些测试环境；

c. 采取哪些测试工具以测试管理工具；

d. 对测试人员进行培训等。

5． 测试日程

a. 测试需求分析；

b. 测试用例编写；

c.测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

6．其他。

测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。

如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。

所以，这些就要求测试负责人能够从宏观上来调控了。

在变化面前能够做到应对自如、处乱不惊那是最好不过了。

测试设计

测试设计主要包括测试用例编写和测试场景设计两方面。

测试用例（checklist），是关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。

从表现形式上而言，测试用例可以是纯文本的说明文档，也可以是用脚本语言或高级语言编写的一段代码。

 测试用例文档由简介和测试用例两部分组成。

简介部分编制测试目的、测试范围、定义术语以及测试背景等。

测试用例部分逐一列示各测试用例，测试用例应当包括测试标识、测试用例名称、目标、测试条件、测试设置、输入数据要求、步骤、以及预期的结果等

一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。

测试场景设计主要也就是测试环境问题了。

测试环境搭建

不同软件产品对测试环境有着不同的要求。

如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。

而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。

当然测试中对于如手机网络等环境都有所要求。

测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。

为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。

有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。

不管如何，我们的目标是测试软件问题，保证软件质量。

测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。

测试执行

测试执行过程又可以分为以下阶段：

单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。

从测试的角度而言，测试执行包括一个量和度的问题。

也就是测试范围和测试程度的问题。

比如一个版本需要测试哪些方面？

每个方面要测试到什么程度？

从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。

当然还要考虑以下问题：

1． 当测试人员测试的执行不到位、敷衍了事时该如何解决？

2． 测试效率问题，怎样提高测试效率？

3． 根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？

4． 当测试过程中遇到一些偶然性随机问题该怎样处理？

5． 当版本中出现很多新问题时该怎样对待？

测试停止标准？

6． ……

总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！

本文不做过多阐述。

测试记录

缺陷记录总的说来包括两方面：

由谁提交和缺陷描述。

一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。

在缺陷的描述上，至少要包括以下一些方面内容：

序号

标题

预置条件

操作步骤

预期结果

实际结果

注释

严重程度

概率

版本

测试者

测试日期

以上是描述一个bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，如附上图片、log文件等。

另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。

缺陷管理

缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有TestDirector、Bugfree等。

软件评估

这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。

软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。

测试总结和测试维护 

每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。

测试总结无严格格式、字数限制。

应该说，测试总结还是很总要的。

由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。

第四章软件测试的分类和方法

4.1软件测试的分类

前面我们讲到了软件测试的流程，了解了测试是一项复杂的系统工程，同样从不同的角度考虑可以有不同的划分方法，对测试进行分类是为了更好的明确测试的过程，了解测试究竟要完成哪些工作，尽量做到全面测试。

1、要执行被测软件的角度

按是否需要执行被测软件的角度，可分为静态测试和动态测试，前者不利用计算机运行待测程序而应用其他手段实现测试目的，如代码审核。

（我认为主要是让测试人员对编译器发现不了的潜在错误进行分析，如无效的死循环，多余的变量等），而动态测试则通过运行被测试软件来达到目的。

2、按阶段划分：

单元测试

单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。

它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。

因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。

因此应用系统有一个设计很好的体系结构就显得尤为重要。

一个软件单元的正确性是相对于该单元的规约而言的。

因此，单元测试以被测试单位的规约为基准。

单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

集成测试

集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。

它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。

集成测试的策略主要有自顶向下和自底向上两种。

系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。

因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。

软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

验收测试

验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。

它的测试数据通常是系统测试的测试数据的子集。

所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。

这是软件在投入使用之前的最后测试。

回归测试

回归测试是在软件维护阶段，对软件进行修改之后进行的测试。

其目的是检验对软件进行的修改是否正确。

这里，修改的正确性有两重含义：

一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

Alpha测试：

在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。

这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

Beta测试：

当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。

这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

3、按测试方法划分：

白盒测试

白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

“白盒”法是穷举路径测试。

在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

贯穿程序的独立路径数是天文数字。

但即使每条路径