空间管理您的位置: 51Testing软件测试网 » 掰掰袖的个人空间 » 日志

软件测试基础理论知识

上一篇 / 下一篇 2022-02-11 11:47:16 / 个人分类：测试

查看( 504 ) / 评论( 0 ) / 评分( 0 / 0 )

今年九月初找工作才开始走上软件测试的道路，下面的是我找软件测试这份工作之前通过阅读软件测评师教程做的笔记。因为是为找工作中的笔试和面试准备的，所以都是一些重点的罗列，希望能帮到正在找软件测试工作的应届生们。

1、软件测试的目的是发现软件中存在的错误，提高软件质量，降低软件项目的风险。

2、软件测试只能证明软件存在错误，而不能证明软件没有错误。测试的目的只是把软件的错误控制在一个可以进行产品交付/发布的程度上，可以交付/发布产品并不是没有错误的产品。

3、软件测试不可能无休止的进行下去。随着测试时间的延伸，发现错误的成本会越来越大，这就需要测试有度，而这个度并不能由项目计划实际判断，而是要根据测试发现错误的概率来判断。

4、第三方测试指独立于软件公司自身测试的测试，所谓第三方是指在软件公司和软件用户之间的一方，是一个中介的服务机构，第三方测试除了发现软件问题之外，还要对软件进行科学、公正的评价的职能。

5、软件测试是指对软件形成过程中的文档、数据及程序进行的测试，而不仅仅是对程序进行的测试。

6、软件测试与质量保证的区别

质量保证（QA）：质量保证的重要工作通过预防、检查与改进来保证软件质量，QA采用“全面质量管理”和“过程改进”的原来来开展质量保证工作，所关注的是软件质量的检查与测量。QA的工作是软件生命周期的管理及验证软件是否满足规定的质量和用户需求，因此主要着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析找出问题或评估。

软件测试：软件测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出来的软件进行剖析。

7、软件测试的作用

对软件质量进行度量和评估，以验证软件的质量满足用户的需求的程度，为用户选择和接受软件提供有力的依据；
通过分析错误产生的原因帮助发现当前开发工作所采用的软件过程的缺陷；
通过测试结果的分析整理，还可以修正软件开发规则，并未软件可靠性分析提供依据；

8、软件测试的原则

所有软件测试都应追溯到用户需求；
应当把“尽早地和不断地进行软件测试”作为软件测试的座右铭；
完全的测试是不可能的，测试需要终止；
测试无法显示软件潜在的缺陷；
充分注意测试中的群集现象；
程序员应避免检查自己的程序；
尽量避免测试的随意性。

9、软件测试的对象

软件中的程序、数据和文档。软件测试贯穿字整个软件生命周期中，各阶段有不同的测试对象，形成了不同阶段的不同类型的测试。

需求分析、概要设计、详细设计以及程序编码等各个阶段所得的文档，包括需求规格说明书、概要设计规格说明、详细设计规格说明以及源程序；
在软件编码结束之后，对编写的每个程序模块进行测试，称为“模块测试”或“单元测试”；
在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；
在集成测试之后，需要检测与证实软件满足软件需求规格说明书中规定的要求，这就成为“确认测试”；
将整个程序模块即成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。

10、验证与确认

验证是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标；确认是保证软件满足用户需求的一系列的活动与过程，目的是在软件开发完成后保证软件与用户需求相符合。

验证与确认均属于软件测试，包括对软件分析、设计及程序的验证和确认。

11、软件测试的分类

按照全生命周期的软件测试概念，测试对象应该包括软件设计开发的各个阶段的内容，此处重点讲述开发阶段的测试和程序测试。

（1）按照开发阶段划分：

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

单元测试：单元测试又称为模块测试，是针对软件设计的最小单位—程序模块进行正确性检验的测试工作。其目的在于坚持每个程序单元能否正确的实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试：集成测试也叫做组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步即成为符合概要设计要求的程序部件或整个系统。

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

确认测试：确认测试时通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。
系统测试：系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统的测试。系统测试时在真实或者模拟系统运行的环境下，检查完整的程序能否与系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。
验收测试：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或者拒收系统。

