如果你去找一份功能測驗的作業，在軟體測驗工程師面試程序中，有一些面試官會來一兩個非常簡單的問題
什么是Test Case？
你是如何去寫Test Case的？
我們先來看一下測驗用例的介紹
什么是測驗用例？
測驗用例（Test Case）是為專案需求而編制的一組測驗輸入、執行條件以及預期結果，以便測驗某一個程式是否滿足客戶需求，
其實測驗用例它就是一個檔案，或者說是一個說明性的檔案，
檔案中間包括了一些關鍵性的內容比如它要有輸入、要有條件，要有預期結果，通過你的條件、輸入以及預期結果，我就可以去執行的時候來判斷這個程式是不是滿足客戶（用戶）的需求，我們把這一型別的檔案就叫做測驗用例，（測驗人員的依據內容）
當然說，對于一些不規范的或者說一些小公司，本來就我一個軟體測驗工程師，然后我也沒有時間去寫測驗用例，那我拿著這個軟體就直接開測了唄，那么在這種情況下，它也是沒有測驗用例的，
但是在沒有測驗用例的情況下，極有可能導致非常多的問題，比如說漏測，比如說測驗重復、無法去衡量軟體測驗完成的作業量，沒有依據等等之類的，
所以說稍微規范的公司，咱們都要去寫測驗用例，我們也會花很多的時間用在撰寫測驗用例上面，
為什么要寫測驗用例？
- 1.熟悉被測軟體的業務
- 2.明確測驗的思維和方式
- 3.保證測驗的時候不遺漏測驗功能點
- 4.測驗作業的一個輸出
就是為了避免前面說的一些問題，第一個，我們在寫測驗用例的時候，其實也是熟悉軟體測驗業務的一個程序，其實這個是非常有必要的，包括咱們在測驗這個專案之前，比如說你去一個新公司，你前一周或者前一個月，你都是在做同一件事情——看檔案，
通過看檔案盡快的去熟悉被測驗軟體的業務，
你對這個被測驗的軟體的業務越熟悉，那么你在測驗的程序中你才能測驗得越準確，可以避免一些不必要的錯誤，
第二個，我們可以明確在軟體測驗中的思維和方式，
第三個，這是你在軟體測驗作業的一個輸出，也就是說我早上九點鐘去晚上六點鐘下班，當老大問你說你今天做了什么事情的時候，結果你這也沒有那也沒有，我把測驗用例寫好了，一天寫了三五百條測驗用例，這也是作業的一種衡量，（當然多少條是沒有硬性規定的）
能夠發現bug的測驗用例就是好的用例？這個是錯誤的！
什么是好的測驗用例？
能夠全部覆寫需求的測驗用例就是好的測驗用例
測驗用例的使用范圍
- 1.手工測驗用例（功能測驗）
- 2.自動化測驗（介面自動化、UI自動化）
- 3.性能測驗用例
不論是在手工測驗還是自動化測驗、性能測驗我們都是需要去寫測驗用例的，
測驗用例的四要素
- 背景關系--前置條件，進入條件
比如說我們要對知乎進行登錄的一個測驗那么他的條件是什么，我們是不是先得把知乎這個APP安裝，這個就是他的背景關系，再比如我們要在知乎發文章，他的前提條件也是必須要登錄，這個登錄的操作就是他的背景關系或者說前置條件） - 測驗資料
測驗資料是非常關鍵的，比如說我們知乎的登錄，登錄的資料要準備的就是用戶名與密碼，準備好了，才能對這個功能去進行測驗，這個資料是非常多的，在這里我們要想到的一個點，是無法進行窮舉測驗的，我們在講測驗原則的時候會講到這個，因為第一個咱們的專案時間有限，第二個我們的人力成本也是有限，第三個實在這個資料量十分龐大，我們根本無法對它去進行一個窮舉測驗，因為我們就要對這些資料去進行一些分類、篩選，選一些有代表性的資料來進行測驗，
對于測驗資料的話，肯定要用一些方法對它進行分類，選取一些具有代表性的資料，這一個其實就是咱們測驗用例非常重要的一個環節，就是設計用例的方法，包括等價類、邊界值、判定表等等這一些，都是幫助你去篩選資料的， - 測驗步驟
第一步做什么第二步做什么第三步做什么，這個好理解吧，因為咱們去寫測驗用例不僅是給自己看的，首先你自己寫的測驗用例，你自己肯定要看得明白，除了當時能看明白，可能我隔兩個月隔一年以后我再來看這個測驗用例我也要能看得明白，同時也是給別人看的，因為我們自己寫的測驗用例并不一定是我們自己執行，這也是咱們測驗的原則之一，因為容易形成思維定式（交叉測驗） - 斷言--預期結果
我們要去設定一個預期結果，來判斷咱們的這個測驗用例以一個什么樣的標準來判斷它是正確的還是錯誤的，從而來驗證這個功能是否OK
測驗用例必須要包含這四個要素，缺一不可！
文章首發于公眾號：程式員一凡，轉載請注明出處！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/262397.html
標籤：其他