软件评测师-11.软件评测基础知识

11.软件评测基础知识

11.1软件测试的概念

11.1.1标准的类别和代号

我国使用的质量标准代号如下：

(1)国家标准：强制性国家标准GB，推荐性国家标准GB/T

(2)行业标准：行业标准代号为××/T，(××代表行业代号)

如航天(QJ)、电子(SJ)、机械(JB)、金融(JR)

(3)地方标准：地方标准由DB加上省××，再加上推荐性地方标准DB××/T

如北京市(11)、天津市(12)、上海市(31)

(4)企业标准：企业标准由Q加上企业代号Q/×××，再加上推荐性企业标准Q/T×××

11.1.2软件测试的目的和作用

11.1.2.1软件测试的定义

在《软件测试艺术》一书中将软件测试定义为：

(1)测试是为了证明程序有错，而不是证明程序无错

(2)一个好的测试用例在于它能发现至今未发现的错误

(3)一个成功的测试在于它能发现至今尚未发现的错误

11.1.2.2软件测试的目的

软件测试的目的和作用体现在以下几个方面：

(1)发现软件中的缺陷：这是软件测试最基础的目的

(2)验证软件的需求和功能是否得到满足和实现，这个目的是“以客户为中心”的思想，软件测试的一个重要目标是验证客户的需求是否得到满足

(3)为软件提供者和软件使用者树立对软件质量的信心

(4)为达到软件产品和软件项目的商业目标提供保证

11.1.2.3软件测试的对象

软件测试的对象不仅仅是程序，还包括数据和相关文档。其中源程序是单元测试和白盒测试的主要对象；目标程序是黑盒测试、集成测试、系统测试和验收测试的主要对象；

11.1.3软件测试的主要工作

软件测试的主要工作内容是：验证(Verification)、确认(Validation)

11.1.3.1验证的作用

验证是保证软件正确的实现一些特定功能的一系列活动，即保证软件实现了所期望的功能(Do the right thing)，包括如下方面：

(1)确定软件生存周期中给定阶段的产品是否达到前阶段确立的需求

(2)程序正确性的形式证明，即采用形式理论证明程序符号设计规约规定

(3)评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定需求相一致进行判断和提出报告

11.1.3.2确认的作用

确认是一些列的活动和过程，目的是证实在一个给定的外部环境中软件逻辑的正确性。即保证软件以正确的方式来做这个事件(Do the thing right) ，包括如下方面：

(1)静态确认：不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性

(2)动态确认：通过分析执行程序，测试程序的动态行为，以证实软件是否存在问题

 软件测试的对象不仅仅是程序，还包括数据，规程以及整个软件开发期间各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档、用户手册

11.1.4软件测试各阶段的活动

下面的表为几个阶段的主要输入文档、输出文档和关键活动的要点：

表11-1  软件测试各阶段的活动

阶段	输入文档	输出文档	关键活动的要点
测试分析	需求规格说明书 概要设计说明书 详细设计说明书	测试计划	测试需求分析、确定测试策略和范围、测试资源和时间安排以及编写和评审测试计划
测试设计	需求规格说明书 概要设计说明书 详细设计说明书 测试计划	测试用例	设计和评审测试用例、准备测试数据和编写脚本
测试执行	测试计划 测试用例	缺陷报告	搭建测试环境、执行测试用例、缺陷分析和跟踪
测试总结	测试计划 测试用例 缺陷报告	测试报告	分析测试结果、质量评估编写和评审测试报告

各个阶段的任务描述：

(1)测试分析阶段：主要任务是编写测试计划，包括确定测试的内容和目标、明确测试的范围、制定测试的策略和用例设计方法、识别风险、安排人力和设备资源，以及估算时间等，测试计划需要经过项目团队的评审。

(2)测试设计阶段：主要利用各种测试用例设计方法编写测试用例，并准备测试数据。

(3)测试执行阶段：需要搭建测试环境，执行测试用例。

