今天朋友发来一份所谓难度适中的软件测试面试题，字里行间里
充斥着各种自动化测试工具和脚本代码，看完之后一脸茫然，感觉自
己像刚入行的萌新一样。随后拿着这份试题向几位师兄请教，师兄也
是看的一知半解。于是我跟朋友讲这份面试题挺难的，而朋友却给出
了他同事觉得试题难度适中的聊天截图，这不禁让我思考一个问题：
怎样才算一名优秀的测试人员？我想每个人对于这个问题都有自己
不同的答案，因每个人的思考方式和工作经历不同而不同。下面我也
谈谈自己对于如何成为一个优秀的测试人员的一些粗略看法。
1、逻辑思维很重要
从入行开始，身边的前辈和接触到的所有的测试大牛的文章都在
强调：逻辑思维很重要。测试人员每天身处在需求文档、复杂的程序
代码和各式的设计稿中，清晰的思维能使我们更全面的解读需求文
档，并设计出合理的测试用例，这样才能保证产品的质量。良好的逻
辑思维也能让我们更好的与产品和开发同学进行交流，从而提高工作
效率，避免线上出错。
2、灵活的工作方式
生活不是电影，不会按照剧本一成不变的演下去。这句话同样也
适用于软件测试工作。我们在工作中会遇见各种突发或者没有遇见过
的情况，这时候就需要我们学会灵活变通。举个栗子：领导分给你一
个比较紧急的功能需求，没有需求文档，没有交互和视觉设计稿，只
是简单跟你描述一下这个需求的大概情况 ，并且时间紧迫，我们该
怎么办呢？这时就需要我们灵活变通一下，没有文档和设计还有产品
的嘛！我们可以向产品详细的询问需求的各功能点，并将这些功能点
都记录下来，然后进行接下来的测试工作。诸如此类的情况在我们工
作中会经常遇见，灵活多变的工作方式能够让我们更好的应对这些突
发情况。
3、基础很重要
随着这两年自动化测试的兴起，很多公司和测试人员都在盲目的
追求掌握更多的自动化测试工具，而忽略了软件测试的基础。我们不
妨想一想，我们掌握了多少测试方法，我们能够怎样更全面的编写出
最合理的测试用例，如何准确的定位 BUG 的归属性，软件技术的基础
知识我们懂得多少，是否详知整个软件测试工作的业务流程。每个公
司对于软件测试工作的规划都是不一样的，但是软件测试基础都是通
用的，熟练的掌握软件测试基础只是，能够让我们在进入一个新环境
中更好适应工作。我们试着回忆一下，曾经学习的 Linux 命令和 sql
语句还记得吗？还能熟练运用性能测试软件吗？
4、懂一些代码
这里的懂一些代码不是说让会写程序代码，而是要求我们在测试
的过程中，学会运用 firebug 或者 fiddler 等抓包工具查看接口请求
和响应结果，我们要看得懂这些请求和响应返回的结果，这样能够更
好的去定位 BUG 的归属性，判断它是前端还是后台的问题，而不是将
这个问题暴露出来让前端和后台盲目的去查询。这样既能提高工作效
率也能减少开发同学的压力。
同样我们在部署测试环境的时候，服务出现了问题的，我们可以
运用 xshell 等终端模拟器通过运行 Linux 命令来查看服务器运行状
况，准确的找到服务出现的问题，再将问题暴漏给开发同学，我想没
有哪一个开发会不喜欢一个能准确判定程序问题的测试同学了！
5、进阶高级测试
不盲目的跟从并不代表不去学习，当我们在软件测试行业有了一
定程度的积累之后，这时候我们需要去更高一级的测试领域去探索学
习。自动化测试工具、脚本语言、搭建测试环境、规划软件测试整体
工作、设计测试方法等等。
6、了解测试市场的发展
互联网行业是一个年轻的行业，也是一个走在时代前沿的行业，
层出不穷的产品和不断更新的程序语言，促使着测试方法和测试工具
也在不断的进化，了解更多的测试工具，掌握更多的测试方法能够更
好的提升我们自身的价值。
以上就是我对软件测试工作的一些浅薄的看法，也算是这两年多软件
测试工作的一些总结。突然觉得，有时候，不定期的总结也能很好的
认识自身的不足，在以后的工作中能更好的完善自己！
职场小故事（1）没有需求如何破（二）
可能我们在看各种前辈总结一些面试题的时候，经常会被面试官问
到，如果要你测试一个功能模块或者是系统，但是没有任何需求，你
会怎么做？
Excuse me? 没有需求我怎么做？！这不科学啊！
如果你是上面的这个想法，那么恭喜你，你已经被教科书给迫
害了。当你真正的进驻一个项目组的时候，没有需求但是要你去做一
个详细测试或者是写测试用例，这个是家常便饭好嘛~！就是现实版
的：来不及解释了，快上车！
所以，如果我们面对这种没有任何需求没有任何解释的系统或者
是软件需要做测试的时候，如果你什么都不做，只是按着自己的感觉
来做测试，那迟早会出现 bug。
1：没有需求，尽管你是多年的老司机或者是初入测试神坛的新手，
都应该提前做好产品的调查，知道有哪些功能？功能具体会怎么实
现？我要如何测试？有哪些细节点需要做测试？---然后把所有想到
的都写好测试点 OR 测试用例。
2：有些功能没有出现在需求说明书里面？需求说明书，有时候不会
特别详尽的写出来，就需要我们自己多去挖掘可能存在的隐藏测试
点，想的越多，怀疑的越多，出现 bug 就会越少！
3：任务紧急，来不及写测试用例？不管多紧急，为了不让自己老是
在同一个功能模块兜兜转转的反复测试，最好把测试点罗列出来，按
点来进行测试。如果你仔细观察下，就会发现，如果你不写个测试点
列表，你就永远在一个功能模块进行测试，总觉得会有问题，不敢进
行下一个模块的测试。
这个就是真实的职场小故事，当你真的遇到这个情况的时候，一定要
记得有无需求有多紧急，一定要写好测试点!!
职场小故事（2）：不会用搜索引擎，怪我咯(三)
场景
可能有很多同学长期混迹各种高手群各种软件测试群，加入这些群之
后第一句话就是：大家好，我有一个问题想要请教，问题如下：
xxxxxxxxx,还望高手不吝赐教，拜托啦！
还有的人就是：直接抓住群主就问，在吗？能够帮我看一个
问题吗？
巴拉巴拉巴拉巴拉~~各种问问题，甚至还有一大幅截图的英
文，希望你能够帮他翻译。 不过，我可以很明智的告诉你，群里大
神一般都很忙，不会看到你的问题；再者即使大神看到了问题，如果
不是可以讨论的的问题技术，而是那种非常简单的可以自己百度解决
的问题，果断忽略之。当然，可能部分加入柠檬班群的同学会得到我
们老师的解答，但是：在柠檬班得到的待遇是别的地方得不到的！
因为对于任何一个人，如果问了问题，一定会是这样的对话：
第一步：你好，大神，可以帮我回答一个问题吗？--大神回答
之。
第二步：我还有一个问题，可以顺便回答一下吗？--大神再次
回答之。
第三步：为啥是这样的，你看我的就这样不行，于是各种强行
截图截屏截屏代码，要别人给你看，还不一定得到你的一句谢谢-- 于是大神答之：请百度。
第四步：因为没有得到答复，开始说不会就不会，装什么大神。
这就是我遇到过的现实版本的：农夫与蛇。
因为被各种问题困扰不堪，但是这些问题不管是小白还是高手，
其实都是可以自己百度或者 Google 解决的。
如何解决
案列：如何使用 Postman
1:不知道 postman 是啥？百度输入：什么是 postman,百度到如下内
容：
2:要使用 postman,就要安装 chrome，接下来就是去百度：
chrome 离线安装包
如何在 chrome 上安装 postman 插件
【至于为啥离线，你懂得】
3：都弄好了，因为 postman 是要测试接口，那接下来就要找一个接
口来测试呀？不需要弄懂接口是什么，因为很难弄懂。你就百度：免
费 api 接口
【如果不找免费的，人家公司的接口根本不可能给你测试的！】
4：开始找教程并开始学习，最好能够把自己的学习历程和经验都可
以总结起来，作为自己的学习笔记。
轻松 4 步搞定，可能操作过程就是 4 步，但是实际上可能要曲
折，只要你你能够定位到问题，就一定可以找到问题。
太多时候，你习惯了张口就来的答案，失去了自学的能力。
与其去各个群乞求答案，自己寻找答案会来的更快！
职场小故事四:XX,你的代码有 BUG（四）
最近项目朋友圈，项目讨论群都在发这样一张图
虽然这张图带点戏谑的成分，但确实折射出大部分 IT 公司测试人员
在报 bug 时，与开发的沟通存在些许问题。如何更有效地说服开发接
收你的 bug，以下咨询资深老鸟给你们一些作为新人的建议：
1、首先确定这是一个个实实在在的 bug。
不要出现因为配置原因或者是操作错误引起的“bug”，这样是会
被开发“鄙视”的。比如说柠檬班学生在测试过程中就发生过这样的
事情，短信平台没有配置，手机接收不到短信直接就提交 bug 了。作
为测试人员应该尽量做到专业，尽量少给开发找麻烦，不要制造一些
并不存在的 bug、不要提交一些重复的 bug。
2、写好 bug 描述。确保依照 bug 描述能重现 BUG 的过程。
这很重要！有时候开发看到一个莫名其妙的 bug，描述不清楚，还
无法重现，他会很生气。这直接会影响测试人员在开发心目中的形象。
我们既然提交这个 bug，就必须对它负责任。Bug 描述精确、没有歧
义，详细简洁的重现步骤，bug 截图是必须的。如果是特殊的测试数
据，我们还需要附带这些数据。比如说 2049KB 的图片数据。对于重
现率很低的问题，我们需要注明偶现，详细记录当时的环境信息。如
操作系统、产品名称、版本、操作步骤、是否机器相关、是否产品相
关等。
3、提升自己的专业技能。
我们应该尽量提升个人技能。我不是说要学习什么测试框架、什
么自动化性能测试工具，这在以后都可以学习。我们要先保证最最基
本的，就是对业务分析的能力。要充分熟悉我们软件产品各个层面的
业务，包括功能业务，代码实现逻辑，环境配置部署等。如果你了解
到类似充值这种操作，是必须要有真实接入的第三方支付平台接口，
那么你就清楚为什么在测试的时候会出现支付页跳转界面异常的提
示了，自然而然也会清楚这不是代码的问题，而是没配置。你就不会
出现第 1 点中的问题。而且在说服开发接受你的 bug 时，才会更加做
到有理有据。
4、测试应把握重点。
测试应把握重点，不要在无关紧要的地方测试过多，也不要为
了无关紧要的所谓的“bug”浪费沟通成本。什么是重点，就是产品
的主要功能，用户经常会用到的操作。如果是需求明确的严重问题，
我相信只要是开发，他都会想法设法去修复它。但比如说，一些非常
规操作导致的严重问题，开发人员会说，实际场景中，用户是不会这
样操作的。对于这些问题，沟通是很浪费成本的，可以把问题记录在
日报中，反馈给测试老大或项目负责人，由他们来评估。再比如说一
些个人界面建议，我们可以提交 bug，但是开发不改，也不影响用户
使用的，我们不用过多纠结。
5、问题集中起来咨询开发
开发也很忙，不要一发现跟预期不清楚的就直接发个 qq 消息
过去。因为在忙的情况下，很大程度上你抛过去的问题都会石沉大海。
把你个人需要问的问题做一下整理，集中起来问开发。为了沟通的高
效率，最好是跟开发进行面对面的交流（除非你需要保留截图证据）。
跟开发约个时间，直接去办公位找他。如果你是颜值一派或是性格可
爱派，这种方法尤其可行。
6、做个聪明的测试人员
a、注意跟开发沟通的语气
要有换位思维的方式，做事情对事不对人，处理事情一定
要有一颗宽容的心。只有这样，才能够很好的说服研发去修改 Bug。
b、和研发人员搞好私人关系。
一旦关系好了，啥话都好说，他也不会觉得你烦。但是别
因为关系好，bug 就直接口头叙述，不提交到 bug 平台做好统计记录。
以上主要是对于测试人员的建议，希望对你的职场有所帮助。不论是
测试还是开发，都是为了更好的完善产品，多站在对方立场想一想。
我们生活依然是很美好的呢~~ 如何巧妙利用碎片化时间来学习（五）
碎片化这个概念，其实最早是在华华看到某一篇文章，说利用碎片化
或者是空隙的时间去给你的朋友打电话，这样时间到了你就可以不用
继续找话题聊，就不会尴尬。
比如说你可能经常会这样跟你的朋友说话：我公交车到了，先
不说了；我电梯到了，先不说了；我地铁到了，先不说了；我在火车
上，到家后再说；先吃饭啦，等会再聊；
是不是觉得这些场景很熟悉？但是随着这些碎片时间的利
用，其实人与人之间的关系越来越远！所以华华是不赞同利用碎片化
时间来联络感情的！那么我们可以利用碎片化时间来干嘛呢？
送大家两个字：学习。
在公交车上&地铁上的时候：
当然早上挤公交的时候就算了吧，那种场景下，碎片时间太
多估计你们也没有办法学习。建议大家早起，以前我就经常这么做，
会把需要学习的视频存在手机上，然后看视频学习，慢慢的提升自己，
华华的性能测试基础学习就是在车上打发的时间学习的。不用担心别
人的眼光看你，也不用担心其他的，早点起来，公交车上人不多，看
书别有一番感觉。
后面换工作啦，要做地铁大概 50 分钟，如果不找点时间做，
真的很无聊，很无聊！所以就买了一本性能测试的书，半年内看完了，
现在也获得了这个知识和技能。当然所有的学习并不是你看书就能解
决的，还需要自己在项目实战！
中午吃完饭准备午休前：
工作日，每天中午吃完饭我都有一个习惯站 30 分钟，这 30 分钟都
是属于我的个人时间，我一般选择的是看书或者是看学习视频，每天
累积 30 分钟，一个月后你会发现你多看了一本书或者是多了一门技
能！
等人的时候：
有木有发现等人的时候，很容易变得有点急躁，会觉得时间一分一秒
都很漫长，那么这个时候你试一下看看书或者学习视频，反正闲着也
是闲着，你会发现 30 分钟原来这么短！这个方法尤其推荐给有女票
的男士，你懂的。
睡觉前：
晚上看书我觉得很好，我就很喜欢。睡前看 10-30 分的书，让心
情平复下来，更加有助于睡眠，而且这是上班族业余学习的好时机，
每天十几二十分钟，日积月累，可以学很多东西。只是不要看入迷舍
不得睡就行。
时间一般挤挤就有了，现在互联网行业加班多，能够找时间看看
书学习简直就是一股清流啊~因为多学点技术，你自己的薪资就会蹭
蹭蹭上涨，如果多看点书，发现你跟不同的人聊天除了泡沫狗血剧，
还可以聊点文学，技术的。
**********************************************************************************
微信咨询 ：jcb-2017
微信+17031115530，拉测试微信群交流
网友评论