南京移動應用性能測試

移動應用如何進行壓力和性能測試？

性能測試就是用來測試應用運行性能的。性能測試可以發(fā)生在各個測試階段中，即使是在單元層，一個單獨模塊的性能也可以使用白盒測試來進行評估，然而，只有當整個系統(tǒng)的所有成分都集成到一起之后，才能檢查一個系統(tǒng)的真正性能。
　
性能測試經(jīng)常和壓力測試一起進行，而且常常需要硬件和軟件測試設備，這就是說，常常有必要的在一種苛刻的環(huán)境中衡量資源的使用。外部的測試設備可以監(jiān)測測試執(zhí)行，當出現(xiàn)情況時記錄下來。通過對系統(tǒng)的檢測，測試者可以發(fā)現(xiàn)導致效率降低和系統(tǒng)故障的原因。
　
壓力測試：對系統(tǒng)不斷施加壓力的測試，是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的*服務級別的測試。例如測試一個應用段時間內(nèi)大量用戶涌入的負荷下，何時系統(tǒng)的響應會退化或失敗。
　
性能測試：在交替進行負荷和強迫測試時常用的術語。性能測試關注的是系統(tǒng)的整體。它和通常所說的強度、壓力/負載測試測試有密切關系。所以壓力和強度測試應該于性能測試一同進行。
目前在移動應用領域，壓力測試和性能測試都是保證產(chǎn)品質(zhì)量的重要項目，當然相對于大多數(shù)APP測試，對壓力測試的需求基本在于手游測試，后者這服務器壓力方面需求更大。
TestBird - 手游和App自動化測試平臺

移動客戶端的性能測試如何做？

不過我畢竟一直在創(chuàng)業(yè)公司,而且就我一個人,所以了解可能有限,我這里就說下我之前碰見的,所知道的,目的只是拋磚引玉.
客戶端的性能從系統(tǒng)層面,電量消耗,網(wǎng)絡流量,內(nèi)存泄漏等都是被關注,或者說用戶最最關注的點.
實例一,3rd 應用的性能測試.應用本身的響應時間可以通過call 應用intent來查看,設備純環(huán)境,設備低內(nèi)存等各種情況下進行同樣此數(shù)的call,進行對比.或者與同行業(yè)同性質(zhì)的應用進行對比測試.我相信很快就能夠有結論了.除了應用本身,還需要對于應用本身某些特別的功能進行響應測試.比如測試一個list,測試的方法為onkeydown之后查看這個list.index(0)是否高亮,是否正常的界面跳轉了,那么分別進行計時(精確ms).同樣的,我們在空list以及有幾百條list的情況進行這樣的case test,那么就會有一個性能的結果出來.
實例二,假設你測試微薄客戶端,那么你肯定是需要進行一個list上下滑動的性能測試.我們需要使用腳本語言shell或者python去call server api來仿造數(shù)據(jù)反饋到移動設備上,否則你不可能自己手動去發(fā)幾百條weibo然后再測試.測試的時候需要關注兩個問題,一個是list在各種情況下是否滑動流暢,一個是當list中有很多的圖片的時候圖片load的速度也是一個很大的測試點.這個load可以直接檢查imageview什么時候load出來pic,什么時候顯示在界面上,計算時間.這里其實很多應用是webview,或者數(shù)據(jù)是存在服務器端的,這個時候無論是平時的測試還是壓力,還是性能,數(shù)據(jù)的修改,其實還是多使用腳本ping api比較好,能夠很好的去輔助達到性能測試的效果.

公司有一款移動應用，想對App進行性能監(jiān)測，求推薦工具！

