最後來談談軟體的測試與維護, 軟體版本發行後, 接下來就是進行軟體的測試並為下一個發行版本做準備.
最後來談談軟體的測試與維護, 軟體版本發行後, 接下來就是進行軟體的測試並為下一個發行版本做準備.

版本的發行有內部發行與外部發行. 內部發行指發行給軟體開發團隊的成員以供其做單元或整合等測試, 外部發行則是發行給測試品保部門及其它單位.

通常, 品保部門的軟體測試都有一定的循環, 一個完整的循環可能需要三天到一個禮拜（視測試規模而定）, 如果再加上硬體與機構的測試就有可能拉到兩到三個禮拜（如穩定度測試，高低溫測試, 環測等都挺耗時的）, 所以對外發行的版本穩定度很重要, 否則就會浪費了兩三個禮拜的循環了.

之前建議一個禮拜就出一版(Weekly build), 這適合作為內部發行, 提供給軟硬體的內部測試即可. 外部發行頻率則可配合測試品保部門的測試循環, 兩到三週發行一次即可. 因此可以在內部Weekly build連續兩到三個版本中挑選一個較穩定的版本來發行. 有分成內部外部版本的另一個好處是, 可以先在內部經過一段時間測試後, 確保一定的穩定度再發行外部版本.

接著來談談測試, 在"軟體團隊內"的測試有單元測試(Unit test), 整合測試（Integration test), 穩定度測試（Stability test), 效能測試（Performance test), 耗電量測試（Power consumption test)等等.

在前面有提到, 軟體部門內的測試與品保部門的測試有所不同. 軟體部門的測試比較偏向技術面, 略述於下:
(1)單元測試: 針對個別模組的測試, 最好包含所有功能. 實做的時候, 建議對每個模組做分類, 編碼, 而每個功能都有一個Test Case, 也有一個編號, 配上模組編號就有了維一的編碼. 基本上四個碼應該就足夠, 前兩碼為模組編號, 後兩碼為Test Case 號碼, 由 00~FF 有256碼, 全部就有 256*256 = 65536 個 Test Case 可用. 這些Test Case 都要寫成Document. 測試完也都要附上報告, 將隨Release Note 一起發行.
內容部分, 建議一次完整的單元測試, 最好能在半小時內完成, 最多不要超過一個小時. 所以如果Test Case 太多或太耗時, 就要有所取捨. 不要讓工程師花費太多時間在單元測試上.

(2)整合測試: 跨模組流程的測試. 整合測試可大可小, 小的包含一些基本的測試, 如開關機等. 大的則可包含所有跨模組功能的測試.

(3)穩定度測試: 針對系統的穩定度做測試, 通常每個平台, 作業系統都會提供自動測試的程式, 進行亂數隨機的功能執行測試, 如Windows mobile, Wince 的 Hopper, Android 的monkey, Windows 或 Linux 上就更多這種tool了, 當然也可以自己撰寫壓力測試的程式.

(4)效能測試: 針對性能做測試, 比如檔案系統的讀寫速度測試, Wifi/BT 的傳輸速度測試, 或是直接執行一 些Benchmark的軟體. 確保新的版本效能不會突然降很多, 降很多就應該有問題.

(5)耗電量測試: 各種運行腳本下的耗電量測試, 比如全速運行, 休眠/待機狀態, 播放影片, 播放MP3 等等. 視你的設備功能而定. 以確保新版本不會突然耗電量大增.

談完版本發行和軟體測試, 那每種發行版本各該做什麼測試呢? 建議如下:
(a)Daily build: 有修改的工程師針對修改的模組做單元測試. 系統整合工程師做簡單的整合測試.
(b)Weekly build: 完整的單元測試, 完整的整合測試, 耗電量測試.
(c)對外發行: 完整的單元測試, 完整的整合測試, 穩定度測試, 效能測試, 耗電量測試.