微軟的軟件質量控制實踐三篇寫完了，收到很多評論。不可能一一回答，所以在這里我挑幾個評論多的和有代表性的，和大家再多討論一下。希望有所幫助。

　　1. 對測試的要求太高了

　　在國內培訓的時候經常遇到的一個說法：“(比如測試自動化，工具，流程)的確好處很多，但是它對測試的要求太高了”。剛開始的時候我很驚訝，第一次聽到對測試要求太高的說法，后來聽多了才慢慢意識到這才是問題所在。如果你認為國內的測試比國外落后N年的話，我覺得“對測試的要求太高了“的觀念是導致這個落后的根本原因。我一直在觀察和對比國內外測試的區別，當然有技術上的，工具上的，流程上的區別等等，但是這些差別都只是表象，根本的差別是觀念上的差別，也是測試在研發中的真正角色。這個不是找到多少個bug的問題，也不是采用什么測試方法的問題，而是是否把測試做為支撐研發兩條腿中的一條腿的問題。測試是一個專門的職業，和開發一樣有不同級別。初級人員解決簡單的事情，高級人員必須負責解決復雜，高難度的事情。這樣才能形成一個完善的測試人員職業發展體系。很多測試經理一直很困惑說我們也在加大在測試上的投資，參加很多技術、流程、管理培訓，但是效果都不好。原因是我們不能總是希望通過學習一個技術，或一個工具來解決觀念上的問題，當然沒有效果。也容易跟風，剛學會手工測試，又要測試自動化了;剛學會測試自動化;又要ET了。剛學會ET，又要敏捷了。沒有觀念沒有主見。所以改變觀念才是提高軟件質量的根本途徑。

　　那么如何改變觀念呢?我也不知道。公司老板不愿改變呢?我也沒有辦法。但是重要的是你知道問題所在了，這是解決了大的難題。如果自己都覺得測試沒有難度，沒有前途或者對測試要求太高了的話，如何指望得了別人?所以我們搞測試的人的一個重要職責是：把這個觀念灌輸給其他人，把測試的門檻提高，對測試的要求沒用很高只有更高，其它問題也都解決了。

　　2. Dev不愿意修改bug.

　　這是一個很多測試抱怨的問題：自己辛辛苦苦找到一個bug，開發卻認為不是bug。或者更為令人氣憤的是開發在沒有溝通之前直接resolved as “by design” or “not repro”。這個情況通常在質量控制成熟度級別(1級或2級)較低的組出現較多。根本上解決的辦法是提高整個組的成熟度級別，當然需要在很多方面加以提高，這個問題隨之而去了。可以使用以下幾個策略：


　　首先這里牽涉到兩個問題：一個是resolve as “not repro”的問題。很多時候dev resolve as ‘not repro’是因為bug本身不清楚沒有足夠的信息來判斷或進一步investigate(當然他應該和你確認一下先)。所以測試在報bug是一定要記錄足夠信息。基本原則是當別人在看該bug是否有足夠的信息來判斷該bug是怎么回事或進一步investigate。我總結過一個好的bug描述應該是Concise，Accurate， Searchable， Entirety， 也是 CASE 原則。可能你會覺得這需要太多的時間才能報一個bug了。的確是，但是總比你花了兩天找到一個bug，花了10秒鐘把bug寫完了，結果過兩天dev resolve 成not repro強吧。另外是自動報bug的工具，還有是創建bug模板等都可以減少報bug的時間。

　　其次是’by design’的問題。很多時候測試不服氣認為是bug，但是開發不同意修改。我想借用一句話來說明我的觀點：a good idea is not really good until it is accepted. 也是說如果你不可以說服別人接受你的主意，再好的主意也沒有用。同樣的道理你認為的bug，如果不能說服別人，它也不是一個bug。或者bug只有在被修復時才是真正的bug。如果dev/test有分歧的話，通常PM負責一個功能，應該有PM做后決定;如果沒有PM的話，通常有整個team來決定。當然如果你非常肯定，可以繼續找更多的理由來支持你的觀點。但是終如果還是不能說服別人的話，還是要服從team的決定，雖然我們常說真理往往掌握在少數人的手里，但是絕大多數時候都是少數人考慮不周。另外一點是我們通常很少在是不是bug上有分歧，而是在什么時候修復上有分歧。這是另外一個話題了，需要考慮很多其它非技術因素了。

　　3. 如何做到自動報bug，并把相關的信息放到bug 里面.

　　我在comments里已經回答過了，把它拷貝一下吧以是完整：我前面提到微軟有很多工具來提高測試人員的工作效率，也是說把時間花在需要專注的地方而不是在其他繁瑣的地方浪費時間。其中一個好的實踐是自動報bug。其實整個過程比較直接：首先用來管理bug的工具應該會有API接口，所以可以使用工具來自動報bug。其次是添加分析處理工具，測試的出錯信息比較容易獲取，比如測試用例出錯了，或者拋異常或者返回錯誤結果，可以容易地把異常信息或錯誤信息放到bug里面;分析產品的日志找到錯誤點有寫難度，需要和dev共同努力把測試日志和產品日志通過某些屬性(時間戳或操作id)關聯起來。或者簡單地把相關日志、windows event log，等拷貝到network share，在bug中指向該路徑即可。還有對于UI測試，如果測試錯誤，一定要把當時的屏幕截圖抓下來放到bug中去。還是那句話，專注于應該要專注的地方而不是把時間浪費在其它步驟上了，測試用例出錯，不應該花太多時間去報bug (多2分鐘)。同樣道理有了bug后dev可以直接去investigate，而不是花時間去找日志在那里?那里出錯了?等等。有條件的產品組還可以進一步提高，比如工具自動報bug的時候可以到到數據庫里根據異常或錯誤信息查找一遍看一看以前有沒有類似的bug，或者做BI，這些信息對于將來的分析和決策非常有幫助，而且也可以幫助預防bug。