软件测试方法单元测试白盒黑盒集成测试系统测试验收测试可编辑优质文档.docx

软件测试方法单元测试白盒黑盒集成测试系统测试验收测试可编辑优质文档.docx

《软件测试方法单元测试白盒黑盒集成测试系统测试验收测试可编辑优质文档.docx》由会员分享，可在线阅读，更多相关《软件测试方法单元测试白盒黑盒集成测试系统测试验收测试可编辑优质文档.docx（13页珍藏版）》请在冰点文库上搜索。

软件测试方法单元测试白盒黑盒集成测试系统测试验收测试可编辑优质文档

1.

测试目的

●以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。

●尽早尽多的发现软件中存在的各种错误和缺陷

●在软件部署之前，解决软件中存在的各种错误和缺陷

●证明软件的功能和性能与需求说明相符合。

●实施测试收集到的测试结果数据为可靠性分析提供了依据

●提高软件的质量

2.测试的基本类型和方法

一．单元测试

1白盒测试：

由负责该模块的程序员负责，利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

主要对程序模块进行如下的检查：

对程序模块的所有独立的执行路径至少测试一次；

对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；

在循环的边界和运行界限内执行循环体；

测试内部数据结构的有效性，等。

出现错误做回归测试—对修改后的单元执行回归测试

2黑盒测试：

由测试设计人员设计合理的测试用例，程序员或测试人员负责测试。

主要着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。

黑盒测试主要是对被测试对象进行如下测试项目：

1、测试程序单元的功能是否实现；

2、测试程序单元性能是否满足要求（可选）；

3、可选的其它测试特性，如边界、余量、安全性、可靠性、强度测试、人机交互界面测试等。

黑盒测试达到的目标：

程序单元正确地实现了需求和设计上要求的功能，满足性能要求，同时程序单元要有可靠性和安全性。

二．集成测试：

集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。

它所测试的内容包括单元间的接口以及集成后的功能。

使用黑盒测试方法测试集成的功能。

并且对以前的集成进行回归测试。

集成测试需求所确定的是对某一集成工作版本的测试的内容，即测试的具体对象。

集成测试需求主要来源于设计模型（DesignModel）和集成构件计划（IntegrationBuildPlan）。

集成测试着重于集成版本的外部接口的行为。

因此，测试需求须具有可观测、可测评性。

1．集成工作版本应分析其类协作与消息序列，从而找出外部接口。

2．由集成工作版本的外部接口确定集成测试用例。

3．测试用例应覆盖工作版本每一外部接口的所有消息流序列。

注意：

一个外部接口和测试用例的关系是多对多，部分集成工作版本的测试需求可映射到系统测试需求，因此对这些集成测试用例可采用重用系统测试用例技术。

三．系统测试

系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。

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

系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性

系统测试类型和目标

确定系统测试策略首先应清楚地说明所实施系统测试的类型和测试的目标。

清楚地说明这些信息有助于尽量避免混淆和误解（尤其是由于有些类型测试看起来非常类似，如强度测试和容量测试）。

测试目标应该表明执行测试的原因。

系统测试的测试类型一般包括：

功能测试：

验证软件是否提供了所期待的服务。

包括：

“主要”方案--所有的输入是合法的。

“辅助”方案--一些或所有的输入是不合法的。

性能测试：

包括响应时间，并发性，吞吐量，处理精度等

负载测试：

测试一个应用在重负荷下的表现，例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。

强度测试：

•资源少的情况下发现可能的错误

●低内存

●磁盘空间

•共享资源竞争的情况下发现可能的错误

⏹系统资源

⏹数据库加锁

⏹网络带宽

容量测试：

使软件经受大数据量的考验，以确定达到限制时是否引发软件失败

配置测试：

测试软件所需要的环境，包括：

软件和硬件

安装测试：

是否能正确安装？

初次安装

升级安装

完全安装

定制安装

安全测试：

验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。

安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

用户界面测试：

根据详细设计式样，检测用户界面是否符合式样书规定。

其中，功能测试、配置测试、安装测试等在一般情况下是必需的。

而其它的测试类型则需要根据软件项目的具体要求进行裁剪。

四．验收测试：

软件产品评测部对经过项目组内部单元测试、集成测试和系统测试后的软件所进行的测试，测试用例采用项目组的系统测试用例子集，或者由验收测试人员自行设计。

工作步骤：

1软件产品评测部按项目管理规定成立项目验收测试小组、确定验收测试费用。

如果是产品开发项目，产品评测部同时应根据项目技术可行性报告完成可测试性报告。

2验收测试小组负责参与项目阶段评审，并对测试工件的质量进行评估。

3验收测试小组在开发组的协助下，对项目组提交的软件产品进行验收测试。

3．测试的过程

●制定测试计划

●设计测试

●实施测试

●执行单元测试

●执行集成测试

●执行系统测试

●评估测试

●测试活动产生的工件

具体的测试过程，详见图1

图1：

测试过程详细图解

1制定测试计划

目的

•收集和组织测试计划信息，并且创建测试计划。

时机

•软件项目计划已确定

输入工件

