02-测试分类

软件测试分类

功能测试——测试人员用鼠标去手动测试(测试GUI),俗称点点点测试

自动化测试——用程序测试程序(测试API),解放双手

性能测试——定位系统瓶颈,保证系统的良好性能与稳定性

黑盒测试——测试应用程序的功能,验证结果是否正确

白盒测试——测试程序内部结构,以编程语言角度设计测试案例

软件测试功能分类

按测试阶段划分

  • 单元测试 Unit Testing
  • 集成测试 Integration Testing
  • 系统测试 System Testing

单元测试 

什么是单元?举个例子,一个整块的拼图,一块小拼图就可以理解为一个单元。

其实一个单元就是一个功能小模块。单元测试是针对基本单元 ( 软件设计最小单位 ) 进行正确性检测工作。目的是检测软件模块是否完成了需求设计书中的要求。

集成测试

集成测试是基于单元测试的基础,将所有模块按照设计组装为一个子系统进行验证。比如将内存条放进卡槽,检查规格是否符合,内存条能否完全插进卡槽或插入内存后机器是否可以正常工作,此做法都称为集成测试。

系统测试

将已经集成好的软件系统,结合测试人员,配置测试环境和计算机硬件环境,整合到一起后进行的测试工作就叫系统测试。

单元、集成、系统测试的区别 

测试方法不同

  • 单元测试属于白盒测试范畴
  • 集成测试属于灰盒测试范畴
  • 系统测试属于黑盒测试范畴

测试范围不同

  • 单元测试检查单元内部数据结构、逻辑控制、异常处理等
  • 集成测试检查模块之间的数据传输
  • 系统测试检查整个软件是否满足了需求

回归测试

回归测试过程信息流

软件环境配置:需求文档,需求设计书,测试代码等

测试环境配置:测试需求说明书,测试计划书,测试用例等

回归测试定义 

软件在测试或者其他活动中发现了缺陷且经过修复之后,应该进行回归测试活动。目的在于验证缺陷是否正确的被修复,并且是否影响到其他的功能。

回归测试流程 

  1. 制定测试策略,回归测试策略
  2. 确定回归测试版本
  3. 根据回归测试策略执行回归测试
  4. 回归测试通过,关闭缺陷跟踪单(禅道,coding,gitee)
  5. 回归不通过,缺陷跟踪单返回给开发人员,重新修复问题,再次回归

回归测试策略设计

完全重复测试:
重新执行所有先前定义的测试用例,来确认问题修改的正确性,以及软件修改后可能造成的影响扩散。
选择性重复测试:
有选择性的重新执行部分测试用例。

  • 覆盖修改法:针对被修改的部分,重新构造测试用例验证缺陷
  • 影响扩散法:再覆盖已修改的部分之上,分析其修改后是否间接造成了其他额外的缺陷
  • 指标达成法:确定要达成的测试目标,例如测试用例覆盖率的百分比

回归自动化测试

由于回归测试的特性是重新执行以前的成果,且无法预知需要回归几次后才能够通过测试标准,因此回归测试可能由于枯燥乏味造成测试人员积极性低下,测试质量下降。因此我们需要机器人或是计算机程序解决此重复且乏味的测试活动,自动化回归测试应运而生。
良好的回归自动化测试活动包括如下:

  • 程序自动运行
  • 程序参数自我配置
  • 测试用例自动管理
  • 测试活动自动执行
  • 测试信息日志自动收集
  • 测试结果自动分析与输出

实现测试用例自动化且进行结果分析,此类活动适合脚本化用例开发,进行逻辑控制,结果断言等,使用Python进行脚本开发灵活性较高。对于特定系统或者复杂测试环境下,商业测试工具难以解决问题,自主研发自动化测试工具是灵活的方法。

验收测试

在软件生命周期流程上来看,软件研发阶段,测试活动包括单元测试、集成测试,系统测试等企业内部进行的测试活动。在软件发布之前还有一个测试活动有真实用户介入,称为验收测试。软件项目开发分为两种形式:
1、企业自研产品,如今日头条,王者荣耀,抖音

  • 自己公司产品上线前由用户介入进行大范围内测,公测,检验软件正确性
  • α测试
  • B测试

2、公司承接业务开发,客户要什么就开发什么

  • 产品研发好后,由客户方验收,检验产品需求正确性

