内容简介:干软件测试这行已经许多年,见过刚刚开始工作的测试人员,也见过一些非常资深和优秀的测试人员,也见过不少无法成长起来的测试人员。很多测试人员技术背景很强,操作能力也不错,但就是很难发现问题,为什么呢?我们就来谈谈怎样执行好测试吧,需要培养哪些能力。做任何工作都要有好的工作态度,如果只是想混日子,无论做什么工作都不会有长进的。技术背景当然也是需要的,测试人员可以不如开发人员深入。比如开发某些协议的时候,开发人员往往对rfc已经倒背如流,测试人员没必要做到如此熟练。
干软件测试这行已经许多年,见过刚刚开始工作的测试人员,也见过一些非常资深和优秀的测试人员,也见过不少无法成长起来的测试人员。
很多测试人员技术背景很强,操作能力也不错,但就是很难发现问题,为什么呢?我们就来谈谈怎样执行好测试吧,需要培养哪些能力。
工作态度和技术背景就不去说它了。
做任何工作都要有好的工作态度,如果只是想混日子,无论做什么工作都不会有长进的。技术背景当然也是需要的,测试人员可以不如开发人员深入。比如开发某些协议的时候,开发人员往往对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容易出现的地方。
而测试人员作为软件的使用者,可以很快地反馈出自己对于软件使用的感受。
让开发人员了解测试,也可以帮助开发人员更清楚用户的需求,对软件如何被使用有了深刻的认识。有些开发人员从来没进过实验室,压根就没用过自己写的软件,这是非常非常错误的。
好的测试人员,会多和开发人员交朋友,和他们一起工作。敏捷的鼓吹者说应该把测试人员分散到开发人员当中,和他们密切合作。这我也不太赞同。
测试人员彼此之间的交流更加重要,而且测试人员不能受软件实现的约束。这是有个度的。 把测试人员打散,测试人员在团队中往往处在劣势,他们很容易成为开发人员的附属品。 开发人员让他们测什么就测什么,开发人员认为是问题才是问题。测试人员很难成长起来。
所以,和软件人员共同工作,是在测试人员有足够的测试经验的时候,而且应该是建立在平等的基础上的合作。执行测试,有点像探雷,需要一步一步地走,小心谨慎地前进。目的是找雷,而不是通过。
【责任编辑:庞桂玉 TEL:(010)68476606】
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Flutter 学习之路 - 测试(单元测试,Widget 测试,集成测试)
- itest(爱测试)接口测试&敏捷测试管理 7.7.7 发布,接口测试重大升级
- 性能测试vs压力测试vs负载测试
- SpringBoot | 第十三章:测试相关(单元测试、性能测试)
- 敏捷测试VS传统测试对比,6招玩转敏捷测试!
- itest(爱测试)接口测试&敏捷测试管理平台 8.1.0 发布
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
计算机网络(第5版)
Andrew S. Tanenbaum、David J. Wetherall / 严伟、潘爱民 / 清华大学出版社 / 2012-3-1 / 89.50元
本书是国内外使用最广泛、最权威的计算机网络经典教材。全书按照网络协议模型自下而上(物理层、数据链路层、介质访问控制层、网络层、传输层和应用层)有系统地介绍了计算机网络的基本原理,并结合Internet给出了大量的协议实例。在讲述网络各层次内容的同时,还与时俱进地引入了最新的网络技术,包括无线网络、3G蜂窝网络、RFID与传感器网络、内容分发与P2P网络、流媒体传输与IP语音,以及延迟容忍网络等。另......一起来看看 《计算机网络(第5版)》 这本书的介绍吧!