其他分享
首页 > 其他分享> > 软件测试3-按生命周期/对象/测试手段分类

软件测试3-按生命周期/对象/测试手段分类

作者:互联网

软件测试3

1. 按生命周期划分

在这里插入图片描述在这里插入图片描述

1.1 单元测试

单元测试是对软件中的最小可验证单元进行检查和验证。 比如对Java中的类和方法的测试。

测试原则:
1、尽可能保证测试用例相互独立(测试用例中不能直接调用其他类的方法,而应在测试用例中重写模拟方法);
2、此阶段一般由软件的开发人员来实施,用来自我测验。用以检验所开发的代码功能符合自己的设计要求。

单元测试的好处:
1、尽早的发现缺陷;
2、利于重构;
3、简化集成;
4、文档;
5、用于设计。

单元测试的不足:
1、不可能覆盖所有的执行路径,所以不可能保证捕捉到所有路径的错误;
2、每行代码需要3~5行代码进行单元测试,存在投入与产出的平衡。

1.2 冒烟测试

冒烟测试:
比如测试app 先别直接测试, 先去测试一下这个app是否具有可测试性。如果这个app直接装上就崩溃,就不用测试了,白费劲儿。比如支付宝 的主要功能是转账,先看看能不能转账。
冒烟测试目的是确认软件基本功能正常,冒烟测试的执行者是版本编译人员。
现基本执行对象为测试人员,在正规测试一个新版本之前,投入较少的人力和时间验证基本功能,通过则测试准入。

1.3 集成测试—对接口进行测试

集成测试是在单元测试的基础上,把软件单元按照软件概要设计规格说明的规格要求,组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求。
对模块与模块之间进行测试
集成测试包括BigBang、自顶向下、自底向上、核心系统集成、高频集成。

1.4 系统测试—对完整软件的测试

在这里插入图片描述
集成测试和系统测试之间的比较:
1、测试内容:集成测试是测试各个单元模块之间的接口,系统测试是测试整个系统的功能和性能;
2、测试角度:集成测试偏重于技术的角度进行测试,系统测试是偏重于业务的角度进行测试。
一般先测功能,测完功能再继续测后面的
兼容性:
网站:同一个网站在不同的浏览器上能不能正常的使用
APP:app在不同手机型号上的表现(因为虽然都是安卓系统 但小米,华为等都对安卓系统做了一些改动)
易用性:
软件好不好用,用户体验如何
稳定性:
一个软件在一直使用的过程中会不会出问题,默认是72小时
UI测试:
检查软件的界面是否好看

1.5 验收测试

也称交付测试,是 针对用户需求、业务流程进行的正式的测试,以确定系统是否满足验收标准,由用户、客户或其他授权机构决定是否接受系统。(就像卖房子房主去看看是否符合自己的要求)

验收测试包括alpha测试和beta测试,alpha测试是由开发者进行的软件测试,beta测试是由用户在脱离开发环境下进行的软件测试。

总结–生命周期各测试方法对比
在这里插入图片描述

2. 按对象进行分类

在这里插入图片描述
按对象:
App测试,Web测试,物联网测试,车联网测试,嵌入式测试,大数据测试(皆是软件测试)
嵌入式测试:
例如扫地机器人的程序就是嵌入式程序写进去的,针对嵌入式开发进行测试

3. 按是否执行程序划分

£ 静态测试(Static testing)
静态方法是指不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。阿旺分析如下

检查项:代码风格和规则审核;程序设计和结构的审核;业务逻辑的审核;走查、审查与技术复审手册。

静态质量:度量所依据的标准是ISO9126。在该标准中,软件的质量用以下几个方面来衡量,即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性(Maintainability)、可移植性(Portability)。

£ 动态测试(Dynamic testing)
动态测试方法是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成:构造测试用例、执行程序、分析程序的输出结果

4. 按测试手段来分类:

黑盒测试、白盒测试、灰盒测试
  静态测试、动态测试
  手工测试、自动化测试
  在这里插入图片描述

4.1 白盒测试