验收测试概要

如何确定验收测试的执行时间、执行人员、执行环境

  • 在通过内部系统测试活动以及软件配置审查之后,开始执行验收测试
  • 验收测试是以人为测试活动为主,由测试人员和用户群体为代表开展测试活动
  • 验收测试原则上是在用户本地进行,在用户同意下,也可以在软件开发公司内部模拟测试环境
  • 验收测试以验收测试计划书或软件需求规格书进行标准化测试
  • 验收测试结果分两种:

              1、软件功能、质量、性能、界面特性与用户需求一致,用户接纳软件结果。
              2、反之,软件不被用户接受。

α、β测试 

α测试活动好比游戏的删档内测

  • 由企业内部员工在模拟真实环境下进行的测试活动,进行结果反馈

              员工在开发人员的接入下,通过指导进行软件使用,且随时记录下使用过程中的错误

  • 由真实用户在软件内测版本,开发版本环境下进行的产品体验/测试活动,进行结果反馈
  • a测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)
  • a测试即为非正式验收测试,尤其注重产品的界面和特色

β测试好比游戏的不删档公测

  • 由多个用户在实际操作环境下进行产品功能测试,如不同的手机型号,平台,网络环境等
  • β测试不受开发者控制,自主开展测试活动,然后进行结果反馈

场景

测试划分 

测试过程分为四大阶段:

测试分类:

生命周期各测试方法对比 

软件测试分类说明 

黑盒测试 

  • 黑盒称为功能测试,一是按顺序检测程序每个功能,二是按功能模块优先级测试。
  • 对软件的界面和功能进行测试,只考虑其整体特性,不考虑其内部实现
  • 需要根据说明书、用户手册进行功能测试
  • 要求多组数据,多次测试才能得到准确的报告

黑盒测试类型 

  • 功能性测试:网站顺序使用的功能,手机使用功能,显示器是否正常显示。
  • 容量测试:海量数据的处理,如1亿人用微信,1亿人用支付宝,这个数值容量
  • 负载测试:系统在短时间内处理海量数据时,系统的健康状况指标
  • 恢复性测试:小米手机秒杀活动太过热火,网站挂了,不该影响用户数据

白盒测试

  • 白盒测试就像打开了黑盒子,可以看到软件的内部代码,对比黑盒测试,白盒测试更严谨。
  • 对软件的源码和架构进行测试,需要软件源代码,流程图等设计文档。
  • 依据被测软件分析程序内部构造,并且根据内部结构设计测试用例,针对内部控制流程进行测试。
  • 白盒测试是基于程序结构的逻辑驱动测试。

黑盒,白盒测试,相辅相成,白盒测试通过了,还得运行软件,查看软件的性能好坏,界面美丑,是否易用等方面。

软件测试方法选择

已知产品需求规格,但不知道其系统内部实现,进行黑盒测试证明需求是否实现。
已知产品内部实现,通过测试每种内部操作是否符合需求,属于白盒测试。

为什么要白盒测试

只验证产品基本需求得到实现,为什么要费力去测试产品内部实现呢?所谓知其然不知其所以然,仅黑盒测试,只能够满足一定的覆盖率,不能够消除更多隐藏的缺陷。而白盒测试能够从内部逻辑检测,测试覆盖率更高,给与软件质量更高的保证。

白盒测试特点

  • 理解软件需求
  • 了解软件代码实现
  • 检测代码逻辑
  • 检测代码中文件路径
  • 白盒测试成本较高

白盒测试的方法 

  • 静态分析:控制流分析,数据流分析,信息流分析
  • 动态分析:逻辑覆盖测试(分支测试、路径测试)、程序插装

逻辑覆盖测试:

  • 语句覆盖
  • 判定覆盖
  • 条件覆盖
  • 路径覆盖

逻辑覆盖率的统计通过程序插装可以体现

程序插装:

  • 调试代码时,往往会在程序中添加print()语句,能够很方便的打印出我们想要的信息,进一步了解程序执行的一些动态信息,比如程序执行顺序,计算后的变量等。
  • 程序插装技术能够按照用户的要求,获取程序部分信息,是测试工作的有效手段。

黑盒测试和白盒测试的优缺点