（2）按照测试实施组织划分

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

开发方测试：通常也叫“验证测试”或“α测试”。开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以与软件的“系统测试”一并进行。
用户测试：在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况下，用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。

β测试通常被看成是一种“用户测试”。β测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。通过用户各种方式的大量使用，来发现软件中存在的问题与错误，把信息反馈给开发者修改。β测试中厂商获得的信息，可以有助于软件产品的成功发布。

第三方测试：介于软件开发方和用户方之间的测试组织的测试，第三方测试也成为独立测试。独立的验证和确认活动。在模拟用户真实应用环境下，进行软件确认测试。

（3）按照测试技术分

第一种划分：静态测试、动态测试；

静态测试：指不允许程序，通过人工对程序和文档进行分析与检查。又称为静态分析技术，实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行检察，包括：走查、符号执行、需求确认。
动态测试：是指通过人工或者使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

第二种划分：白盒测试、黑盒测试、灰盒测试；

白盒测试：通过对程序内部结构的分析、检测来寻找问题。白盒测试是在清楚了解程序结构和处理过程的基础上，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。又称为结构测试。
黑盒测试：通过软件的外部表现来发现其缺陷和错误，完全不考虑程序内部结构和处理过程，在程序界面处进行测试，只是检查程序是否按照需求规格说明书的规定正常实现。
灰盒测试：介于白盒测试与黑盒测试之间的测试，关注输出对于输入的正确性；同时也关注内部表现，但是这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、时间、标志来判断内部的运行状态。

12、软件测试过程模型

（1）V模型

优点：是瀑布模型的变种，反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确的标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对于关系。

缺点：仅仅把测试过程作为在需求设计、概要设计、详细设计及编码之后的一个阶段，不能体现“尽早地和不断地进行软件测试”的原则。容易使人认为测试时软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而是需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

（2）W模型

在V模型中增加软件各开发阶段应同步进行的测试，被演化为W模型，因为开发是“V”，测试也是与此并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998《软件验证和确认（V&V）》的原则。

局限性：跟V模型一样把软件开发是为需求、设计、编码等一系列串行的活动。同样的，软件开发与测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段，这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要时候补充，或者根本就没有文档的做法下（这已成为一种开发的文化），开发人员和测试人员都面临同样的困惑。

（3）H模型

将测试活动完全独立出来，形成一个独立的流程，将测试准备活动和测试执行活动清晰地表现出来。

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

H模型揭示了：

软件测试不仅仅指测试的执行，还包括很多其他的活动。
软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
软件测试要尽早准备，尽早执行。
软件测试是根据被测物的不同分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

（4）X模型

X模型的目标是弥补V模型的一些缺陷。X模型左边描述的是针对单独程序片段进行的相互分离的编码和测试，此后进行频繁的交接，通过集成最终合成可执行的程序。这一点在图的右上方得以体现，而且这些可执行程序还需要进行测试，已通过测试的成品可以进行封板并提交给用户，也可以作为更大规模和范围内集成的一部分。此外，X模型还定位了探索性测试，即不进行事先计划的特殊类型的测试，诸如“我这么测一下，结果会怎么样”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

（5）前置测试模型

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

开发和测试相结合；
对每一个交付内容进行测试，不仅仅是源程序代码，还包括可行性报告、业务需求说明、系统设计文档等；
在设计阶段进行测试计划和测试设计；
测试和开发结合在一起，在开发阶段以编码—测试—编码—测试的方式实现，也就是说程序片段一旦编写完成，就会立即进行测试；
让验收测试和技术测试保持相互独立。

13、软件测试与软件开发过程的关系

14、软件测试策略

（1）测试信息流

软件配置：包括软件需求规格说明书、软件设计规格说明书、源代码等；
测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程中，测试配置只是软件配置的一个子集；
测试工具：减轻测试的手工劳动，如测试数据的自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。

（2）分析设计阶段

主要包括需求说明书评测、详细设计说明书评测以及软件编码规范评测。

软件编码规范评测主要围绕源程序文档化、数据说明的方法、语句结构和输入输出这四个方面进行。

