怎样做一名合格的测试工程师

前言

距离上一次写博客已经很久了，来瞎扯点东西，谈谈在我这个菜鸟程序员眼里，测试工程师到底应该做什么？

公司前段时间有过人事变动，一个新来的测试工程师（还未转正）被公司裁了。因为之前是我在和这位测试合作，因此他找到我希望我和他谈谈他在工作中有什么问题。

实话实说，这位测试老哥是不配“工程师”这个称呼的——就像只会画画原型图的人不配被称为产品经理一样。我想人家都要离职了，况且都是做技术的，也不妨给了点建议，希望他在以后的职业生涯中能走得顺利点。

测试工程师之路的开始

我对技术人员的定义的一个核心观点是：他的工作是否能够被非技术人员替代。比如说，一个不懂技术但是能说会道的产品经理（又黑产品）能否让一个经验老道的销售或者运营替代？测试时只会点点画面看看结果是否正确的测试人员能否拉一个知晓这块需求的运营来兼任？问题的关键就在这里，你的职位叫做“测试工程师”，那你就必须有胜任“工程师”这个称号的能力。

就我有限的观察而言，我所见到的、听说的创业公司的测试人员无非就是写写测试用例、点点画面、看看结果，能力稍强的会用一下Postman做一下模拟请求、抓个包看一下应用的接口返回结果，但是也就止步于此了，况且抓包和模拟请求只是对工具的应用而已，还远远谈不上会一门手艺。话说回来，在培训班大行其道的今天，你都不能指望你们团队的Android开发人员会抓包。

因此，对于一个测试人员来说，学会使用工具是成为一个“工程师”的开始，你可能还不知道GET请求有长度限制、不知道签名验证是怎么回事，但是不重要，起码你知道怎样才是测试的正确姿势了，而不是一昧的点击应用上的按钮。

描述问题的能力

大部分学习理工科并且工作内容也与理工科相关的人都有一个特点：说话办事都喜欢遵循一定的逻辑，譬如我们目前谈论的这件事发生问题的场景是怎样的，前置条件是什么，后置操作会产生怎样的副作用。这样的沟通模式下，问题可以得到很快的定位，解决方案的大致雏形也会在沟通中慢慢形成。

对于测试工程师来说也是，程序是人写的难免会出Bug，但是也是因为是某个程序员写的，他对于内在的逻辑、可能发生问题的地方会有一个大致的判断。测试工程师的工作就是，告诉他发生问题数据的ID、发生问题的场景、当时的测试数据是怎样的等等。而不是，把一个截图甩给程序员，说：“这地方出错了啊。”

基础代码能力

如何增强对逻辑思维的锻炼？写代码啊，又学一门手艺又得到了大脑的锻炼，岂不是美滋滋？

貌似很多测试工程师都喜欢去学Python这门语言，确实这是一门对于代码入门者非常友好的语言，但是包括那位测试小哥在内都有一个困惑：学了Python能干嘛？我的建议是从写爬虫开始，学习爬虫的编写可以接触到网络请求的基本知识、可以学习到正则表达式，需要爬取大量数据时还可以顺便学习一下数据库的使用，当然了对于爬虫来说学习一下非关系型数据库就可以了。这一方面是为自己学习自动化测试铺路，一方面也可以为以后转岗提供换一个后路：不做测试了我干脆去写代码好了。

乐观的心态

测试工程师每天面对的是程序中的“错误”，而程序员每天都在创造代码。起码我作为一个垃圾代码的创造者，是很讨厌去排错的。因此就我而言，测试时你很难保证心态的平和，因为你不知道什么时候会出一个莫名奇妙的错误。

假设这么一个场景，你测试出了一个bug，但是程序员自测之后发现无法复现，你的第一反应不应该是脱口而出：“不可能！”而应该是比对两个人的测试用例，发现可能存在的问题。