浅谈测试技术落地

最近在testerhome看到一个帖子，大意是一些测试同学吐糟《测试开发者大会》上分享的技术过于脱离自己实际工作，从而无法根本无法落地，从而引起激烈的讨论。

在过去这些年里，我被问到最多的问题，恰恰也是学的技术无法落地。以至于"自动化"等技术都成了玄学，一部分人在公司用的很好，一部分人一直在质疑他的价值。

我从来不觉得一个技术无法在自己的工作中落地是问题，或者说是技术的问题。

在测试从业的是十几年间，我学的太多技术，也忘记了太多技术，例如，我已经好多年没有碰LoadRunner了，甚至他里面的功能我已经忘记的差不多了，但是，我在刚做测试的头几年性能测试还是一个"高级"的测试职位，再加上工作中有一些性能测试的需求，当时就非常热衷于学习相关技术，我甚至看了当时能找到的所有的关于性能测试的纸质书和电子书，如果看我早期分享的博客，能明显的发现这一点。

放到现在的微服务架构下，性能测试变成了后端接口性能测试、Web前端性能测试 和 App专项测试，再加上云服务普及，LoadRunner这种又大又重的性能工具就很少被大家提及了。

后来就是把重心转向了自动化技术，学习python语言和 selenium自动化工具，之前的文章中也有说明，学python的主要是因为公司业务是用python开发的，学会python不但可以做自动化，对于业务功能的实现也会有帮助。

再之后因为业务的需要转用PHP/PHPunit编写接口自动化项目。测试代码和业务功能代码同时维护，不但能更早地发现问题，也很大程度上降低了维护成本。

转测试开发去做平台开发又学了大量的web开发技术...

回望过去的经历，我学过很多技术，有些压根没用到公司项目中，有些短暂的使用过，有些到现在还在用。就算我不用了，也并不能说明这个技术一定是落后了，或者太超前了，只是因为他不适合我们公司的当前业务而已。

如果你很在意落地，就找个能落地的公司。

我曾短暂的待过一家偏金融业务的公司，公司的业务很复杂，刚加入学习业务的一段时间一度怀疑自己的能力，尤其看到同时加入的同事比自己学的快。因为是业务型的公司，所以，把业务梳理清楚，能从业务中发现bug，就是测试最大的价值。当然，公司也有基于robot fromework实现自动化，这个时候，自动化的难度不大，如果基于工具编写业务测试的难度却要远远高于自动化技术本身。

因为业务的特点，加上已经沉淀下来的流程，很多新的测试技术并无用武之地。

• 如果你本身比较擅长业务，敏锐发掘业务功能bug，并以此找到自身的价值，当然是选择继续。

• 如果你很喜欢和擅长新的测试技术，并期望他在项目中落地，当然是选择离开了换个公司。

你认为某个公司分享的某个技术不能落地，是在瞎吹牛~！好了，赶快跳槽去他们公司。看他们到底是否在吹牛。如果只是因为在你所在的公司不能落地，那不是很正常的事情嘛！否则所有公司用的技术一摸一样，你觉得这正常吗？

后来，重新跳回到互联网公司，我突然觉得我又行了，哈哈~！

重复造轮子，并不是坏事。

另一个经常被吐糟的话题是重复造轮子，造各种测试平台。

首先，我不觉得测试平台本身有错，否则，JIRA、pingcode、ones这些研发项目管理平台也不应该存在了。他们或多或少也包含了一些测试相关的相关的功能，测试用例管理、测试bug管理，甚至是自动化测试。测试平台 只是把测试相关的功能独立出来，专注服务于测试团队。

问题在于，很多公司不足以供养一个独立的测试平台开发团队，你们的测试平台有项目经历、UI/UX设计师、产线经理和功能测试吗？ 我相信绝大部分没有。单凭会一些开发的测试做出来的产线，能指望他有多好用，而且还没有足够的时间投入迭代。

如果，单纯的学习测试平台开发，我并不认为有什么问题，怎么，合着老美造了原子弹，就不允许我们造了呗！？ 从这个角度，学的人越多，就促进了整个测试从业人员的水平提升。

问题出来，功能简陋，无法做到长期维护，还非要拿出来往业务测试团队推广，还非要拿来开源，还非要到处炫耀！这应该就是许多人反感重复造平台的原因。

我的观点： 保持学习新技术并没有错，尤其是处在IT行业，大到整个行业的技术进步离不开从业人员的技术进步；小到个人的升级加薪也离不开个人的技术成长。