•软件项目计划

•软件需求工件

步骤

•确定测试需求

•制定测试策略

•建立测试通过准则

•确定资源和进度

•评审测试计划

•更新测试计划

输出工件

•软件测试计划

2设计测试

目的

•为每一个测试需求确定测试用例集，并且确定执行测试

用例的测试过程。

时机

•软件需求规格被基线化

输入工件

•软件测试计划

•软件需求工件

•软件构架设计

•软件详细设计

•界面原型（可选）

步骤

•设计测试用例

对每一个测试需求，确定其需要的测试用例。

对每一个测试用例，确定其输入及预期结果。

确定测试用例的测试环境配置、需要的驱动界面或稳定桩。

编写测试用例文档

对测试用例进行同行评审

•开发测试过程

根据界面原型为每一个测试用例定义详细的测试步骤

为每一测试步骤定义详细的测试结果验证方法。

为测试用例准备输入数据。

编写测试过程文档

对测试过程进行同行评审

在实施测试时对测试过程进行更改。

•设计驱动程序或稳定桩

设计单元测试和集成测试需要的驱动程序和稳定桩。

输出工件

•测试用例

•测试过程

3实施测试

目的

•创建可重用的测试脚本，并且实施测试驱动程

序和稳定桩。

时机

•软件单元已实施/工作版本已集成

输入工件

•测试用例

•测试过程

•软件单元或工作版本

步骤

•开发测试脚本（可选）—根据测试过程创建测

试脚本，并且调试测试脚本。

•编写驱动程序和稳定桩—根据设计编写测试需

要的测试驱动程序和稳定桩。

输出工件

•测试脚本（可选）

•测试驱动程序和稳定桩

4执行单元测试

目的

•验证单元的内部结构以及单元实现的功能。

时机

•软件单元已实施

输入工件

•测试过程

•测试用例

•软件单元

步骤

•执行单元测试—按照测试过程手工执行单元测

试或运行测试脚本自动执行单元测试。

•记录单元测试结果—将单元测试结果作详细记

录，并将测试结果提交给相关组。

•回归测试—对修改后的单元执行回归测试

输出工件

•测试结果

5执行集成测试

目的

•验证单元之间的接口以及集成工作版本的功

能、性能等。

时机

•软件工作版本已集成

输入工件

•测试过程

•测试用例

•软件集成工作版本

步骤

•执行集成测试—按照测试过程手工执行集成测

试或运行测试脚本自动执行集成测试。

•记录集成测试结果—将集成测试结果作详细记

录，并将测试结果提交给相关组。

•回归测试—对修改后的工作版本执行回归测

试，或者对增量集成后的版本执行回归测试。

输出工件

•测试结果

6执行系统测试

目的

•确认软件系统满足软件需求。

时机

•软件系统已集成

输入工件

•测试过程

•测试用例

•软件系统

步骤

•执行系统测试—按照测试过程手工执行系统测

试或运行测试脚本自动执行系统测试。

•记录系统测试结果—将系统测试结果作详细记

录，并将测试结果提交给相关组。

•回归测试—对修改后的软件系统执行回归测

试。

输出工件

•测试结果

7执行评估测试

目的

•对每一次测试结果进行分析评估，在每一个测

试阶段提交测试分析报告。

时机

•已生成了测试结果

输入工件

•测试结果

步骤

•分析测试结果—由相关组对每一次测试结果进行分析，

并提出变更请求或其他处理意见。

•分析阶段测试情况

对每一个阶段的测试覆盖情况进行评估。

对每一个阶段发现的缺陷进行统计分析。

确定每一个测试阶段是否完成测试。

对每一个阶段生成测试分析报告。

输出工件

•测试分析报告

•变更请求

4．测试停止的标准

1测试停止的标准：

●软件系统经过单元，集成，系统测试，分别达到单元，集成，系统测试停止的标准；

●软件系统已经过验收测试，并已得出验收测试的结论；

●软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据；

●软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或中止时，测试应随之暂停，并备份暂停点数据；

2单元测试停止标准

1）单元测试用例设计已经通过评审

2）按照单元测试计划完成了所有规定单元的测试

3）达到了测试计划中关于单元测试所规定的覆盖率的要求

4）被测试的单元每千行代码必须发现至少3个错误

5）软件单元功能与设计一致

6）在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准

3集成测试停止标准

1）集成测试用例设计已经通过评审

2）按照集成构件计划及增量集成策略完成了整个系统的集成测试

3）达到了测试计划中关于集成测试所规定的覆盖率的要求

4）被测试的集成工作版本每千行代码必须发现2个错误

5）集成工作版本满足设计定义的各项功能、性能要求

6）在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准

4系统测试停止标准

1）系统测试用例设计已经通过评审

2）按照系统测试计划完成了系统测试

3）达到了测试计划中关于系统测试所规定的覆盖率的要求

4）被测试的系统每千行代码必须发现1个错误

5）系统满足需求规格说明书的要求

6）在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准

黑盒测试用例总结：

黑盒测试中，测试者通过输入大量的测试用例，来检测程序的功能和性能是否达到要求