軟體測試指南

2002 年，我參加了 XP/Agile Universe 的工作坊，當時「範例規格」這個詞句讓我想到，可以用來描述XP中測試的角色之一。

測試驅動開發 (TDD) 是一種透過撰寫測試來引導軟體開發的軟體建構技術。它是由Kent Beck在 1990 年代後期開發，作為極限程式設計的一部分。基本上，我們重複執行三個簡單的步驟

測試金字塔是一種思考方式，說明如何使用不同類型的自動化測試來建立平衡的組合。其重點在於您應該執行比透過 GUI 執行的 BroadStackTests 高階 UnitTests 多得多的低階測試。

「測試金字塔」是一個比喻，告訴我們將軟體測試分組到不同粒度的區塊中。它也提供了一個概念，說明我們應該在每個群組中有多少測試。儘管測試金字塔的概念已經存在一段時間，但團隊仍然難以適當地實踐它。本文重新探討測試金字塔的原始概念，並說明如何將其付諸實踐。它說明您應該在金字塔的不同層級中尋找哪些類型的測試，並提供有關如何實作這些測試的實用範例。

在過去幾年中，服務基礎架構已經轉向更小、更專注的「微」服務。這種方法有很多好處，例如能夠獨立部署、擴充和維護每個元件，以及在多個團隊中並行開發。然而，一旦引入這些額外的網路分割，就需要重新考量用於單體處理程序應用程式的測試策略。在此，我們計畫討論許多方法來管理多個獨立部署元件的額外測試複雜性，以及如何在多個團隊各自擔任不同服務的守護者的情況下，讓測試和應用程式保持正確。

對於測試組合應為金字塔形或蜂巢形，存在著爭論。我對此論點的第二大問題是，由於人們對於單元測試和整合測試的差異看法不明確，因此這論點變得不透明。

單元測試在軟體開發中經常被討論，在我撰寫程式碼的整個過程中，這是一個我熟悉的術語。然而，與大多數軟體開發術語一樣，它的定義非常模糊，我發現當人們認為它的定義比實際上更嚴謹時，經常會產生混淆。

廣域堆疊測試是一種測試，會執行大型應用程式的大部分元件。它通常稱為端對端測試或全堆疊測試。它與僅執行系統中定義良好的部分的元件測試相反。

整合測試確定獨立開發的軟體單元在連接在一起時是否能正確運作。這個術語甚至模糊了軟體產業的廣泛標準，所以我一直謹慎地在文章中使用它。特別是，許多人假設整合測試的範圍必然廣泛，而實際上它們可以更有效地執行在較窄的範圍內。

故事測試是面向業務測試，用於描述和驗證作為使用者故事一部分提供的軟體。當一個故事被詳細說明時，團隊會建立幾個故事測試，作為故事的驗收標準。故事測試可以組合成軟體的回歸套件，並提供從需求（使用者故事）到測試，以及（透過執行）到系統行為的可追溯性。故事測試通常是廣域堆疊測試。

使用 測試替身 最常見的情況之一是與外部服務進行通訊時。通常此類服務由不同的團隊維護，它們可能會受到速度慢且不可靠的網路影響，而且本身可能不可靠。這就是測試替身很方便的原因，它可以防止您自己的測試速度慢且不可靠。但針對替身進行測試時，總會出現一個問題，即替身是否確實準確代表外部服務，以及如果外部服務變更其合約會發生什麼事？

元件測試是一種將受測軟體的範圍限制在受測系統的一部分的測試。它與 廣域堆疊測試 相反，後者旨在執行系統中合理的部分。

面向業務的測試是一種旨在用於協助與開發團隊中非程式設計成員（例如客戶、使用者、業務分析師等）進行通訊的測試。當自動化時，它們會以面向領域的術語描述系統，而忽略系統本身的元件架構。面向業務的測試通常用作驗收標準，通過此類測試表示系統提供客戶預期的功能。

