测开领域,三种高性价比测试方法

引言

最近也是临近年底,各位小伙伴也是蠢蠢欲动,我最近也是没闲着,除了加班,还在做一项"公益活动":one by one 的指导想要体现自己价值的小伙伴。

在面试指导过程中,我发现,即使有10N+工作经验的小伙伴,其实对测开的理解,还停留在3N左右的经验上,这不禁让我惊叹…

所以,我也是决定,开一个专栏,来详细分享测开领域的专业知识

我们都知道,测试领域的测试方法,很多种(多的不少于100种),所以那些所谓的说测试很简单的人,你就呵呵他就行!!

而在这100多种测试方法中,有三种,是能非常体现出高效产出比的。

我们今天,就来聊一聊 这三种测试方法:

  • 灰度测试

  • 冒烟测试

  • 单元测试

我一直推崇的都是高效产出比,有的时候,要屈服于现实…但,这不等于放弃。

单元测试

单元测试引入

软件的问题,90% 都是编码的问题,在编码阶段发现问题,不会对任何人有影响,并且可以随手改掉。这也是成本最低,效率最高的。

那么,单元测试,如何执行呢?

一句话,就是 一行一行执行代码。只要让代码跑起来,才能发现代码的问题。

单元测试带来的收益,还有很多,例如:更好的模块设计,更放心的代码重构等等。

当然,任何事情都有两面性,单元测试也不例外,这需要持续地编写测试代码。

这也就是出现了两极分化的情况,支持派与反对派。一般的大厂,都会做单元测试,因为这是减少缺陷,提高效率的方式;而一些小厂,可能就不会考这么多,毕竟人员,资源都有限…

投入产出比

测试投入:???

测试产出:???

测试指数:???

冒烟测试

冒烟测试引入

每个测开的大佬,都会经历过。修复了1个缺陷,引入10个缺陷。开发大佬提供的版本,不是闪退,就是无法运行,计划中的特性测试根本没办法开展。

每次出现这种情况,都需要PM出面,否则…(可能会休长假…)

而解决这些问题,最好的方法就是,给开发提交测试版本设置的一道防线,即冒烟测试。

如果说回归测试是追求大而全,那么冒烟测试追求的就是小而精。

冒烟用例/测试环境/执行入口 由测开人员提供,覆盖本次提交版本的核心功能,涉及主流程。

冒烟测试通过,可以说明开发的代码改动没有很大问题,软件也有了基本的质量保证,后续的测试阶段也可以陆续展开。

冒烟测试作为开发提测的一道防线,可以减少浪费,提交效率。冒烟测试用例比较少,因为开发和维护成本就低很多。

主要的成本是冒烟用例失败的定位分析成本,这是一件持续的事情。

投入产出比

测试投入:??

测试产出:???

测试指数:???

灰度测试

软件的依赖

软件测试中,有一个根深蒂固,也是很普遍存在的问题:预发环境都OK的功能,上线后就出现各种问题,我想这在大厂的人,是很有感触的。

我们都知道,软件是运行在特定环境中的,软件的的实际行为与其所处的环境具有高度依赖性。

软件运行的中级环境时生产环境,只有在生产环境测试通过,我们才能说软件有风险的几率非常低。

但是,在生产环境做测试,风险是很大,对用户的影响也很大,那这个时候,就需要引入了 灰度测试。

引入灰度环境

在灰度测试中,通常将待发版的软件部署到部分生产环境(即 灰度环境)上,然后将测试流量或者部分用户流量引入到灰度环境。

如果你是某软件非常活跃的用户,你会收到某新功能的体验邀请…

例如:支某宝邀请你参加体验xx新功能;某信邀请你体验xx新功能。

灰度测试实现了在生产环境对软件的终极验证,是软件发布前的最后一道防线。

它的投入(环境配置/引流/自动化用例)等是一次性的,但是其产出是显著的(提前于用户发现问题),并且可以持续产出(每一次软件升级都受益)

投入产出比

测试投入:?

测试产出:???

测试指数:???

总结

今天聊的三种测试方法,不期望每个公司都能够完全推行,但是至少各位测开同学,能够了解,熟悉,掌握。

至少在测开领域,掌握足够多的知识,是进大厂的资本,也是提升收入的资本。

绵薄之力

最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走

这些资料,对于想进阶【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助,需要的小伙伴点击下方插件进群免费领取:

猜你喜欢

转载自blog.csdn.net/weixin_54696666/article/details/126651607
今日推荐