系統(tǒng)性能測試六大步

1、系統(tǒng)性能測試六大步性能測試是為了保證產(chǎn)品發(fā)布后其性能能夠滿足用戶的需求，本文結(jié)合具體案例介紹了應(yīng)用系統(tǒng)性能測試的六大步驟。在本文介紹的這個(gè)案例中，被測應(yīng)用系統(tǒng)是一家公司的客戶信息系統(tǒng)，它主要用來錄入、修改以及查詢?nèi)蚩蛻舻男畔?，并將客戶信息轉(zhuǎn)入到業(yè)務(wù)系統(tǒng)。但是，在應(yīng)用過程中，客戶經(jīng)常投訴在某個(gè)時(shí)刻新建或者修改一個(gè)客戶信息非常慢，正常情況下完成該操作只需要15秒，而異常時(shí)卻需要10分鐘左右，而且系統(tǒng)管理員發(fā)現(xiàn)系統(tǒng)資源使用率都比較低，這種情況的出現(xiàn)并沒有規(guī)律性。在這個(gè)案例中我們發(fā)現(xiàn)了系統(tǒng)存在性能問題，下一步工作就是要在性能測試過程中查找形成系統(tǒng)瓶頸和故障的根本原因，在此項(xiàng)工作中我們應(yīng)該按照如下幾個(gè)

2、步驟進(jìn)行。目錄隱藏    * 1 確定明確的測試目標(biāo)    * 2 測試需求分析    * 3 測試用例設(shè)計(jì)    * 4 腳本開發(fā)數(shù)據(jù)的準(zhǔn)備以及測試執(zhí)行與監(jiān)控    * 5 測試分析    * 6 系統(tǒng)調(diào)優(yōu)與驗(yàn)證    * 7 參考資料          o 7.1 相關(guān)條目          o 7.2 外部連接確

3、定明確的測試目標(biāo)性能調(diào)優(yōu)是是無止境的，所以在測試之前應(yīng)確定一個(gè)明確性能調(diào)優(yōu)目標(biāo)，這也是后面“評估性能驗(yàn)證”的一個(gè)基準(zhǔn)，也是測試終止的一個(gè)基準(zhǔn)。在本案例中目標(biāo)設(shè)定為: 在相同系統(tǒng)環(huán)境配置下30個(gè)并發(fā)用戶在15秒鐘內(nèi)完成各類在線操作。測試需求分析性能調(diào)優(yōu)的測試分析主要目的是要挖掘出可能造成系統(tǒng)瓶頸的因素，并為后面的測試用例設(shè)計(jì)提供保證。影響系統(tǒng)性能有很多種原因，在此應(yīng)關(guān)注如下幾個(gè)關(guān)鍵點(diǎn):    * 應(yīng)用配置需求: 例如應(yīng)用整體框架、涉及到哪些第三方的組件、應(yīng)用層與數(shù)據(jù)庫層的接口、使用了什么數(shù)據(jù)庫等。     * 系統(tǒng)配置需求: 例如用戶客戶端配置、

4、客戶端與服務(wù)器端的網(wǎng)絡(luò)配置、應(yīng)用服務(wù)器或數(shù)據(jù)庫服務(wù)器操作系統(tǒng)等。     * 用戶使用情況需求: 例如用戶分布情況; 哪些模塊用戶使用比較頻繁; 在用戶操作的數(shù)據(jù)有哪些特點(diǎn)等。     這方面工作是非常繁雜的，而且要求測試人員具有挖掘可能造成系統(tǒng)瓶頸因素的洞察力和敏銳感，但是很多測試人員在接手測試之后，很快進(jìn)入到測試用例設(shè)計(jì)階段。實(shí)踐證明，這樣做往往都適得其反，要么工期延期，要么項(xiàng)目開發(fā)失敗。這個(gè)過程在測試整體過程中是非常關(guān)鍵的一環(huán)。性能測試分析有個(gè)特點(diǎn): 它關(guān)注的是應(yīng)用的整體，或者會(huì)仔細(xì)分析圍繞著應(yīng)用的各種外部因素，比如說它所涉及到

5、的硬件、第三方軟件，而不會(huì)深入到項(xiàng)目具體的內(nèi)部。這是因?yàn)樾阅軠y試關(guān)注的是項(xiàng)目整體、是一種黑盒測試方法，我們關(guān)心一個(gè)項(xiàng)目的整體在運(yùn)行時(shí)所暴露出來的問題。在此案例中我們獲取到如表所示需求。 測試用例設(shè)計(jì)此過程主要目的是設(shè)計(jì)出一些合理的場景去驗(yàn)證在需求分析階段獲得的可能影響性能的因素是否是造成系統(tǒng)瓶頸的因素。測試用例設(shè)計(jì)一般包括測試策略、測試案例、測試內(nèi)容。測試策略一般包括對比測試環(huán)境與真實(shí)的業(yè)務(wù)操作環(huán)境，真實(shí)業(yè)務(wù)操作環(huán)境又可能涉及局域網(wǎng)測試環(huán)境與機(jī)房測試環(huán)境等測試案例主要是根據(jù)測試需求分析的結(jié)果制定出在測試執(zhí)行時(shí)系統(tǒng)的執(zhí)行方法，比如本案例中“5個(gè)人同時(shí)錄入不同的新客戶信息，以及具體的模擬

