軟體無論是新的還是現有的, 都要經過各種測試, 例如: 功能測試, 效能測試, 安全性和冒煙測試等等. 組合運行這些測試, 來確保軟體發佈時沒有錯誤, 並可供商業/企業使用.

因此, 在測試執行過程中, 需要涵蓋測試過程的多個面向和多種活動, 哪我們可以怎樣把他整合進去

持續整合

1. 內容
   在持續整合面向上, 會包含以下事情
   • Build
   • Unit Test
   • Smoke Test: 主要是測試大功能, 確認是否可以進行後續的測試
   • 靜態測試: 使用類似 sonarqube 等工具, 確認安全性問題.

2. 頻率
   每天至少一次
   或是每次 check-in 時也要

3. 時間長度
   如果需要每次 check-in 都進行的話, 時間長度需要在 3 到 5 分鐘內, 否則開發人員會沒有耐心去執行.

圖 21-1 持續整合

功能測試

1. 內容
   新完成功能, 即時進行, 讓RD可以盡快得到回饋

2. 測試策略
   • 因為不可能測試所有的支援環境, 在這邊的話, 先針對最常見環境平台測試, 單一平台確認沒問題後, 再考慮在其他環境組合測試.
   • 驗證順序
   先確認邏輯/行為
   詳細功能
   UI
   功能間組合使用

這是以漸進式的方式, 來確定受測產品的功能. 一方面是風險高的先確定, 另一方面, 如果來不及測試完畢, 後面剩下的也比較沒影響

下圖中, 大約拆解出三輪測試, 並且在第三輪測試開始之前, 程式碼必須凍結, 不能夠再修改, 這樣才能進行最後一輪的測試.

圖 21-2 功能測試

回歸測試

這邊主要是要進行持續測試, 一方面程式會持續修改, 就會有機會改 A 錯 B, 所以要一直確認. 另一方面, 不是所有部分, 我們都開立測試個案去涵蓋, 對於有些部分要檢查, 但是沒有測試個案時, 我們需要進行探索性測試.

1. 持續回歸測試
   程式有修改就要進行, 如果這部分可以自動化執行會很省成本. 但是一般來說都是先從smoke test(確認 ready for testing), 再到主功能, 最後細部功能. 如果能能持續擴大自動化涵蓋的範圍, 對確保產品品質越有幫助.

不同時間有不同策略, 例如
• 下午 2 點, 單一平台, 主功能自動回歸
• 下午 6 點, 所有平台, 主功能自動回歸
• 半夜, 所有平台, 所有功能自動回歸

但是如果你自動化的測試個案個數沒多少的話, 那就每次都跑全部吧.

2. 探索性測試
   這是以快速和低成本方式在進行. 如果你想要在短時間, 抓到最多 bug, 並且又不想花很多時間開立測試個案的話, 這招絕對是首選.

哪些狀況可以使用呢, 以下是常見的狀況
• 確認修改影響到誰
• 確認哪些地方也有相同問題
• 確認難以重現的 bug 要如何重現
• Smoke test 要用手動方式
• 第二輪或是第三輪測試, 可以換不同人確定原先測試人員的品質

圖 21-3 回歸測試

系統測試

從前面的章節可以知道, 系統測試要進行的測試包含: 整體系統的功能測試, 和功能性的測試. 這裡我們提的是偏向非功能性測試的部分. 像是易用性測試, 安全測試, 效能測試, 壓力測試 和 負載測試等等.

在開發中期, 你就需要開始規劃, 等到開發快結束時, 就可以進行設計, 環境建置, 準備相關測試資料. 接著就是可以執行測試, 有些不是只有執行一次, 像效能測試, 可能是一個長期調整的工作, 會不斷執行, 直到大家滿意或是專案時間結束為止.

圖 21-4 系統測試

測試執行兩階段

測試執行的過程, 大致可以分成兩種重點, 如下面所示

前半段：發現問題
• 需要發現 70% 以上錯誤
• 強調深度
最容易發現錯誤的地方
容易找錯的測試個案要先執行
• 有執行障礙要及早排除

後半段：降低風險, 驗證需求
• 從客戶角度出發
對用戶有用的場景要多測
• 強調廣度
各種不同型態的測試
各種不同的環境組合

圖 21-5 前後期不同重點