【软件缺陷概述】

1 软件缺陷是什么

1.1 软件出错机理

软件出错机理可描述为：

（1）软件错误（error）

是指软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。

（2）软件缺陷（bug）

是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

（3）软件故障（fault）

是指软件运行过程中出现的一种不希望或不可接受的内部状态，此时若无适当措施加以及时处理，便产生软件失效。

（4）软件失效（failure）

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

错误（error）可能转化为缺陷（bug），也可能不会；缺陷可能导致系统故障（fault）或失效（failure），也可能不会。

 

1.2 软件缺陷激活条件

符合下列五种情况之一就可认为是软件缺陷：

（1）软件未达到软件产品需求说明书指明的要求；

（2）软件出现了软件产品需求说明书指明不会出现的错误；

（3）软件功能超出软件产品需求说明书指明的范围；

（4）软件未达到软件产品需求说明书虽未指明但应达到的要求；

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

 

1.3 软件缺陷的特征

（1）“看不到”——缺陷不易看到

（2）”看到但是抓不到“——发现了缺陷，但不易找到问题发生的原因所在

 

2 软件缺陷分类

2.1 按错误的影响和后果分类

（1）较小错误

只对系统输出有一些非实质性的影响。例如输出的数据格式不合要求。

（2）中等错误

对系统的运行有局部影响。

（3）较严重错误

系统的行为出现明显不合情理的现象。

（4）严重错误

系统运行不可跟踪，一时不能掌握其规律，时好时坏。

（5）非常严重的错误

系统运行中突然停机，原因不明，无法软启动。

（6）最严重的错误

系统运行导致环境破坏，或是造成事故，引起生命、财产的损失。

 

2.2 按错误的性质和范围分类

Beizer从软件测试观点出发，把软件错误分为5类：

（1）功能错误

规格说明错、功能错误、测试错误、测试标准引起的错误

（2）系统错误

外部接口错误、内部接口错误、硬件结构错误、操作系统错误、软件结构错误、控制与顺序错误、资源管理错误

其中，外部接口指的是终端、打印机等系统与外部环境通信的手段，内部接口指的是程序之间的联系。

（3）加工错误

算术与操作错误、舒适化错误、控制和次序错误、静态逻辑错误

（4）数据错误

动态数据错误、静态数据错误、数据内容错误、数据结构错误、数据属性错误

（5）代码错误

语法错误、打字错误、对语句或指令不正确理解所产生的错误

 

2.3 按软件生存期阶段分类

（1）问题定义（需求分析）错误

由于问题定义不满足用户的要求而导致的错误。

（2）规则说明错误

指规格说明与问题定义不一致所产生的错误。

分为：不一致性错误、冗余性错误、不完整性错误、不可行错误、不可测试错误

（3）设计错误

设计阶段产生的错误，使得系统的设计与需求规格说明中的功能说明不相符。

分为：设计不完全错误、算法错误、模块接口错误、控制逻辑错误、数据结构错误

（4）编码错误

多种多样。

在不同的开发阶段，错误的类型和表现形式不同，故应采用不同的方法和策略来进行检测。

 

3 软件缺陷的产生

3.1 造成软件缺陷的主要因素

（1）技术问题

（2）团队工作

（3）软件本身

 

3.2 软件缺陷的构成

软件需求说明书是存在软件缺陷最多的地方。

原因：

用户的计算机知识较少、要开发产品的特性不够清晰、需求变化的不一致、对需求说明书不重视、项目组成员间缺少沟通

 

3.3 软件缺陷的状态

（1）激活状态（Active或Open）：问题还没解决

（2）已修正状态（Fixed或Resolved）：开发人员针对缺陷修正程序，认为已解决问题或通过单元测试

（3）关闭或非激活状态（Close或Inactive）：测试员验证Fixed bug，确认bug已经被修改的状态

（4）Hold状态：第三方产品引起的、或是无法解决的bug

（5）Differed状态：不需解决或者准备在下版中解决的bug

 

4 软件缺陷修复的代价

软件在从计划、编制、测试、一直到交付用户公开使用的过程中，都有可能产生和发现错误。

随着整个开发过程的时间推移，修复软件的费用呈几何级数增长。

 

5 软件可靠性问题

5.1 软件可靠性定义

IEEE将软件可靠性定义为：

在给定的时间间隔内和特定环境下，软件按规格说明成功运行的概率。

（1）给定的时间间隔：一般采用 运行时间t 作为时间的尺度

（2）环境条件：软件的使用环境。

无论什么软件，如果不对它的使用环境加以限制，都会失效。这种失效的数据，不能用来度量软件的可靠性。

