软件工程实践方法—— 软件测试

这是我参与更文挑战的第4天，活动详情查看：更文挑战

在一项系统软件完成之后，且在上线之前，需要经过不断的软件测试，找出 bug 和错误，不断修补，才能正式上线。在下面的这篇文章中，将讲解软件测试的一些基础知识以及测试用例的设计和软件测试的步骤。

接下来开始进行讲解。

一、软件测试概述

1、软件测试的目的

（1）从用户和开发者角度

基于不同的立场，存在着两种完全不同的测试目的：

从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。
从软件开发者的角度出发，则希望测试表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，树立人们对软件质量的信心。

（2）Myers软件测试目的

测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试。

总结来说就是，测试的目的是想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析提供了依据。

2、软件测试的原则

应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
程序员应避免检查自己的程序。
在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
严格执行测试计划，排除测试的随意性。
应当对每一个测试结果做全面检查。
妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

3、软件测试的对象

软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。

需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。

简单来说，就是程序、数据和文档都应该成为测试对象。

4、测试信息流

测试信息的步骤：

软件配置（对象）：软件需求规格说明、软件设计规格说明、源代码等；
测试配置（方法）：测试计划、测试用例、测试程序等；
测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。
测试结果分析：比较实测结果与预期结果，评价错误是否发生。
排错（调试）：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。
修正后的文档再测试：直到通过测试为止。

得出结论：

通过收集和分析测试结果数据，对软件建立可靠性模型。

利用可靠性分析，评价软件质量。

如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。

5、测试与软件开发各阶段的关系

（1）软件开发过程是一个自顶向下，逐步细化的过程，主要有以下步骤：

软件计划阶段定义软件作用域。
软件需求分析阶段建立软件信息域、功能和性能需求、约束等。
软件设计。
把设计用某种程序设计语言转换成程序代码。

（2）而测试过程是按照相反顺序安排的自底向上，逐步集成的过程。

二、软件测试用例

1、黑盒测试概述

把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据需求规格说明来检查程序的功能是否符合。

黑盒测试又叫做功能测试或数据驱动测试。

黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误：

是否有不正确或遗漏了的功能?
在接口上，输入能否正确地接受? 能否输出正确的结果?
是否有数据文件访问错误?
性能上是否能够满足要求?

用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。

但这是不可能发生的事情。为什么呢？

假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按照黑盒测试方法进行穷举测试：

可能采用的测试数据组：2³² x 2³² ＝ 264。

如果测试一组数据需要1毫秒，一年工作365× 24小时，完成所有测试需5亿年。

5亿年！想想都不太可能。所以说，程序一般没有办法引入穷举测试。

2、白盒测试概述

把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构设计测试用例，对程序所有逻辑路径进行测试。

通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

因此白盒测试又称为结构测试或逻辑驱动测试。

白盒测试方法，主要对程序模块作出以下检查：

对程序模块的所有独立的执行路径至少测试一次；
对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；
在循环的边界和运行界限内执行循环体；
测试内部数据结构的有效性等等。

对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环。

包含的不同执行路径数达5²⁰条，对每一条路径进行测试需要1毫秒，假定一年工作365 × 24小时，要想把所有路径测试完，需3170年。

比起穷举测试的5亿年，3170年似乎少了不少。但是呢？3170年会不会也挺太漫长的。

因此，我们要引入一些黑白盒测试方法来解决这些问题。

3、白盒测试方法

白盒测试方法主要有以下6种方法：

语句覆盖
判定覆盖
条件覆盖
判定-条件覆盖
条件组合覆盖
路径覆盖

白盒测试方法这里篇幅较长，放在另外一篇文章中，有需要的小伙伴自取~

4、条件测试路径选择

当程序中的判定条件超过一个时，形成的分支结构可以分为两类：嵌套型分支结构和连锁型分支结构。

对于嵌套型分支结构，若有 n 个判定语句，需要 n+1 个测试用例；

对于连锁型分支结构，若有 n 个判定语句，需要有 2n 个测试用例，覆盖它的 2n 条路径。

如下图所示：

5、循环测试路径选择

循环分为4种不同类型：简单循环、连锁循环、嵌套循环和非结构循环。如下图所示：

接下来对这四种循环进行一一介绍。

（1）简单循环

①零次循环： 从循环入口到出口。

②一次循环： 检查循环初始值。

③二次循环： 检查多次循环。

④m次循环： 检查在多次循环。

