LoadRunner性能測試結果分析

性能測試的需求指標：本次測試的要求是驗證在30分鐘內完成2000次用戶登陸系統，而後進行考勤業務，最後退出，在業務操做過程當中頁面的響應時間不超過3秒，而且服務器的CPU使用率、內存使用率分別不超過75%、70%

LoadRunner性能測試結果分析內容：

一、結果摘要

LoadRunner進行場景測試結果收集後，首先顯示的該結果的一個摘要信息，如圖1- 2所示。概要中列出了場景執行狀況、「Statistics Summary（統計信息摘要）」、「Transaction Summary（事務摘要）」以及「HTTP Responses Summary（HTTP響應摘要）」等。以簡要的信息列出本次測試結果。

 

圖1- 2性能測試結果摘要圖

場景執行狀況：該部分給出了本次測試場景的名稱、結果存放路徑及場景的持續時間，如圖1- 3所示。從該圖咱們知道，本次測試從15:58:40開始，到16:29:42結束，共歷時31分2秒。與咱們場景執行計劃中設計的時間基本吻合。

 

圖1- 3場景執行狀況描述圖

Statistics Summary（統計信息摘要）

該部分給出了場景執行結束後併發數、總吞吐量、平均每秒吞吐量、總請求數、平均每秒請求數的統計值，如圖1- 4所示。從該圖咱們得知，本次測試運行的最大併發數爲7，總吞吐量爲842,037,409字節，平均每秒的吞吐量爲451,979字節，總的請求數爲211,974，平均每秒的請求爲113.781，對於吞吐量，單位時間內吞吐量越大，說明服務器的處理能越好，而請求數僅表示客戶端向服務器發出的請求數，與吞吐量通常是成正比關係。

 

圖1- 4統計信息摘要圖

Transaction Summary（事務摘要）

該部分給出了場景執行結束後相關Action的平均響應時間、經過率等狀況，如圖1- 5所示。從該圖咱們獲得每一個Action的平均響應時間與業務成功率。

注意：由於在場景的「Run-time Settings」的「Miscellaneous」選項中將每個Action當成了一個事務執行，故這裏的事務其實就是腳本中的Action。

 

圖1- 5事務摘要圖

HTTP Responses Summary（HTTP響應摘要）

該部分顯示在場景執行過程當中，每次HTTP請求發出去的狀態，是成功仍是失敗，都在這裏體現，如圖5- 6所示。從圖中能夠看到，在本次測試過程當中LoadRunner共模擬發出了211974次請求（與「統計信息摘要」中的「Total Hits」一致），其中「HTTP 200」的是209811次，而「HTTP 404」則有2163，說明在本次過程當中，通過發出的請求大部分都能正確響應了，但仍是有部分失敗了，但未影響測試結果，「HTTP 200」表示請求被正確響應，而「HTTP 404」表示文件或者目錄未能找到。有朋友可能會問，這裏出現了404的錯誤，爲何結果還都經過了。出現這樣問題的緣由是腳本有些頁面的請求內容並不是關鍵點，好比可能請求先前的cookie信息，若是沒有就從新獲取，因此不會影響最終的測試結果。

 

圖1- 6 HTTP響應摘要

經常使用的HTTP狀態代碼以下：

400 沒法解析此請求。

401.1 未經受權：訪問因爲憑據無效被拒絕。

401.2 未經受權: 訪問因爲服務器配置傾向使用替代身份驗證方法而被拒絕。

401.3 未經受權：訪問因爲 ACL 對所請求資源的設置被拒絕。

401.4 未經受權：Web 服務器上安裝的篩選器受權失敗。

401.5 未經受權：ISAPI/CGI 應用程序受權失敗。

401.7 未經受權：因爲 Web 服務器上的 URL 受權策略而拒絕訪問。

403 禁止訪問：訪問被拒絕。

403.1 禁止訪問：執行訪問被拒絕。

403.2 禁止訪問：讀取訪問被拒絕。

403.3 禁止訪問：寫入訪問被拒絕。

403.4 禁止訪問：須要使用 SSL 查看該資源。

403.5 禁止訪問：須要使用 SSL 128 查看該資源。

403.6 禁止訪問：客戶端的 IP 地址被拒絕。

403.7 禁止訪問：須要 SSL 客戶端證書。

