软件测试之【单元测试、系统测试、集成测试】_电影销售系统 集成测试和系统测试报告

优点：这个方法比较简单，最容易操作，可以达到很高的结构覆盖率，可以并行开展，该方法是纯粹的单元测试。

缺点：桩函数和驱动函数工作量很大，效率低。

**2、自顶向下的单元测试策略（Top Down Unit Testing）**

方法：先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对第二层进行测试，使用上面已经测试过的单元做驱动模块，以此类推，直到测试完所有模块。

优点：可以节省驱动函数的开发工作，效率高。

缺点：随着被测单元一个一个被加入，测试过程将变得越来越复杂，并且开发和维护的成本将增加。

**3、自底向上的单元测试策略（Bottom Up Unit Testing）**

方法：先对最底层的模块进行单元测试，将模拟调用该模块的模块设置为驱动模块，然后再对上面一层做单元测试，用下面已经测试好的模块做桩模块，以此类推，直到测试完所有模块。

优点：可以节省桩函数的开发工作量，测试效率较高。

缺点：不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大影响。

##  六、系统测试的概念


**系统测试（****System Testing****）的定义：**将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）的环境下，对计算机系统进行一系列的组装测试和确认测试。


**系统测试的对象：**软硬件集合在一起的系统，集成后的产品，不应是独立的软件与硬件环境。不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设，甚至包括某些数据、某些支持软件的系统等。


**目的：**通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方，以验证软件的功能和性能等满足其规约所指定的要求。


**常见的系统分类：**


纯软件：QQ.................


软件和硬件：手机，PSP，空调，电梯


软件硬件和维护人员：大型系统


## 七、系统测试的环境


**真实环境：**直接将整个系统和其交联的物理设备真实的建立链接，进行测试


优点：可以发现某些只能在真实环境下出现的问题


缺点：构建这样一个环境需要高昂的费用，它的测试运行也需要高昂的费用


**仿真环境：**它能够逼真的模拟被测试软件运行所需的真实物理环境的输入与输出，并且能够组织被测软件的输入，来驱动被测软件运行，同时接收被测软件的输出结果。


优点：仿真环境和真实环境的软件依赖是一样的，并且它能够保证测试的可重复性、完整性、可扩展性



**Example 1****：**某系统环境搭建的要求


硬件环境：


CPU：主频2GHZ以上，4核及以上


内存：4GB及以上


硬盘：可用空间10G以上


软件环境：


平台要求：Windows XP/2003标准版+Apache2.2.X+Mysql5.0及以上版本


目录权限：目录/Attachment，/Cache及文件需要写的权限


推荐平台：推荐使用XAMPP作为安装介质



**选用测试工具应考虑的因素：**


1.测试工具与被测软件系统的匹配程度


2.测试工具提供的主要功能和辅助机制


3.测试工具的服务和技术支持


4.测试工具的价格



**测试数据：**


**特点：**


1.数据可以以消息、事物、记录、文件等形式存在


2.数据来源很多


3.真实数据最好，但在很多情况下不易或者不能得到


**来源：**


1.产品数据


2.手工构造数据


3.生成数据（一般由工具设备构造）


4.捕获数据（少用，与捕获数据源有关，允许手工修改）


5.随机数据（系统测试少用，它易于获得，不够真实，性能测试常用）


**产品数据**


1.最具真实性


2.不能覆盖所需所有场景


3.数据敏感，很难保证正确性


4.随时间变化


5.可能数据量太大（从而降低测试执行速度）


**手工构造数据**


1.费时间、枯燥


2.如果对系统的功能缺乏了解，数据不真实


3.有时是获得特定测试用例所需独特数据的唯一手段


**生成数据**


1.一般由工具或设备构造


2.数据取决于工具的完善程度和测试人员的关于如何构造数据的规格说明


**捕获数据**


1.与捕获数据源无关


2.允许手工修改


**随机数据**


