1. 関連概念
1. パフォーマンステスト関連: 負荷テスト、パフォーマンステスト、ストレステスト、安定性テスト、フルリンクテストなど。
2. パフォーマンス指標: スループット レート、tps、同時ユーザー数、スループット、応答時間など。
2. 性能試験
1. 概念分析: ツールを使用して、さまざまな動作条件下でのシステムのパフォーマンス指標値を調べたり取得したりします。主にパフォーマンス テスト ツール (jmeter、loadrunner など) またはコードを使用します。
1.1 調べる: 製品が初めて性能テストを実行するときに、性能指標値 (複数の値) を調べます。
1.1.1 判明後: これらの指標値が期待を満たしていない場合、特定の性能指標値が実際にテストした指標値よりも大きいことが予想されます。このとき、ポジショニング、分析、チューニングが必要です
1.2 取得: 製品の性能試験は初めてではなく、既存の性能指標に基づいて再度性能試験を実施し、2 つの試験結果を比較します。
1.2.1 パフォーマンス テスト ツールを使用して、さまざまな方法でマルチユーザーの同時実行をシミュレートします。
1.2.1.1 パフォーマンス テスト (サーバー側パフォーマンス テスト)。複数のユーザーがパフォーマンス テストのためにサービスのインターフェイスを呼び出す必要があります。
(1) マルチユーザー: パフォーマンス テスト、シングル ユーザー リクエストは使用できません (同時ユーザーが 1 人であることはできません)
(2) ユーザー情報は 1 つ以上とすることができますが、通常は複数の異なるユーザー情報を使用します。
注: パフォーマンス テスト結果はパフォーマンス インデックス値であり、インデックス値は要件を満たしています。パフォーマンス テスト レポートを作成できます。パフォーマンス テストは終了できます。満たされていない場合は、これらのインデックス値を位置決め、分析、および分析に使用します。チューニング
2.広義と狭義
2.1 一般化されたパフォーマンス テスト: パフォーマンス テストに関連する限り
2.2 狭いパフォーマンス テスト: パフォーマンス テストの指標を見つけるか検証するだけです (現在のパフォーマンス テストはすべて狭いパフォーマンス テストです)
2.3 一般化された同時実行性: リクエストを同時に開始します (現在のパフォーマンス テストは一般的に一般化された同時実行性です)
2.4 狭い同時実行性: 同じリクエストを同時に開始します。
3. 負荷試験
1. 概念: 同時ユーザー数を徐々に増やすことで、サーバーが耐えられる同時ユーザーの最大範囲を確認します。
1.1 同時ユーザー数: 複数人によるリクエストの送信をシミュレートするパフォーマンス テストの推進力
1.2 開始間隔を通じて、この間隔を徐々に狭めて、許容可能な最大同時ユーザー数を取得します。
難易度：最大処理能力を超えていることを確認する方法（後で分析します）
1.3 二十八原則: リクエストの 80% が 20% の確率で発生する
例: 製品の 1 日の平均訪問数が 500 万回であると仮定します。----- 1 日の Web サイトへの訪問数は 500w / 24 / 3600 ==== 1 秒間の訪問数は 58 です。 1秒あたりの訪問数
(500w*0.8 )/ (24*0.2 *3600) 28 番目の原則のリクエストの 80% が 20% の確率で発生します。
400w / 17280 == 232 1 秒あたり 232 のアクセス --- サーバーは 1 秒あたり 232 のリクエストを処理する必要があります ----TPS はユーザーが 1 秒あたり 1 回送信すると想定しています ---232 人
1.4 同時接続ユーザー数の見積もりの考え方
(1) 本番環境の 1 日あたりの平均訪問数を換算します。
(2) 本番環境の監視、監視中のその期間中の最大同時リクエスト数を確認します。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
4. ストレステスト
1. コンセプト: 一定量の同時リクエストの下で、比較的長時間実行を継続してサーバーの安定性を確認します。
1.1 時間: 通常は時間単位
1.2 サーバーにダウンタイムの問題が発生したら、ストレス テストを実行します。一般に、最初は比較的少数の同時ユーザーを使用し、次に比較的多数の同時ユーザーを使用します (同時ユーザーの最大許容数と比較して)。
注: 企業で一般的に呼ばれる圧力テストは、ストレス テストではなく、負荷とパフォーマンスのテストです。
5. 圧力試験
1. 概念: ストレス テストは、いわゆるストレス テストでも、パフォーマンス テストでもありません。企業では、通常、負荷テストとパフォーマンス テストを組み合わせたものです。
2. 操作: 圧力テストは、実際には完全な性能テストを行う必要があることを意味します。
2.1 最初に負荷テストを実行し、次にパフォーマンス テストを実行し、負荷テストを通じて許容可能な最大同時ユーザー数を取得し、次にこの最大同時ユーザー数を使用してパフォーマンス テストを実行してインデックス値を取得します。つまり、圧力テストです。 = 負荷テスト + パフォーマンステスト
6. 安定性試験
1. コンセプト: 一定数の同時ユーザーを通じてサーバーへのリクエストを開始し、サーバーが一定期間経過後も安定して実行されているかどうかを確認します。
2. 安定性試験とストレス試験の違い
2.1 違い: 同時ユーザー数。安定性テストでは最大同時ユーザー数の 20% を使用するだけで済みますが、ストレス テストでは 20%、40%、80% を段階的に使用する必要があります。
2.2 安定性: 主な理由は、一定数の同時ユーザーによる比較的長期間の連続運用中に、サーバーがより多くのリソースを占有することです。この期間中に占有しているリソースが時間内に回復できれば、サーバーはより多くのリソースを占有することになります。ダウンタイムのリスクなし: リソースが時間内に回復できない場合、リソースはますます占有され、最終的にはサーバーが耐えられる制限を超え、リソースが不足し、サービスのダウンタイムが発生します。
2.2.1 ソフトウェアやサービスは起動時に一定量のリソース（メモリ）を占有しますが、その量は起動時に決定されており、本ソフトウェアはライフサイクルを通じて一定量のリソースを使用します。このときメモリ不足によりソフトウェアが異常になることをメモリオーバーフローといいます。
2.2.2 サーバーのリソースは限られている 多くのサービスが有効になっており、各サービスが一定量のリソースを占有するため、マシン全体のリソースが不足し、マシンがクラッシュする可能性があります。
7. 能力テスト
1. 概念: 特定のソフトウェアおよびハードウェア条件下で、データベース内のデータ量が桁違いに大きい場合、システム内でより多くの読み取りおよび書き込みを行うビジネスをテストし、パフォーマンス指標値を取得します。さまざまなデータレベルで。
1.1 さまざまなデータ レベル: データベース テーブル内のデータの総量
1.2 データ規模: a. 本番データベースのデータ規模に応じて決定できます b. 製品の将来の開発傾向に応じて見積もります
2. 上記のパフォーマンス テストでは、パフォーマンス テストに最大同時ユーザー数を使用します。実際には、デフォルト条件は非表示になっています。データベース テーブルの容量は、推定されたデータ量の範囲内です。
8. まとめ
企業における性能テストでは、負荷テストを行って許容最大同時ユーザー数を取得し、次に許容最大同時ユーザー数に基づいて性能テストを実施して性能テスト指標値を取得し、判定するのが一般的です。期待を満たしている場合、要件を満たしている場合、テストは終了し、要件を満たしていない場合は、問題を特定し、分析し、最適化する必要があります。通常、ストレス テストはサーバーの安定性をテストするために最後に実行されます。
以下はサポート学習教材です。[ソフトウェア テスト] を行う友人にとって、これは最も包括的で完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を私に同行させてくれました。あなたにも役立つことを願っています。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
情報取得方法：
