讀書心得 (二) Continued:

在組織開發團隊制定開發流程時，就要將測試整合到團隊開發所使用的模型中，如瀑布、遞迴、敏捷⋯等。因為不同的開發模型施行測試之時機不同，人力配置也有差異。以瀑布式為例，大多集中在開發接近完成時，若採用遞迴開發，則變成週期性的測試，而敏捷模式則為時時刻刻開發與測試混著進行（關於敏捷開發 下的測試可參考本書《第2章：談Visual Studio與敏捷測試》）。

如何規劃開發團隊的資源以及何時施行測試，其設備與人力的配置於專案初始即有腹案，專案經理應在驗收規格載明要通過的測試類型與標準。非到專案快結束時，才由甲、乙雙方專案經理自己，或是指派工程師或使用者隨意測試。團隊中最好要有專業的測試人員。初階的測試人員或許僅執行手動測試，但資深的測試人員要熟悉程式語言，需規劃測試平台與架構，讓測試自動化，精準而有效率。最好不要由開發者兼任測試者，因為測試者和開發者完成工作的方式不同，測試者代表使用者來測情境，開發者則測試程式碼單元。測試者思考使用者如何工作，開發者思考程式碼如何工作。測試者愛找蟲，開發者不願找到蟲。

在《約耳趣談軟體》一書中，作者就明言沒有專職測試者的壞處，例如：再優秀的開發者都有盲點，他自身可能永遠忽略了不自覺犯下的錯誤，需由測試者來發現。且若由資深的開發工程師來測試自己開發的程式，則優秀的開發人力無法進行開發，卻要將心力耗在測試上，豈不本末倒置？唯有優秀的測試人員才能在短期間找到大量的錯誤。

整體而言，最好在分析時期，即同步撰寫如何測試的程式案例，以確認是否符 合使用者需求的文件4。在設計時期，要提出模組與架構之間整合測試的方式， 以確認架構與介面定義的正確性。並在開發時期，同時撰寫單元測試（Unit Test），以驗證個別程式碼的正確性。待稍具功能之後，便能展開手動測試，以 及其後一連串用途不同的測試。同時，說明文件的正確性也要一併測試，讓V&V （Verification and Validation）的精神貫穿整個開發過程，時時驗證（Verification） 是在做使用者需要的產品，並確認（Validation）事情做對了。

除了上述開發流程中的配套作業之外，測試目的尚有針對架構的整合、安全、壓力、容錯⋯等測試。廣義而言，整個軟體生命週期充滿了各式各樣的測試，例 如：導入新技術前的POC（Proof Of Concept）。上線之前，你還需要測試使用 者的專業能力（使用者的無知很可能是系統損毀、安全疑慮的最大來源）；上 線之後，週期性地測試系統災難復原的能力，乃至於隨著軟硬體Hot fix、service pack、迭代更新版本的相容性測試⋯等等。

你可以依照當下的需求，選擇規劃上述某個面向的系列測試。此外，在建立測試計畫時，需涵蓋測試平台、工具、案例管理、環境、資料收集、結果分析等項目的規劃。由於測試是周而復始的執行，所以在規劃時應儘量提升週期性、自動化之能力。

在規劃與施行某項測試之前，應當為個別的測試撰寫測試案例5，其內容須包含右列項目：

案例編號、名稱、說明、區域、擁有人、優先權、狀態、系統環境、應執行的情境與頻率。

驗證功能，包含少見的使用情境，以達到最大程式碼的涵蓋範圍。

動作步驟：步驟完備、說明簡單、可執行。

預期結果：可明確判讀。

實際結果：完整、明確。

測試案例的內容必須簡單易懂，讓任何人都可執行，換句話說，儘量避免專有名詞，不要夾雜開發人員的術語，且測試案例要可累積、易管理。待假以時日，一個專案或產品可能有成百上千個測試案例。若沒有規範，將很難讓需求、實作、 測試、bug、修正、回歸測試等資訊串起來，如同一掛粽子，從任何一個點都可 以追溯到所有其他的來龍去脈。

在定出軟體測試的流程之後，若沒有功能完備、整合軟體開發各個環節、易上手且自動化的工具程式、方便準備與重用的測試環境⋯等，則推廣的結果可能流於空談。畢竟測試是重複的流程，還需詳述測試環境與測試方法，並填寫大部分內容近似的報告或電子郵件。一再進行相同的事情會變得枯燥、輕忽。然而，測試者應專注於找bug，而非耗在重複執行與撰寫測試報告。測試者應有 技巧、富創意、高效率地尋找潛在的bug，讓「獵蟲」的樂趣令測試者有源源不 絕的動力。此外還需強調一點，當今大量的測試皆以手動完成，這並不代表測試者沒有好的自動化測試工具；而是手動測試的過程可以讓測試者察覺以往未考慮到的測試案例或情境。若僅以完成測試案例自動化為實作測試重點，測試者將僅有很少時間使用待測產品，而是把時間花在製作與維護自動化測試。

自動化應該用在重複性工作，而非替代手動測試。自動化測試可能導致虛假的安 全感，尤其是當測試結果和涵蓋範圍不對稱時，因此，測試的涵蓋面要高，又要易於維護，還要不停找出新的測試方式，這需要有好的工具輔助。

到底要進行哪些測試呢？當我們在談論測試的類型時，可用來分類的面向如下：

功能面：使用者需求。
架構面：效能、負載、安全、易用性、管理、整合相容性。
測試層級：單元、元件、模組、整合、系統。
測試施行方式：黑箱、白箱、灰箱

end.