软件测试理论汇总

/> 1.   什么是软件测试，以及软件测试的意义？
       软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。编码和单元测试属于软件生存期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，这是软件生存期的另一个独立阶段，即测试阶段。
      软件测试的意义：
a.发现软件错误  b.有效定义和实现软件成分由低层到高层的组装过程
c.验证软件是否满足任务书和系统定义文档所规定的技术要求  d. 为软件质量模型的建立提供依据；
2． 什么是软件测试静态分析，软件测试动态分析？
      静态分析，是相对动态说的，即不运行程序。
      白盒测试一般会用到静态分析和动态分析两类技术，常用的有：
                  静态分析：控制流分析、数据流分析、信息流分析、检查表、代码走读，需求文档评审。
                  动态分析：逻辑覆盖测试（分支测试、路径测试等）、程序插装等。
      静态测试和动态测试的区别在于是否需要运行被测软件。代码走读最主要的目标是要发现缺陷，遗漏和矛盾的地方；改进产品；和考虑可替换的实现方法。 具体为：
a.静态测试是用于预防的，动态测试是用于矫正的；b.多次的静态测试比动态测试要效率和效益高；c.静态测试综合测试程序代码；
d.在相当短的时间里，静态测试的覆盖度能达到100%，而动态测试经常是只能达到50%左右，原因是动态测试发现的bug大部分只是在测试实际执行的那部分代码；e.动态测试比静态测试更花时间；f.静态测试的执行可以在程序编码编译前，动态测试只能在编译后才能执行；g.静态测试能发现动态测试所不能发现的一些:"Syntaxerror,code that hard to maintain,code that hard totest,code that does not confirm to coding standard, and ANSI violations（语法错误，难以维护的代码，难以校验的代码，不确定编码标准和ANSI违规的代码 ）"。
3． 针对缺陷采取怎样的管理措施？
1)   预测此缺陷会导致什么错误现象属于几级严重度 (如果是一级/致命严重度 立即反馈研发人员,让他们有足够时间进行软件的修改)
2)   进行定位分析，分析是由哪个模块引起的
3)   建议如何进行修改
4)   考虑其他缺陷是否因为这个缺陷所引起
5)   要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
6)   根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
7)   所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。
8)   缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
4． 在测试生命周期，测试过程分为几个阶段，以及各个阶段的含义？  
      大体上来说可分为单元测试，集成测试，系统测试，验收测试，每个阶段又分为以下五个步骤:测试计划，测试设计，用例设计，执行结果，测试报告
      初始测试集中在每个模块上，保证源代码的正确性，该阶段称为单元测试，主要用白盒测试方法。
      然后是模块集成和？集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。主要采用黑盒测试方法，辅之以白盒测试方法。
      软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。
1    单元测试
      单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
2    集成测试
      集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
3    系统测试
      系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
4    验收测试
      验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。
回归测试  回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
5、 软件的缺陷等级应如何划分？
1)      致命错误（fatal）：造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异                                       常等问题。
2)      严重错误（critical）：功能和特性没有实现导致严重的问题或致命的错误声明。问题局限在本模块，导致模块功能失效或异常退出
3)      一般错误（major）：次要功能丧失，提示信息不太准确，或用户界面差，操作时间长、模块功能部分失效等。
4)      建议问题（suggestion）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
6、 如果能够执行完美的黑盒测试，还需要进行白盒测试吗？为什么？
       黑盒测试：从用户角度出发，根据规格说明设计测试用例，并不涉及程序的内部特性和内部结构，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试有两个显著特点：
（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以用。
（2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。
      黑盒测试主要是为了发现以下几类错误：
1、是否有不正确、遗漏或额外的功能实现？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
      白盒测试：已知程序的内部结构，检查内部操作是否按规定执行。主要对程序细节进行严密检验，针对特定条件和循环设计测试用例，对程序的逻辑路径进行测试。通过在程序的不同点检查程序状态，确定实际状态是否与预期的状态一致。
      白盒测试主要是想对程序模块进行如下检查：
1、程序的所有语句至少执行一次。
2、对所有的逻辑条件都能至少执行一次。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
      从以上可以看出就算执行了完美的黑盒测试也是无法测试程序内部特定部位，另外当规格说明本身有误，也不能发现问题。而白盒测试能对程序的内部特定部位进行覆盖测试，所以黑盒和白盒测试为互补关系，结合起来进行测试用例的设计更为合理。
      经验表明，通常在进行单元测试时采用白盒测试方法，集成测试采用灰盒测试方法，系统测试采用黑盒测试方法。
7、 测试计划的目的是什么？
      软件测试计划是指导测试过程的纲领性文件，包含了产品概述，测试策略，测试方法，测试区域，测试配置，测试周期，测试资源，风险分析等内容；借助软件测试计划，参与测试的项目成员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。
      测试计划和测试用例间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围，方法和资源配置；而测试用例是完成测试任务的具体战术。
8、 针对缺陷采取怎样的管理措施？
1.  要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
2.  根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
3.  所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。
4.  缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
5.  为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
9、区别阶段评审的与同行评审
同行评审目的:发现小规模工作产品的错误，只要是找错误;
阶段评审目的:评审模块阶段作品的正确性、可行性及完整性。
同行评审人数:3-7人，人员必须经过同行评审会议的培训，由SQA指导；
阶段评审人数:5人左右，评审人必须是专家，具有系统评审资格。
同行评审内容:内容小，一般文档 < 40页， 代码 < 500行；
阶段评审内容: 内容多，主要看重点。
同行评审时间:一小部分工作产品完成；
阶段评审时间: 通常是设置在关键路径的时间点上。
10、简述集成测试的过程
      系统集成测试主要包括以下过程：
1. 构建的确认过程。
2. 补丁的确认过程。
3. 系统集成测试测试组提交过程。
4. 测试用例设计过程。
5. 测试代码编写过程。
6. Bug的报告过程。
7. 每周/每两周的构建过程。
8. 点对点的测试过程。9. 组内培训过程。
11、怎么做好文档测试
仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例；检查文档的编写是否满足文档编写的目的；
内容是否齐全，正确；内容是否完善标记是否正确
12、白盒测试有几种方法
      总体上分为静态方法和动态方法两大类。
静态：关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义
动态：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。  
13、系统测试计划是否需要同行审批，为什么
      需要，系统测试计划属于项目阶段性关键文档，因此需要评审。
14、Alpha测试与beta的区别
      Alpha测试是在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
      Beta测试当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。这种测试一般由程序员或测试员完成，不能由最终用户或其它人员完成。
15、比较负载测试，容量测试和强度测试的区别
负载测试：在一定的工作负荷下，系统的负荷及响应时间。
强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统                 在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理                 的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且                 它的目的是显示系统可以处理目标内确定的数据容量。
16、 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。
白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径                 进行测试。
单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
集成测试：在单元测试的基础上，对单元模块之间的连接和组装w进行测试。
系统测试：在所有都考虑的情况下，对系统进行测试。
验收测试：第三方进行的确认软件满足需求的测试。
17. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1．等价类划分
2．边界值分析法
3．错误推测法
4．因果图方法

http://www.cnblogs.com/droidpilot/archive/2012/04/27/2473185.html

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

      从软件开发的过程按阶段划分有: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	就是对需求，设计工件进行审核

软件测试步骤
　1 测试计划
　书写测试用例
　开发测试代码
　开展测试工作（往往需要进行几次轮测包括测试和复测，每次对于测试中的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.稳定性测试

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