現(xiàn)在是移動互聯(lián)網(wǎng)時代，App已經(jīng)成了企業(yè)數(shù)字化業(yè)務的標配，APP的用戶體驗直接關系到用戶的留存、轉化和業(yè)務拓展，所以非常重要，我現(xiàn)在在金融公司負責一款APP的運維工作，之前我真心覺得這是一個苦逼有高風險的工作啊，App一旦發(fā)生網(wǎng)絡錯誤、卡頓、崩潰等，我就得加班加點排查故障，現(xiàn)在我用了博睿數(shù)據(jù)的APP監(jiān)控產(chǎn)品，包括模擬監(jiān)控，無需插碼，就能自動對APP進行事務流程測試，全面監(jiān)控自家app和競爭對手app的性能數(shù)據(jù)，做到知己知彼；還有一款是需要在App中嵌入SDK，能獲取每一次真實用戶的訪問體驗數(shù)據(jù)，快速發(fā)現(xiàn)本地代碼和網(wǎng)絡質(zhì)量等問題及原因，提升排障效率，提升用戶體驗。
根據(jù)使用經(jīng)驗，我建議大中型企業(yè)的App都要結合使用這兩種監(jiān)控產(chǎn)品，一個側重提前預警，一個側重定位根因，互補。

游戲app的性能測試，需要測試哪些指標和場景

主要監(jiān)測：不同網(wǎng)絡下啟動及業(yè)務的響應速度，不同時間段各種資源CPU,內(nèi)存，電量，流量占用情況，及連接超時、連接失敗等移動應用聯(lián)網(wǎng)性能問題
如何開展：根據(jù)公司的要求和實力決定吧，中小公司可以借助一些成熟平臺，使用一些開源的工具,大點的公司會開發(fā)自己的監(jiān)測工具。因為是移動應用的性能測試，我們一般將重點放在監(jiān)測啟動及業(yè)務的響應速度上，原則上不過多關注CPU占有率，但我們需要關注下，在程序閑時沒有異常的CPU占用，程序忙時沒有異常的峰值占用，這些好多開源的工具（GT/ Emmagee.apk）都能滿足。內(nèi)存，電量，流量占用可以用android自帶的一些tool: DDMS,hprof,TCPdump,traeview及shell命令來獲取Android手機的某些性能指標。
App系統(tǒng)性能要求==〉App性能測試要求==〉性能測試用例==〉收集性能測試指標基準==〉測試結果報告優(yōu)化

如何用測試移動APP應用性能

手機App能用lr測試的話，只能用在測試后臺服務器性能方面，至于app前段性能那只能用其他專門的工具。如果要用lr測試app后臺服務器性能，可以通過接口進行，選擇http協(xié)議即可。因為apps跟后臺的交互還是基于http協(xié)議的，所以首先你要確定接口都是那些，然后在lr中通過手動方式編寫腳本，無非就是模擬get、post方法，用到的函數(shù)基本就是web_url、web_submit_data()。

如何制作移動app測試方案及詳細流程？

