在談到怎麼做效能測試之前，要先明確為什麼要做效能測試。通常，效能測試的目標主要有以下幾種：
1：賣點。和別的產品相比，效能指數有較大的提公升。
2：和自己的老闆本相比，無明顯下降。
3：某些產品，效能指標是作為requirement，那麼這類產品，效能測試用來確認滿足使用者需求。
系統的效能在低負載的情況下可能對使用者沒有什麼影響，但是當負載提高後，效能會影響到使用者的體驗，甚至影響到使用者的業務。所以無論以什麼為目的，效能測試都是一種必須要做的系統測試型別。
第一講：真實的環境
我想大家都知道測試環境要真實，越貼近使用者的環境，測試結果就越可信。但是基於各種因素，通常測試環境和使用者環境都會有所不同。關鍵是我們要認識到這些不同點，然後分析這些不同點會對我們的測試結果產生什麼影響，測試環境下得到的結果是否有說服力。
第二點：真實的負載
第三點：為測試建模
既然測試環境和測試負載對於我們的測試極為重要，那麼我們如何確定我們對這些因素的考慮是正確的？通過對產品建模和評估，可以在設計的時候就有個直觀的概念。同時可以在真正測試的時候根據建模的資料進行驗證。結構良好的建模一方面可以為今後產品的效能做出評估，同時也可以通過分析得到可信度較高的在各種情況下的產品效能（如果什麼，效能如何？如果什麼什麼，會如何？），避免度所有情況都去做effort很大的performance test。
第四點：投資工具，但不要過度
系統測試中使用工具是不可避免的。工具的種類可以分為以下三類：
1）商業工具：這類工具通常具有大而全的特點。但是費用較高，而且沒有實現細節，不利於定製一些特別的需求。
2）開源：這類工具目前逐漸走向成熟，基本商業軟體可以實現的功能都可以找到開源軟體來替代。開源軟體免費：），有原始碼，可以做部分的定製。
3）自主開發：不用說了，特點就是自由度最大，缺點就是effort較大，特別是工具開發初期。
不要一開始就定下來選擇這種或者那種工具來進行測試。比較好的做法是：
1）design system test：給出測試設計文件，測試策略，測試資料等。
2）了解對於測試工具的需求以及限制
3）列出候選的工具list，然後根據2）中的列表，逐一評價工具優劣
4）選擇工具，並且drill run（有可能的話）
雖然open source 的工具沒有購買費用，但是也不能濫用。主要有以下幾個原因：
1）open source的工具種類繁多，很容易造成不同的team是用不同的工具來實現類似的功能。一方面浪費了學習的時間，一方面增加了不同team之間人員toi的開銷。
2）open souce不收費，自然也沒有人來做maintain。如果工具發生問題，只能自己解決。
3）open souce工具沒有廣告:)，需要自己去尋找
第五點：盡早開始系統測試，並且持續run
應該盡可能早的考慮效能、負載、可靠性等系統測試，而不是等到最後才開始。通常系統測試發現的問題對整個系統的影響比較大，修復這類問題的影響面也比較大。甚至可能是由系統架構等這模擬較high level的問題導致的，這樣的話肯定會影響到專案的release.如果早期開始系統測試，有問題及早發現，可以極大的降低在專案後期發現嚴重的系統問題，降低了專案整體的risk。通常有兩種方法在專案早期進行系統測試：
1）根據設計文件，為系統建模，分析可能存在的系統瓶頸
2）考慮對重要的module在模組級別進行系統測試。通過和rd合作，為關鍵模組開發專用的介面，實現模組級別的系統測試。
以上幾點是系統測試中要注意的一些普遍問題，希望可以幫助大家少走一些彎路。
Installation 測試注意點
1 start installer by double click,command line 2 install under differrent user previlege 3 install on pc with limited space 4 install while other sw i...
測試注意問題
很多時候，由於人力資源的不足，測試專案負責人都是在執行測試，這樣就使整個專案缺乏控制，一些問題 例如 有些成員的缺陷質量不夠合格 開發人員修改不及時，系統某些功能發生嚴重問題導致部分功能無法測試。得不到解決，耽誤了進度。所以測試負責必須全程監控專案，盡可能多的掌握資訊。通常，測試負責人需要完成下面這...
軟體模式變遷與測試注意點
在傳統的c s架構下應用程式 如，windows下客戶端應用程式 一般是一台 資料庫伺服器 db 然後對應n臺客戶端 dal bll ui 本質上就把ui這一層放在客戶端，把ui以下放在server端。客戶端在不同的平台下面有不同的表現形式，就形成了現在流行的所謂的 abc s 模式的架構，這個基本...