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

发布时间：2025-11-05 00:17:28 来源：码上建站 作者：IT科技

干软件测试这行已经许多年，资深见过刚刚开始工作的测试才软程师常心测试人员，也见过一些非常资深和优秀的老司测试人员，也见过不少无法成长起来的机经结什件测测试人员。

很多测试人员技术背景很强，验总操作能力也不错，试工但就是资深很难发现问题，为什么呢？测试才软程师常心我们就来谈谈怎样执行好测试吧，需要培养哪些能力。老司

工作态度和技术背景就不去说它了。机经结什件测

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相关文章