1、-作者xxxx-日期xxxx軟件測試(驗收)大綱【精品文檔】軟件測試（驗收）大綱1. 引言57 目的57 術語57 參照標準572. 測試日期安排583. 測試小組及成員584. 測試具體內容58 合法性檢查58 軟件文檔檢查58 必須提供檢查的文檔58 其他可能需要檢查的文檔59 由業主確定必須檢查的其他文檔59 文檔質量的度量準則59 軟件代碼測試59 源代碼一般性檢查59 軟件一致性檢查60 軟件系統測試60 界面(外觀)測試61 可用性測試61 功能測試61 穩定性(強度)測試61 性能測試61 強壯性(恢復)測試61 邏輯性測試61 破壞性測試61 安全性測試625. 測試結果交付方

2、式621. 引言1.1 目的為了盡可能的找出軟件的不足，提高軟件的質量，促進軟件的成功驗收，專門制定了本大綱。其主要目的在于為所要進行的測試工作制定各種必要的準則和規范，以及在有關方面協議的基礎上對測試工作進行合理組織與管理。1.2 術語本大綱所提及的術語，其定義遵照GB/T 11457標準。1.3 參照標準 GB/T 114571995軟件工程術語 GB 85661995；信息技術軟件生存期過程 OGB 85671988*計算機軟件產品開發文件編制指南 GB 9385*計算機軟件需求說明編制指南 GB 93861988*計算機軟件測試文件編制指南 GB/T 125041990計算機軟件質量保

3、證計劃規范 OGB/T 125051990計算機軟件配置管理計劃規范 OGB/T 140791993軟件維護指南 OGB/T 143941993計算機軟件可靠性和可維護性管理 GB/T 16680一1996軟件文檔管理指南 開發者企業規范軟件開發者有關軟件工程的規范 其它文件例如：合同書等，法律文件中的有關規定。說明：（1）應該遵循自頂而下、就嚴不就寬的原則，除非合同書等法律文件中另有規定。 （2）標記（*）號的標準為推薦標準。2. 測試日期安排開發方如期交付軟件的基礎上，由業主審核確定具體日期安排。3. 測試小組及成員由業主聘請具有一定的分析、設計、編程和軟件測試經驗的測試組長和其他專業人員

4、組成。測試組設組長一名(可設有副組長)，負責整個測試的計劃、組織工作。或委托具有國家認可測試資質的第三方進行測試。4. 測試具體內容測試內容應該包括：合法性檢查、文檔檢查、軟件一致性檢查、軟件系統測試與測試結果評審等幾項工作。4.1 合法性檢查檢查開發者在開發本軟件時，使用的開發工具是否合法。對在編程中使用的一些非本單位自己開發的，也不是由開發工具提供的控件、組件、函數庫等，檢查其是否有合法的發布許可。4.2 軟件文檔檢查4.2.1 必須提供檢查的文檔 項目實施計劃； 詳細技術方案； 軟件需求規格說明書(STP)(含數據字典)； 概要設計說明書(PDD)； 詳細設計說明書(DDD)(含數據庫設

5、計說明書)； 軟件測試計劃(STP)(含測試用例)； 軟件測試報告(STR)； 用戶手冊(SUM)(含操作、使用、維護、應急處理手冊)； 源程序(SCL)(不可修改的電子文檔)； 項目實施計劃(PIP)； 項目開發總結(PDS)； 軟件質量保證計劃(SQAP)；4.2.2 其他可能需要檢查的文檔 軟件配置計劃(SCMPP)； 項目進展報表(PPR)； 階段評審報表(PRR)；4.2.3 由業主確定必須檢查的其他文檔說明：如果業主認為節和節所列文檔之外，還需要檢查其它文檔，則在此列出文檔名稱；如果業主認為不需要進行額外的文檔檢查，則本部分無內容。4.2.4 文檔質量的度量準則文檔是軟件的重要組成

6、都分，是軟件生存周期各個不同階段的產品描述。文檔質量的度量準則就是要評審各階段文檔的合適性。主要有以下六條： 完備性開發方必須按照GB 8567(計算機軟件產品開發文件編制指南)的規定編制相應的文檔，以保證在開發階段結束時其文檔是齊全的。 正確性在軟件開發各個階段所編寫的文檔的內容，必須真實的反映階段的工作且與該階段的需求相一致。 簡明性在軟件開發各個階段所編寫的各種文檔的語言表達應該清晰、準確簡練，適合各種文檔的特定讀者。 可追蹤性在軟件開發各個階段所編寫的各種文檔應該具有良好的可追蹤性。文檔的可追蹤性包括橫向可追蹤性和縱向可追蹤性兩個方面。前者是指在不同的文檔的相關內容之間相互檢索的難易程

7、序；后者是指確定同一文檔某一內容在本文檔范圍中檢索的難易程度。 自說明性在軟件開發各個階段所編寫的各種文檔應該具有較好的自說明性。文檔的自說明性是指在軟件開發各個階段中，不同文檔能夠獨立表達，該軟件在其相應階段的階段成果的能力。 規范性在軟件開發各個階段所編寫的各種文檔應該具有良好的規范性。文檔的規范性是指文檔的封面、大綱、術語的含義以及圖示符號等符合有關規范的規定。4.3 軟件代碼測試4.3.1 源代碼一般性檢查僅對系統關鍵模塊的源代碼進行抽查，檢查模塊代碼編寫的規范性，批注的準確性，是否存在潛在性錯誤，以及代碼的可維護性。 命名規范檢查檢查源代碼中的變量、函數、對象、過程等的命名是否符合約

