先從基礎說起吧！探索兩種一般測試模式和三種常見的測試自動化類型。
我們都遇過這種情況：在現實生活中，常會重複發生的程式爆發是什麼？
這個網路迷的結論是非常好的摘要：每個抽屜可以個別順暢運作，但如果搭配其他抽屜，它們會彼此封鎖，導致無法運作。您希望讓兩個導覽匣順暢運作，並同時操作。
應用在網站開發上：您撰寫了一些測試，甚至達到 100% 的測試涵蓋率，但應用程式在其他部分實現後仍需運作。這些單元可能獨立運作，但彼此無關。撰寫一些測試非常重要，但這只是專案理想測試設定的一部分。首先，您必須決定所需的應用程式品質部分，以及如何達成這些目標。
簡單來說，您必須先擬定計畫，才能開始撰寫實際測試程式碼。為了讓學員瞭解實際的測試方式，我們先從簡明的插入畫面開始思考，並回答兩個基本問題：
- 您想如何測試？
- 您想進行什麼測試？
本文將重點放在回答第一個問題時所需的一般資訊。首先，讓我們瞭解可用的測試模式，然後著重於常見的測試類型。在後續的文章中，我們將回答第二題，合併答案，找出最適合您專案的測試策略。馬上出發！🙌
先從基礎測試開始：一般測試模式
回答測試方法時，釐清的第一點顯然非常抽象。您應該手動測試，還是由電腦接管？然而，這很重要，不可以考慮使用二元法則思考。
手動測試與自動化測試
如果您要求品質查驗工程師定義測試，他們可能會先將測試分成兩個「模式」：
- 手動測試。這是由實際人員進行的一般測試方法。品質查驗工程師會點閱應用程式，確認是否正常運作，同時嘗試破壞應用程式。最常見的方法是探索性測試，工程師會根據預先定義的路徑或檢查清單，運用自己對應用程式的知識來調查應用程式。
- 自動化測試。這是由電腦進行的測試。品質查驗工程師會執行這項功能，自動排除重複且不連續的測試。
本系列的指南主要著重於自動化測試。不過，不應只著重一種測試方式。即使自動化功能有助於您節省大量時間和精力，人員和手動測試還是至關重要。測試自動化功能應讓員工專心進行探索性測試，並專注於解決創意的問題。例如確保使用者體驗品質，或保護高風險商業邏輯。也就是說，自動化功能是您的後盾。❤️
不透明的箱子與清除方塊
因此，您已定義一般測試模式。不過，這樣還不夠。為了規劃測試策略，還有一個問題必須回答：您是否知道應用程式的實際運作原理，還是在不知情的情況下進行測試？視答案而定，有兩種程序可供選擇，讓您選擇導引和選取測試案例：
- 不透明箱測試 (或黑箱測試)。是以分析元件或系統的功能或非功能需求 (規格) 為基礎，不會考慮其內部結構。
- 透明箱測試 (或白箱測試) 是將上述盒子的內部結構納入考量的程序。換句話說，瞭解應用程式究竟如何運作。
這兩項程序可同時套用至手動和自動化測試。不過，一般測試模式的某些層面可能更著重在其中一種，我們稍後會說明。現在，我們進一步細分為測試自動化的類型。
測試自動化類型：您想如何測試？
在回答「操作」問題的過程中，您決定進行手動測試。不過，選擇及套用測試自動化類型比較困難。自動化測試的類型與您要在專案中建立的指標密切相關。接下來我們要進一步瞭解最重要的規則。
如前面提到的網路迷因所示，您已分成兩種類型：單元測試和整合測試。第三項重要測試是端對端測試。但這不僅止於此。一起來仔細看看。
單元測試
單元測試是一種測試類型，會個別測試應用程式的少數可測試部分或單元，並進行適當測試。這些單位的適用範圍涵蓋函式、類別、介面、服務或完整元件。主要特質在於執行速度、隔離和易於維護。如要深入瞭解單元測試，請參閱這份單元測試指南。
整合測試
整合測試著重於元件或系統之間的互動。也就是協同合作的成效。整合測試的常見例子包括 API 或元件測試。
端對端測試
這些測試通常稱為 UI 測試，這個名稱可進一步描述其功能。這些測試會與應用程式的 UI 互動 (包括完整的應用程式堆疊)，並在另一端測試應用程式。
就像是品質查驗的理論一樣。這些測試模擬出真實的使用者及其互動情形。端對端測試涉及整個系統，需要更多的運算能力，因此需要較長的執行時間。因此，這個額外的工作成本會增加。
視覺 UI 測試
有趣的 UI 測試子類別是視覺測試。這些測試是延伸端對端測試，可讓您驗證應用程式可見的輸出內容。這類測試會在變更後擷取螢幕截圖，並擷取另一張含有「現狀」(或黃金檔案) 的螢幕截圖，然後將這些結果交由人工審查員進行檢查和檢查。換句話說，這項技術有助於找出網頁外觀中的「視覺錯誤」，而不只是單純提供功能錯誤，或是沒有明確寫成斷言。
靜態分析
這裡還有一個重點，就是「靜態分析」。這並不是教科書的測試類型。然而，這項概念日後也會是品質查驗策略的重要一環。您可以將其想像成像拼字檢查功能一樣：這項功能可以在不執行程式的情況下掃描程式碼，找出更顯著的缺陷和語法錯誤，進而偵測程式碼樣式問題。這種簡單的測量方式可以防止許多錯誤。如果想進一步瞭解靜態分析，這就很適合用來學習。
針對各種形狀進行測試：如何共同運作？
搜尋這些問題的答案時，你或許可以在一些比喻中找到可能的解決方法。尤其是網路與測試社群，開發人員通常會利用這些比數，瞭解應使用多少次測試。
下圖中最常見的五種策略是：
- 測試金字塔
- 測試鑽石
- 測試冰棒 (又稱為測試披薩)
- 測試 Honeycomb
- 測試獎盃
這需要處理大量資訊，請問你該如何根據上述各項資訊，決定合適的測試策略？別擔心，交給我們就好。下一篇文章將進一步探討各種不同的策略，並說明如何選擇最適合專案的方式。別離開！🔥