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

　　1. 對測試的要求太高了

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

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

　　2. Dev不愿意修改bug.

　　這是一個很多測試抱怨的問題：自己辛辛苦苦找到一個bug，開發(fā)卻認(rèn)為不是bug；蛘吒鼮榱钊藲鈶嵉氖情_發(fā)在沒有溝通之前直接resolved as “by design” or “not repro”。這個情況通常在質(zhì)量控制成熟度級別(1級或2級)較低的組出現(xiàn)較多。根本上解決的辦法是提高整個組的成熟度級別，當(dāng)然需要在很多方面加以提高，這個問題隨之而去了。可以使用以下幾個策略：


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

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

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

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