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

img
img
img

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

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

需要这份系统化的资料的朋友,可以戳这里获取

三、单元的常见错误

四、如何进行单元测试

五、单元测试策略

六、系统测试的概念

七、系统测试的环境

八、系统测试的类型

九、系统测试的过程

十、集成测试概念

十一、集成测试的目的

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

十三、集成测试的层次

十四、集成测试策略

1.大爆炸集成(Big Bang Integration)

2.自顶向下的集成策略(Top-Down Integration)

3.自底向上的集成策略(Bottom-Up Integration)

4.三明治集成(Sandwich Integration)

5.基干集成(Backbone Integration)

6.分层集成(Layers Integration)

7.基于功能的集成(Function-Based Integration)

8.基于进度的集成(Schedule-Based Integration)

9.基于风险的集成(Risk-Based Integration)

10.基于事件(消息)的集成(Event/Message-Based Integration)

11.基于使用的集成(Use-Based Integration)

12.分布式集成(Distributed Services Integration)

13.客户/服务器的集成(Client/Server Integration)

14.高频集成(High-frequency Integration)


一、单元测试的概念

单元测试(Unit Testing)是对软件基本组成单元进行的测试,如函数(function或procedure)或一个类的方法(method)。当然这里的基本单元不仅仅指的是一个函数或者方法,有可能对应多个程序文件中的一组函数。

单元也具有一些基本的属性。比如:明确的功能、规格定义,明确的与其他部分的接口定义等,可清晰地与同一程序的其他单元化分开来。

二、单元测试的目的

单元测试的目的在于发现各模块内部可能存在的各种错误,主要是基于白盒测试。(也就是说,在单元测试过程中,用的最多的是白盒测试方法,也可能会有灰盒或者黑盒。单元测试和白盒测试是不同的划分,不存在包含关系)。

在单元测试阶段对应的文档是详细设计文档(LLD);对应的代码就是单元代码,因此单元测试的目的主要有3点

1、验证代码是与设计相符合的;

2、发现设计和需求中存在的错误;

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

三、单元的常见错误

单元的常见错误一般出现在以下五个方面,因此这五个方面是单元测试应该关注的重点。

1、单元接口。

2、局部数据结构。

3、独立路径。

4、出错处理。

5、边界条件。

四、如何进行单元测试

在单元测试时,由于单元本身不是一个独立的程序,一个完整的可运行的软件系统并没有构成,所以需要设置一些辅助测试单元,辅助测试单元有两种,一种是驱动单元,另外一种是桩单元。

1、驱动单元(Driver):用来模拟被测单元的上层单元,相当于被测函数的主函数,如main函数。所以驱动单元主要完成以下4个步骤:

(1)接受测试数据,包含测试用例输入和预期输出;

(2)把测试用例输入传送给被测单元,驱动被测单元测试;

(3)将被测单元的实际输出和预期输出进行比较,得到测试结果;

(4)将测试结果输出到指定位置。

2、桩单元(Stub):用来代替被测单元工作过程中调用的子单元。

桩单元模拟的单元可能是自定义函数:这些自定义函数可能尚未编写完成,为了测试被测单元,需要构造桩单元来代替它们,可能存在错误,会影响测试结果,所以需要构造正确无误的桩单元来达到隔离的目的。

驱动单元和桩单元都是额外的开销,虽然在单元测试的时候必须写,但是并不需要作为最终的产品提供给客户。

五、单元测试策略

一般的单元执行策略有三种:孤立的单元测试策略(Isolation Unit Testing),自顶向下的单元测试策略(Top Down Unit Testing)和自底向上的单元测试策略(Bottom Up Unit Testing)。需要注意的是:在集成测试中也有自顶向下和自底向上的测试策略,但是测试对象不同。

1、孤立的单元测试策略(Isolation Unit Testing)

方法:不考虑每个模块与其它模块之间的关系,为每个模块设计桩模块和驱动模块,每个模块进行独立的单元测试。

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

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

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.进行软件系统可测性分析,确定系统测试的对象、范围和方法

系统测试计划的要点

img
img
img

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

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

需要这份系统化的资料的朋友,可以戳这里获取

试报告的评审

软件测试组:

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

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

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

系统分析组:

1.提出系统测试需求

2.进行测试需求跟踪

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

系统测试计划的要点

[外链图片转存中…(img-Rt1aMZdR-1715544702934)]
[外链图片转存中…(img-lHfnqxvC-1715544702935)]
[外链图片转存中…(img-Yn9GY1lH-1715544702935)]

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

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

需要这份系统化的资料的朋友,可以戳这里获取

  • 25
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值