软件测试有捷径嘛?怎么样可以快速学习软件测试

文章末尾给大家留下了大量的福利

前言

今天,笔者想和大家来唠唠软件测试,因为有些小伙伴一直在问我学习软件测试有没有比较好的方法或者建议,笔者就给大家来好好唠唠。

 

怎么才算把软件测试做好,不做弯路呢,接下来我从几个方面谈一下理解:

  • 软件测试的目的
  • 软件测试做哪些事情
  • 哪条路是捷径

软件测试是通过验证产品实现过程好的行为和不好的行为,目的是达到一个更高的产品交付标准。可以通过检查研发代码的方式验证,也可以通过检查产品的特性验证。

初级的软件测试通常把测试目标放在找出更多不好的行为,找出更多的 bug,通常不需要对软件业务有很清晰的认识,只需要根据一些固定的套路去找问题就可以。

中级的软件测试除了能找出很多 bug 外,还能关注整个产品设计和研发中好的部分,为什么有些部分很少出问题,为什么另一些部分却经常出问题。 中级的软件测试不仅有很成熟的方法论,而且对软件研发、系统架构有一定的认识,对某些领域比较熟悉。

高级软件测试不仅能做到前面的,而且能推动软件能有更好的交付质量,不仅要熟悉测试整个流程,而且还知道研发流程,并且结合这些来制定更好的交付标准和流水线。 到了这个阶段,不需要太纠结哪些工作由测试负责,哪些由 QA 负责,实际上,从一开始就不用纠结。

怎么做软件测试,哪些测试工作比较重要?

平时的测试工作主要分为 3 类:

  • 功能性测试
  • 非功能测试
  • 回归测试

功能测试主要验证产品能不能用,也是所有软件测试工作中的重心。如果一款产品交付到用户手中有质量问题,不仅容易损失客户,而且会让品牌的形象受到严重挑战。

非功能测试主要验证产品好不好用。它是一个持续优化的过程,不可能在一开始就做得很好,所以一款新产品刚上市,在资源有限的情况,往往对非功能测试不会特别看重,根据用户的反馈再去调整。

而一款老产品,随着用户越来越多,竞争对手的加入,会越来越关注品牌形象,从而越来越注重非功能测试。

当一个测试工程是在选择岗位的时候,一般情况下,越注重非功能测试的公司,对自己的品牌形象越看重,业务发展的相对较好,可以大致判定为好公司。 而一个公司如果有一定的体量,仍然不注重非功能测试,则可能不太注重用户体验,或者公司发展较差,没办法投入这么多资源。

回归测试其实不是单独的测试种类,不过我把它放进来了。前面的功能测试和非功能测试是在同一时间点时要关注的测试种类,是静态的。 而回归测试是从时间方面来关注的测试种类,是动态的。

它关注的是随着产品不停的研发,会不会出现新的质量问题。比如说公司每个月发布一次新版本,因为每次都有新的软件改动,所以很有可能引入新的问题,我们就需要关注开发修改完代码后,是不是引入了新问题,是不是解决了之前的老问题。

现代化企业产品发布的频率越来越快,因此回归测试也越来越重要。

接下来,讨论一下手工测试和自动化测试的问题。

手工测试是通过手来完成测试工作,自动化测试通过工具、代码、机器等来完成测试工作。 实际上,手工测试在一定程度上都需要借助自动化工具。所以他们并没有明显的界限。 可以简单理解为自动化测试是执行过程中不需要人工值守和干预的。

这两个只是实现测试目标的方式不一样,并没有谁高谁低,谁强谁弱的问题。就好像我想和朋友打电话,我可以使用苹果手机,也可以使用安卓手机。 我想寄快递,可以选择顺丰快递或者德邦快递。

虽然他们都能达到目的,但是还是有人更喜欢自动化测试,因为它格调高,说出去特别有面子。 我记得我以前不怎么喜欢玩手机,但是有那么一次买了个苹果手机,玩手机的频率就明显变快了。

手工测试和自动化测试各有各的特点,自动化方式更适合可以重复执行的测试场景,手工测试更适合灵活、单次的测试场景。

一款新产品或者新功能,你还不知道它的未来,可能明天就下线了,明显就适合手工测试。 而回归测试就是要多次运行,因此更适合自动化测试。 随着产品的更新和迭代,有的手工测试会逐步转成自动化测试的方式。

不管是手工测试还是自动化测试的方式,几乎都要编写脚本。脚本是执行测试的文本依据,自动化测试的脚本往往是代码或者工具中创建的交互过程。 手工测试的脚本是编写的用例文本内容,可以按照里面的说明执行用例。

除了脚本方式,手工测试的探索式测试和自动化当中的智能化测试需要单独说明。

探索式测试是手工测试人员按照以外的经验和方法论快速验证产品特性的方式,更适合中高级测试人员,执行完后可能也是需要补上脚本的。

智能化测试是通过人工智能方式自动识别和生成用例,然后再通过代码执行的过程。用例的编写几乎都不需要人工参与,是新时代下快速发展的一种测试方式。

端对端 vs UI 测试

功能性测试可根据测试金字塔分为3种:

  • 单元测试
  • 集成测试
  • 端对端测试

通常进行的接口测试属于集成测试, 从页面点击到反馈的过程是端对端测试(客户端-服务端-客户端)。

UI 测试我会把它放在非功能测试,因为它测试的其实是好不好用的问题。

像平时说的性能测试、ui测试、兼容性测试、稳定性测试基本都是属于非功能测试的问题。

有没有捷径?

这几块内容可谓捷径:

  • 完整系统的测试方法和理论
  • 探索式测试方法
  • 领域知识,把业务用领域语言描述和分析的能力
  • 研发流程和软件架构,比如目前常用的微服务架构、云原生
  • 在这里面代码能力不是必须,不过基本还是会去掌握,因为他确实能解决很多手工无法解决的问题。~~~~

总结

今天的文章就到这里,希望可以帮助到大家,喜欢的小伙伴可以点赞收藏评论加关注哟。

下面是我给大家留下的一些福利,有需要的小伙伴可以私信关键字“资料”获取哟。

项目实战

app项目,银行项目,医药项目,电商,金融

​大型电商项目

全套软件测试自动化测试教学视频

​300G教程资料下载【视频教程+PPT+项目源码】

​全套软件测试自动化测试大厂面经

​python自动化测试++全套模板+性能测试

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值