一百九十二

一、听听测试跟开发都吐槽对方什么？
1.来自开发的问候
由于忙于各种业务，所以认识了很多的开发童鞋。接触的多了，大家话题也就聊开了。因为他们也会跟不同的测试人员合作，所以我
偶尔就能听到开发对测试的一些吐槽。

“那XX，稍微有点不对，直接反手就是一个bug单，问都不问”；
“你这算啥，你没看那XXX，说问题就一张截图，无语”；
“哎，现在测试都不看数据库的么？前端的锅bug提给我干嘛？”… …

不知道大家是否也曾经听到过类似的吐槽，我觉得场景很真实，我相信一定有测试人员是这样做的。别问，问就是我也曾…

其实对于上述的测试童鞋的表现，我觉得通常是2种情况：

不知道怎么去定位bug，点出问题后只能全抛给开发自己去排查
知道怎么定位，但是没有去进一步定位（太忙 或者 懒得动）
2.来自测试的问候
就是最近，我们组里新来了一位测试童鞋。虽然人家是新来的，但是履历还是非常棒的，在阿里、华为都待过。
然后晚会的时候就听到新童鞋吐槽楼上的xx开发，几个小功能居然能有十几个bug。
bug多就算了，最可气的是，被发现了bug还不承认，一会自己偷偷改了，再跟你说这功能没问题…
不知道你有没有遇到过这样的开发人员呢？

对于这位开发的表现，我觉得可能是这样的：

专业能力差，bug多
专业能力还行，不认真，没自测，没责任心
人品不行，这个人做任何工作都可能会引起身边合作的人反感。

二、我和开发的“恩怨情仇”
其实大家在日常工作中讲得就是一个“合作”，但是对于测试这份工作，你进行的顺利与否还是挺"看脸"的。

如果你测试的业务，对于的开发是一个自我要求高，技术能力很强的大佬，那么基本上你的case会跑的很顺利，有问题也很少。
反之，开发能力差还蜜汁自信，你就会很心累，各种测不通。

我的记忆里，我接触的到开发童鞋总体都还不错，起码沟通起来没有不愉快过。所以，通常来说，我跟这些开发相处的都不错，
自然就没有“无间道”了。

但是对于上面提到的那种“毒瘤”，自然也不能惯着。如果对方不自测，那我会去了解下为什么不自测。如果真的是因为太忙，那我觉得
也是可以给与一定的理解。
如果就是那种不自测，拿测试当“保姆”的，对不起，冒烟测试3次不过，打回不测了。把涉及到此需求的各方人员
都拉在群里，说明原因，开发自测后直接上线。

其实上面说的情况自然是我最不想看到的，但是这是因为对方实在可气，导致你的工作不能顺利进行，但是我相信大多数的开发童鞋还是很有
责任心的，大家都是一个诉求，功能没问题，如期上线。

三、我在工作中是怎么做的？
首先，我觉得测试的工作形式绝对不是一成不变的，还是要以适应当下的形式才行。

比如说我上个东家，虽说是个三线互联网公司，但是也是港股上市，业务稳定，大几千人。这样的公司通常很多流程已经比较规范了，比如从需求的
提出，到最终的上线，可以较好的按照比较标准的流程走下来，具体流程大家都知道，就不赘述了。

那现在的情况就不一样了，我现在的是创业型公司，处于C轮。需求多、测试人力不够（一直在招，合适的难找）、流程不规范，这些缺点都有。这时候
还用之前的那套显然啥都做不了了。

就拿最近负责的业务来说说，我在测试工作中通常会去做什么？

1. 需求急，短时间上线——关键词【沟通】
   其实这种情况，在稳定和创业型公司都会遇到，只不过后者这种情况更多见。这时候，熟悉需求肯定还是首要的。不管你有没有直接参与需求的评审，都要
   找涉及需求的直接人员进行有效沟通，注意是有效沟通。

找到需求的推进人，确定上线周期，提测时间，好规划测试时间，以及对于需求的一个测试重点分布。另外，还要把发现的一些风险点或者测试覆盖不到的地方
及时的抛出来，群策群力一起想办法。千万不要有阻塞点卡着 你不说出来，这样的话万一导致延期的话，锅可就是你的了。

