测试基础 越迷信技巧越容易失败

CKL的思考 · 2024年05月31日 · 最后由 Jerry li 回复于 2024年06月06日 · 7958 次阅读

最近和几位测试经理在一起闲聊的时候,提到了一个比较有趣的话题,就是在当前降本增效的大环境下,测试人员如何提升自己的竞争力或者影响力?因为大家都发现了一个问题,很多测试人员过份追求自动化,又没有很好的落地实践经验,也没有锻炼自己处理问题的能力。本文聊点自己的看法。

先提一句比较好玩的谚语:房间里的大象。

我们知道,大象的特点是体积巨大,行动迟缓——假如说,现在房间里如果站着一头大象,那么你肯定是能看见这个庞然大物的。所以这里的 “大象”,是指那些非常明显的、以至于让我们根本无法忽视的事实和真相。那么所谓房间里的大象,说的就是:虽然有些事情就明摆在那里,每个人都知道发生了什么,但出于各种原因,人们却对这些事绝口不提,要么保持沉默,要么用打岔的方式来顾左右而言他,逃避,或者回避。这种奇怪的场景,就像是我们明明知道房间里站着一头大象,却假装对其视而不见,甚至连走路都要小心翼翼地绕开,生怕碰着它。

那么,在提升测试人员的价值,或者说测试人员个人能力提升的场景中,非常明显的 “大象” 是什么呢?个人认为有以下三个基础的内容:

精业务:对于被测系统的业务逻辑,需要有很深了解,才能更好地开展测试活动。不能仅仅停留在页面操作上,知道被测系统,什么是核心功能,什么是辅助功能,哪些业务是不能出错的,哪些业务与周边哪些系统有千丝万缕的联系,能够基于业务流程、数据流程来做测试用例的设计。

同时,需要具备一些探索式测试的能力。能够贴近用户,基于用户的视角进行测试,关注功能点的实际业务价值,从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」,不断地发现新的问题。

懂技术:伴随着软件复杂度的提升,功能测试已无法满足日常的测试要求了。在很多场景下,需要测试人员能够开发一些小工具来帮助自己从有序的、重复的活动中释放出来。比如一些常规的造数、验证等。还有就是自动化测试相关的内容,也需要我们对代码能力有一些了解。

代码能力现在基本上会成为测试人员的必备技能,可能在深度上无法与开发相对比。但是基础的使用、基本的框架和常见的技术栈,都需要去了解和学习。日常测试内部的一些工具研发,还是要能够胜任。在一些专项测试领域,测试人员应该要能够做到对框架十分的了解,比如在接口测试层面,Junit、Pytest 等常见的框架需要知道他们的现实原理,能够进行简单的二次开发等等。

会架构:除了懂技术外,为什么还要会架构呢?因为现在的企业级产品,基本上都会拆成若干个,基于几十个微服务。在这种情况下,如果你不懂架构,不了解这些服务或者组件的特性、通信方式、适用场景,你就很难发现一些深层次的问题。对于被测试系统的技术架构,需要每个测试人员都能够了解并画出来,这样在测试用例设计的时候,也会有更好的针对性。

在这三者的基础上,如果你还能够独立推进和解决问题,那就是个非常优秀的测试人员了。

但在现实中,很多测试从业人员并不认可这些东西,

提起业务,会说大家都是点工,不需要什么测试思维,是个人都能点,但现实是很多人连自己负责的业务系统较全面的数据流都说不清楚;

提起技术,会觉的测试要什么技术,会技术我还做什么测试?但现实是很多时候开发在讨论问题的时候不带上你,是因为你根本就听不懂他们在说什么。

提起架构,更是离测试很遥远,那你不是架构,性能测试又是怎么做的?那些深层次的缺陷又如何能被发现?

很多测试从业者,并不会从这三方面去提升自己,反而越来越迷信各类 “捷径”:搞接口自动化,但是基础的代码能力都没有,做 UI 自动化,PO 模式都没弄明白,只是为了让简历更好看些,但是一问,又说不出什么来,各类前沿名词一大堆,落地时遇到的难点又都没有解决方案,人浮于事。

