（v0.2）
修訂歷史記錄
目錄1. 概要 3
1.1. 目的 3
1.2. 適用範圍 3
2. 職責 4
3. 測試準備 4
3.1. 文件分析 4
3.2. 測試計畫 4
3.3. 測試用例 4
3.3.1. 測試用例設計方法 5
3.4. 測試軟/硬體環境 5
3.5. 測試資料準備 5
4. 測試執行 5
4.1. 專案測試週期 5
4.2. 專案測試啟動 6
4.3. 專案測試階段 6
4.4. 專案測試結束 6
5. 測試變更 6
6. 缺陷管理 6
6.1. 缺陷管理流程 6
6.2. 問題提交 7
6.3. 問題分配 7
6.4. 問題修改 7
6.5. 問題關閉 7
7. 回歸測試 7
7.1. 回歸測試策略 7
7.2. 回歸測試基本過程 7
8. 測試結果分析 8
本過程規範軟體測試過程中的各項活動，通過測試活動及早發現軟體系統中的缺陷，並確保缺陷被有效的標識、跟蹤、和修改，保證軟體系統能夠達到要求的質量，符合客戶的要求。
本過程適用於軟體生命週期中的整合測試、系統測試、效能測試活動和缺陷管理活動。
測試組長可以由測試經理或專案經理指定專案組成員其他人員擔任。測試組長負責：
制定測試計畫
參與、跟蹤測試過程
對測試活動和結果進行分析，撰寫測試分析報告
測試人員，由專案組成員擔任，負責：
根據測試計畫編寫測試用例
搭建測試環境，準備測試指令碼
執行測試，記錄測試結果和缺陷
執行回歸測試
測試人員應參加需求評審、設計評審。對《使用者需求說明書》、《系統介面原型》和《軟體設計說明書》等進行閱讀和審查，與需求經理、專案經理溝通，根據系統功能複雜度，系統業務複雜度進行估算有效測試執行時間，為專案總計畫和測試計畫的制定提供參考和依據。
通過對文件分析，分解各功能模組，各功能點，為測試用例設計提供資料依據。
根據測試的種類，測試計畫分為功能測試和效能測試計畫。測試計畫旨在說明各測試階段任務、人員分配、時間安排、測試要點、工作規範等。測試計畫在策略和方法方面說明如何計畫、組織和管理測試專案。
測試計畫包含足夠的資訊使測試人員明白專案需要做什麼是如何運作的。測試計畫不包括測試用例的細節和系統功能的詳細資訊。測試計畫的制定請參閱《測試計畫》模板。
測試計畫應附有測試功能點矩陣、測試效能點矩陣。
測試計畫應在專案組內進行評審。參與測試計畫評審的人員包括：專案經理、測試組長、開發組長、測試組員。
測試用例是為實施測試而向被測試系統提供的輸入資料、操作或各種環境設定以及期望結果的乙個特定的集合。解決要測什麼、怎麼測和如何衡量的問題。
依據使用者需求分析說明書、概要設計文件來設計測試用例，發現需求與設計中的問題後，與需求作者及時溝通確認。
測試用例的設計方法有等價類測試、邊界值分析、基於判定表的測試、基於因果圖的測試、基於狀態圖的測試、基於場景的測試。
在設計測試用例時常用的設計方法有等價類測試、邊界值分析兩種方法。
1、 在設計編寫測試用例時，首先要從測試用例庫中選擇相應功能的測試用例，在原有測試用例的基礎上依據系統需求文件對測試用例的進行修改、更新，評審通過後將使用該測試用例測試被測系統。
2、 在測試專案結束後，統計分析所使用過的測試用例，進行分類放到相應的測試用例庫中。為以後測試用例的設計編寫提供資料基礎。
測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入資料、操作和環境設定等；
測試結果的可判定性：即測試執行結果的正確性是可判定的或可評估的；
測試結果的可再現性：即對同樣的測試用例,系統的執行結果應當是相同的。
根據需求文件提供的內容，和開發部溝通確定測試專案所需的軟硬體環境，完成對測試專案所需軟硬體資源的準備工作，使軟硬體資源得到滿足。
完成對軟硬體資源的配置後，要進行對測試專案的軟硬體環境進行評審，確認對軟硬體資源配置的有效性。
完成對測試專案基本資料的準備操作，包括資料庫連線、使用者資訊、使用者角色許可權、單位組織等資訊和測試相關的測試資料。
為促進測試人員積極主動做好測試執行工作，對測試人員進行測試執行過程進行考核。
以上統計資料由專案經理提供給部門經理。
測試專案的測試週期可分為：單元測試、接收測試、整合測試、系統測試、回歸測試、效能測試等。
軟體專案測試活動的正式啟動，是在確認軟體可測試性後展開的。開發人員需要對產品進行單元測試，單元測試效果通過接收測試驗證。
測試人員依據測試計畫和測試用例進行測試活動。
測試一般分為兩個階段：
1、整合測試、系統測試階段：該階段測試人員每天提交缺陷，並跟蹤缺陷，驗證缺陷，直到提交的缺陷被關閉或被保留。開發人員週期性提交修改過缺陷的新版本，測試人員在新版本上驗證缺陷。
2、回歸測試階段：在整合測試、系統測試階段完成後，產品將進入回歸測試階段。測試人員對修改後的產品進行重新功能驗證，確保修改的正確性，驗證在修改缺陷的同時沒有引入新的問題。
回歸缺陷是指開發人員標示已修改的缺陷，經測試後發現仍未修改正確，或引入其他缺陷，或在前乙個版本中未發現的缺陷，在後乙個版本中出現。
如產品進行效能測試，則需要在效能測試後，進行一輪回歸測試，確保功能的正確性。
專案測試結束時應達到測試質量目標所規定的標準。通過評審後結束該專案測試。
為促進開發人員積極主動做質量工作，對開發人員進行考核。
以上統計資料由測試人員在專案交付後提供給部門經理。
當需求變更，功能變化，測試人員根據變更情況，評估測試變更所需時間，提出變更風險。如變更情況被專案組通過，測試人員將按上述流程進行變更測試。
測試人員將缺陷填寫到管理工具中，選擇指派人為開發組長或相應的開發人員。
開發人員分別對自己收到的缺陷進行評審。評審後如果對提交的缺陷有疑問，可以與提交人協商。對未能達成一致的缺陷由專案經理組織專案組成員評審。評審人員可以是專案組人員。
如果缺陷初次分配的開發人員無法修改該缺陷，初次分配的開發人員可以將缺陷再次分配給其他開發人員。但為避免缺陷被多次分配，專案經理應跟蹤3天以上未修改的缺陷。
開發人員對已確認的缺陷進行修改，填寫修改記錄，修改缺陷狀態為「已修改」或其他狀態。
測試人員對已修改的缺陷進行驗證。如果已修改完成，測試人員將缺陷狀態設定為關閉。如果沒有修改或引起回歸問題，將修改缺陷狀態為「重新開啟」或新增缺陷，由開發工程師繼續修改。
對於有爭議的缺陷進行，將有專案經理最終決定是否修改。如果缺陷是由於技術原因、版本原因不能修改，則保留該缺陷。
測試結果分析是對測試結果的乙個綜合評估，主要描述有測試中各個等級的缺陷數量，缺陷分布情況，缺陷修改情況、回歸測試提交缺陷數量，效能測試指標情況。
測試報告由測試組長編寫並提交給專案經理。測試報告需要經專案組評審通過。
軟體測試過程
引言1963年，在美國發生了這樣一件事 程式設計人員把乙個fortran程式的迴圈語句do 5 i 1，3誤寫為do 5 i 1.3。一點之差導致飛往火星的火箭 造成1000多萬美元的損失。這種情況的發生，迫使人們考慮在軟體投入使用之前必須進行徹底的測試。今天，在軟體比較發達的國家，軟體測試已經成為...
管理體系 測試過程管理
編寫人 提交時間 批准人 批准人意見 批准時間 文件的提交和審批 提交 由管理體系制定的相關人員提交 審批 與管理體系相關文件一同審批確認 執行 由測試專案開發經理在測試過程中根據測試流程組織測試過程的執行。修訂記錄 變化狀態 a 增加，m 修改，d 刪除說明 本文件為管理體系文件 在文件修訂時，請...
網口雷擊測試過程
網口雷擊測試步驟 引數設定 板子後端加上tvs 差模試驗 注 1 rj45介面說明 網口朝向自己左邊為1，最右邊為8,1與2,3與6為百兆和千兆共有。4與5,7與8位千兆獨有。2 快速判斷百兆與千兆網口 百兆網口可以看出有2個tvs，千兆網口可以看出有4個tvs。3 千兆網口既要用網線的百兆線進行雷...