6、步驟”。在測試案例設(shè)計(jì)時(shí)應(yīng)注意如下幾點(diǎn):    * 虛擬用戶的操作步驟要盡量類似于真實(shí)用戶的操作。     * 操作的數(shù)據(jù)要類同于真實(shí)用戶實(shí)際使用數(shù)據(jù)，例如在案例中用戶錄入客戶信息時(shí)，根據(jù)需求得到的結(jié)果，我們可以設(shè)計(jì)有34個(gè)虛擬用戶在錄入一些小客戶的信息，12個(gè)虛擬用戶在錄入大客戶的信息等。     * 在案例設(shè)計(jì)時(shí)要充分考慮到需求中用戶對模塊的使用頻率。使得在模擬時(shí)每個(gè)模塊使用情況盡量地類似于真實(shí)環(huán)境。 測試內(nèi)容一般包括并發(fā)性能測試、疲勞強(qiáng)度測試、大數(shù)據(jù)量測試以及系統(tǒng)資源監(jiān)控等，我們在做性能調(diào)優(yōu)測試時(shí)主

7、要是做并發(fā)性能測試以及系統(tǒng)資源監(jiān)控這些方面的工作。從對系統(tǒng)產(chǎn)生并發(fā)性能測試過程中監(jiān)控系統(tǒng)中各種資源的變化，來判斷導(dǎo)致性能瓶頸的原因。腳本開發(fā)數(shù)據(jù)的準(zhǔn)備以及測試執(zhí)行與監(jiān)控測試執(zhí)行與監(jiān)控的主要目的是根據(jù)設(shè)計(jì)方案去驗(yàn)證系統(tǒng)是否存在瓶頸，給測試分析提供各種分析數(shù)據(jù)。此過程會(huì)與下面的“測試分析”過程不斷進(jìn)行重復(fù)執(zhí)行，直至真正確定出系統(tǒng)瓶頸所在。筆者認(rèn)為，在此過程中如果有測試工具能夠滿足測試要求，那么應(yīng)盡量使用測試工具，不要手工去開發(fā)測試程序，因?yàn)樽銎髽I(yè)項(xiàng)目往往時(shí)間緊張，而且測試工具畢竟是一個(gè)成熟的產(chǎn)品，在各方面都得到驗(yàn)證。使用工具將會(huì)縮短測試周期，而且現(xiàn)在市場上有很多成熟的測試軟件。例如: Mercur

8、y的LoadRunner、IBM的Robot、Compuware的QALoad等。在這個(gè)案例中筆者使用的是Mercury的 LoadRunner。關(guān)于一些技術(shù)細(xì)節(jié)筆者就不再贅述了，在這里主要提兩點(diǎn)。一是數(shù)據(jù)的準(zhǔn)備。數(shù)據(jù)準(zhǔn)備一定要關(guān)注數(shù)據(jù)的質(zhì)量和數(shù)量，不要出現(xiàn)一些不符合業(yè)務(wù)邏輯的廢數(shù)據(jù)，并且數(shù)據(jù)量要滿足測試運(yùn)行的需要。例如測試需要100組數(shù)據(jù)，但是實(shí)際只準(zhǔn)備了50組，從而導(dǎo)致測試執(zhí)行結(jié)果出現(xiàn)大的偏差。二是測試執(zhí)行。除了正確按照設(shè)計(jì)的要求去設(shè)置各種參數(shù)之外，還要關(guān)注系統(tǒng)是否存在功能問題，這往往成為性能測試的“盲點(diǎn)”。原則上性能測試之前必須確保功能測試已經(jīng)完備，但是任何事情都不絕對，所以一般做性能測

9、試之初，都會(huì)模擬一個(gè)用戶去運(yùn)行設(shè)計(jì)的場景，主要是確?！皽y試腳本正確性”、“在設(shè)計(jì)的場景中應(yīng)用系統(tǒng)不存在功能上的問題”。很多性能測試過程往往因?yàn)楣δ軉栴}導(dǎo)致性能測試失敗，或者是測試延期的現(xiàn)象。本案例的測試執(zhí)行結(jié)果如圖所示。測試分析測試分析的主要目的是要根據(jù)測試執(zhí)行獲取到的數(shù)據(jù)去判斷造成系統(tǒng)出現(xiàn)瓶頸的位置，挖掘造成系統(tǒng)瓶頸的真正原因。這個(gè)過程是技術(shù)含量最高的一環(huán)，因?yàn)樵跍y試執(zhí)行過程獲取到的數(shù)據(jù)會(huì)涉及到各個(gè)方面，在這個(gè)案例中就涵蓋了網(wǎng)絡(luò)方面的知識、系統(tǒng)方面的知識、應(yīng)用方面的知識等，測試人員需要從這些繁雜的數(shù)據(jù)中挑出異常，系統(tǒng)越大越復(fù)雜在這個(gè)方面對測試人員要求會(huì)更高。但是這里面也有一些技巧: 

