我是Dzreal，工作三年的测试开发工程师。以下是我在测试工作中不断总结实践的，测试工程师需要具备一些软实力。

 

先看目录：

一、情商

二、沟通

三、责任心

四、流程控制

五、风险意识

 

这个话题，我相信80%的工程师都不会特别重视，因为这个东西说起来很虚，技术上有那么多东西要学，哪有时间提升什么软实力啊！

 

真香警告：你到底硬不硬，不是你的硬实力决定的，而是你的软实力决定的。

 

 

假如你的技术能力很扎实，你到35岁乃至65岁之后都还有能力写代码；但是你的软实力不行的话，可能你到30岁之后，你就很难在这个行业进步了，你周边刚毕业的同事都在跟你做同样的工作，你又拿什么跟他们拼？你头发还剩多少？

 

在这里，我分享几个我亲身经历的小事，借此跟大家聊聊这个话题，大家也就当听听故事。行文不易，假如对大家有帮助、有共鸣的，欢迎 收藏/点赞/在看/分享。

 

一、情商

要听话，千万不要自大！

 

曾经因为自大，我给自己和团队挖了一个天坑！

 

记得就在毕业第二年的秋天，因为自己会写一些ui自动化的脚本，被划分到部门的自动化效能团队一起做一些测试工具。

 

在此之前，做过一些app的测试，觉得app的埋点测试，手工测试的话，耗费很多精力，但是因为埋点这块又一直出问题，就想做一个工具来“造福”业务测试的同事。

 

当时带我一起做这个项目的领导是刚入职的，对这块也不是很了解，也是硬着头皮跟我一起做这个工具了。

 

方案很快就定好了，采用app抓包的形式，将埋点数据进行拦截，转发埋点数据到测试平台，测试平台做埋点规则校验，再把结果报告展示到测试平台web页面上。

 

当时抓包工具是用anyproxy做二次开发，我在项目中主要负责前端采集埋点数据并转发http请求。后端是我的领导开发。

 

一开始，领导就嘱咐我说，前端的工具，做成命令行就行，越简单越好，做成可配置、可移植的，以后有可能的话，做成平台化的工具。

 

我当时真的很自大，真的要膨胀到爆炸了。没有明白设计为先的原则，也懒得去体会领导的用意，就自己开发自己的。

 

我心里只考虑到，团队的测试同学多是外包同学，给他们用命令行，多难用！考虑到易用性，当然做一个客户端界面（pyqt5），点点点就更方便啦！

 

我几乎通宵做了两个晚上，有一天代码提交出了问题，又修改到了后半夜，那时候真的是感觉很“充实”，做出来成果之后，还发朋友圈自嗨！

 

结果，到演示的时候，可谓瞬间爆炸啊……

 

因为客户端做的太臃肿了，中间出了不少交互的bug，简单的功能被我做得那么复杂，而且距离交付的时间也越来越近，领导瞬间都气炸了，会上直接就发飙了。

 

会后，我又得按领导的要求把功能砍到最精简的样子，当时感觉既挫败又委屈。

 

后来，工具还是交付并且推广了，但由于安装运行环境很麻烦，很多同事都不爱用，非但不能帮助业务测试的同学，还给他们造成麻烦，最后工具就没有推广起来。

 

真的后悔自己因为自大，浪费了自己和大家那么多时间。

 

 

 

二、沟通

能群聊就不要单聊，能文字就不要语音！

 

刚开始进入互联网公司不久，我就接手了一个特别乌龙的需求。

 

这个项目，从活动运营，到开发，到测试，都是刚入职不久的新人。

 

一开始这个只是运营领导一句话的需求，没有产品经理跟进，没有经过需求评审，单纯就是口头沟通，就搞起来了。

 

我当时还是很负责任的，找当事运营也确认了很多遍需求，但是完全都没有意识到这样的沟通很低效。

 

没有沟通群，全靠口口相传；需求改了很多遍，但是需求文档一直是两行字的需求，全靠猜。

 

最后我们终于品尝到了因为沟通问题滋生的恶果！

 

由于我对需求的理解存在偏差，我给开发提了一个错误的“bug”，这个“bug”改完之后，直接使功能的实现背道而驰！甚至影响到了用户流量！

 

在提这个bug之前，我也找运营同学确认过bug的有效性，当时明明都确认这个“bug”是有效的。

 

但是出现线上问题之后，我却成了众矢之的，运营同事当场就“不承认”这个bug是找她确认过的，大家都一致认为这个bug就是我自己给自己“加戏”！

 

我真的感觉跳到黄河都洗不清了，我甚至拿不出任何证据给自己洗白，比窦娥还冤！

 

测试背锅真的很正常，但是我却因为沟通问题，背了我不该背的锅！

 

