常見的窘境：
這也許是大多數軟件公司面臨的一個老大難的問題，即送測的程序版本質量差——甚至會出現連冒煙測試都不能通過的情況——面對這樣的版本，作為測試人員的我們，也常常陷入兩難的境地：如果投入測試，會浪費大量的時間；如果不投入測試，項目的交付時間在那里卡着......所以這就讓測試人員陷入一個兩難抉擇的窘境。
對這個問題，我說一下自己的看法。
我覺得如果想解決問題，首先得認清楚問題，掌握問題的本質。
拿這個問題來說，導致版本質量差的原因許多，比如開發沒時間自測、不懂測試，又或者不重視質量，但歸根究底總結起來，無法也就那么幾大類：管理的問題、客觀現狀、人的問題等。下面針對這些原因，我一一進行闡釋，也給出自己目前想到的應對措施，希望能成為拋磚之舉，引出更多金玉良策。
一、人的問題：
（1）開發人員能力不足
一般來說開發人員的能力越強，開發出來的程序質量就越高。不過開發人員的能力也可以說是可遇而不可求的東西，難以在短時間內得到很大提升。我的看法是可以在項目啟動前，針對有必要的技術、工具做好培訓，同時在項目技術后做好項目總結和分享——為下次項目做准備。
（2）不夠細心、細致
說話說“人無壓力輕飄飄”， 針對這一點我覺得可以通過增加一些考核指標來進行應對，比如增加bug率的考核，通過制造壓力的方式，讓開發人員更加的小心、細致。
（3）不知道如何測試
確實存在一些開發人員不知道如何測試才能更好的交付高質量的送測版本，畢竟術業有專攻嘛。這一點上可以通過讓小組搭配的方式進行交叉測試，或者進行code review進行適當的提升。同時測試人員可以在全公司范圍內組織一些測試方法的培訓（最好提供一些測試框架和模板），幫助開發人員提高自測水平。
（4）責任心不足
人都是有惰性的，在很多公司里也常常會有開發人員對測試人員有依賴心理，覺得版本開發完了隨便測測（甚至不測）就扔給測試人員。應對這種情況，測試人員可以在冒煙測試/回歸測試不通過后，把不通過的原因以郵件的形式發送給項目全員，抄送相關領導。人都是好面子的， 這樣的做法可以讓開發人員有意識的更認真的對待送測版本。
我很少遇到責任心特別差的開發， 如果真有，可以用數據“批斗”一下，實在不行，淘汰吧。
二、項目管理方面
（1）風險分析不足
我遇到過一些項目，版本在送測后bug頻出，甚至開發改bug都改不完，更不用說去開發新的功能了，最終項目被迫中止，造成巨大損失。后來做項目總結的時候我才了解到這個項目采用了一個不太成熟的新技術。。。！ 這件事就是典型的風險分析工作做得不充分。特別是大型或者重要的項目，是不應該應用一些不成熟的新技術的（這豈不是拿這個項目做小白鼠么？）。 若有新技術出現，可以在小項目進行試點，等掌握了熟悉了再運用到大型項目中。
（2）bug預防工作做得不足
bug預防工作包括幾大方面：制定開發規范、測試規范、總結常見缺陷並制定應對措施，制定產品測試框架並培訓，開發人員質量意識灌輸等。
（3）開發流程
敏捷開發中有種開發方式叫“測試驅動開發”，這種方式若能推行，倒是可以很好的提升送測版本的質量。
三、客觀現狀
（1）自測時間不足
我經歷過的項目中，很少有哪個項目能留給開發留充足的時間做自測。 大多數情況都是開發草草自測，然后交給測試人員，然后導致雙方花很多時間在bug的溝通和維護上。這個項目本身也會有大量的返工。如果給開發相對充足的時間進行自測，送測版本的質量會有不錯的提升。
（2）開發不重視質量
現在不重視質量的人相對很少了吧？ 我遇到的開發人員，他們不是不重視質量，只是不知道自己的行為會對質量產生什么樣的影響。
下表是對以上問題的總結，為了看起來更清晰，我將應對措施分成了事前和事后兩類：
總結到這里，那作為測試人員我們能做什么呢？
- 測試流程中加入冒煙測試，收到送測版本以后安排一個人投入1小時對主要功能點一點看看是否有問題，若有問題把問題用郵件通知相關責任人並將版本駁回；
- 測試結束后，統計每個開發的bug率，並將該數據給到項目經理（視情況可以抄送更高層）
- 在版本測試中、結束后總結歸納版本問題，選擇適當的時間給開發人員做一些培訓分享。盡可能跟項目經理達成一致，推動bug預防的工作；
- 給開發人員宣貫bug修改成本，在公司層面做一些測試技術培訓，讓開發掌握一些測試手段和工具
- 自動化測試：送測前保證自動化測試腳本執行成功，或者推動測試驅動開發的開發模式。
- 在調研和分析階段考慮風險（這不單是項目經理或者需求分析、設計人員的責任）；
當然，質量是全員原流程的事，后續再跟大家討論作為項目經理和開發能做什么吧。
下面是我的微信號：
