软件测试有没有捷径?

本贴最后更新于 942 天前,其中的信息可能已经天翻地覆

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

端对端 vs UI 测试

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

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

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

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

有没有捷径?

这几块内容可谓捷径:

回帖
请输入回帖内容 ...