day01(软件测试背景、基础理论、测试分类)

1.软件测试背景:

软件测试在软件生命周期中占据重要的地位,软件测试慢慢的独立发展成为一个行业,并且在迅猛发展。

1.1. 软件缺陷与软件故障

一:软件缺陷的定义

对于软件缺陷的精确定义,通常有下列5条描述:
1.软件未达到产品说明书的功能 《需求文档》
2.软件出现了产品说明书指明不会出现的错误
3.软件功能超出产品说明书指明范围
4.软件未达到产品说明书虽未指出但应达到的目标
5.软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好

二:软件缺陷的特征

1.软件的特殊性决定了缺陷不易看到,即“看不到”;
2.发现了缺陷,但不易找到问题发生的原因所在,即“看到但是抓不到”。

1.2.软件缺陷产生的原因

软件缺陷从哪来?第一大原因就是软件产品规格说明书,很多情况下,说明书没有写,或写的不够全面,经常更改,或者开发小组没有很好的沟通,造成对说明书理解的不一致。第二大原因是软件设计,没有做设计或设计不好,经常变动等和产品规格说明书一样的问题,第三个原因才是编写代码和其它原因;前两个原因至少占了 80%以上。

图1-1 软件缺陷产生的原因分布

day01(软件测试背景、基础理论、测试分类)_第1张图片
image.png

通过大量的测试理论研究及测试实践经验的积累,典型的软件缺陷产生的原因被归纳为以下几种类型:

(1)需求解释有错误;
(2)用户需求定义错误;
(3)需求记录错误;
(4)设计说明有误;
(5)编码说明有误;
(6)程序代码有误;
(7)数据输入有误;
(8)测试错误;
(9)问题修改不正确;
(10)不正确的结果是由于其他的缺陷而产生。

1.3.软件测试和缺陷修复的代价

缺陷发现的越早,则修复这个缺陷的代价就越小,在需求、设计、编码、测试、发布等不同的阶段,发现缺陷后修复的代价都会比在前一个阶段修复的代价提高10倍(参见图1-2)。

图1-2 软件测试和缺陷修复的代价

day01(软件测试背景、基础理论、测试分类)_第2张图片
image.png

2.软件测试基础理论

软件测试是保证软件质量的一种手段,那么,什么叫软件测试?

2.1.软件测试定义

- 狭义:测试的定义:“程序测试是为了发现错误而执行程序的过程”。这个定义,被业界所认可,经常被引用。

- 广义:为了更早地发现问题,所以将测试延伸到需求评审、设计审查活动中去,也就是将“软件质量保证”的部分活动归为测试活动。实际上,在软件开发实际操作中,常常将软件测试和质量保证——这两种努力(efforts)合并起来。延伸后的软件测试,被认为是一种软件测试的广义概念。

- 软件测试的定义:软件测试是贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程,其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。

2.2.测试流程:

需求评审 测试计划制定 测试计划执行 发布与测试报告总结

1从用户体验角度提供设计建议
2从开发经验角度,分析设计是否存在风险,是否能够实现
3 联合其他模块分析,设计是否存在漏洞,逻辑功能存在缺陷
1测试用例设计
2测试用例评审,和测试时间估计
3测试资源申请
1用例执行
2 Bug修复验证和推动版本进度
3性能监控,压力测试,兼容测试
1版本发布和线上质量监控,用户反馈实时响应
2测试用例更新整合,测试计划评估
3提供版本最终测试报告,包括用例覆盖率,bug数据分析等

全程跟进需求变更,与产品无缝沟通,在测试阶段有需求变更要第一时间了解改动范围,如果影响版本的质量要说明风险,评估需求是否必须更改以及是否影响版本发布上线的时间线
规划测试项目需要的功能开发和自动化开发人员比例,规划整个测试流程需要的时间,要预留处理紧急事件的缓冲
执行
协调测试资源,部署测试环境,督促开发和产品提供一切需要的测试工具,测试数据等,推动版本进度,每日进行bug review(bug复盘),标识出bug解决的优先级和提交测试的时间点,每日提供当日产品质量报告
报告
项目发布上线后,对整个版本的bug进行数据分析,总结出用例的覆盖率,对于没有覆盖到用例的bug,转化成用例,同时测试人员之间进行分享,针对新接触的测试方法测试工具和有价值的bug进行经验总结

day01(软件测试背景、基础理论、测试分类)_第3张图片
image.png
day01(软件测试背景、基础理论、测试分类)_第4张图片
image.png

3.软件测试分类

day01(软件测试背景、基础理论、测试分类)_第5张图片
image.png

3.1.黑盒测试和白盒测试

黑盒测试(Black Box -Test) :已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。

白盒测试(White Box Testing) :已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。

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

3.2.静态测试和动态测试

静态测试,是指不实际运行被测试软件,而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。

动态测试:是指实际运行被测程序,输入相应的测试数据,检查实际输出结果和预期结果是否相符的过程。