（3）成功运行：指不仅程序能正确运行，满足用户对它的功能要求；而且当程序一旦受到意外的伤害或系统故障时，能尽快恢复正常运行。

 

5.2 软件可靠性的主要指标

借用硬件可靠性的定量度量方法来度量软件的可靠性

MTBF：平均故障间隔时间

MTTF：平均故障时间

MTTF = 1/n × Σ(i=1~n) ti        t1, t2, ……, tn：失效时间

 

5.3 软件可靠性问题

因软件设计故障而引发的系统失效 与 因计算机硬件设计故障而引发的系统 的比例大约是 10：1

 

运行软件的驻留故障密度（每千行代码的故障数目）：

（1）要求很高的关键财务或财产软件为：每千行代码 1~10 个故障

（2）关键的生命软件为：每千行代码 0.01~1 个故障

 

软件可靠性是对软件在设计、开发以及所预定的环境下具有能力的置信度的一个度量，是衡量软件质量的主要参数之一。

软件测试则是保证软件质量、提高软件可靠性的最重要手段。

 

6 软件错误数估算

6.1 植入故障法估算（捕获—再捕获抽样法）

设 Ns 是在测试前人为地向程序中植入的故障数（称为播种故障）

ns 是经过一段时间测试后发现的播种故障的数目

n 是在测试中发现的程序原有故障数

（即 经过一段时间测试后发现的故障数 = 播种故障的数目 + 原有故障的数目）

设测试用例发现植入故障和原有故障的能力相同，则程序中原有故障总数：

 

6.2 Hyman分别测试法

由两个测试员同时互相独立测试同一程序的两个福本，用 t 表示测试时间，记：

t = 0 时，程序中原有故障总数是 B0；

t = t1 时，测试员甲发现的故障总数为 B1，测试员乙发现的故障总数为 B2；其中两人发现的相同的故障数目是 bc，两人发现的不同故障数目为 bi。

则：

 

【软件测试概述】

1 软件测试的定义

1.1 一般定义

IEEE：明确提出了软件测试以检验是否满足需求为目标

Myers：软件测试是为了发现错误而运行程序的过程。

这一定义明确指出软件测试的目的是“发现错误”。

 

广义软件测试的定义

广义的软件测试是由确认、验证、测试三方面组成。

（1）确认：评估将要开发的软件产品是否“正确无误”、可行和有价值的。

（2）验证：检测软件开发的每个阶段、每个步骤的结果是否“正确无误”、是否与软件开发各阶段的要求或期望的结果相一致。

（3）测试：同前。

 

软件测试相关术语

测试用例

所谓测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果；测试用例是执行测试的最小实体。

测试步骤

测试步骤详细规定了如何设置、执行、评估特定的测试用例。

精确和准确

准确是指得到的测试结果与真实值之间的接近程度；

精确是指同样环境下重复测试所得到的结果之间的重现性。

确认和验证

确认—证明所提供的（或将要提供的）产品适合其预计的用途；保证“做的东西正确”；

验证—查明工作产品是否恰当地反映了规定的要求；保证“做得正确”。

软件测试的对象

软件测试应该贯穿整个软件定义与开发整个期间。

因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都是软件测试的对象。

 

2 软件测试的重要性

软件错误不可避免

软件错误不一定是由编码引起的，很可能是详细设计、概要设计阶段，甚至是需求分析阶段的问题引起的。

及早排除开发中的错误，就可排除给后期工作带来的麻烦，降低出错代价。

 

软件测试无处不在

 

3 软件测试的分类

3.1 按测试过程/开发阶段

（1）单元测试：又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。

（2）集成测试：又称组装测试，是将模块按照设计要求组装起来进行测试，主要目标是发现与接口有关的问题。

（3）确认测试：验证软件的功能和性能及其它的特性是否与用户的要求一致。

（4）系统测试：是在集成测试通过后进行，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。

（5）验收测试：用户为主，开发人员参与，以规格说明书为烂笨的测试。

 

3.2 按测试用例设计方法

（1）白盒测试：也称结构测试或逻辑驱动测试。

从程序的控制结构出发进行的测试，测试程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。

（2）黑盒测试：又称功能测试、数据驱动测试或基于规格说明书的测试。

是一种从用户观点出发的测试，已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。

（3）灰盒测试：是介于白盒测试和黑盒测试之间的测试。

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

 

3.3 按实施对象

（1）Alpha测试（企业内部测试）：是由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。

（2）Beta测试（最终用户测试）：是软件的多个用户在实际使用环境下进行的测试。

（3）第三方测试（独立测试）

 