1.首先是測試 資源確認及準備
（1）產(chǎn)品需求文檔，產(chǎn)品原型圖 ，接口說明文檔及設計文檔應該齊全
（2）測試設備及測試工具 的準備：IOS和Android的不同年版本的真機，以及測試相關工具的準備
2.測試用例的設計及評審
（1）根據(jù)產(chǎn)品需求文檔，產(chǎn)品原型圖等文檔，設計客戶端的一般功能測試用例
（2）測試用例評審，修改與完善，評審過后著手進入正式測試階段
3. UI測試
（1）確保手頭的原型圖與效果圖為當前*版本，符合產(chǎn)品經(jīng)理及用戶需求
（2）測試過程一切以效果圖為準，若用戶體驗方面有建議，先以郵件的形式 與產(chǎn)品經(jīng)理確認，確認通過后，可以正式的發(fā)出用戶體驗方面的問題
4.功能測試
（1）APP功能測試主要依據(jù)編寫的功能 測試用例進行軟件功能的遍歷
（2）涉及的測試主要包括基本功能測試，安裝，卸載，運行測試 ，異常處理（包括網(wǎng)絡 突然中斷或者網(wǎng)速 過慢，機器內(nèi)存不足等異常情況的處理 ）
5.中斷測試
（1）軟件運行 過程中接電話，收短信，鎖屏，鬧鈴，充電，收到通知提醒后在 使用軟件，軟件任可以 正常運行
（2）運行軟件時由前臺切換到后臺，再切換回前臺 仍能繼續(xù)運行
6.兼容性及適配器測試
（1）硬件的適配 ：不同手機 廠商，硬件 性能，不同屏幕大小的適配
（2）OS版本的兼容
（3）不同屏幕分辨率的適配：移動端設備的屏幕分辨率多種多樣 ，如果 app沒有做合適的處理可能會顯示不好，甚至影響功能的操作
（4）兼容性測試必須放在 一定數(shù)量的真機上運行 ，由于真機類型較多，兼容性測試 的時候可以選取典型的幾種運用較多的真機進行兼容性測試
7.性能測試
（1）客戶端性能測試注重安裝卸載時間，啟動時間，頁面加載時間，主要功能占用的床鋪，內(nèi)存，流量，耗電量 等，以及與同類產(chǎn)品相比較是否具有優(yōu)勢
（2）至于服務器端的性能，主要利用接口對服務器進行加壓，重點關注相應時間，吞吐量，并發(fā)數(shù)，事務通過率等
8.穩(wěn)定性測試
（1）安卓app的穩(wěn)定性常常使用 monkey進行測試，通過隨機事件流模擬個人操作，對檢查程序的內(nèi)存溢出，空指針有很大的作用
9.檢測分析及測試報告輸出
以上各種形式的APP測試結束后，應該形成完整的分析及報告文檔，輸出給相關人員
TestBird

如何對安卓市場App進行性能測試？

對App性能測試一般來說有：安裝和啟動時間、內(nèi)存實時監(jiān)控、卡頓、閃退、崩潰、CPU的占用、流量的耗用等等，傳統(tǒng)的方式比較費時費力，想要對App進行性能監(jiān)測你可以了解下聽云App，通過植入探針主動探測移動應用性能，幫助開發(fā)者及時發(fā)現(xiàn)應用性能隱患，采集真實用戶移動設備上的應用性能，幫助企業(yè)了解真實的用戶體驗，跟蹤App應用移動設備端用戶進行屏幕操作時的交互性能，還可以深入追蹤HTTP錯誤、網(wǎng)絡錯誤和崩潰原因，從而提高APP的質(zhì)量。

怎么進行性能測試

問題一：性能測試應該做哪些準備 環(huán)境搭建：這個根據(jù)實際規(guī)劃，我在企業(yè)內(nèi)做過的性能測試搭建的環(huán)境都是和用戶上線使用的實際環(huán)境一樣的。
數(shù)據(jù)準備：個人感覺是整個工作里第二耗時的，需要真實模擬用戶數(shù)據(jù)，這個不是單單的創(chuàng)建幾個帳號就完事的，每個用戶基本都會有不太一樣的配置，實際操作的時候部署數(shù)據(jù)的腳本都寫到手軟。
腳本編譯：選擇性能工具編譯性能腳本，你需要跑什么業(yè)務流程就編譯什么樣的腳本。
腳本執(zhí)行：用規(guī)劃好的用戶數(shù)執(zhí)行腳本，這個一般持續(xù)很長時間，時間太短不足以暴露服務器等的性能瓶頸，性能測試中最耗時的就是這個步驟。
收集日志：在執(zhí)行腳本完成后收集到的能客觀反應系統(tǒng)性能的日志、報表文件，比如LR的報告、數(shù)據(jù)庫的AWR日志等等。
分析結果：分析收集到的日志、報表，找出性能瓶頸或是得出性能指標結果。這個一般需要對數(shù)據(jù)庫或者底層非常了解的專業(yè)人士來分析，一般測試人員只需要提供收集到的報告就差不多了。
生成報告：將上面所有的性能測試活動整理總結，輸出測試報告。

