日常的工作中，每天都會與開發工程師打交道。我們服務的核心對象也是開發同學，和開發同學保持較好的合作關系，很大程度上影響了測試工作的好壞。
談談自己的一點看法：
1、加強開發團隊對缺陷和測試人員的重視程度，規范開發測試流程，從根源上解決問題。 開發和測試的矛盾來自于缺陷，也終止于缺陷。 開發團隊的領導技術覺悟，可能會直接影響到成員和測試人員的合作，如果開發團隊領導對缺陷都視而不見，對測試認知度有限，開發同學就可能會對bug產生抵觸情緒。 采用適當的培訓來提高開發團隊對測試工作的認識，可以使開發同學提高代碼質量意識，更加尊重測試的工作。如果可以有一個非常明確的開發測試流程，并能夠將代碼質量計算 到每個人的能力考核范圍內，那么測試的工作會好做很多。目前公司很多的需求跟進、代碼review工作都理所當然的由測試來負責推進，這種現狀其實不利于測試人員解脫出來，專注于測試 本身。
2、引入缺陷統計工具 缺陷解決周期及質量可以一目了然，提供給開發和測試同學一個渠道去查看團隊成員的代碼質量、缺陷頻率、線上代碼存在的隱患等等。 同時，對于某一個項目來說，缺陷統計工具提供的數據可以做為一個數據倉庫以提供各位老大們做各種數據挖掘，比如某一個項目在引入自動化測試框架后，bug頻度和數量是否了 下降，某開發團隊引入code coverage工具后，首版本嚴重級別相同的bug數量是否有降低。
3、簡化開發測試間的缺陷溝通渠道，避免無效bug。 我們可以先來個換位思考，如果我們來做開發，什么樣的bug我們樂意改，什么樣的bug我們最討厭？
我大概想了想，有幾下幾種：
最喜歡的bug：
1）容易改的；
2）可以讓代碼更簡潔的；
3）不需要重構的；
4）改完了有種成就感的；
5）這個bug不被發現可能影響重大的；
6）可以讓我有技術成長的；
......
最討厭的bug：
1）費了半天勁但發現是個無效bug，測試根本沒搞清楚需求是什么；
2）吹毛求疵的小問題，而且很費時間的問題；
3）可能是個問題，但我從bug描述上根本看不出是什么地方出了問題；
4）我只是遺忘了一個sql腳本，結果QA給我提個P0級別bug，至于么？
5）測試庫都是垃圾數據，你們為什么不清一下就總說程序有問題？
......
綜上，應該盡量做到以下幾點：
1）前期的需求明確，達到開發和測試認識一致是前提；
2）bug的描述盡可能清晰，優先級盡可能準確，盡可能深刻，最好深入到代碼級，避免重復的bug；
3）減少隨機測試帶來不可重現的bug，如有可能，盡量所提bug都是可以重現的；
4）能夠和開發同學說明bug的嚴重性和可能帶來的具體風險；
5）減少對開發同學的技術依賴，建立技術尊重。比如自動化部署、獨立掌握測試環境、了解一定的代碼邏輯等等。
4、引用臺企的一句話“Work Smart”
1）注意bug提交的時機。嚴重的bug如果在上線前才提出來，大家都會很窩火，開發即使不埋怨心里對測試的信任度也會打折。同時，目標對象的心情也很重要，即使你很資深，開 發人員關機了準備走，或者和女朋友約了吃飯，這個bug被處理的可能性肯定很小的。
2）對事不對人。一個標題鮮明的嚴重bug列表也許會讓pm覺得項目問題很多，同時也會讓開發很“沒面子”，特別是一堆無關緊要的問題被標紅和羅列成一屏幕的時候，會引起很 大的反感。這種情況應該盡量避免發生。同時，測試應該盡可能只就事論事，討論bug盡可能理智和克制，有耐心，避免和開發同學因為bug爭吵。這樣才能夠很好的說服開發修改 缺陷。
3）和開發搞好私人關系，做開發的朋友： 盡可能站在開發角度考慮問題，特別是開發同學遇到困難的時候，使開發同學認識到測試不僅僅是找茬，而是在協助他完成他的工作。這樣既能夠解決問題，又能夠交個朋友， 何樂而不為？
以上僅是個人一點想法，歡迎拍磚！謝謝！