我使用皮下測試來表示在應用程式的使用者介面下方運作的測試。在執行應用程式的功能測試時，這特別有價值：當您想要測試端對端行為，但很難透過使用者介面本身進行測試時。

閾值測試是一種插入 部署管線 的測試，它透過將目前建置中的值與閾值進行比較來監控一些可測量的現象。如果目前建置的值通過閾值，測試就會失敗，導致建置失敗。

Gerard Meszaros 正在 撰寫一本書 來擷取使用各種 Xunit 框架的模式。他遇到的其中一個尷尬問題是，人們用於替換系統部分以進行測試的 stub、mock、fake、dummy 等東西名稱不一。為了解決這個問題，他想出了自己的詞彙，我覺得值得進一步推廣。

XUnit 是給予廣為軟體開發人員所知的測試架構的一系列家族名稱。此名稱源自於 JUnit, 這是第一個廣為人知的測試架構。

「模擬物件」一詞已成為用來描述特殊情況物件的熱門詞彙，這些物件會模仿真實物件以進行測試。現在大多數的語言環境都有讓建立模擬物件變得容易的架構。然而，常被忽略的是，模擬物件只是特殊情況測試物件的一種形式，它能啟用不同的測試樣式。在本文中，我將說明模擬物件如何運作、它們如何鼓勵基於行為驗證的測試，以及它們周圍的社群如何使用它們來開發不同的測試樣式。

本世紀見證了程式設計師測試的顯著增加，程式設計師承擔了撰寫他們自己程式碼測試的責任。我們發現這有助於減少錯誤、讓思考 API 設計變得更容易，並能進行重構。讓這件事發生的很大一部分原因在於 xUnit 簡單測試架構家族，它起源於 Kent Beck 和 Erich Gamma 的工作。但儘管 xUnit 是個簡單的工具，但有效使用它需要經驗和技能。Gerard Meszaros 是這些工具和使用模式來幫助人們學習軟體設計技術這個想法的早期採用者。它提供了一個詞彙，幫助我們溝通我們如何使用測試，以及一個讓經驗豐富的從業人員將他們的知識傳授給新一代的基礎。

2014 年初發現了兩個電腦安全漏洞：Apple 的「前往失敗」錯誤和 OpenSSL 的「Heartbleed」錯誤。這兩個錯誤都有可能導致廣泛且嚴重的安全失敗，我們可能永遠不知道其全部程度。鑑於其嚴重性，軟體開發專業人員必須反思如何才能偵測到它們，以便我們能改善我們在未來預防這些種類缺陷的能力。本文考慮了單元測試可能扮演的角色，展示了單元測試，更重要的是單元測試文化，如何能找出這些特定錯誤。它繼續探討這種文化的成本和好處，並描述了這種文化如何在 Google 中灌輸。

自動化回歸套件在軟體專案中扮演至關重要的角色，既能減少生產中的缺陷，也是演化設計不可或缺的要素。在與開發團隊交談時，我常聽聞非決定性測試的問題，也就是有時通過，有時失敗的測試。如果放任不管，非決定性測試會完全破壞自動化回歸套件的價值。在本文中，我將概述如何處理非決定性測試。隔離有助於降低它們對其他測試的損害，但你仍必須盡快修復它們。因此，我將討論非決定性的常見原因的處理方式：缺乏隔離、非同步行為、遠端服務、時間和資源外洩。

隨著我的職業生涯轉為全職寫作，我常擔心自己會與日常軟體開發的現實脫節。我曾看過其他知名人物失去與現實的聯繫，我害怕自己也會步上後塵。我對抗這種情況的最大來源是 Thoughtworks，它就像一劑定期的現實良藥，讓我腳踏實地。

Thoughtworks 也是來自現場的點子來源，我很喜歡寫同事發現和開發的有用事物。這些通常是有用的點子，我希望部分讀者能加以利用。我今天的題目並非如此令人愉快。這是一個問題，而且我們沒有答案。

