-

2021年2月21日发(作者：蔡头)

目录

1 ................ ...............................................

错

误！未定义书签。

软件测试的目的和原则

................. .......................................... 2

2

软件测试用例设计

...... .................................................. ....... 3

2.1

测试用例的选择

............................................. ............... 3

2.2

测试用例输入数据的选择

........................................... 4

2.3

输出结果预测

.

................................. ............................. 4

2.4

保留全部测试用例

................... .................................... 4

2.5

软件测试的误区

< p>
............................................ ............... 4

3

测试方法分类

..................... .................................................. 5

3.1

黑盒测试和白盒测试

. .................................................. 5

3.1.1

黑盒测试

.

............................... ............................... 5

3.1.2

白盒测试

.

.................................................. ............ 6

3.2

静态测试和动态测试

.................. ................................. 7

3.2.1

静态测试

.

................................. ............................. 7

3.2.2

动态测试

.

.................................................. ............ 8

3.3

测试方法的发展

......... .................................................. 8

3.4

测试方法小结

.

............................... ............................... 9

4

软件验收测试的主要内容

................ ................................... 9

软件测试的目的和原则

基于不同的立 场，

存在着两个不同的测试目的。

从用户的角度出发，

普遍希

望通过软件测试暴露软件中隐藏的错误和缺陷，

< br>以考虑是否接受该产品。

而从软

件开发者的角度出发，< /p>

则希望测试成为表明软件产品中不存在错误的过程。

验证

该软件已正确的实现了用户的要求，

确立人们对软件质量的信心。

因此，

他们会

选择那些导致程序失效概率小的 测试用例。

回避那些易于暴露程序错误的测试用

例

$$

，同时，也不会着意去检测、排除程序中可能包含的副作用。显然，这样的

测试对完善和提高软件的质量毫无价值。

因为在程序中存在着许 多预料不到的问

题。

可能会被疏漏，

许 多隐藏的错误只有在特定的环境下才能暴露出来。

如果不

把着眼 点放在尽可能查找错误这样一个基础上。

这些隐藏的错误和缺陷就查不出

来，

会遗留到运行阶段中去。

如果站在用户的角度替他 们设想，

就应当把测试活

动的目标对准揭露程序中的错误。

在选取测试用例时，

考虑那些易于发现程序错

误的数据。

软件测试的原则一般如下：

1

）

应当把尽早地和不断地进行软件测试（

Check

early,check

often

）作为软件开

发者的座右铭。

由于原 始问题的复杂性，

软件的复杂性和抽象性，

软件开发各个阶段工 作的

多样性，

以及参加开发各种层次人员之间工作的配合关系等 因素，

使得开发的每

个环节都可能产生错误。

< br>所以不应该把软件测试仅仅看作是软件开发的一个独立

阶段，

而应当把它贯穿到软件开发的各个阶段中。

坚持在软件开发的各个阶段的

< p>
技术评审，

这样才能在开发过程中尽早发现和预防错误，

< br>把出现的错误克服在早

期，杜绝某些隐患，提高软件质量。

2

）

测 试用例应由测试输入数据和对应的预期输出结果这两部分组成。

测试以前应当根据测试的要求选择在测试过程中使用的测试用例，

测试用例

< p>
主要用来检查程序员编制的程序，

因此不但需要测试的输入数据，

而且需要针对

这些输入数据的预期输出结果

!

如果对测试输入数据没有给出预期的输出结果，

那么就缺少了检 验实测结果的基准，

就有可能把一个似是而非的错误结果当成正

确结果。

3

）

程序员应避免检查自己的程序。

测试 工作需要严格的作风，

客观的态度和冷静的情绪，

人们常由于各 种原因

具有一种不愿否定自己工作的心理，

认为揭露自己程序中 的问题总不是一件愉快

的事，

这一心理状态就成为测试自己程序 的障碍。

另外，

程序员对软件规格说明

理解错误而引入的错误更难发现，

如果由别人来测试程序员编写的程序可能会更

客观，

更有效，

并更容易取得成功。

< p>
要注意的是，

这点不能与程序的调试相混淆。

调试 由程序员自己来做可能更有效。

4

）

在设计 测试用例时

,

应当包括合理的输入条件和不合理的输入条件。< /p>

合理的输入条件是指能验证程序正确的输入条件，

而不合理的输入条件是指

异常的，临界的，可能是引起问题异变的输入条件。 在测试程序时，人们常常过

多地考虑合法的和期望的输入条件，

以检查它是否做了它应该做的事情，

而忽视

了不合法的和预想不 到的输入条件，事实上，软件在投入运行后

用户的使用往

往不遵循事先的约定，

使用了一些意外的输入，

