测试工程师到底应该作什么？

测试工程师到底应该作什么？

周煦辰 2017-05-21

前言

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

公司前段时间有过人事变更，一个新来的测试工程师（还未转正）被公司裁了。由于以前是我在和这位测试合做，所以他找到我但愿我和他谈谈他在工做中有什么问题。

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

测试工程师之路的开始

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

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

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

描述问题的能力

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

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

基础代码能力

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

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

乐观的心态

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

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

就说这么多，祝各位在警察部一路顺风，干杯各位长官！