单元测试

单元测试

单元测试是在软件开发过程中要进行的最低级别的测试活动，针对软件设计的最小单元——模块。

目标：

验证代码是与设计相符合的；

跟踪需求与设计的实现；

发现设计和需求中存在的缺陷；

发现在编码过程中引入的错误。

单元测试与集成测试的区别：

测试对象不同。单元测试对象是实现了具体功能的程序单元；集成测试对象是概要设计规划中的模块及模块间的组合。

测试方法不同。单元测试中的主要方法是基于代码的白盒测试；集成测试中主要使用基于功能的黑盒测试。

测试时间不同。集成测试晚于单元测试。、

测试内容不同。单元测试主要是模块内程序的逻辑、功能、参数传递、变量引用、出错处理及需求和设计中具体要求方面的测试；集成测试主要验证各个接口、接口之间的数据传递关系，及模块组合后能否达到预期效果。

单元测试与系统测试的区别：

单元测试输入白盒测试，从开发者的角度出发，关注的是单元的具体实现、内部逻辑结构和数据流向；系统测试属于黑盒测试，从用户角度出发，证明系统已满足用户的需要。

单元测试使问题及早暴露，便于定位解决，属于早期测试；系统测试是一种后期测试，定位错误比较困难。

单元测试允许多个被测单元同时进行测试；系统测试时基于需求规格说明书的。

单元测试环境

需要用到一些辅助模块来模拟与被测模块相联系的其他模块：

驱动模块：相当于被测模块的主模块。

桩模块：用于代替被测模块调用的子模块

单元测试策略 自顶向下的单元测试策略

从最顶层开始，把顶层调用的单元用桩模块代替，对顶层模块做单元测试。

对第二层测试时，使用上面已测试的单元做驱动模块，并为被测模块编写新的桩模块。

以此类推，直到全部单元测试结束。

优点：可以在集成测试之前为系统提供早期的集成路径。

缺点：随着单元测试的进行，测试过程会变得越来越复杂。因为改变任何一个单元时，就必须重新测试该单元下层调用的所有单元。

自底向上的单元测试策略

先对模块调用图上最底层的模块进行测试，使用驱动模块来代替调用它的上层模块。

对上一层模块进行单元测试时，用已经测试的模块做桩模块，并为被测模块编写新的驱动模块。

以此类推，直到全部单元测试结束。

优点：无需单独设计桩模块；无需依赖结构设计；可为系统提供早期的集成途径。

缺点：随着单元测试的不断进行，测试过程会变得越来越复杂，测试周期延长，测试和维护的成本增加。

孤立测试

这种测试不考虑每个模块与其他模块之间的关系，分别为每个模块单独设计桩模块和驱动模块，逐一完成所有单元模块的测试。

综合测试

考虑自底向上测试策略与孤立测试策略相结合的综合测试策略。

测试重点

模块接口：首先应对通过模块接口的数据流进行测试，如果数据不能正确的进出，所有其他测试都是不切实际的。测试参数的数目、次序、属性或单位系统与变元是否一致；是否修改了只作输入用的变元；全局变量的定义和用法在各个模块中是否一致。

局部数据结构：应该仔细设计测试方案， 以便发现局部数据说明、初始化、默认值等方面的错误。

独立路径：保证模块中每条语句至少执行一次。使用基本路径测试和循环测试有助于发现程序中因计算错误、比较不正确、控制流不适当而造成的错误。

出错处理通路：好的设计应该能遇见出现错误的条件，并且设置适当的处理错误的通路，以便在真的出现错误时执行相应的出错通路或干净的结束处理。

边界条件：软件时常会在边界上失败，边界测试运用边界值分析技术对边界值及其左右设计测试用例，可以帮助发现错误。

集成测试 简介

集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

集成测试测试组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。一个有效的集成测试有助于解决相关的软件与其它系统的兼容性和可操作性的问题。

集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。

目标

集成测试的目标是按照设计要求使用那些通过单元测试的构件来构造程序结构。单个模块具有高质量但不足以保证整个系统的质量。有许多隐蔽的失效是高质量模块间发生非预期交互而产生的。以下两种测试技术是用于集成测试：

1）功能性测试。使用黑盒测试技术针对被测模块的接口规格说明进行测试。

2）非功能性测试。对模块的性能或可靠性进行测试。

另外，集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

集成测试是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。

实施

集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：

1、是采用何种系统组装方法来进行组装测试；

2、组装测试过程中连接各个模块的顺序；

3、模块代码编制和测试进度是否与组装测试的顺序一致

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

解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。

在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应测试应安排在这些设备能够投入使用之时，并需要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例、生成程序等）的准备情况。

单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。对子系统，集成测试也叫部件测试。

任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。

完成标准

怎样判定集成测试过程完成了，可按以下几个方面检查：

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

2、修正了所发现的错误；

3、测试结果通过了专门小组的评审。

集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。

在完成预定的组装测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。

集成测试过程

根据IEEE标准 集成测试划分为4个阶段：计划阶段，设计阶段，实现阶段，执行阶段（实施阶段）

计划阶段

1）时间安排 概要设计完成评审后大约一个星期

