软件测试基本理论

软件测试概念：通过各种手段和测试工具，判断软件系统是否能够满足预期期望。

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

  A.单元测试 B.集成测试 C.确认测试 D.系统测试 E.验收测试

  * 测试过程按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 应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。

  验收测试（Acceptance Testing）

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

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

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

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

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

  – 确认测试分析报告

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

  – 项目开发总结报告。

  系统测试（System Testing）

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

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

 

软件工程模型
　谈起测试学，不得不讨论一下软件工程模型，因为测试学与软件工程学的发展依依相关，相辅相成。另外对于比较先进的测试理念，测试工程师应该贯穿于软件工程的整体过程之中。

　瀑布模型
　这个模型大概是现在最经典的软件工程模型，业务建模-〉系统分析-〉概要设计-〉详细设计-〉编码-〉测试-〉部署。
但是这个模型存在着比较严重的问题：

　1，不可反复，不适应与需求变更处理：由于瀑布模型从业务建模到部署一脉相承，不可以回复。现代软件项目中需求变更是无处不存在的：唯一不变的就是需求变更。而运用这种模型，只要项目需求发生变化，就要打翻重新进行系统分析，概要设计，详细设计…

　2，用户很难在项目初期了解项目状态：由于用户在项目初期很难提出自己的需求，他们有时候也不知道该做些啥？而利用瀑布模型只有到编码结束，用户才可以看到正正他们所需要的产品，而初期这些产品往往是他们所了解不全的，需要补充的，客户往往在这个时期推翻他们的需求，要求另立需求，这样往往给客户方，需求方带来比较麻烦的结果。

　迭代模型和螺旋模型：
　这两个模型往往在概念上区别不明显，许多书上将这两个模型混为一谈。其实这两个模型的思想本质上是一致的。他将客户的需求按照用户的重要等级和模块自身的等级，从最基础的进行分析，设计，编码，测试，然后再进入下一轮迭代。这样用户可以在每一轮结束就可以看到产品的一些雏形，进行需求变更和下一轮的建议，由于初期开发工作比较少，用户又可以在产品初期提出相对可观的下一轮的需求，所以这样的模型往往利于现在软件公司产品的开发，著名的RUP工具每一项都遵循迭代的思想。

　测试模型

　V模型
　单元测试相对于编码进行，这一步往往由测试人员来执行；
　集成测试相对于详细设计，他将模块由上到下，由下到上进行逐步的集成。以测试模块与模块，类与类之间的关联性；
　系统测试是相对于总体设计而言的，测试人员站在用户的角度对系统进行全面的测试工作；
　接收测试是用户对产品进行测试，一般分为Alpha测试和Beta测试。Alpha测试一般由公司内部的非技术人员或非参与人员对产品进行的测试；Beta测试往往是指定客户对公司进行测试，是系统推出市场之前，测试阶段推出的第二个版本。

　V模型可以运用于瀑布模型和迭代模型
　X模型
　X模型是将软件系统分为罗干模块，对每个模块进行单元，集成以及系统测试，然后统一对模块进行集成测试，这种测试方法目前软件行业处于淘汰趋势。

　前置模型
　图示中所列出的是面向对象的前置模型，其他编成方法的前置模型大小意，就是将测试贯穿于软件开发的全部过程。在需求，设计和编码阶段对产生的工件进行复审，提出自己的建议和意见。对于前置软件测试法，bug在软件前期就可以发现从而降低软件开发成本。

　不利用前置方法的bug曲线。
　利用前置方法的bug曲线,bug在开始之前就能够被发现。
　软件测试方法

	白盒	黑盒
动态	就是利用KDE的调试功能逐步调试程序，进行测试	就是普通所说的通过人工或者自动方法进行测试
静态	即test review	就是对需求，设计工件进行审核

软件测试步骤
　测试计划
　书写测试用例
　开发测试代码
　开展测试工作（往往需要进行几次轮测包括测试和复测，每次对于测试中的bug，要求开发人员给与明确答复修改完毕，非法bug以及下一版中解决）

　2 评估测试
　软件测试类型

　1.数据和数据库完整性测试
　在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。

　2.功能测试
　对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：

　3.UI测试
　用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化测试。

　4.性能测试
　4.1负载测试：
　负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

　4.2强度测试
　是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

　4.3容量测试
　容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。

　4.4基准测试：与已知系统的比较　

4.5竞争测试
　软件竞争使用各种资源（数据纪录，内存等）

