[软件测试][概论和基础][一][学习笔记]

1.软件测试概论

软件测试是伴随软件的产生而产生的，有了软件生产和运行就必然有软件测试。早期的软件开发过程中，测试等同于调试，目的是纠正软件中已知的错误，通常由开发人员自己完成。对测试投入极少，介入的时间也很晚，常常等到产品基本完成时才进行测试。

直到1957年，软件测试才开始与调试区别开来，成为一种发现软件缺陷的活动。但测试工作仍然后于开发的活动。1972年在北卡罗莱纳大学举行了首届软件测试会议，1975年John Good Enough和Susan Gerhart在IEEE上发表了"测试数据选择的原理（Toward a Theory of Test Data Selection）"的文章，软件测试才被确定为一种研究方向。而1979年，Glen ford Myers的《软件测试艺术》（The Art

of Software Testing）算是软件测试领域的第一本最重要的著作，Myers对测试定义是：测试是为发现错误而执行的一个程序或者系统的过程。Myers和他的同事在20世纪70年代的工作是测试过程发展的里程碑。

20世纪80年代早期，"质量"号角开始吹响。软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。软件开发人员和测试人员开始坐在一起讨论软件工程和测试问题，制定了各类标准，包含IEEE（Institute of Electrical and Electronic Engineers）标准、美国ANSI（American National Standard Institute）标准以及ISO（International Standard Organization）国际标准。1983年，Bill Hetzel在《软件测试完全指南》（Complete Guide of Software Testing）一书中指出：测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。Myers和Hetzel的定义至今仍被引用。

20世纪90年代，测试工具开始流行。2002年，Rick和Stefan在《系统的软件测试》（Systematic Software Testing）书中对软件测试做了进一步的定义：测试是为了度量和提高被测试软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。

随着计算机和软件技术的飞速发展，软件测试技术研究也取得了很大突破，测试专家总结了很好的测试模型，比如V模型、W模型等，在测试过程改进方面提出了TMM（Testing Maturity Model）概念，在单元测试、自动化测试、负载压力测试以及测试管理等方面也出现了大量优秀的测试工具。

2.软件测试基础

2.1.软件测试和软件质量

2.1.1.什么是软件测试

测试（test）最早出现在古拉丁字，它有"罐"或"容器"的含义。在工业制造和生产中，测试被当作一个常规的检验产品质量的生产活动。测试的含义：以检验产品是否满足需求为目标。而软件测试活动包括了很重要的任务，即发现错误。

"软件测试"的经典定义是在规定条件下对程序进行操作以发现错误，对软件质量进行评估。

软件是由文档、数据以及程序组成的，那么软件测试就应该是对软件形成过程的文档、数据以及程序进行的测试，而不仅是对程序进行测试。

随着人们对软件工程化的重视以及软件规模的扩大，软件分析、设计的作用越来越突出，多数软件错误并不是程序错误，而是分析和设计错误。因此，做好软件需求和设计阶段的测试工作就显得很重要。这就是提倡软件全生命周期测试的理念。

2.1.2.什么是软件质量

1999年，软件"产品评价"国际标准ISO 14598经典的"软件质量"定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。

2001年，软件"产品质量"国际标准ISO 9126定义的软件质量包括"内部质量"“外部质量”"使用质量"三部分。也就是说，"软件满足规定或潜在用户需求的能力"要从软件在内部、外部和使用中的表现来衡量。

2.1.3.测试和质量的区别

软件测试人员的一项重要任务是提高软件质量，但不等于说软件测试人员就是软件质量保证人员，因为测试只是质量保证工作的一个环节。

质量保证（QA）：质量保证的重要工作通过预防、检查与改进来保证软件质量。QA采用"全面质量管理"和"过程改进"的原理开展质量保证工作。所关注的是软件质量的检查与测量。QA工作是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求，因此主要关注软件开发过程、步骤和产物。

软件测试：测试是对过程的产物以及开发的软件进行剖析。测试人员要"执行"软件，对过程中的产物-开发文档和代码进行走查，运行软件，找出问题，报告质量。测试人员必须假设软件存在问题，测试中的操作是为了找出更多的问题，而不仅仅是为了验证正确性。对测试中发现的问题的分析、跟踪与回归测试也是软件测试的重要工作，因此软件测试是保证软件质量的一个重要环节。