403.8 禁止訪問：客戶端的 DNS 名稱被拒絕。

403.9 禁止訪問：太多客戶端試圖鏈接到 Web 服務器。

403.10 禁止訪問：Web 服務器配置爲拒絕執行訪問。

403.11 禁止訪問：密碼已更改。

403.12 禁止訪問：服務器證書映射器拒絕了客戶端證書訪問。

403.13 禁止訪問：客戶端證書已在 Web 服務器上吊銷。

403.14 禁止訪問：在 Web 服務器上已拒絕目錄列表。

403.15 禁止訪問：Web 服務器已超過客戶端訪問許可證限制。

403.16 禁止訪問：客戶端證書格式錯誤或未被 Web 服務器信任。

403.17 禁止訪問：客戶端證書已經到期或者還沒有生效。

403.18 禁止訪問：沒法在當前應用程序池中執行請求的 URL。

403.19 禁止訪問：沒法在該應用程序池中爲客戶端執行 CGI。

403.20 禁止訪問：Passport 登陸失敗。

404 找不到文件或目錄。

404.1 文件或目錄未找到：網站沒法在所請求的端口訪問。

須要注意的是404.1錯誤只會出如今具備多個IP地址的計算機上。若是在特定IP地址/端口組合上收到客戶端請求，並且沒有將IP地址配置爲在該特定的端口上偵聽，則IIS返回 404.1 HTTP錯誤。例如，若是一臺計算機有兩個IP地址，而只將其中一個IP地址配置爲在端口80上偵聽，則另外一個IP地址從端口80收到的任何請求都將致使IIS返回404.1錯誤。只應在此服務級別設置該錯誤，由於只有當服務器上使用多個IP地址時纔會將它返回給客戶端。

404.2 文件或目錄沒法找到：鎖定策略禁止該請求。

404.3 文件或目錄沒法找到：MIME 映射策略禁止該請求。

405 用於訪問該頁的 HTTP 動做未被許可。

406 客戶端瀏覽器不接受所請求頁面的 MIME 類型。

407 Web 服務器須要初始的代理驗證。

410 文件已刪除。

412 客戶端設置的前提條件在 Web 服務器上評估時失敗。

414 請求 URL 太大，所以在 Web 服務器上不接受該 URL。

500 服務器內部錯誤。

500.11 服務器錯誤：Web 服務器上的應用程序正在關閉。

500.12 服務器錯誤：Web 服務器上的應用程序正在從新啓動。

500.13 服務器錯誤：Web 服務器太忙。

500.14 服務器錯誤：服務器上的無效應用程序配置。

500.15 服務器錯誤：不容許直接請求 GLOBAL.ASA。

500.16 服務器錯誤：UNC 受權憑據不正確。

500.17 服務器錯誤：URL 受權存儲沒法找到。

500.18 服務器錯誤：URL 受權存儲沒法打開。

500.19 服務器錯誤：該文件的數據在配置數據庫中配置不正確。

500.20 服務器錯誤：URL 受權域沒法找到。

500 100 內部服務器錯誤：ASP 錯誤。

501 標題值指定的配置沒有執行。

502 Web 服務器做爲網關或代理服務器時收到無效的響應。

二、併發數

「Running Vusers（運行的併發數）」顯示了在場景執行過程當中併發數的執行狀況。它們顯示Vuser的狀態、完成腳本的Vuser的數量以及集合統計信息，將這些圖與事務圖結合使用能夠肯定Vuser的數量對事務響應時間產生的影響。圖1- 7顯示了在OA系統考勤業務性能測試過程當中Vusers運行狀況，從圖中咱們能夠看到，Vusers的運行趨勢與咱們場景執行計劃中的設置是同樣，代表在場景執行過程當中，Vusers是按照咱們預期的設置運行的，沒有Vuser出現運行錯誤，這樣從另外一個側面說明咱們的參數化設置是正確的，由於使用惟一數進行參數化設置，若是設置不正確，將會致使Vuser運行錯誤。在腳本中咱們加入了這樣一段代碼：

 if (atoi(lr_eval_string("{num}")) > 0){

              lr_output_message("登陸成功，繼續執行.");

              }

        else{

              lr_error_message("登陸失敗，退出測試");

              return -1;

        }

