Web パフォーマンス テストでよくある問題は何ですか?

1. 現在 jmeter を勉強中なのですが、初期段階のパフォーマンスに関しては何から始めればよいでしょうか？

Jmeter と LR は、現在、パフォーマンス テストに推奨されるツールです。LR の学習経験がある場合は、スレッドとプロセスの概念を理解することに重点を置いて、すぐに Jmeter を使い始めることができます。プロセスは次のようなものです。 LRのこと。そうでない場合は、入門的な観点から、まず一般的なネットワーク プロトコルとオペレーティング システムのスレッドとプロセスの概念を理解することをお勧めします。Java は Jmeter に最適であり、プログラミングの基本をいくつか理解することを検討してください。 PS: 実際、最初に Jmeter を使用してインターフェイス テストを学習すると、パフォーマンスをよりよく理解できるようになります。

2. 基本的な知識のないコンピュータ ハードウェアの専門家がこの業界に転職したい場合、どのような準備が必要ですか?

コンピュータ ハードウェアには、コンピュータの基本的な知識がすでに備わっています。ソフトウェアの変換は比較的簡単です。次のような観点から準備を検討できます:

1) まず、必要なネットワークとオペレーティング システムの部分を準備します。得意分野: ネットワークは主にアプリケーション層プロトコルであり、パフォーマンスとインターフェイスのテストへの道を開きます。オペレーティング システムは主にテスト環境の構築に使用されます。

2) プログラミング言語に精通していることが推奨されますJava または Python は両方とも推奨される言語です。熟練度は必要ありません。少なくとも、簡単なスクリプトを作成できる必要があります。

3) 包括的な専門ソフトウェア テストの本を見つけて、集中的に読みます。集中的に読む必要があります。

4) 可能であれば、練習できるプロジェクトを見つけて、機能テストから始めるのが最善です。

3. 現在インターフェイスのテストを行っていますが、先に進むとまだ混乱するでしょう。さらに、あなたが管理職に就いているとき、従業員に対する一般的な態度や態度はどのようなものですか?どのようにトレーニングし、どのように仲良くなり、タスクを割り当て、プロジェクトの進捗と品質を管理するか?

これは大きな問題です。重要なポイントをいくつか挙げておきます:

1) インターフェイスのテストは、実際にはプロトコルのテストです。ネットワーク プロトコルから始めることをお勧めします。あなたはインターフェイステストで良い仕事ができます

2) テスト管理の仕事に関しては、人によって異なると思います。生まれつき強い人もいますが、より穏やかな人もいます。最も重要なことは、自分の力が足りなければ、熊を巣に連れ込むようなものだと言いますが、それが理由であり、それが重要ではなく、存在が重要なのです。

3) 教育、人間関係、仕事の割り当てについては、管理ルールです。一般的な考え方は、長所を活かして短所を補うことです。完璧な人間はいませんし、ほとんどの人がそう感じています。彼らはリーダーより優れているので、すべての従業員が自分の価値を最大化し、達成感を得ることがより重要です。

4) プロジェクトの進捗と品質の管理 これは手法の問題です。テストのバージョン管理、欠陥分析など、さまざまな方法があります。ソフトウェア エンジニアリング、アジャイル プロセスに関する情報を参照してください。 、など。お役に立てば幸いです。

4. ストレス テストには Loadrunner を使用すると、応答時間は実際よりもはるかに長くなります。ストレス テストには LR を使用すると、平均応答時間は数十秒です。実際に手動で開くと、リンクは 1 秒未満です。ギャップは非常に大きいです。この問題が発生する原因は何ですか?

たとえば、下の図では仮想ユーザーが十数個しかなく、応答時間はわずか 10 秒ですが、実際のエクスペリエンスは依然として非常に高速です。

最初の推測は、応答時間が不適切に設定されているということです。たとえば、ログイン スクリプトを記録し、ログイン応答時間を記録したいとします。トランザクション関数を挿入します (関数のセットであることに注意してください)。 LR スクリプトに入力した場合、応答時間は 5 秒ですが、実際にログインすると 1 秒を感じられません。ユーザー名とパスワードを入力する時間も含め、関数の位置が間違っている可能性があります。または、応答時間関数に思考時間が含まれている可能性があります。前者のトランザクションの位置を調整するか、後者の実行時設定で思考時間を除外する必要があります。参考までに

5. プログラムのページ要素をキャプチャする方法を教えてください。 Selenium Web のようにページ要素をキャプチャしますか?何か良いツールや方法はありますか？

ページ要素をキャプチャするには、Chrome デベロッパー ツールの要素オプションを使用することをお勧めします。 Selenium の使用に加えて、自動テストに QTP (ALM) の使用を検討することもできます

6. ソフトウェア疲労テストはどのように行うべきですか?

一般的には、圧力試験が行われます。圧力試験はプロジェクトやビジネスによって異なります。推奨される圧力は 4H のピーク圧力の 80%、24H の 3 種類です。 60p % で制御され、もう 1 つは 7*24 時間です (50% の一定圧力を持つものもあれば、時間に基づいて圧力値が変動するものもあります)

