軟體測試中的測試用例Test Case原來是這麼回事！

如果你去找一份功能測試的工作，在軟體測試工程師面試過程中，有一些面試官會來一兩個非常簡單的問題

什麼是Test Case？

你是如何去寫Test Case的？

我們先來看一下測試用例的介紹

什麼是測試用例？

測試用例（Test Case）是為項目需求而編制的一組測試輸入、執行條件以及預期結果，以便測試某一個程式是否滿足客戶需求。

其實測試用例它就是一個文檔，或者說是一個說明性的文檔。

文檔中間包括了一些關鍵性的内容比如它要有輸入、要有條件，要有預期結果，通過你的條件、輸入以及預期結果，我就可以去執行的時候來判斷這個程式是不是滿足客戶（使用者）的需求。我們把這一類型的文檔就叫做測試用例。（測試人員的依據内容）

當然說，對于一些不規範的或者說一些小公司。本來就我一個軟體測試工程師，然後我也沒有時間去寫測試用例，那我拿着這個軟體就直接開測了呗，那麼在這種情況下，它也是沒有測試用例的。

但是在沒有測試用例的情況下，極有可能導緻非常多的問題，比如說漏測，比如說測試重複、無法去衡量軟體測試完成的工作量。沒有依據等等之類的。

是以說稍微規範的公司，咱們都要去寫測試用例，我們也會花很多的時間用在編寫測試用例上面。

為什麼要寫測試用例？

• 1.熟悉被測軟體的業務
• 2.明确測試的思維和方式
• 3.保證測試的時候不遺漏測試功能點
• 4.測試工作的一個輸出

就是為了避免前面說的一些問題。           

第一個，我們在寫測試用例的時候，其實也是熟悉軟體測試業務的一個過程，其實這個是非常有必要的，包括咱們在測試這個項目之前，比如說你去一個新公司，你前一周或者前一個月，你都是在做同一件事情——看文檔。

通過看文檔盡快的去熟悉被測試軟體的業務。

你對這個被測試的軟體的業務越熟悉，那麼你在測試的過程中你才能測試得越準确。可以避免一些不必要的錯誤。

第二個，我們可以明确在軟體測試中的思維和方式。

第三個，這是你在軟體測試工作的一個輸出。也就是說我早上九點鐘去晚上六點鐘下班，當老大問你說你今天做了什麼事情的時候，結果你這也沒有那也沒有。我把測試用例寫好了，一天寫了三五百條測試用例，這也是工作的一種衡量。（當然多少條是沒有硬性規定的）

能夠發現bug的測試用例就是好的用例？這個是錯誤的！

什麼是好的測試用例？

能夠全部覆寫需求的測試用例就是好的測試用例

測試用例的使用範圍

• 1.手工測試用例（功能測試）
• 2.自動化測試（接口自動化、UI自動化）
• 3.性能測試用例

不論是在手工測試還是自動化測試、性能測試我們都是需要去寫測試用例的。

測試用例的四要素

• 上下文--前置條件，進入條件

  比如說我們要對知乎進行登入的一個測試那麼他的條件是什麼，我們是不是先得把知乎這個APP安裝，這個就是他的上下文。再比如我們要在知乎發文章，他的前提條件也是必須要登入，這個登入的操作就是他的上下文或者說前置條件）

• 測試資料 

  測試資料是非常關鍵的，比如說我們知乎的登入，登入的資料要準備的就是使用者名與密碼，準備好了，才能對這個功能去進行測試。這個資料是非常多的，在這裡我們要想到的一個點，是無法進行窮舉測試的。我們在講測試原則的時候會講到這個。因為第一個咱們的項目時間有限，第二個我們的人力成本也是有限，第三個實在這個資料量十分龐大，我們根本無法對它去進行一個窮舉測試。因為我們就要對這些資料去進行一些分類、篩選。選一些有代表性的資料來進行測試。

  對于測試資料的話，肯定要用一些方法對它進行分類，選取一些具有代表性的資料。這一個其實就是咱們測試用例非常重要的一個環節，就是設計用例的方法。包括等價類、邊界值、判定表等等這一些，都是幫助你去篩選資料的。

• 測試步驟

  第一步做什麼第二步做什麼第三步做什麼，這個好了解吧。因為咱們去寫測試用例不僅是給自己看的，首先你自己寫的測試用例，你自己肯定要看得明白，除了當時能看明白，可能我隔兩個月隔一年以後我再來看這個測試用例我也要能看得明白。同時也是給别人看的，因為我們自己寫的測試用例并不一定是我們自己執行，這也是咱們測試的原則之一。因為容易形成思維定式（交叉測試）

• 斷言--預期結果

  我們要去設定一個預期結果，來判斷咱們的這個測試用例以一個什麼樣的标準來判斷它是正确的還是錯誤的，進而來驗證這個功能是否OK

測試用例必須要包含這四個要素，缺一不可！

文章首發于公衆号：程式員一凡，轉載請注明出處！

微信公衆号：程式員一凡