源程序文档化：符号名的命名、程序注释、标准的书写格式。

数据说明：数据说明的次序应当规范化、说明语句中变量的安排有序化、使用注释说明复杂数据结构。

语句结构：清晰第一，效率第二，不要为了最求效率而丧失了清晰性。

输入输出：输入输出的方式和格式应尽可能方便用户的使用。

（3）开发阶段

单元测试

a、单元测试的内容

模块接口测试：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入给子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配；是否修改了制作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传递。

局部数据结构测试：局部数据结构是最常见的错误来源，局部数据结构测试主要包括不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的却缺省值；变量名拼写错或书写错；不一致的数据类型。可能的话，除局部数据之外的全局数据对木块的影响也需要查清。

路径测试：选择适当的测试用例，对模块中重要的执行路径进行测试。

错误处理测试：要求能遇见出错的条件，并设置适当的出错处理，以便在一旦程序出错是，能对出错程序重做安排，保证其逻辑上的正确性。以下情况表明模块的错误处理功能半酣有错误或缺陷：出错描述难以理解；出错的描述不足以对错误进行定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对粗无进行处理之前，错误条件已经引起系统的干预等。

边界测试：要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。

b、单元测试的步骤

在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。

单元测试的辅助模块：

驱动模块--相当于所测模块的主程序，它接受测试数据，把这些数据传送给所测模块，最后再输出实测结果。

桩模块—也叫做存根模块，用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事都不做。

驱动模块和桩模块的编写会给测试带来额外的开销。因为他们在软件交付时不作为产品的一部分一同交付。为了能够正确地测试软件，桩模块可能需要模拟实际子模块的功能，这样，桩模块的建立就不是很轻松了。

模块的内聚程度高的话，可以简化单元测试的过程。如果一个模块要完成多种功能，且以程序包的形式出现的也不少见，这是就可以把这个模块看成几个小程序，分别进行单元测试，对关键模块还要做性能测试。对支持某些标准规程的程序，更要招收进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

集成测试

集成测试也叫做组装测试或者联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

a、组装时要考虑的问题

在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

一个模块的功能是否会对另一个模块的功能产生不利的影响；

各个子功能模块组合起来，能否达到预期要求的父功能；

全局数据结构是否有问题；

各个模块的误差累计起来，是否会放大，以致达到不能接受的程度。

b、部件测试

子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明书之间的不一致。

c、模块组装成为系统的方式

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

其中，d1,d2,d3,d4,d5是对各个模块做单元测试时建立的驱动模块，s1,s2,s3,s4,s5是为单元测试而建立的桩木块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所有模块连接起来进行测试。但是由于不可避免的存在模块间接口、全局数据结构等方面的问题，所以一次性试运行成功的可能性并不大，其结果是，发现有错误，却茫然找不到原因，查错和改错都会遇到困难。

增值式组装方式：又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题，最后通过增殖逐步组装成为要求的软件系统。包括自顶向下的增殖方式、自底向上的增殖方式、混合增值式测试。

自顶向下的增殖方式：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替他们的直属下属模块，与已测试的模块或子系统组装成新的子系统。然后进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中，是，则结束测试；否则继续执行。

缺点是要建立桩模块，而且建立桩模块的复杂度高，会增加附加的测试；底层模块最容易出问题，如果到组装后期才遇到，就会导致过多的回归测试。

优点是能够较早的发现主要控制方面的问题。

自底向上的增殖方式：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的指数子模块组装成为子系统。然后为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块，是则结束测试，否则继续执行测试。

缺点是主要控制最后才接触到，优点是不需要桩模块，而驱动模块一般叫好建立。

混合增殖式测试：自顶向下的增殖方式和自底向上的增殖方式混合。

d、集成测试计划要考虑的因素

采用何种系统组装方法进行集成测试;

集成测试过程中各个连接模块的顺序;

模块代码编制和测试进度是否与集成测试的顺序一致;

测试过程中是否需要专门的硬件设备;

e、集成测试完成的标识

成功地执行了测试计划中规定的所有集成测试;