10、;   * 在做測試分析時(shí)人員組成建議為: 開發(fā)人員、系統(tǒng)人員、測試人員共同組成。這樣會(huì)在技術(shù)上填補(bǔ)個(gè)人技術(shù)上的不足。實(shí)際每個(gè)項(xiàng)目涉及到的技術(shù)都可能各有不同，對于個(gè)人來說不可能每樣都精通。     * 反復(fù)比較一個(gè)類型的參數(shù)在不同時(shí)間的跳躍值，或者不同場景下同一個(gè)類型參數(shù)的變化。     * 在發(fā)現(xiàn)參數(shù)有異常變化時(shí)，不要輕易下結(jié)論，而是要盡量挖掘可能影響這個(gè)參數(shù)的其他參數(shù)值。在長期的測試過程中發(fā)現(xiàn)往往發(fā)現(xiàn)第一個(gè)所謂的瓶頸都是因?yàn)槠渌蛩卦斐傻摹?#160;    * 在測試分析時(shí)使用較多的一種方式是排除法

11、，根據(jù)開始獲取到的信息大概能將問題定位在某一層面上。但具體在什么地方，就可以采取排除的方法去定位。     * 盡量使用一些比較成熟的工具協(xié)助分析工作，這樣將大大減輕工作負(fù)擔(dān)。     * 在確定出真正的性能瓶頸時(shí)，可以做一些小的測試模型去做驗(yàn)證，確定分析的正確性。 在本案例中，在測試結(jié)果經(jīng)過各種比對之后，最后確定是數(shù)據(jù)庫層上出現(xiàn)問題。但是問題究竟出現(xiàn)什么地方呢？筆者在分析過程中采用了許多排除法，比如更新索引的統(tǒng)計(jì)值、將數(shù)據(jù)庫中的表從頁級鎖改為行級鎖等，但是都效果甚微。所以，我們回到上面看與數(shù)據(jù)庫層相關(guān)的需求: 

12、  * 因?yàn)闃I(yè)務(wù)需要，需要使用很多模糊查詢。此類操作會(huì)進(jìn)行表掃描。為了防止臟讀，會(huì)向數(shù)據(jù)庫申請表級意向鎖。    * 因?yàn)榭蛻絷P(guān)系復(fù)雜，所以數(shù)據(jù)庫設(shè)計(jì)的時(shí)候，存在多表關(guān)聯(lián)。    * 在應(yīng)用開發(fā)時(shí)，我們使用了Hiberate這個(gè)組件，這些組件對于開發(fā)人員來說是一個(gè)黑盒，而且存在一些局限性: 在更新記錄時(shí)會(huì)同步更新所有相關(guān)聯(lián)的表，即使關(guān)聯(lián)表不需要更新; 同步更新的記錄操作會(huì)涵蓋一個(gè)事物處理過程中，會(huì)產(chǎn)生大事務(wù)操作; 無法利用SQL優(yōu)化技術(shù)去優(yōu)化他所產(chǎn)生出來的SQL語句。 研究之后發(fā)現(xiàn): 在進(jìn)行模糊查詢與大客戶信息錄入與修改的操作時(shí)，由h

13、iberate這個(gè)組件產(chǎn)生的大事務(wù)SQL導(dǎo)致了數(shù)據(jù)庫的互鎖，是系統(tǒng)瓶頸所在。為了驗(yàn)證這一判斷的正確性，筆者做了一個(gè)小的模型去驗(yàn)證。假設(shè)庫中有A、B、C三張表，現(xiàn)在有三個(gè)虛擬用戶同時(shí)在上面進(jìn)行操作: 用戶Vuser1需要查詢客戶信息，他只知道客戶的姓氏，所以他采取了模糊查詢; 用戶Vuser2正在修改一個(gè)客戶信息，正準(zhǔn)備保存; 用戶Vuser3正在查詢客戶辦公信息，也需要模糊查詢。Vuser1操作先得到執(zhí)行，在表掃描中出現(xiàn)表級意向鎖; 此時(shí)Vuser2進(jìn)來需要修改A、B、C三張表對應(yīng)記錄，并成功的鎖定了B、C兩張表對應(yīng)的行（因?yàn)槭切屑夋i），然后進(jìn)行了修改，但是無法修改表A，所以 Vuser2此時(shí)等待Vuser1釋放鎖; 此時(shí)Vuser3進(jìn)來了，需要查詢C表，因?yàn)閂user2并沒有釋放鎖，此時(shí)Vuser3也處在等待狀態(tài)。驗(yàn)證顯示，在出現(xiàn)大數(shù)量的操作并且在多