(4)测试总结阶段：分析总结测试结果、对照质量标准进行质量评估，以及撰写测试报告并得出结论。

11.1.5软件质量保证(SQA)

软件测试和软件质量保证(SQA)是软件质量工程的两个不同层面的工作，

·软件测试只是软件质量保证工作中的重要环节，属于质量控制(QC)的范畴；

·软件质量保证是建立一套系统的有计划的方法，以向管理层保证拟定出的标准、步骤、实践、方法能够正确的被项目所采用。

具体来说，软件测试属于技术性工作，软件质量保证属于管理性工作

软件测试和软件质量保证的范畴如下表：

表11-2  软件测试和软件质量保证的区别

软件测试	软件质量保证
发现软件错误 保证和提高软件质量 度量和评估软件质量	发现软件错误 保证和提高软件质量 度量和评估软件质量 改进软件开发过程

11.1.6软件测试的原则

11.1.6.1常用的软件测试原则

常用的软件测试原则如下：

(1)应当把“尽早的和不断地进行测试”作为软件开发者的座右铭

(2)测试前应当设计合理的测试用例

(3)程序员应避免检查自己的程序

(4)在设计测试用例时应当包括合理和不合理的输入条件，合理的输入条件能验证程序正确的输入条件；不合理的输入条件指的是异常、临界且可能引起问题变异的输入条件

(5)充分注意测试中的集群现象：经验表明，测试后程序中残存的错误数与该程序中已发现错误数目或检错率成反比

(6)严格执行测试计划，排除测试的随意性

(7)应当对每一个测试结果做全面检查

(8)妥善保存测试计划、测试用例、出错统计和最终测试报告，为后续的维护提供方便

(9)修改程序以后要进行回归测试

(10)测试用例要能够映射到需求

11.1.6.2测试的出口条件

软件测试的停止标准或出口条件通常在测试计划中定义，度量标准包括缺陷修复率、测试覆盖率、错误曲线强度等。

测试应当适可而止，避免过度测试。

软件测试路径不可能被穷尽的，在项目时间和资源有限的情况下应当尽量满足客户的需求

11.1.6.3测试的观念

软件测试的原则和观念：

①测试开始越早，越有利于发现软件缺陷

②尽管采用正确的测试用例设计方法，软件测试的路径是无法穷尽的

③测试用例数目与测试覆盖度没有正比关系

④测试时间并非越长越好，需要在质量、进度、成本之间做出平衡

11.2软件测试过程模型

11.2.1软件测试V模型

11.2.1.1软件测试V模型的结构

软件测试V模型中的过程从左到右，描述了基本的开发 过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

局限性： 把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现.

11.2.1.2软件测试V模型的优点

软件测试V模型的优点：

(1)改善了瀑布模型

(2)反映了测试活动与分析设计的关系

(3)制定的测试策略既包括了低级测试也包括高级测试

11.2.1.3软件测试V模型的局限性

软件测试V模型的将局限性：

(1)认为测试是开发之后的阶段

(2)测试的对象就是程序本身

(3)实际应用中容易导致需求阶段的错误一直到最后系统测试才被发现

(4)整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心

11.2.2软件测试W模型

软件测试V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试” 的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W 模型（如下图）。在模型中不难看出，开发是“V”，测试是与此并行的“V”。

基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活 动应遵循IEEE1012-1998《软件验证与确认（V&V）》的原则。

W模型相对于V模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代和适应开发过程中的变更调整。

11.2.3软件测试H模型

在H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。

H模型对测试流程予以了说明。

下图为H模型示意图：

这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。

H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

H模型指出软件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

11.2.4软件测试X模型

软件测试X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。

软件测试X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。

己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。

由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

 11.2.5前置测试模型

前置测试模型吸取了V模型和X模型的优点，

它是将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以加快项目的速度。

前置测试模型如下图：

前置测试模型体现了以下的优点：

(1)开发和测试相结合

(2)对每一个交付内容进行测试

(3)在设计阶段进行测试计划和测试设计

(4)测试和开发结合在一起