⑤最大次数循环： 比最大次数多一次、少一次的循环。

（2）嵌套循环

①对最内层循环做简单循环的全部测试。所有其它层的循环变量置为最小值。

②逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。

③反复进行，直到所有各层循环测试完毕。

④对全部各层循环同时取最小循环次数，或者同时取最大循环次数。

（3）连锁循环

如果各个循环互相独立，则可以用与简单循环相同的方法进行测试。但如果几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理。

（4）非结构循环

这一类循环应该使用结构化程序设计方法重新设计测试用例。

6、基本路径测试

基本路径测试法也已经放到白盒测试方法文章当中，有需要的小伙伴自取~

7、黑盒测试的测试用例设计

黑盒测试方法主要有以下8种方法：

等价类划分法
边界值分析法
错误推测法
因果图法
判定表驱动法
正交实验设计法
场景法
功能图法

黑盒测试方法篇幅较长，已放在另外一篇文章中，有需要的小伙伴自行查阅~

三、软件测试步骤

测试过程需要按照4个步骤进行，分别是单元测试（模块）、组装测试（集成）、确认测试和系统测试。详细过程如下：

开始是单元测试，集中对使用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
组装测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
确认测试则是要检查已实现的软件是否满足了需求规格说明中已经确定的各种需求，以及软件配置是否完全、正确。
系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份地组合在一起进行测试。

以下将对这四个测试步骤进行一一讲解。

1、单元测试

（1）单元测试的定义

单元测试又称模块测试，是针对软件设计的最小单位 —— 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

（2）单元测试的内容

在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。

如下图所示：

下面对这五个测试内容进行一一讲解。

1）模块接口测试

在单元测试的开始，应该对通过被测模块的数据流进行测试。测试项目包括：

调用本模块的输入参数是否正确；
本模块调用子模块时输入给子模块的参数是否正确；
全局量的定义在各模块中是否一致；

在做内外存交换时要考虑：

文件属性是否正确；
OPEN 与 CLOSE 语句是否正确；
缓冲区容量与记录长度是否匹配；
在进行读写操作之前是否打开了文件；
在结束文件处理时是否关闭了文件；
正文书写／输入错误，
I/O 错误是否检查并做了处理。

2）局部数据结构测试

不正确或不一致的数据类型说明；
使用尚未赋值或尚未初始化的变量；
错误的初始值或错误的缺省值；
变量名拼写错或书写错；
不一致的数据类型；
全局数据对模块的影响。

3）路径测试

选择适当的测试用例，对模块中重要的执行路径进行测试；
应当设计测试用例来查找因错误的计算、不正确的比较或不正常的控制流而导致的错误；
对基本执行路径和循环进行测试，可以发现到大量的路径错误。

4) 错误处理测试

出错的描述是否难以理解；
出错的描述是否能够与具体错误相定位；
显示的错误与实际的错误是否相符；
对错误条件的处理正确与否；
在对错误进行处理之前，错误条件是否已经引起系统的干预等。

5) 边界测试

注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性；
对这些地方要仔细地选择测试用例，认真加以测试；
如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和正常情况下影响模块运行时间的因素。

（3）单元测试的步骤

模块并不是一个独立的程序，因此，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。其中，辅助模块包括：

驱动模块 (driver)；
桩模块 (stub) —— 存根模块。

依据驱动模块和桩模块，单元测试的步骤如下图所示：

网络异常，图片无法展示

如果一个模块要完成多种功能，可以将这个模块看成是由几个小的程序组成。必须对其中的每个小的程序先进行单元测试所需要做的工作，对关键模块还要做性能测试。

对支持某些标准规定的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

2、组装测试

（1）组装测试的什么

组装测试，也称为集成测试或联合测试。

（2）组装测试需考虑问题

通常，在单元测试的基础上，需要将所有模块按照设计的要求组装成为系统。这时需要考虑的问题是：

在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
各个子功能组合起来，能否达到预期要求的父功能；
全局数据结构是否有问题；
单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行组装测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
子系统的组装测试特别称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
通常，把模块组装成为系统的方式有两种：

一次性组装方式
增殖式组装方式

3、确认测试

（1）确认测试是什么

确认测试又称有效性测试。

任务是验证软件的功能和性能和其它特性是否与用户的要求一致。

在软件的需求规格说明书中明确规定软件的功能和性能要求。

它包含的信息就是软件确认测试的基础。