為什麼軟體測試很重要呢?

為什麼軟體測試會受到重視, 主要可以從以下面向來說明:

1. 節省費用

由前面的資料可以知道, 軟體測試所佔的費用大約是 15-25%, 如果我們不想讓這個比例變高, 便要好好管理與投資, 以更有效率的方式去進行, 否則就會付出慘痛代價.

2. 安全

很多金融業或是賺錢的產品, 他們常常會被駭客盯上, 利用軟體的弱點(vulnerability), 來竊取客戶的資料; 或者是造成營運的中斷, 使得企業蒙受重大的損失.

3. 品質

對於熱門或者是成熟的產品, 是禁不起有嚴重的問題. 即使是小問題, 如果個數很多, 也會造成很不好的印象.

4. 客戶滿意度

企業經營的目的就是要賺錢, 因此推出的服務或是產品, 需要讓客戶有高的滿意度. 高品質便是考量滿意度時的重要因素.

圖 3-1 軟體測試很重要的原因

什麼是軟體測試呢

軟體測試是什麼呢? 往往大家有不同的說法, 這裡我找了幾個大佬的話來讓大家參考, 從他們的說明中, 你可以知道軟體測試的重心會在哪裡.

1. Glenford Myers

Glenford Myers 是何許人也呢? 有他寫過一本”The art of software testing”, 這本書可以說是黑箱測試的聖經, 大多數提到黑箱測試的書籍, 內容都是參照這本書.

他說到軟體測試是“為了找出錯誤 而執行程式的程序”. 因此重點在找出錯誤, 如果沒有找到錯誤, 即使你的作法很炫很先進, 都會令人質疑它的效果不彰.

2. Boris Beizer

Beizer 他寫了一本”Software testing techniques”, 提到了大量白箱測試的方法, 可以說是白箱測試的鼻祖. 基本上, 沒有任何書在描述白箱測試的原理, 可以比這本更詳細和更完整.

他認為軟體測試是”設計與執行測試的動作”. 測試要做得好, 需要精心的測試, 才容易抓到 Bug. 並且在執行測試的過程, 也需要思考, 如何才能以較小代價執行, 在有限的時間內去找到較多的問題.

3. James Whittaker

Whittaker 是之前是微軟的首席測試架構師. 而微軟是世界上在軟體測試方面, 最專業, 最大的軟體開發公司, 他的經驗和能力是值得和學習.

Whiitaker 說到軟體測試是”用來檢視是否符合(需求)規格, 並於設定的環境內, 執行軟體系統的程序”. 及早確認需求, 讓大家對需求有共識, 是軟體測試過程中非常關鍵的事情. 在測試環境的管理, 如何讓大家有一致的環境, 並且能夠快速安裝, 將會有不同的測試成本.

4. IEEE

IEE 這個組織, 相信大家很清楚它的地位和權威. 它定義了軟體測試是”於特定的條件下操作系統或元件, 觀察或記錄 結果, 以評估系統或元件是否有某方面的問題”

這裡你可以知道測試的執行, 除了觀察和記錄結果外, 測試人員很重要的一件事情, 就是要評估這個測試結果. 測試人員不該只是告訴開發人員你的系統有問題, 最好還能幫助開發人員知道哪裡可能是發生的原因. 這裡就會需要評估和分析的功力. 他需要對系統內部運作有了解, 可以讀懂開發人員的 debug log, 或是看懂受測的程式碼.

誰來測試軟體

在知道軟體測試是什麼後, 接下來常見的問題, 就是誰合適來進行軟體測試. 基本上大約有三類人:

1. 開發人員
   他們總是會客氣地測試, 因為程式是他們寫, 自己的小孩總是不敢用力打. 並且還有偏見, 認為自己的小孩總是對的.

他們的測試是以釋出為目的. 也就是希望做完後要趕快交付出去. 重點是要能出去, 而非在意品質, 或是客戶會不會覺得好用.

2. 測試工程師
   測試人員在進行測試時, 總是想盡辦法破壞系統, 因為這個又不是他們寫的, 並且他們可能的 KPI 是要以找到越多問題越好. 因此會傾全力去找碴, 絕對不會手軟.

測試人會從品質的角度出發, 希望受測軟體能夠具備一定的品質水準, 而非要趕快交付出去

3. 客戶
   客戶的想法很單純, 想確認是否符合自己的需求, 是否能幫助自己解決問題, 或是自己常用的部分沒有問題.

如果他們是驗收單位, 他們將看看是否滿足驗收標準, 是否和 spec 上寫的大致相同.

從上面的敘述可以知道, 不同角色在意的事情不同, 他們有各自不同的盲點. 因此, 如果只有單一角色去做測試, 不容易考慮很完整, 會建議在不同階段, 讓不同角色來進行測試, 讓測試的完整性可以被實現.

