测试详细分类、测试流程、测试阶段、测试模型、测试工具

测试详细分类

角度细分

从是否关心软件内部结构和具体实现的角度划分（按测试分类）

A.白盒测试

B.黑盒测试

C.灰盒测试

从是否执行程序的角度

A.静态测试

B.动态测试。

阶段细分

从软件开发的过程按阶段划分有

A.单元测试

B.集成测试

C.确认测试

D.系统测试

E.验收测试

F.回归测试

G.Alpha测试

H.Beta测试

* 测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发布测试。

* 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

*集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。

* 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。

* 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。

单元测试 (Unit Testing)

* 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

* 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

1. 单元测试的内容

* 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。

(1) 模块接口测试

* 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：

– 调用本模块的输入参数是否正确；

– 本模块调用子模块时输入给子模块的参数是否正确；

– 全局量的定义在各模块中是否一致

* 在做内外存交换时要考虑：

– 文件属性是否正确；

– OPEN与CLOSE语句是否正确；

– 缓冲区容量与记录长度是否匹配；

– 在进行读写操作之前是否打开了文件；

– 在结束文件处理时是否关闭了文件；

– 正文书写/输入错误，

– I/O错误是否检查并做了处理。

(2) 局部数据结构测试

* 不正确或不一致的数据类型说明

* 使用尚未赋值或尚未初始化的变量

* 错误的初始值或错误的缺省值

* 变量名拼写错或书写错

* 不一致的数据类型

* 全局数据对模块的影响

(3) 路径测试

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

* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

* 对基本执行路径和循环进行测试可以发现大量的路径错误。

(4) 错误处理测试

* 出错的描述是否难以理解

* 出错的描述是否能够对错误定位

* 显示的错误与实际的错误是否相符

* 对错误条件的处理正确与否

* 在对错误进行处理之前，错误条件是否已经引起系统的干预等

(5) 边界测试

* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。

2. 单元测试的步骤

* 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。

– 驱动模块 (driver)

– 桩模块 (stub) ── 存根模块

* 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。

* 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

集成测试（Integrated Testing）