(5)让验收测试和技术测试保持相对独立

(6)反复交替的开发和测试

11.3软件测试的分类

11.3.1按测试过程和层次划分的测试分类

按测试过程和层次分为如下类型：

(1)单元测试：单元测试又称“模块测试”针对软件最小单位——程序模块进行正确性验证的测试

(2)集成测试：集成测试又称为“组装测试”，在单元测试完成的基础上，将模块按照要求组装起来进行测试，主要目标是发现与接口有关的问题

(3)确认测试：确认测试验证软件功能和性能是否满足用户的要求

(4)系统测试：验证各个子系统是否能正常工作并完成设计的要求

(5)验收测试：在用户环境中测试，以确定系统和产品是否能满足合同规定的需求

11.3.2按测试采取的技术和思想方法划分的测试分类

按测试采取的技术和思想方法分为如下类型：

(1)黑盒测试：又称为“功能测试”或“数据驱动测试”，不考虑程序的内部结构，把程序看做黑盒子，只是检测功能是否能正确使用的测试

(2)白盒测试：又称为“结构测试”或“逻辑驱动测试”，不考虑软件的外部功能，把程序看做白盒子，只是检测程序内部逻辑是否正确

(3)灰盒测试：介于黑盒与白盒之间的测试

11.3.3按测试所关注的质量特性和目的划分的测试分类

按测试所关注的质量特性和目的分为如下类型：

·功能测试(Functional Testing)

·性能测试(Performance Testing)

·压力测试

·负载测试

·强度测试

·容量测试

·安全性测试

·兼容性测试

·可靠性测试

·容错性测试

·安装/卸载测试

·恢复性测试

·文档测试

·帮助测试

11.3.4按测试组织实施的对象划分的测试分类

按测试组织实施的对象分为如下类型：

·开发方测试(α测试)

·用户测试(β测试)

·第三方测试

11.3.5按测试是否执行程序划分的测试分类

按测试是否执行程序分为如下类型：·静态测试      ·动态测试

11.4单元测试

11.4.1单元测试的目的

单元测试又称“模块测试”针对软件最小单位——程序模块进行正确性验证的测试，目的在于发现软件各模块内部的错误

11.4.2单元测试的内容

单元测试的内容如下：

(1)模块接口测试

(2)局部数据结构测试

(3)路径测试

(4)错误处理测试

(5)边界测试

11.5集成测试

11.5.1集成测试的目的

集成测试又称为“组装测试”，在单元测试完成的基础上，将模块按照要求组装起来进行测试，主要目标是发现与接口有关的问题

11.5.2集成测试的内容

集成测试需要考虑的问题如下：

(1)在把各个模块连接起来时穿越模块接口的数据是否会丢失

(2)一个模块的功能是否会对另外一个模块的功能产生不利影响

(3)各个子功能组合起来是否能达到预期要求的父功能

(4)全局数据结构是否存在问题

(5)单个模块的误差累积起来是否会放大，从而达到不能接受的程度

11.5.3模块集成组装的方式

11.5.3.1一次性集成方式

一次性集成方式又称为“big bang”，首先对每个模块分别进行模块测试，然后把所有模块组装起来测试，最终得到达到要求的软件系统，这是一种“非增值式组装方式”，也称为“整体拼装”，由于一次性集成的成功率可能性不是很大，所以大型系统一般不采用这种方法

11.5.3.2增殖式集成方式

增殖式集成方式又称为“渐增式集成方式”，首先测试完成模块，然后将下一个要测试的模块和已经测试好的模块结合起来进行测试，这样逐步将其他模块组装成较大的系统

增殖式集成测试分为3种：

(1)自顶向下的增殖方式

·这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。

·自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。

·选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。

(2)自底向上的增殖方式

·这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。

·因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块(包括子模块的所有下属模块)已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。

·自顶向下增殖的方式和自底向上增殖的方式各有优缺点。

·一般来讲，一种方式的优点是另一种方式的缺点。

(3)混合式增殖方式