修正了所发现的错误;

测试结果通过了专门小组的评审;

测试完成后要提交测试报告，测试报告中药积累实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果，此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终觉得，以提出处理意见。

集成测试要提交的文档包括集成测试计划、集成测试规格说明和集成测试分析报告。

确认测试

确认测试的任务是验证软件的功能与性能及其其他特性是否与用户的要求一致，对软件的功能和性能要求在软件需求规格说明书中明确规定。确认测试一般包括有效性测试和软件配置复查，一般由独立的第三方机构进行。

有效性测试：在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。

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

在确认测试中，还应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查文档资料的完整性和正确性。

系统测试

系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列的测试。目的是通过与系统的需求定义做比较，发现软件与系统定义不符合或者与之矛盾的地方。

验收测试

验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例，使用用户输入界面输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。

（4）软件验证与确认（V&V）过程

软件的V&V）过程是确定按照规定的软件开发过程开发的产品是否符合活动的要求，软件会否满足它的预期用户和用户需要，包括软件产品和过程的分析、评价、评审、审核、评估和测试。

15、软件失效分类

软件错误、软件缺陷、软件故障、软件失效。

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

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

（3）软件故障：是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无适当措施加以即时处理，便会产生软件失效

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

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

软件缺陷第一大来源是产品说明书，第二大来源是设计方案，原因都是片面、多变、理解与沟通不足。

16、缺陷与错误的严重性和优先级

（1）严重级：

严重：系统崩溃、数据跌势、数据毁坏。
较严重：操作性错误、错误结果、遗漏功能。
一般：小问题、错别字、UI布局、罕见故障。
建议：不影响使用的瑕疵或更好的实现。

（2）优先级：

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

17、软件错误跟踪管理

（1）错误跟踪管理

Bug记录信息：测试软件名称、测试版本号、测试人名称、测试事件、测试软件和硬件配置环境、发现软件错误的类型、错误的严重级别、详细步骤、必要的附图、测试注释；
Bug处理信息：处理者姓名、处理时间、处理步骤、错误记录的当前状态；

（2）软件错误的状态

新信息（New）：测试中新报告的软件Bug。
打开（Open）：被确认并分配给相关开发人员处理。
修正（Fixed）：开发人员已完成修正，等待测试人员验证。
拒绝（Declined）：拒绝修改Bug。
延期（Deferred）：不在当前版本修复的错误，下一版本修复。
关闭（Closed）：Bug已被修复。

（3）错误管理流程

测试人员提交新的错误入库，错误状态为“New”。
高级测试人员验证错误。

如果确认是错误，分配给相应的开发人员，设置状态为“Open”。

如果不是错误，则拒绝，设置为“Declined”状态

开发人员查询状态为“Open”的错误，做如下处理：

如果不是错误，则置状态为“Declined”。

如果是错误，则修复并置状态为“Fixed”。

如果不能解决的错误，要留下文字说明并保持错误为“Open”状态。

对于不能解决和延期解决的错误，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

测试人员查询状态为“Fixed”的错误，验证错误是否已解决，做如下处理：

如果问题解决了，置错误状态为“Closed”。

如果问题没解决，则置状态为“Reopen”。

18、自动化测试

自动化测试就是通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动的测试，它是软件测试的一个重要组成部分，它能够完成许多手工无法完成或者难以实现的一些测试工作。

（1）优势：

提高测试质量；

提高测试效率，缩短测试工作时间；

提高测试覆盖率；

执行手工测试不能完成的测试任务；

更好的重现软件缺陷的能力；

更好的利用资源；

增进测试人员与开发人员之间的合作伙伴关系。

（2）适用项目和环境：

需要反复进行的工作；

复杂压力测试；

公司有大量的测试人员和开发人员，他们合作完成一个产品，那么如何在产品的生命周期中进行有效的管理和合作，借助自动化测试管理工具，会取得事半功倍的效果。

如果需要进行测试系统后台或者内部的性能特征，进而进行故障定位和性能调优，自动化测试工具是一个不错的选择。

（3）局限性：定制型项目、周期很短的项目、业务规则复杂的对象、人体感官与易用性测试、不稳定的软件、涉及物理交互。