1.易于获得，不够真实


2.对强度或负载测试是非常有用的


## 八、系统测试的类型


**常见的测试类型：**


功能测试（配置测试、恢复性测试、备份测试）


性能测试（压力测试、稳定性测试、容量测试）


GUI测试（可用性测试）


兼容性测试


安全性测试（网络测试）


安装性测试


文档测试



**功能测试**


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


目标:


1.是否有不正确或者遗漏了的功能（做错或少做）


2.功能实现是否满足用户需求和系统设计的隐藏需求


3.能否正确的接受输入，能否正确的输出结果


功能测试步骤：


1.对每个明确的功能需求进行标号


2.对每个隐含的功能需求进行标号


3.对可能出现的功能异常进行分类分析并且标号


4.把功能划分为关键功能和非关键功能


5.对每个功能进行测试分析，分析其是否可测，如何测试，可能的输入、输出


6.脚本化和自动化



**性能测试**


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


目标: 度量系统各项指标，确认系统有无各种性能瓶颈


特点：混合白盒测试和黑盒测试的方法


性能测试考虑的两个方面:


1.验证系统实现的性能是否与性能需求完全一致


2.检测系统实现的具体性能到底怎样


常用方法：探针，测试驱动


常用工具：Loadrunner,WebLoad,SilkPerformer



**GUI****测试**


概念：针对软件系统界面进行的测试


目标：1.测试界面实现与界面设计的吻合情况   2.确认界面处理的正确性


关注点：界面层与功能接口层上（GUI系统分为三个层次：界面层、界面与功能的接口层、功能层）


常用工具：QTP，QARun



**兼容性测试**


概念：考虑被测试软件在其他软件（例如操作系统）或硬件设备下的运行情况。


目标：1.与辅助软件的结合情况（操作系统，其他应用程序，测试软件，监控软件，浏览器等）；  2.与硬件设计的结合情况（由于兼容性测试对硬件要求较多，一般无特殊要求都只会针对软件要求做测试）。



**安全性测试**


概念：验证集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入，用来保护数据本身的完整性和保密性。广义的还包括物理安全和业务安全。


范围：主要从几个方面考虑：系统登录，用户管理，防火墙，系统数据，WEB安全，数据库安全，内部通讯，系统防毒测试等。


保护测试是安全测试中的一种常见的测试，主要用于测试系统的信息保护机制



**安装性测试**


概念：主要依据软件的测试特征列表、软件安装、配置文档、设计安装过程的测试用例，发现软件在安装过程中的错误。


目标：找出软件安装的错误，安装手册的错误。


安装测试前所要做的检查工作：


1.安装文档是否齐全


2.安装软件的程序文件是否齐全


3.被测试的安装文件是否齐全


4.软件的文件格式是否与安装指导中的要求的文件格式相符


常用自动化安装测试软件：Total Uninstall:它能够监视软件安装的所有过程，记录下它对系统所做的任何改变FileRiver:可以自动监视和准确记录下多个文件夹中的文件以及子文件的细微变化。



**文档测试**


概念：主要针对软件需求说明书，安装手册，配置指南等文档，测试内容主要是编写规范，内容正确性，无歧义性，完整性。


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


## 九、系统测试的过程


**测试阶段的划分**


系统测试计划阶段：完成系统测试计划（规划和步骤）


系统测试设计阶段：完成系统测试方案


系统测试实现阶段：完成系统测试用例，系统测试规程，系统测试预测试（冒烟测试）项


系统测试执行阶段：执行系统测试预测试，系统测试用例，开展回归测试，校验已修复的问题，提交系统预测试报告，系统测试报告，缺陷报告



过程：软件需求分析、设计（概要）、系统测试（执行）




