經過昨天用 atm 與捷運門來解釋單元測試與整合測試後，不知道大家有沒有清楚。我早上起床聽著以前最愛的 Evanescence - Bring me to life 後，突然想到可以用樂團來解釋，所以今天就讓我們用樂團來理解所有測試類型是什麼概念。

一個樂團代表一個專案，這個樂團(專案)的目的就是要在演唱會上演奏歌曲。一個樂團裡會有鼓手、Bass手、吉他手、主唱，這每一個樂手代表著一個又一個的方法、類別等最小單位，他們的樂譜代表 code，所以樂手 (功能) 會依照樂譜 (code) 彈奏出音樂 (執行後的結果)，當所有樂手組合起來彈奏出各自的音樂，就是演奏出一首歌 (一個完整的專案)。

今天我們進行單元測試時，就是針對每一個樂手(功能、方法等) 去確認是不是已經能照著樂譜(code)彈奏歌曲(正確的執行，沒有 bug) 了，solo、過門是不是都沒問題了。

大家都練好也確認都沒問題之後，就開始進行整合測試，也就是所有樂手到練團室一起演奏同一首歌，彼此協調節拍，確認大家在演奏同一首歌時，節奏是一致的，也就是在確認彼此的運作關係。

接著承接 Day2，繼續來講解系統測試與消費者使用測試：

三、系統測試：

完成了整合測試後，接續進行系統測試，而通常會與其他外部系統一同進行，所以也會與其他人員一起合作，相當耗時。以上述樂團為例，團練(整合測試) 沒問題後，接著就是要到現場與 PA 設備一起預演，確認樂團演奏時，音響設備都正常，而且還要安排好設備擺放位置與方向以利達到演唱會聲音傳播的最佳程度。

四、消費者使用測試：

製作專案的最終目的就是要讓使用者滿意，因為工程師與使用者的視角不同，有時工程師製作出來的東西可能會稍微不合乎使用者體驗，所以才需要進行消費者使用測試。

小結:

最後再跟讀者們說一下，盡量不要把測試想的太可怕，因為之後在業界有蠻大的機率會碰到測試，而測試的重點除了開發時找 bug 以外，更重要的是之後的維護與增加新的功能，到時就會知道測試的好。

這三天的文章一直圍繞在測試的概念上，希望大家都有明白這三天的內容。如果有大大發現文章裡有什麼地方說錯的，還請留言跟我說一下，非常感謝大家~

那麼接下來就要開始進入本系列的重點，將會一一介紹測試模式 TDD 與 BDD，以及它們的測試框架如何使用。