提到性能測試，相信大家可以在網上找到很多種不同的定義、解釋以及分類方法。不過歸根結底，在大多數情況下，我們所要做的性能測試的目的是“觀察系統在一個給定的環境和場景中的性能表現是否與預期目標一致，評判系統是否存在性能缺陷，并根據測試結果識別性能瓶頸，改善系統性能”。

本文是《LoadRunner沒有告訴你的》系列的第五篇，在這篇文章中，我希望可以跟大家一起來探討“如何將性能測試應用到軟件開發過程的各個階段中，如何通過盡早的開展性能測試來規避因為性能缺陷導致的損失”。

因此，本文的結構也將依據軟件開發過程的不同階段來組織。

另外，建議您在閱讀本文前先閱讀本系列文章的第三篇《理發店模型》和第四篇《理解性能》。

需求階段

我們不可能將一輛設計載重為0.75噸的皮卡改裝成載重15噸的大型卡車，如果你面對的正是這樣的問題，那么恐怕你只能重做一輛，而且客戶不會為你之前那輛付錢。對于一個已經完成的應用系統來說也是如此。

如果我們在系統結構確定之前就能夠了解到系統的將要面對的壓力，用戶的使用習慣和使用頻度，我們就可以更早也更有效的提前解決或預防可能發生的性能缺陷，也將會極大的減少后期返工和反復調優所帶來的工作量。如果我們預期到系統的容量將會不斷的增長，我們還可以給出相應的解決方案來低成本的解決這類問題，就像上面那輛皮卡，也許你可以有辦法把20輛皮卡捆在一起，或者把15噸的東西分由20輛來運。

分析設計階段

系統性能的優化并不是要等待整個系統全部集成后才能開始的，早在分析設計階段，我們就可以開始考慮系統的技術架構和數據庫部分的優化。

數據庫通常位于整個系統的最底層，如果直到系統上線前才發現因為數據庫設計不合理而導致性能極差，通常使用任何一種方法來優化都已經于事無補了。要避免這類問題，最常見的做法是在數據庫結構確定后，通過工具或腳本向數據庫中注入大量的數據，并模擬各種業務的數據庫操作。根據對數據庫性能的觀察和分析，對數據庫表結構和索引進行調整以優化數據庫性能。

在系統的技術架構方面，要明白先進的技術并不是解決問題的唯一方法，過于強調技術的作用反而會將你帶入歧途。例如：某些業務雖然經常面臨著巨大的壓力，并且業務本身的復雜性決定了通過算法的優化來提高系統的性能收效甚微。但是我們知道用戶對于該業務的實時性要求并不高，并且返回結果對于不同用戶來說是相同的。那么我們完全可以考慮將每次請求都動態生成返回結果的方式改為每次用戶請求都返回一個定期更新的靜態頁面。

另外，所謂“先進技術”通常都會在帶來某一方面改進的同時帶來另一方面的問題，未經試驗就盲目的在系統中加入各種流行元素未必是最好的選擇。例如ORM可以提供一些方便，但是它生成的SQL是未經優化的，有時甚至比人工編寫的SQL效率更低。

最后，要知道不同廠家的設備性能是不同的，而且不同的硬件設備搭載不同的操作系統、數據庫、中間件以及應用服務器，表現出來的性能也是不同的。如果有足夠的資源，應當考慮提前進行軟硬件平臺的對比選型；如果沒有足夠的資源，可以考慮通過一些專業的組織或網站來獲取或購買相關的評估報告。

編碼階段

一片樹葉在哪里最難被發現？——當這片樹葉落在一堆樹葉里面的時候。

如果你只是在系統測試完成后才開始性能測試，那么即使發現系統存在性能缺陷，并且已經有了幾個可供懷疑的對象，但是當一段因為使用了不當的算法而導致執行效率很低的代碼藏身于一個龐大的系統中時，找出它是非常困難的。避免這種情況出現的方法是盡早開始核心業務代碼的性能測試，重點集中在對算法和實現方法的優化上。

另外，及早開始的測試也可以幫你更容易找到內存泄漏的問題。

測試階段

產品終于交到我們手上了，搭建測試環境，設計測試場景，執行測試，找到系統的最佳并發用戶數和最大并發用戶數，將系統進行分類，評判系統的性能表現是否滿足需求中定義的目標——如果有需求的話 ^_^

如果發現系統的性能表現與預期目標相去甚遠，則需要根據執行測試過程中收集到的數據來分析和識別性能瓶頸，優化系統性能。

在這個階段還有很多值得我們深入思考和討論的東西，在本系列后續的文章中，我們將會更多的關注這一部分的內容。

維護階段

維護階段通常遇到的問題是需要在實驗室中模擬客戶環境，重現在客戶那里發現的缺陷并修復缺陷。相比功能缺陷，性能缺陷與某一具體環境和場景的關聯更加密切，所以在測試前需要檢查生產環境中各服務器的資源利用率、系統訪問日志、應用服務器的日志、數據庫的日志。如果客戶使用了專門的系統來監測各個服務器的軟硬件資源使用情況的話，檢查該系統是否記錄下了軟硬件資源的異?；蛘呔?。

原文轉自：http://www.anti-gravitydesign.com