測試時代工作室推出“案例分析”欄目，主要搜集過程改進、質量管理、測試等多方面的案例，之后邀請相應方面的專家來點評這些案例。主要采取以下的方式：
方式一：設立各行業軟件測試解決方案案例分析，對于行業的測試項目進行做案例分析。
方式二：按照測試管理，測試技術，過程改進分類，對于測試組織中的管理案例和技術實施以及優化工作方式方法的案例做分析。
方式三：按照測試時代論壇的欄目分類方式，把相關的技術案例分類進行做分析。
方式四：按照不同類別的軟件，如，應用類的，游戲類的，驅動類的，工具類的，防火墻類等等軟件測試案例分析，主要分析測試技術的正確應用。
　　案例和案例專家分析的文章由測試時代論壇上的各版主來維護，過客可以以評論的形式發言。預計一個月到一個半月搞一期。

案例分析第六期（2005-08）

你在日常的工作中沒有遇到問題嗎？如果有，你也可以提交案例�！�我要提交案例】
案例分析
		本期案例
題目：覆蓋率如何計算？ 所屬主題：軟件質量度量 作者：Green
案例內容： 　　有誰知道如何知道測試用例對需求的覆蓋率？ 　　測試的覆蓋率又是如何計算的？
相關分析
分析一： 　　作者：ggwemail 　　分析內容： 　　不知道你們用什么分析方法。一般如果用用例的話，用例都可能映射出測試用例，他們可能是多對多的關系。你也可以用需求跟蹤矩陣來跟蹤、檢查測試用例的需求覆蓋率。 　　但是只是需求覆蓋是遠遠不夠的，還要進行例如：語句、判定、條件、組合等等的覆蓋。如果測試力量較弱就只做到語句、判定吧！ 　　不過這些覆蓋率一般是用自動測試工具自動統計的，如果用手工統計太繁瑣，復雜的系統也是沒法辦到的。嵌入式系統要更復雜些。
分析二： 　　作者：小穎 　　分析內容： 　　我覺得計算測試覆蓋率是考核測試人員的工作質量，達到高的覆蓋率，軟件質量也許就會提高吧，但是目前大多數公司也沒有引入自動化測試工具，根本無法去計算路徑、語句、判定、條件、組合等等的覆蓋。目前我們只能從測試人員的測試記錄中可以查看到需求功能的測試覆蓋率，只能說目前保證了功能測試全面性。
分析三： 　　作者：越中女兒 　　分析內容： 　　我也覺得也是，如果是一個很龐大的項目，你根本就沒有指望通過語句、判定、條件、組合等等的覆蓋來進行。關于如何確定覆蓋率，如何編寫出有效合適的用例，這個問題我也一直在思考，但是，對于一個沒有白盒測試的公司而言，是相當困難的。但是如果我們的QA連覆蓋率都不知道，又談何對于項目整體品質的監控呢？
分析四： 　　作者：戴金龍 　　分析內容： 　　測試覆蓋率包括功能點覆蓋率和結構覆蓋率。功能點覆蓋率大致用于表示軟件已經實現的功能與軟件需要實現的功能之間的比例關系。一般地，軟件需要實現的功能由軟件需求規格說明給出，由設計規格說明細化。在實際操作中，計算某軟件功能點覆蓋率的最佳時機宜選在功能測試階段，具體結果由功能測試人員匯總后給出。也有一些企業選擇在單元測試階段做功能點覆蓋。筆者認為，這樣效果并不很好。如果功能點粒度很細，確有必要提前進行，筆者建議在集成測試階段進行。因為集成階段涉及模塊組裝以及分系統集成。 　　結構覆蓋率一般包括語句覆蓋率和路徑覆蓋率。所謂語句覆蓋率，是指程序代碼經編譯后形成的指令在測試過程中實際被執行的比例數。注意：這里已經排除了“死語句”，即不要把冗余語句和永遠無法到達的語句放在語句覆蓋率的計算中。一般意義上，語句覆蓋率百分之百是指編譯后形成的指令在實際測試過程中均被執行過，而沒有強調必須在一次測試中全部覆蓋所有指令。因此，語句覆蓋率具有較好的可操作性，測試成本也不高。一般，計算語句覆蓋率可以選擇在單元測試階段進行。 　　與語句覆蓋率相對應的是路徑覆蓋率。路徑覆蓋率百分之百是指測試過程必須遍歷程序所有可能的執行路徑。顯然，在面向對象時代，百分之百的路徑覆蓋率是難以實現的。運用簡單的排列組合知識，不難可以發現，語句覆蓋率用的是加法法則，而路徑覆蓋率用的是乘法法則，要遍歷程序所有可能的執行路徑大多數情況下是不現實的。然而，路徑覆蓋率的誘惑太大了，路徑覆蓋率遠比語句覆蓋率更有意義，因此，針對于路徑覆蓋，不少人作了更進一步的算法優化，有些使乘法運算的某些乘法因子變小，有些使乘法運算的次數變少，取得了不少成果。但整體來看，目前突破并不大，并沒有徹底改變路徑覆蓋率乘法運算的根本屬性。 　　結構覆蓋率除了上面講的語句覆蓋率和路徑覆蓋率，還有一些雜七雜八的概念，比如分支覆蓋率、循環覆蓋率、條件覆蓋率、線程覆蓋率、模塊覆蓋率等等等等。筆者覺得太復雜，不實用。如果是寫學術文章，可能有點意思；但如果要用來指導工程實踐，基本幫不上忙。 　　最后，從企業應用的角度，筆者推薦在單元測試階段做好語句覆蓋，在集成與系統測試階段做好功能點覆蓋，一般商用軟件這樣做就夠了。至于路徑覆蓋，在沒有充足的理由和必要的準備的情況下盡量不要去提，如果條件不具備，提了也難以保證測試效果。實踐告訴我們，針對整個軟件的路徑覆蓋率往往是一句口號；如果資源真的很充足，而且確有必要，那么，建議在模塊內部踏踏實實做好路徑覆蓋測試就夠了。模塊與模塊間的路徑測試往往是很不容易的。
測試時代工作室分析
測試用例對需求的覆蓋率是指所有的測試用例對全部需求的覆蓋率。而這種大而全的概念無法體現出軟件測試的特點，即測試類型。只有按測試類型統計覆蓋率，才能體現出“覆蓋率”的價值。 測試覆蓋：指測試用例對同類型需求的覆蓋率。 　　總的需求覆蓋計算方法為：各類型測試的覆蓋率的加權平均值；其中，各類型的加權值由測試負責人或質控負責人給出。 　　做法思路：將大目標劃分成多個小目標，對小目標的實現最終匯總為對大目標的實現。這種思路適合絕大多數的目標、計劃等等。
關注案例
焦點5：在軟件項目規劃和開發階段，如何考慮與測試配合？ 焦點7：如何進行滾動測試？ 焦點8：嵌入式軟件的測試設計應該如何做？ 焦點9：怎么搭建測試環境。
案例分析
你在日常的工作中沒有遇到問題嗎？如果有，你也可以提交案例�！�我要提交案例】
－>本期案例點評