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

若是你去找一份功能測試的工做，在軟件測試工程師面試過程當中，有一些面試官會來一兩個很是簡單的問題

什麼是Test Case？
你是如何去寫Test Case的？

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

什麼是測試用例？

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

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

文檔中間包括了一些關鍵性的內容好比它要有輸入、要有條件，要有預期結果，經過你的條件、輸入以及預期結果，我就能夠去執行的時候來判斷這個程序是否是知足客戶（用戶）的需求。咱們把這一類型的文檔就叫作測試用例。（測試人員的依據內容）

固然說，對於一些不規範的或者說一些小公司。原本就我一個軟件測試工程師，而後我也沒有時間去寫測試用例，那我拿着這個軟件就直接開測了唄，那麼在這種狀況下，它也是沒有測試用例的。

可是在沒有測試用例的狀況下，極有可能致使很是多的問題，好比說漏測，好比說測試重複、沒法去衡量軟件測試完成的工做量。沒有依據等等之類的。

因此說稍微規範的公司，我們都要去寫測試用例，咱們也會花不少的時間用在編寫測試用例上面。

爲何要寫測試用例？

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

就是爲了不前面說的一些問題。

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

經過看文檔儘快的去熟悉被測試軟件的業務。

你對這個被測試的軟件的業務越熟悉，那麼你在測試的過程當中你才能測試得越準確。能夠避免一些沒必要要的錯誤。

第二個，咱們能夠明確在軟件測試中的思惟和方式。

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

可以發現bug的測試用例就是好的用例？這個是錯誤的！
什麼是好的測試用例？
可以所有覆蓋需求的測試用例就是好的測試用例

測試用例的使用範圍

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

不管是在手工測試仍是自動化測試、性能測試咱們都是須要去寫測試用例的。

測試用例的四要素

• 上下文--前置條件，進入條件
  
  好比說咱們要對知乎進行登陸的一個測試那麼他的條件是什麼，咱們是否是先得把知乎這個APP安裝，這個就是他的上下文。再好比咱們要在知乎發文章，他的前提條件也是必需要登陸，這個登陸的操做就是他的上下文或者說前置條件）
  
  
• 測試數據 
  
  測試數據是很是關鍵的，好比說咱們知乎的登陸，登陸的數據要準備的就是用戶名與密碼，準備好了，才能對這個功能去進行測試。這個數據是很是多的，在這裏咱們要想到的一個點，是沒法進行窮舉測試的。咱們在講測試原則的時候會講到這個。由於第一個我們的項目時間有限，第二個咱們的人力成本也是有限，第三個實在這個數據量十分龐大，咱們根本沒法對它去進行一個窮舉測試。由於咱們就要對這些數據去進行一些分類、篩選。選一些有表明性的數據來進行測試。
  對於測試數據的話，確定要用一些方法對它進行分類，選取一些具備表明性的數據。這一個其實就是我們測試用例很是重要的一個環節，就是設計用例的方法。包括等價類、邊界值、斷定表等等這一些，都是幫助你去篩選數據的。
• 測試步驟
  
  第一步作什麼第二步作什麼第三步作什麼，這個好理解吧。由於我們去寫測試用例不只是給本身看的，首先你本身寫的測試用例，你本身確定要看得明白，除了當時能看明白，可能我隔兩個月隔一年之後我再來看這個測試用例我也要能看得明白。同時也是給別人看的，由於咱們本身寫的測試用例並不必定是咱們本身執行，這也是我們測試的原則之一。由於容易造成思惟定式（交叉測試）
  
  
• 斷言--預期結果
  咱們要去設置一個預期結果，來判斷我們的這個測試用例以一個什麼樣的標準來判斷它是正確的仍是錯誤的，從而來驗證這個功能是否OK

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

文章首發於公衆號：程序員一凡，轉載請註明出處！