目录
- 一.软件测试分类
- (1)按照开发阶段划分
- (2)按照测试实施组织划分
- (3)按照测试技术划分
- 二.软件测试过程模型
- (1)V模型
- (2)W模型
- (3)H模型
- (4)X模型
- (5)前置测试模型
- (6)测试模型的使用
- 三.软件测试策略
- (1)测试信息流
- (2)分析设计阶段
- 1.需求说明书评测
- 2.概要设计说明书评测
- 3.详细设计说明书评测
- 4.软件编码规范评测
- (3)开发阶段
- 1.单元测试
- 2.集成测试
- 3.确认测试
- 4.系统测试
- (4)软件验证与确认(V&V)过程
- 1.V&V基本概念
- 2.软件V&V过程
- 3.软件V&V过程中的测试
- 4.软件测试V&V活动
一.软件测试分类
(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.单元测试
①模块接口测试。
②局部数据结构测试。
③路径测试。
④错误处理测试。
⑤边界测试。