functional testing vs performance testing
機能テストとパフォーマンステスト：
間の違い パフォーマンステスト、負荷テスト、ストレステスト 前回のチュートリアルで例を挙げて説明しました。
ソフトウェアテストは、ソフトウェア機能の検証または検証が行われる可能性のある幅広い領域を対象としています。時折、非機能的側面は機能的側面に関して少なくなります。それらは実際には実行されません。ソフトウェアテスト中に同時に。
=> 完全なパフォーマンステストチュートリアルシリーズについては、ここをクリックしてください
この記事では、ソフトウェアテストライフサイクルのさまざまなシナリオにおけるソフトウェア製品の品質の追加の利点について説明します。 機能的および非機能的の両方が同時に取られる場合。
学習内容：
パフォーマンステストと機能テストの簡単な違い
| Sl NO | 機能テスト | 性能試験 |
|---|---|---|
| 1 | 期待される出力に対して明確な入力を使用してソフトウェアの精度を検証する | さまざまな負荷条件でのシステムの動作を検証する |
| 二 | 手動または自動にすることができます | 自動化すれば効果的に実行できます |
| 3 | すべての操作を実行する1人のユーザー | 必要な操作を実行する複数のユーザー |
| 4 | お客様、テスター、開発者の関与が必要 | 顧客、テスター、開発者、DBA、およびN / W管理チームからの関与が必要 |
| 5 | 実稼働サイズのテスト環境は必須ではなく、H / W要件は最小限です | 負荷を投入するために、実稼働テスト環境といくつかのH / W設備に近い要件 |
機能テストとパフォーマンステストを同時に実行する必要があるのはなぜですか？
機能テストは、ソフトウェアのプレリリースにとってはるかに重要になります。実際の結果ベース 検証と妥当性確認 複製された本番環境またはテスト環境では、通常、テストが行われます。
欠陥の漏れは、最大の問題の1つになる可能性があります。
テスターは、製品の品質に関して開発者よりも責任があります。基本的に、彼らはテストされた製品に欠陥の漏れがあることを望んでいません。テスターは通常、これを達成するために機能テストのみを実行する傾向があります。
以下は、テストマネージャーとテスター ：
（テストマネージャーは「TM」、テスターは「TR」と呼ばれます）
TM ：やあバディ…製品「A」のテストはどうですか？
TR ：うん…私たちはもっと進んでいます。
TM ：それは素晴らしいことです…そして、機能テストが実行されている間のパフォーマンステストの観点から私たちの範囲は何ですか？
TR ：私たちはそれらをカバーしていません。私たちの成果物は機能領域にのみ存在し、非機能領域には存在しないことになっています。また、使用しているテスト環境は、本番環境の正確なレプリカではありません。
上記の会話から考慮すべきいくつかの質問があります：
- 機能テストにはパフォーマンスに依存する要素がありますか？
- ソフトウェアのパフォーマンスが低下したが、パフォーマンスをチェックせずに製品の配送が行われた場合はどうなりますか？
- パフォーマンステスト–機能テストプロセス内で共存していますか？
テスターは、要求されない限り、機能以外の側面に取り組んでいないことが一般的になっています。避けるのが一般的です 非機能テスト クライアントがテスト対象のソフトウェアのパフォーマンスに関する問題を報告するまで。
したがって、考慮すべき2つの質問があります。
- パフォーマンス–機能テストに影響しますか？
- クライアントが心配している場合でも、パフォーマンステストを別の成果物として保持しますか？
パフォーマンステストは 重要 ！
java配列を逆にする方法
ソフトウェアは、次のようなさまざまなアーキテクチャと次のモデルに基づいて機能します。
- 必要な応答応答モデル
- トランザクションベースのシステム
- 負荷ベースのシステム
- データ複製ベースのシステム
上記の体系的なモデルの機能テストの動作は、システムのパフォーマンスによって異なります。
自動化の観点では、パフォーマンステストに多くの注意を払う必要があります。
以下は、クライアントとテストマネージャー。
（クライアントは「CL」、テストマネージャーは「TM」と呼ばれます）
CL ：したがって、私たちが要求した解決策に到達したので、現在行われているテストが複数回繰り返されることを願っています。
TM ：はい、これは可能です。あなたが言ったように、反復テストの可能性が高くなるでしょう、私たちは機能的（回帰）テストに対処するための自動化を提案したいと思います。
CL ：わかりました。承認できるように、アプローチをお送りください。自動化は、最小限の労力ではるかに高い出力を実現します。
TM ： 丁度。このアプローチに取り組み、概念実証でご連絡いたします。
上記の会話から、クライアントのニーズは効率を最適化することであることは明らかです。
ケーススタディ
ABC社はソフトウェアAを開発するためのプロジェクトに取り組んでいます。ソフトウェアAのテストはXYZ社によって行われています。
ABC社とXYZ社の契約には、コラボレーションにいくつかの制限があります。 2社間の話し合いは、週に1回または月に3回行う必要があります。システムは、要求/応答モードのモデルで動作します。開発フェーズはABC社によって完了しました。
今こそ、XYZ社がソフトウェアAの正式な機能テストを実行するときです。XYZはソフトウェアAのテストに取り組み始めました。彼らはソフトウェアにクリーンチットを与え、2サイクルのテストの後にライブ実装の「実行」を行いました。
テストチームからの品質証明書にもかかわらず、ライブ実装はうまくいきませんでした。ポストプロダクションのバグがたくさんありました。エンドツーエンドのビジネスプロセスの機能の中断など、クライアントが直面する問題は多数ありました。
だから今何ですか問題？
- 開発チームとテストチーム間のコラボレーションの制限に問題がありますか？
- 要件が100％取得されなかったということですか？
- 製品が適切なテスト環境でテストされなかったということですか？
- または他の原因はありますか？
注意深い調査と分析の後、以下が推測された：
- 応答のフェッチ中にパフォーマンスの問題が発生した依存アプリケーションと相互依存アプリケーションはほとんどありませんでした。
- 使用したテスト入力は絶対的なものではありませんでした。
- ソフトウェアの堅牢性は考慮されていませんでした。
- 複数の独立したアプリケーション間の同期の問題がたくさんあります。
- ソフトウェアテストは、考慮されなかった複数のやり直しを行いました。
したがって、是正措置計画チームが介入し、次のことが提案されました。
- 開発チームとテストチームの間の相互作用を増やす必要があります。
- 依存するすべてのアプリケーションを接続して、システム機能テストに含める必要があります
- 非実稼働環境に余裕を持たせるには、要求と応答のタイムアウト値を増やす必要があります
- 機能テストでは、単純なものから複雑なものまで、さまざまな入力を使用する必要があります
- 非機能テスト、特にパフォーマンスと負荷のテストは、修復チームのアドバイスに従って実行する必要があります。
- システムテストに加えて、システム統合テストを実行する必要があります。
- 2回のテスト反復間の最小のタイムギャップを提供する必要があります。これは、以前に特定されたバグを再テストするためのものです。
- 以前のイテレーションで特定されたすべてのバグは、現在のイテレーションで修正する必要があります。
テストチームは提案されたすべてのアクションを実装し、短時間で多数の欠陥が発見されました。
観察：
- ソフトウェアのライブ実装スケジュールは、テストサイクル時間を最適化することで大幅に改善されました。
- ソフトウェア品質の最適化は順調に進んでいます。したがって、実装後のサポートチケットは大幅に減少しました。
- 再作業が減り、再作業の代わりに反復をテストしていました。異なる反復の間に、観察された品質のより良い改善がありました。
結論
機能テストの実行中に非機能テストを実行する方が有利であり、ソフトウェア全体の品質にさらに多くの利点が追加されます。これにより、パフォーマンスのバグ（テスト環境と依存関係に限定）が特定されるため、機能上の問題が想定される状況が軽減されます。
プロジェクトの他の利害関係者間の強力な関係を維持するために、機能テストと非機能テストを（最小限のレベルで）実行するための十分な計画を立てる必要があります。
著者について： ナガラジャンが書いた記事です。彼は、手動と自動化の両方の観点から、銀行、航空会社、電気通信などのさまざまな機能分野で6年以上のテスト経験を持つテストリーダーとして働いています。
今後のチュートリアルでは、パフォーマンステスト計画とテスト戦略について詳しく説明します。
=> 完全なパフォーマンステストチュートリアルシリーズについては、こちらをご覧ください