軟件項目的測試流程大只包含的幾個階段：立項、需求評審、用例評審、測試執行、測試報告文檔。
立項后測試需要拿到的文檔
1、需求說明書
2、原型圖（及UI圖）
3、接口文檔
4、數據庫字典（表的數量、緩存機制）
需求評審
參加人員：開發、測試及需求人員，由需求人員主持講解。
為了會議的有效舉行，軟件測試及開發人員需要在會議開始之前熟悉需求文檔及原型，將有疑問 的點標注出來在會議中一一確認，對不明確的點要督促開發及需求一並關注，對不能立馬得到肯定回復的點記錄在一起，會議結束后，郵件整理好發出給各位參與的人員。
在項目可控的進度中，需求評審時必要的環節。當然，有些比較小的項目會忽略此階段，個人認為這是非常有必要的環節，這不但減少了后期開發、測試、需求人員的意見分歧，保證項目的進度的必要手段。
用例編寫（同時根據開發計划編寫測試計划）
用例功能類型
所在就職部門將用例分成7類：
1、主流程：該模塊實現的主要功能流程。
2、備選流：不一定完成執行一個功能，而是終止了流程。
3、異常流：由於某些異常原因，使流程的功能無法實現。
4、業務規則：必填項，強制的要求。
5、正常類：返回功能、必填項輸入范圍、頁面按鈕的切換等。
6、異常類：網絡異常、返回異常等。
7、界面檢查：針對每個頁面的樣式及內容檢查。
注：幾個大類中主流程、正常類、異常類、和界面檢查四個大類使用的比較多，一個項目不需要涵蓋所有的用例類別，只需要根據所在項目的實際情況來進行測試用例的分類即可。
編寫用例可在TestLink及excel上進行，一般會在TestLink上進行，小項目會比較習慣用excel進行，excel記錄測試用例的字段有：
用例編號、功能模塊、功能類型、用例等級、用例描述、前置條件、數據、測試步驟、預期結果、客戶端、執行結果、備注、設計人、執行人等
用例編寫注意點：
1、盡可能結合用例設計方法設計測試用例
2、不要只根據需求文檔明確標出的需求編寫用例，還需要多考慮一些衍生的場景；
3、用例編寫前，先畫出整個功能的煎葯流程圖；
4、用例描述簡潔且帶有結果，不要重復贅述；
5、用例步驟和預期結果要一致，且一個步驟對應一個預期結果。
測試用例的編寫方法
1、等價類划分
2、邊界值分析法
3、錯誤推斷法
4、因果分析法
5、場景法
用例評審
參與人員：開發、測試、需求人員、項目經理，由測試人員主導。
此環節在開發完成功能之前進行，根據評審時提的點進行用例完善，完善后郵件發給參與人員。
在項目組中，bug管理工具更多情況下測試比開發會更了解需求，專業決定我們對需求的理解是肯定更接近客戶的，我們的對需求理解后的輸出產物是測試用例，某種意義上講用例是對需求細化的一種。 而開發對需求理解會更偏向於功能實現，產物就是程序。所以開發、測試經常會存在需求理解不一致的情況，開發也不會那么細致的去理解需求，這點相信所有的項目經理和需求分析都是有共鳴的：
我們做測試用例評審的作用有但不局限於以下3點：
1、統一開發、測試、需求三方對需求的理解
2、幫組開發更細致的去理解需求、同時養成看需求的習慣
3、需求分析人員在一定程度上對需求的理解也是有盲點的，通過評審可以挖出這些盲點（需求評審的作用也是一樣）
4、測試人員的能力和經驗不一樣，所有用例也會有差異性，通過評審可以指出我們遺漏的場景，從而能更好的保障咱們的項目質量
5、在用例評審時，很多交互設計上的問題，前后台交互的問題等都會暴露
6、如果測試用例在開發完成前進行評審，很多時候開發人員即使不去看需求說明書，只要他認真的參加了用例評審會，基本上也不會出現遺漏需求，需求實現偏差太大的情況了.因為你要去每個開發人員那么仔細的去看需求，短時間內是不太可能的。用例評審是這個過渡期的橋梁。
一般可根據計划時間完成用例編寫，中間會預留1天給他們看需求。在評審每一個模塊的用例之前，會明確點名這幾個人要注意，在評審的過程中，問開發一些問題,不是只單純的講用例,他們可以不看需求，但是我會提問一下,們要同時提升開發人員的參與感。
測試執行
showcase測試：
測試到開發的電腦上進行，主要執行一下關鍵測試用例、流程用例，由開發操作，測試人員一起查看。showcase不通過，則打回，郵件發出。
冒煙測試：
showcase測試通過后，提交到測試，由測試人員開始大量跑關鍵測試用例。若針對某個模塊跑用例時，出現較多問題，則也可重新打回給開發。