在国内，测试就是“低人一等”
产品和开发，往往视测试为“保障部门”
举几个例子：
1、开发交付产品给测试，说的是：点点看，看下有没有问题。产品过来补刀：时间比较紧，半天时间够了吧？
2、多轮迭代之后，用例库存下了巨量的测试用例。老板希望每次上线，你都来一遍回归测试，你质疑能否发现新的缺陷，可你又说不出所以然来；
3、产品上线了，运行过程中出现一个生产问题，最后反馈到你这里，你恍然大悟：艹（一种植物），为什么如此简单，当初却没有想到？
不得不承认，很多测试工程师，太水
或者说，大部分的“点工”，都不能称之为“软件测试工程师”
回想一下，培训机构的宣传是不是写到“测试很好入门，上手很快”、“做测试不用写代码”、“做测试不用加班”、“做测试没有年龄限制，越老越吃香”？
你搁这儿清明烧报纸，糊弄鬼呢？
这种局面下，又何谈测试人员的能力，何谈核心竞争力，何谈能够被团队所重视呢？
那么说，什么才是软件测试工程师的核心竞争力呢？
懂业务、懂技术、懂架构
懂业务要求能够从用户的角度，通过测试设计保证业务质量；
懂技术要求具备一定的技术水平，能够通过技术设计去提升质量和效率；
懂架构要求能够认识和识别架构中的质量和风险，保证产品需求和用户需求，以及后期产品发展的需要。
但是目前国内各个层级的测试工程师均具有非常明显的“痛点”：
功能测试工程师，很多情况下不懂业务，工作中更像是盲人摸象，而且做功能的，往往刚入行不久，会被第一份工作的业务所限制。换句话说，就是很有可能离开这个领域，又是从零开始。因此功能测试的核心竞争力在于，对产品的理解，对需求的理解，以及产品背后的实现逻辑。
性能测试工程师，痛点在于很多场景下只会套用工具，只会跑出数据，具体怎么分析数据，进而调优，就熄火了。举个例子：
我拿到了一份“流氓”的性能测试报告，上面只写了响应时间、TPS是多少，然后罗列了一下压力机基本配置情况，比如40个并发相应时间是5秒，TPS是260。
那么，我该怎么判断这次性能测试的有效性：
1.场景是否合理？
2.压力是否传递均匀或者传递到指定目标？
3.是否有干扰因素，或者说那些数据是否有效？
4.有没有一些可信的判断方法？
这些问题的出现，其实就是反映出了目前在做性能测试的一些误区：
- 只测不调，无法给出研发和运维人员执行建议
- 无法定位问题，缺乏清晰的逻辑和数据证明价值
- 性能测试工具≠性能测试
- 性能测试技术体系落后（loadrunner），急需拥抱开源软件
自动化测试工程师，自动化测试的魅力在于围绕产品提升效率，而不是只是将手工测试用例转化为自动化测试用例。
功能测试往往非常推崇去做自动化测试，因为他觉得这是新的提升效率的方法；
自动化测试却想的是能够多了解一些业务，多了解一些产品；
本质上他们都在追求自己当前角色下所不具备的能力。
这是好事，但是也是坏事，坏就坏在盲人摸象始终是局部看法。
因此自动化测试工程师的核心竞争力一定是围绕产品质量，提升测试效率，通过不断的技术创新、应用，不断提高测试整体流程能力。
测试开发工程师，对于想进阶到测试开发的从业者来说，最大的短板在于开发技能的不足，首先很多做测试的都是半路出家或者非计算机专业，对于编程语言等基础知识是比较薄弱的，因此做测试开发需要大量的开发工作积累。
做开发工作并不是说会语言，真正的开发能力，一定是来自于项目实践。
有人问测试开发是懂测试的开发，还是懂开发的测试？我更倾向于是懂开发的测试。市面上不缺优秀的开发人员，但是能够从测试的角度，去提炼测试的需求，并把遇到的难点，结合业务做成提高效能的工具，这样的人才是非常稀缺的。
因此测试开发的核心竞争力，一定是是对测试的生态的理解，以及对工具需求的提炼，以及把这些提炼出来的需求以最简单的方式最容易落地的方式来做实现。
因此，我给测试从业者的建议就是：
1、培养全面的测试能力；
2、建立良好的质量意识；
3、拓展测试技术的深度与广度。
版权归原作者 阿九-进取的测试er 所有， 如有侵权，请联系我们删除。