　5. 安全性和访问控制测试
　安全性和访问控制测试侧重于安全性的两个关键方面：
　应用程序级别的安全性，包括对数据或业务功能的访问
　系统级别的安全性，包括对系统的登录或远程访问。
　应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一” 能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。

　6.故障转移和恢复测试
　可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。

　恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。

　7.配置测试
　配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本。OS版本等）

　8.安装测试
　安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。

　9.本地化测试
　又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。

　10.文字测试
　测试文字是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否由出入等等，包括图片文字

　11.分辨率测试
　测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试

　12发布测试
　主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试

　12.1说明书测试
　主要为语言检查，功能检查，图片检查
　语言检查：检查说明书语言是否正确，用词是否易于理解；
　功能检查：功能是否描述完全，或者描述了并没有的功能等；
　图片检查:：检查图片是否正确

　12.2宣传材料测试
　主要测试产品中的附带的宣传材料中的语言，描述功能，图片

　12.3帮助文件测试
　帮助文件是否正确，易懂，是否人性化

软件的杀虫剂现象　由于测试人员的思路不尽相同，每个人测试的侧重点不同，由于都按照测试用例进行测试，但是测试用例一般仅描述系统的一些基本测试项，不会将所有的测试用例方方面面都写到，有时还需要测试人员的经验和素质。所以A测试某个产品用了七个工作日，第一天到第四天报出许多bug,但从第五天开始几乎报不出啥 bug了。七天后换了B,B一下子又测试出一堆bug,不能说A的水平差，只能说，该产品已经对A产生了抗药性，这就是测试学中的杀虫剂现象。　所以在测试中每次轮流测试最好安排不同的测试人员进行不同模块测试工作，以避免杀虫剂现象产生。

1．什么是测试？

IEEE定义:使用人工或自动化来测试某个程序,来验证它是否满足规定的需求或者实际结果和预期结果之间的差别.

简单定义:找出软件中的BUG

2．为什么要测试？

在软件开发过程中容易出现缺乏有效沟通,软件复杂,编程错误,需求不断变更,时间的压力,缺乏文档的代码,软件开发工具和人员的自大等原因引发的错误,通过测试能够找出其中的错误,解决错误,从而提高软件的质量.

3．测试的目的是什么？

证明软件没有问题(20世纪60年代)

发现软件中的错误(20世纪70年代)

验证软件与需求是否一致的一系列活动(现在)   提高软件质量

4．软件的生命周期分为哪几个阶段？具体的内容是什么？

计划：确定软件开发总目标；给出软件各方面的设想；研究可行性和解决方案；给出评估计划；指定完整的实施计划

需求分析：对开发软件进行详细定义，给出《需求规格说明书》SRS

设计：在设计阶段把各项需求转换成相应的体系结构，给出概要设计

编码：将软件设计成计算机能识别的语言，给出《详细设计》

测试：检测软件是否符合用户需求

运行：将软件交付给用户使用

评价：用户对软件的好与坏给出判定

5．研发团队的组织架构与研发流程是什么？

瀑布模型 螺旋模型 RUP模型 IPD 模型

6．测试阶段怎么划分？

测试计划阶  段测试设计阶  段测试实施阶  段测试执行阶段

7．什么是UT,IT,ST？它们有什么区别？

单元测试：对软件的基本组成单元来进行正确性检验，目的在于检测软件模块对《详细设计说明书》的符合程度，属于白盒测试，

          测试范围为单元内部的数据结构，逻辑控制，异常处理

评估标准为逻辑覆盖率

集成测试：测试模块或子系统组装后功能以及模块间接口是否正确，目的在于检测软件模块对《概要设计说明书》的符合程度。

         属于灰盒测试，测试范围为模块之间接口与接口数据传递的关系，以及模块组合后的功能，

评估标准为接口覆盖率

系统测试：将被测软件系统和计算机硬件，数据库，外设，人员以及其它软件结合在一起，在实际运行环境下对计算机系统进行的一系列的组装测试和确认测试。

          目的在于检测软件对《需求规格说明书》的符合程度。属于黑盒测试，测试范围为整个系统，

评估标准为测试用例对需求规格的覆盖率

8．什么是回归测试？为什么要回归测试？回归测试的流程是什么？回归测试的测试策略有哪些？

回归测试：是软件维护阶段，对缺陷进行修复后的测试。

目的在于：验证缺陷已经得到修复，检测是否引入新的缺陷

流程：1.在测试策略制定阶段,制定回归测试策略

      2.确定需要回归测试的版本

      3.测试版本发布后,按照回归测试策略来执行回归测试

      4.回归测试通过,关闭缺陷跟踪单

      5.回归测试不通过,缺陷跟踪单返回给开发人员,开发人员重新修改BUG.再次提交给测试人员回归测试