2. 需求描述简单，不仔细——关键词【梳理】
   这情况也是伴随着上述的情况而生，因为这种需求下很难有完整的需求文档描述以及原型图等等， 那么这个时候开发在设计的时候也可能考虑不全。那么，既然我
   又不能直接撂挑子不管不顾，那我也只能尽我自己一份力，去帮着查漏补缺。

比如，最近的需求测试当中，我就要测试一个job接口，这个接口用来按照策略生成任务的，数据很重要，自然这个部分就是测试的一大核心重点。

重点需求重点对待，不仅要看功能页面上的展示，还要去查询各种表，去确定数据的准确性。
这个需求因为测试数据不好准备，在前期与开发沟通的时候，了解了涉及到的各种表之间的关系，自己去写sql造测试数据。

在验证结果的时候，我还会去查日志，一些关键点没有日志的话 提醒开发童鞋补上，方便验证。然后在一次次的测试中，再次梳理接口的处理逻辑。
看似正确的处理逻辑，当设计了足够多的场景数据去测试的时候，果然，发现了2除逻辑上的疏忽。

开发童鞋连赞发现的好，立马找来产品确认下是否需要补齐这个逻辑。

另外，在我查询各种表的时候，开发童鞋还反问我：“你还查库呢？我看很多测试都不查数据库的，挺好的”

3. 发现问题，如何更好的提bug——关键词【谨慎】
   提bug，那肯定是我们工作中的一大重点内容了。发现问题，我觉得可以不用立即去提bug单，首先我会在我的case脑图后加标记，出现的什么问题。
   然后再结合我的时间安排，觉得定位bug的深度。 最最最不济，你也要确定这问题是能复现出来的。

其实定位bug还是常用的那些方式，看请求，确认参数返回，查数据，看日志，依次来大概确定下是谁的问题，这时候你再提单会好一些。
当然了，肯定有一些我不能确定的问题，那么我可能会提给这个功能的最直接的那个人。

此外！！！还要多加一句：“这个问题可能不是你导致的，如果你发现不是你的问题，你直接将bug流转给对应的人就好”。

对应没时间写测试用例，这个事情也很经常了。我觉得这种需求下，在你熟悉大概情况后，可以边测边写，再不济的话，测试过的点和考虑到的场景务必要记录，
还有重要的沟通内容，截图等等，这是你工作细节的证明，也是你日后甩锅的证据。

4. 无意之中，“秀”一下你的代码
   其实很多开发会鄙视测试的最直接的因素，就是测试不写代码。 我在上一家测试一个专项的时候，跟组里的高T开发合作过，结项的时候，他表示觉得我
   是一个不错的测试，他觉得不会写代码的测试不能算做一个合格的测试。

其实这位大佬的言论在我看来还是有些偏激的，但是这确实就是代表了一部分开发的想法。

就包括我现在，在开发debug的空闲期，我也会打开我的编辑器去继续写一些有用的代码，有些开发看到后，会好奇的问：你在写什么代码呀？这个时候你就可以
扯一波了，千万不是吹嘘自己，表示你用代码在做一些有利于提效等等的事情，尽管你的开发水平不高，但是开发人员这时候还是会对你刮目相看，给你打上一个会
写代码的标签。

但是，我们别忘了，测试学习写代码，最终目的就是要去提效，提高工作效率，做一些对大家有意义的事情，让代码发挥出价值。千万不要本末倒置，为了写而写。

四、小结
思路比较杂乱，想到哪说到哪，最后点一下主题，如何不被开发鄙视。

首先，我觉得测试童鞋绝对不要妄自菲薄，其实你可以这样想一下，多数的开发人员天天的工作内容也是业务的CRUD，跟你的业务测试不会高到哪里去，如果你换了份开发
的工作做，你熟练后同样可以达到他们水平。 工作没有贵贱之分，互联网行业从业人员这么多，那是不是所有人都要去做开发？

再者，你的工作内容并不局限你的发展，你代码该学学，熟练了，简单的算法也可以搞一搞。千万不要满足于现状，这一点是最重要的，就算你投身其他行业，亦是如此。

最后，在测试工作中，扮演好你这个角色，做一个有责任心、谨慎、对团队有帮助的人，试问，这样的一个人，谁会看不起你？

以上都是我的个人愚见，欢迎大家分享一下自己的工作状态内容。

–不要用肉体的勤奋，去掩盖思考的懒惰–