技巧,只有在扎实的基础上,才能锦上添花。没有扎实的基础,技巧只能让你更快的失败。

先解决 “大象” 的问题,而不是视而不见。

我们要学会复杂的事情简单化,看透问题本身,动作就会变得简单,你就不会做错误的动作,确保自己走在正确的路上。

共勉。

共收到 16 条回复 时间 点赞

感同身受。自认为是一个精业务、懂技术、会架构的测试人员,且在项目管理和团队管理方面也有一些经验。但是面试的时候有很多面试官都过多关注自动化知识,性能测试工具的使用,对底层逻辑和测试策略聊之甚少,岂不知工具只是解决问题的手段,深入理解业务和架构,结合有效的测试策略才是精准测试的根本之道。

技巧不等于技术,无他 唯手熟尔 😀

newman 回复

我觉得和业务的复用性太小相关吧,从 A 业务转到 B 业务,如果是相关的还好,不相干的就了解你大致的测试思路和测试思维就行,自动化、性能更加通用一点吧

写得很棒,从业七年,从以前一味追求技术到现在会主动去思考如何让现网用户用得更爽,如何让技术使团队内部效率提升,虽还没到架构那步;总体都是会围绕业务成功的大方向去努力

sir 回复

实际工作中肯定都是基于业务展开的,自动化或者性能的落地都必须与业务强关联。举个例子:前司的自动化测试一开始是一个单独的部门做,是与测试执行团队独立的,结果开发出来的自动化测试工具在推广和应用的时候效果并不好,还提出了全员自动化测试的口号,结果由于每个人的 coding 水平参差不齐,手工测试的时间还压缩一部分给自动化了,导致测试进度缓慢且产出低。在实际工作中跨行业(指的是完全无关的行业)跳槽的应该还是少数吧,比如我之前是做金融行业的,可能跳槽的时候会找相关的领域的企业,大概率不会去找一个做交换机的公司,这其实也印证了精业务的重要性。

谁能给我用一个例子证明,自动化落地和必须与业务强关联这个有必然的因果关系?什么样的业务如果在人员能力,时间,成本没有任何约束的情况下不能做自动化?

simonpatrick 回复

其实自动化就算不做,对业务上线一点影响都没有,哈哈哈哈

你说的没错的。就是这么个情况。

这个现象只靠自我认知是不够的,想想给测试人员发工资的角色,是什么标准。

过了这些年以后,其实我已经不迷信任何方法论了, 现在就是老板需要什么,我们就去做什么。 以解决老板的问题为最高优先级。

孙高飞 回复

👍 能够解决实际问题,带来切实价值的方法才是好方法,其实方法论在某些时候确实能高效解决,但不一定都凑效。

borys 回复

主要是再好的理论都是需要人来认可和实践的。在公司里老板认为好的东西才能推行下去。 理论很丰满现实很骨感,在现实里是要去解决老板的一个一个的问题的。

孙高飞 回复

解决问题,沉淀流程,把业务和流程梳理好。就是很大的价值体现了。但是解决问题的基本前提是要有对应的业务能力,要能和研发做同频交流。把测试的内核沉淀好。

孙高飞 回复

以目前的职场,你说的是最对的

糯米团 回复

其实再往回倒 5 年, 我还是小愤青,一个理想主义派的时候, 我那会应该会完全不认同我现在的想法😂

测试(test)只是对软件质量检测的一系列手段的结合,从静态测试,文档测试,单元测试,集成测试,回归测试,自动化测试,性能测试等等都是不同阶段和不同类型的测试类型和手段。
我觉得 “测试人员(tester)” 其实应该更倾向于是回归到 QC 和 QA 的身份上面,也就是我们的目的不是为了要测试而测试,而是如果为软件提供质量控制和质量保障。 这里需要的能力,除了上面提到的各种测试方法的掌握, 还需要有敏锐的质量管理意识,为团队梳理质量管理的流程,建立完善的质量体系。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册