2.2.软件测试目的

Grenford J. Myers就软件测试目的提出了以下观点。

测试是程序的执行过程，目的在于发现错误。

一个好的测试用例在于能发现至今未发现的错误。

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

Bill Hetzel提出测试目的不仅是发现软件缺陷与错误，也对软件质量进行度量和评估，以提高软件质量。

测试的目的是以最少人力、物力和时间找出软件中潜在错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在软件缺陷和错误造成的隐患所带来的商业风险。

2.3.软件测试原则

所有的软件测试都应追溯到用户需求。

这是因为软件的目的是使用户完成预定的任务，并满足用户的需求，而软件测试所揭示的错误和缺陷使软件达不到用户需求。

应当把"尽早地和不断地进行软件测试"作为软件测试者的座右铭。

在软件生命周期各个阶段都可能产生错误，所以不应把软件测试看作是软件开发的一个独立阶段的工作，应当把它贯穿到软件开发的各个阶段中。在需求分析和设计阶段就应开始测试工作，编写相应的测试文档。同时，坚持在开发的各个阶段进行技术评审与验证，这样才能尽早发现错误与预防错误。只要测试在生命周期中进行得够早，就能够提高被测软件的质量，这就是预防性测试的基本原则。

完全测试是不可能的，测试需要终止。

想要进行完全的测试，在有限条件和时间下，找出所有缺陷和错误是不可能的。有三个原因：1，输入量太大。2，输出结果太多。3，路径组合太多。因此要根据测试错误概率和软件可靠性要求，确定最佳停止测试时间。

测试无法显示软件潜在的缺陷。

进行测试是可以查找并报告发现的软件缺陷和错误，但不能保证能找到所有的缺陷和错误。

充分注意测试中的群集现象。

测试后程序残存的错误数目与该程序中已发现的错误数目成正比。应对错误群集的程序段进行重点测试以提高测试投资的效益。

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

由于思维定势，人们难以发现自己的错误。因此，应由独立的测试部门进行测试。

尽量避免测试的随意性。

应该从工程的角度去理解软件测试，它是有组织、有计划、有步骤的活动。

2.4.软件测试对象

软件包括程序、数据以及文档，软件测试应贯穿整个软件生命周期中。在软件生命周期中，各阶段有不同的测试对象。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都是测试的对象。在编码结束后，对编写的每一个程序模块进行测试，称为"模块测试"或"单元测试"；在模块集成后，对集成在一起的模块组件，称为"集成测试"；在集成测试后，需要检测软件是否满足软件需求说明书中规定的要求，称为"确认测试"；将整个软件模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为"系统测试"。

验证（verification）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。

确认（validation）是保证软件满足用户需求的一系列活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。

2.5.软件测试分类

2.5.1.按开发阶段划分

按开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。

单元测试

单元测试也叫模块测试，针对软件设计的最小单元-程序模块进行正确性检验。目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部存在的错误。单元测试需要从程序内部结构出发设计测试用例。多个模块可以独立平行进行单元测试。

集成测试

集成测试也叫组装测试。在单元测试基础上，将所有程序模块进行有序递增的测试。检验程序单元或部件的接口关系，逐步集成为符合概要设计的程序部件或整个系统。

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

确认测试

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

系统测试

系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行测试。是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（硬件、外设、网络和系统软件等）正确配置、连接，并满足用户需求。

验收测试

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

2.5.2.按测试实施组织划分

按照实施组织划分，软件测试可分为开发方测试、用户测试（β测试）、第三方测试。

通常叫"验证测试"或"α测试"。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。α测试是在软件开发环境下，有开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的"系统测试"一并进行。

在用户的应用环境下，用户通过使用软件，检测软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的"验收测试"，而是指用户的使用性测试，找出软件应用过程中发现的软件缺陷问题，对使用质量进行评价。β测试通常看成一种"用户测试"。β测试是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。通过用户各种方式的大量使用，来发现软件存在的问题与错误，把信息反馈给开发者修改。β测试中厂商获取地信息，可以有助于软件产品地成功发布。

介于软件开发方和用户方之间地测试组织地测试。第三方测试也称为独立测试。软件质量工程强调开展独立验证和确认（IV&V）活动。是由在技术、管理和财务上与开发组织具有规定程度独立地组织执行验证和确认过程。软件第三方测试也就是由在技术、管理和财务上与开发方和用户方相对独立的组织进行软件测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。

