制定測試計畫->測試設計->測試開發->測試執行->評估測試
軟體測試階段：
測試階段：編碼後或者編碼前
測試物件：模組（軟體測試的最小單位）
測試人員：白盒測試工程師或開發人員
測試依據：**和注釋+詳細文件
測試方法：白盒測試
測試內容：模組介面測試、區域性資料測試、路徑測試、錯誤處理測試、邊界測試
補充說明：
（1）學習測試依據時，我們可以對比軟體測試的「v」模型結合記憶
（2）白盒測試不是單元測試，單元測試是白盒測試
（3）測試驅動開發：測試人員先編寫測試用例，開發人員根據測試用例寫程式
測試階段：一般是單元測試之後
測試物件：模組間的介面
測試人員：白盒測試工程師或開發工程師
測試依據：單元測試的文件+概要設計文件
測試方法：黑盒測試與白盒測試（灰盒測試）
測試內容：模組之間資料傳輸、模組之間功能衝突、模組組裝功能的正確性、全域性資料結構、單模組缺陷對系統的影響
測試階段：整合測試階段之後
測試物件：整個系統（軟體、硬體）
測試人員：黑盒測試工程師
測試依據：需求規格說明文件
測試方法：黑盒測試
測試內容：功能、介面、可靠性、易用性、效能、相容性、安全性等
補充說明：先冒煙、再系統、後回歸。
（1）回歸測試（regression testing）：指修改了舊的**之後，重新進行測試以確認修改沒有引入新的錯誤或導致其他**產生錯誤。（自動回歸測試將大幅度降低系統測試、維護公升級等階段的成本）。
在整個軟體測試過程中占有很大的工作比重，軟體開發的各個階段都會進行多次回歸測試。隨著系統的龐大，回歸測試的成本越來越大，通過正確的回歸測試策略來改進回歸測試的效率和有效性是很有意義的。
（2）冒煙測試（smoke testing）：該術語來自硬體，指對乙個硬體或一組硬體進行更改或修復後，直接給裝置加電。如果沒有冒煙，則該元件就通過了測試，也可以理解為該種測試耗時短，僅用一袋煙的功夫就足夠了。
冒煙測試的物件是每乙個新編譯的需要正式測試的軟體版本，目的是確認軟體基本功能正常，可以進行後續正式的測試工作。
冒煙測試的執行者是版本編譯人。
冒煙測試一般在開發人員開發完畢後送給測試人員來進行測試時，測試人員會先進行冒煙測試，保證基本功能正常，不阻礙後續測試。
測試階段：系統測試通過後
測試物件：整個系統（包括軟硬體）
測試人員：主要是終端使用者或者需求方
測試依據：使用者需求、驗收標準
測試方法：黑盒測試
測試內容：同系統測試（功能、各類文件文件等）
例子：針對買回來的新手機以及它的美顏功能來進行測試。
（1）我們只針對美顏功能的**進行測試，就是單元測試。
（2）檢測手機通訊錄是否可以增添、刪除、更改手機號碼，打**時需要手動的輸入**，也可以在手機中查詢，這就是整合測試。
（4）當修好新買回來的手機的美顏功能以後，使用者除了會檢視美顏功能是否完好，還會檢視其他功能是否也完好，這個叫回歸測試。
（5）對於新買回來的手機，我們做的第一件事是將常用的手機功能試一遍，第二件事情就是講所有功能都試一遍，這個叫冒煙測試。
（6）對於新買回來的手機，一般都有7天包退，30天包換，我們一般都是在7天內把手機的所有功能都試一遍，這叫驗收測試。
軟體測試分類：
黑盒測試方法：
1.等價類劃分：把程式輸入域分成若干部分，從每部分取少數具代表性資料作為測試用例。
2.邊界值分析法: 是對輸入或輸出的邊界值作為測試用例
3.錯誤推測法：基於經驗/直覺推測程式中所有可能存在的錯誤，有針對性地設計測試用例。
4.因果圖/判定表：利用**分析輸入輸出的各種組合關係，寫出判定表，設計相應的測試用例
5.正交試驗設計：從大量的實驗資料中挑選適量的、有代表性的點來設計測試用例
6.隨機數法
白盒測試的測試方法有（按照強度由低到高）：
（1）語句覆蓋：設計若干測試用例，執行被測程式，使得每一可執行語句至少執行一次。
（2）判定覆蓋：使設計的測試用例保證程式中每個判斷的每個取值分支至少經歷一次。
（3）條件覆蓋：選足夠測試用例，使判定中每個條件的所有可能結果至少出現一次，未必覆蓋全部分支
（4）判定條件覆蓋：條件覆蓋基礎上，要求各個判斷的所有可能的條件取值組合至少執行一次。
（5）條件組合覆蓋：選足夠測試用例，使所有判定中各條件判斷結果的所有組合至少出現一次
（6）路徑覆蓋：是每條可能執行到的路徑至少執行一次。
補充：1.語句覆蓋在所有的測試方法中是一種最弱的覆蓋。
2.滿足判定/條件覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋和語句覆蓋
3.路徑覆蓋也是一種比較強的覆蓋，但未必考慮判定條件結果的組合，並不能代替條件覆蓋和條件組合覆蓋。
一、測試顯示軟體存在缺陷（testing shows presence of defects）
測試只能證明軟體中存在缺陷，但並不能證明軟體中不存在缺陷。軟體測試是為了降低存在缺陷的可能性，即便是沒有找到缺陷，也不能證明軟體是完美的。
二、窮盡測試是不可能的（exhaustive testing is impossible）
現在軟體的規模越來越大，複雜度越來越高，想做到完全性的測試是不可能的。在測試階段，測試人員可以根據風險和優先順序來進行集中和高強度的測試，從而保證軟體的質量。
三、測試盡早介入（testing early）
為什麼測試要盡早介入呢，簡單的說就是保證軟體質量，降低風險和成本。測試人員一般在需求階段就開始介入，使缺陷在需求或設計階段就被發現，缺陷發現越早，修復的成本就越小。
四、缺陷集群性，2/8原則（defect clustering）
缺陷集群性表明小部分模組包含大部分的缺陷。軟體測試中存在pareto原則：80%的缺陷發現在20%的模組中。
乙個功能模組發現的缺陷越高，那存在的未被發現的缺陷也越高，故發現的缺陷與未發現的缺陷成正比。
五、殺蟲劑悖論（pesticide paradox）
反覆使用相同的殺蟲劑會導致害蟲對殺蟲劑產生免疫而無法殺死害蟲。軟體測試也一樣。如果一直使用相同的測試方法或手段，可能無法發現新的bug。
為了解決這個問題，測試用例應當定期修訂和評審，增加新的或不同的測試用例幫助發現更多的缺陷。
測試人員不能一直依賴於現有的測試技術，而要不斷的提公升測試方法以提高測試效率。
六、測試活動依賴於測試內容（testing is context dependent）
根據業務的不同，軟體測試內部也分為不同的行業，比如遊戲行業、電商行業、金融行業。不同的行業，測試活動的開展都有所不同，比如測試技術、測試工具的選擇，測試流程都不盡相同，所以軟體測試的活動開展依賴於所測試的內容。
七、沒有錯誤是好是謬論（absence of error - fallacy）
有可能99%沒有bug的軟體也是不能使用的。如果對錯誤的需求進行了徹底的測試，這種情況就發生了。軟體測試不僅是找出缺陷，同時也需要確認軟體是否滿足需求。如果開發出來的產品不滿足使用者的需求，即便找到和修復了缺陷也作用不大。
軟體測試原則
1.測試證明軟體存在缺陷 無論執行什麼樣的測試操作都能證明當前軟體是有缺陷的 2.不能執行窮盡測試 有些功能是沒有辦法將所有的測試情況都邏輯出來，所以任何的測試操作都有結束的時間 3.缺陷存在群集現象 對於軟體功能說，核心功能佔20 非核心80 在實際工作中我們會集中測試20 的核心功能，所以這個部...
軟體測試原則
軟體測試規範 zero bug和good enough 對於相對複雜的產品或系統來說，沒有bug是不可能的，我們只能想方設法把軟體的bug數控制在可以忍受的範圍內 good enough 原則就是一種權衡投入 產出的原則 不充分的測試時不負責任的，過分的測試是一種資源的浪費 不要窮舉測試 窮舉測試指...
軟體測試理論 方法及流程
一 軟體測試理論基礎 1.軟體測試的定義 使用人工和自動手段來執行程式，目的在於檢驗是否滿足了需求。2.軟體測試的目的 是想以最少的人力 物力和時間找出軟體中潛在的各種錯誤與缺陷，通過修正各種錯誤和缺陷提高軟體質量，迴避軟體發布後由於潛在的軟體缺陷和錯誤造成的隱患以及帶來的商業風險。以最少的人力 物...