上述代碼的意思是說，若是登陸失敗了，就退出腳本的迭代，那麼什麼緣由可能會致使登陸失敗呢？就是咱們前面參數化的設置，一旦Vuser分配不到正確的登陸帳號，就可能致使登陸失敗，從而引發Vuser中止運行。因此，從圖5- 7的表現，能夠認爲參數化是沒有問題的。

 

圖1- 7運行的併發數圖

測試腳本中咱們還使用了集合點，那麼這裏還能夠看看集合點在場景執行過程當中的表現，點擊左邊的「New Graph」，出現圖5- 8，展開「Vusers」前的加號，雙擊「Rendezvous」，出現集合點的圖形後，點擊【Close】，關閉添加新圖界面。

 

圖1- 8添加集合點統計圖

集合點的圖形如圖1- 9所示，從圖中能夠看到，全部用戶到達集合點後，馬上就釋放了。與以前設定的集合點策略設置「全部運行用戶到達後釋放「是一致的。假設這樣的一種狀況，Running的Vusers有10個，集合點策略設置是「全部運行用戶到達後釋放」，而集合點圖形顯示的最大釋放Vusers是7個，那麼就表示有些Vuser超時了，引發超時的緣由多是Vuser獲得的響應超時了，能夠結合平均事務響應時間再詳細分析緣由。

 

 圖1- 9集合點狀態圖

咱們本次測試Running Vusers與集合點是一致，說明整個場景執行過程當中，併發數用戶的執行正確，OA系統測試服務器可以應付7個併發用戶的業務操做。

 

三、平均事物響應時間

在性能測試要求中咱們知道，有一項指標是要求登陸、考勤業務操做的頁面響應時間不超過3秒，那麼本次測試是否達到了這個要求呢？咱們先來看「Average Transaction Response Time（平均事務響應時間圖）」（圖1- 10），這張圖是平均事務響應時間與結果摘要中的「Transaction Summary」合成的。

 

 圖1- 10平均事務響應時間圖

從圖形下部咱們能夠看到，登陸部分對應的Action是「submit_login」，考勤業務提交對應的Action是「submit_sign」，他們的「Average Time（平均響應時間爲）」分別是4.425秒與0.848秒，從這兩個數值來看，考勤業務的事務響應時間0.848秒小於預期的3秒，達到了要求，而登陸是4.425秒，大於預期的3秒，不符合要求。這樣的結果是不正確的，由於在統計的登陸業務的時候，咱們沒有去除思考時間，因此，登陸功能的實際事務時間應該是4.425秒-3秒=1.425秒，小於預期的3秒，故登陸業務的事務響應時間也達到了咱們的要求。在平時的性能測試活動中，統計結果的時候須要去掉思考時間，加上思考時間是爲了真實的模擬用戶環境，統計結果中除去思考時間是爲了更真實的反映服務器的處理能力，二者並不矛盾。

看完了「Average Time」，咱們再看「90 Percent Time」，這個時間從某種程度來講，更準確衡量了測試過程當中各個事務的真實狀況，表示90%的事務，服務器的響應都維持在某個值附近，「Average Time」值對於平均事務響應時間變更趨勢很大的狀況統計就不許確了，好比有三個時間：1秒、5秒、12秒，則平均時間爲6秒，而另一種狀況：5秒、6秒、7秒，平均時間也爲6秒，顯然第二種比第一種要穩定多了。因此，咱們在查看平均事務響應時間的時候，先看總體曲線走勢，若是總體趨勢比較平滑，沒有忽上忽下的波動狀況，取「Average Time」與「90 Percent Time」均可以，若是總體趨勢毫無規律，波動很是大，咱們就不用「Average Time」而使用「90 Percent Time」可能更真實些。

從圖1- 10能夠看出，全部Action平均事務響應時間的趨勢都很是平滑，因此使用「Average Time」與「90 Percent Time」差異不是很大，用哪一個均可以。這裏是使用最經常使用的統計方法「90 Percent Time」。登陸業務的「90 Percent Time」是5.298秒-3秒（思考時間）=2.298秒，考勤業務的「90 Percent Time」是1.469秒，沒有思考時間，那麼就是實打實的啦。根據上面的計算，本次測試結果記錄如表1所示。

