テストを始めて 1 年以上経ちますが、普段の仕事はきちんとこなせるのですが、テストに関する全体的な知識体系がよく理解できていないことに気づき、空いた時間にいくつかのテストを行っています。 . 知識の補足です。欠点については、お互いにコミュニケーションをとり、学び合ってください。
さて、普段の仕事は自動テストですが機能テストのほうが多いようですが、今日はパフォーマンステストについて学びました。
同時に、テスト ツールについては、頻繁に使用する限り、慣れるかどうかは時間の問題ですが、テストの基本をマスターし、いくつかのテストのアイデアや概念を理解することで、メリットは無限大です。
パフォーマンス テストについて学んだことの要約は次のとおりです。
パフォーマンス テスト (パフォーマンス テスト):自動テスト ツールを使用して、さまざまな正常、ピーク、および異常な負荷条件をシミュレートすることにより、システムのさまざまなパフォーマンス指標をテストします。負荷テストとストレス テストはどちらもパフォーマンス テストです。負荷テストを通じて、さまざまなワークロード下でのシステムのパフォーマンスを確認します。目標は、負荷が徐々に増加したときのシステムのさまざまなパフォーマンス指標の変化をテストすることです。ストレス テストは、システムのボトルネックまたは許容できないパフォーマンス ポイントを特定することにより、システムが提供できる最大のサービス レベルを取得するテストです。
負荷テスト ( Load Testing ):実際のソフトウェアの負荷状態をシミュレートするシステム負荷です。継続的な負荷 (シミュレートされるユーザーの数を徐々に増やすなど) またはその他の負荷方法を通じて、ソフトウェアの応答時間とデータ スループットを観察します。システムが占有しているリソース (CPU、メモリなど) は、システムの動作と特性をテストして、システム内の潜在的なパフォーマンスのボトルネック、メモリ リーク、リアルタイム同期の問題を検出するために使用されます。負荷テストは、方法やテクノロジーをより反映します。
ストレス テスト (ストレス テスト):強力な負荷 (大量のデータ量、多数の同時ユーザーなど) の下でテストし、ピーク使用条件下でアプリケーション システムの動作動作をチェックし、隠された特定の機能を効果的に発見します。システムの危険性、およびシステムの耐障害性と回復性が優れているかどうか。ストレス テストは、高負荷下での長期 (24 時間以上など) 安定性ストレス テストと、極端な負荷条件下でシステム クラッシュを引き起こす破壊的ストレス テストに分けることができます。
3 つの違い: テストの目的とユーザーのニーズから、パフォーマンス テスト、負荷テスト、ストレス テストを区別する方が簡単です。パフォーマンス テストは、特定の条件 (特定の負荷条件を含む) でシステムのパフォーマンス指標データを取得することです。負荷テストとストレス テストは、パフォーマンスのボトルネックやメモリ リークなど、ソフトウェア システムの問題を発見することです。負荷テストに合格するということは、システムが正常に動作する際に耐えられる最大負荷を求めることでもあり、このときの負荷テストが容量テストとなります。ストレス テストを通じて、システムがどのような極端な条件でクラッシュするか、システムが自己回復するかどうかなどを知ることができますが、それ以上にシステムの安定性を判断することができます。
パフォーマンス テスト ツール (現時点ではこれらのツールしか知りません。使用方法については、後で使用方法をまとめます):
(1) Apache Jmeter: ユーザーマニュアルApache JMeter - ユーザーマニュアル
(2) ロードランナー
(3) QTP(クイックテスト)
(4) ウェブポリグラフ
パフォーマンス テストでは、テスト ツールに慣れるだけでなく、テストのアイデアも重要です。パフォーマンス テストに関する 3 つの概念を次に示します。
- 正確かつ曖昧
つまり、車が100キロメートル走行するにはどれくらいのガソリンが必要ですか?
仮定を立てます。仮定には 3 つの段階があります。
a. 思い込みをしていることに気づかずに思い込みをする
自分の経験に基づいてテストを行い、他の人が見てもらえるようにテスト レポートを作成する人もいます。重要なのは、自分のテストが正しいと思っているということですが、自分の環境に全員がいるわけではありません。自分がテストしたときと同じ方法で実行してください。 test 全く同じことなので、テスト結果は他の人を誤解させるだけです。例えば、先ほどの燃費の問題ですが、100キロ走って確認して、できるだけ多く取るということをやっている人もいます。
b. 思い込みが多すぎる
「路面が滑らかで、ずっと緑で、風速が 5km/h、体重 70kg の乗客が 1 名だけ、速度が 70km/h で安定、運転習慣が良い場合、…、燃費は7.1L/100km」 これは非常に厳密かもしれませんが、レポートの読者にとって、そのようなデータはあまり意味がありません。
c. 必要かつ合理的な仮定を立てる
人生には、それが必要かつ合理的であれば、妥協や妥協が必要なときがあります。話が飛びますが、テストでは貴重な情報を提供する必要があるため、そのような貴重な情報に対して必要な合理的な仮定を行うことは許容されます。
- マクロとミクロ
これも興味深い対比です。パフォーマンス テスト、特に製品全体のパフォーマンス テストを行う場合、製品のコア機能と、データベース、Web サーバー、コアデーモンなどの主要な機能モジュールが確認されます。たとえ描かなくても、私たちの頭の中にはアーキテクチャ図があります。そのため、パフォーマンス テストには、特定の詳細ではなく大きなコンポーネントに注目する、製品に対するマクロ的な視点があると考えられることがあります。
本当にそうですか？以下の例を見てください。
1. デーモンのログ レベルをデバッグに変更した後 (log_level が 2 から 5 に変更された)、パフォーマンスがほぼ半分に低下しました。
2. キャッシュ オプションをオフにする
3. キープアライブ オプションをオンにする
4.DNS逆引き参照を開く
……
上記はすべて細かい設定であり、DB の特定のテーブルまたは ini に隠された単なる構成項目です。ただし、変更後は、得られるパフォーマンス結果が大きく異なる場合があります。
現時点では、実際のところ、細部を考慮するかどうかは、主にその人が批判的かどうかによって決まります。何が重要なのかについては、今後の作業で検討し、まとめる必要があります。
- プロジェクトとタスク
パフォーマンス テストは、それを行うよう割り当てられた人にとっても、それを手配した人にとっても、それ自体が確かにタスクです。しかし、それを行う人にとって、それはプロジェクトのようなものである場合もあります。なぜ？
まずはたくさんの人と関わる必要があります。
プロダクト マネージャーまたは顧客: 要件を取得し、目標を設定します。
QA マネージャー/リーダー: リソースとスケジュールについて話し合います。必要なマシン、環境、ソフトウェア、および全体の計画が含まれます。
開発者: 問題の発見、調整など。
機能テストの所有者: パフォーマンス テスト担当者は、すべての機能をよく知っているわけではないかもしれません。
管理者: 研究室、ネットワーク、DB など
2つ目はサイクルが長く、スパンが大きい作品であること。特に比較的大きな製品の場合。目標、範囲、可能な方法、上記のリソースと時間計画を含む詳細なテスト設計を準備し、多くの人に計画をレビューしてもらい、次にツール、環境、テスト データを準備する必要があります。次に、分析結果を実行して記録します。問題がある場合は調整と回帰を繰り返す必要があります。最後にレポートを整理し、質問に答えます。
上記のような理由で業務が複雑であるためプロジェクトであると言われていますが、その理由としては、パフォーマンステストが評価の性質を持っているため、何かを測定、計測、評価しようとしているため、比較 絶対的な結果。これは、必ずしもこれを期待しているわけではありませんが、パフォーマンス テストにいくつかの権威ある質問が必然的に導入されることになります。そのため、他のプロジェクトと同様に、期待値の管理や外部との適切なコミュニケーションと調整が必要になります。そのため、より包括的なものにするために、私はそれを小さなプロジェクトとして扱うことを好むことがあります。
[パフォーマンス テスト] 最後に、包括的なパフォーマンス テストのチュートリアルのセットが登場しました。本物のエンタープライズパフォーマンステスト全プロセスプロジェクト実戦！