問題二：如何做好性能測試？ 你好，首先很欣賞你的這種態(tài)度。我在TestBird 招聘新人的時候，也有很多小朋友覺得自己有多了解工具運用，有多熟練步驟過程，自我感覺很不錯。
其實，我卻想說，性能測試的重點不在性能測試工具的學習上。
當然，你也通過分析系統(tǒng)的壓力點、LR錄制腳本，設置用戶，做壓力，分析結果，整理測試報告。完成了性能測試的整個過程。那么我說這個性能測試報告是有效的，但它不一定是有用的。
為什么呢？因為在性能測試報告中，在你所在的環(huán)境中，你是測出了這樣的效果。并未摻假，全部真實的記錄。
為什么說它不一定是有用的，你了解系統(tǒng)架構么？知道數(shù)據(jù)庫、中間件、前端程序的運行方式和處理機制么？了解網(wǎng)絡協(xié)議么？了解操作系統(tǒng)么？熟悉開發(fā)系統(tǒng)的語言么，如java JVM的內(nèi)在機理知道么？這些都是系統(tǒng)運行的一部分，都在影響著系統(tǒng)的性能。如果不了解這些，你如何做出有價值的有參考意義的性能測試。
所以，學會這些性能測試工具很好，但是這僅僅是*步。性能結果只是一些數(shù)據(jù)而已，知道你在做什么，為什么要做這些，做完后能給出有價值的東西，才是后面要慢慢修煉的。

問題三：移動客戶端的性能測試如何做？ 。就當練習了。。大家看了不要噴我。?，F(xiàn)在很多測試人員做移動端測試，可能主要還是關注功能和自動化測試。性能測試可能大多是按照每個人的體驗來做報告，是不是比較快，或者比較慢。當然也不乏有很多的測試人員會回復我說，性能測試都是服務器的，移動端根本就不需要性能測試。我實在覺得可笑。 不過我畢竟一直在創(chuàng)業(yè)公司，而且就我一個人，所以了解可能有限，我這里就說下我之前碰見的，所知道的，目的只是拋磚引玉。 另外，我這里也不去說什么MAT，了，這種固有查找內(nèi)存的工具大家自己google吧。 客戶端的性能從系統(tǒng)層面，電量消耗，網(wǎng)絡流量，內(nèi)存泄漏等都是被關注，或者說用戶最最關注的點。 實例一，3rd 應用的性能測試。應用本身的響應時間可以通過call 應用intent來查看，設備純環(huán)境，設備低內(nèi)存等各種情況下進行同樣此數(shù)的call，進行對比。或者與同行業(yè)同性質(zhì)的應用進行對比測試。我相信很快就能夠有結論了。除了應用本身，還需要對于應用本身某些特別的功能進行響應測試。比如測試一個list，測試的方法為onkeydown之后查看這個list.index（0）是否高亮，是否正常的界面跳轉了，那么分別進行計時（精確ms）。同樣的，我們在空list以及有幾百條list的情況進行這樣的case test，那么就會有一個性能的結果出來。 實例二，假設你測試微薄客戶端，那么你肯定是需要進行一個list上下滑動的性能測試。我們需要使用腳本語言shell或者python去call server api來仿造數(shù)據(jù)反饋到移動設備上，否則你不可能自己手動去發(fā)幾百條weibo然后再測試。測試的時候需要關注兩個問題，一個是list在各種情況下是否滑動流暢，一個是當list中有很多的圖片的時候圖片load的速度也是一個很大的測試點。這個load可以直接檢查imageview什么時候load出來pic，什么時候顯示在界面上，計算時間。這里其實很多應用是webview，或者數(shù)據(jù)是存在服務器端的，這個時候無論是平時的測試還是壓力，還是性能，數(shù)據(jù)的修改，其實還是多使用腳本ping api比較好，能夠很好的去輔助達到性能測試的效果。 實例三，比如要測試一個優(yōu)酷的視頻軟件，那么視頻的播放的時候，首先保證網(wǎng)絡的情況下，各種分辨率各種碼率的視頻接入時間是需要關注。然后在播放，也就是和網(wǎng)絡不停的通信的同時，那么需要通過tcp dump和wireshark工具來檢查網(wǎng)絡訪問是否正確，視頻的卡頓，視頻的花屏等除了硬件兼容之外，可以通過抓包來判斷其性能。如果丟包率高那么自然視頻卡，體驗不好，性能也就不會好。 其實以上只是一些很基礎，現(xiàn)在很多公司也已經(jīng)在這個基礎上改良測試了。不過也是一些思路，讓更多的企業(yè)和測試關注移動客戶端的性能。不要一提到性能腦中只有LR等這些Server測試。