7. 実行する前に行う必要がある準備B/Sシステムのストレステスト?システムを客観的に分析するにはどうすればよいでしょうか? Loadrunner はストレステストツールとしてしか触ったことがなかったので、これから使おうと思っているのですが、あまり詳しくなく、その中で行う必要があるシステムインジケーターの設定が非常に面倒そうで、システムを分析する方法がわかりません。ストレス テストを実行する前に、使い慣れたツールを選択することに加えて、他にどのような準備が必要ですか?

ご質問を 1 ～ 2 文で明確に説明するのは困難です。事前準備作業に関しては、パフォーマンス テスト プロジェクトにおける私の個人的な意見を話すことしかできません:

1) 最初の実施要件の予備分析、どのリンクにパフォーマンス テストが必要か、つまり、システムにとって最もストレスのかかるポイントがどこであるかを判断します

2) 既存のリソースを確認し、事前に環境を準備します。環境と運用環境を 1:1 でテストします (どうしてもできない場合は、できるだけ近づけるように努めるべきです。これは非常に重要です。そうでない場合は、比例変換を行う必要があります)

3) テスト対象のシステムで使用されているプロトコルと、オペレーティング システムやアプリケーション サーバーなどのさまざまな構成を確認し、一致するテスト ツールを選択します (ほとんどの WEB システム LR で処理できます)

4）看時間，大多數情況下效能測試的時間並不充裕，需要抓重點優先測試。

8、如何取捨Loadrunner和Jmeter？

全看心情，玩笑哈~~如果從學習入門的角度就看程式碼和網路基礎，如果程式碼和網路基礎還不錯直接用Jmeter入門就好，反之用LR入門更好。如果從企業應用的角度看哪種比較合適，對受測系統支援的較好。

工具只是形式，理解效能測試的基本原理用什麼工具都可以的。

9、對Java頻繁GC怎麼定位問題?

請嘗試用profiler尋找記憶體異常，例如短時間過多的物件創建，或是較大的物件創建。

10、我想實現50個用戶並發上班打卡簽到，參數化、迭代已設，然後，在簽到函數前面添加了集合點函數,運行結果發現，用戶簽到後返回的簽到時間是一分鐘一個，並沒有在同一個時間點簽到！請教這是為什麼？如何解決?

先去掉集合點試試看呢？同時啟動50個使用者並行（不設定集合點也可以實現並發操作的），如果還是持續一分鐘，那請你檢查事務時間和思考時間，事務時間是需要你手動配置的，思考時間預設是啟動狀態，你可以在Runtime Setting中查看一下，有可能你最終得到的1分鐘是整個腳本運行一次的時間或者是包含了思考時間的結果，不是同時打卡的時間。

11、請問電商秒殺產品是如何測試的？

和其他產品的測試沒有太大區別，主要是對時間點的要求比較高，可以考慮在效能測試腳本中使用集合點函數實現同一秒鐘的並發。

12、壓力測試和效能測試一樣嗎？

分類方法各有不同，沒有定論，普遍來講效能測試是這類測試的統稱。我傾向於下面的分類方式

性能測試（狹義）——性能測試方法是在特定的運行環境下，透過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否滿足生產性能要求。

基準測試－在一定的軟體，硬體和網路環境下，模擬一定數量的使用者運行一種或多種業務，將測試結果作為基準數據，以供後續測試活動參考。

負載測試－透過在被測系統上不斷加壓，直到效能指標達到極限，例如「反應時間」超過預定指標或某種資源已經達到飽和狀態。

壓力測試－壓力測試也稱為強度測試，主要測試系統在一定飽和狀態下，例如cpu、內部存在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。注意：在保持在80％左右的極限值下持續運行2-4小時

配置測試－配置測試方法透過對被測系統的軟\硬體環境的調整，了解各種不同對系統的性能影響的程度，從而找到系統各項資源的最適分配原則。

可靠度測試－在系統載入一定業務壓力的情況下，讓系統運作一段時間，以此偵測系統是否穩定。

並發測試－並發測試方法透過模擬使用者並發訪問，測試多使用者並發訪問同一個應用程式、同一個模組或資料記錄時是否存在死鎖或其者他效能問題。

PS：分類其實不那麼重要，在實際專案中往往都是混合應用的

13、Web效能測試除了並發登陸以外，還有哪些比較常見的測試場景？

場景取決於業務，例如你是電商網站，你肯定要測試同時下訂單的情況? ?；如果你是醫院掛號網站，你肯定要測試多人搶一個醫生的號源；如果你是銀行系統，要考慮多人同時提款吧？

14、一般網站壓力多大百萬用戶？

這要看計算方式，理論值100萬/天的業務訪問量  拆分到每秒鐘是非常少的；但這不符合實際情況。

根據線上資料可以直接推導出每天有幾個峰值時段以及其對應的並髮用戶量

如果系統未上線，可以利用2/8原則，80%用戶集中在20%的時段，推導出業務訪問量

15、目前遇到一個問題，在一台配置為8g，i3的win7系統運行壓力測試，並發總是上不去，總是在140左右就會出現異常，超時等問題，請問如何分析呢，是因為伺服器還是電腦的問題？

伺服器壓力上不去可以從以下維度分析：

網路流量是否有限制、

資料庫/應用程式伺服器是否報了異常，如果有請查看日誌;

查看作業系統的資源監控情況，CPU佔用率如何，是否達到了100%

程式碼方面是否存在效能問題，可以在大並發存取的時候手動存取系統，看看業務上有無異常。

以上がWeb パフォーマンス テストでよくある問題は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。