|  |  |  |  |  |
| --- | --- | --- | --- | --- |
| **阶段** | **入口准则** | **输入** | **出口准则** | **输出** |
| **计划** | SRA完成 成立了需求规格基准 | 软件开发计划 软件测试计划、SRS | 系统测试计划评审并通过 | 系统测试计划 |
| **设计** | 系统测试计划评审并通过 | 系统测试计划、SRS | 系统测试方案评审并通过 | 系统测试方案 |
| **实现** | 系统测试方案评审并通过 | 系统测试计划 系统测试方案、SRS | 系统测试用例 系统测试规程 系统测试预测试项评审并通过 | 系统测试用例 系统测试规程 系统测试预测试项 |
| **执行** | 系统测试用例、系统测试规程、系统测试预测试项评审并通过，集成测试执行结束 | 系统测试计划 系统测试方案 系统测试用例 系统测试规程 系统测试预测试项 | 系统测试报告评审并通过 | 系统预测试报告 系统测试报告 缺陷报告 |



**系统测试中的角色及职责**


开发代表：解决资源需求，对系统测试结果进行监督


QA：系统测试过程质量保证，参与相关评审，对过程进行审计


配置管理组：对系统测试文档，及测试代码等相关配置进行配置管理


**软件开发组：**


1.系统测试计划阶段，提供软件开发计划SDP，参与系统测试计划的评审


2.系统测试设计和实现阶段，提供SRS，需求分析，测试建议，响应系统测试需求，参与软件系统测试方案的评审


3.系统测试执行阶段，跟踪解决软件测试项目组的缺陷问题报告单，参与系统测试报告的评审


**软件测试组：**


1.系统测试计划阶段，制定系统测试计划并组织评审


2.系统测试设计和实现阶段，制定软件测试方案并组织评审，按照软件系统测试方案，实现测试用例，测试代码和测试工具等设计，编写测试规程


3.系统测试执行阶段，执行系统测试，反馈并跟踪缺陷问题报告单，完成系统测试报告并组织评审，输出测试案例、总结等经验文档


**系统分析组：**


1.提出系统测试需求


2.进行测试需求跟踪


3.进行软件系统可测性分析，确定系统测试的对象、范围和方法



**系统测试计划的要点**


1.明确系统测试的被测对象


2.完成系统测试的需求跟踪


3.明确系统的通过或失败标准


4.系统测试的挂起标准及恢复的必要条件


5.明确系统测试工作任务分配


6.系统测试结束后应交付的工作产品


**系统测试设计的要点**


1.测试环境和测试数据的准备


2.测试工具的开发/场景设计


3.系统测试用例设计


4.测试策略的选择（如：测试几轮）



**系统测试方案和系统测试计划的区别**


**系统测试计划：**对系统测试全过程的组织、资源、原则等进行规定和约束，并制定系统测试全过程各个阶段的任务以及时间进度安排，并提出对各项任务的评估、风险分析和管理需求。


**系统测试方案：**描述系统需要测试的特性，测试的方法，测试环境的规划，测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。（设计测试方法的细节文档）


**注：**案需要在系统测试计划的指导下进行，系统测试计划提出做什么，而系统测试方案明确提出“如何做”



**系统测试执行概述**


1.按一定的系统测试计划，依据系统测试用例，完成测试的各项操作任务


2.根据系统测试方案，搭建系统测试环境是系统测试执行的一个重要步骤，测试环境时候与否会严重影响测试结果的真实性和正确性


3.系统测试执行阶段应完成：环境准备、测试操作、测试记录、测试报告


4.执行的时间安排：在集成测试执行完成之后进行系统测试的执行



**系统测试预测试**


目的：验证软件系统基本功能或预测主要的系统功能，以确保其后的系统测试执行能够顺利进行。


时间安排：系统预测试应在开发项目组提出软件版本转系统测试申请后进行，主要是完成转系统测试评审需要输入的《软件系统与测试报告》。


人员安排：执行验证软件基本功能活动的主体可以是软件开发项目组也可以是软件测试项目组或联合的组织。



**转系统测试评审**