問題四：為什么要進行性能測試? 原因有三：
川. 開發(fā)者的水平各有不同，有的寫出來的東西性能高，有的低，所以需要統(tǒng)一測試一下。
2. 編程工具本身也有性能問題，用這樣的工具開發(fā)出來的軟件也要確認一下是否達到了需求所要求的性能指標，比如響應時間應該控制在多少秒以內(nèi)。
3. 性能測試，強度測試都是為了測試系統(tǒng)的穩(wěn)定性，穩(wěn)定性好，軟件的質(zhì)量就好，買的錢就多。

問題五：如何進行Web服務的性能測試 貼一篇我們內(nèi)部的文章：
隨著瀏覽器功能的不斷完善，用戶量不斷的攀升，涉及到web服務的功能在不斷的增加，對于我們測試來說，我們不僅要保證服務端功能的正確性，也要驗證服務端程序的性能是否符合要求。那么性能測試都要做些什么呢？我們該怎樣進行性能測試呢？
性能測試一般會圍繞以下這些問題而進行：
1. 什么情況下需要做性能測試？
2. 什么時候做性能測試？
3. 做性能測試需要準備哪些內(nèi)容？
4. 什么樣的性能指標是符合要求的？
5. 性能測試需要收集的數(shù)據(jù)有哪些？
6. 怎樣收集這些數(shù)據(jù)？
7. 如何分析收集到的數(shù)據(jù)？
8. 如何給出性能測試報告？
性能測試的執(zhí)行過程及要做的事兒主要包含以下內(nèi)容：
1. 測試評估階段
在這個階段，我們要評估被測的產(chǎn)品是否要進行性能測試，并且對目前的服務器環(huán)境進行粗估，服務的性能是否滿足條件。
首先要明確只要涉及到準備上線的服務端產(chǎn)品，就需要進行性能測試。其次如果產(chǎn)品需求中明確提到了性能指標，那也必須要做性能測試。
測試人員在進行性能測試前，需要根據(jù)當前的收集到的各種信息，預先做性能的評估，收集的內(nèi)容主要包括帶寬、請求包大小、并發(fā)用戶數(shù)和當前web服務的帶寬等
2. 測試準備階段
在這個階段，我們要了解以下內(nèi)容：
a. 服務器的架構是什么樣的，例如：web服務器是什么？是如何配置的？數(shù)據(jù)庫用的是什么？服務用的是什么語言編寫的？；
b. 服務端功能的內(nèi)部邏輯實現(xiàn)；
c. 服務端與數(shù)據(jù)庫是如何交互的，例如：數(shù)據(jù)庫的表結構是什么樣的？服務端功能是怎樣操作數(shù)據(jù)庫的？
d. 服務端與客戶端之間是如何進行交互的，即接口定義；
通過收集以上信息，測試人員整理出服務器端各模塊之間的交互圖，客戶端與服務端之間的交互圖以及服務端內(nèi)部功能邏輯實現(xiàn)的流程圖。
e. 該服務上線后的用戶量預估是多少，如果無法評估出用戶量，那么可以通過設計測試執(zhí)行的場景得出這個值；
f. 上線要部署到多少臺機器上，每臺機器的負載均衡是如何設計的，每臺機器的配置什么樣的，網(wǎng)絡環(huán)境是什么樣的。
g. 了解測試環(huán)境與線上環(huán)境的不同，例如網(wǎng)絡環(huán)境、硬件配置等
h. 制定測試執(zhí)行的策略，是需要驗證需求中的指標能否達到，還是評估系統(tǒng)的*處理能力。
i. 溝通上線的指標
通過收集以上信息，確定性能測試用例該如何設計，如何設計性能測試用例執(zhí)行的場景，以及上線指標的評估。
3. 測試設計階段
根據(jù)測試人員通過之前整理的交互圖和流程圖，設計相應的性能測試用例。性能測試用例主要分為預期目標用戶測試，用戶并發(fā)測試，疲勞強度與大數(shù)量測試，網(wǎng)絡性能測試，服務器性能測試，具體編寫的測試用例要更具實際情況進行裁減。
用例編寫的步驟大致分為：
a. 通過腳本模擬單一用戶是如何使用這個web服務的。這里模擬的可以是用戶使用web服務的某一個動作或某幾個動作，某一個功能或幾個功能，也可以是使用web服務的整個過程。
b. 根據(jù)客戶端的實際情況和服務器端的策略，通過將腳本中可變的數(shù)據(jù)進行參數(shù)化，來模擬多個用戶的操作。
c. 驗證參數(shù)化后腳本功能的正確性。
d. 添加檢查點
e. 設計腳本執(zhí)行的策略，如每個功能的執(zhí)行次數(shù)，各個功能的執(zhí)行順序等
4. 測試執(zhí)行階段
根據(jù)客戶端的產(chǎn)品行為設計web服務的測試執(zhí)行場景及測試執(zhí)行的過程，即測試執(zhí)行期間發(fā)生的事兒。通過監(jiān)控程序收集web服務的性能數(shù)據(jù)和web服務所在系統(tǒng)的性能數(shù)據(jù)。
在測試執(zhí)行過程中，還要不斷的關注以下內(nèi)容：
a. web服務的連接速度如何？
b. 每秒的點擊數(shù)如何？
c. Web服務能允許多少個用戶同時在線？
d. 如果超過了這......>>

