1、軟件測試規范1 測試目的為了確保軟件產品的質量，使產品能夠順利交付和工程驗收。2 測試職責（ 1 ）編寫測試計劃&測試方案，指導測試。（2） 搭建測試環境。（3） 完成所承擔的測試任務，并按要求填寫問題報告。（4） 測試出現bug 及時與研發人員進行溝通確認，確認是 bug 的情況下提缺陷報告單記錄bug,并在下一版本中返測該問題單。3 工作流程（ 1 ）測試依據：詳細設計是測試的依據。因此設計人員需向測試人員提供系統需求規格書詳細設計概要設計等相關材料，測試人員需仔細閱讀相關材料，弄清系統的功能需求和詳細設計。（ 2） 測試方案的制定：在測試之前需要編寫測試方案， 測試方案包含： 測

2、試目的; 所需人員及相應培訓要求; 測試環境工具及測試軟件; 測試用例測試數據及預期結果。（ 3） 單元測試軟件產品在開發過程中，每個功能模塊開發完成代碼調試后都要盡快的進行單元測試，測試出的bug 應立即進行修改。（ 4） 集成測試在單元測試的基礎上，在代碼開發完成后進行的組裝測試，將每個單元組合成一個軟件系統進行集中測試，此時需要進行編寫測試計劃和測試用例。集成測試著重驗證各功能模塊之間能否協調工作，參數傳遞及功能調用是否正常。集成測試中出現問題應提交缺陷報告單，記錄缺陷，待下一版本中進行驗證，也 就是接口之間的測試。（ 5） 系統測試在項目開發完成后，應對整個系統軟件進行系統測試，對功能

3、性能 可靠性壓力承受能力等方面進行評價，以驗證系統是否滿足需求規定。系統測試由負責人組織編寫測試計劃和測試用例，測試用例中應覆蓋絕大部分測試點。系統測試一般測試方法如下： 有效等價類及有效邊界值; 無效等價類及無效邊界值; 非法情況; 性能測試; 場景的測試找出基本流和備選流，基本流是模擬用戶正確的操作；備選流是模擬用戶錯誤的操作; 因果圖法，找出輸入組合和輸出組合，根據輸入和輸出組合進行測試用例的編寫。界面測試一般測試如下情況： 光標的初始位置； 字體的統一性； 符號是否符合規范； 字體顏色是否符合需求； 按鈕名稱是否規范； 標題顏色。輸入參數的規范： 數據類型； 數據長度； 約束條件是否滿

4、足； 快捷鍵是否可用（鍵盤操作是否可完全替代鼠標操作）； 輸入光標是否按順序推進。按鈕測試：按鈕的可用性與置灰是否明確；檢查“確認”與“取消”功能鍵是否實現功能。異常情況測試在完成按正常操作順序測試后，按照與正常順序不同的測試動作進行測試 需求說明中要求輸入數字的地方輸入字符串，查看結果； 需求說明中有范圍要求的，超出范圍很多或者邊界值附近取值； 需求說明中有按鍵要求的，我們更改按鍵操作，查看結果； 不同于指定的按鈕操作。6） 交付版本的要求： 集成版本滿足設計定義的各項功能、性能要求； 按照集成測試用例完成整個系統的集成測試； 在集成測試中的bug 已經解決，缺陷的修復率達到標準； 系統需求

5、規格書中提到的各項功能均已實現，性能指標全部達到要求； 提交階段性測試報告，功能和性能； 所有文檔齊全。7） 軟件發布要求 軟件產品通過了單元測試、集成測試、系統測試和性能測試。 測試部門提交：測試計劃、測試方案、測試用例及結果報告。 各功能模塊需符合以下標準：致命錯誤：無嚴重問題：無功能缺陷：部門人員進行評審，認為該缺陷不影響客戶正常使用情況下可留 待下一版本解決界面缺陷：部門人員進行評審，認為該缺陷不影響客戶正常使用情況下可留 待下一版本解決在產品交付和用戶驗收之前，通過驗收測試來確認在規定的環境中整個產品的運行情況是否滿足規定的要求4、 編寫測試文檔（1） 測試點：將測試模塊分解成多個功

6、能點，測試點應涵蓋功能點，也涵蓋正常功能點和異常功能點。（2） 輸入數據：測試數據的輸入應覆蓋軟件正常功能的測試點和異常功能的測試點。（3） 測試描述：描述測試步驟，包括：測試員所執行的動作（鼠標、鍵盤、加載數據等操作）；系統的反應，包括：光標定位、顯示字段值、按鈕的置灰與否、功能鍵的實現與否和系統提示、消息等。（4） 預期輸出數據：按照準備的數據和設計要求的處理過程，模塊應輸出的預期數據，輸出數據應包括：屏幕輸出的數據、輸出到數據庫的數據和輸出到其他外部的數據。（5） 實際輸出數據：程序運行后輸出的數據。（6） 正確與否：預期結果與實際數據之間是否一致，若不一致則判定為缺陷。（7） 測試結論

