忙忙碌碌，不知不覺在新公司已經3個月了。尤其是最近一段時間，異常的忙，但是我仍然會抽出一定量的時間來做些開發。
以後成熟的話，打算輸出一個手把手開發的系列，分享給更多的測試童鞋。
前幾天跟群裡一位小夥伴聊天，聽到了一個關鍵詞。相信這也是很多測試童鞋都有過的體會，感覺測試容易被開發鄙視，得不到尊重。
既然今天也沒什麼技術向的內容分享，那就隨便聊聊吧，以一個入行3年多的測試小兵的角度，談談我的感受。
一、聽聽測試跟開發都吐槽對方什麼？
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，跟你的業務測試不會高到哪裡去，如果你換了份開發
的工作做，你熟練後同樣可以達到他們水平。 工作沒有貴賤之分，網際網路行業從業人員這麼多，那是不是所有人都要去做開發？
再者，你的工作內容並不侷限你的發展，你程式碼該學學，熟練了，簡單的演算法也可以搞一搞。千萬不要滿足於現狀，這一點是最重要的，就算你投身其他行業，亦是如此。
最後，在測試工作中，扮演好你這個角色，做一個有責任心、謹慎、對團隊有幫助的人，試問，這樣的一個人，誰會看不起你？
以上都是我的個人愚見，歡迎大家分享一下自己的工作狀態內容。