測試原則

在測試的過程中, 都應該追朔到需求文件, 讓任何測試都是有所本, 否則開發人員會抱怨你這個是亂測. 但是需求文件也無法涵蓋所有狀況, 這邊就需要及早和 PM和 開發人員測試, 這樣的預期結果, 是否是大家都有共識的.

另外, 在做測試計畫的時候, 一開始還是要先有個計畫書, 讓大家粗略知道我們要進行哪些測試活動. 但是因為這是在專案最早期制定的, 這時候對專案的資訊掌握度最低, 隨著專案的展開, 越來越了解受測軟體時, 需要調整測試計畫. 所謂 Plan is nothing, planning is everything. 我們要有計畫, 但是還需要持續規劃.

對於所有測試狀況, 如果我們都需要處理, 他的複雜度或是排列組合可能會超出我們能負荷的. 並且專案都是有時間限制的, 也不可能無限制地去執行. 因此我們需要利用柏拉圖法則 (20/80法則), 將時間花在風險最高的地方, 而不是全部都去測試.

我們在進行測試時, 應該先從小地方開始, 或者是從單一功能開始. 一方便比較好進行, 另一方便如果找到問題時, 也比較好釐清問題在哪. 如果小地方或是單一地方穩定後, 之後要測大功能或是組合性使用, 才不會一下就爆, 並且問題也比較可以鎖定在界面處.

好測試的特性

哪怎樣才算是好的測試呢?測試個案不應該太冗長, 如果步驟太長, 或者是同時間要測試的場景太多, 會導致測試過程中容易出錯, 或者是檢查遺漏. 但是也不能夠太簡單, 這樣會導致測試個案的數量增加很多.

打過棒球的人都知道, 打擊率三成以上, 已經是為強打者, 要能夠四成以上哪簡直是神. 同樣地, 在測試方面也是如此, 測試個案不容易可以抓到 bug, 如果大多數的測試個案都可以抓到 bug, 那不是測試人員厲害, 應該是開發人員需要檢討. 但是, 我們還是希望在開立測試個案時, 還是要考慮抓到問題的機會高不高, 如果有些場景不容易出錯, 或者是出錯後所帶來的風險也不高, 可能就不見得需要測試.

另外, 執行測試個案的代價也需要考慮, 所找到的 bug, 是否值得我們花很多精力去準備測試資料, 執行環境, 或者輔助工具呢？如果不值得, 是否有比較簡單的方式呢?

測試人員要測什麼?

在進行軟體測試時, 很多人都以為只要進行功能測試, 也就是確保軟體功能運作正確就好, 但事實上要檢查的面向很多, 並不是只有正確性而已.

完整性(Completeness)
要確保整個需求都有被測試給涵蓋到, 每個細節都需要被測到.

正確性(Correctness)
測試人員要確認受測軟體能夠正確無誤地被執行, 遇到一些例外狀況, 也能處理很好, 可優雅地結束並且資料沒有損壞

可靠性(Reliability)
受測軟體要能長時間穩定執行, 像是 24x7 小時全年無間斷運作.

相容性(Compatibility)
確認受測軟體能夠在其支援的作業系統, 資料庫, 或是瀏覽器, 都能夠搭配順暢, 運作良好

效率(Efficiency)
受測軟體要能執行快速, 即使在巨量資料, 或者有大量用戶同時使用, 系統也可以運作適宜.

可使用性(Usability)
受測軟體除了功能方面要運作正確外, 也要有好的用戶體驗, 不要動不動就讓用戶誤解軟體的用意.

可攜性(Portability)
當你將程式從某個應用環境遷移至另一個應用環境時, 現有的程式碼還能夠重複使用, 毋需重新寫過.

可變比例性(Scalability)
系統能夠因應資料或處理的工作事項增加, 所具備的潛在擴充能力

軟體測試的挑戰

1. 溝通是傳話遊戲

測試基本上要確認客戶的需求是否被正確的實踐. 一開始是客戶描述給 PM, PM 再說給 SA, SA 再跟開發人員解釋, 最後開發再跟測試說明. 中間這一連串的傳話, 很容易就會失真.

圖 3-2 測試很容易變成傳話遊戲

2. 缺乏資源

軟體開發的資源一向都很緊張, 光是開發人員都不太夠用, 更不用說要有專職測試人員, 往往都是開發人員要來做測試的工作.

此外, 不只人員短缺, 在進行測試時所需要的軟體或是硬體, 往往也是不夠. 像是 app 測試時, 本來需要多種機型或是作業系統, 但是都只有基本機子可用. 對於複雜的雲端環境或是網路裝置, 大多也只有 production 一套, staging 環境可能就退化成陽春版, 或者甚至沒有可以測.

