【正文】 年 月 日 軟件測試規(guī)范 附錄六 程序錯誤報告 19 附錄六 程序錯誤報告 （系統(tǒng)名稱） 測試項目 項目名稱 測試類型 模塊 名稱 模塊名稱 版本 測試時間 測試批次 序號 錯誤等級 錯 誤 描 述 修改情況 復 核 測試人： 軟件測試規(guī)范 附錄七 測試分析誤報告 20 附錄七 測試分析報告 1 概述 編寫目的 編寫本文檔的目的在于 通過對測試結果的分析得到對軟件的評價； 為糾正軟件缺陷提供依據(jù)； 使用戶對系統(tǒng)運行建立信心。 3 測試分析 測試結果分析 列出測試結果分析記錄 ,并按下列模板產生 BUG 分布表和 BUG 分布圖。 測試主管： 年 月 日 B U G 分布圖9%74%13%0% 4%A級B級C級D級E級。 測試評估 通過對測試結果的分析提出一個對軟件能力的全面分析，需標明遺留缺陷、局限性和軟件的約束限制等，并提出改進建議。 術語和縮 寫詞 說明本次測試所涉及到的專業(yè)術語和縮寫詞等。 測試進度安排 給出進行測試工作的時間安排。 3 測試環(huán)境 硬件 列出進行本次測試所需的硬件資源的型號、配置和廠家。 參考資料 說明軟件測試所需的資料（需求分析、設計規(guī)范等）。 [測試 2 名稱及標識符 ]說明 測評組： 年 月 日 軟件測試規(guī)范 附錄四 測試大綱附錄 17 附錄四 測試大綱附錄 本附錄描述了各測試步驟的詳細說明，在填入測試結果后，可直接作為測試記錄。 [測試 1 名稱及標識符 ]說明 測試概述 對測試 1 進行一個總體描述 ,主要說明這組測試的基本內容。 3 測試目的 4 測試環(huán)境 硬件 列出進行本次測試所需的硬件資源的型號、配置和廠家。 ] 本文檔的編寫目的在于為 XXXX（軟件名稱）軟件測試人員提 供詳細的測試步驟和測試數(shù)據(jù)，以保證測試人員對軟件測試的正確性和完整性。 A類錯誤 B類錯誤 C類錯誤 D類錯誤 E類建議 無 無 1% 5% 暫不作要求 以上比例為錯誤占總測試模塊的比例。 上面四個例子雖然滿足條件組合覆蓋，但并不能覆蓋程序中的每一條路徑，可以看出條件組合覆 蓋仍然是不徹底的，在白盒測試時，要設法彌補這個缺陷。 “條件組合覆蓋”的含義是：執(zhí)行足夠的測試用例，使得每個判定中條件的各種可能組合都至少執(zhí)行一次。 對于例子程序，我們選取測試用例： (1)A=2， B=0， x=4 (2)A=1， B=l， x=l 它滿足判定／條件覆蓋標準。 IF(A AND B)THEN S 設計兩個測試用例： A“真” B“假”和 A“假” B“真”。 它的含義是：執(zhí)行足夠的測試用例，使得判定中每個條件獲得各種可能的結果。 比“語句覆蓋”稍強的覆蓋標準是“判定覆蓋” (或稱分支覆蓋 )。 顯然，語句覆蓋是一個比較弱的覆蓋標準。 所謂“語句覆蓋”測試標準，它的含義是：選擇足夠的測試用例，使得程序中每個語句至少都能執(zhí)行一次。最徹底的白盒法是覆蓋程序中的每一條路徑，但這不可能，我們希望覆蓋的路徑盡可能多一些。但當程序中含有大量循環(huán)時，要執(zhí)行每一條通路是 44可能的。但其關鍵在于隨機數(shù)的規(guī)律是否符合使用實際。 猜錯法充分發(fā)揮人的經(jīng)驗，在一個測試小組中集思廣益，方便實用，特別在軟件測試基礎較差的情況下，很好地組織 測試小組 (也可以有外來人員 )進行錯誤猜測，是有效的測試方法。如果能在等價類劃分中注入邊值分析的思想。一個典型的邊值分析例子是三角形分類程序。如有規(guī)范“某文件可包含 l至 255”個記錄??“，則測試用例可選 1和 255及 0和 256等。另外，邊值分析不僅考查輸入的邊值，也要考慮輸出的邊值。把判定表的每一列寫成一個測試用例。 分析程序規(guī)范的描述中語 義的內容，并將其表示成連接各個原因與各個結果的“因果圖”。采用因果圖方法能幫助我們按一定步驟選擇一組高效的測試用例，同時，還能為我們指出程序規(guī)范的描述中存在什么問題。等價類劃分法能夠全面、系統(tǒng)地考慮黑盒測試的測試用例設計問題，但是沒有注意選用 一些“高效的”、“有針對性的”測試用例。重復這一步，最后使得所有有效等價類均被測試用例所覆蓋； 設計一個新的測試用例，使其只覆蓋一個無效等價類。 如果我們確知，已劃分的等價類中各元素在程序中的處理方式是不同的，則應將此等價類進一步劃分成更小等價類。 確定等價類有以下幾條原則： 如果輸入條件規(guī)定了取值范圍或值的個數(shù)，則可確定一個有效等價類和兩個無效等價類。 在考慮等價類時，應該注意區(qū)別以下兩種不同的情況： 有效等價類：有效等價類指的是對程序的規(guī)范是有意義的、合理的輸入數(shù)據(jù)所構成的集合。它表示對揭露程序中的錯誤來說，集合中的每個輸入條件是等效的。下述幾種方法： (a)等價類劃分， (b)因果圖方法， (c)邊值 分析法， (d)猜錯法， (e)隨機數(shù)法，就是從更廣泛的角度來進行黑盒測試。 用數(shù)據(jù)類型和數(shù)據(jù)值的最小集測試。完整的“任何情況”是無法驗證的，為此黑盒測試也有一套產生測試用例的方法，以產生有限的測試用例而覆蓋足夠多的“任何情況”。 軟件測試規(guī)范 黑盒測試方法 7 五 .黑盒測試方法 黑盒測試 (black— box testing)又稱功能測試、數(shù)據(jù)驅動測試或基于規(guī)范的測試 (即 ec 顛cation— based testing)。在這個測試步驟中發(fā)現(xiàn)的往往是軟件設計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤。 子系統(tǒng)測試是把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。因此，大型軟件系統(tǒng)的測試基本上由下述幾個步驟組成： 在設計得好的軟件系統(tǒng)中，每個模塊完成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關系。 妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。 對測試錯誤結果一定要有一個確認的過程。 這一項測試主要是對軟件的錯誤處理功能進行測試。數(shù)據(jù)查詢（顯示）界面應注意顯示信息是否正確和完整。（以邊界值法、等價類劃分法為主）。（每一個子界面也應如此） 其中，應注意提示信息和軟件開發(fā)商信息是否正確。 由項目開發(fā)組或測試組配合用戶進行用戶方測試。 待測軟件測試通過后，項目測評結束。 提交《測試分析報告》。 測試組按測試計劃、測試大綱的要求對待測軟件進行有效性測試、集成測試。 項目開發(fā)組對完成的功能模塊進行單元測試，測試人員參與單元測試過程；單元測試完成，產生單元測試報告。 軟件測試規(guī)范 軟件測試流程 3 三 .軟件測試流程 N Y N Y N Y 參與需求分析，了解項目需求內容 了解需求變更 制定《測試計劃 》 編寫《測試大 綱》 編寫《單元測試報告》 項目組進行修改 編寫《集成測試報告》 項目組進行修改 收集待測軟件的各種相關文檔及 《需求分析》、《軟件設計規(guī)范》和上一級《測試報告》 填寫《錯誤報告》 項目組進行修改 編寫《測試分析報告》 提交《測試分析報