性能測試從測試目的來說分爲三類：評估型測試、確認型測試、調優型測試。
評估型測試主要是在評估某種條件下運行的性能狀況。如測試系統在不同環境下的性能狀況，隨用戶數量的變化或者數據量的變化情況下軟件的性能變化狀況。評估型測試往往並沒有特別明確的通過目標，而是根據測試結果的分析和對比給出本次評估內容的一些結論。
確認型測試主要是爲了驗證系統是否滿足規定的性能指標要求。通常測試目的中都或有測試系統在某一條件下的平均響應時間，或者吞吐率，或者併發用戶數等是否滿足規定的要求。確認型測試一定有很明確的通過標準，測試結果與既定的通過標準對比，給出被測系統是否確認通過的結論。
調優型測試主要是通過性能測試找出被測系統的性能瓶頸，分析出引起系統性能缺陷的原因，並進行針對性的性能優化，以改進軟件性能。如對軟件進行性能測試，確定系統否存在內存泄漏、線程泄漏、不合理爭用資源或者死鎖等問題，對其進行性能優化。調優型測試一般都是進行單個業務場景的併發測試，以能更具體的模擬和更快速定位問題。
根據不同的測試類型，需要在測試執行過程中針對負載對象的調度以及運行過程中的如思考時間、迭代時間進行設計，以期能更貼近不同的測試類型的要求。這些不同的設計，這裏提出來三種不同的模型供大家參考。
瀑布模型
瀑布模型，就是根據測試總時長，每隔一段時間增加一個測試對象提供負載。通過這種組合模型可以保證每過一個時間段，當前運行的都是不同的負載模型，不僅僅是負載量變化了，包括負載對象也同時發生變化。
這種模型主要應用在進行確認型測試時，在確認系統是否有問題的同時還能夠很快的根據出問題的時間點來確認是由於哪個負載對象的加入從而導致系統開始出現性能問題。這種模型對於問題的定位更有意義。
該模型的缺點在於根據出問題的時間點只能確認是因爲哪種負載對象的加入而導致的性能問題。但並不能回答該負載對象和哪一個負載對象同時提供負載導致的性能問題。比如下圖所示：在CASE3加入負載後系統開始出現問題，我們沒有辦法知道具體是因爲CASE3和CASE1同時運行導致系統問題？還是因爲CASE3和CASE2同時運行導致系統問題。
魚骨模型
基於以上提到的瀑布模型的缺點，我們又提出另外一種模型，魚骨模型。魚骨模型是通過不同負載對象的各種組合來覆蓋所有可能的組合情況。
如下圖所示：從不同負載對象兩兩組合、三三組合一直到所有負載對象同時運行都覆蓋到了。但是該模型的缺點在於當一個場景中包括的負載對象非常多時，這種可能的組合是成指數增加的。因此，負載對象超過4個的場景都不適用於該模型。
該模型也是主要用於確認型測試。對於負載對象較少的情況，可以直接使用該模型進行負載對象調度的設計；對於負載對象較多的情況，應該跟瀑布模型結合進行，先通過瀑布模型進行設計定位造成系統問題的負載對象分別是哪幾個，縮小範圍後再通過魚骨模型精準定位。
混合模型
在實際測試的過程中，很多時候，我們並沒有太多的時間把所有可能的負載對象組合都測試到，即便是先通過瀑布模型縮小範圍依然需要很長的時間，這時候，我們往往直接將所有負載對象同時運行，爲了能夠在固定的時間內覆蓋儘可能多負載對象組合，我們往往需要將思考時間、迭代時間設置爲範圍隨機。每個測試對象的時間範圍的最大值建議爲該負載執行一次所需時間的1/7或者1/13，可以儘量減低因爲滿足所有的的公倍數而導致的組合重合的情況。
該模型是我們日常測試使用最多的模型，該模型的缺點在於即便測試出問題，也無法之間具體是因爲哪幾個負載對象同時運行導致。因此，該模型更多的時候主要適用於評估型測試。
截止到此，關於性能測試負載模型的十篇文章就算是到此結束了，後面有時間了我會逐步說一下性能測試體系建設的一些思路。