測試項	目標值	實際值	是否經過
登陸業務響應時間	<=3秒	2.298秒	Y
考勤業務響應時間	<=3秒	1.469秒	Y
登陸業務成功率	100%
考勤業務成功率	100%
登陸業務總數	30分鐘完成2000
考勤業務總數	30分鐘完成2000
CPU使用率	<75%
內存使用率	<70%

表1測試結果對照表一

 

四、每秒點擊數

「Hits per Second（每秒點擊數）」反映了客戶端每秒鐘向服務器端提交的請求數量，若是客戶端發出的請求數量越多，與之相對的「Average Throughput (bytes/second)」也應該越大，而且發出的請求越多會對平均事務響應時間形成影響，因此在測試過程當中每每將這三者結合起來分析。圖1- 11顯示的是「Hits per Second」與「Average Throughput(bytes/second)」的複合圖，從圖中能夠看出，兩種圖形的曲線都正常而且基本一致，說明服務器能及時的接受客戶端的請求，並可以返回結果。若是「Hits per Second」正常，而「Average Throughput (bytes/second)」不正常，則表示服務器雖然可以接受服務器的請求，但返回結果較慢，多是程序處理緩慢。若是「Hits per Second」不正常，則說明客戶端存在問題，那種問題通常是網絡引發的，或者錄製的腳本有問題，未能正確的模擬用戶的行爲。具體問題具體分析，這裏僅給出一些建議。

 

 圖1- 11每秒點擊數與每秒吞吐量複合圖

對於本次測試來講，「Hits per Second」與「Average Throughput (bytes/second)」都是正常的，並且總體表現仍是不錯的。

通常狀況下，這兩種指標用於性能調優，好比給定了幾個條件，去檢測另一個條件，用這兩個指標衡量，每每起到很好的效果。好比要比較某兩種硬件平臺的優劣，就可使用相同的配置方法部署軟件系統，而後使用相同的腳本、場景設計、統計方法去分析，最終得出一個較優的配置。

 

五、業務成功率

「業務成功率」這個指標在不少系統中都說起到，好比電信的、金融的、企業資源管理的等等。舉個例子，咱們樓下的建行，假如天天的業務類別是這樣的：20個開戶，5個銷戶，300個存款，500取款，100個匯款等，那麼在作他們的營業系統測試時就須要考慮業務成功率了，通常不得低於98%。具體的業務成功率是什麼意思呢？排除那些複雜的業務，好比異步處理的業務（移動的套卡開通就是異步的），業務成功率就是事務成功率，用戶通常把一個Aciton當作一筆業務，在LoadRunner場景執行中一筆交易稱爲一個事務。因此說業務成功率其實就是事務成功率、經過率的意思。在「Transaction Summary」中咱們能夠很明確的看到每一個事務的執行狀態，如圖1- 12所示。

 

 圖1- 12事務狀態統計圖

從圖中能夠看出，全部的Aciton都是綠色的，即表示爲Passed，同時除了vuser_init與vuser_end兩個事務，其餘的事務經過數爲2163，也就代表在30分鐘的時間裏，共完成了2163次登陸考勤業務操做。那麼根據這些能夠判斷本次測試登陸業務與考勤業務的成功率是100%，再次更新測試結果記錄表如表2所示。

測試項	目標值	實際值	是否經過
登陸業務響應時間	<=3秒	2.298秒	Y
考勤業務響應時間	<=3秒	1.469秒	Y
登陸業務成功率	100%	100%	Y
考勤業務成功率	100%	100%	Y
登陸業務總數	30分鐘完成2000	2163	Y
考勤業務總數	30分鐘完成2000	2163	Y
CPU使用率	<75%
內存使用率	<70%

表2測試結果對照表二

 

六、系統資源

系統資源圖顯示了在場景執行過程當中被監控的機器系統資源使用狀況，通常狀況下監控機器的CPU、內存、網絡、磁盤等各個方面。本次測試監控的是測試服務器的CPU使用率與內存使用率，以及處理器隊列長度，具體的數據如圖1- 13所示。

 

 圖1- 13測試服務器系統資源監控結果圖