2）输入 需求规格说明书 概要设计文档 产品开发计划路标

3）入口条件 概要设计文档已经通过评审

4）活动步骤 1.定被测试对象和测试范围 2.评估集成测试被测试对象的数量及难度，即工作量 3.确定角色分工和作任务4.标识出测试各阶段的时间，任务，约束等条件5.考虑一定的风险分析及应急计划6.考虑和准备集成测试需要的测试工具，测试仪器，环境等资源7.考虑外部技术支援的力度和深度，以及相关培训安排8.定义测试完成标准

5）输出集成测试计划

6）出口条件 集成测试计划通过概要设计阶段基线评审

设计阶段

1）时间安排详细设计阶段开始

2）输入需求规格说明书概要设计集成测试计划

3）入口条件概要设计基线通过评审

4）活动步骤 1.被测对象结构分析 2.集成测试模块分析3.集成测试接口分析4.集成测试策略分析5.集成测试工具分析6.集成测试环境分析7.集成测试工作量估计和安排。

5）输出集成测试设计（方案）

6.出口条件集成测试设计通过详细设计基线评审。

实现阶段

1）时间安排在编码阶段开始后进行

2）输入需求规格说明书概要设计集成测试计划集成测试设计

3）入口条件详细设计阶段

4）活动步骤：1.集成测试用例设计2.集成测试代码设计（如果需要）3.集成测试脚本（如果需要）4.集成测试工具（如果需要）

5）输出集成测试用例集成测试规程集成测试代码集成测试脚本集成测试工具

6）出口条件测试用例和测试规程通过编码阶段基线评审

执行阶段

1）时间安排单元测试已经完成后就可以开始执行集成测试了

2）输入 需求规格说明书概要设计集成测试计划集成高度设计集成测试例集成测试规程集成测试代码（如果有）集成测试脚本集成测试工具详细设计代码单元测试报告

3）入口条件单元测试阶段已经通过基线化评审

4）活动步骤执行集成测试用例回归集成测试用例撰写集成测试报告

5）输出集成测试报告

6）出口条件集成测试报告通过集成测试阶段基线评审

注：集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。

系统测试

系统测试是将已经继承好的软件系统，作为计算机系统的一个元素，与计算机硬件、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试。

系统测试的目标是：通过与系统的需求规格说明进行比较，检查软件是否存在与系统规格说明不符合或与之矛盾的地方，从而验证软件系统的功能和性能等满足规格说明所制定的要求。

系统测试分析

用户层：围绕用户界面的规范性、友好性、可操作性、系统对用户的支持，以及数据的安全性等方面展开。另外，用户层的测试通常还应注意可维护性测试和安全性测试。

应用层：主要是针对产品工程应用或行业应用的测试。从应用软件系统的角度出发，模拟实际应用环境，对系统的兼容性、可靠性等进行测试。针对整个系统的应用层测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。

功能层：检测系统是否已经实现需求规格说明中定义的功能，以及系统功能之间是否存在类似共享资源访问冲突的情况。

子系统层：针对产品内部结构性能的测试。

协议/指标层：针对系统所支持的协议，进行协议一致性测试和协议互通测试。

系统测试的方法

功能测试：功能测试属于黑盒测试，是系统测试中最基本的测试。功能测试主要根据产品的需求规格说明和测试需求列表，验证产品是否符合需求规格说明。

协议一致性测试：主要用于分布式系统。在分布式系统中，很多功能的实现是通过多台计算机相互协作来完成的，这要求计算机之间能相互交换信息，所以需要制定一些规则（协议）。对协议进行测试，通常包括：协议一致性测试、协议性能测试、协议互操作性测试、协议健壮性测试。

性能测试：主要用于实时系统和嵌入式系统，性能测试是指测试软件在集成系统中的运行性能，目标是量度系统的性能和预先定义的目标有多大差距。一种典型的性能测试是压力测试，当系统同时接收极大数量的用户和用户请求时，需要测量系统的应对能力。性能测试要有工具的支持，在某种情况下，测试人员必须自己开发专门的接口工具。

压力测试：又称强度测试，是在各种超负荷的情况下观察系统的运行情况的测试。

容量测试：在系统正常运行的范围内测试并确定系统能够处理的数据容量。容量测试是面向数据的，主要目的就是检测系统可以处理目标内确定的数据容量。

安全性测试：安全性测试就是要验证系统的保护机制是否抵御入侵者的攻击。保护测试是安全性测试中一种常见的测试，主要用于测试系统的信息保护机制。评价安全机制的性能与安全功能本身一样重要，其中安全性的性能主要包括：有效性、生存性、精确性、反应时间、吞吐量。

失效恢复测试：验证系统从软件或者硬件失效中恢复的能力。失效恢复测试采用各种人为干预方式使软件出错，造成人为的系统失效，进而检测系统的恢复能力。如果恢复需要人为干预，则应考虑平均修复时间是否在限定的范围内。

备份测试：备份测试是失效恢复测试的补充，目的是验证系统在软件或者硬件失效的实践中备份其数据的能力。

