前言

如果沒有好的測試習慣，會造成很多可怕的事情：

• 系統直接死掉，使用人數歸零，被迫加班。
• 舊的東西改不動（不敢改）、新的東西加不進去（太複雜），只好花個幾年重寫。
• 使用者給負評的比例越來越高，卻不知道產品哪裡壞掉。
• 修這個壞那個，洞永遠補不起來，而且每一次都是流程走到很後面甚至是交到使用者手上才知道。
• 還有很多。

所以，身為工程師，我們要盡量完善測試的流程以及涵蓋的範圍。

測試的種類

軟體工程中，測試的種類非常多種，
光是測試的人是否知道 code 的結構或流程就能分為 黑箱測試 與 白箱測試。

也可以用流程來分：單元測試 -> 整合測試 -> UI 測試。

甚至也有直接找使用者來操作，以觀察是否容易上手的 可用性測試。

就算把本來好好的程式碼改壞了，也有 回歸測試。

另外，也有先寫測試再開發的 測試驅動開發（TDD）。

不同公司的測試方式

不同規模的公司與合作模式，有著不同的測試方式：

• 小公司：可能不會請測試工程師，專案經理（PM）可能會做簡單的 驗收測試。
• 大公司：可能會有測試部門專門處理各種大大小小的測試，這種情況下，我們要做的可能就只有上面提過的 單元測試。
• 結案公司：客戶除了要產品以外，也會要求測試。
• 商業合作：如果是商業合作，對方經常只有他們內網才有的環境、他們尚未公開的機種，這時候可能就要盡量模擬對方的環境，然後交由對方測試。
• 資安測試：通常是比較大的公司、需要安全性高的 app、用戶量大的產品，才會做資安測試，會找外面資安/駭客競賽得獎的隊伍假裝駭客，破解產品，這是不同於開發人員與測試工程師的領域。

時程規劃

測試是很容易被忽略的一環，
尤其是公司沒有測試部門、時程壓力大的時候，
所以，我們在產品規劃前期的時候，
就必須保留以下時間：

• 寫各種測試。
• 交付測試、等待測試的過程。
• 修正測出來的一堆問題。
• 給 UI / UX 設計師做 design review（這是很容易被忽略的一點）。

這些時間不是固定的，而是看專案的大小、功能的複雜度來預估。

大致流程

• 專案經理給出 需求書（PRD） 後，測試工程師按輕重等級列出所有需要測試的項目。
• 開發人員 code freeze 後開始測試。
• 測試完成後，按嚴重程度開始進行修復，並反復進行修復與測試。
• 工程師與專案經理共同決定修復程度，因為有些問題很難踩到，卻很難修復，所以可能會先上線再補。

結語

每一家公司、不同專案，甚至每一項功能的開發，都有不同的測試流程與方法。
測試的情境多得數不完，如何在壯大測試的堡壘時，避免沒必要的測試覆蓋率、以及保持彈性也是值得思考的。