2、評估測試代價

　　● 測試的消耗有多大？我們能承受的測試代價是多大？

　　● 我們能否從測試覆蓋中消除不必要的冗余？

　　● 是什么讓測試執(zhí)行困難（代價高）？

　　● 產(chǎn)品的可測性能否再提高？

　　● 是否有工具或技術(shù)可以使測試過程更加高效？

　　● 早點測試好還是遲點測試好?哪種情況下測試的整體成本低一些？

　　3、檢查測試對決策的作用

　　● 測試過程是否清楚管理者、開發(fā)人員或其它客戶需要做的決定？

　　● 測試過程是否關(guān)注潛在產(chǎn)品和項目風險？

　　● 測試過程是否依賴變更控制過程和項目管理？

　　● 測試報告是否及時遞交？

　　● 測試報告是否用易于理解的方式溝通？

　　● 測試過程和測試結(jié)果一樣被傳達嗎？我們是否報告評估的基礎(chǔ)以及融入我們的信心在里面？

　　● 測試過程是否對技術(shù)支持、發(fā)行、市場或其它需要使用質(zhì)量評估的任何業(yè)務(wù)過程提供服務(wù)？

　　4、是否及時

　　以上三方面都是時間驅(qū)動的。所以帶來了問題：我們永遠也沒有足夠的時間去做每一件事，所以我們要做的每一件事都是與時間賽跑。

　　整合分析

　　1、我們的測試有多好？

　　● 綜合前面的幾個問題，考慮我們現(xiàn)在的測試過程中是否存在緊迫的問題？

　　● 我們的測試流程是否充分，是否能在產(chǎn)品質(zhì)量未能達到預(yù)期目標時對項目管理提出預(yù)警？

　　● 是否存在某些潛在類型的問題是不可忍受的，如果有，我們是否有有信心我們的測試流程能發(fā)現(xiàn)定位這些問題？

　　2、是否值得改進？

　　● 我們能用什么策略改進測試？

　　● 我們有能力應(yīng)用這些測試策略嗎？我們知道怎樣應(yīng)用嗎？

　　● 改進測試會消耗多大？會有多麻煩？是否是利用資源的佳方式？

　　● 能否暫時不改進？能否在一個可接受的時間范圍內(nèi)達到改進？

　　● 改進是否會造成反效果，引入新的bug，對士氣造成影響？

　　● 改進會帶來明顯的不同嗎？

　　測試經(jīng)理不愿意面對“毫無遺漏的測試是不可能的”這一事實的話，他會選擇一個不可能完成的測試。

　　Good Enough Testing 的目的是幫助軟件測試工程師擺脫測試的條條框框、主觀性、被動的局面，把結(jié)構(gòu)化的、合理的方法應(yīng)用到復(fù)雜的、多維的問題集合中去。