3. 變化很多很快

眾所皆知, 在開發過程中, 客戶常常會修改需求, 或者發現他自己想錯了. 老闆也常常忽然靈機一動, 不斷地落下隕石, 因此開發人員常需要在短時間內, 趕快把程式寫完.

另外除了外面需求外, 還包括開發人員自己也會作怪, 有時候可能會進行重構, 也可能是自己發現了一些測試人員沒發現的問題, 所以自己便動手修改. 這麼多變化, 測試人員都要自己吃下去.

圖 3-3 隕石太多導致測試很難

4. 時間有限

正如前面所述, 需求不斷變化, 外加開發人員自己不斷修改, 因此測試人員要測試的東西非常多. 本來這些有足夠的時間還是可以處理的, 但是在排時間時, 大多是交付時間已經確定, 扣掉開發所需時間, 剩下的就是測試時間. 所以這裡並沒有考慮測試做不做得完, 而是把時間留給開發, 測試只能用剩下的時間.

另外, 最怕的是最後一刻的修改, 這時候往往幾乎沒有充分時間進行回歸測試, 並且對於修改的東西掌握度也不高, 因此, 測試的進行是難上加難.

5. 缺少文件

在開發過程, 通常需求文件都是比較簡單的描述, 但也可能接近於 0. 至於開發的設計文件, 往往是沒有的, 就算要有也是整個開發完畢之後, 開發人員才會有空去寫.

在這樣的狀況下, 測試人員可能是靠口耳相傳, 或者是自己很神奇的通靈術, 想盡各種方法去了解受測軟體, 因此這樣要能測好, 真的是件很神奇的事情.

圖 3-4 中間這些文件往往是沒有

6. 測試不充分

目前大家在進行測試時, 多數測試人員都是在做功能測試, 而開發人員就是寫寫 unit test, 勤勞一點的就再多點 E2E(端到端)測試. 其他種類的測試就沒有進行. 由前面的說明可以知道, 我們還有 安全性, 可變比例性, 效率等等, 一堆不同測試活動要做.

圖 3-5 往往以為做了功能測試就是做完全部測試

7. 測試環境不穩定

為了要有準確的測試結果, 我們需要準備獨立的測試環境, 來確保不受到環境因素所影響. 也就是不要有在我這邊可以, 在你那邊不行的狀況.

但是為了要進行測試, 受測軟體需要常常更新, 只要開發人員有修復. 另外, 因為受測系統的異常狀況, 導致測試環境也可能常常受到破壞. 這些都需要測試人員不斷去維持一個正常且乾淨的環境, 這個成本其實是不小的.

8. 相容性的組合太多

受測系統所在的環境通常不少, 例如可以存在的作業系統, 所支援的瀏覽器, 或是可以連接的資料庫, 這些組合可能可以數十個到數百個. 再加上如果測試個案的數目有數百個到數千個, 這樣乘出來的數目就非常驚人. 測試人員可能可以跑完一次, 但是如果需要多次回歸測試, 那是不可能的任務. 這些組合沒有去測, 我們也不好意思宣稱我們支援這麼多環境, 這樣是無法對得起客戶的.

9. 測試數據很難準備

測試要測得好, 找對測試資料很重要. 同樣的場景, 輸入 (0,-1) 和輸入 (2,3), 前者可能會找到問題的機率比較大.

因此, 你要測試時, 測試資料不能夠只是單一狀況, 尤其都是 happy path 的狀況, 需要有不正確的資料. 除了不正確外, 還需要像真實狀況, 不像真的會發生的場景, 那測試了也是白測.

另外, 資料的產生最好也要能自動化, 可以快速產生, 這樣測試才能比較方便進行. 有時候為了像真的, 可能需要引用真實資料, 但是要去識別化, 避免從這些資料可以猜出真實用戶在做什麼事情. 這些都是不容易做到.

10. 好的測試人員不好找

在台灣測試人員不好找, 因為能力強又會寫程式, 大多會跑去當開發人員. 不會寫程式的, 如果腦筋不夠多元, 不會想到一些不同的狀況, 測試也會做不好.

就算有合適的人選, 台灣這邊也常常無法給出好的薪水, 因此人才常常會跑去國外, 或者是外商. 中小型公司或是傳產, 很難選到好人才.

此外, 就算進來之後, 主管或者開發人員容易不太尊重他們, 總認為他們的工作很簡單, 沒有太多價值. 更不用說要對他們進行培育, 多數的測試人員只能私下自己默默去學習. 所以基於上述原因, 願意當測試人員的真的少之又少.