1.评审责任的主体为软件项目测试组，需要完成软件转系统测试评审表


2.软件版本转系统测试通过后，才能启动执行系统测试过程


3.启动执行系统测试过程后，系统预测试相关的软件版本，测试代码，文档，环境等均应在配置管理中基线化



**系统测试报告写作和评审**


1.依据系统测试计划的测试通过准责，结束系统测试后，撰写系统测试报告


2.系统测试报告需要通过评审，责任人为软件测试项目组，由软件开发项目组，配置管理小组和QA参与


3.评审不通过，系统测试报告退回。在评审不符合项和问题解决后再提交评审申请，或重新启动系统测试过程


4.评审通过后，系统测试相关文档、代码、工具等均需跟随软件代码，开发文档一起完成配置基线化，系统测试过程结束



**系统测试日报的写作目的**


1.测试人员总结每天的测试工作，便于了解自己的测试进度和测试情况，用以调整下一天的工作计划


2.测试人员对被测对象每天给出评估结果，用以调整后续工作的测试策略


3.测试人员向测试经理反映测试中的困难，保证测试的顺利进行


4.测试经理通过测试日报，了解每个工作人员的测试进度，把握测试的整体进度，发现进度上的风险及时调整计划


5.测试经理通过测试日报，了解各模块缺陷发展的趋势，判断测试是否可以退出


6.开发经理可以通过软件测试日报了解当前软件的质量情况，并可以调整缺陷修改的人力资源、


7.如果软件有多个测试组并行测试，测试日报可以提供彼此测试交流的手段



**系统测试步骤**


需求分析 -> 计划、方案 -> 用例设计 -> 环境搭建 -> 执行 -> 测试报告


需求分类： 1. 项目需求（用户自己提需求） 2．产品需求（产品人员进行调查撰写）


基线：第一种说法：软件版本相对稳定  第二种说法：文档经过多次评审修改之后封存起来，任何人需求修改都要提出申请。


## 十、集成测试概念

1.集成测试也叫组装测试、联合测试、子系统测试或部件测试。

2.集成测试是在单元测试的基础上，将所有模块按照概要设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

## 十一、集成测试的目的

1.找出模块接口以及整体体系结构上的问题；

2.确保各组件组合在一起后能够按照既定意图协作运行，并确保增量的行为正确；

3.集成测试属于灰盒测试；

		1)验证接口是否与设计相符合；
		
		2)发现设计和需求中存在的错误。

## 十二、集成测试关注的重点


一些模块虽可以单独正常工作，但不能保证连接起来也能正常工作，程序在某些局部反映不出来的问题，在全局上就很有可能暴露出来，影响功能的实现。


因此，集成测试应当考虑一下两个问题：


#### 1.模块间的接口（需要考虑的有两点）

	1)在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
		
	2)全局数据结构是否有问题，会不会被异常修改。

#### 2.集成后的功能（需要考虑三点）

	1)各个子功能组合起来，能否达到预期要求的父功能；
		
	2)一个模块的功能是否会对另一个模块的功能产生不利的影响；
		
	3)单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

## 十三、集成测试的层次


一个产品的开发过程包括了一个分层的设计和逐步细化的过程，从最初的产品到最小的单元可以划分为：产品——>子系统——>硬件子系统、软件子系统——>软件模块——软件程序——>单元。


一般单元测试针对最小的单元结构，系统测试对应于产品级，而当中的所有各层测试都需要通过集成测试来完成，由于集成的力度不同，因此将集成测试划分为3个级别：

1.模块内集成测试（单元测试完成后）
	
2.子系统内集成测试，即模块间集成测试

3.子系统间集成测试

## 十四、集成测试策略


集成测试策略是在测试对象分析的基础上，描述软件模块集成（组装）的方式、方法，分类如下：


#### 1.大爆炸集成（Big Bang Integration）

