15.12本章討論
15.12.1韓昭候
果凍：韓昭候真過分！我很好心地幫助別的同事，沒有功勞也有苦勞，他怎么能說“甚于寒”？這樣我的心都寒了。
阿亨：果凍，你不是有“各司其職”的筆記么，好好看看。
九條：謝謝你的幫助，你如果急需驗證某些問題，可以告訴我，我會安排盡量早日完成。
15.12.2測試經(jīng)驗交流
測試進行一段時間后，大家發(fā)現(xiàn)阿毛報告的bug 比較多，九條其次，小燕最少。阿亨讓測試人員交流一下各自的經(jīng)驗。
阿毛：我的原則是“如果問題看起來像一個bug，那我就要報告這個bug”。寧可多報一千，也不放過一個。這個原則也導致了我的bug 有不少被歸為“As Design”。
阿亨：“As Design”也不是什么壞事，至少我們明確了Design 是什么。這樣以后就有依據(jù)了。
小燕：我發(fā)現(xiàn)了一個問題，都是先跑去找開發(fā)人員商量是什么情況。或者自己研究，想找到問題的根源，再報告。
九條：小燕的做法，似乎越界到了開發(fā)人員的職責范圍了。我們的職責就是找到足夠多的bug，讓開發(fā)人員有事可干。
阿亨：可以選定一個典型用戶（Persona），然后按照典型人物的思路和看問題的角度，把整個系統(tǒng)的各項功能都經(jīng)歷一遍。如果有什么你覺得典型用戶不滿意的，那就可以考慮開一個bug。我有時知道這個功能的設計想法，但是在測試的時候沒必要替別人考慮太多，要把自己當成用戶，而不是設計者。
阿毛：測試的時候，要各個角度都試試看，一些犄角旮旯也得用一些隨機的數(shù)據(jù)去搗搗亂。黑箱、白箱都可以換著玩。就像對軟件一竅不通的用戶在使用軟件一樣。
阿亨：阿毛的這一個經(jīng)驗，用正式的語言描述就是：保證測試方法的多樣化。
九條：我拿到一個測試任務，就想：這個功能最可能出問題的會是在什么地方？然后就集中火力，在容易出問題的地方測試。比如如果一個產(chǎn)品的標題長度規(guī)定是32個字符，那我就測試31，32，33個字符，看看在這種邊界條件下是否會出問題。
阿毛：測試的時候還要舉一反三，看到產(chǎn)品標題字段出了問題，我就會檢查一下別的字段有沒有類似的問題。
阿亨：對，我們要注重從產(chǎn)品的風險出發(fā)，進行測試。還有，我們要根據(jù)當前的產(chǎn)品特性來決定測試的策略，不必強求一律，舉一反三很重要。
阿毛：有時候我測試自己負責的功能比較多了，我就想和別人換一換，有點新鮮感。不料小燕拒絕了我的交換請求，說是沒經(jīng)過領導批準，是侵官之害。我只好和九條交換。
阿亨：我批準這樣的交換，關(guān)鍵是找到bug。我們都是同一類工作人員，在事先安排好的情況下，不存在“侵官之害”的問題。
小燕：我發(fā)現(xiàn)隨著bug 的增多，我又要驗證以前的bug，又要發(fā)現(xiàn)新的bug，工作量越來越大，你們都怎么辦？
九條：我一般都把一些比較穩(wěn)定的測試寫成自動測試，這樣就減輕了我手工測試的壓力。
15.12.3傳說中的拐點
小飛：我聽說在軟件項目中，有這樣一個拐點存在——在這一點之前，新的bug產(chǎn)生的數(shù)量大于bug解決的數(shù)量；在這一點之后，bug的解決數(shù)量大于新的bug 產(chǎn)生的數(shù)量。這樣bug的曲線就向下移動。我們移山項目的拐點到了么？
阿超：我也聽說過，不過我們不能等待拐點的到來，對于我們這樣的日期驅(qū)動的項目，拐點必須在發(fā)布日之前的若干時間發(fā)生，如果我們的bug 數(shù)量還是繼續(xù)向上攀升，我們無法保證以后曲線會像懸崖一樣掉下來。我們就得主動讓拐點發(fā)生，例如推遲一些bug，砍掉一些功能，等等。
15.12.1韓昭候
果凍：韓昭候真過分！我很好心地幫助別的同事，沒有功勞也有苦勞，他怎么能說“甚于寒”？這樣我的心都寒了。
阿亨：果凍，你不是有“各司其職”的筆記么，好好看看。
九條：謝謝你的幫助，你如果急需驗證某些問題，可以告訴我，我會安排盡量早日完成。
15.12.2測試經(jīng)驗交流
測試進行一段時間后，大家發(fā)現(xiàn)阿毛報告的bug 比較多，九條其次，小燕最少。阿亨讓測試人員交流一下各自的經(jīng)驗。
阿毛：我的原則是“如果問題看起來像一個bug，那我就要報告這個bug”。寧可多報一千，也不放過一個。這個原則也導致了我的bug 有不少被歸為“As Design”。
阿亨：“As Design”也不是什么壞事，至少我們明確了Design 是什么。這樣以后就有依據(jù)了。
小燕：我發(fā)現(xiàn)了一個問題，都是先跑去找開發(fā)人員商量是什么情況。或者自己研究，想找到問題的根源，再報告。
九條：小燕的做法，似乎越界到了開發(fā)人員的職責范圍了。我們的職責就是找到足夠多的bug，讓開發(fā)人員有事可干。
阿亨：可以選定一個典型用戶（Persona），然后按照典型人物的思路和看問題的角度，把整個系統(tǒng)的各項功能都經(jīng)歷一遍。如果有什么你覺得典型用戶不滿意的，那就可以考慮開一個bug。我有時知道這個功能的設計想法，但是在測試的時候沒必要替別人考慮太多，要把自己當成用戶，而不是設計者。
阿毛：測試的時候，要各個角度都試試看，一些犄角旮旯也得用一些隨機的數(shù)據(jù)去搗搗亂。黑箱、白箱都可以換著玩。就像對軟件一竅不通的用戶在使用軟件一樣。
阿亨：阿毛的這一個經(jīng)驗，用正式的語言描述就是：保證測試方法的多樣化。
九條：我拿到一個測試任務，就想：這個功能最可能出問題的會是在什么地方？然后就集中火力，在容易出問題的地方測試。比如如果一個產(chǎn)品的標題長度規(guī)定是32個字符，那我就測試31，32，33個字符，看看在這種邊界條件下是否會出問題。
阿毛：測試的時候還要舉一反三，看到產(chǎn)品標題字段出了問題，我就會檢查一下別的字段有沒有類似的問題。
阿亨：對，我們要注重從產(chǎn)品的風險出發(fā)，進行測試。還有，我們要根據(jù)當前的產(chǎn)品特性來決定測試的策略，不必強求一律，舉一反三很重要。
阿毛：有時候我測試自己負責的功能比較多了，我就想和別人換一換，有點新鮮感。不料小燕拒絕了我的交換請求，說是沒經(jīng)過領導批準，是侵官之害。我只好和九條交換。
阿亨：我批準這樣的交換，關(guān)鍵是找到bug。我們都是同一類工作人員，在事先安排好的情況下，不存在“侵官之害”的問題。
小燕：我發(fā)現(xiàn)隨著bug 的增多，我又要驗證以前的bug，又要發(fā)現(xiàn)新的bug，工作量越來越大，你們都怎么辦？
九條：我一般都把一些比較穩(wěn)定的測試寫成自動測試，這樣就減輕了我手工測試的壓力。
15.12.3傳說中的拐點
小飛：我聽說在軟件項目中，有這樣一個拐點存在——在這一點之前，新的bug產(chǎn)生的數(shù)量大于bug解決的數(shù)量；在這一點之后，bug的解決數(shù)量大于新的bug 產(chǎn)生的數(shù)量。這樣bug的曲線就向下移動。我們移山項目的拐點到了么？
阿超：我也聽說過，不過我們不能等待拐點的到來，對于我們這樣的日期驅(qū)動的項目，拐點必須在發(fā)布日之前的若干時間發(fā)生，如果我們的bug 數(shù)量還是繼續(xù)向上攀升，我們無法保證以后曲線會像懸崖一樣掉下來。我們就得主動讓拐點發(fā)生，例如推遲一些bug，砍掉一些功能，等等。
鄂公網(wǎng)安備 42010302001612號