一、 軟件的開發階段划分
1、 需求分析階段
由需求分析師完成
產出物：《需求文檔》
2、 設計階段
1） 概要設計
產出物：《概要說明書》
2） 詳細設計
產出物：《詳細說明書》
一般是由系統架構師（分析師）完成
3、 編碼階段
程序員
注：一般公司只有產品文檔和原型，，所以如果你的公司這些文檔都有，那么請珍惜吧。。。。
常見面試題：哪個階段bug最多？哪個階段bug最小？
需求分析階段引入的bug最多，其次是設計階段，在編碼階段引入的bug的最少。
所以：
1）測試不能只測程序，文檔也要測。
2）測試工作應該從開發開始就介入，並且應該貫穿整個開發周期始終。
注：身在小公司的我，不得不告訴你們，文檔不需要測，一般是不需要編寫測試用例的（測試我負責），但是我們得要求自己編寫用例，因為這家公司只是我們測試路上的路人甲，並不是我們的重點。測試時間短暫，感覺領導不太重視，測試可能沒有測完，領導就喊着要上線。我希望從我手上流出去的產品不說完美，但是盡量沒有那么多bug，總感覺有那么點憂桑。
二、軟件測試的階段划分
1、單元測試
1）單元測試是最小的測試單位，一般就是一個功能模塊，一個方法（函數），一個類等
2）單元測試依據的是《詳細設計文檔》 （單元測試是根據詳細設計文檔寫功能）
3）單元測試以白盒測試為主，可能輔助以黑盒測試
4）單元測試可能要求測試人員編寫驅動模塊和樁模塊
A）驅動模塊：模擬被測模塊的上一級模塊（調用被測模塊的那個模塊）
B）樁模塊：模擬被測模塊的下一級模塊 （被被測模塊調用的那個模塊）
總結：驅動模塊à被測模塊à樁模塊
5）在實際工作中，單元測試往往由程序員完成--（節約成本，但是不嚴格）
2、集成測試
1）集成測試也叫組裝測試，在單元測試的基礎上把軟件的功能模塊逐步合並在一起進行的過程
2）功能合並的過程一般是逐步完成的，會形成很多的臨時的版本
3）集成測試依據的是《概要設計文檔》
4）集成測試階段以黑盒測試為主，核心模塊適當采用白盒測試。
名詞解釋：冒煙測試（版本驗證測試）使用較少的人（1-3人，經驗豐富）、較少的時間（0.5-2天），對軟件的核心功能進行測試，如果軟件核心功能沒問題，就讓全組投入全面測試，如果問題較多，，版本不穩定，就打回開發組。
5）集成測試中，拿到新的內部版本，基本工作思路：
l 首先要進行冒煙測試（有可能省略），驗證該版本是否可以接受
l 返測 ：對之前的bug，在本版本中解決的，檢查是否通過。
l 回歸測試 ：對上一版本中的所有功能再測試一遍----驗證修改的代碼或新加了功能，以前的功能是否依然正常。
l 對該版本新組裝的功能進行測試 ---- 但如果有些版本只是用於修復以前的bug，也有可能沒有新功能。
3、系統測試
1）整個功能全部組裝完成后，對模擬集成了硬件、軟件的完整系統進行的測試。
2）系統測試的重點在於
A）整個系統在模擬真實環境下是否可以正確運行
B）系統與硬件、軟件的兼容性問題
3）系統測試的依據是《需求文檔》
4）系統測試全部為黑盒測試
5）在系統測試之前，一般會安排“確認測試”，主要確認：
A、確認該系統是否進入全面的系統測試階段（可以理解為一次大的冒煙測試）
B、確認相關文檔是否准備齊全（尤其是給用戶的文檔，參與認證的文檔）
說明：確認測試一般時間相對較短，參與的人員較少。所以不把其與單元測試、集成測試、系統測試所並列
4、 用戶驗收階段 --- 驗收測試
UAT（User acceptance Testing）用戶接受度測試
1） 用戶參與的一個檢查過程
2） 可以分為兩個小階段：
A）Alpha測試 ：在開發環境中，由最終用戶對軟件進行檢查，一般經常由軟件公司代用戶完成。
B）Beta測試 ：在用戶的實際環境中，由最終用戶對軟件進行檢查
對於公共類軟件（操作系統，游戲，輸入法），一般把軟件免費發放給最終用戶，通過用戶使用收集bug ---- 公測版本
三、軟件測試的模型
1、軟件測試模型表達的是測試階段和開發階段的對應關系。
2、兩個常見模型
1）V模型（重點）
A、會畫
B、優缺點
優點：
（1）開發和測試階段划分明確，對應關系明確
（2）測試階段既包含單元測試（代碼、專業級）又包含驗收測試（用戶級）
缺點：沒有體現需求、設計階段的文檔測試工作，容易造成誤解，以為測試工作只是開發完成后的收尾工作
2）W模型（了解）
A、可以理解為雙V模型，第一個V是開發活動，第二個V是測試活動
B、比V 模型更加強調了文檔測試階段的重要，體現了測試對象不僅是程序需求和設計同樣需要測試。測試與開發是同步進行的
C、W模型更符合盡早測試和不斷測試的原則
四、軟件測試的分類
1、按測試技術划分
1）黑盒測試 ：（功能測試的基本特征）又叫功能測試、數據驅動測試，是不考慮程序內部結構，只需考慮輸入和輸出情況下進行的功能測試
2）白盒測試 ：又稱為結構測試，基於程序的測試。只考慮程序內部結構，而不去考慮程序功能的測試
3）灰盒測試 ：結合黑盒和白盒測試的要素，對軟件進行測試，一般先做黑盒測試，當發現有bug，對bug進行定位，對有可能有問題的代碼再進行白盒測試的過程（在集成測試中經常使用）
補充說明：
1）測試階段中黑盒測試為主
2）白盒測試測試常常對風險較大，難度較大的模塊進行測試
3）白盒測試要求測試人員懂得代碼，效率較低，時間成本高
4）白盒測試也需要編寫測試用例
2、按是否需要運行代碼划分：
1）靜態測試 ：不需要運行程序
2）動態測試 ：需要運行程序才能進行的測試
黑盒（功能）測試一般都是動態測試
白盒測試即有可能是動態的，也有可能是靜態的
3） 靜態測試包括：
A、 界面測試 ：主要測實際界面與需求要求是否符合
B、 文檔測試 ：主要測試文檔和說明是否真正符合
C、 代碼測試 ：主要測試代碼是否符合相應的標准和規范
常見問題：靜態的代碼測試和白盒測試的區別：
（1） 白盒測試主要關注代碼的邏輯功能實現，測試者必須要懂代碼，要求寫測試用例
（2） 靜態代碼測試主要關注代碼的規范性、標准性，測試人員不需要懂代碼，不需要寫測試用例，只需參考代碼審查單檢查即可
3、按軟件的特性分類
1）功能測試 ：
(1) 任何軟件都必須要做功能測試
(2) 軟件要先做功能測試，保證其功能正確。
分布式軟件需要在功能正確的前提下，在考慮性能
(3) 功能測試分為：手工功能測試和功能自動化測試(需要借助於工具完成)
2）性能測試 ：
（1）分布式（c/s，b/s）需要做性能測試
（2）性能測試只有自動化（要借助工具完成）
4、其它（常見的名詞術語）
1）返 測 ：在新版本中對程序員修改的bug進行測試，驗證bug是否被修改
2）回歸測試 ：對上個版本中的所有功能重新測試一遍，檢驗新版本中原有的功能是否依然正確，回歸測試存在大量的重復性工作，所以企業會使用自動化工具實現
3）隨機測試（猴子測試）：在測試用例執行完成之后，對軟件進行隨意的測試的過程【只是時間充足時，對正常測試用例之外的補充測試】
4）兼容測試 ：指對被測軟件與硬件、軟件之間的兼容性的測試，
兼容性測試可以分為三大類：
（1）硬件兼容
A、與整機兼容
B、與外設兼容
（2）軟件兼容
A、操作系統
B、應用軟件之間的兼容：殺毒軟件，工具類軟件
C、不同瀏覽器的兼容
D、數據庫的兼容
（3）數據兼容
不同版本間的數據兼容
5）測試流程（步驟）
（1）需求 ：閱讀需求，理解需求
（2）測試計划 ：測試經理對整個項目做一個宏觀的計划
（3）設計測試用例
（4）執行測試
（5）記錄測試執行結果，並填寫《缺陷報告》，記錄缺陷
（6）跟蹤管理缺陷
（7）測試總結報告或測試評估報告