3.4 按执行方式

（1）人工测试

（2）自动化测试：通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试。如负载测试、性能测试、可靠性测试等。

 

3.5 按测试方法

（1）静态测试：在用计算机测试源程序时，并不真正运行被测试的程序，只对被测程序进行特性分析。

（2）动态测试：计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况（输入/输出的对应关系）进行分析。

 

3.6 按测试形态（Testing Types）

（1）建构性测试（Construction Testing）

（2）系统测试（System Testing）

（3）特殊测试（Special Tesing）

 

4 软件测试的目的和原则

4.1 软件测试的目的

Myers观点：

（1）软件测试是程序的执行过程，目的在于发现错误；

（2）测试是为了证明程序有错，而不是证明程序无错误；

（3）一个好的测试用例是在于它能发现至今未发现的错误；

（4）一个成功的测试是发现了至今未发现的错误的测试。

解释：

测试要以查找错误为中心，但发现错误并不是软件测试的唯一目的，没有发现错误的测试也是有价值的。

 

4.2 软件测试的原则

七大测试原则

（1）测试只是展示缺陷

测试只能表明缺陷存在，却不能证明没有缺陷。

测试能降低未发现缺陷留存的概率，却不能证明软件是绝对正确的。

（2）穷尽测试是不可能的

可以取而代之的是基于风险和优先级的测试。

（3）早期测试

（4）缺陷簇生

要对缺陷发现率高的模块投入更多的测试。

（5）杀虫剂悖论

相同的测试再重复多次后就无法再找到缺陷了。

要克服“杀虫剂悖论”，测试用例要不断评审修改，不断添加新的和不同的测试，就有可能找到更多缺陷。

（6）测试是上下文相关的

测试在不同上下文环境中的执行是不同的。

即，不能用相同的态度和手段来测试不同类型的系统。

（7）无错谬论

加入建立的系统不稳定或不能满足用户需要和期望，那么发现和修复缺陷就毫无帮助了。

 

其他测试原则

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

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

在设计测试用例时，应当包括合理的输入条件和不合理的输入条件（即异常的、临界的、可能引起问题的输入条件）。

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

妥善保存测试计划、测试用例、出错统计和最终分析报告。

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

对测试结果要有一个确认过程，A测出的错误由B确认。

软件测试必须基于“质量第一”的思想去开展各项工作。

并非所有软件缺陷都要修复。正确判断，合理取舍。

 

5 软件测试活动

基本测试过程

基本测试过程由以下测试活动构成：

（1）计划与控制

测试计划是定义测试目标及测试活动规格说明以满足特定目标和使命的过程，可总结为：什么人，在什么时间内，根据什么，做什么。

测试控制是持续比较实际进展和计划的活动，并报告状态，比如实际和计划的偏离。

（2）分析与设计

测试分析和设计是将抽象测试目标转化为具体有形测试条件和测试用例的过程。

（3）实施与执行

测试实施和执行是结合测试用例确定测试规程、脚本以及执行顺序，建立测试环境并运行测试的过程。

a. 测试用例可以是高级/抽象的，也可以是具体可遵照执行的；

b. 测试用例中可以遵照执行的动作序列

c. 测试脚本特指自动化脚本

（4）评估出口准则和报告

评估出口准则是指将测试执行与先前定义目标做比较评估的活动。

（5）测试结束活动

测试结束活动指的是从已完成的测试活动中整理经验、测试件和事实数据等。

 

测试独立性

一定程度的独立性常使测试人员能更有效地发现缺陷和失效，由低到高定义独立性级别：

（1）被测试软件开发者来设计测试（最低独立性）

（2）其他人（比如其他开发人员）来设计测试

（3）同组织内其他组的人员（比如独立测试组）或测试专业人员来设计测试

（4）不同组织或公司的人员来设计测试

 

软件测试的周期性

软件测试的周期性是：测试 -> 改错 -> 再测试 -> 再改错 这样一个循环过程

 

6 软件测试技术概要

通常，软件测试要经过单元测试、集成测试、确认测试、系统测试以及验收测试。

 

软件测试技术

（1）白盒测试和黑盒测试

（2）静态测试和动态测试

（3）传统测试方法和面向对象测试的方法

（4）特定环境及应用的测试

 

7 软件测试误区

 

8 测试员应有的素质

（未完）

 

【软件测试的模型】

软件测试模型是软件测试的工作框架，用于指导软件测试过程

1 V模型

V模型描述了一些不同的测试级别，并说明了这些级别所对应的生命周期中的不同阶段。

左边下降的是开发过程各阶段，右边上升的是测试过程各阶段。

V模型的价值