测试策略：1.完全重复测试：重新执行前期设计的用例，来确认问题修改的真确性和修改的扩散局部影响性

          2.选择性重复测试：

             1）覆盖修改法：针对被修改的部分,选取或重新构造测试用例验证没有错误再次发生的选择方法

             2）周边影响法：该方法包括覆盖修改法,还要分析修改后对扩散的影响

              3）指标达成法：先确定一个达成的指标,基于这种要求选择一个最小的测试用例集合

13．测试的方法有哪些？

按是否使用工具：人工测试   自动化测试

按软件是否运行：静态测试  动态测试

按测试的重点：白盒测试  黑盒测试  灰盒测试

14．什么是白盒测试？

依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试。

15．什么是黑盒测试?      

把测试对象看做一个黑盒，只考虑整体特性，不考虑内部具体实现

16．什么是静态测试？

不运行被测软件系统，而采用其他手段和技术对被测软件进行检测的一种技术

17．什么是动态测试？

运行被测软件系统的测试

18．什么是人工测试?

测试活动由人来完成，狭义上指测试执行由人工完成。

19．什么是自动化测试？

通过计算机模拟人的测试行为，替代人的测试活动，狭义上指测试执行由计算机来完成

20．逻辑覆盖关注的内容是哪些？

逻辑覆盖测试

  语句覆盖  条件覆盖  判定覆盖  路径覆盖   判定-条件覆盖

21．常见的黑盒测试方法有哪些？

 等价类划分法   边界值分析法  因果图分析法  判定表法  正交试验法  状态迁移法

25．       什么是缺陷管理？引入的原因有哪些？

缺陷管理的目的： 保证信息的一致性；保证缺陷得到有效跟踪，解决；

    获取正确的Bug信息，用作缺陷分析和产品度量。      

引入原因：

1.开发过程中缺乏有效沟通，或者没有沟通 2.软件负责度越来越高

3.编程中产生的错误 4.需求不断变更 5.项目进度的压力

6.不重视开发文档 7.软件开发工具本身隐藏的问题

33．系统测试的类型有哪些？

1.功能测试

  概念：根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品需求规格

  目标：1.是否有遗漏需求。2.是否正确的实现所有功能

3.隐示需求在系统是否实现 4.输入，输出是否正确

2.性能测试

  概念： 用来测试软件在集成系统中的运行性能

  目标： 度量系统相对于预定义目标的差距

3.压力测试

     压力测试：在一定的软硬件及网络环境中，通过模拟大量的用户执行多种业务处理大量数据，使系统在极限环境下长时间运行，目的在于寻找系统的失效点

    负载测试：在一定的软硬件及网络环境下，通过模拟不同的用户，执行一种或多种业务，观察系统在不同负载下的性能表现。

  目标： 通过极限测试方法，发现系统在极限或恶劣的环境中自我保护能力，主要验证系统的可靠性

4.容量测试

  概念： 使系统承受超额的数据容量来发现它是否能够正确处理

  目标：是面向数据的，显示系统可以处理目标内确定的数据容量

5.安全性测试

  概念：用来验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入。

  目标：通过安全性测试，来检查系统的功能性是否完善

6.GUI测试

  概念：指界面的外形是否与设计内容一致

7.可用性测试

  概念：检测用户在理解和使用系统方面到底有多好？

8.安装测试

  概念： 检测软件在安装过程中的错误

  目标：不仅仅找安装软件本身的错误，还要找到安装文档的错误。

9.配置测试

  概念： 测试系统在各种软硬件配置，不同的参数配置下系统具有的功能和性能

  目标：验证全部配置的可操作性和有效性，特别需要对最大配置，最小配置和特殊配置进行测试

10.异常测试（恢复性测试）

  通过人工干预手段使系统发生软，硬件异常，通过验证系统异常前后的功能和运行状态，达到检验系统容错，排错和恢复的能力

11.备份测试

  验证系统在软件或者硬件的事件中备份它数据的能力

12.健壮性测试

  用于测试系统在出现故障时，是否能够自动恢复或忽略故障继续运行

13.文档测试

  验证用户文档是否正确的并且保证操作手册的过程能够正确工作

14.在线帮助测试

  验证系统的实时在线帮助的可用性和正确性

15.网络测试

  在网络环境下和其他设备对接，进行系统功能，性能与指标方面的测试，保证设备对接正常

16.稳定性测试

  评价系统在一定负荷情况下，长时间的运行情况