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

　　1. 對(duì)測(cè)試的要求太高了

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

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

　　2. Dev不愿意修改bug.

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


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

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

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

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