7、：填寫測試結論， 是合格還是不合格， 若不合格時，應提單進行闡述，在提單的時候應該詳細敘述操作過程和操作步驟，讓開發人員能清楚的看到缺陷在哪一個模塊哪一步中產生，便于研發人員修改代碼。5、 缺陷管理（ 1） 什么是缺陷？ 軟件未實現產品所要求的功能； 軟件實現了產品未提及的功能； 軟件實現了產品指明不應該出現的錯誤； 產品需求雖未說明，但站在客戶的角度應該實現該功能； 軟件導致系統崩潰，不易使用。（ 2） 缺陷報告的組成缺陷的編號；缺陷摘要；缺陷的發現者；缺陷發現的日期；所屬模塊；發現缺陷的版本；指派給誰；缺陷的狀態；缺陷的嚴重程度；缺陷的優先級；缺陷描述；缺陷的出現頻率；附件的上傳；附注上述

8、選項都是在提交缺陷時測試人員需填寫的項目，這可以很準確的記錄缺陷的具體信息，以便在后續操作中進行缺陷跟蹤、開發修改代碼及責任劃定。（ 3） 缺陷的分類文檔缺陷：指對文檔的靜態檢查過程中發現的缺陷，檢查過程包括：文檔的評審、產品審計等。評審的缺陷要根據被評審對象的類型來確定，被評審的對象包括：需求文檔、設計文檔、報告、用例等。其中軟件缺陷中文檔中的缺陷就達到了80%。代碼缺陷：代碼走查過程中發現的缺陷。測試缺陷：指由測試活動發現的測試對象的缺陷(測試對象一般指可運行的代 碼和系統)，測試活動包括：單元測試、集成測試和系統測試、性能測試。(4) 文檔缺陷分類缺陷分類描述描述不完整文檔內容缺失或文檔

9、應該包括的范圍沒有涵蓋不T一致性問題有兩類：1、與源頭說明書不一致，比如需求和客戶業務需求不一致、設計與需 求不一致等2、上下文或者與前提不一致描述錯誤文檔描述是錯誤的，不可實現或導致錯誤的輸出或結果功能問題該缺陷將會導致用戶功能的錯誤、不滿足、/、可用不清楚或有歧義內容的描述不清楚、不能準確表達、或表達的意思有歧義邏輯錯誤內容組織邏輯不清楚、邏輯錯誤接口問題與最終用戶接口問題、與外部系統的接口問題、內部子系統或模塊的 接口問題輸入輸出問題輸入輸出不完整、不止確、不可測試或驗證不細化內容還需要八步細化性能問題文檔的設計或實現方式存在性能問題安全性問題文檔的設計或實現方式存在安全性問題(5) 代

10、碼缺陷分類常量變量定義問題、不滿足設計或需求、代碼編寫不合規范、條件判斷處理、循環處理出錯、異常處理、算法邏輯問題、注釋問題。(6) 系統缺陷分類缺陷類型描述功能錯誤影響了重要的特性、用戶界面、產品接卬或全局數據結構，并且 設計文檔需要爭取的變更。如邏輯、循環、遞歸、功能等缺陷結構錯誤Web應用程序結構化頁面尢法顯布,或者顯不錯誤腳本錯誤Web應用程序當中出現腳本錯誤，包括客戶端對數據進行校驗和 運算的各種情況卜產生的錯誤貝血鏈接錯誤Web應用程序貝血出現空鏈接、錯誤鏈接、死鏈接貝聞文子錯誤Web應用程序貝囿出現的中外文拼寫、使用、以及小同語種貝囿 的編碼錯誤頁面圖形錯誤Web應用程序貝囿出現

11、圖片內容使用小當，或者無法顯示ALT錯誤Web應用程序頁面當中超文本標識語言、文本標簽解釋錯誤排版錯誤Web應用程序頁面排版不符合要求或者不符合使用習慣業務邏輯不合理應用程序的實現流程和規定業務流程不一致，或者實現流程無法 正確完成。包括流程數據的部分并行、爭用、同步等操作，引起 的流程斷裂、死鎖、以及其他異常情況業務邏輯不方便應用程序實現流程在實際情況下雖然可以完成，但是存在不必要 的反復、等待、冗余等影響使用效率的情況其他錯誤其他未分類錯誤建議系統改進建議(7) 缺陷等級定義發現對象可能造成的影響或后果來定義的。缺陷 等級缺陷性質系統中對應的錯 誤分類描述一級致命錯誤系統崩潰 系統死鎖導致