黑盒测试的优点有:

  1. 比较简单,不需要了解程序内部的代码及实现;
  2. 与软件的内部实现无关;
  3. 从用户角度出发,很容易知道用户会用到哪些功能,会遇到哪些问题;
  4. 基于软件开发文档,知道软件实现了文档中的哪些功能;
  5. 在做软件自动化测试时较为方便。

黑盒测试的缺点有:

  1. 没有清晰的测试规格说明,测试用例难以设计;
  2. 自动化测试的复用性较低;
  3. 无法控制程序内部路径,可能缺少较多测试点。

白盒测试的优点有:

  1. 帮助软件测试人员增大代码的覆盖率,提高代码的质量,发现代码中隐藏的问题。

白盒测试的缺点有:

  1. 程序运行会有很多不同的路径,不可能测试所有的运行路径;
  2. 测试基于代码,只能测试开发人员做的对不对,而不能知道设计的正确与否,可能会漏掉一些功能需求;
  3. 系统庞大时,测试开销会非常大。

灰盒测试

介于白盒与黑盒之间,针对被测对象信息的不同,采用不同的测试方法。

  • 检验被测对象整体特性信息,采用黑盒测试
  • 检验被测对象内部实现,采用白盒测试
  • 既要观察被测对象整体信息,又要观察内部具体信息,信息占比不同,这就是所谓灰盒测试。

软件测试文档

软件研发如同工厂生产,整个过程会有产品输出,输出的产品有三类

  • 编译好的代码程序,如XX.exe
  • 用户使用手册,XX使用手册
  • 源代码,XX源代码

  • 需求分析:软件测试依据
  • 概要设计:根据需求分析的内容,进行方案设计,明确是否覆盖到软件的需求
  • 详细设计:包含方案、策略、架构、体系、接口名、接口文档、数据结构算法,保证开发过程细致
  • 测试设计:测试需要进行哪些内容,包含哪些功能点,是否会影响其他功能,例如第三方支付页面跳转
  • 测试用例:用例是进行测试的依据,测试的规范条文
  • 测试报告:测试成功数量、失败数量、测试是否通过,允许产品上线等

动态测试与静态测试

静态测试:不运行被测试的软件系统,采用例如代码阅读、文档评审、代码分析等方式进行软件测试。
动态测试:按照预先规划好的测试数据与流程执行被测软件系统。 

静态分析技术

定义:静态分析是不执行程序而分析程序的技术
功能:检查软件功能与需求是否一致,没有明显缺陷与歧义
测试点:

  • 程序代码语法上是否一致性与完整性
  • 文档描述是否规范、精准、便于查阅
  • 程序与文档之间描述的一致性 

动态分析技术

定义:对软件系统进行数据驱动运行,与期望结果进行对比检查的过程。

  • 脚本录制工具,进行反复测试,回归测试,如Robot、QTP、Selenium工具
  • 性能测试工具,LoadRunner、Robot等 
具有多种最大功率点跟踪(MPPT)方法的光伏发电系统(P&O-增量法-人工神经网络-模糊逻辑控制-粒子群优化)之使用粒子群算法的最大功率点追踪(MPPT)(Simulink仿真实现)内容概要:本文介绍了一个涵盖多个科研领域的综合性MATLAB仿真资源集合,重点聚焦于光伏发电系统中基于粒子群优化(PSO)算法的最大功率点追踪(MPPT)技术的Simulink仿真实现。文档还列举了多种MPPT方法(如P&O、增量电导法、神经网络、模糊逻辑控制等),并展示了该团队在电力系统、智能优化算法、机器学习、路径规划、无人机控制、信号处理等多个方向的技术服务能力与代码实现案例。整体内容以科研仿真为核心,提供大量可复现的Matlab/Simulink模型和优化算法应用实例。; 适合人群:具备一定电力电子、自动控制或新能源背景,熟悉MATLAB/Simulink环境,从事科研或工程仿真的研究生、科研人员及技术人员。; 使用场景及目标:①学习并实现光伏系统中基于粒子群算法的MPPT控制策略;②掌握多种智能优化算法在电力系统与自动化领域的建模与仿真方法;③获取可用于论文复现、项目开发和技术攻关的高质量仿真资源。; 阅读建议:建议结合提供的网盘资料,按照研究方向选取对应模块进行实践,重点关注Simulink模型结构与算法代码逻辑的结合,注重从原理到仿真实现的全过程理解,提升科研建模能力。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值