MSC性能測試之體會一 性能測試工具
我做MSC性能測試只有兩年多，平常也有寫點東西記下自己對測試的體會，就是零零散散。趁星期天整理了一下，發一下“牢騷”，和大家探討一下…
1. 性能測試
性能測試我們把它稱為performance test，一般來說都是對于整個MSC框架進行的，應該在MSC中各模塊比較成熟穩定后再進行的，也就是說是在function test之后才會執行，是一種典型的system test!它的測試目的其實是根據之前已經制定的的需求分析報告或者文檔來validate MSC系統的性能是否達到了customer request或者design request，保證系統的穩定性，例如，系統的容量是多少?達到用戶要求嗎?呼叫的成功率又有多少呢?CPU處理能力如何?響應時間呢?如果現在發起的呼叫超過系統處理能力MSC怎么辦?等等……并且發現潛在的系統性能瓶頸，從而優化系統性能!
2. 性能測試的測試計劃
測試的話不能不提到test plan這個綱領性的document，performance test plan包含的內容其實和一般的test plan template大體一致的，包括：
test activity scope/overview
test objectives
test strategy
test areas
test env configuraion
test tools
test timeline planning
test resource
test cases...etc
而且這個plan應該在design phase的時候就draft出來，提前做plan是為了縮短軟件開發的流程，減少開發成本，是產品更早地到達客戶手上;test plan要在test start之前就邀請開發人員，architect，有經驗的人員或者更高一層的管理層來參加test plan reviewe，一起討論。這樣的做法是為了增加測試的coverage，而且及時的發現test plan的不足，risk，得到更多的專業意見，保證測試計劃的質量和可行性;最后根據reviewer的feedbacks對testplan和 test case作出相應調整修改，并得到approved和獲得baseline version。
同時要注意的就是testplan approved之后就一成不變，應該根據實際的執行情況或代碼的改動對testplan作出相應的update，并生成新的version，以便以后質量管理的audit。
3. 性能測試的測試工具和測試腳本
測試MSC性能，都是用自動化的測試工具啦，不可能人工執行。想想，如果還要人工的一個一個的打電話來產生話務量，那相對MSC的容量標準(每小時幾百K甚至幾M的呼叫次數)來說的話，根本就是九牛一毛，對于測試也是無效的數據!所以嘛，這個時候automatic traffic simulator 就發揮出巨大的潛能和力量啦;同時要注意一點就是，因為simulator是模擬MSC的用戶或MSC對端的節點，要盡量模擬真實的用戶打電話環境的，所以選擇一個穩定性高的模擬器是很重要的，是直接關系到測試的效果。
有了測試工具還不夠，因為還需要寫測試腳本，為什么呢?因為既然我們不能手工的來打電話產生話務量，那么就要依靠測試腳本來模擬各種真實的打電話情景了。其實測試腳本一旦完成后就應該保存好，因為以后軟件版本的性能測試很多時候還會重用那些測試腳本產生話務量的，即便MSC某個功能改變或者增加新的功能，我們也只是需要修改或增加那部分的測試腳本……哈哈怎么樣?我們是不是就可以省下不少的開發時間呢。。。
在調試完單個測試腳本的時候，還要把全部腳本綜合起來一起調試，及時調整腳本，確保腳本的健壯性，這可以說是性能測試前期的一個重頭戲。如果不能保證這一點的話，那到了test start的時候，擺在你面前的是數百萬的話務，你都不知道錯誤是MSC引起還是模擬工具引起的，還說什么性能分析呢～～～
文章來源于領測軟件測試網 http://www.kjueaiud.com/