12、對被描述的主要對象的理解錯誤、不可行、不可 運轉、對業務和整個系統造成重大損失或損害；對使 用、維護或保管人員有危險或不安全，以及對產品的 基本功能有致命影響的缺陷。二級嚴重缺陷嚴重錯誤對被描述的部分對象的理解或實現錯誤，部分的模塊或系統不可行或不能運轉或部分模塊和系統缺失，對整個系統有重大影響或可能造成部分的損失或損害； 嚴重影響使用安全。三級次要缺陷次要錯誤 布局不合理，文字錯誤系統中部分單兀模塊或單個功能描述和實現有錯誤、 有偏差、不一致或有缺失，不影響模塊的正常運行， 或有影響，但可以有替代的辦法或避免辦法。四級一般缺陷不影響使用的缺 陷基本不影響系統的運行和功能的實現。但是與標準、

13、規范和定義不一致。五級建議缺陷優化建議不在定義、標準、范圍的定義和約束之內，但是從提 出者來看是需要完善的建議。缺陷的嚴重程度對以上所述的缺陷類型都是適合的,缺陷的嚴重程度反映的是對缺陷的(8) 缺陷的優先級定義Urgent緊急，立即解決Veryhigh加急，本版本中解決High急，下一版本中解決Medium： 一般，缺陷需進行正常排隊進行修復，發布前解決Low：低，允許在發布中存在一定的缺陷(9) 處理缺陷的流程圖涕試人員一升段人員一網試人員一圖試人員一New,指派給開發經理；然后，開發該圖中測試人員首先提交缺陷報告，缺陷狀態為經理在收到該缺陷后進行確認，并將缺陷狀態改為open,指派給所屬

14、模塊的開發人員；開發人員接收到缺陷后，處理該缺陷，處理完畢后將該缺陷狀態改為fixed已修復，并將該缺陷重新指派給報告人；測試人員在下一版本中對缺陷進行返測，若確認缺陷修復，則將缺陷狀態改為closed,若依舊沒有修復則將缺陷狀態改為reopen ,并指派給開發人員。 除以上缺陷的5個狀態外，實際測試中有遺留問題，遺留問題需評審需求或者留待以后有計劃解決； 缺陷的合并，一個代碼錯誤導致多個問題的出現，缺陷重復。6、 軟件版本的回退機制若軟件在測試過程中出現如下情況，可以將測試版本回退到開發部門進行重新評審(1) 經過測試后，發現與需求規格說明書中所要求的功能項存在較大的差異；(2) 單一模塊，

15、測試過程中發現測試缺陷較多，影響到其他功能的測試，無法進行 下去的，繼續測試無意義的；(3) 測試過程中頻繁死機或系統崩潰的；(4) 主業務流程出現問題。7、 測試完成標準(1) 被測試出的，在軟件錯誤級別分類中定義的:一級缺陷，致命錯誤,二級缺陷，嚴重錯誤,三級缺陷，一般錯誤,四級缺陷，輕微錯誤,100%修復并且回歸通過100%修復并且回歸通過95%修復并且回歸通過95%修復并且回歸通過(2)用戶可以接受未修改的軟件錯誤；(3)超過了預計的測試時間表，由領導確定是否停止測試。8、 開發與測試之間的關系圖v型圖反應了開發與測試之間的對應關系，在該圖中各個階段的測試任務標注明確;但是它很容易讓人

16、理解為開發后期才介入的測試，測試應該越早越好，也沒有反應出文檔測試內容。當需求文檔和概要設計文檔編寫出來后，測試人員需進行文檔測試；根據需求文檔和開發文檔測試人員需要編寫測試計劃和測試用例。9、 實際工作中的測試流程（1） ）準備好服務器，等待研發人員給出版本安裝包及測試大綱文檔和需求文檔，該安裝包研發人員已經自測過；（2） 版本安裝包出來后進中試流程，測試人員在服務器上進行軟件包的安裝；（3） 設置調試好測試環境；（4） 對照測試大綱進行測試工作，結果填寫在測試大綱中，如在測試過程中遇見bug則需在系統中進行提單，報告bug 有特定系統；（5） 第一輪測試結束后，測試人員軟件也熟悉了，在下一版本出包前參照第一輪的包和測試大綱進行測試用例的編寫，編寫完成后需與軟件開發人員等相關人等評審用例；（6） 安裝第二輪的軟件包，對照測試用例進行測試，并驗證第一輪出現的bug 是否得到修復，如沒修復則在bug 系統中進行注釋，并指派給相關開發人員；（7） 如在第二輪中遇到bug依然進行提單，第二輪需驗證完第一輪發現的所有bug，需要掛起（遺留）的做特殊說明并標記，第二輪測試結束；（8） 第三輪測試工作重點在返測，回歸問題單，測試需加快速度；（9） 測試完畢后，結果報項