軟體測試基礎

軟體的組成

軟體是由資料、程式、文件組成

測試的生命週期

測試計畫

---

測試方案設計

---

測試開發

---測試用例的編寫與執行

測試執行

---

測試評估

---對測試結果的分析和報告

什麼是軟體測試？

一種用來促進鑑定軟體的正確性、完整性、安全性和質量的過程。換句話說，

軟體測試

是一種實際輸出與預期輸出之間的審核或者比較過程。在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程。

更直接的意思就是：我要乙個能吃飯的碗，而你不能給我乙個盆子，也不能給我乙個杯子，更不能給個有缺口的碗。而這一切就只是為了滿足客戶的要求。

軟體測試的分類

1)按測試階段分：單元測試

——整合測試

——系統測試

——驗收測試

2)按測試方法分：白盒測試

——灰盒測試

——黑盒測試

3)按被測物件是否執行的角度分：動態測試、靜態測試

4)其他測試分類：功能測試、介面測試、安全測試、相容性測試、易用性測試、效能測試、壓力測試、負載測試、恢復測試、冒煙測試、回歸測試、探索性測試

軟體測試的目的

1）驗證軟體是否滿足

軟體開發合同

或者專案開發計畫，系統

/子系統設計文件，軟體需求規格說明，軟體產品說明等規定的軟體質量要求

2）通過測試，發現軟體缺陷

3）為軟體產品的質量測量和評價提供依據

軟體測試的標準

4個過程，以及對應的解釋

1）測試策劃：主要是進行測試的需求分析

和測試計畫的編寫

2）測試設計：

依據測試需求，分析並選用，已由的測試用例或者設計新的測試用例，在進入下乙個階段工作之前，應該通過，測試就緒評審

3）測試執行，執行測試用例，獲取測試結果

分析並判定

設計結果

4）測試總結：整理和分析

測試資料

，評價測試效果和被測軟體項，描述

測試狀態

最後完成軟體測試報告並通過測試評審

測試用例的編寫流程

需求分析

①需求就是客戶需要的東西和客戶對其的要求。如果這款產品的使用者就是直接面向大眾的，那麼就需要自己去分析大眾使用者需要的是什麼，怎樣的功能才能讓使用者喜歡用。

②一般需求分為

業務需求

---表示組織或客戶高層次的目標。業務需求通常來自專案投資人、購買產品的客戶、實際使用者的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麼要開發乙個系統，即組織希望達到的目標。使用前景和範圍文件來記錄業務需求，這份文件有時也被稱作專案輪廓圖或市場需求文件。

行業都有自己的領域系統（行業所處的大環境，包括行業的習慣、北京等），而根據行業的領域系統及領導、客戶等的方向及目標。

使用者需求

---描述的是使用者的目標，或使用者要求系統必須能完成的任務。

這個範圍很廣，比如軟體的介面是否好看、功能使用是否便捷等都屬於使用者需求。使用者需求可以認為是對業務需求的乙個具體目標。比如業務需求提出了這個系統具有語音功能，那麼使用者需求就可能包含了語音具備的功能，比如可以喊「劉德華的電影」去搜尋電影等。

功能需求

---規定開發人員必須在產品中實現的軟體功能，使用者利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求。

功能需求是去解決業務需求、使用者需求的具體解決方案，也是我們通常說的需求說明書。對使用者需求做具體的分析、提出實施方法（需求說明書通常是由軟體開發方編寫如產品經理，使得使用者和軟體開發方都對軟體的初始的規定有乙個共同的理解，是整個開發的基礎）。同時，開發方需要對需求說明書進行評估，比如這個需求能不能做，耗費的成本是不是小於帶來的收益，還有風險評估等。

如果沒有需求怎麼辦？直接給你乙個軟體直接測試怎麼搞？

我們可以參考市面上同型別的產品。

如果需求模糊怎麼辦？

產品經理提出來的需求往往只有幾句話概況，這時候我們可以整理好已有的需求，把不明白的地方提出來，和相關的負責人確認，又或者參考同型別的產品實現的情況。也可以拿到產品後，進行探索性測試，去探索相關的功能需求，邊測試邊學習，驗證看是否滿足了業務，實在不明白再進行確認，但這樣會有風險，如果你和開發理解的一樣，但恰巧你們都理解錯了，那麼可能做出來的東西就不是產品經理需要的東西了。

提取測試點

①測試點事通過需求分析後對得出的需要測試的具體內容

②將測試點總結完畢，就可以根據測試點快速的寫測試用例，並可以很好的覆蓋需求。

編寫測試用例

測試用例設計的基本原則

1）基於測試需求的原則

2）基於測試方法的原則

3）兼顧

測試充分性

和效率的原則

4）執行用例的可再現性原則

測試用例的作用

1)檢驗軟體是否滿足客戶的需求

2)體現乙個測試人員的工作量

3)展現測試的設計思路，可以通過閱讀別人的測試用例學習測試用例的設計方法和思路。

測試用例一般包含

編號---

編號並不是簡單的

1234

，而是可以通過下劃線將一些測試用例的資訊包含進去，比如：

tv-yuyin-0001

，代表著這條測試用例是測試電視語音相關的。

用例名稱

---用例的名字，這個可以不寫。

測試背景

---說明該測試用例的背景，是測試什麼專案，什麼內容的。也可以不寫，有時候測試背景通過測試編號、測試檔案的名字、標題等就可以表達出來。

前置條件

---測試之前應該滿足於什麼條件才可以進行測試，一般要寫，如果沒有前置條件寫無就可以。

優先順序、重要級

---看似差不多，其實關係不大，優先順序高並不意味重要級高。

測試資料

---輸入的資料。

測試步驟

---是必須的，可以根據實際情況寫測試步驟，可以寫的粗糙，也可以寫的很詳細，比如第一步是什麼，第二步是什麼等。

預期結果

---對應著測試步驟，如果測試步驟寫的詳細，那麼預期結果也要寫的詳細，比如測試步驟有

5步，預期結果有

2個，別人怎麼知道這個結果是哪一步產生的？最好在編號上實現預期記過和操作步驟的統一。

實際結果

---在測試過程中的實際情況，如果一樣就寫通過、

ok等就可以了，如果不一樣，需要寫明實際結果是什麼。有的時候，我們可以再實際結果中寫ok、

false

，然後將實際結果寫在備註裡

備註但可以根據實際需要增加、刪除、修改部分項，比如：增加分類、子分類等。

測試用例的評審

①評審就是對測試用例進行檢查，包括

同行評審

---測試和測試之間的評審

小組評審

---組織乙個測試小組進行評審

部分評審

---整個部門進行評審

三方評審

---開發、測試、產品或者使用者都會參與進行評審

②評審不是一次性的，每次評審完進行測試用例的修改，再評審修改，直到測試用例通過。

測試用例的管理

①原始方式是通過

excel

**進行管理，雖然原始但是方便。只不過對於需求進行變更的專案來說，改起來比較痛苦。

②也可以採用一些專案管理工具，比如禪道，對測試用例及

bug系統進行統一管理，比較方便。

軟體測試基礎

軟體測試基礎 軟體測試概要

軟體測試基礎

軟體測試基礎

相關推薦

軟體測試基礎軟體測試概要