問題六：網(wǎng)站性能測試主要有哪幾種方法? 我知道的性能測試主要有：壓力測試，負載測試，容量測試，發(fā)性能測試，兼容性測試（不同的操作系統(tǒng)和不同的瀏覽器）。測的時候應用在客戶端的性能、應用在網(wǎng)絡上的性能和應用在服務器端的性能都要進行測試的。
希望能幫到你。

問題七：怎么才能做性能測試工程師？ 性能測試實際上確實需要些功底兒，但是也并不是非得一兩年之后才去做。
我給你列幾條性能測試工作中的建議，你可以自己溫習一下，然后去面試，具體的經(jīng)驗需要實際的工作才能得到，然而你扎實的基礎知識才識支撐你走下去的動力。
1，最直接也是最表面的建議，適用于面試：, HttpWatch, Dynatrace, TeamQuest, JMeter(可選), Wily(可選), HTML/HTTP, , Mainframe, DB. 這些東西足夠?qū)W很久很久的了，所以說需要幾年的工夫，但是沒必要每一樣都學太深，了解即可，經(jīng)驗日后會積累到的。
2，相對比較深層的建議：性能測試最關鍵之處不是工具的選擇，而是對整個性能參數(shù)的理解，所以比較貼近于概念，比如說什么是TPS, Response Time, 浮 per Second....還有就是什么是CPU , FreeMem, Disk IO, Paging.... 工具也無非都是通過日積月累形成的客戶端，所以抓到本質(zhì)才是關鍵。

不在這里長篇大論了，呵呵，加油！

問題八：性能測試應該怎么做 需求分析 － 測試設計 － 測試執(zhí)行 － 結果分析

問題九：APP如何做性能測試 目前市面上有很多家做安全加密的平臺都有做安全檢測，但是大部分需要付費，如果說只是個小項目的話花錢去做的話成本太高，也不建議去做
你可以了解下愛內(nèi)測這個平臺，專門做測試的，有安全檢測、兼容測試、插件評估等，雖然這個平臺也是付費的，但是他有免費的版本提供，個人覺得安全檢測免費版本已經(jīng)足夠強大了，自動化生成測試報告，提供精準的檢測數(shù)據(jù)
希望可以幫助到你

