<sub id="l9qyp"><listing id="l9qyp"></listing></sub>

    <form id="l9qyp"><legend id="l9qyp"></legend></form>
      1. <wbr id="l9qyp"></wbr>
        1. 更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          進行性能測試前需要準備什么?怎么做好這些準備?

          • 發布:軟件測試培訓
          • 來源:軟件測試資源分享
          • 時間:2018-12-10 18:07

          進行性能測試前需要準備什么?怎么做好這些準備?這個可能關乎你進行性能測試的結果與導向,關乎你進行性能測試的質量與效率,你說這個準備重要嗎?

          進行性能測試前需要準備什么?怎么做好這些準備?通過提供的一套全面的解決方案, 本文描述Quests Application Management Suite for Java and Portals是如何與該方法論相集成,從而在應用開發生命周期的每個階段保證您的成功。運用這套方法論和Quest的應用管理解決方案,您將充滿信心地把符合性能規范的應用展現給您的用戶。

          本文同時強調自動化的重要性,采用自動化方式可以創建重復的測試過程并迅速報告應用代碼的質量。只有自動化方式才能保證正確地遵循這些測試過程,并且保證準確和一致地測試應用組件。

          導言

          性能測試已經成為軟件開發開發開發開發開發界的一個事后總結出來的想法。IDG 的研究報告指出只有20%的上線的企業Java 應用符合他們的性能要求。如果所有上線的企業Java應用中有80%不滿足他們的服務標準協議(SLAs),那么就需要花費巨大努力去分析為什么會發生這種情況以及如何解決這種問題。要想成功滿足SLA,其關鍵在于應該采用正規的性能測試方法論。本文將詳細闡述該方法論并且指出在每個測試階段所需使用的工具集,以成功確保企業應用的性能。

          測試主要分兩類: 功能測試和性能測試。本文專注于性能測試,因此本文中的所有提及的測試除非有另外說明,否則都指性能測試。

          進行性能測試前需要準備什么,怎么做好性能測試前準備

          進行性能測試前需要準備什么?怎么做好這些準備?

          一、量化性能需求

          為了量化性能要求,我們假設您已經定義了SLA。在深入分析問題之后,關鍵的負責人員應該系統地定義SLA。SLA 的主要推動者應該是應用業務負責人和應用技術負責人。 應用業務負責人,有時是應用產品經理,他負責分析商業案例并把客戶的需求轉化為SLA。其實, 只要滿足SLA, 客戶的需求也會滿足。應用技術負責人,有時是應用構架師,分析必要的技術需求,解釋用例并"真實地檢驗"SLA。因此,技術業務負責人的責任就是確保服務等級是可達到的。有效的SLA具有三個關鍵特性:

          1.具體的。

          2.靈活的。

          3.現實的。

          一個有效的SLA必須是一個具體的值。一個用例必須在大約五秒內完成是不準確的,因此很難檢驗--5.25秒鐘是否是大約的五秒。一個具體的值便于QA在應用上線前進行測試,當應用上線后,SLA將提供對主動監測和被動監測兩種警報(Alert)的規范。同時,一個有效的SLA在分布式的變化環境中必須也是靈活的??紤]到一些未預料到的情況,我們需要對靈活性進行測量,因此用例必須采用預先定義的時間百分比的方式滿足具體的SLA值。例如,您每天使用的常用搜索引擎。當您執行一次查尋,在95%的時間里可以在2秒內完成;在每20次查詢中,有一次的響應時間是7秒;通常這種變化的范圍是可以接受的。但是如果每20次查詢中,有10次超過7秒,你可能就會考慮換個搜索引擎了。SLA不僅必須是具體的, 也要靈活,同時必須也是現實的。你可以通過要求應用業務負責人和應用技術負責人共同制定SLA的方式保證SLA是現實的。這是一個有效用例的特別關鍵的特性,這是因為在大多數情況下,SLA只由應用業務負責人單方面確定,沒有考慮應用技術負責人的意見。當技術小組接到這些性能需求時,他們往往會忽略,一個不現實的SLA比根本沒有還要糟糕。

          二、了解你的用戶

          為了保證調優努力的成功你能做的最重要的事就是安排時間了解你的用戶和理解他們在使用你的應用時的行為情況。很少會在生產環境中調優應用服務器,而更多的情況是,通過寫測試腳本再現為虛擬用戶,在上線前的環境中執行負載并進行調優。當在上線前環境中完成調優后, 就可以安全地把配置信息應用到生產環境中。多數公司無法在上線前的環境中充分地再現生產負載。如果您在這些公司中工作,沒必要失望。多數大型的公司并沒有對他們的用戶行為有很好的理解并且在測試環境中不能產生有代表性的負載。

          有兩個共同的似是而非的理由:

          1. 生產負載太大,在上線前無法模擬。

          2. 我沒有任何辦法知道我的最終用戶到底是如何操作的。

          針對第一點,我們可以在上線前環境中建立一個按比例縮減的生產版本,當在生產環境中部署時,再按比例放大。雖然沒有做一個生產環境的鏡像有效,但是有時并值得那么做。針對第二點,下面將說明如何采集最終用戶的操作行為。

          由于我們需要在投入生產之前設法在上線前的環境中調優我們的應用系統,這樣才能驗證配置,所以一個隨之而來的問題就是我們需要在這個環境中執行的負載測試腳本。對一個企業應用進行調優的步驟包括實施一些最佳實踐設置,負載測試應用,觀察應用的行為,以及適當調整配置參數等。這是一個疊代過程,我們需要不斷調整以達到最優的配置。一些調整可能會提高性能,而一些會降低性能。這也是為什么性能調優不應該放在開發周期后期的一個原因。

          假設我們根據我們的負載腳本進行調優,那對你又意味著什么呢?這意味著負載腳本應該真實反映現實世界用戶的使用行為。假設我們在優化一個Web搜索引擎,我們可以寫一個測試腳本,該腳本總是在測試蘋果和香蕉,但是用戶是這樣使用嗎?我們可以為此調整出最好的性能。但是當查詢Bea和IBM時,又會怎樣呢?在我的應用中,我可以將技術公司的詞匯放在與水果和蔬菜不同的數據庫庫庫庫庫中,那么在測試環境中,永遠不會執行到那段代碼,我們的調優努力也就徒勞無益了。

          更好的解決辦法是確定名列前茅1000 或10,000 個查尋詞組和他們頻率。然后,計算每個被請求的時間百分比并且編寫按照該百分比查詢這些詞匯的測試腳本。對于剩余的百分比,你可以把負載測試工具連到一個詞典,可以隨機生成查詢的詞匯。

          三、使用工具分析

          編寫一個典型用戶負載腳本的困難之處是發現你的用戶是怎么使用的應用的。這不是一門精確的學問。但是為得到一個合理的可靠的結果,第一步是看看您的訪問日志?,F在,我不會推薦手工做這件事,因為對于一個中型的Web應用,工作量也是巨大的?,F在有大量商業或免費工具可為您分析訪問日志。

          這些工具將告訴你有關你的服務請求的一些情況:

          a) 將服務請求按時間的百分比排序,并顯示百分比。

          b) 放大或縮小分析時間間隔,便于以粗粒度或細粒度方式顯示結果。

          c) 識別每天,周,月,年的高峰使用時間。

          d) 跟蹤字節傳輸和請求的平均時間。

          e) 按照你的應用的內部,外部或地理位置,識別和分類請求的用戶。

          f) 匯總成功請求的百分比。

          g) 匯總HTTP發生的錯誤。

          h) 匯總顧客忠誠度, 譬如回頭客和平均會話長度。

          i) 跟蹤從其他站點的轉入情況。

          無論你選擇哪種軟件分析訪問日志,重要的是你應該做這些分析工作并且把這些信息作為編寫測試腳本的基礎。有時訪問日志的作用是有限的,在某些情況下不能提供足夠的信息。例如前端應用只使用一個URL發出請求,而通過在請求中嵌入不同的參數區分業務功能。在這種情況下,就需要高級一些的工具根據不同的請求參數監測應用的使用情況和劃分業務功能。

          訪問日志只能提供部分解決辦法。接下來需要對應用本身有更深入的理解。例如,當發出一個特定的服務請求時,你應該知道其不同的選項所控制的相應行為。這些信息的最好來源是應用的用例和負責該功能的架構設計人員。這些工作的目標是識別出真實世界中用戶的使用行為,所以應該徹底和全面地完成此階段任務。這里發生的錯誤將導致上文提到的"蘋果和香蕉"搜索引擎的問題。

          為了全面獲得更可靠和更詳盡的最終用戶行為信息,可以考慮Quest公司的User ExperienceMonitor(UEM)。UEM在最終用戶和WebServer之間,實時捕獲向你應用環境發出的每個請求,可提供有關真實用戶所做的詳盡數據,包括連接速度,瀏覽器版本,按地理位置匯總等信息。由于采用了被動的網絡Sniff技術,所以對應用的性能影響為零。

          四、用戶如何退出系統

          最后,有一個值得重視的問題,我們了解到目前客戶在編寫負載測試腳本時最大的錯誤是:用戶不知道怎樣退出應用系統。不管你把退出按扭作的多大,至多只有 20%用戶會使用。這是由于現在將Web作為主要業務平臺的必然結果。商業Web站點正式基于此而得以快速發展并統治了Internet.

          因此,現在用戶習慣以下面方式退出網站:

          1. 離開當前網站,轉到其他網站

          2. 關上瀏覽器窗口。

          由于這已是根深蒂固的Web 使用模式,所以不能指望用戶正確地退出網站。當編寫測試腳本時,應用確定正確退出和非正確退出的用戶比例,然后根據這個比例編寫腳本。我們遇到的一個大型汽車網站,已經為此困擾了一年多,他們的應用服務器每隔幾天就會崩潰,他們已經習慣于在晚上重起應用服務器。仔細分析HTTP會話的使用模式,我們發現閑置的會話非常多。

          我們檢查了他們的測試腳本,發現每個測試場景都包含了正確的退出。他們就是基于這個假設進行優化的,因此優化工作并沒有觸及閑置的會話內存問題。在調整測試腳本,重新優化系統環境后,由于"Outof memory"引發的強制重起問題就解決了。

          感謝您的閱讀,以上就是達內軟件測試培訓分享給大家的進行性能測試前需要準備什么?怎么做好這些準備?你學會了嗎?更多軟件測試相關的內容盡在達內軟件測試培訓機構,敬請關注!

          免責聲明:內容和圖片源自網絡,版權歸原作者所有,如有侵犯您的原創版權請告知,我們將盡快刪除相關內容。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:有了這份常見bug匯總表,將更有針對性地進行bug測試!
          下一篇:達內軟件測試培訓12月免費訓練營開班了!

          軟件測試必備的數據庫知識有哪些?(終)

          日志在快速定位自動化腳本故障中的重要性研究

          測試慣例是什么?怎么打破測試慣例?

          “用鼠標點點點”的測試,未來還有機會嗎?

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          奇米影视奇米色777欧美欧美一级高清片在线观看876av电影高清 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>