1、軟件測試（驗收）大綱1.1 目的.21.2 術語.21.3 參照標準 . 22.測試日期安排.33.測試小組及成員 .34.測試具體內容.34.1 合法性檢查 . 34.2 軟件文檔檢查 . 34.2.1 必須提供檢查的文檔 . 34.2.2 其他可能需要檢查的文檔 . 44.2.3 由業主確定必須檢查的其他文檔 . 44.2.4 文檔質量的度量準貝 U . 44.3 軟件代碼測試 . 44.3.1 源代碼一般性檢查.44.3.2 軟件一致性檢查.54.4 軟件系統測試 . 54.4.1 界面（外觀）測試.64.4.2 可用性測試. 64.4.3 功能測試. 64.4.4 穩定性（強度）測試.

2、64.4.5 性能測試. 64.4.6 強壯性（恢復）測試 . 64.4.7 邏輯性測試. 64.4.8 破壞性測試. 64.4.9 安全性測試. 71.引言.2.5.測試結果交付方式 .7.1.引言1.1 目的為了盡可能的找出軟件的不足， 提高軟件的質量，促進軟件的成功驗收， 專門制定了本 大綱。其主要目的在于為所要進行的測試工作制定各種必要的準則和規范，以及在有關方面協議的基礎上對測試工作進行合理組織與管理。1.2 術語本大綱所提及的術語，其定義遵照GB/T 11457標準。1.3 參照標準GB/T 114571995軟件工程術語GB 85661995； 信息技術軟件生存期過程OGB 85

3、671988*計算機軟件產品開發文件編制指南GB 9385*計算機軟件需求說明編制指南GB 93861988*計算機軟件測試文件編制指南GB/T 125041990計算機軟件質量保證計劃規范OGB/T 125051990計算機軟件配置管理計劃規范OGB/T 140791993軟件維護指南OGB/T 143941993計算機軟件可靠性和可維護性管理GB/T 16680一1996軟件文檔管理指南開發者企業規范軟件開發者有關軟件工程的規范其它文件 例如：合同書等，法律文件中的有關規定。說明：（1）應該遵循自頂而下、就嚴不就寬的原則，除非合同書等法律文件中另有規定。（2）標記（*）號的標準為推薦標準。

4、2.測試日期安排開發方如期交付軟件的基礎上，由業主審核確定具體日期安排。3.測試小組及成員由業主聘請具有一定的分析、設計、編程和軟件測試經驗的測試組長和其他專業人員組 成。測試組設組長一名（可設有副組長），負責整個測試的計劃、組織工作。或委托具有國家認可測試資質的第三方進行測試。4.測試具體內容測試內容應該包括：合法性檢查、文檔檢查、 軟件一致性檢查、軟件系統測試與測試結果評審等幾項工作。4.1 合法性檢查檢查開發者在開發本軟件時， 使用的開發工具是否合法。 對在編程中使用的一些非本單 位自己開發的，也不是由開發工具提供的控件、組件、函數庫等，檢查其是否有合法的發布許可。4.2 軟件文檔檢查4

5、.2.1必須提供檢查的文檔項目實施計劃；詳細技術方案；軟件需求規格說明書（STP）（含數據字典）；概要設計說明書（PDD）；詳細設計說明書（DDD）（含數據庫設計說明書）；軟件測試計劃（STP）（含測試用例）；軟件測試報告（STR）；用戶手冊（SUM）（含操作、使用、維護、應急處理手冊）；源程序（SCL）（不可修改的電子文檔）；項目實施計劃（PIP）；項目開發總結（PDS）；軟件質量保證計劃（SQAP）；422其他可能需要檢查的文檔軟件配置計劃（SCMPP）;項目進展報表（PPR）;階段評審報表（PRR）；4.2.3由業主確定必須檢查的其他文檔說明：如果業主認為4.1.1節和4.1.2節所列文

6、檔之外，還需要檢查其它文檔，則在此列出 文檔名稱；如果業主認為不需要進行額外的文檔檢查，則本部分無內容。4.2.4文檔質量的度量準則文檔是軟件的重要組成都分，是軟件生存周期各個不同階段的產品描述。文檔質量的度量準則就是要評審各階段文檔的合適性。主要有以下六條：完備性開發方必須按照GB 8567（計算機軟件產品開發文件編制指南）的規定編制相應的 文檔，以保證在開發階段結束時其文檔是齊全的。正確性在軟件開發各個階段所編寫的文檔的內容，必須真實的反映階段的工作且與該階段的需求相一致。簡明性在軟件開發各個階段所編寫的各種文檔的語言表達應該清晰、準確簡練，適合各 種文檔的特定讀者。可追蹤性在軟件開發各個

7、階段所編寫的各種文檔應該具有良好的可追蹤性。文檔的可追蹤性包括橫向可追蹤性和縱向可追蹤性兩個方面。前者是指在不同的文檔的相關內容之間相互檢索的難易程序；后者是指確定同一文檔某一內容在本文檔范圍中檢 索的難易程度。自說明性在軟件開發各個階段所編寫的各種文檔應該具有較好的自說明性。文檔的自說明性是指在軟件開發各個階段中， 不同文檔能夠獨立表達， 該軟件在其相應階段的 階段成果的能力。規范性在軟件開發各個階段所編寫的各種文檔應該具有良好的規范性。文檔的規范性是指文檔的封面、大綱、術語的含義以及圖示符號等符合有關規范的規定。4.3 軟件代碼測試4.3.1源代碼一般性檢查僅對系統關鍵模塊的源代碼進行抽查