如用户在键盘上按错了键或打入

了非法的命令，

如果开发的软 件遇到这种情况时不能作出适当的反应，

给出相应

的信息

那么就容易产生故障

轻则给出错误的结果，重则导致软件失效。因此，

系统软件处理非法命令的能力也必须在 测试时受到检验。

用不合理输入条件测试

程序时，往往比用合理 的输入条件进行测试能发现更多的错误。

5

）

充分注意测试中的群集现象。

测试时 不要以为找到了几个错误问题就已解决，不需要测试了，经验表明，

测试后程序中残存的 错误数目与该程序中已发现的错误数目或检错率成正比，

根

据这 个规律应当对错误群集的程序进行重点测试，

以提高测试投资的效益。

< br>在所

测试程序段中，若发现错误数目多，则残存数目也较多，这种错误群集性现象 ，

已为许多程序的测试实践所证实。

这种现象对测试很有用，< /p>

如果发现某一程序模

块似乎比其它程序模块有更多的错误倾向时，

则应当花费较多的时间和代价来测

试这个程序模块。

< p>

6

）

严格执行测试计划，排除测试的随意性。

测试计划应包括，所测试软件的功能，输入和输出，测试内容，各项测试的

进度安排 ，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方式

和过程，系统组装 方式，跟踪规程，调试规程，以及回归测试的规定等以及评价

标准。对测试计划，要明确 规定，不要随意解释。

7

）

应当对每一个测试结果做全面检查。

这是一条最明显的原则，

但常常被忽视，

有些错误的征兆在输出 实测结果时

已经明显地出现了，

但是如果不仔细地全面地检查测 试结果，

就会使这些错误被

遗漏掉。

所 以必须对预期的输出结果明确定义，

对实测的结果仔细分析检查，

抓

住征候，暴露错误。

8

）

妥善保 存测试计划，

测试用例，

出错统计和最终分析报告，

< p>
为维护提供方便。

测试可以采用自顶向下或自底 向上进行，

自顶向下测试先从全系统开始，

再

< br>测试每个子模块，

自底向上测试先从子模块测试开始，

逐 步测试各子模块的父模

块，最后进行全系统综合测试，模块测试的目的是验证是否和规格 相符。

进行模块测试必须考虑两件事，

测试用例的设计和测试模块的规模，

测试用

例可从规格或分析 模块代码产生，

相应的测试策略分为黑盒测试和白盒测试，

并< /p>

有两种方法和它们进行组合，

非增量与增量测试，

非增量测试分别对每个模块进

行测试，

然后组装成系统 ，

不再进一步测试。

而增量测试对每一个模块和被测试

过的模块进行组合测试，

增量测试能更早地检测出错误，

自顶向下或自底向上测

试它们均基于这样的假设，模块的调用关系为有向无环图 。

2

软件测试用例设计

2.1

测试用例的选择

软件测试是对软件功能、设计和实现的最终审定

,

其 方法可以分为两类

:

基于

规范的功能测 试方法和基于程序的结构测试方法。

功能测试以软件规范为依据选

取测试数据

,

其正确性依赖于规范的正确性。结构测试则根据 程序的内部结构设

计测试用例。其实无论采取哪一种测试策略

,

设计测试方案都是测试阶段最关键

的技术问题。理想情况下

,

测试所有可能的输入

,

< br>将提供程序行为最完全的信息

,

但这是不可能的。因此< /p>

,

如何来选择测试值是一个非常值得研究的方向。

一个测试用例

,

就是设定输 入数据

,

运行被测试函数

,

< p>
然后判断实际输出是否

符合预期。输入数据是测试用例的核心

,

输入数据的定义是

:

被测 试函数所读取的

外部数据及这些数据的初始值。

测试用例是对某 个特定的软件产品进行测试任务

的描述

,

体现测试方案、方法、技术和策略

,

内容包括测试目标、测试 环境、输入

数据、测试步骤、预期结果、测试脚本等

,

并形成文档。由此可见

,

测试用例是软

件测试的核心

,

也是软件测试质量稳定的根本保 障。因此

,

软件测试用例的选择一

般遵 循以下几条基本准则

:

1

）

测试用 例要具有代表性

,

即能够代表各种合理和不合理的、合法的和非 法的、

边界和越界的以及极限的输入数据、

操作和环境设置等< /p>

;

测试结果具有可判定

性

,

即测试执行结果的正确性是可判定的或可评估的。

2

）

测试结 果具有可再现性，即同样的测试用例，系统执行结果相同。

2.2

测试用例输入数据的选择

< /p>

用一定的规则选择有代表性的数据作为输入数据

,

主要有三种

:

正常、边界、