* 集成测试 (组装测试、联合测试）

* 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：

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

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

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

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

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

在单元测试的同时可进行集成测试，

发现并排除在模块连接中可能出现

的问题，最终构成要求的软件系统。

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

* 通常，把模块集成成为系统的方式有两种

– 一次性集成方式

– 增殖式集成方式

1. 一次性集成方式(big bang)

* 它是一种非增殖式组装方式。也叫做整体拼装。

* 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。

2. 增殖式集成方式

* 这种集成方式又称渐增式集成

* 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统

* 在集成的过程中边连接边测试，以发现连接过程中产生的问题

* 通过增殖逐步组装成为要求的软件系统。

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

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

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

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

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

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

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

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

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

(3) 混合增殖式测试

* 衍变的自顶向下的增殖测试

– 首先对输入/输出模块和引入新算法模块进行测试；

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

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

* 自底向上-自顶向下的增殖测试

– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试；

– 然后对含写操作的子系统做自顶向下的组装与测试。

* 回归测试

– 这种方式采取自顶向下的方式测试被修改的模块及其子模块；

– 然后将这一部分视为子系统，再自底向上测试。

关键模块问题

* 在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。

* 关键模块的特征：

① 满足某些软件需求

② 在程序的模块结构中位于较高的层次（高层控制模块）

③ 较复杂、较易发生错误

④ 有明确定义的性能要求。

确认测试（Validation Testing）

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

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

1. 进行有效性测试（黑盒测试）

* 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。

* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。

* 通过实施预定的测试计划和测试步骤，确定

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

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

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

* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：

– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。

– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。

2. 软件配置复查

n 软件配置复查的目的是保证

u 软件配置的所有成分都齐全；

u 各方面的质量都符合要求；

u 具有维护阶段所必需的细节；

u 而且已经编排好分类的目录。

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

系统测试（System Testing）

* 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

* 系统测试的目的在于通过与系统的需求定义作比较， 发现软件与系统的定义不符合或与之矛盾的地方。

验收测试（Acceptance Testing）

* 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。

* 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。

* 由用户参加设计测试用例，使用生产中的实际数据进行测试。

* 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

*确认测试应交付的文档有：

– 确认测试分析报告

– 最终的用户手册和操作手册

– 项目开发总结报告。

测试流程

测试流程

1、制定测试计划

2、编辑测试用例

3、执行测试用例

4、发现并提交BUG

5、开发组修正BUG

6、对已修正BUG进行返测

7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活

测试阶段

测试阶段

单元测试

单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：模块。

集成测试

集成测试也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。

系统测试

系统测试 主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。

回归测试

回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。

与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。

测试模型

V模型

测试阶段:

单元测试

集成测试

系统测试

实现意义

V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。

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

左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。

用户需求 验收测试

需求分析和系统设计 确认测试和系统测试

概要设计 集成测试

详细设计 单元测试

编码

软件测试V模型

V模型问题

1.测试是开发之后的一个阶段。

2.测试的对象就是程序本身。

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

4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度

W模型

W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

软件测试

H模型

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

软件测试

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

H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备， 尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

X模型

X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

测试工具

Test Platform软件测试平台，简称TP，是业界唯一的对软件测试全过程进行支撑的软件测试工具。

业界已有的软件测试工具基本上都局限在测试执行阶段，只能支撑测试执行阶段的活动，而测试分析、测试设计、测试实现这三个前期阶段的活动缺乏有效的测试工具支撑，直接影响了软件测试的完整性和充分性，从而影响最终研发的软件质量。David.yuan这样说：企业使用了博为峰TP测试平台，整个软件测试过程的 测试覆盖率提高到前所未有的高度和广度，可以极好的达成软件在安全性、健壮性、稳定性和功能、性能方面的要求，即使是没有很多年测试经验的管理和测试人员，通过TP测试平台就可以完成智能化地管理、设计、分析、执行整个测试过程，达到一流测试管理专家所做到的效果。

引入缺陷分析模型

在业界首先将各种有效的缺陷分析模型引入到该软件平台中，包括ODC分析、Gompertz分析、Rayleigh分析、四象限分析、缺陷注入分析、DRE/DRM等工程方法，帮助管理者建立软件研发过程的质量基线、测试能力基线，并帮助管理者将项目实际缺陷、能力数据和基线数据进行对比分析，发现软件过程中的改进点，判断测试是否可以退出、软件是否可以发布，并对软件中残留缺陷数进行预测；

利用理论框架分析

建立了测试分析和设计的理论框架和一整套工程方法，能够很好的支撑测试的辅助分析和设计；

建立测试跟踪关系

建立“开发需求项－>测试项－>测试子项－>测试用例－>缺陷”的测试跟踪关系，能够及时的反应开发需求和设计的变更对测试的影响范围，保证软件的一致性和测试的充分性，从而保证软件的质量；

使用TestPlatform

能够全面的管理软件质量工作，具有高度的集成性，一款TestPlatform能够完成多款其他各类的相关质量管理工具集成在一起才能完成的软件质量管理工作。它集成了需求跟踪、静态测试、动态测试、测试人员管理、测试环境管理、测试计划管理、测试用例管理、缺陷管理、缺陷分析等软件质量相关的流程。

AutoRunner是国内第一款自动化测试工具，可以用来完成功能测试、回归测试、每日构建测试与自动回归测试等工作。是具有脚本语言的、提供针对脚本完善的跟踪和调试功能的、支持IE测试和Windows native测试的自动化测试工具。

TestCenter是一款功能强大测试管理工具，它可以帮助您：实现测试用例的过程管理，对测试需求过程、测试用例设计过程、业务组件设计实现过程等整个测试过程进行管理。实现测试用例的标准化即每个测试人员都能够理解并使用标准化后的测试用例，降低了测试用例对个人的依赖；提供测试用例复用，用例和脚本能够被复用，以保护测试人员的资产；提供可伸缩的测试执行框架，提供自动测试支持；提供测试数据管理，帮助用户同意管理测试数据，降低测试数据和测试脚本之间的耦合度。

TAR(Terminal AutoRunner)适用于VT100、VT220等标准的应用系统，支持命令行模式和窗口模式（使用Cursors编写的应用程序），支持自动录制脚本、所见即所得的资源和脚本编辑，稳定的自动同步功能。是目前国内最好的银行业务测试工具.

TestDirector是全球最大的软件测试工具提供商Mercury Interactive公司生产的企业级测试管理工具，也是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。