---

前言

测试团队的新同事，甚至是有一定经验的同事都喜欢沉浸在探索bug的世界中不能自拔。乍一听这不是好事吗？测试人员不就是找bug的吗？

简单来说就是这种探索超出了范围（如用户需求、时间成本、人力成本等）。

如果单纯的站在测试的角度来说那么没问题，测试人员可以无止境的探索可能的问题，但问题是现实中不需要或者说不能如此，测试的标准一定是要基于用户需求的，即使你自己就是用户，你也不可能要求不计成本的保证一个系统100%完美。

举个例子，假如有一个系统是用来处理订单，用户实际使用时处理的订单量并不大，同时使用的用户数也不多，如果你非得测测系统的并发、吞吐量之类的case那就是没事找事，甚至还提一堆性能bug，那都是完全没有必要的。当然这也可以归结于需求不明确，或者说测试人员对需求理解得不够。

要从商业利益的角度考虑。
有些情况确实有一些问题，而且也几乎可以判断这是用户关心的，但是需求上没说，用户自己也并没有提出来，这时就要根据情况处理了，不能说有问题就一定要报告，就一定要修复，有的时候合同可能已经签完，再有超出需求的改动是要另算的，这涉及到公司的利益问题。

当然了，如果单纯的作为一名测试人员也可以将问题提出来，至于如何处理就留待领导决定。

很多情况（用例）只存在于测试者眼中，我们应该根据情况有所为有所不为，特别是时间比较紧张的时候，如果你过多的探索不需要探索的区域那么肯定就会给其它重要的区域带来测试风险，这反而违背了你“做好事”的初衷。

如何改进测试方式和避免盲目探索呢？

当然是熟悉需求，多熟悉系统相关的行业和业务逻辑，比如物流、餐饮、财务等等，对行业相关的业务有一定了解后你甚至可以判断出哪些部分是用户最关注的，从而有的放矢，避免吃力不讨好。

总而言之，测试的原则应该是在有限的时间内找出最有价值的bug。

测试与开发的共同秘密

测试员几天都发现不了bug，因此身为好朋友的程序员知道后，善解人意的写了几个bug。

测试员和程序员闹矛盾了，测试员使劲提bug，程序员使劲写bug，最后互相妥协了。

临近发版，程序员优化了一个小功能，程序员让测试员相信自己，不会出问题不用测试，测试员果断选择了信任。往往这样的后果……都是泪。

程序员告诉测试员，新来的技术leader每天做得最多的事就是copy他们的代码，一份不够还再来一份，觉得代码行少了，再随便加一堆压根都不调用的代码行作为个人的日产出代码行。都知道这技术leader水，没想到如此水。

下面是我整理的2022年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

梦自己想梦的，做自己想做的，生命只有一次……一旦错过了就不可能再有这个机会了，不要让自己后悔。

不要四处乱撞，每天做好一件事，在遇到挫折的时候，坦然微笑地面对生活，这样就可以享受到成功的境界。

人生，要的就是惊涛骇浪，这波涛中的每一朵浪花都是伟大的，最后汇成闪着金光的海洋。