GUI测试：GUI测试与用户友好性测试和可操作性测试有重复，但GUI测试更关注对图形界面的测试。GUI测试分为两个部分，一方面是界面实现与界面设计的情况要符合；另一方面是要确认界面能够正确处理事件。GUI测试设计测试用例一般要从以下4方面考虑：

（1）划分界面元素，并根据界面的复杂性进行分层。通常把界面划分为三个层次，第一层是界面原子层；第二层是界面组合元素层；第三层是一个完整的窗口。

（2）在不同的界面层次确定不同的测试策略。

（3）进行测试数据分析，提取测试用例。

（4）使用自动化测试工具进行脚本化工作。

健壮性测试：又称容错测试，用于测试系统在出故障时，是否能够自动恢复或者忽略故障继续运行。健壮性测试的一般方法是软件故障插入测试，在软件故障插入测试中，需要关注三个方面：目标系统、故障类型和插入故障的方法。

兼容性测试：检验被测的应用系统对其他系统的兼容性。

易用性测试：与可操作性类似。检测用户在理解和使用系统方面是否方便。易用性测试是面向用户的系统测试，包括对被测系统的系统功能、系统发布、帮助文本和过程等的测试。最好在开发阶段就开始进行。

安装测试验证成功安装系统的能力。

文档测试：主要是针对系统提交给用户的文档进行验证。文档测试的目标是验证用户文档的正确性并保证操作手册的过程能正常工作。

在线帮助测试：用于检验系统的实时在线帮助的可操作性和准确性。

数据转换测试：目标是验证已存在数据的转换并载入一个新的数据库是否有效。

系统测试的实施

确认测试：又称有效性测试。其任务就是确认软件的有效性，即确认软件的功能和性能及其它特性是否与用户的要求一致。这一阶段要做的主要工作是进行功能测试和软件配置复审。

Alpha和Beta测试：Alpha测试是用户在开发环境下进行的测试，也可以是产品供应商内部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用，开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制环境下进行的测试。Beta测试是由多个用户在一个或多个用户的实际使用环境下进行的测试。通常是在不受控制的环境下进行的测试，开发者通常不在现场。用户记录在测试过程中遇到的一切问题（真实的或想象的），并且定期把这些问题报告给开发者。

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

回归测试： 在软件变更之后，对软件重新进行的测试。其目标是检验对软件进行的修改是否正确，保证改动不会带来不可预料的行为或者另外的错误。

系统测试问题总结、分析

问题严重级别划分如下：

致命问题——对应于系统的可用性。

严重问题——用于分析系统版本稳定性。

一般问题——用于评估测试效率。

提示问题——用于产品的完善性指标。

验收测试 1. 验收测试简介 1.1简介

验收测试即由产品开发方按照新浪提供的需求文档中所有内容（或按合同及其它有效约定，对方承诺实现的需求）进行开发、内测完毕，提交版本符合验收测试标准，通过新浪质量保证部进行的测试。通过验收测试判断产品质量是否符合产品需求，功能实现是否正确并可以最终上线。

1.2角色定义

验收提交方：产品研发方

验收接收方：质量保证部

2. 验收测试目的

通过验收测试判断产品质量是否符合产品需求、功能实现是否正确，性能和安全性方面是否符合发布标准，并且产品可以最终上线。

3. 验收测试版本 3.1测试版本命名

提交验收测试的产品版本统一按如下格式命名：产品名称_版本_ATx 各部分释义如下：

产品名称：提交测试的产品名称，例如“易享收藏夹”（）

版本：提交测试的产品版本号，例如“1.0.1”

ATx：其中“AT”表示 ；“x”表示提交验收测试的次数后，如1、2、3等

示例： .0.1_AT1（表示“易享收藏夹”第一次提交验收测试的版本）

3.2测试版本保存

每次提交验收测试的版本统一保存至新浪主体产品的版本库中，上线版本以验收测试通过版本为准。

4. 验收测试范围 4.1界面测试

所有页面浏览，连接的正确、所有功能按钮及界面显示正确

4.2功能测试

所有需求文档描述的功能实现正确

4.3性能测试

重点业务功能、性能能满足上线运营需求

4.4安全性测试

接口和数据调用等方面符合安全性规范；没有安全性漏洞

5. 验收测试流程

验收测试基本工作流程如下：

5.1. 准入条件检测

5.1.1文档

进入验收测试的文档准备齐全：

a) 验收版本的需求文档（提交方提供）：要求需求文档与最终提交验收测试的程序完全匹配 ；

b) 验收版本的测试用例（提交方提供）：要求测试案例覆盖最终版本的需求文档；

c) 验收版本的测试告（提交方提供）：在测试报告书中说明测试总体情况，缺陷列表及修复情况；

5.1.2缺陷

要求开发方在 IE6 /IE7/.x兼容环境中（该兼容性需求会根据项目情况有变动，以新浪要求的为准），对需要文档上提及的所有功能进行全面测试，且提交验收测试时，开发方发现的所有缺陷都已解决。

5.1.3测试环境

验收测试环境准备完成，与线上真实环境一致

我方项目负责人负责测试环境控制，保证测试期间环境一致、稳定

5.1.4沟通和联系