安徽和安科技****
2023年12月
文件修改歷史記錄
目錄一、 目的與適應範圍 4
1.1 目的 4
1.2 適用範圍 4
二、 測試階段的劃分 4
2.1 確定測試需求 4
2.2 測試用例階段 4
2.2.1設計測試用例 4
2.2.2執行測試用例 5
2.3 回歸測試 5
2.4 結束測試 5
2.4.1、結束測試的前提 5
2.4.2、執行結束測試的步驟 5
2.4.3.結束測試的標準 5
2.5 測試總結 5
三、 接收測試 6
3.1 接收測試標準 6
3.1.1 版本完整性 6
3.1.2 安裝 6
3.1.3 冒煙測試 6
3.1.4冒煙測試標準 6
3.1.5 版本說明 6
四、 測試過程中的進度控制與監督 6
4.1 測試進度匯報 6
4.2 測試工程師負責督促開發人員對bug的處理 7
一、 目的與適應範圍
1.1 目的
測試工作的標準化是質量保證中重要且必須的環節，制定本標準的目的在於使測試流程更加標準，測試過程更加規範。
1.2 適用範圍
本標準適用於軟體測試流程的管理和測試的具體操作過程。本標準的使用者涵蓋測試人員和開發人員。
二、 測試階段的劃分
根據開發過程和實際工作需要將測試階段分為確定測試需求、設計測試用例、執行測試用例、提交bug、回歸測試、結束測試、測試總結階段，各階段的主要工作和規範如下：
2.1 確定測試需求
在需求評審結束後，測試人員在任何階段發現的需求問題（有疑問的需求或者不明確的需求）都要記錄下來，提交在mantis中，定時彙總到質控部主管處，由質控主管與專案經理協商，組織召開專案**會，就文件中的需求問題進行確認。
2.2 測試用例階段
2.2.1設計測試用例
設計測試用例需注意：
1、 測試用例要包含所有需求中涉及的功能，以及對需求驗證的部分用例；
2、 為了節省時間，可編寫公共部分的用例，到寫具體模組時可直接呼叫；
3、 測試用例編寫的思路要清晰，相似的測試點放在一起，按照功能由主到次的順序排列；
4、 測試步驟要描述清楚；
5、 預期結果要明確，不要存在模稜兩可的描述，如果不確認的，可在後續工作中進行完善；
6、 對於主要的功能乙個用例寫一條，不要把多條用例合併寫在一起；
7、 測試用例要保持時時更新（用例評審後、需求變更後、有疑問的需求得以確認後，任何時候發現遺漏的用例後）。
2.2.2執行測試用例
1、 嚴格按照測試用例執行測試，執行用例不通過，填寫bug並提交，若通過的測試用例，在用例中標註為通過；
2、 覆蓋的測試用例，及每輪測試的測試結果，在測試反饋單中詳細描述，並將反饋單上傳svn備份；
3、 按照《bug描述規範》描述bug；
4、 按照《bug流程規範》，進行bug管理。
2.3 回歸測試
1、 對於上一輪開發人員修改後的bug執行回歸測試，首先確定bug已全部處理；
2、 修改對應的bug狀態；
3、 重新執行上一輪未通過的用例，若時間允許，重新執行所有的用例；
4、 填寫反饋單，記錄本輪測試結果。
2.4 結束測試
2.4.1、結束測試的前提
系統中只有關閉、反饋、延遲下版本三個狀態的bug，不再有新bug產生；
2.4.2、執行結束測試的步驟
1、 首先回歸所有關閉狀態的bug，對於重新出現的bug，重新開啟；
2、 ghost成純淨的系統環境；
3、 重新執行所有的測試用例。
2.4.3.結束測試的標準
1、 所有反饋和延遲下版本狀態的bug均已經過專案經理、研發主管、質控主管確認；
2、 隨著測試的程序，bug發現的機率相應減少，無新bug產生，所有確認需要修改的bug均已修改。
2.5 測試總結
1、 彙總專案的所有需求不符合方面的bug到質控部主管處，分析原因，按照專案進行總結，作為下次專案的參考；
2、 彙總所有用例評審後新新增的用例和測試過程中修改的用例到質控主管處，分析遺漏的測試用例原因，避免下次遺漏；
3、 測試工程師總結測試中的不足和取得的經驗、教訓。
2.6 測試流程規範
1、 根據「接收準則」接收符合要求的系統版本；
2、 每一輪提交的測試版本，均需在純淨系統環境下（資料庫中只有初始資料），進行測試；
3、 每一輪測試，在回歸上一版本的bug後，需覆蓋遍歷所有測試用例，並標註測試結果，在反饋單中描述測試結果，並附電子版測試用例結果一併提交給質控主管；
4、 系統主測人員將每輪測試的結果反饋單上傳至svn進行備份；
5、 根據測試結束標準，結束測試；
6、 測試環境搭建規範：服務端與資料庫分開搭建；系統交付使用者使用前，模擬實際情況，搭建**環境，進行功能測試。
三、 接收測試
開發人員提交測試版本後，由相關測試人員根據接收標準，驗證該版本是否符合接收測試標準，通過的進行系統測試，不通過返回開發人員。
3.1 接收測試標準
3.1.1 版本完整性
1、 程式版本完整性：某一功能或需求任務全部開發完成，不要存在開發還需要自檢的時候就提交測試；
2、 程式功能完成：軟體需求分析說明書中定義的所有功能已全部實現。
3.1.2 安裝
軟體可以正常發布，能夠正常訪問，安裝解除安裝無bug。安裝、解除安裝測試需在純淨的系統環境下進行。
3.1.3 冒煙測試
1、 對於提交的測試版本，要確認軟體基本功能正常，可以進行後續的正式測試工作，可以正確安裝/解除安裝，主要功能已經實現，不存在嚴重宕機或資料嚴重丟失等bug；
2、 對於上一輪測試，只允許存在已確認、已解決、反饋狀態的bug；
3、 冒煙測試不通過，則不接受測試。
3.1.4冒煙測試標準
1、 確保所有的正常業務流程沒有問題，否則視為冒煙測試不通過；
2、 確保所有的主要功能正常，否則視為冒煙測試不通過。
3.1.5 版本說明
1、 提交測試時，開發人員必須向測試人員提交版本的完整說明（程式包含的所有功能）與本次修改說明（包括修改的內容以及修改了哪些bug，或還存在哪些bug因何原因未做修改等）；
2、 程式修改的範圍以及影響範圍；
3、 程式修改、新增、刪除的配置項，及其說明。
四、 測試過程中的進度控制與監督
4.1 測試進度匯報
測試期間，測試工程師每天下班前匯報當天的專案測試情況，告知測試進度與狀態，尤其是測試後期，要加強測試進度的匯報工作。
4.2 測試工程師負責督促開發人員對bug的處理
1、 每輪回歸測試前，檢查本專案的bug狀態，確認開發人員是否對已發現的bug進行處理；
2、 專案結束時，檢查本專案的bug狀態，只允許存在：已關閉、反饋、延遲下版本的bug；
3、 對於改動比較大的bug，監督開發人員填寫備註（說明改動的部分和影響到的模組）。
測試工作規範
版本記錄 目錄目錄.1 1.編寫目的.2 2.測試團隊構成.2 2.1職責.2 2.2角色劃分.2 3.1計畫與設計階段.2 3.1.1成立測試團隊.2 3.1.3召開測試啟動會議.3 3.1.4編寫測試計畫文件.3 3.1.5設計測試用例.4 3.2實施測試階段.4 3.2.1實施測試用例.43....
測試工作規範
v1.0 修改歷史 更改請求號 為文件正式發布後需要變更時的編號，編號方法待定，見配置管理kpa相關文件。正式批准 本文件是測試團隊的日常工作規範，主要側重測試工作流程的控制，明確軟體工程的各階段測試團隊應完成的工作。測試技術和策略等問題不在本文件描述範圍內。測試是軟體開發過程中的重要組成部分，肩負...
測試工作規範
1編寫目的 本文件是測試團隊的日常工作規範，主要側重測試工作流程的控制，明確軟體工程的各階段測試團隊應完成的工作。2測試職責 測試是軟體開發過程中的重要組成部分，肩負著如下責任 在專案的前景 需求文件確立基線前對文件進行測試，從使用者體驗和測試的角度提出自己的看法。編寫合理的測試計畫，並與專案整體計...