問題十：服務端怎么做性能測試 使用LR對數(shù)據(jù)庫進行性能測試，實際上有多種辦法，包括通過現(xiàn)有的數(shù)據(jù)庫協(xié)議進行CS模式的先錄制后執(zhí)行的模式，以及通過socket方式向服務器發(fā)包方式的測試方式。這些是常規(guī)書籍上介紹的比較簡單上手的測試方法，但是不具備通用性，受已有協(xié)議或socket編程方式的限制，所以需要更為通用的測試方法。
用Java user的協(xié)議進行所有數(shù)據(jù)庫性能的測試工作：
Java user 不需要錄制，把所有的操作通過java語言進行實現(xiàn)，通過lr調(diào)用java的class進行加壓批量操作，這樣可以不關心被測系統(tǒng)是哪個數(shù)據(jù)庫，只要能夠通過jdbc進行訪問，就能實現(xiàn)性能測試。
一、測試環(huán)境準備
1. 被測服務器準備，根據(jù)測試目的，搭建需要的數(shù)據(jù)庫服務器，確保數(shù)據(jù)庫能夠正常訪問，正常操作；
2. Java代碼的準備，無論使用哪種IDE，只要能夠編寫訪問數(shù)據(jù)庫的class就可以，形式可以是j2se，也可以是j2ee，因為在操作時只使用class的部分方法，所以j2ee就可以了；
3. LR的腳本調(diào)試，把java的class導入到腳本調(diào)試模式，根據(jù)需要添加事務以及其他操作。
二、編寫數(shù)據(jù)庫訪問
1. 使用myeclipse，創(chuàng)建web project，創(chuàng)建如下圖的包目錄：
Java文件中包含各種訪問數(shù)據(jù)庫的方法。
需要注意的是，class中的方法必須是public static，否則LR中無法調(diào)用。由于創(chuàng)建的是j2ee程序，所以不用main函數(shù)，在web中就可以進行功能驗證。
確認class中的方法編寫完成，創(chuàng)建一個web.jsp文件，如下：
導入class
聲明類，并實例化，直接調(diào)用剛才編寫的3個方法，因為這3個方法是直接對數(shù)據(jù)庫進行操作，不需要實參，也沒有返回值，所以直接實現(xiàn)即可。
此時啟動web服務，在瀏覽器中輸入jsp的地址，直接刷新頁面，就可以調(diào)用這3個方法，如果正確，就會對相應的表進行操作，如果不正確，則需要修改相應的代碼。
2. LR腳本準備：
LR腳本實際上就是對訪問代碼的調(diào)用，關鍵在于需要根據(jù)測試場景劃分不同的腳本布局。
例如：在myEclipse里，我們只編寫了一個class，其中包含三個方法，如果在執(zhí)行性能測試時，這三個方法相互獨立，互不干涉，則最簡單的劃分方法是，創(chuàng)建三個java user，每個java user中包含一個方法，做三份腳本，場景執(zhí)行時分別進行調(diào)用。如果三個方法之間有相互關系，則需要根據(jù)實際情況，把有關聯(lián)的方法放在一起，具體情況可按實際靈活分配。
因為已經(jīng)將class文件進行編譯發(fā)布了，所以可以在“WebRootWEB-INFclasses\lrtest”目錄中找到對應的class文件，
復制這個文件，找到LR的目錄：HP\classes\lrtest 如果沒有文件夾，按相同的內(nèi)容創(chuàng)建。
在LR腳本中進行引包操作：
將需要執(zhí)行的java類以及方法，放在action中，可根據(jù)實際測試情況和所需要驗證的內(nèi)容，具體調(diào)試代碼。
在這里可以像編寫普通LR腳本一樣，添加事務或 *** 點等內(nèi)容。
由于是通過JDBC對數(shù)據(jù)庫進行訪問，因此要在java user中加載jdbc驅(qū)動。
運行時設置中，增加jdbc驅(qū)動，需要注意的是java user使用的本地jdk，需要至多1.6版......>>