此篇是測試的基礎概念，希望你可以從這裡入門~

1、軟體測試的目的和原則

目的：驗證軟體是否存在問題

原則：以客戶為中心，遵循軟體測試的規範，流程，標準和要求。

2、需求是什麼？

IEEE定義： 軟體需求是 ① 使用者解決問題或達到目標所需的條件或權能；② 系統或系統部件要滿足合同、標準、規範或其他非正式規定檔案所需具有的條件或權能； ③ 一種反映上述兩者所述條件或權能的文件說明。 它包含功能性需求及非功能性需求。

總結 “需求” 是指：滿足使用者期望或正式規定文件（合同、標準、規範）所具有的條件和權能。 包括使用者需求和軟體需求。

• 使用者需求： 牛逼轟轟的甲方提出的需求；或理解為終端使用者使用產品時必須要完成的任務；較為簡單。

• 軟體需求：會詳細描述開發人員必須實現的軟體功能。也是測試人員工作的基本依據。

從“使用者需求”轉到“軟體需求”：需要 ——> 溝通！！

注：此處你可以想一下，不以測試人員的角度，對一個聲控燈的需求。

3、什麼是bug？

軟體錯誤的定義：
當且僅當規格說明是存在的並且正確，程式與規格說明之間的不匹配才是錯誤。當沒有需求規格說明書時，判斷標準以終端使用者為準：當程式沒有實現其終端使用者合理預期的功能要求時，就是軟體錯誤。

4、什麼是測試用例？

測試用例是為了實施而向被測試的系統提供的一組集合，這組集合包含：測試環境、操作步驟、測試資料、預期結果等因素。

最初的測試用例是用Excel寫的~

測試用例解決的問題：衡量測試的覆蓋率，可以實施新版本的重複測試，避免大量冗餘的測試影響測試效率。

此處你可以試著用Excel寫一個“蘋果手機中新建聯絡人”的測試用例。

5、開發模型和測試模型

軟體的生命週期

是指從軟體產品的設想開始到軟體不再使用而結束的時間。

分為6個階段：
== 需求分析–>計劃–>設計–>編碼–>測試–>執行維護 ==

模型1：瀑布模型

瀑布模型是所有其他模型的基礎框架，每一個階段都只執行一次，是線性順序進行的軟體開發模式。

優點：強調–>開發的階段性、早期計劃及需求調查、產品測試。
缺點：不能適應需求變化。因為是單一流程，開發的經驗不能反饋應用於本產品的過程。bug到最後一步才暴露出來。“整合之日就是爆炸之日。”

適合於：需求相對穩定，變更小的專案

模型2：螺旋模型

採用漸進式的開發模式。

優點：強調–>嚴格的全過程風險管理、各開發階段的質量。
缺點：引入–>極嚴格的風險識別、風險分析和風險控制。

適合於：規模大、複雜度高、風險大的專案

模型3：增量模型

增量開發能顯著降低專案風險，結合軟體持續構建機制。它鼓勵使用者反饋，在每個迭代過程中，促使開發小組以一種迴圈的、可預測的方式驅動產品的開發。

模型4：迭代模型

迭代是反覆求精的概念。

模型5：敏捷模型（當前較流行）

《敏捷宣言》（http://agilemanifesto.org/）：

① 個體與互動重於過程和工具–>“人與人之間的溝通”

② 可用的軟體重於完備的文件–>“輕文件”

③ 客戶協作重於合同談判–>“客戶參與”

④ 響應變化重於遵循計劃–>“擁抱變化”

⑤ 上面的每對比較中，後者並非全無價值，但我們更看重前者。

敏捷的特點：週期短（1_{4周）、人員（5}9人）、固定站會（10~15分鐘）

6、軟體測試模型

V模型

目的是改進軟體開發的效率和結果，是瀑布型的變種。

如下圖：

W模型

又叫“雙V模型”，它增加了軟體各開發階段中應同步進行的驗證和確認活動。

如下圖：

特點：測試與開發同步執行，即每個環境都要進行測試，避免了線型順序的缺點。

優點：儘早發現問題；缺點：研發和測試分開來看，仍為序列的；不能滿足需求頻繁變更。

7、配置管理

定義：通過對在軟體生命週期不同的時間點上的軟體配置進行標識，並對這些貝表示的軟體配置項的更改進行系統控制，從而達到保證軟體產品的完整性和可塑性的過程。

配置項：程式碼、文件、使用工具、程式等。

實施好處：軟體配置管理（SCM）實施可以 ① 對配置項進行有效管理；② 方便重現歷史版本； ③ 可重新編譯歷史版本； ④ 可實現異地多團隊開發、並行開發； ⑤ 提高工作效率。