（4）对自动化测试的不正确的期望

自动化测试可以完成一切测试工作：在显示中有关的测试计划、测试案例以及一些关键的测试任务害死需要人工参与的，即自动化测试时对手工测试的辅助和补充，它永远不可能取代手工测试。
测试工具可适用于所有的测试：每种自动化测试工具都有它的应用范围和可用对象，针对不同的测试目的和测试对象，应该选择合适的测试工具，在很多情况下，需要利用很多测试工具才能完成测试工作。
测试工具能使工作量大幅降低：事实上，引入自动化测试工具不会马上减轻测试工作，相反，在更多情况下，首次将自动化测试工具引入企业时，测试工作实际上变得更艰巨。只有正确合理的使用测试工具，并且有一定的技术积累，测试工作量才能逐渐减轻。
测试工具能实现百分百的测试覆盖率：自动化测试可以增加测试覆盖的深度和广度，但是也不可能进行百分之百的彻底测试。
自动化测试工具容易使用：许多人认为测试工具可以简单地通过捕获（录制）客户端操作生成脚本，且脚本不加编辑就可以用于回放使用。事实上，自动化测试不是那么简单，捕获的操作是否正确以及脚本编辑是否合理都会影响到测试结果，因此，自动化测试需要更多的技能，也需要更多的培训。
自动化测试能发现大量的新缺陷：发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试区发现更多新缺陷，事实上自动化测试主要用于发现老缺陷。

（5）自动化测试工具分类

负载压力测试工具：主要目的是为了度量应用系统的可扩展性和性能，是一种预测系统行为和性能的自动化测试工具。通过模拟成百上千直至上万用户并发执行关键业务，而完成对应用程序的测试，在实施并发负载过程中通过实施性能检测来确认和查找问题，并针对所发现的问题对系统性能进行优化，确保应用的成功部署。负载压力测试工具能够对整个企业架构进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。这类工具的主要代表有LoadRunner、QALoad、SILKOERFORMA V和E-Test Suite等。
功能测试工具：通过自动录制、检测和回放用户的应用操作，将被测系统的输出记录同预先给定的标准结果进行比较，功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同分布版本的功能进行测试，提高测试人员的工作效率和质量。其主要目标是检测应用程序是否能够达到预期的功能并正常运行。功能测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好的进行回归测试。这类工具的代表有WinRunner、QARun等。
白盒测试工具：白盒测试一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又分为静态测试工具和动态测试工具。静态测试工具可以直接对代码进行分析，不需要运行代码，也不需要对代码编译连接和生产可执行文件。静态测试工具一般是对代码进行语法扫描，找到不符合编码规范的地方，根据某种质量模型评价代码的质量，生产系统的调用关系图等，代表工具有Logiscope软件和PRQA软件。动态测试工具与静态测试工具不同，动态测试工具一般采用“插桩”的方式，向代码生产的可执行文件中插入一些检测代码，用来统计程序运行时的数据。其余静态测试工具最大的不同就是动态检测工具要求被测系统实际运行，代表工具有DevPartner、Rational Purify系列等。
网络测试工具：这类工具主要包括网络故障定位工具、网络性能监测工具、网络仿真模拟工具等。他们分析分布式应用性能，关注应用、网络和其他元素（如服务器）内部的交互式活动，以便使网络管理员能够了解网络不同位置和不同活动之间应用的行为。你可以用它在交易执行过程中、web查找和检索或在日常数据库上载/下载中跟踪应用行为。它可以在会话级、代码级，甚至在帧级和包级观察应用的行为过程，并深入代码内部的结构，解析有问题的会话。
测试管理工具：用于对测试进行管理，一般对测试需求、测试计划、测试用例、测试实施进行管理，还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员通过一个重要数据仓库，在不同的地方就能交互信息。测试管理工具将测试过程流水化，从测试需求管理到测试计划、测试日程安排、测试执行到出错后的错误跟踪，实现了全过程的自动化管理。测试管理工具的代表有TestDirector、TestManger、TrarkRecord等。
测试辅助工具：这些工具本身不执行测试，例如生产测试数据，为测试提供数据准备。