从那时起，只要是未经过需求评审的一句话需求以及没有详细文字版prd的需求，我都不接；只要是需要我测试的需求，我都会主动拉群，有事都在群里沟通，不再单聊。

 

后来，再也没有出现过这类的问题。

 

 

 

三、责任心

责任心是测试工程师的底线！

 

我在找工作面试过程中，有一个问题被问到过很多次：“你印象最深刻的bug是哪一个？”

细细想来，我碰到过的bug，绝大部分都是显而易见的bug。

 

我还经常抱怨：“开发的代码怎么写得这么烂，连主功能都没走通！能写出这些bug，都不是技术问题了，真的就是态度问题！”。

 

但就是这么简单的bug，在我们的团队里，还是会时不时流露到线上！线上的问题，你能怪开发么？这就是测试工程师责任心的问题！

 

试想假如你负责的项目，线上出现这么“沙包”的主流程都过不了的问题，你再怎么辩解“测试环境中明明是好的啊”，都显得好苍白无力啊！最尴尬的是，线上出问题之后，你再在测试环境中尝试复现，竟然还稳定复现～

 

嗨！兄弟，这就是漏测！

 

相信开发兄弟的水平就是对自己作为测试工程师的责任心的侮辱！

 

自己写过测试用例，一定要经得起用例评审；自己写的测试用例，再怎么恶心都要一条一条执行完毕！不要拿环境问题和测试时间紧迫当自己漏测的借口！

 

你一年干得再出色，出现一两个线上bug之后，所有出彩的地方都会被掩盖，责任心就是测试工程师的底线！我们要时刻坚守住自己的底线。

 

四、流程控制

要敢于对不合理的流程说不！

 

以前手工测试app埋点时，有一个不合理的流程是：测试完埋点之后，还要手写一份测试报告，把抓包的数据填充到测试报告中，然后再写一份邮件，抄送给BI部门。

 

维护这个测试报告的成本十分高，起码占用了50%的测试时间，完了这个测试报告发给BI部门，但根本没人会看！

 

这个测试报告的作用，可能就仅仅是测试人员完成埋点测试的“打卡”操作，并不能给埋点质量的提升带来任何帮助！

 

我当时按这个流程测了2个版本之后，再也忍受不住这种恶心的流程。

 

 

我当即找到了BI的负责人，沟通取消这个流程，因为这个流程对于测试人员来说就是一种羁绊，我们只专注于写这个测试报告，却忽略了测试埋点的意义，总感觉时间不够用，但是埋点测试的质量又得不到提高。

 

后来，经过妥善沟通，我们取消了这个测试报告，我们终于可以不用再忍受这个恶心的流程！

 

从此，埋点的测试不再只是为了完成任务而完成任务，我们可以花费更多时间去验证埋点的数据格式和埋点策略，埋点测试的质量和效率得到很大的提升。

 

五、风险意识

问题越早发现，风险越小！发现bug，一定要提交bug单留存并追踪到底！

 

之前有一个项目需要和别的团队进行合作，我在测试环境中发现了一个非本版本功能改动的bug，当时凭借经验，以为是合作团队的改动引发的问题，并且当时我自己的测试需求还忙得不可开交，就当了回甩手掌柜，把问题丢给合作团队的测试同事去跟进了，然后我就不管了，也没有提bug单。

 

没想到那个测试同事当时休假了，事情一直得不到妥善解决。

 

凭借经验，我也仅仅以为是环境或者账号的问题，也并没有重视这个问题。

 

等这个同事回来的时候，时间已经接近发版了，这时才发现这个问题根本不是他们的问题，而是我们连接他们服务的时候，这个版本的传参有问题，但是由于我并不知晓这个改动。

 

我发现这个问题，一没告知我们的开发，二没提交bug单，除了我和合作部门的测试之外，其他人对这个bug都不知情......导致这个bug差点就流露到线上去。

 

现在想想都还后怕！

 

任何bug，不管多小，都要bug单留存，并且要追踪到底！

 

▼▼▼

 

分享的几个我测试生涯中的案例，也是想强调软实力（情商 + 沟通 + 责任心 + 流程控制 + 风险意识）的重要性，其实还有诸如管理能力、演说能力也都包含在软实力里面，具备这些软实力能让你在职场走得更远！

 

延伸阅读：写给工程师的十条精进原则

https://tech.meituan.com/2018/08/16/10-principles-for-engineers.html​

 


长按识别下方二维码关注公众号

关注我的微信公众号【测试开发Guide】，

 

回复「java」：即可获得java经典学习资料（我花200元买的），带你轻松入门java编程。

回复「python」：免费获取「python入门」高分好书，业余时间偷偷变牛逼。

回复「面试」：24个常见的测试面试题，你一定不想错过。