软件测评师教程之软件测试基础

一.软件测试分类

(1)按照开发阶段划分

1.单元测试(模块测试)

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

2.集成测试(组装测试)

软件集成的过程是一个持续的过程，会形成很多个临时版本，在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。

3.确认测试

通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。

4.系统测试

在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接，并满足用户的需求。

5.验收测试

按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

(2)按照测试实施组织划分

1.开发方测试
2.用户测试
3.第三方测试

(3)按照测试技术划分

1.白盒测试(结构测试)

对程序内部结构的分析、检测来寻找问题。将程序看成一个透明的白盒子，能清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的。

2.黑盒测试

通过程序的外部来发现缺陷和错误。将程序看成一个黑盒子，不考虑程序结构和处理过程，在程序的界面进行测试，检查是否按照需求规定来正常实现。

3.灰盒测试

介于白盒与黑盒之间的测试。灰盒关注输出对于输入的正确性以及内在表现，但这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

二.软件测试过程模型

(1)V模型

V模型是最具有代表意义的测试模型，但存在着一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，容易使人理解为测试是软件开发的最后一个阶段，只针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

(2)W模型

强调测试伴随着整个软件开发周期，测试的对象也不仅仅是程序，需求、功能和设计同样要测试。可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。
W模型和V模型都把软件开发视为需求、设计、编码等一系列串行的活动。将软件开发和测试看成了一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一阶段，这样就无法支持迭代、自发性以及变更调整。

(3)H模型

H模型揭示了软件测试不仅仅指测试的执行，还包括很多其他的活动；软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行；软件测试要尽早准备，尽早执行；软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

(4)X模型

X模型是弥补V模型的一些缺陷。X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。【定位了探索性测试】

(5)前置测试模型

开发与测试相结合；对每一个交付内容进行测试；在设计阶段进行测试计划和测试设计；测试和开发结合在一起；让验收测试和技术测试保持相互独立。

(6)测试模型的使用

在W模型的框架下，运用H模型的思想进行独立地测试，并同时将测试和开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。

三.软件测试策略

(1)测试信息流

(2)分析设计阶段

1.需求说明书评测

编制良好需求说明书的8条原则：
原则1：功能与如何实现相分离，描述需要“做什么”而不是“如何做”；
原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明；
原则3：描述该目标软件与系统的其他系统元素交互的方式；
原则4：规格说明必须包括系统运行的环境；
原则5：系统规格说明必须是一个认识的模型，而不是设计和实现的模型；
原则6：规格说明必须是可操作的；
原则7：规格说明必须容许不完备性并允许扩充；
原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落。同时，规格说明应被松散的构造，以便容易加入和删去一些段落。

需求说明书的框架：

需求说明书评测规范：

2.概要设计说明书评测

评测内容：
①可追溯性：软件的每一成分是否可追溯到某一项需求；
②接口：确认内部接口与外部接口是否已经明确定义；
③风险：
④实用性；
⑤技术清晰度；
⑥可维护性；
⑦质量；
⑧各种选择方案；
⑨限制；
⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。

3.详细设计说明书评测

与概要说明书基本相同，这里不再赘述。

4.软件编码规范评测

A.源程序文档化：①符号名的命名，这些名字应能反应它所代表的实际东西，应有一定的实际意义；②程序的注释；③标准的书写格式。
B.数据说明：①数据说明的次序应当规范化；②说明语句中变量安排有序化；③使用注释说明复杂数据结构。
C.语句结构：语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。
D.输入和输出：输入和输出的方式和格式应尽可能方便用户的使用。

(3)开发阶段

1.单元测试

①模块接口测试
A.调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；
B.所测模块调用子模块时，它输入给子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配；
C.是否修改了只作输入用的形式参数；
D.输出给标准函数的参数在个数、属性、顺序上是否正确；
E.全局量的定义在各模块中是否一致；
F.限制是否通过形式参数来传送；
G.文件属性是否正确；
H.OPEN语句与CLOSE语句是否正确；
I.规定的I/O格式说明与I/O语句是否匹配；
J.缓冲区容量与记录长度是否匹配；
K.在进行读写操作之前是否打开了文件；
L.在结束文件处理时是否关闭了文件；
M.正文书写/输入错误，以及I/O错误是否检查并做了处理。

②局部数据结构测试（最常见的错误来源，应设计测试用例来检查）
A.不正确或不一致的数据类型说明；
B.使用尚未赋值或尚未初始化的变量；
C.错误的初始值或错误的缺省值；
D.变量名拼写错或书写错；
E.不一致的数据类型。

