忙忙碌碌，不知不觉在新公司已经3个月了。尤其是最近一段时间，异常的忙，但是我仍然会抽出一定量的时间来做些开发。
以后成熟的话，打算输出一个手把手开发的系列，分享给更多的测试童鞋。
前几天跟群里一位小伙伴聊天，听到了一个关键词。相信这也是很多测试童鞋都有过的体会，感觉测试容易被开发鄙视，得不到尊重。
既然今天也没什么技术向的内容分享，那就随便聊聊吧，以一个入行3年多的测试小兵的角度，谈谈我的感受。
一、听听测试跟开发都吐槽对方什么？
1.来自开发的问候
由于忙于各种业务，所以认识了很多的开发童鞋。接触的多了，大家话题也就聊开了。因为他们也会跟不同的测试人员合作，所以我偶尔就能听到开发对测试的一些吐槽。
不知道大家是否也曾经听到过类似的吐槽，我觉得场景很真实，我相信一定有测试人员是这样做的。别问，问就是我也曾...
其实对于上述的测试童鞋的表现，我觉得通常是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，跟你的业务测试不会高到哪里去，如果你换了份开发的工作做，你熟练后同样可以达到他们水平。 工作没有贵贱之分，互联网行业从业人员这么多，那是不是所有人都要去做开发？
再者，你的工作内容并不局限你的发展，你代码该学学，熟练了，简单的算法也可以搞一搞。千万不要满足于现状，这一点是最重要的，就算你投身其他行业，亦是如此。
最后，在测试工作中，扮演好你这个角色，做一个有责任心、谨慎、对团队有帮助的人，试问，这样的一个人，谁会看不起你？
以上都是我的个人愚见，欢迎大家分享一下自己的工作状态内容。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
