在工作中 Test Case、Test Suite 等這些詞都會很常被使用到
先來簡單介紹一下這行名詞定義

Test Case(測試案例)

通常會由

• 前置條件(StepUp)
  • 某些 Test Case 需要先完成一些前置作業，才能順利進行該測試。
• 測試描述(Test Description)
  • 簡單描述該 Test Case 在做什麼，通常都是描述該測試的重點為主即可。
• 測試步驟(Test Step)
  • 將測試的步驟準確的寫下來，才能清楚地知道該如何操作、如何驗證。
• 測試資料(Test Data)
  • 需要一些測試的假資料來輔佐測試案例可以更為清楚。
• 預期結果(Expected Result)
  • 透過 測試步驟(Test Step) 的操作 以及 需求規格文件 相輔作為預期的驗證結果。

等欄位相組合成為一個測試案例。

可能會有額外的欄位輔佐 Test Case 可以更順暢執行驗證

• 實際結果(Actual Result)
  • 這通常為當開發已經完成該功能後，透過實際操作後的結果。
    (注意: 實際結果 ≠ 預期結果，因為有可能是開發會搞錯預期結果，導致出現錯誤的結果。)
• 驗證狀態(Verify Status)
  • 主要是當要開始執行所有 Test Case 時，需要逐一檢驗是否該 Test Case 有被執行到，並記錄執行結果，以便更好追蹤測試的進度。
    備註: 當 Test Case 多到 500+、1000+ 以上時，就會發現手動驗證非常耗時耗人力，所耗費的時間成本很大，這時就須要有自動化來輔佐完成這件事情

實際範例一: 登入功能

實際範例二: 商品加入購物車

Test Suite(測試套件)

是將相同性質的 Test Case 組合在一起，即為 Test Suite。

通常在撰寫 Test Case 時都會將其分門別類，以確保日後的維護性、可讀性等。

然後一個頁面中，大多同時都會有多個功能相組而成，因為這樣可以讓使用者很方便的使用、操作

那在撰寫 Test Case 時，就會需要將每個功能區隔開來撰寫。

以 iT邦幫忙 網站來說，光是上方此頁面，其時就可以先分成 5 大區塊的 Test Suite，然後在依照每個區塊中依序撰寫 Test Case。

結語

懂得列 Test Case 已經是 QA 的命脈了
不管新舊功能，只要到 QA 手上，Test Case 就是必列無疑了
然而在條列的同時，也會對產品功能越來越熟悉，對測試的敏銳度也能慢慢提高

Test Suite 通常會比較應用在 規劃 的時候需要用到
要懂得善用 Test Suite 將測試分門別類，又同時時還要團隊的其他夥伴也看得懂

不管是 Test Case 還是 Test Suite，只要你是在列測試
就是在提高產品測試的範圍，列完後，自動化基本上就可以直接實作了

但要注意一點~
不管是 Test Case 還是 寫自動化，在團隊中，都還是需要有 Review 的階段哦~
這樣才比較能確保你寫的測試是沒問題的，也是別人看得懂的
(Code) Review 的機制及規則，之後我也會在寫一篇