非常明确地标明了测试过程中存在地不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系：

单元测试是针对编码过程中可能存在的各种错误；

集成测试是针对详细设计中可能存在的问题，尤其是检查个单元与其他程序部门之间的接口上可能存在的错误；

系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运行；

验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

V模型的问题

测试是开发之后的一个阶段，测试的对象是程序本身，容易导致需求阶段的错误一直到最后系统测试阶段才能发现。

 

2 W模型

W模式是对V模型测试的改进，在概要设计、详细设计和编码每个步骤都要进行检测，尽量把问题及时发现、及时消灭。

W模式是基于 IEEE std 1012-1998《软件验证和确认（V&V）》原则提出，此原则的主要思想是：尽早地和不断地进行软件测试。

W模型特点：

测试伴随整个开发周期，相应开发活动完成，即可对相应开发活动进行测试。

测试对象不仅是程序，还包括需求和设计。

优点

强调了测试计划等工作的先行和对系统需求和设计的测试。

缺点

没有对软件测试流程予以说明。

 

3 H模型

V模型和W模型的局限

软件开发被视为一系列串行活动，实际上大部分时间可并发。

（未完）

H模型

H模型讲测试作为一个独立流程，贯穿整个开发周期，与其他流程并行，同时测试准备和测试执行分离。

H模型特性

测试是一个独立流程，贯穿产品整个生命周期，与其他流程并发执行；

测试要尽早准备，尽早执行；

测试是根据被测对象的不同而分层进行。

H模型的意义

测试准备和测试执行分离，有利于资源调配、降低成本、提高效率。

充分体现测试过程的复杂性。

有组织、有结构化的独立流程，有助于跟踪测试投入的流向。

 

4 X模型

左侧

X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试；

右上

此后将进行频繁的交接，通过集成最终合成为可执行的程序；

这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模的范围内集成的一部分。

多根并行的曲线标识变更可以在各个部分发生。

右下

X模型还定位了探索性测试，即不进行事先计划的特殊类型的测试。

这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

X模型的特定

X模型不像V模型一样有明确的需求角色的确认；

X模型也不要求在集成测试前对每一个程序片段都进行单元测试，但X模型没能提供是否要跳过单元测试的判断准则。

 

5 前置模型测试

前置模型测试将测试和开发紧密结合，可加快项目的开发速度。

V模型和X模型是当前被测试专家所推崇的主要的测试模型，前置模型从V模型和X模型中汲取其中精华，并设法弥补了它们的不足之处。

（1）开发和测试相结合

前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为，并且标识了这些行为在项目周期中的价值所在。

（2）对每一个交付内容进行测试；每一个交付的开发结果都必须通过一定的方式进行测试

 除了源代码之外，图中的圆圈标识了其他需要测试的对象，包括可行性报告、业务需求说明、系统设计文档等。

（3）在设计阶段进行计划和测试设计；设计阶段是做测试计划和测试设计的最好时机

（4）前置测试将测试执行和开发结合在一起，并在开发阶段以 编码-测试-编码-测试 的方式来体现；也就是说，程序片段一旦编写完成，就会立即进行测试。

（5）让验收测试和技术测试保持相互独立：验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及编码能够符合最终用户的需求

验收测试既可以在实施阶段的第一步来执行，也可以在开发阶段的最后一步执行。

前置测试模型体长验收测试和技术测试沿着两条不同的路线来进行，每条路线分别地验证系统是否能够如预期的设想进行正常工作。

（6）反复交替的开发和测试：开发和测试需要一起反复交替地执行

（7）发现内在的价值：迁至测试能给需要使用测试技术的开发人员、测试人员、项目经理和用户等带来很多不同于传统方法的内在的价值

前置测试用较低的成本来及早发现错误，并且充分强调了测试对确保系统的高质量的重要意义。

在整个开发过程中，我们反复使用了各种测试技术以使开发人员、经历和用户节省时间、简化工作。

前置测试模型内在的价值

（1）针对设计的测试编写是检验设计的一个非常好的方法，由此可以及时避免因为设计不哼却而造成的重复开发及代码修改。

（2）测试工作先于程序开发而进行，这样可以明显地看到程序应该如何工作；提前的测试可以帮助开发人员立刻得到正确的错误定位

（3）在测试先于编码的情况下，开发人员可以在一完成编码时就立刻进行测试，效率高、思路不会被打断。

（4）程序员能够参考到测试的输入数据及输出结果要求，及时纠正理解上的误区

（5）前置测试定义了如何在编码之前对程序进行测试设计，节省时间、减少重复工作

 

 

来源：微拂素罗衫