19、功能自动化测试

（1）概述

功能测试自动化工具可以帮助测试工程师自动处理测试开发到测试执行的整个过程中的问题。其主要功能就是为了确保应用按照预期设计执行而将业务处理过程记录到测试脚本中。当应用被开发完成或应用升级时，测试工具支持测试脚本的编辑、扩展、执行和报告测试结果，并且保证测试脚本的可重复使用，贯穿于应用的整个生命周期。

对于功能测试工具的使用，比较重要的是测试规划问题。

（2）原理

功能自动化测试工具基本上都是采用录制回放的方式来模拟用户的实际操作。当你在软件操作中点击图形用户界面上的对象时，测试工具会用一种类C或其他脚本语言（TSL）生产一个测试脚本，该脚本记录了你的操作过程，然后测试工具就可以回放刚才的操作。通常情况下，测试工具采取两种录制模式。

（1）环境判断模式

这种模式根据你选取的图形用户界面对象（如窗体、清单、按钮等），把你对软件的操作动作录制下来，并忽略这些对象在屏幕上的物理位置。每一次你对被测软件进行操作，测试脚本语言会记录并描述你选取的对象和你的操作动作。当你进行录制时，测试工具会对你选取的每个对象对唯一描述并写入相应的文件中。当软件用户界面发生改变时，你只需要更小特定的对象记录文件。这样一来，环境判断模式的测试脚本将非常容易地被重复使用。执行测试只需要回放测试脚本。回放时，测试工具从指定文件中读取对象描述，并在被测软件中查找符合这些描述的对象并模拟用户使用鼠标选取该对象、用键盘输入数据的操作。

（2）模拟模式

这种模式记录鼠标点击、键盘输入和鼠标在二维平面上（x轴和y轴）的精确运动轨迹。执行测试时，测试工具让鼠标根据轨迹运动。这种模式对于那些需要追踪鼠标运动的测试非常有效，例如画图软件等。

不管采用何种模式，功能自动化测试必须经历以下几个操作步骤：

创建脚本：可以通过录制、编程或者两者同用的方式创建测试脚本。
调试脚本：脚本录制或编辑结束后，你可以先在调试模式下运行脚本，并可以设置断点来检测变量，控制对象识别和隔离错误。
执行测试：脚本调试结束后，便可以在检测模式下测试被测软件。
结果分析:每次测试结束，测试工具都会把测试情况显示在测试结果报告中。测试结果报告会详细描述测试执行过程中发生的所有主要事件，如检查点、错误信息、系统信息或用户信息。

20、负载压力自动化测试

（1）什么是负载测试和压力测试？

负载测试是为了证明在与产品（预期）规模等同的数据库中处理给定的事务请求的容量下，系统功能与性能是否与需求规格说明书中规定的，可接受的响应时间一致的测试过程。
而压力测试则是使客户机在大容量情况下运行的测试过程，目的是查看应用将在何时何处出现中断，即识别系统的薄弱环节。可能暴露的系统缺陷有内存泄露、系统资源过量消耗、磁盘空间用完等。

（2）负载压力测试工具可以记录下客户端的操作，并以脚本的方式保存，然后建立多个虚拟用户，在一台或者几台PC机上模拟上百或上千虚拟用户同时操作的情景，同时记录下每一事务处理的响应时间、中间件服务器资源使用、数据库负载等，测试工程师可以根据测试结果分析系统瓶颈。

负载测试是任何Web应用的开发周期中一个重要的步骤。

（3）测试原理

负载压力测试工具基本上都是采取录制回放的方式来模拟用户的实际操作的。而且测试工具一般都会有一个后台代理进程，通过该代理进程，测试工具可以监视并获取在各种通信协议下应用系统的客户与服务器端的通信信息，测试工具会用一种类C或者其他脚本语言（TSL）生成一个测试脚本，该脚本记录了你对服务器的请求过程，然后测试工具就可以回放刚才的访问过程，接受服务器的响应，当然，也可以手工编程生成这个脚本。