非 法输入

,

每种输入还可以分类

,

也就是平常说的等价类法

,

每类取一个数据作 为

输入数据

,

如果测试通过

< p>
,

可以肯定同类的其他输入也是可以通过的。

2.3

输出结果预测

整的测试用例不但需要测试的输入数据

,

而且需要对 应这些输入数据的预期

输出结果。在使用白盒测试时

,

最理想的情况是希望能够执行到每条路径

,

但由 于

软件需求的不完整性、

软件逻辑路径的组合性、

输入数据的大量性及结果多样性

等因素

,

< p>
哪怕是一个极其简单的程序

,

要想穷尽所有逻辑路 径、所有输入数据和验

证所有结果是非常困难的一件事情。

2.4

保留全部测试用例

< p>
软件测试开发过程中

,

一定要做好测试用例的保存 工作

,

这样在测试人员发生

变动或者开 展回归测试时会减少许多工作。

我们在在程序改良或者

Bug< /p>

改正后需

要重新测试时

,

就避免大量的枯燥乏味的重复工作

,

从而在提高测试效 果的同时也

相应的节省了软件开发成本。

2.5

软件测试的误区

< p>
在确定测试用例设计目标时

,

一些项目管理人员强 调测试用例

“越详细越好”

。

这种做法 和观点最大的危害就是耗费了很多的测试用例设计时间和资源

,

可能等

到测试用例设计、评审完成后

,

留给实际执行测试的时间所剩无几了。由于当前

软件公司的项目团队在规划测试阶段

,

分配给测试的时间和人力资源是有限的

,

而

且软件项目的成功要坚持“质量、时间、成本”的最佳平衡< /p>

,

然而

,

没有足 够多的

测试执行时间

,

就无法发现更多 的软件缺陷

,

测试质量更无从谈起了。

所以

,

有效地

设计测试用例

< p>
,

是搞好软件测试的关键。

总之

,

测试用例是测试工作的指导

,

是软件测试必须遵守的准则

,

更是软 件测

试质量稳定的根本保障。

3

测试方法分类

软件测试的目标在于以最少的时间和人力系统地找出软件中潜在的各种错

误和缺陷。

所以如何测试的彻底、

怎样设计测试用例是测试的关键所在。< /p>

而软件

测试的方法是多种多样的

,

这些方法各有优缺点

,

适用于不同的场合。下 面针对各

种测试方法及其优缺点作一下简要地介绍

,

< p>
可以从不同的角度加以分类

:

（

1

）软件开发过程中的测试。包括单元测试、集成测试、系统测试、验收

测试等

.

（

2

）软件产品的测试。测试对象是己经或即将产品化的软件

,

包括功能测

试、性 能测试、

p

测试和

Benchmark

测试

;

（

3

）

专门的软件测试。

包括可靠性测试、

标准符合性测试、

互操作性测试、

安全性测试、强度测试等。

（

4

）从是否需要执行被测软件的角度来看

,< /p>

可分为静态测试和动态测试。

（

5

）从测试是否针对系统的内部结构和具体实现算法的角度来看

,

可分为

黑盒测试和白盒测试。

软件测试的方 法和技术是多种多样的

,

从不同的角度出发

,

软件测试可以

划分为不同的分类

3.1

黑盒测试和白盒测试

最早的测试方法可分为黑盒测试和白盒测试。

3.1.1

黑盒测试

黑盒测试也称功能测试或数据驱动测试。

它在己知产品应具有的功能条件下< /p>

,

通过测试来检测每个功能是否都能正常使用。在测试时

,

把程序看作一个不能打

开的黑盒子

< p>
,

在完全不考虑程序内部结构和内部特性的情况下

,

测试者在程序接口

进行测试

,

它只检查程序功能是否按照需求规格说明书的规定正常使用

,

程序是否

能适当地接收输入数据并产生正确的输出信息

< br>,

并且保持外部信息

(

如数据库 或文

件

)

的完整性。黑盒测试也称功能 测试或数据驱动测试

,

是系统测试时常使用的方

法。它主要关注的是产品所应具有的功能

,

而不是内部 逻辑。很明显

,

如果外部特

性本身有问 题或规格说明的规定有误

,

用黑盒测试方法是发现不了的。黑盒 测试

法注重于测试软件的功能需求

,

主 要试图发现几类错误

:

功能不对或遗漏、界面错

误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误。

黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等

,

主要

用于软件确认测试

,

人们不仅要测试所有合法的输入

,

而且还要对那些不 合法但是

可能的输入进行测试

:

1< /p>

）等价类划分。等价类划分是一种典型的黑盒测试方法。等价类是指测试

< br>

-

-

-

-

-

-

-

-