在這篇文章中，我將探討《軟體測試實務：業界成功案例與高效實踐[Ⅱ]》的第三章——桌面應用程式效能測試的規劃與實踐。這一章節深入分析了如何有效地規劃和執行桌面應用程式的效能測試，並提供了實用的策略和方法。
標題中的「桌面應用程式效能測試」討論的情境是安裝防毒軟體前與安裝後，是否會影響使用者的一般操作。例如：開網頁時間延長、看影片延遲或玩遊戲變慢等情境。
當系統在開發環境上運行正常且穩定，但在客戶端運行一段時間後，客戶抱怨系統變得緩慢且申請單無法正常送出時，我們需要考慮系統的效能。效能問題可能與特定環境或資料量有關。當我們無法明確定義「效能好」時，可以逐步進行測試以確定效能的標準。
要如何定義效能好呢?
可以依據自己站的角度，也就是利害關係人是誰，來決定什麼叫做效能好。
利害關係人有那些呢?
每個利害關係人所在意的事情不同就會又不同的效能好的標準。
每個利害關係人關心的事情不同，因此效能好的標準也不同。為了明確定義我們的最終目標，我們需要確定自己的利害關係人是誰。這樣，在內部和外部討論時，我們才能更好地溝通和協調，確保目標是合理且可達到的。
有了這些目標就可以開始進行實踐計畫了!!!
依據討論的目標，要明確的定義出來。
第一步驟：定義明確的範圍與目標
為了確保我們的計畫朝著正確的方向前進，我們需要明確定義範圍和目標。要注意的一點是目標盡量數值化，可以提供給利害關係人進行參考，系統條件下是穩定的，也讓利害關係人知道最少的環境資源是多少，也確保系統在不同情況下都能站得住腳。
第二步驟：測試案例設計
我們要依據自己的目標把系統功能一一拆解出來，列出適合的測試案例，測試案例要明確的定義測試步驟與所需的測試資料並且列出範例，讓之後接手的同仁可以清楚的知道這個測試案例在測試什麼。
良好的測試案例設計有助於滿足利害關係人需求。
第三步驟：測試環境建置
為了確保系統在不同使用量下的穩定性，我們需要建立適合的測試環境，一天2,000筆的案件送出與一天200筆的案件送出使用的資源強度也不同，如何建置出適合的測試環境可以依據目前客戶平均的使用量來當基準點，來確保資料的準確性與可靠性。
第四步驟：執行測試案例
在測試過程中，我們需要詳細記錄每個測試案例的結果。這包括錯誤訊息、Log檔等。為了避免測試誤差，我們會對同一個案例進行多次測試。
這樣有助於確保系統的功能正常運作。
第五步驟：分析測試結果
在進行測試時，我們可以使用簡單的統計方法來確認目標是否達成，並且可能發現其他異常行為。以下是一些常用的統計指標：
平均數：代表資料的中心趨勢。
中位數：反映資料分布的集中程度。
眾數：顯示出資料的常態值。
最大值&最小值：測試結果的極端狀態。
標準差：評估資料分散程度。
統計完後先確認標準差是過大，如果標準差數值很大我們就要看一下測試結果裡面是否有極端值，極端值可能會影響後續的統計判斷，所以可以將其移除。
接著，我們可以計算效能結果。
*基準值的取得方法，本章中以防毒軟體為例就是抓未安裝防毒軟體時測試案例的執行時間。(在與安裝後的測試值做比較)
*測試值的取得方法，可以透過自動化測試紀錄每個測試案例的操作時間或者每個小功能執行的時間來當測試值。
有基準值，我們可以使用以下兩種比對方法：
1. 數值比對 → 測試值-基準值
2. 百分比比較 → (測試值/基準值)-1
沒有基準值就看測試值是否符合第一步驟所設定的目標。
小小讀者認為：
當需要比較功能在更新前與更新後的差異時，更新前的測試結果可以作為基準值，更新後的結果則為測試值。例如，想測試網頁頁面內容含附件與不含附件時的等待時間差異。這種情況下，測試值通常用來確認每次更新後，原本的功能效能是否有所改善或下降。
第六步驟：改善與驗證
效能測試的最後步驟，如果在第五步驟發現測試案例的結果未達到第一步驟的目標，我們必須進一步分析並利用第四步驟收集到的資訊進行改善。必要時，我們會重複執行第四步驟和第五步驟，以收集更多資訊進行改進。在驗證過程中，我們也會回到第四和第五步驟，確認修改後的系統是否符合我們所期望的效能標準。
遇到效能瓶頸時...
1.確認問題是可重現的，可以透過重複執行測試案例或測試步驟收集必要的資訊。
2.用適當的工具縮小範圍，找到根本原因後給予修復。
最後重回第四步驟和第五步驟，透過一個完整的測試循環來驗證我們的修改，最終目標是達成在第一步驟所設定的目標。
小小讀者心得：
小小讀者知道效能測試很重要，但在進行效能測試時，常常不知道如何規劃範圍。從這篇文章中，可以很明確地了解到可以從利害關係人的角度著手，確認範圍後就可以開始規劃測試腳本等作業。此外，測試後記錄下來的測試值也可以用來計算系統操作的平均時間，這些紀錄的時間或許可以作為產品的基準值。
