最近和几位测试经理在一起闲聊的时候，提到了一个比较有趣的话题，就是在当前降本增效的大环境下，测试人员如何提升自己的竞争力或者影响力？因为大家都发现了一个问题，很多测试人员过份追求自动化，又没有很好的落地实践经验，也没有锻炼自己处理问题的能力。本文聊点自己的看法。
先提一句比较好玩的谚语：房间里的大象。
我们知道，大象的特点是体积巨大，行动迟缓——假如说，现在房间里如果站着一头大象，那么你肯定是能看见这个庞然大物的。所以这里的“大象”，是指那些非常明显的、以至于让我们根本无法忽视的事实和真相。那么所谓房间里的大象，说的就是：虽然有些事情就明摆在那里，每个人都知道发生了什么，但出于各种原因，人们却对这些事绝口不提，要么保持沉默，要么用打岔的方式来顾左右而言他，逃避，或者回避。这种奇怪的场景，就像是我们明明知道房间里站着一头大象，却假装对其视而不见，甚至连走路都要小心翼翼地绕开，生怕碰着它。
那么，在提升测试人员的价值，或者说测试人员个人能力提升的场景中，非常明显的“大象”是什么呢？个人认为有以下三个基础的内容：
精业务：对于被测系统的业务逻辑，需要有很深了解，才能更好地开展测试活动。不能仅仅停留在页面操作上，知道被测系统，什么是核心功能，什么是辅助功能，哪些业务是不能出错的，哪些业务与周边哪些系统有千丝万缕的联系，能够基于业务流程、数据流程来做测试用例的设计。
同时，需要具备一些探索式测试的能力。能够贴近用户，基于用户的视角进行测试，关注功能点的实际业务价值，从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」，不断地发现新的问题。
懂技术：伴随着软件复杂度的提升，功能测试已无法满足日常的测试要求了。在很多场景下，需要测试人员能够开发一些小工具来帮助自己从有序的、重复的活动中释放出来。比如一些常规的造数、验证等。还有就是自动化测试相关的内容，也需要我们对代码能力有一些了解。
代码能力现在基本上会成为测试人员的必备技能，可能在深度上无法与开发相对比。但是基础的使用、基本的框架和常见的技术栈，都需要去了解和学习。日常测试内部的一些工具研发，还是要能够胜任。在一些专项测试领域，测试人员应该要能够做到对框架十分的了解，比如在接口测试层面，Junit、Pytest等常见的框架需要知道他们的现实原理，能够进行简单的二次开发等等。
会架构：除了懂技术外，为什么还要会架构呢？因为现在的企业级产品，基本上都会拆成若干个，基于几十个微服务。在这种情况下，如果你不懂架构，不了解这些服务或者组件的特性、通信方式、适用场景，你就很难发现一些深层次的问题。对于被测试系统的技术架构，需要每个测试人员都能够了解并画出来，这样在测试用例设计的时候，也会有更好的针对性。
在这三者的基础上，如果你还能够独立推进和解决问题，那就是个非常优秀的测试人员了。
但在现实中，很多测试从业人员并不认可这些东西，
提起业务，会说大家都是点工，不需要什么测试思维，是个人都能点，但现实是很多人连自己负责的业务系统较全面的数据流都说不清楚；
提起技术，会觉的测试要什么技术，会技术我还做什么测试？但现实是很多时候开发在讨论问题的时候不带上你，是因为你根本就听不懂他们在说什么。
提起架构，更是离测试很遥远，那你不是架构，性能测试又是怎么做的？那些深层次的缺陷又如何能被发现？
很多测试从业者，并不会从这三方面去提升自己，反而越来越迷信各类“捷径”：搞接口自动化，但是基础的代码能力都没有，做UI自动化，PO模式都没弄明白，只是为了让简历更好看些，但是一问，又说不出什么来，各类前沿名词一大堆，落地时遇到的难点又都没有解决方案，人浮于事。
技巧，只有在扎实的基础上，才能锦上添花。没有扎实的基础，技巧只能让你更快的失败。
先解决“大象”的问题，而不是视而不见。
我们要学会复杂的事情简单化，看透问题本身，动作就会变得简单，你就不会做错误的动作，确保自己走在正确的路上。
共勉。
PS：最近因为工作的原因，本公众号停更了2个月，感谢大家的不离不弃。从今天起恢复周更，同时也会把最近工作上的沉淀和思考逐步总结并在公众号上分享。
往期推荐：
自动化测试落地为什么那么难
测试人员的价值体现
接口测试这么玩才明白
如何高质量的做BUG分析
质量团队在忙什么
常见技术类缺陷及解决方案
迭代测试发现不了问题，怎么办
接口自动化不是救命稻草
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/416812.html