自顶向下和自底向上的两种方式各有优缺点，实际应用中，采用两者结合的思路

·首先对输入／输出模块和引入新算法模块进行测试;

·再自底向上组装成为功能相当完整且相对独立的子系统;

·然后由主模块开始自顶向下进行增殖测试。

11.6确认测试

11.6.1确认测试的内容

确认测试(Validation Testing)，又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。

对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。

11.6.2确认测试的目标

确认测试的目标：

·软件的特性是否与需求相符

·所有的文档都是正确且便于使用

·同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试

11.7其他测试

11.7.1易用性测试

易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。

11.7.2安装测试

安装测试的内容如下：

(1)评估安装手册

(2)检查系统是否能够安装所有需要的文件/数据并进行必要的系统设置

(3)安装的自动化程度

(4)安装过程中是否出现不可预见或不可修复的错误

(5)安装的顺序

(6)在标准或最低配置的环境下是否可以顺利安装

(7)安装后原有的应用程序是否可以正常运行

(8)卸载后文件目录以及快捷方式是否清除

11.7.3软件的α与β测试

软件的α测试是软件公司内部展开的测试，一般由公司内部专业人员执行

软件的β测试是软件公司外部展开的测试，一般由最终用户执行

11.7.4验收测试

验收测试的依据是双方事先约定的标准，如需求规格、合同及软件开发任务书等，验收测试通常由用户或用户委托的第三方测试机构来执行。

用户手册不是验收测试的依据，只是执行测试的参考资料。

11.8缺陷(Bug)描述

11.8.1缺陷产生的原因

缺陷(bug)从不同的角度表现为软件错误、软件缺陷、软件故障、软件失效

(1)软件错误

指软件生存周期中不希望或不可接受的人为错误

(2)软件缺陷

是指存在于软件之中的那些不希望或不可接受的偏差

(3)软件故障

是指软件运行过程中出现的一种不希望或不可接受的内部状态。

(4)软件失效

是指软件运行时产生的一种不可接受的外部行为结果。

11.8.2软件缺陷的定义

符合下列5种情况之一的即可认为是软件缺陷。

(1)软件未达到软件产品需求说明书中指明的要求。

(2)软件出现了软件产品需求说明书中指明不会出现的错误。

(3)软件功能超出了软件产品需求说明书中指明的范围。

(4)软件未达到软件产品需求说明书中虽未指明但应达到的要求。

(5)测试人员认为难以理解、不易使用、运行速度缓慢或者最终用户认为不好的问题。

11.8.3缺陷探测率(DDP)的计算方法

缺陷探测率DDP是一个衡量测试工作效率的软件质量成本指标，其计算公式为：

DDP=Bugs(tester)/( Bugs(tester)+ Bugs(customer))

其中，Bugs(tester)是公司测试者(包括开发人员和测试人员)发现的Bug数

Bugs(customer)是客户发现并反馈给技术支持人员修复的Bug数

例如：某公司开发的软件产品，开发人员发现80个bug，测试人员A发现50个bug，测试人员B发现50个bug，且开发人员和测试人员发现的bug不重复，客户反馈的bug数为50个。则DDP=(80+50+50)/(80+50+50+50)=78.3%

11.8.4错误的估算方法

11.8.4.1植入故障法

设Ns是测试前人为的在程序中植入的故障数(称为“播种故障”)，ns是经过一段时间测试后的播种故障数目，n0是测试中发现的程序原有故障数，则程序中原有故障总数N0为：

N0=(n0*Ns)/ns

11.8.4.2故障的Hyman分别测试法

这种方法是对植入故障法的一种补充，由两个人员分别进行测试，程序中原有故障数记为B0，测试人员甲发现的故障数是B1；测试人员乙发现的故障数是B2，两人发现的相同故障数是bc，这时有：

B0=(B1*B2)/bc

11.8.5软件编码规范评测

软件编码规范评测围绕4各方面展开：

(1)源程序文档化

(2)数据说明的方法

(3)语句结构

(4)输入/输出方法