從圖中能夠看出，CPU使用率、可用物理內存、CPU的隊列長度三個指標的曲線逗較爲平滑，三者的平均值分別爲：53.582%、83.456M、8.45，而測試服務器總的物理內存爲384M，那麼內存使用率爲（384-83.456）/384=78.26%，根據本次性能測試要求的：CPU使用率不超過75%，物理內存使用率不超過70%這兩點來看，內存的使用率78.26%大於預期的70%，故內存使用率不達標。根據Windwos資源性能指標的解釋，通常狀況下，若是「Processor Queue Length（處理器隊列長度）」一直超過二，則可能表示處理器堵塞，咱們這裏監控出來的數值是8.45，並且整體上保持平衡，那麼由此推斷，測試服務器的CPU也多是個瓶頸。同時在測試過程當中，場景執行到23分半鐘的時候，報出了錯誤！未找到引用源。的錯誤，意思是說被監控的服務器當前沒法再進行計數器數據的獲取了，因此，本次操做系統資源的監控只獲得了場景執行的前23分半鐘的數據。這樣對本次測試結果有必定的影響。

得到上述數據後，最新的測試結果記錄表如表3所示。

測試項	目標值	實際值	是否經過
登陸業務響應時間	<=3秒	2.298秒	Y
考勤業務響應時間	<=3秒	1.469秒	Y
登陸業務成功率	100%	100%	Y
考勤業務成功率	100%	100%	Y
登陸業務總數	30分鐘完成2000	2163	Y
考勤業務總數	30分鐘完成2000	2163	Y
CPU使用率	<75%	53.582%	Y
內存使用率	<70%	78.26%	N

表3測試結果對照表三

從上表數據來看，本次測試整體上已經達到了預期的性能指標，但從其餘的數據，好比CPU的隊列長度、內存使用率來看，被測服務器的硬件資源須要提高。

 

七、網頁細分圖

網頁細分圖能夠評估頁面內容是否影響事務響應時間。使用網頁細分圖，能夠分析網站上有問題的元素（例以下載很慢的圖像或打不開的連接）。

咱們這裏查看一下網頁細分圖中的「Page Download Time Breakdown」，點擊錯誤！未找到引用源。左邊的「New Graph」，出現圖1- 14，展開「Web Page Diagnostics」前的加號，雙擊「Page Download Time Breakdown」，待出現「Page Download Time Breakdown」監控圖後，點擊【Close】按鈕關閉添加監控圖界面。

 

 圖1- 14添加網頁細分圖

在監控圖列表中，咱們看到圖1- 15，從圖中咱們看到，在全部的頁面中，登陸後的用我的面頁面的下載時間最長。

 

圖1- 15網頁下載時間細分圖

圖1- 16詳細列出了每一個頁面所消耗的時間分佈，圖中每個指標含義見表4所示。該表由LoadRunner使用手冊提供。經過這些指標的數據，咱們能夠輕易的判斷是哪一個頁面、哪一個請求致使了響應時間變長，甚至響應失敗。

 

圖1- 16 oa.jsp頁面下載時間分佈圖

名稱	描述
Client Time	顯示因瀏覽器思考時間或其餘與客戶端有關的延遲而使客戶機上的請求發生延遲時，所通過的平均時間。
Connection  Time	顯示與包含指定URL的Web服務器創建初始鏈接所需的時間。鏈接度量是一個很好的網絡問題指示器。此外，它還可代表服務器是否對請求作出響應。
DNS Resolution Time	顯示使用最近的DNS服務器將DNS名稱解析爲IP地址所需的時間。DNS查找度量是指示 DNS解析問題或DNS服務器問題的一個很好的指示器。
Error Time	顯示從發出HTTP請求到返回錯誤消息（僅限於HTTP錯誤）這期間通過的平均時間。
First Buffer Time	顯示從初始HTTP請求（一般爲GET）到成功收回來自Web服務器的第一次緩衝時爲止所通過的時間。第一次緩衝度量是很好的Web 服務器延遲和網絡滯後指示器。 （注意：因爲緩衝區大小最大爲8K，所以第一次緩衝時間可能也就是完成元素下載所需的時間。）
FTP Autherntication Time	顯示驗證客戶端所用的時間。若是使用 FTP，則服務器在開始處理客戶端命令以前，必須驗證該客戶端。FTP驗證度量僅適用於 FTP協議通訊
Receive Time	顯示從服務器收到最後一個字節並完成下載以前通過的時間。接收度量是很好的網絡質量指示器（查看用來計算接收速率的時間 / 大小比率）。
SSL   Handshaking Time	顯示創建SSL鏈接（包括客戶端hello、服務器hello、客戶端公用密鑰傳輸、服務器證書傳輸和其餘部分可選階段）所用的時間。此時刻後，客戶端和服務器之間的全部通訊都被加密。SSL握手度量僅適用於HTTPS通訊。

