软件测试最全软件测试需要掌握哪些技术?_软件测试需要掌握的技能,2024年最新Activity的6大难点你会几个

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

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

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

1.1 黑盒测试

黑盒测试 又叫 功能测试、数据驱动测试 或 基于需求规格说明书的功能测试。该类测试注重于测试软件的功能性需求。

采用这种测试方法,测试工程师把测试对象看作一个黑盒子,完全不考虑程序内部的逻辑结构和内部特性,只依据程序的《需求规格说明书》,检查程序的功能是否符合它的功能说明。

测试工程师无需了解程序代码的内部构造,完全模拟软件产品的最终用户使用该软件,检查软件产品是否达到了用户的需求。黑盒测试方法能更好、更真实地从用户角度来考察被测系统的功能性需求实现情况。

在软件测试的各个阶段,如 单元测试、集成测试、系统测试及验收测试 等阶段中,黑盒测试都发挥着重要作用,尤其在系统测试和确认测试中,其作用是其他测试方法无法取代的。

1.2 白盒测试

白盒测试 又称 结构测试、透明盒测试、逻辑驱动测试 或 基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,即清楚盒子内部的东西以及里面是如何运作的。

"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。

白盒测试的测试方法有 代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异。

白盒测试法的覆盖标准有 逻辑覆盖、循环覆盖 和 基本路径测试。

其中 逻辑覆盖 包括 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖 和 修改条件判断覆盖 。六种覆盖标准发现错误的能力呈 由弱到强 的变化:

  • 语句覆盖:每条语句至少执行一次。
  • 判定覆盖:每个判定的每个分支至少执行一次。
  • 条件覆盖:每个判定的每个条件应取到各种可能的值。
  • 判定/条件覆盖:同时满足判定覆盖、条件覆盖。
  • 条件组合覆盖:每个判定中各条件的每一种组合至少出现一次。
  • 修改条件判断覆盖:每一个判断的所有可能结果都出现过、每一个判断中所有条件的所有可能结果都出现过、每一个进入点及结束点都执行过、判断中每一个条件都可以独立的影响判断的结果。

1.3 灰盒测试

灰盒测试,是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。

灰盒测试不像白盒那样详细、完整,但又比黑盒测试更关注程序的内部逻辑,常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

2、自顶向下集成和自底向上集成各自的优缺点

集成测试的方法有两种:非增量式测试 和 增量式测试

非增量式是每个模块测试完了再连接。

增量式则是测一个模块,就连接一个模块。而采用增量式测试时又有两种选择:自顶向下结合、自底向上结合。

2.1 自顶向下集成

自顶向下的集成测试就是 按照系统层次结构图,以主程序模块为中心,自上而下按照深度优先或者广度优先策略,对各个模块一边组装一边进行测试。

优点:

  • 较早地验证了主要控制和判断点
  • 按深度优先可以首先实现和验证一个完整的软件功能
  • 功能较早证实,带来信心;只需一个驱动,减少驱动器开发的费用
  • 支持故障隔离。

缺点:

  • 柱的开发量大
  • 底层验证被推迟
  • 底层组件测试不充分

适应于产品控制结构比较清晰和稳定;高层接口变化较小;底层接口未定义或经常可能被修改;产口控制组件具有较大的技术风险,需要尽早被验证;希望尽早能看到产品的系统功能行为。

2.2 自底向上集成

自底向上集成是 从系统层次结构图的底层模块开始进行组装和集成测试的方式。对于某一个层次的特定模块,因为它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在测试过程中,如果想要从子模块得到信息可以通过直接运行子模块得到。也就是说,在集成测试的过程中只需要开发相应的驱动模块就可以了。

优点:

  • 对底层组件行为较早验证
  • 工作起初可以并行集成,比自顶向下效率高
  • 减少了桩的工作量;支持故障隔离。

缺点:

  • 驱动的开发工作量大
  • 对高层的验证被推迟,设计上的错误不能被及时发现

适应于底层接口比较稳定;高层接口变化比较频繁;底层组件较早被完成。

strongerHuang

,赞 58

3、按照开发阶段划分,软件测试可以分为哪几个流程?

软件测试类型按开发阶段分为:

  • 单元测试 又称为模块测试,是针对软件设计的最小单位——程序模块进行正确性检查的测试工作,单元测试需要从程序内部结构出发设计测试用例,多个模块可以平行地独立进行单元测试。
  • 集成测试 又称为 组装测试 或 联合测试,在单元测试的基础上需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
  • 确认测试 的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般由第三方测试机构进行。
  • 系统测试:软件作为计算机系统的一部分,与硬件、网络、外设、支撑软件、数据以及人员结合在一起,在实际或模拟环境下,对计算机系统进行测试,目的在于与系统需求比较,发现问题。
  • 验收测试:以用户为主的测试,软件开发人员和质量保证人员参加,由用户设计测试用例。不是对系统进行全覆盖测试,而是对核心业务流程进行测试。

4、什么是测试用例,为什么要设计测试用例?

测试用例(Test Case)是为某个特殊目标而编制的 一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

1、指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准,测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中,以便自动生成测试结果文档。

根据测试用例的测试等级,集成测试应测试那些用例,系统测试和回归测试又该测试那些用例,在设计测试用例时都已作明确规定,实施测试时测试人员不能随意作变动。

2、规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。

尤其象测试报表之类数据集的正确性,按照测试用例规划准备测试数据是十分必须的。

除正常数据之外,还必须根据测试用例设计大量边缘数据和错误数据。

3、编写测试脚本的"设计规格说明书"

为提高测试效率,软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。

如果说软件工程中软件编程必须有设计规格说明书,那么测试脚本的设计规格说明书就是测试用例。

4、评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估,并且编制测试报告。

判断软件测试是否完成、衡量测试质量需要一些量化的结果。例:测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,等等。以前统计基准是软件模块或功能点,显得过于粗糙。采用测试用例作度量基准更加准确、有效。

5、分析缺陷的标准

通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映实施测试或变更处理存在问题。

软件测试和软件开发一样,都遵循软件工程原理,遵循管理学原理。

测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象,明确了测试与开发之间的关系,是测试管理的重要参考依据。

img
img
img

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

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

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

以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!**

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值