2.5.3.按测试技术划分

按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。

静态测试是指不运行程序，通过人工对程序和文档进行分析与检查；又称为静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查。

静态测试包括：走查、符号执行、需求确认等。

动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。又称结构测试。

通过软件的外部表现来发现其缺陷和错误。把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，只是检查程序是否按照需求规格说明书的规定正常实现。

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

开发文档和源码可以应用单元测试应用走查方法；单元测试可应用白盒测试；集成测试应用灰盒测试；系统测试和确认测试应用黑盒测试。

2.6.软件测试过程模型

2.6.1.V模型

V模型最早是由Paul Rook在20世纪80年代后期提出的，V模型在英国国家计算中心文献中发布，皆在改进软件开发的效率和效果。

在传统开发模型比如瀑布模型中，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全完成后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但有人仍认为测试只是一个收尾工作，而不是主要的过程。V模型的推出就是对这种认知的改进。V模型是瀑布模型的变种，反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如下图所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，对应右边上升部分是各测试过程的各个阶段。

V模型的软测策略既包含低层测试又包含高层测试，低层验证源代码正确性，高层验证整个系统满足用户需求。

V模型指出，单元和集成测试是验证的程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证应当验证系统设计，检验系统功能、性能的质量特性是否达到系统设计的指标，由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。

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

2.6.2.W模型

V模型局限性在于没有明确地说明早期的测试，不能体现"尽早地和不断地进行软件测试"的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型，实际上开发是"V"，测试的和开发并行的"V"。W模型如下图所示：

W模型有Evolutif公司提出。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，测试与开发同步进行，有利于尽早发现问题。以需求为例，需求分析一完成，就可以对需求进行测试，不用等到最后才进行针对需求的验收测试。

W模型有其局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，上阶段完成才能进行下一阶段。这样就无法支持迭代、自发性以及变更调整。

2.6.3.H模型

V模型和W模型都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上大部分时间内，它们是可以交叉进行的。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V、W模型没有很好体现测试流程的完整性。

为了解决以上问题，有专家提出了H模型，它将测试活动完全独立出来，形成一个独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型的示意图如下：

示意图仅仅演示了整个生产周期中某个层次上的一次测试"微循环"。图中的其他流程可以是任意开发流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。在H模型中，测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。

H模型揭示了：

软件测试不仅仅指测试的执行，还包括很多其他活动

软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

软件测试要尽早准备，尽早执行。

软件测试是根据被测物地不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，也可能是反复的。

2.6.4.X模型

X模型的基本思想是由Marick提出的，目标是弥补V模型的一些缺陷。如下图所示：

X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。而且这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。

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

2.6.5.测试模型的使用

任何模型都是不完美的，尽可能应用模型中对项目有实用价值的方面，不能为使用模型而使用模型。在实际工作中，我们要灵活运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立地测试，并同时将测试和开发紧密结合，寻找恰当地就绪点开始测试并反复迭代测试，最终保证按期完成预定的目标。

2.7.软件生命周期测试策略

2.7.1.软件开发和软件测试

软件开发过程是一个自顶向下，逐步细化的过程。首先，在软件计划阶段定义了软件的作用域，然后进行软件需求分析，建立软件的数据域、功能和性能需求、约束及一些有效性准则。接着进入软件开发、软件设计，把设计用某种编程语言转换成代码。而测试过程则是按照相反的顺序安排自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。不排除两者平行进行测试。

如下图所示，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。随后再对照需求，进行确认测试。最后从系统整体出发，运行系统，看是否满足要求。

2.7.2.软件测试策略

测试过程按4个步骤进行，即单元测试、集成（组装）测试 、确认测试和系统测试。

开始是单元测试，检查各个程序是否正确实现规定的功能。然后，把已测试过的模块组装起来，进行集成测试（组装测试），主要对与设计相关的软件体系结构的构造进行测试。再将一个个实施了单元测试并确保无误的程序模块组装成软件系统的过程中，对正确性和程序结构等方面进行检查。确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。最后是系统测试，把已经经过确认的软件纳入实际运行环境中，与其他系统成分组合在一起进行测试。

自动化测试

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。