是属于非增值式集成（Non-Incremental Integration）的一种方法，也叫一次性组装或整体拼装。该集成把所有系统组件一次性集合到被测系统中，不考虑组件之间的相互依赖性或者可能存在的风险。应用一个系统范围内的测试包来证明系统最低限度的可操作性。

1)方法(策略)
	a.在这种集成方式中，首先对每个模块分别进行单元测试
	b.然后再把所有单元组装在一起进行测试		
	c.最后得到要求的软件系统
		
2)目的
	在最短时间内把系统组装出来，并且通过最少的测试来验证整个系统
		
3)优点
	a.在有利的情况下，大爆炸集成可以迅速完成集成测试，并且只要极少数的驱动和桩模块设计（如果需要的话）;
	b.它需要的测试用例也是很少的;
	c.该方法比较简单；
	d.多个测试人员可以并行工作，对人力，物力资源利用率较高。

4)缺点
	a.这种一次性组装方式试图在辅助模块的协助下，在模块单元测试的基础上，将所测模块连接起来进行测试，但是由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大;
	b.在发现错误的时候，其问题定位和修改都比较困难;
	c.即使被测系统能够被一次性集成，但还是会有很多接口错误很容易的躲过测试而进入到系统范围测试内。

5)适用范围
	a.维护型项目（或功能增强型项目），其以前的产品已经很稳定，并且新增的项目只有少数几个组件被增加和修改；
	b.被测系统比较小，并且它的每个组件都经过了充分的单元测试；
	c.产品使用了严格的净室软件工程过程，并且每个开发阶段的质量和单元测试质量都非常高。

#### 2.自顶向下的集成策略（Top-Down Integration）

采用了和设计一样的顺序对系统进行测试，在第一时间内对系统的控制接口进行了验证。

1)方法（策略）
	 a. 以主模块为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块替换，对主模块进行测试；
	 b.采用深度优先（Depth-First）或者宽度优先（Breath-First）的策略，用实际模块替换相应桩模块，再用桩替代它们的直接下属模块，与已测试的模块或子系统组装成新的子系统；
     c.进行回归测试，排除组装过程中引起的错误的可能；
	 d.判断所有的模块是否都已组装到系统中?如果是，则结束测试，否则转到b步骤去执行。
		
2）目的
	从顶层控制开始，采用同设计顺序一样的思路对被测系统进行测试，以验证系统的接口稳定性。
		
3）优点
	a.自顶向下的增殖方式在测试过程中较早的验证了主要的控制和判断点;
    b.功能可行性较早得到证实，还能够给开发者和用户带来成功的信心;

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

经过了充分的单元测试；
c.产品使用了严格的净室软件工程过程，并且每个开发阶段的质量和单元测试质量都非常高。

#### 2.自顶向下的集成策略（Top-Down Integration）

采用了和设计一样的顺序对系统进行测试，在第一时间内对系统的控制接口进行了验证。

1)方法（策略）
	 a. 以主模块为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块替换，对主模块进行测试；
	 b.采用深度优先（Depth-First）或者宽度优先（Breath-First）的策略，用实际模块替换相应桩模块，再用桩替代它们的直接下属模块，与已测试的模块或子系统组装成新的子系统；
     c.进行回归测试，排除组装过程中引起的错误的可能；
	 d.判断所有的模块是否都已组装到系统中?如果是，则结束测试，否则转到b步骤去执行。
		
2）目的
	从顶层控制开始，采用同设计顺序一样的思路对被测系统进行测试，以验证系统的接口稳定性。
		
3）优点
	a.自顶向下的增殖方式在测试过程中较早的验证了主要的控制和判断点;
    b.功能可行性较早得到证实，还能够给开发者和用户带来成功的信心;

[外链图片转存中…(img-idORvoOb-1719280803439)]
[外链图片转存中…(img-YUK9EoLk-1719280803439)]
[外链图片转存中…(img-nUdV58PY-1719280803440)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！