3.3.功能测试和性能测试

1.1.1.功能测试

是黑盒测试的一部分,它检查实际软件的功能是否符合用户的需求。

功能测试可以细分逻辑功能测试,界面测试,易用性测试,安装测试和兼容性测试。

逻辑功能测试:测试应用是否符合逻辑,比如应该先注册账号之后,才能进行登录,登录之后才能看我的购物车

界面测试:窗口大小,按钮大小,点击按钮弹出什么样的提示框,是否有滚动条,下拉菜单是否有展示内容...

易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如,软件窗口长宽比例是否合适,颜色色彩是否赏心悦目,字体大小是否合适

安装测试:

day01(软件测试背景、基础理论、测试分类)_第6张图片
image.png

兼容性测试:硬件兼容性测试和软件兼容性测试

硬件兼容性:比如一款软件在pc机,笔记本上是否兼容

软件兼容性测试:比如一款软件在windows8和windows10上是否兼容

1.1.2.性能测试

时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮,到登录成功(失败)的反应时间,浏览器非常常见,ANR(Application not responding 应用程序无响应)

空间性能:软件运行时所消耗的系统资源,比如对内存和cpu的消耗

一般性能测试:软件正常运行,不向其施加任何压力的测试

稳定性测试:也叫可靠性测试,是指连续运行被测系统,检查系统运行时的稳定成都。

负载测试:让被测系统在其能够忍受的压力范围之内连续运行,来测试系统的稳定性。(测试载重)

压力测试:持续不断的给被测试的系统增加压力,直到被测试的系统压垮为止,用来测试系统所承受的最大压力。(测试强度)

day01(软件测试背景、基础理论、测试分类)_第7张图片
image.png

3.4.回归测试、冒烟测试、随机测试

1.1.3.回归测试

是指对软件的新版本进行测试时,重复执行上一个版本测试时的用例,比如在1.0版本中,有一个bug,到了2.0版本中,再重新测试1.0中这个bug

1.1.4.冒烟测试

指对一个软件进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。

测试小组在正式测试一个新版本之前,先指派一两个测试人员测试一下软件的主要功能,如果没有实现,则打回开发组重新开发,这样做可以节省大量的时间成本和人力成本。

1.1.5.随机测试

是指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。

3.5.单元测试、集成测试、系统测试和验收测试

day01(软件测试背景、基础理论、测试分类)_第8张图片
image.png
1.1.6.单元测试

单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。
总的来说,单元就是人为规定的最小的被测功能模块。

单元测试当一段代码完成之后,是由白盒测试工程师或者开发人员自行测试,比如java中执行单元测试叫做junit测试。

目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序,没有相应的单元测试计划。

单元测试方式:先静态地观察代码是否符合规范,然后动态地运行一下代码,检查运行的结果。

例如:模块接口测试

  • 应对通过所测模块的数据流进行测试
  • 调用所测模块时的输入参数与模块的形式参数的个数、属性和顺序是否匹配
  • 所测模块调用子模块时,输入子模块的参数与子模块的形式参数在个数、属性和顺序上是否匹配。
  • 输出给标准函数的参数的个数、属性和顺序是否正确。
  • 全局变量的定义在各个模块中是否一致。
  • 当模块通过外部设备进行输入/输出操作,文件属性是否正确、open和close语句是否正确,规定的I/O格式说明与I/O语句是否匹配;缓冲区容量是否与记录长度匹配,在读写之前是否打开了文件,读写之后是否关闭了文件,对I/O错误是否做了处理。

驱动模块:相当于所测模块的主程序,它接收测试数据,把这些数据传送给所测模块,最后再输出实际结果

桩模块:用以代替所测模块调用的子模块。

1.1.7.集成测试

集成测试是单元测试的下一个阶段,是指将通过测试单元模块组装成系统或者子系统,再进行测试,重点测试不同模块的接口部分。

  • 在把各个模块连接起来的时候,穿越各个模块的接口的数据时候会丢失
  • 一个模块的功能是否会对另一个模块的功能产生不利的影响
  • 各个子功能组装完成后,能否达到预期的父功能
  • 全局数据结构是否有问题
  • 单个模块产生的误差累计起来是否会放大
1.1.8.系统测试和验收测试

集成测试完成之后,就是系统测试和验收测试。

系统测试:指的是将整个软件系统看做一个1个整体进行测试,包括对功能、性能,以及软件所运行的软硬件环境进行测试。

系统测试由黑盒测试人员在整个系统集成完毕后进行测试,前期主要测试系统的功能是否满足需求,后期主要测试系统运行的性能是否满足需求,以及系统在不同的软硬件环境的兼容性等。

day01(软件测试背景、基础理论、测试分类)_第9张图片
image.png

验收测试:以用户为主的测试,软件开发人员和质量保证人员参加,

你可能感兴趣的:(day01(软件测试背景、基础理论、测试分类))