目录
一、软件测试
1、测试的目的
2、测试的类型
(1)动态测试
(2)静态测试
3、测试的阶段
(1)单元测试
(2)集成测试
(3)确认测试
(4)系统测试
(5)性能测试
(6)第三方测试
(7)面向对象测试基础
二、软件维护
1、维护的类型
(1)改正性维护
(2)适应性维护
(3)完善性维护
(4)预防性维护
软件测试是软件质量保证的主要手段之一,也是在将软件交付给客户之前所必须完成的步骤。
目前,软件的正确性证明尚未得到根本的解决,软件测试仍是发现软件错误和缺陷的主要手段。软件测试的目的就是在软件投入生产性运行之前,尽可能多地发现软件产品(主要是指程序)中的错误和缺陷。
1983年,BillHetzel在"CompleteGuideofSoftwareTesting"一书中指出:"测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量".
GrenfordJ.Myers在"TheArtofSoftwareTesting"一书中指出:
这种观点可以提醒人们测试要以查找错误为中心,而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的,事实并非如此。
首先,测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征,可以帮助项目管理者发现当前所采用的软件过程的缺陷,以便改进。同时,这种分析也能帮助我们设计出有针对性的检测方法,改善测试的有效性。
其次,没有发现错误的测试也是有价值的,完整的测试是评定测试质量的一种方法。
因此,软件测试可以验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及其软件质量特性的要求,为软件质量的评价提供依据。我们要注意的是软件测试只是软件质量保证的手段之一,不能单凭测试来保证软件质量。
软件测试方法一般分为两大类,分别为动态测试和静态测试。
动态测试指通过运行程序发现错误,分为黑盒测试法、白盒测试法和灰盒测试法。
不管是哪一种测试,都不能做到穷尽测试,只能选取少量最有代表性的输入数据,以期用较少的代价暴露出较多的程序错误。这些被选取出来的数据就是测试用例(一个完整的测
试用例应该包括输入数据和期望的输出结果)。
黑盒法
_______________
把被测试对象看成一个黑盒子,测试人员完全不考虑程序的内部结构和处理过程,只在软件的接口处进行测试,依据需求规格说明书,检查程序是否满足功能要求。
常用的黑盒测试用例的设计方法有等价类划分、边值分析、错误猜测、因果图和功能图等。
等价类划分:将所有可能的输入数据,划分为等价的部分,然后从每个部分中选取少数有代表性的数据作为测试用例。等价类可以分为有效等价类(即合理、有意义的数据集合)、无效等价类(即不合理、无意义的数据集合)两种。而在选取测试用例时,应遵从"设计一个新的测试用例时,应尽可能多地覆盖尚未覆盖的有效等价类;但每次应仅覆盖一个尚未覆盖的无效等价类"的原则。
边界值分析:它是对等价类划分法的一个补充,即选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
错误推测法:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据它们选择测试用例。
因果图:等价类划分、边界值分析都只考虑了输入条件,未考虑输入条件间的联系,而因果图则用来描述多种条件组合的测试用例,其最终生成的结果是判定表。
它首先基于规格说明书分析原因(等价类)和结果(输出条件);然后找出原因与结果之间的关系,画出因果图;在因果图上加上约束或限制条件;将其转换为判定表;根据判
定表得出测试用例。
功能图:它是由状态迁移图和逻辑功能模型构建的,状态迁移图用于表示输入数据序列以及相应的输出数据;逻辑功能模型用于表示在状态中输入条件与输出条件之间的对应关系。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成的。
白盒法
_______________
把测试对象看作一个打开的盒子,测试人员须了解程序的内部结构和处理过程,以检查处理过程的细节为基础,对程序中尽可能多的逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致。
由于白盒测试是结构测试,所以被测对象基本上是源程序,以程序的内部逻辑为基础设计测试用例。
常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试、逻辑覆盖测试。
逻辑覆盖:以程序内部逻辑为基础的测试技术,如常用的语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖。
灰盒法
_______________
灰盒测试是一种介于白盒测试与黑盒测试之间的测试,它关注输出对于输入的正确性。同时也关注内部表现,但这种关注不像白盒测试那样详细且完整,而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
灰盒测试结合了白盒测试和黑盒测试的要素,考虑了用户端、特定的系统知识和操作环境,在系统组件的协同性环境中评价应用软件的设计。
静态测试指被测试程序不在机器上运行,而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
静态分析中进行人工测试的主要方法有桌前检查(DeskChecking)、代码审查和代码走查。经验表明:使用这种方法能够有效地发现30%~70%的逻辑设计和编码错误。
1)桌前检查由程序员自己检查自己编写的程序。
程序员在程序通过编译之后,进行单元测试设计之前,对源程序代码进行分析、检验,并补充相关的文档,目的是发现程序中的错误。这种桌前检查,由于程序员熟悉自己的程序和自身的程序设计风格,可以节省很多的检查时间,但应避免主观片面性。
2)代码审查
代码审查是由若干程序员和测试员组成一个会审小组,通过阅读、讨论和争议,对程序进行静态分析的过程。
代码审查分两步:
在会上,首先由程序员逐句讲解程序的逻辑。在此过程中,程序员或其他小组成员可以提出问题,展开讨论,审查错误是否存在。实践表明,程序员在讲解过程中能发现许多原来自己没有发现的错误,而讨论和争议则促进了问题的暴露。
在会前,应当给会审小组每个成员准备一份常见错误的清单,把以往所有可能发生的常见错误罗列出来,供与会者对照检查,以提高会审的实效。这个常见错误清单也叫做检查表,它把程序中可能发生的各种错误进行分类,对每一类列举出尽可能多的典型错误,然后把它们制成表格,供在会审时使用。这种检查表类似于单元测试中给出的检查表。
3)代码走查
代码走查与代码审查基本相同,其过程也分为两步。
即首先由测试组成员为被测程序准备一批有代表性的测试用例,提交给走查小组。走查小组开会,集体扮演计算机角色,让测试用例沿程序的逻辑运行一遍,随时记录程序的踪迹,供分析和讨论用。
值得说明的是使用静态测试的方法也可以实现白盒测试。例如:使用人工检查代码的方法来检查代码的逻辑问题,也属于白盒测试范畴。
为了保证系统的质量和可靠性,应力求在分析、设计等各个开发阶段结束前,对软件进行严格的技术评审。而软件测试是为了发现错误而执行程序的过程。
根据测试的目的、阶段的不同,可以把测试分为单元测试、集成测试、确认测试、系统测试等种类。
单元测试又称为模块测试,是针对软件设计的最小单位(程序模块)进行正确性检验的测试工作。
其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求,发现各模块内部可能存在的各种错误。
单元测试需要从程序的内部结构出发设计测试用例,多个模块可以平行地独立进行单元测试。
单元测试根据详细设计说明书,包括模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试,单元测试通常由开发人员自己负责。
而由于通常程序模块不是单独存在的,因此常常要借助驱动模块(相当于用于测试模拟的主程序)和桩模块(子模块)完成。单元测试的计划通常是在软件详细设计阶段完成的。
集成测试也称为组装测试、联合测试(对于子系统而言,则称为部件测试)。它主要是将已通过单元测试的模块集成在一起,主要测试模块之间的协作性。集成测试计划通常在软件概要设计阶段完成。
从组装策略而言,可以分为一次性组装和增量式组装,增量式组装又包括自顶向下、自底向上、混合式三种,其中混合式组装又称为三明治测试。
软件集成的过程是一个持续的过程,会形成多个临时版本。在不断的集成过程中,功能集成的稳定性是真正的挑战。在每个版本提交时,都需要进行冒烟测试,即对程序主要功能进行验证。冒烟测试也称为版本验证测试或提交测试。
确认测试也称为有效性测试,主要验证软件的功能、性能及其他特性是否与用户要求(需求)一致。确认测试计划通常在需求分析阶段完成。根据用户的参与程度,通常包括4种类型:
1)内部确认测试:主要由软件开发组织内部按软件需求说明书进行测试。
2)a测试(Alpha测试):由用户在开发环境下进行测试。
3)b测试(Beta测试):由用户在实际使用环境下进行测试。
4)验收测试:针对软件需求说明书,在交付前由用户为主进行的测试。
如果项目不只包含软件,还有硬件和网络等,则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起,在实际运行环境下,对计算机系统的一系列集成与确认测试。
一般地,系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。系统测试计划通常是在系统分析阶段(需求分析阶段)完成的。
不管是哪个阶段的测试,一旦测试出问题,就要进行修改。修改之后,为了检查这种修改是否会引起其他错误,还要对这个问题进行测试,这种测试称为回归测试或退化测试。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试,两者可以结合进行,统称为负载压力测试。
性能测试的目的
————————————————————————
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标,同时发现软件系统中存在的性能瓶颈,优化软件,最后起到优化系统的目的。
具体来说,包括以下几个方面:
性能测试的类型
————————————————————————
性能测试类型包括负载测试,强度测试,容量测试等。
负载压力测试
————————————————————————
系统的负载压力测试(负载测试)是指系统在某种指定软件、硬件及网络环境下承受的流量,例如:并发用户数、持续运行时间、数据量等,其中并发用户数是负载压力的重要体现。
系统在应用环境下主要承受并发访问用户数、无故障稳定运行时间、大数据量操作等负载压力。
负载压力测试的目的如下:
在网络应用系统中,负载压力测试应重点关注客户端、网络、服务器(包括应用服务器和数据库服务器)的性能。应获取的关键测试指标如下:
第三方测试指独立于软件开发方和用户方的测试,组织的测试也称为"独立测试"。
软件质量工程强调开展独立验证和确认(IV&V)活动,是由在技术、管理和财务上与开发组织具有规定程序独立的组织执行验证和确认过程。
软件第三方测试是相对独立的组织进行的软件测试,一般情况下是在模拟用户真实应用环境下,进行的软件确认测试。
第三方测试机构是一个中介的服务机构,它通过自己专业化的测试手段为客户提供有价值的服务。但是这些服务不同于公司内部的测试,因为第三方测试机构的测试除了发现软件问题之外,还有科学公正地评价软件的职能,这就要求该机构要保持公正、廉洁、客观、科学且独立的态度。
第三方测试机构存在的价值主要是由软件公司、软件用户,以及国家的公正诉求所决定的。
此外,经过国家认可的第三方测试机构,还为国家软件产品的质量监督抽查提供独立公正的测试支持。
在选择第三方测试机构时,主要查看其资质、信息系统工程测评经验、测试环境、测试工具及测试工程师队伍的素质等。
面向对象测试是与采用面向对象开发相对应的测试技术,它通常包括4个测试层次,从低到高排列分别是算法层、类层、模板层和系统层。
设计测试方案的传统技术,例如:逻辑覆盖、等价划分、边界值分析和错误推测等方法,仍然可以作为测试类中每个方法的主要技术。
面向对象测试的主要目标,也是用尽可能低的测试成本和尽可能少的测试方案,发现尽可能多的错误。但是,面向对象程序中特有的封装、继承和多态等机制,也给面向对象测试带来一些新特点,增加了测试和调试的难度。
在软件维护阶段,主要考查软件维护的分类、软件的可维护性等。
软件经过测试,交付给用户后,在使用和运行过程中可能在软件运行/维护阶段对软件产品进行的修改就是维护。
软件可维护性是指纠正软件系统出现的错误和缺陷,以及为满足新的要求进行修改、扩充和压缩的容易程度。目前广泛用来衡量程序可维护性的因素包括可理解性、可测试性、可修改性。
软件维护占整个软件生命周期的60%-80%,维护的类型主要有3种:
为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用,应当进行的诊断和改正错误的过程就叫做改正性维护。
在使用过程中,外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。为使软件适应这种变化,而去修改软
件的过程就叫做适应性维护。
在软件的使用过程中,用户往往会对软件提出新的功能与性能要求。为了满足这些要求,需要修改或再开发软件,以扩充软件功能、增强软件性能、改进加工效率、提高软件
的可维护性。这种情况下进行的维护活动叫做完善性维护。
在实际维护工作中,改正性维护大约占20%的工作量,适应性维护大约占25%的工作量,完善性维护大约占50%的工作量。
除了这3类维护之外,还有一类维护活动,叫做预防性维护。
这是为了提高软件的可维护性、可靠性等,为以后进一步改进软件打下良好基础。
通常,预防性维护定义为:"把今天的方法学用于昨天的系统以满足明天的需要"。也就是说,采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编制和测试。
在软件开发过程中,错误纠正成本在逐步放大。也就是说,错误发现得越早,纠正错误所花费的成本就会越低,反之则越高。例如:如果在软件设计阶段有个错误未被发现,而待编码阶段时才发现,这时,纠正这个设计错误比纠正源代码错误需要更大的成本。