我曾經服務於這樣的客戶，開發團隊由於需求不明晰，驗收條件缺乏，導致返工嚴重；知識分享的缺乏，導致人員間不能相互替換，工作無法合理分配，進度緩慢；架構劃分的不合理，又沒有頻繁的在各團隊間進行整合，導致發布難度大，周期長。內憂外患下，團隊領導人卻僅對於測試覆蓋率表現出異乎尋常的熱情，與之形成鮮明對比的是對於其它的問題冷漠和麻木。人們似乎很容易犯這樣的錯誤，由於不確定應該做什麼，或者不知道如何去做最重要的事情，最終將注意力放在了易於提公升的次等重要的事情上。
很多團隊的領袖不遺餘力地提公升測試覆蓋率，以至於患上了「測試覆蓋率大於90強迫症」，89.99%的測試覆蓋率也會讓他們寢食難安，並發明了自動化測試覆蓋率檢查工具(當測試覆蓋率達不到90%，測試便會失敗)來減輕自己的症狀。在我看來，這一強迫症的**在於對專案控制的力不從心引發的壓力無法排除，加強對於測試覆蓋率(或者專案其它生命體徵)的要求從技術決策變成了心理上的減壓渠道。面對可能的專案失敗，他蠻可以說：「技術職位上我盡了最大的努力，看看測試覆蓋率！專案的失敗應歸罪於愚蠢的合同(銷售)，不清晰的需求(業務分析師)，又或者是不切實際的進度安排(專案管理者)。」
拋開管理因素不談， 從技術上講，高測試覆蓋率和高質量的軟體能夠被等同起來麼？看看下面的例子：
ncover會告訴我們測試已經完全覆蓋了功能(測試覆蓋率100%)。可事實果真如此麼？現有的測試至少不能回答系統在如下情況下對於「除法」這個功能的期待是什麼？
測試覆蓋率僅僅能夠告訴團隊什麼沒有被測試，根本就回答不了軟體是否經過了有效測試！
舌苔厚重反映的是消化問題，**方案當然不是刷刷舌頭這麼簡單，同樣，測試覆蓋率低的病灶常常是：
相對於提公升測試覆蓋率，這些問題解決起來就要複雜的多，也棘手的多。我不確定特定環境上述問題的解決問題是什麼，但是我很確定補測試不是良方，它往往會催生出沒有assert的畸形測試以及大量針對getter/setter的無用測試。
檢查覆蓋率得到好的結果可以增強團隊信心，鞏固測試實踐；而得到壞的結果則需要綜合分析，找到原因，制定改進方案。這是團隊積累經驗，提公升能力的一種有效途徑，單純要求提高覆蓋率則是頭疼醫頭，腳疼醫腳的可笑方法。測試不是為了**需要被測試的需求而存在，它存在的原因是市場需要以低成本生產高質量軟體。補測試無法滿足測試實踐的內在需求。在我看來，利用覆蓋率的分析結果在團隊中引發乙個話題，討論系統模型的可測試性、設計的合理性，並藉此改善產品才是更加可取的做法，單純追求覆蓋率常常反映出團隊將流程和目標混淆起來，甚至誤將流程當作了目標。
如果不再要求所有的元件必須被覆蓋，我們就必須回答乙個新的問題：「哪些元件應該被覆蓋？ 多少覆蓋率比較合適？」。以我的經驗，在考慮測試策略時至少需要參考業務價值，功能變化趨勢以及缺陷率這三個因素：業務價值是核心，討論清楚業務流程和價值，優先針對高業務價值的功能分析和設計測試。其次是根據元件的變化趨勢有重點的投資測試。系統中一定存在常常變化的元件，對於這些元件多投入一些測試有助於減少破壞已完成功能的風險，並進而提高團隊的信心。bug則是另乙個風向標，向我們指明系統的哪些部分比較薄弱。對bug進行一下分類整理，我們就能很容易的發現系統的這些薄弱區域；在這些區域新增測試、修補有缺陷的功能，將有助於提高產品的質量。
去解決資料掩蓋之下的問題難度更大也更令人恐懼，沒人清楚我們可以走多遠，但重要的是我們已經出發。恐懼和無所適從是因為我們所面對的新領域再沒有絕對的對錯，再沒有容易做出的決策，我們需要更多經驗，承擔更多的風險，它迫使我們駛出了心理舒適區，開始在心理學習區鍛鍊自我，挑戰自我，只有這樣資料強迫症才會被清除**。
測試覆蓋率
摘要 在測試方法中粗略的介紹了幾種測試方法。其中，白盒測試的動態分析方法中提到邏輯覆蓋率測試有 語句覆蓋 分支覆蓋 判定覆蓋 條件覆蓋 條件 判定覆蓋和路徑覆蓋。這裡將詳細闡述邏輯覆蓋率測試。準備知識 可執行語句 可執行的一項操作 真 假分支 ture false 運算元 opreand 操作符 o...
測試覆蓋率
摘要 在 測試 方法中粗略的介紹了幾種測試方法。其中，白盒測試 的動態分析方法中提到邏輯覆蓋率測試有 語句覆蓋 分支覆蓋 判定覆蓋 條件覆蓋 條件 判定覆蓋和路徑覆蓋。這裡將詳細闡述邏輯覆蓋率測試。準備知識 可執行語句 可執行的一項操作 真 假分支 ture false 運算元 opreand 操作...
測試 覆蓋率
覆蓋率準則 覆蓋率是度量測試完整性的乙個手段，是測試有效性的乙個度量。通過已執行 表示，用於可靠性 穩定性以及效能的評測。測試覆蓋是對測試完全程度的評測。測試覆蓋是由測試需求和測試用例的覆蓋或已執行 的覆蓋表示的。建立在對測試結果的評估和對測試過程中確定的變更請求 缺陷 的分析的基礎上。測試覆蓋是就...