8、定規范，該規范可以由開發方在軟件工程文檔規范中單方面約定。 注釋檢查檢查程序中的注釋是否規范，注釋量是否達到約定要求，例如：要求注釋量達到30左右。 接口檢查檢查數據庫接口等外部接口是否符合要求，各程序模塊使用的接口方式是否一致，特定的外部接口協議是否符合。 數據類型檢查源代碼中涉及的金額的常量、變量及數據集和數據庫中涉及金額的數據類型是否采用貨幣類型，以防止在特定條件下產生較大的誤差而影響統計結果。 限制性檢查對一些程序中使用到的、具有使用限制的命令、事件、方法、過程、函數、對象、控件等進行檢查。檢查在長時間運行時，有無可能接近或者達到限制條件，這里考慮的系統運行時間可能長達數年。4.3.2

9、 軟件一致性檢查 編譯檢查要求提交的源代碼在其規定的編譯環境中，能夠重新編譯無錯誤，并且能夠完成相應的功能，從而確定移交的確實是正確的源代碼。 安裝卸載檢查在新系統上用交付的軟件安裝盤重新安裝各個模塊，并且通過運行這些軟件模塊，能否完成相應的功能，從而確定移交的確實是正確的軟件安裝盤。在安裝后立即卸載所安裝的模塊，并且檢查是否能夠做到徹底卸載。 運行模塊檢查將新安裝的軟件模塊與現場運行模塊用軟件工具抽樣比較，確認交付的軟件安裝盤與現場運行軟件一致。抽查數處現場運行模塊用軟件工具比較，確認現場運行軟件一致。4.4 軟件系統測試軟件系統測試不僅是檢測軟件的整體行為表現，從另一個側面看，也是對軟件開

10、發設計的再確認。進行軟件系統測試工作時，具體的測試用例是由開發方提供，并由測試方和用戶共同補充制定的。在開發方做完功能演示后，可以進行下列測試： 界面(外觀)測試； 可用性測試； 功能測試； 穩定性(強度)測試； 性能測試； 強壯性(恢復)測試； 邏輯性測試； 破壞性測試； 安全性測試。說明：實際進行的測試內容有測試方法和業主根據具體情況共同確定，并非文中所列測試內容都必須進行測試。4.4.1 界面(外觀)測試對照界面規范(在軟件需求規格說明書中規定，或者由軟件工程規范中給出)和界面表(在概要設計中給出)，檢查各界面設計是否規范，包括：界面風格、表現形式、組件用法、字體選擇、字號選擇、色彩搭配

11、、日期表現、計時方法、時間格式、對齊方式等等，是否符合規范、是否協調一致、是否便于操作。4.4.2 可用性測試測試操作是否方便，用戶界面是否友好等。測試系統是否有影響操作流程的界面Bug和功能Bug，紀錄具體Bug的數量、出現頻率和嚴重程度。4.4.3 功能測試檢查數據在流程中各個階段的準確性。對系統中每一模塊利用實際數據運行，將其結果與同樣數據環境下應該得出的結果相比較，或與軟件需求規格說明書中要求的結果進行比較，如有偏差，則功能測試不能通過。檢查軟件需求規格說明書中描述的需求是否都得到滿足；系統是否缺乏軟件需求規格說明書中規定的重要功能；以及系統實際使用中不可缺少而軟件需求規格說明書中沒有

12、規定的功能。如果存在遺產數據，應該檢查遺產數據轉換是否正確。4.4.4 穩定性(強度)測試測試系統的能力最高實際限度，即檢查軟件在一些超負荷情況下，功能實現的情況。例如：要求軟件進行某一行為的大量重復、輸入大量的數據或大數值數據、對數據庫進行大量復雜的查詢等。利用邊界測試(最大值、最小值、N次循環)對系統進行模擬運行測試，觀察其是否處于穩定狀態。4.4.5 性能測試根據系統設計指標，或者對被測軟件提出的性能指標，測試軟件的運行性能，例如：傳輸連接最長時限、傳輸錯誤率、計算精度、記錄精度、響應時限和恢復時限等。4.4.6 強壯性(恢復)測試采用人工的干擾使應用軟件、平臺軟件或者系統硬件出錯，中斷正常使用，檢測系統的恢復能力。進行強壯性測試時，應該參考性能測試相關的測試指標。4.4.7 邏輯性測試根據系統的功能邏輯圖，測試軟件是否按規定的邏輯路徑運行，選擇一些極限數據判斷軟件運行是否存在錯誤或非法路徑，從而發現系統的邏輯錯誤或非法后門。4.4.8 破壞性測試輸入錯誤的或非法的數據(類型)，檢查系統的報錯糾錯的能力及穩定性。并測試可連續使用多長時間而系統不崩潰。4.4.9 安全性測試驗證安裝在系統內的保護機構確實能夠對系統進行保護，使之不受各種非常的干擾，安全測試時需要設計一些測試用例試圖突破系統