時不時我會聽到有人詢問他們應該追求什麼價值的測試涵蓋率（也稱為程式碼涵蓋率），或自豪地說明他們的涵蓋率等級。此類說法都錯失重點。測試涵蓋率是找出程式碼庫中未測試部分的有用工具。測試涵蓋率作為數值說明你的測試有多好的用處不大。

測試影響分析 (TIA) 是加速建置測試自動化階段的現代方法。它的運作方式是分析原始碼的呼叫圖形，找出在變更生產程式碼後應該執行哪些測試。Microsoft 已針對此方法進行廣泛的研究，但開發團隊也可以相當低成本地實作一些有用的東西。

Ruby on Rails 的創建者 David Heinemeier Hansson 在 RailsConf 上發表主題演講時宣稱 TDD 已死。這在 Rails 和更廣泛的軟體開發社群中引發了預期中的大量爭議。這也導致 David、Kent 和我之間進行了一些有趣的對話。我們認為這些對話很有趣，其他人可能也喜歡觀看，因此錄製了一系列影片聚會，討論 TDD 在軟體開發中的角色。

針對網頁撰寫測試時，您需要參照網頁中的元素才能按一下連結並確定顯示的內容。但是，如果您撰寫直接操作 HTML 元素的測試，您的測試將會容易受到 UI 變更的影響。頁面物件會以特定於應用程式的 API 包裝 HTML 頁面或片段，讓您可以在不深入探究 HTML 的情況下操作頁面元素。

使用 測試替身 的經典案例之一是當您呼叫遠端服務時。遠端服務通常很慢且經常不可靠，因此使用替身是讓您的測試更快速且更穩定的好方法。

有些程式元素本質上難以測試，甚至無法測試。這些元素中的任何邏輯因此容易出現錯誤且難以演進。為了解決這個問題，請盡可能將邏輯移出難以測試的元素，並移至程式碼庫中其他更友善的部分。透過讓無法測試的物件保持謙虛，我們可以減少它們藏有惡意錯誤的機率。

現代模擬工具對我們處理舊有程式碼的能力可能產生的正面影響，以及使用這些工具的可能負面影響。

如果您需要在程式碼中取得目前日期或時間，請勿直接存取系統常式來取得該資料。請在常式周圍加上某種形式的封裝器，讓您可以透過將「目前日期/時間」設定為特定值來覆寫它。這對於簡化測試非常重要。

物件母體是一種用於測試的類別，用來協助建立您用於測試的範例物件。

我正在翻閱一些舊筆記，並發現 Rich Garzaniti 給我的簡單但有用的提示。

傳統上，品質保證專注於在軟體發布到生產環境之前進行測試，以查看它是否已準備好發布。但現代品質保證組織也越來越關注執行中生產環境中的軟體。透過分析日誌和其他監控工具，他們會找出品質問題，並強調給開發組織。此方法特別適用於使用持續交付將新版本的軟體快速且可靠地投入生產環境的組織。

探索性測試是一種強調快速學習、測試設計和測試執行週期的測試方式。探索性測試並非試圖驗證軟體是否符合預先寫好的測試腳本，而是探索軟體的特徵，提出將被歸類為合理行為或失敗的發現。

我們軟體系統中的可觀察性一直很有價值，並且在雲端和微服務的時代變得更加重要。然而，我們新增到系統中的可觀察性往往在性質上相當低階且技術性，而且似乎太常需要在我們的程式碼庫中散佈大量繁瑣、冗長的呼叫，以使用各種記錄、儀器和分析架構。本文描述了一種模式，可以清理此混亂，並允許我們以乾淨、可測試的方式新增與業務相關的可觀察性。

合成監控（也稱為語義監控）會定期針對應用程式的自動化測試子集，對實際的生產系統執行測試。結果會推送到監控服務中，在發生故障時觸發警示。此技術結合自動化測試與監控，以偵測生產環境中不合格的商業需求。