一、需求調研
1. 委托方提供資料
A. 填寫測試委托申請表
B. 操作手冊
C. 開發需求規格說明書
D. 開發合同及招标檔案等
2. 雙方技術溝通确定測試具體内容，如功能性測試、性能效率測試、資訊安全性測試、相容性測試、可靠性測試等。
3. 我方給出測試方案及報價，達成合作意向
二、合同簽訂
我方根據确定的測試内容配置設定項目編号拟定測試協定，雙方無異議後簽訂合同。
三、測試過程安排
1. 測試人員安排
測試人員我方根據測試工作量進行調整，測試開始前委托方須部署測試環境，準備測試會用到的軟硬體資源，包括不限于測試軟體、測試資料、配合測試的人員等。
測試人員安排
2. 測試活動安排
測試活動安排
3. 測試環境
測試環境
4. 測試政策
測試政策
4.1測試用例設計方法
4.1.1功能性
功能測試用例主要采用等價類劃分法、錯誤推測法、邊值分析法與因果圖法進行設計：
Ø 等價類劃分法的原則：
對業務流程進行等價類劃分，測試用例應是業務主流程和流程主分支的最小集，所有的判别分支都能被覆寫，在流程覆寫的同時，完成等價功能的測試。
Ø 邊值分析法的原則：
針對功能說明中的輸入輸出域，進行邊界值和極限值的設計和測試。
Ø 錯誤推測法的原則：
采用逆向思維方式，結合以往測試經驗和直覺設計軟體在功能和流程上可能存在的 各種錯誤，進行容錯性測試。
Ø 因果圖法的原則：
因果分析圖是以結果作為特性，以原因作為因素，完成測試的方法。
4.1.2性能效率
性能效率測試主要分為價基準測試、負載測試、壓力測試、配對測試、并發測試和可靠性測試。
Ø 基準測試：
基準測試是基于一定規模的資料量上進行單業務或按實際使用者操作同比例組合業務的測試，目的在于量化響應時間、吞吐率的名額，便于後續比對。
Ø 負載測試：
通過在被測系統上不斷增加壓力，直到性能名額，例如“響應時間”超過預定名額或者某種資源使用已經達到飽和狀态。
Ø 壓力測試：
測試系統在一定飽和狀态下，例如CPU、記憶體等在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。
Ø 配對測試：
通過對被測系統的軟/硬體環境的調整，了解各種不同環境對系統性能影響的程度，進而找到系統各項資源的最優配置設定原則。
Ø 并發測試：
通過模拟使用者的并發通路，測試多使用者并發通路同一個應用、同一個子產品或者資料記錄時是否存在死鎖或者其他性能問題。
Ø 可靠性測試：
通過給系統加載一定的業務壓力（例如資源在70%~90%的使用率）的情況下，讓應用持續運作一段時間，測試系統在這種條件下是否能穩定運作。
本次性能測試主要采用并發測試和負載測試，模拟使用者執行業務操作，使用者執行登入，依次通路黨模組化塊首頁，通路綜治子產品并查詢一條資料，通路網格首頁并新增一條資料。
5 品質保證
由品質監督員進行監督記錄，若項目負責人為該品質監督員，由品質負責人進行複核，由技術負責人審批。（至少保證每周一次對正在執行的項目進行跟蹤）
來源;公衆号“軟體測評閑聊站”
來源：“軟體測評閑聊站”
6. 溝通保證
為了保障測試過程順利進行，測試方、委托方和開發方等均應保持溝通的暢通，以便快速定位和解決問題。溝通手段包括但不限于以下：
Ø 會議溝通：在整個測試活動中，應當召開首次會議和末次會議；
Ø 現場交流：主要是測試人員和軟體開發人員現場溝通交流；
Ø 電話溝通：較快捷的描述問題和原因；
Ø 聊天工具：可通過截圖、傳輸方式，形象的描述問題和原因；
Ø 其他。
7. 測試風險分析
軟體測評閑聊站
四、測試輸出
a) 測試方案
b) 測試大綱
c) 測試說明
d) 測試記錄
e) 測試報告
f) 其他（測試截圖、腳本等）