01 第一步：需求分析
1.1 需求分析說明
- 在軟件項目的開發過程中，軟件需求規格說明書的編寫是必不可少的
- 他能夠使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解，這是整個項目開發工作的基礎
- 提取測試點是通過對需求的細化和分解，形成可測試的內容
- 測試內容應全部覆蓋系統的業務流程，以及功能和非功能方面的需求
- 非功能的需求，包括：用戶體驗，性能等其他需求
1.2 業務流程圖
1.3 注冊功能
1.4 需求如下
1.5 需求分析的結果
02.第二步：需求評審
1、需求評審會議：
- 在需求分析之后，會進行一個需求評審的會議
- 整個項目的成員會聚集再一起討論一下各自對需求的理解
- 看看需求的理解是否出現不一致的地方，是否出現可遺漏的地方
2、評審的內容：
1、完整性審查
- 應保證測試需求能充分覆蓋軟件需求的各種特征
- 重點關注功能要求、數據定義、接口定義、系統約束等方面
- 同時還已應關注是否覆蓋開發人員遺漏的、系統隱含的需求
2、准確性審查
- 應保證所描述的內容能夠得到相關各方的一致理解
- 各項測試需求之間沒有矛盾和沖突，各項測試需求在詳盡程度上保持一致
- 每一項測試需求都可以作為測試用例設計和依據
03 第三步:測試計划
3.1 測試計划介紹
1、在評審完成之后，會完成一個測試計划的編寫，安排一下測試的進度與內容。
2、為什么要編寫測試計划？
- 軟件測試是有計划、組織和有系統的軟件質量保證活動，而不是隨意地、松散地、雜亂地實施過程
- 為了規范軟件測試內容、方法和過程，在對軟件進行測試之前，必須創建測試計划
3、什么時間開始編寫測試計划
- 需求分析后編寫測試計划，在整個測試工作過程中，不斷修改
4、由誰來編寫測試計划？
- 具有豐富經驗的項目測試負責人
5、測試計划的內容
- 測試項目的背景、測試范圍和測試策略、測試環境、測試開始和結束
- 進度安排，測試組織，以及與測試有關的風險等方面的內容
6、測試項目的背景
- 對測試對象及其目標進行簡要說明，包含的信息有
- 主要的功能和性能，測試對象的架構和項目的作用
- 通常，項目的背景可以從需求文檔中獲取
7、測試范圍
- 簡單的列出本次測試的主要模塊
8、測試方法/策略
- 功能測試
- 界面測試（UI測試）
- 安全測試
- 安裝測試
- 兼容性測試
- 負載測試
- 壓力測試
3.2 測試環境
1、從軟件的編寫、測試道用戶實際使用，存在者：開發環境、測試環境和生產環境
- 開發環境：開發環境是程序員們專門用於開發的服務器，配置可以比較隨意，為了開發調試方面，一般打開全部錯誤報告
- 測試環境：一般是克隆一份生產環境的配置，一個程序在測試環境工作不正常，那么肯定不能把它發布到生產機上
- 生產環境：是指正式提供對外服務的，一般會關掉錯誤報告，打開錯誤日志
2、環境：指的是被測試軟件所運行的軟件環境和硬件環境
3、測試環境
- 測試環境是測試人員為進行軟件測試而搭建的環境，根據不同的測試階段
- 測試環境可以分為冒煙測試環境，SIT測試環境，UAT測試環境等；
- 根據不同的測試類型，測試環境可以分為功能測試環境，自動化測試環境，性能測試環境
04：第四部測試用例
05 第五步：測試執行
根據已有的測試用例，按照步驟一步一步的執行，查看預期結果與實際結果是否一致。
5.1 測試執行過程中注意事項
1、搭建測試環境事項
- 測試用例執行過程前，成功搭建測試環境是第一步。
- 一般來說，軟件產品提交測試后，開發人員應該提交一份被測試軟件產品的詳細安裝指導書
- 如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候
- 測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方式記錄下來
- 避免同樣的問題再次請教開發人員，這樣會導致開發人員的反感，也降低了開發人員對測試人員的認可程度。
2、測試環境怎樣搭建的？
- 搭建環境前，開發都會給帶我們一份系統發布手冊，我們會根據這個手冊來搭建
- 比如，我這個xx系統，是搭建在Unix系統下的，web服務器用的是Tomcat8,MYSQL版本5.7，程序是JAVA編寫的
- 首先我們向開發拿到編譯好的安裝包，然后用xshell遠程連接上Unix系統，把tomcat服務器停掉
- 把程序包放到webapps目錄下，然后再啟動tomcat服務器就可以。
5.2 偶然性問題的處理
- 在測試執行過程中，一旦系統出現異常信息，我們第一時間要做的是截圖，保存證據；
- 確定是偶然性的bug之后，收集相關的日志，連同截圖一並提交過單位開發
- 如果缺陷在當前版本無法復現，且缺陷的影響程度比較低，我們會跟蹤三個版本，如果后三個版本都無法復現，就可以關閉該缺陷；
- 如果很嚴重的Bug,除了要及時反饋給上級之外，最后還要寫到測試報考中，說明出現了什么現象，但無法再現！
- 詳細記錄預期與實際的不一致，如果不一致，要從多個角度多測試幾次，盡量詳細的定位軟件出錯的位置和原因，並測試出因為這個錯誤會不會導致更嚴重的錯誤出現，最后把詳細的輸入和實際的輸入，以及對問題的描述寫到測試報告中。因為在一個項目組中，項目的開發時間是有效的，如果我們測試時能把問題描述詳細一些，那么開發人員就會很容易的重修這個問題，也就能更快的解決問題，節省項目時間。
- 提交缺陷時與開發的關系處理
- 堅持原則
- 對事不對人，拿證據說話
- 尊重對方的勞動成果，平時和開發人員打好關系，不要把關系搞僵。
06 缺陷的定義（bug）
07 測試報告主要內容