软件测试及常用的策略和方法.docx

软件测试及常用的策略和方法.docx

《软件测试及常用的策略和方法.docx》由会员分享，可在线阅读，更多相关《软件测试及常用的策略和方法.docx（23页珍藏版）》请在冰豆网上搜索。

软件测试及常用的策略和方法

软件测试分类

一.黑盒测试与白盒测试

1.黑盒测试:

black-boxtesting:

只关心软件的输入数据和输出结果。

包括功能测试与性能测试。

2.白盒测试:

white-boxtesting:

研究源代码与程序结构

二.静态测试和动态测试

1.静态测试:

不实际运行被测软件,只静态地检查程序代码,界面或文

档中可能存在的错误的过程。

包括:

代码测试（测试标准和规范,界面测试（实际界面与需求中的说明是否相符,文档测试（用户手册与需求说明是否真正符合用户的实际要求

2.动态测试:

实际运行被测程序,输入相应的测试数据,检查实际输出

结果和预期结果是否相符过程

三.单元测试,集成测试,系统测试和验收测试

1.单元测试:

对软件中的最小可测试单元进行检查和验证。

A.单元测试需要在项目前期进行,在程序员编码之后,代码已经通过编

译后进行;

B.由白盒测试员或者开发人员来测试,开发人员需要交叉测试,避免测

试自己的代码

C.测试的依据是:

源程序本身,包括代码和注释;还项目的《详细设计》

文档

D.通过的标准:

程序通过所有单元测试的用例。

语句的覆盖率达到百分

百;分支的覆盖率达到85%

E.需要检查代码是否符合规范,动态运行代码,检查其实际运行结果。

F.桩模块和驱动模块

桩模块:

STUB指模拟被测模块所调用的模块

驱动模块:

DRIVER指模拟被测模块的上级模块,用来接收测试数据,启动被测模块并输出结果

2.集成测试

A.integrationtesting:

将通过测试的单元模块组装成系统或者子系统,再进行测试,重点测试不同模块的接口部分

B.单元与集成同步进行。

测试参数传递。

C.由开发人员或者白盒测试员测试

D.依据是单元测试的模块以及《概要设计》文档

3.系统测试与验收测试

A.系统测试:

systemtesting将整个软件系统看做一个整体进行测试,包括对功能,性能以及软件所运行的软硬件环境进行测试

系统测试由黑盒测试员来完成,前期主要测试系统的功能是否满足需求,后期主要测试系统运行的性能是否满足需求,以及在不同的软硬件环境中的兼容性;主要依据是《系统需求规格说明》文档

B.验收测试

α测试:

由用户,测试人员,开发人员共同参与的内部测试

β测试:

内测后的公测,完全交给最终用户的测试

4.功能测试与性能测试

A.功能测试:

functiontesting检查实际软件的功能是否符合用户的需求

逻辑功能测试（logicfunctiontesting:

计算器

界面测试（uitesting:

窗口,下拉式菜单和鼠标操作,数据项

易用性测试（usabilitytesting:

合理性与方便性进行测试

安装测试（installationtesting:

安装与缷载

兼容性测试（compatibilitytesting:

包括硬件兼容性测试与软件兼容性测试。

5.性能测试（performancetesting

A.软件性能主要有时间性能与空间性能两种。

一般需要用到自动化的测试工具。

B.软件测试分为:

一般性能测试,稳定性测试（reliabilitytesting,

负载测试（loadtesting和压力测试（stresstesting

6.回归测试,冒烟测试,随机测试

A.regressiontesting:

对软件的新的版本测试时,重复执行上一个版本

测试时的用例

B.smocktesting:

在对一个新版本进行系统大规模的测试之前,先验证

一下软件的基本功能是否实现,是否具备可测性

C.randomtesting:

在测试中所有的输入数据都是随机生成的,目的是模

拟用户的真实操作,并发现一些边缘性的错误。

也叫猴子测试。

功能测试常用的策略和方法

黑盒测试（Black-boxTesting,又称为功能测试或数据驱动测试是把测试对象看作一个黑盒子。

利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。

采用黑盒技术设计测试用例的方法有:

等价类划分、边界值分析、错误推测、因果图和综合策略。

黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。

黑盒测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误。

黑盒测试试图发现以下类型的错误:

1功能错误或遗漏;

2界面错误;

3数据结构或外部数据库访问错误;

4性能错误;

5初始化和终止错误。

一、黑盒测试的测试用例设计方法

·等价类划分方法

·边界值分析方法

·错误推测方法

