一、明確測試任務：
1.確定項目的研發周期、項目進度、版本發布時間以便於制定測試計划。
2.查找已有的需求說明，功能設計等文檔進行需求分析便於了解自己的工作內容和熟悉項目。
3.與測試負責人、或項目負責人明確工作對接。（提bug是按照已有規則還是自由發揮，具體問題提交給指定人還是統一分發，有沒有工作會議等）
二、明確分析測試范圍：
1.了解測試對象都有哪些（包括需要測試哪些平台、哪些文件（演示腳本）、各類手冊（安裝手冊、使用手冊））
2.了解版本迭代中測試功能有哪些（第三方功能需求測試嗎？只包含當前版本提測功能？測試類型有哪些？）
三、制定測試計划、策略、方案：
測試計划：
測試計划制定包括：測試進度、時間安排、測試任務分配、測試任務的責任人、測試任務風險、文檔的存放、工具的使用、測試中的資源獲取、測試階段。
測試策略：
⑴測試的優先級：高需求、新功能、舊功能改動、使用率高的功能、危險性大的功能
⑵測試標准：
准出/准入標准：
准入： 1.開發人員完成自測
2.需求功能基本實現，沒有需求需要開發提供范圍
3.提測演示通過基本冒煙測試
4.開發人員提交測試申請和相應的文檔
准出：1.滿足客戶需求
2.用例通過評審並完成執行
3.測試覆蓋率達到要求
4.所有bug已經記錄在bug管理系統
5.一、二級bug修復率100%
6.三、四級bug修復率達到95%
7.遺留問題都有解決方案
8.測試 滿足要求
9.完成測試總結報告
通過/失敗標准：
通過/失敗：1.系統測試執行對需求達到100%
2.高級、中級用例100%執行，低級95% 3.缺陷修復率達到99%，無致命和嚴重bug
掛起/恢復標准：
掛起/恢復：1.測試過程發現致命bug導致用例50%無法進行，堵塞問題修復后恢復測試
2.高優先級用例未執行100%,待回歸測試通過后繼續
3.版本不停變更和需求不停變動，待開發自測后恢復
4.外部 因素導致測試無法進行，通過項目經理確認后恢復
⑶預估工作量：設計用例時間，執行用例時間，bug回歸時間，測試文檔交付時間
⑷風險評估：軟硬件環境未到位、用例沒有完成、需求或界面變更、開發未完成研發
測試方案：
功能、性能、界面、數據庫、安全、兼容測試的實施階段
四、編寫測試用例和執行：
1.通過測試用例設計方法進行用例編寫：
等價類划分法：划分有效等價類和無效等價類。有效指對系統的輸入是合理的，檢驗系統實現需求規定的功能；無效指不符合需求的數據輸入是否有異常。 例如：手機號 有效：11個整數 無效：輸入字母、漢字、特殊符號
邊界值分析法：輸入或輸入的邊界值進行測試 例如：上傳10個文件 取點：0、1、5、10、11個文件上傳
錯誤推測法：根據系統實際情況，結合實際情況進行推斷。 例如：日期開始時間大於結束時間；為空、為0的判斷
判定表法：通過輸入輸出的組合方式進行分析 例如：重要類型1 2 3 4 次要類型A B C D 兩兩組合輸出不同的結果
正交實驗法：測試多因素、多水平的一種情況，通過少數代替全面，選擇具有代表性的數據，多用於在查詢。 例如：1班和2班男女生成績及格或不及格
| 序號 | 性別 | 班級 | 成績 |
| 1 | 女 | 1 | 合格 |
| 2 | 女 | 1 | 不合格 |
| 3 | 女 | 2 | 合格 |
| 4 | 女 | 2 | 不合格 |
| 5 | 男 | 1 | 合格 |
| 6 | 男 | 1 | 不合格 |
| 7 | 男 | 2 | 合格 |
| 8 | 男 | 2 | 不合格 |
五、工作內容評審：
1.測試用例評審
2.需求評審
3.提測演示
4.產品驗證
六、記錄bug進行跟蹤管理回歸驗證
七、測試完成后文檔的輸出、歸檔
八、測試完成工作內容討論和總結
主要討論本版本在進行測試時遇到的問題，與研發、產品的建議，和自己本次測試總結及技術分享。