③路径测试（对基本的执行路径和循环进行测试）
A.运算的优先次序不正确或误解了运算的优先次序；
B.运算的方式错，即运算的对象彼此在类型上不相容；
C.算法错；
D.初始化不正确；
E.运算精度不够；
F.表达式的符号表示不正确；
G.不同数据类型的相互比较；
H.不正确的逻辑运算符或优先次序；
I.因浮点数运算精度问题而造成的两值比较不等；
J.关系表达式中不正确的变量和比较符；
K.不正确的多循环一次或少循环一次；
L.错误的或不可能的循环中止条件；
M.当遇到发散的迭代时不能中止的循环；
N.不适当地修改了循环变量。

④错误处理测试。
若出现下列的情况之一，则表明模块的错误处理功能包含有错误或缺陷：
A.出错的描述难以理解；
B.出错的描述不足以对错误定位，不足以确定出错的原因；
C.显示的错误与实际的错误不符；
D.对错误条件的处理不正确；
E.在对错误进行处理之前，错误条件已经引起系统的干预。

⑤边界测试。

2.集成测试

①一次性组装方式

首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。

②增殖式组装方式

A.自顶向下的增殖方式：将模块按系统程序结构，沿控制层次自顶向下进行组装；
B.自底向上的增殖方式：从程序模块的最底层模块开始组装和测试；
C.混合增殖式测试：把以上两种结合起来进行组装和测试。

集成测试完成的标志：
Ⅰ.成功地执行了测试计划中规定的所有集成测试；
Ⅱ.修正了所发现的错误；
Ⅲ.测试结果通过了专门小组的评审。

3.确认测试(一般由独立的第三方测试机构进行)

①进行有效性测试

在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。需要制定测试计划、测试步骤以及具体的测试用例。

②软件配置复查

其目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。

4.系统测试

将通过集成测试的软件与计算机的硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行的环境下，对计算机系统进行一系列测试。

5.验收测试

验收测试往往不是对系统的全覆盖测试，而是针对用户的核心业务流程进行的测试。同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。

(4)软件验证与确认(V&V)过程

V&V基本概念

①验证(Verification):通过检查和提供客观证据，证实规定的需求已满足；
②确认(Validation):通过检查和提供客观证据，证实预期用途的需求是否得到满足；
③独立验证和确认(Independent Verification and Validation):由在技术、管理和财务上与开发组织有规定程度独立性的组织执行的V&V过程。

四.软件失效分类与管理

1.软件失效分类

①软件错误：软件生存期内不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见软件错误是一种人为过程，相较于软件本身，是一种外部行为。
②软件缺陷：存在于软件(文档、数据、程序)之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等，其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。
③软件故障：软件运行过程中出现的一些不希望或不可接受的内部状态，此时若没有适当措施加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。
④软件失效：软件运行时产生的一种不希望或不可接受的外部行为结果。

综上所述，软件错误是一种人为错误，一个软件错误必定产生一个或多个软件缺陷，当一个软件缺陷被激活时，便产生一个软件故障(同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障)，软件故障如果没有及时的容错措施加以处理，便不可避免地导致软件失效(同一个软件故障在不同条件下可能产生不同的软件失效)。

2.缺陷与错误发布

分布情况：需求56%，设计27%，代码7%，其他10%。

3.缺陷与错误严重性与优先级

缺陷与错误划分严重性与优先级的通用原则是：
①表示软件缺陷所造成的危害的恶劣程度；
②优先级表示修复缺陷的重要程度和次序。

优先级：
①最高优先级：立即修复，停止进一步测试；
②次高优先级：在产品发布之前必须修复；
③中等优先级：如果时间允许应该修复；
④最低等优先级：可能会修复，但是也能发布。

五.白盒测试(将测试对象看作一个打开的盒子)

白盒测试也称结构测试或逻辑驱动测试，按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常运行，检测程序中的每条通路是否都能按预定要求正确工作。

六.黑盒测试(将测试对象看作一个不能打开的盒子)

黑盒测试也称功能测试，通过测试检测每个功能是否都能正常使用。着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试用例设计方法：
等价类划分法：将程序的输入域划分为若干部分，然后从每个部分中选取少数代表性数据作为测试用例，每一类的代表性数据在测试中的作用等价于这一类中的其他值。
边界值分析法：不仅重视输入条件边界，而且也必须考虑输出域边界。
错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
因果图法：从用自然语言书写的程序规格说明的描述中找出因(输入条件)和果(输出或程序状态的改变)，可以通过因果图转换为判定表。
正交试验设计法：使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。