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