表4網頁下載時間細分指標說明

對於本次測試，從網頁細分圖來看，基本上每一個頁面的加載時間都是預期範圍內，oa.jsp頁面由於集成了用戶的我的工做平臺，須要檢索不少的數據，併合成了不少圖片，因此相應的加載時間較長，這是正確的。

 

八、Web服務器資源

上述全部的監控圖形LoadRunner均可以提供，但對於某些測試監控圖來講，LoadRunner就沒有提供了，指望其新版支持這些功能，固然想監控Tomcat、Jboss或者其餘的Web服務器能夠SiteScope工具，這個工具配置較爲複雜，根據我的須要吧。我這裏監控Tomcat使用的是ManageEngine Applications Manager 8的試用版，測試結束後得出Tomcat的JVM使用率如圖1- 17所示。

 

圖1- 17 Tomcat JVM使用率監視圖

從圖中咱們能夠明顯看出，Tomcat的JVM使用率不斷上升，配置Tomcat時共分配了100M左右的物理內存給其，測試初期使用的JVM相對來講較少，咱們的測試場景是從15:58:40開始，到16:29:42結束，共歷時31分2秒。從圖中看到，從16:00到16:30這個時間內，也就是測試場景執行期間，JVM的使用率不斷上升，並無在請求達到均衡狀態後也呈現一種平衡狀態，因此，從這點能夠推斷，若是測試場景繼續執行，或者加大併發數，最終必將致使Tomcat內存不夠用而報出「Out Of Memory」內存溢出的錯誤。在正常狀況下，內存的使用應該與「Hit per Second」、「Average Throughput (bytes/second)」等監控圖的圖形走勢是一致的。

從上述過程能夠得出一個結論，出現圖1- 17中的問題，可能有兩個緣由：

一、Tomcat的內存分配不足；

二、 程序代碼有錯誤，可能致使內存泄露。

解決方法：

一、  爲Tomcat分配更多的內存，若是是使用的catalina.sh或Catalina.bat啓動的Tomcat，則可在這兩個文件中添加「SET CATALINA_OPTS= -Xms300m–Xmx300m」，若是使用的winnt服務方式啓動的Tomcat，則可在「運行」中輸入「regedit」進入註冊表，而後在「HKEY_LOCAL_MACHINE-->SOFTWARE-->Apache Software Foundation-->Process Runner 1.0-->Tomcat5-->Parameters」修改兩個屬性，一個是JvmMs，另一個是JvmMx，如圖1- 18所示。

二、檢查程序代碼，使用一些內存泄露檢查工具進行清查。

 

 圖1- 18修改Tocat的JVM數據

 

九、數據庫服務器

數據庫服務器資源監控相對來講就複雜的多了，如今經常使用的數據有Mysql、SQL Server、Oracle、DB2等，LoadRunner提供對後面幾種數據庫的監控方法，但對Mysql沒有提供對應的監控方法。他不提供，我們就本身找監控工具，我這裏使用的是Spotlight，該工具監控數據庫的好處是配置鏈接簡單，不只能監控數據庫，還能監控操做系統的資源，監控結果直觀明瞭。錯誤！未找到引用源。顯示了Mysql數據庫在場景執行過程當中SQL語句的執行狀況，從圖中能夠看到，「Selects（查詢）」與「Inserts（插入）」兩種語句執行的趨勢在場景執行過程當中是比較平滑，而且測試中沒有錯誤發現，也就說明在處理相關業務時Mysql的處理是正常的。假如這兩種SQL語句任何一個出現波動很大的狀況，就能夠推出在場景執行過程當中存在頁面錯誤，由於這些語句不執行，就代表某些頁面未被加載或者某些功能未被使用。在本次測試中，OA系統的「oa.jsp」頁面有大量的「Selects（查詢）」語句，而考勤操做則是「Inserts（插入）」，因此，只要有一方出問題，必然表示測試過程當中存在頁面打不開或者考勤不成功的錯誤。

經過前面的分析，在查看錯誤！未找到引用源中的SQL語句執行狀態，本次測試在頁面訪問、功能執行方面是沒有問題的。