·因果图方法

·判定表驱动分析方法

·正交实验设计方法

·功能图分析方法

等价类划分:

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集,然后从每一个子集中选取少数具有代表性的数据作为测试用例。

该方法是一种重要的,常用的黑盒测试用例设计方法。

1划分等价类:

等价类是指某个输入域的子集合。

在该子集合中,各个

输入数据对于揭露程序中的错误都是等效的。

并合理地假定:

测试某等价类的代表值就等于对这一类其它值的测试。

因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据。

取得较好的测试结果。

等价类划分可有两种不同的情况:

有效等价类和无效等价类。

有效等价类:

是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合。

利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类:

与有效等价类的定义恰巧相反。

设计测试用例时,要同时考虑这两种等价类。

因为,软件不仅要能接收合理的数据,也要能经受意外的考验。

这样的测试才能确保软件具有更高的可靠性。

2划分等价类的方法:

下面给出六条确定等价类的原则。

①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效

等价类和两个无效等价类。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类。

③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效

等价类。

④在规定了输入数据的一组值（假定n个,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则和若干个无效等价类（从不同角度违反规则。

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

3设计测试用例:

在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

输入条件有效等价类无效等价类

然后从划分出的等价类中按以下三个原则设计测试用例:

①为每一个等价类规定一个唯一的编号。

②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步。

直到所有的有效等价类都被覆盖为止。

③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步。

直到所有的无效等价类都被覆盖为止。

边界值分析法

边界值分析方法是对等价类划分方法的补充。

（1边界值分析方法的考虑:

长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。

因此针对各种边界情况设计测试用例,可以查出更多的错误。

使用边界值分析方法设计测试用例,首先应确定边界情况。

通常输入和输出等价类的边界,就是应着重测试的边界情况。

应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

（2基于边界值分析方法选择测试用例的原则:

1如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

2如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

3根据规格说明的每个输出条件,使用前面的原则1。

4根据规格说明的每个输出条件,应用前面的原则2。

5如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

6如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

7分析规格说明,找出其它可能的边界条件。

错误推测法

错误推测法:

基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。

错误推测方法的基本思想:

列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

例如,在单元测试时曾列出的许多在模块中常见的错误。

以前产品测试中曾经发现的错误等,这些就是经验的总结。

还有,输入数据和输出数据为0的情况。

输入表格为空格或输入表格只有一行。

这些都是容易发生错误的情况。

可选择这些情况下的例子作为测试用例。

因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等。

考虑输入条件之间的相互组合,可能会产生一些新的情况。

但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。

因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。

这就需要利用因果图（逻辑模型。

因果图方法最终生成的就是判定表。

它适合于检查程序输入条件的各种组合情况。

利用因果图生成测试用例的基本步骤:

（1分析软件规格说明描述中,那些是原因（即输入条件或输入条件的等价类,那些是结果（即输出条件,并给每个原因和结果赋予一个标识符。

（2分析软件规格说明描述中的语义。

找出原因与结果之间,原因与原因之间对应的关系。

根据这些关系,画出因果图。

（3由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不不可能出现。

为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。

（4把因果图转换为判定表。

（5把判定表的每一列拿出来作为依据,设计测试用例。

从因果图生成的测试用例（局部,组合关系下的包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加。

前面因果图方法中已经用到了判定表。

判定表（DECisionTable是分析和表达多逻辑条件下执行不同操作的情况下的工具。

在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了。

由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

判定表驱动分析方法

判定表通常由四个部分组成。

条件桩（ConDItionSTub:

列出了问题得所有条件。

通常认为列出得条件的次序无关紧要。

动作桩（ActionStub:

列出了问题规定可能采取的操作。

这些操作的排列顺序没有约束。

条件项（ConditionEntry:

列出针对它左列条件的取值。

在所有可能情况下的真假值。

动作项（ActionEntry:

列出在条件项的各种取值情况下应该采取的动作。

规则:

任何一个条件组合的特定取值及其相应要执行的操作。

在判定表中贯穿条件项和动作项的一列就是一条规则。

显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

判定表的建立步骤:

（根据软件规格说明

①确定规则的个数。

假如有n个条件。

每个条件有两个取值（0,1,故有种规则。

②列出所有的条件桩和动作桩。

③填入条件项。

④填入动作项。

等到初始判定表。

⑤简化、合并相似规则（相同动作。

B.Beizer指出了适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出,或很容易转换成判定表。

②条件的排列顺序不会也不影响执行哪些操作。

③规则的排列顺序不会也不影响