您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

资深测试老司机经验总结:什么才是软件测试工程师的正常心态?

发表于:2019-02-15 作者:柠檬班软件测试 来源:今日头条

干软件测试这行已经许多年,见过刚刚开始工作的测试人员,也见过一些非常资深和优秀的测试人员,也见过不少无法成长起来的测试人员。

很多测试人员技术背景很强,操作能力也不错,但就是很难发现问题,为什么呢?我们就来谈谈怎样执行好测试吧,需要培养哪些能力。

工作态度和技术背景就不去说它了。

做任何工作都要有好的工作态度,如果只是想混日子,无论做什么工作都不会有长进的。技术背景当然也是需要的,测试人员可以不如开发人员深入。比如开发某些协议的时候,开发人员往往对rfc已经倒背如流,测试人员没必要做到如此熟练。

那么,除此之外,测试人员需要培养哪些能力呢?

我见过不少测试人员,他们非常渴望case能pass。如果一个case由于某种原因被block了,或者fail了,他们都表现出沮丧,或者嘲笑开发人员,认为这给他们的工作带来了麻烦。

如果一个case顺利地pass了,他们都欢天喜地,觉得总算完成了一个工作,可以对经理有交代了。可是资深的测试人员不是这样的。他们渴望的不是pass一个case,而是通过这个case,帮助开发人员找出更多的问题。

当问题出现的时候,他们很兴奋,而不是沮丧。

他们会寻根究底,来考察为什么会有这个问题,如何来解决这个问题,如何来改进测试计划发现更多类似的问题,等等。当一个测试人员渴望做完一个 case的时候,他往往下意识地会忽略很多他本来应该发现的问题。只要操作能继续,大的错误不出现,他们就不会去主动寻找错误。

我记得某部门有个老外刚来,就报了很多的bug。大家发现,他报的很多bug,大家以前也碰到过,但因为不影响测试过程,不认为这是bug,就都忽略了。

但其实有些bug是很严重的问题,比如系统的CPU突然被长时间百分百占用,内存泄漏,状态显示和真实情况不符,等等。到了用户那里,都会成为用户抱怨产品的可能。

那个老外曾经也指导过我做平台集成测试,在他的指导下,我两个礼拜报了十多个bug。有一个我记得很清楚,就是扩展卡的以太网接口顺序与主机上的相反。主机上的网口是从左往右递增,而扩展卡上的是右边为1,左边为2,而且没有在机器上标注。这样就很容易造成配置错误。

我一开始碰到这个问题,就认为是自己的问题,为啥我没配对呢?但是老外说,你也是用户,你没配对,用户也不会配对。到了用户那里,这肯定就是一个bug。很多人都很不喜欢做集成测试,因为软件还没有准备好,测试case运行非常不顺利。我发现这么多bug的时候,其实真正的case一个也没跑成。我一直停留在安装和基本配置上。

但我一点也不气馁,反而在这个过程中发现了很多问题,对于最基本的系统启动和安装也有了很多深刻的认识。一个测试人员能够很快成长起来,不是靠他能够顺利地完成测试任务,而是要遇到很多问题,在问题中求成长,在问题中寻找答案。

测试人员的一个很重要的品质,就是欢迎问题,喜欢寻找问题,而不是完成测试。我发现资深的测试人员都有自己很好的测试习惯,我曾经把这个当成我学到的最宝贵的财富。可是当我想传递给其他的测试人员的时候,他们却嗤之以鼻。

我有个同事,把所有的操作都事先写在文档里,用copy-paste来输入命令。这样可以完全重复测试过程,而不存在手工输入错误的问题,使得测试过程可以重现。在输入命令时,他把实时的log显示和alarm显示打开,并利用工具记录所有的命令输出。每输入一条命令, 他就会看看是否会出现问题。如果出现问题,他就立刻去分析这个问题出现的原因并考虑是否是个bug。

很多测试人员只有在出了大问题的时候,比如call打不通了,或者机器重起了,或者整个测试结果与预想的不符,才想起去察看和记录错误。

我刚开始做测试的时候,也是这样的。这样常常会无法判断错误什么时候出现,是因为什么操作出现的,只好再重复一遍。如果不是必现的问题,就无法说清了。很多测试人员,在测试计划上写的是一套,自己做的是另一套。因为测试计划 和执行不是同时做的,执行时发现了一些问题,调整了测试步骤,但没有及时更新计划,也没有记录操作步骤。

当发现问题时,只好重新回忆自己做过的步骤,很浪费时间。没有出现问题的话,测试步骤根本不被记录。这些问题看似简单,但影响不小。所以,在平时的测试工作中,有意识地培养起自己良好的测试习惯,是成为优秀的测试人员的一个很重要的品质。资深的测试人员总是把自己当成用户,喜欢评论软件给用户的感受,这是很多测试人员不敢去做的。在测试报告里,我们只关注报了多少个bug,这些 bug有没有被修改,却不关心测试人员对软件的评价。

其实这些评价对开发人员是非常重要的。测试人员往往能感受到系统最薄弱的地方在哪里。比如系统内存保护机制错误导致系统经常crash,系统层次过多,交互很成问题,系统有瓶颈,性能上不去,等等。

软件人员只有各个分散的bug,却得不到总体的感觉,这些反馈对系统架构师和开发人员改进系统、提高产品质量是非常重要的。好的测试人员,要时时刻刻站在用户的角度,表达出自己对软件,对产品的感受。

资深的测试人员喜欢和软件人员pair-work。因为软件人员比较清楚这个软件的架构,对出现的问题会很快定位,从软件人员对开发过程的描述,也可以事先判断出bug容易出现的地方。

而测试人员作为软件的使用者,可以很快地反馈出自己对于软件使用的感受。

让开发人员了解测试,也可以帮助开发人员更清楚用户的需求,对软件如何被使用有了深刻的认识。有些开发人员从来没进过实验室,压根就没用过自己写的软件,这是非常非常错误的。

好的测试人员,会多和开发人员交朋友,和他们一起工作。敏捷的鼓吹者说应该把测试人员分散到开发人员当中,和他们密切合作。这我也不太赞同。

测试人员彼此之间的交流更加重要,而且测试人员不能受软件实现的约束。这是有个度的。把测试人员打散,测试人员在团队中往往处在劣势,他们很容易成为开发人员的附属品。开发人员让他们测什么就测什么,开发人员认为是问题才是问题。测试人员很难成长起来。

所以,和软件人员共同工作,是在测试人员有足够的测试经验的时候,而且应该是建立在平等的基础上的合作。执行测试,有点像探雷,需要一步一步地走,小心谨慎地前进。目的是找雷,而不是通过。