8、，檢查模塊代碼編寫的規范性，批注的準確性，是否存在潛在性錯誤，以及代碼的可維護性。命名規范檢查檢查源代碼中的變量、函數、對象、過程等的命名是否符合約定規范，該規范可 以由開發方在軟件工程文檔規范中單方面約定。注釋檢查檢查程序中的注釋是否規范，注釋量是否達到約定要求，例如：要求注釋量達到30%左右。接口檢查檢查數據庫接口等外部接口是否符合要求，各程序模塊使用的接口方式是否一致，特定的外部接口協議是否符合。數據類型檢查源代碼中涉及的金額的常量、變量及數據集和數據庫中涉及金額的數據類型是否 采用貨幣類型，以防止在特定條件下產生較大的誤差而影響統計結果。限制性檢查對一些程序中使用到的、具有使用限制的命

9、令、事件、方法、過程、函數、對象、 控件等進行檢查。檢查在長時間運行時，有無可能接近或者達到限制條件， 這里考慮的系統運行時間可能長達數年。4.3.2軟件一致性檢查編譯檢查要求提交的源代碼在其規定的編譯環境中，能夠重新編譯無錯誤，并且能夠完成 相應的功能，從而確定移交的確實是正確的源代碼。安裝/卸載檢查在新系統上用交付的軟件安裝盤重新安裝各個模塊，并且通過運行這些軟件模 塊，能否完成相應的功能，從而確定移交的確實是正確的軟件安裝盤。在安裝后立即卸載所安裝的模塊，并且檢查是否能夠做到徹底卸載。運行模塊檢查將新安裝的軟件模塊與現場運行模塊用軟件工具抽樣比較，確認交付的軟件安裝盤與現場運行軟件一致。

10、抽查數處現場運行模塊用軟件工具比較，確認現場運行軟件一致。4.4 軟件系統測試軟件系統測試不僅是檢測軟件的整體行為表現， 從另一個側面看， 也是對軟件開 發設計的再確認。進行軟件系統測試工作時，具體的測試用例是由開發方提供，并由測試方和用戶共同補充制定的。在開發方做完功能演示后，可以進行下列測試：界面（外觀）測試；可用性測試；功能測試；穩定性（強度）測試；性能測試；強壯性（恢復）測試；邏輯性測試；破壞性測試；安全性測試。說明：實際進行的測試內容有測試方法和業主根據具體情況共同確定，并非文中所列測試內容都必須進行測試。441界面（外觀）測試對照界面規范（在軟件需求規格說明書中規定， 或者由軟件工

11、程規范中給出）和界面表（在 概要設計中給出），檢查各界面設計是否規范，包括：界面風格、表現形式、組件用法、字 體選擇、字號選擇、色彩搭配、日期表現、計時方法、時間格式、對齊方式等等，是否符合 規范、是否協調一致、是否便于操作。4.4.2可用性測試測試操作是否方便，用戶界面是否友好等。測試系統是否有影響操作流程的界面Bug和功能Bug，紀錄具體Bug的數量、出現頻率和嚴重程度。4.4.3功能測試檢查數據在流程中各個階段的準確性。對系統中每一模塊利用實際數據運行，將其結果與同樣數據環境下應該得出的結果相比較，或與軟件需求規格說明書中要求的結果進行比 較，如有偏差，則功能測試不能通過。檢查軟件需求規

12、格說明書中描述的需求是否都得到滿足；系統是否缺乏軟件需求規格說明書中規定的重要功能；以及系統實際使用中不可缺少而軟件需求規格說明書中沒有規定的 功能。如果存在遺產數據，應該檢查遺產數據轉換是否正確。4.4.4穩定性（強度）測試測試系統的能力最高實際限度，即檢查軟件在一些超負荷情況下，功能實現的情況。例如：要求軟件進行某一行為的大量重復、輸入大量的數據或大數值數據、對數據庫進行大量復雜的查詢等。利用邊界測試（最大值、最小值、N次循環）對系統進行模擬運行測試，觀察其是否處于 穩定狀態。4.4.5性能測試根據系統設計指標，或者對被測軟件提出的性能指標，測試軟件的運行性能，例如：傳輸連接最長時限、傳輸

13、錯誤率、計算精度、記錄精度、響應時限和恢復時限等。4.4.6強壯性（恢復）測試采用人工的干擾使應用軟件、平臺軟件或者系統硬件出錯，中斷正常使用，檢測系統的恢復能力。進行強壯性測試時，應該參考性能測試相關的測試指標。4.4.7邏輯性測試根據系統的功能邏輯圖，測試軟件是否按規定的邏輯路徑運行，選擇一些極限數據判斷軟件運行是否存在錯誤或非法路徑，從而發現系統的邏輯錯誤或非法后門。4.4.8破壞性測試輸入錯誤的或非法的數據（類型），檢查系統的報錯糾錯的能力及穩定性。并測試可連續 使用多長時間而系統不崩潰。449安全性測試驗證安裝在系統內的保護機構確實能夠對系統進行保護，使之不受各種非常的干擾，安全測試時需要