刚入行的测试工程师如何自学软件测试【下篇】-- 软实力

子曾经曰过：“这个bug在测试环境中没有啊！”

大家好，我是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单留存，并且要追踪到底！

▼▼▼

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

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

最后： 可以在公众号：伤心的辣条！免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。你可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

好文推荐

转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！

面试经：一线城市搬砖！又面软件测试岗，5000就知足了…

面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作？

那个准点下班的人，比我先升职了…

测试岗反复跳槽，跳着跳着就跳没了…