在这里插入图片描述定义: 
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。 白盒测试是一种测试用例方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。
逻辑覆盖测试:
通过检查内部的结构来判断功能有没有问题, 对应软件上就是 不去运行代码,去看代码,直接去看代码写的对不对
插桩测试:
如果后面流程没做完, 进行模拟化,不用真的有接口,做一个假的接口。
(比如现在有一个APP,前期的操作都做好了,现在需要有给app充钱的操作,但是还没做好,并且不同银行接口不同报文不同,所以做一个系统能模拟不同银行给app充钱的操作。)

图示:
在这里插入图片描述
优点:
  1.迫使测试人员去仔细思考软件的实现,理解原理
  2.可以检测代码中的每一条分支和路径
  3.揭示隐藏在代码中的错误
  4.对代码的测试比较彻底
缺点:
  1.昂贵
  2.无法检测代码中遗落的路径和数据敏感性错误
  3.不能直接验证需求的正确性
主要测试方法:
在这里插入图片描述

4.2 黑盒测试

在这里插入图片描述 
定义:
把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。主要针对软件界面和软件功能进行测试。
(看不到内部的东西,只根据外部来判断测试,只在乎输入和输出,看输入与输出是否能对应上)
比如:
QQ 在乎是否能发送消息 A发送消息 大家可以收到,但是对于消息如何发送出去的技术并不关心
图例:
在这里插入图片描述
优点: 
  1.容易实施,不需要关注内部的实现
  2.更贴近用户的使用角度
缺点:
  1.测试覆盖率角度,一般只能覆盖到代码量的不到40%;
  2.针对黑盒测试的自动化测试,复用率较低,维护成本较高;
关注点:
  1.是否有不正确或者遗漏的功能?
  2.在接口上,输入是否能正确的接受?能否输出正确的结果?
  3.是否有数据结构错误或者外部信息(例如数据文件)访问错误?
  4.性能上是否能够满足要求?
黑盒测试的主要设计方法
在这里插入图片描述

4.3 灰盒测试

灰盒测试介于两种之间,既可以通过外部也可以通过观察结构
灰盒测试,是介于白盒测试与黑盒测试之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

灰盒测试的特点:
灰盒测试结合了白盒测试盒黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识盒与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出,但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

执行灰盒测试有什么好处呢?
1、 能够进行基于需求的覆盖测试和基于程序路径覆盖的测试;
2、 测试结果可以对应到程序内部路径,便于bug的定位、分析和解决;
3、 能够保证设计的黑盒测试用例的完整性,防止遗漏软件的一些不常用的功能或功能组合;
4、 能够需求或设计不详细或不完整对测试造成的影响。

进行灰盒测试有什么缺点呢?
1、 投入的时间比黑盒测试大概多20-40%的时间;
2、 对测试人员的技术要求更高;

5. 按测试方向分类

在这里插入图片描述功能测试:
对功能进行测试(比如对于一个网站,他可以查询注册了的公司,那么它的功能就是查询这种功能 对这种功能进行测试)
和黑盒测试不一样,功能测试是一个方向,而黑盒测试是一个方法,对于功能测试来说,采用最多的方法是黑盒测试,功能测试是吃饭,而黑盒是筷子,白盒是勺子这样。

性能测试:
测试性能(比如买票软件太卡,说明性能不足,功能测试是能不能做,性能测试即能够做多好)
–包括:负载测试(指标变化),压力测试(性能点),强度测试,容量测试,基准测试,渗入测试,峰谷测试

1.压力测试(食堂能容纳多少个人来吃饭,找到xx人发现有空余,再加一点,找到食堂瓶颈点)
2.负载测试(食堂打菜的师傅在放学的时候会工作压力增大,通过负载测试来判断食堂师傅高强度工作能维持多长时间,举重能举xx斤多久) 一般采取峰值的百分之八十到百分之九十来进行
3.并发测试(同一瞬间发生的事,比如秒杀商品,出现两个人都抢到了同一件商品,并发测试就是为了防止出现这种情况)

安全测试(黑客技术,防止黑客盗取信息和攻击)

标签:灰盒,黑盒,白盒,代码,生命周期,测试,软件,软件测试
来源: https://blog.csdn.net/sunshine612/article/details/104554396