軟體測試執行階段, 是整個測試過程時間花費最久, 還是最關鍵的階段. 因此有些準備工作要做好, 之後才會比較輕鬆.

1. 受測系統 (build) 的管理

建構系統 (Build system) 應該要是一個獨立的環境, 並且可以確保每次若是要建構同一版本時, 都可以建構出相同的受測系統.

通常我會建議需要需要週期性產生 build. 工程師可能會說程式碼沒有改為什麼要建構呢? 那就是代表大家平時不會頻繁 check-in 程式, 這不是一個好的習慣. 會建議每個小時大家都要進版, 建構和跑自動化測試. 如果無法這麼頻繁進版, 每天一到兩次應該要是基本盤.

每當開發人員修復 bug, 要記得趕快 check-in 你修復的代碼, 並且要趕快把它給建構出來, 這樣測試人員才能很快去確認是否真的修復, 以及是否有改 A 錯 B 的狀況. 這裏如果不及時, 一方面測試人員沒有東西可以驗證, 另一方面如果有改 A 錯 B, 會導致很後面才發現.

當 build 被建構出來時, 也需要有些檢查的機制. 像是 build berification test (BVT, 這個是微軟提出的), 快速對他做個確認.

2. 測試環境

測試環境對於測試執行來說非常關鍵, 很多錯誤都是因為環境不同, 導致會產生出很多神奇的錯誤. 我想你應該聽過這樣的笑話: 開發人員常說在我這邊會通過, 可是測試人員卻說在他那邊卻發生問題. 因此, 測試環境要和開發環境分開, 這會是第一件要做到的事情.

這些我們來看看有些環境需要準備, 這裏可能要準備的環境有以下種類:

• 自己用: 自己在開發端先進行測試的環境
• 公用: 可以是開發人員共用, 或是測試人員共用環境
真實: 可以是實體機器
虛擬: 可以上雲, 或是虛擬機器
• staging: 模擬真實運作的環境
• production: 真實運作環境

針對這些用途, 我們需要安裝測試環境, 那要裝哪個環境呢? 通常來說, 我們不會剛好只有一個環境要支援, 你可能要支援多個作業系統, 多個瀏覽器, 或是多個資料庫系統, 那你要選擇哪一個? 還是每個都要裝？

一般來說, 在自己用的應該是選擇最常見的, 但是在公用和 staging 上面, 應該是要包含大多數用戶環境組合. 但是在經費和時間的考量下, 確實不容易都包含. 我們可能會用 pairwise testing 的作法, 去選擇合適的組合來測試. 這邊大家可以自行去查閱一下什麼是 pairwise testing.

測試環境一般來說要能很快重置, 因為當測試完後, 測試環境便被污染, 若是要測不同的場景, 便需要重置.

在部署測試環境時, 建議要部署工具搭配, 並且整個過程最好都是自動化, 通常在裝系統時, 步驟都很繁瑣, 很容易會漏掉或者是打錯. 所以自動化是比較保險. 但是這也是需要花時間去做, 也是有代價的.

除了環境外, 測試資料也可能伴隨環境不同, 需要有不同的內容. 另外 import 這些資料, 還需要確認是否正確, 是否有損毀. 並且要有備份, 因為有沒有測試資料, 對測試來說是差很大.

有些受測系統是在有網路的環境下執行, 因此, 我們需要準備相關的網路環境. 這個網路環境可能是需要獨立的網路環境, 避免過程中, 因為別人的介入, 測試過程受到干擾, 導致測試結果不正確.

另外, 很容易忽略的是第三方軟件, 通常它的版本很重要, 是否是最新版, 或者是要支援哪些版本. 若是哪些版本有安全弱點, 也需要加以更換.

3. 測試成員

因為測試執行是整個過程中最耗人力的部分. 因此在這個階段是需要確保人手是可以到齊的.

為什麼會這樣說, 一般測試人員都是共享的, 或是人數非常少, 或者他們還正在測試其他專案, 或是上一版本的專案, 所以在專案起始階段, 多數可能無法全部到位.

在前面的章節有提到, 等到需求和設計階段, 測試人員可能會逐漸到位, 他們漸漸從上述的那些事情中脫身. 但是也可能很慘, 都是還是有事情, 沒有到測試執行階段, 別的專案, 或者是主管, 是不會放過他們的, 因為他們會認為測試人員在測試執行時才有在做事, 其他時間他們都是沒事做的.

因此, 他們可能在早期真的不會出現. 這樣的話, 我都會建議至少參加需求和設計的討論. 為什麼呢? 如果前期都不參加, 等到測試執行階段進來, 他們馬上就可以工作嗎? 當然是不行, 這時候他們需要花時間研究受測系統的需求和設計. 在時間壓力下, 外加沒有人可以教或是討論, 他們能夠了解多深呢? 這樣的測試能夠做得好嗎?

如果他們至少參加需求和設計的討論, 就不會對受測系統了解是 0. 至少有些基礎知識, 這時候再去看受測系統的需求和設計, 才有機會比較快, 懂得比較深入一些.

從上述的說明也可以了解, 測試是一個動態過程, 人員上可能會來來去去. 所以在任務的安排上, 從來都不會是固定的, 你會不斷調整和分配.

4. 是否可以開始測試

對於是否能夠開始進行測試執行, 有些事情需要進行:

(1) 做完的定義 或是 測試進入條件

如果是敏捷開發, 通常會定義做完的定義 (Definition of Done). 讓團隊知道如果是功能完成, 有哪些事情要做到. 例如

完成的 code 要 check-in
unit test 要通過, 如果有錯需要修復
靜態測試需要跑過
設計文件需要更新

如果你是一般瀑布式開發的團隊, 這時候會有測試執行的進入條件. 這通常會在測試計畫規格書中說明. 內容跟上面做完的定義差不多.

(2) 冒煙測試 (Smoke Testing)

冒煙測試 (Smoke Testing) 源至於硬體測試, 當硬體完成時, 最快確認是否可以開始測試的方法, 就是直接插電. 如果會冒出燒焦味道, 就代表這個硬體有問題. 所以他的目的就是要做最最基本的測試, 看看這個東西的品質是否有基本水準, 可以拿來測試.

所以在開立測試個案時, 事先會開立好哪些是屬於冒煙測試的案例. 並且這些個案通常會自動化. 通常他們的涵蓋範圍廣, 但是測試的深度比較淺. 例如, 針對防毒軟體, 它的冒煙測試可能是

安裝防毒軟體
更新病毒碼
按下掃描病毒

這些是屬於最基本的事情, 如果這些都不能通過, 就不需要進行後續的測試了.

(3) 探索性測試 (exploratory testing)

正如上面提到的, 冒煙測試一般都是會自動化. 但是受測程式剛寫好, 開發人員可能還來不及寫這個自動化. 測試人員對受測程式也不熟, 所以也還沒有寫. 因此, 很多公司在進行這一段都是手動測試.

另外, 不少公司在開立測試個案時, 也沒有特地挑出哪些測試個案是冒煙測試要用的, 如果是某個人要去手動執行冒煙測試, 他還需要把所有測試個案都看一次, 這個時間可能不短. 因此, 有種方式就是進行探索性測試. 給這個執行者有一定的自由度, 但不是亂測, 而是針對受測程式的主功能, 去確認他是否已經準備好, 可以進行後續大規模的測試. 通常會有時間的限制. 大約 30 分鐘內要確定.