TechCodeview

機能テストに進む前に、テストについて知っておく必要があります。テストとは何ですか?

テストとは何ですか?

簡単に言えば、テストは実際の結果と期待される結果を比較することです。テストは、すべての機能が期待どおりに動作しているかどうかを確認するために行われます。

ソフトウェアテストとは何ですか?

ソフトウェアテストは、実際の結果が期待した結果と一致するかどうかを確認し、ソフトウェアに欠陥やバグがないことを確認する技術です。

ソフトウェア テストでは、アプリケーションに欠陥がないこと、または要件が実際のニーズを満たしていないことを確認します。ソフトウェア テストは手動テストでも自動テストでも実行できます。

ソフトウェア テストは、テスト対象アプリケーション (AUT) の検証としても定義されます。

テストには次の 2 種類があります。

機能テスト:

ソフトウェア テストの一種で、ソフトウェア アプリケーションの機能が要件仕様に従って動作しているかどうかを検証するために使用されます。機能テストでは、値を指定し、出力を決定し、実際の出力と期待値を検証することによって各機能をテストします。機能テストは、アプリケーションまたはシステムの機能が期待どおりに動作することを確認するために提示されるブラックボックス テストとして実行されます。アプリケーションの機能を確認するために行われます。

機能テストは、実際のコードではなくアプリケーションの仕様に焦点を当てるため、ブラックボックス テストとも呼ばれます。テスターはシステムではなくプログラムのみをテストする必要があります。

長さの文字列

機能テストの目標

機能テストの目的は、主な入力機能、必ず使用できる機能、画面GUIの流れを確認することです。機能テストではエラー メッセージが表示されるため、ユーザーはアプリケーション全体を簡単に移動できます。

機能テストのプロセスは何ですか?

テスターは機能テストで次の手順に従います。

• テスターは、ソフトウェア アプリケーションの要件仕様の検証を行います。
• 分析後、要件仕様テスターは計画を立てます。
• テストを計画した後、テスターはテスト ケースを設計します。
• テスト設計後、ケーステスターはトレーサビリティマトリックスの文書を作成します。
• テスターはテスト ケースの設計を実行します。
• アプリケーションの対象となるテスト領域を調べるためのカバレッジの分析。
• 欠陥管理は、欠陥の解決を管理するために行う必要があります。

機能テストでは何をテストするのでしょうか?説明する

機能テストの主な目的は、ソフトウェア システムの機能をチェックすることです。以下の点に重点を置いています。

基本的な使いやすさ:機能テストには、システムのユーザビリティ テストが含まれます。ユーザーが画面内を問題なく自由に移動できるかどうかをチェックします。アクセシビリティ:機能テストでは、機能のアクセシビリティをテストします。メインライン機能:主要な機能のテストに重点を置いています。エラー状態:機能テストは、エラー状態をチェックするために使用されます。エラーメッセージが表示されるかどうかを確認します。

機能テストを実行するための完全なプロセスを説明します。

機能テストを実行するには次の手順があります。

• ソフトウェア要件を理解する必要があります。
• テスト入力データの特定
• 選択した入力値を使用して期待される結果を計算します。
• テストケースを実行する
• 実際の結果と計算結果の比較

機能テストの種類について説明します。

機能テストの主な目的は、コンポーネントの機能をテストすることです。

機能テストは複数の部分に分かれています。

機能テストには次の種類があります。

単体テスト: 単体テスト ソフトウェア テストの一種で、ソフトウェアの個々のユニットまたはコンポーネントがテストされます。単体テストでは、各モジュールが正しく動作していることを確認するため、単体テストによってアプリケーションのさまざまな部分を検査します。また、単体テストによって機能テストも行われます。

開発者は単体テストを行います。単体テストはアプリケーションの開発段階で行われます。

煙試験: 機能試験 煙テストによる。スモークテストには、システムの基本 (機能) 機能のみが含まれます。煙テストは「」として知られています。 ビルド検証テスト 。」スモークテストは、最も重要な機能が動作することを確認することを目的としています。

Java文字列を配列に入れる

たとえば、Smoke テストでは、アプリケーションが正常に起動するかどうかを検証し、GUI が応答するかどうかを確認します。

健全性テスト: 健全性テスト これには、高レベルのビジネス シナリオ全体が正しく機能することが含まれます。健全性テストは、修正された機能/バグを確認するために行われます。健全性テストはスモーク テストよりもほとんど進歩していません。

たとえば、ログインは正常に機能します。すべてのボタンは正しく機能します。ボタンをクリックした後、ページのナビゲーションが完了したかどうか。

回帰試験： このタイプのテストは、コードの変更がシステムの既存の機能に副作用を及ぼさないことを確認することに集中します。回帰テストでは、バグを修正した後にシステムにいつバグが発生したかを特定し、すべての部分が機能しているかどうかに重点を置きます。回帰テストは、システムに影響があるかどうかに焦点を当てます。

統合テスト: 統合テスト 個々のユニットを組み合わせてグループとしてテストしました。このテストの目的は、統合ユニット間の相互作用における障害を明らかにすることです。

ホワイトボックステスト: ホワイトボックステスト クリア ボックス テスト、コードベース テスト、構造テスト、広範なテスト、およびガラス ボックス テスト、透明ボックス テストとして知られています。内部構造・設計・実装をテスターが知っている状態でテストするソフトウェアテスト手法です。

ホワイトボックステストでは、コンポーネントまたはシステムの内部構造の分析が必要です。

ブラックボックステスト: 行動テストとも呼ばれます。このテストでは、内部構造/設計/実装はテスターに​​はわかりません。このタイプのテストは機能テストです。このタイプのテストをブラックボックス テストと呼ぶ理由は、このテスト テスターでは内部コードを見ることができないためです。

たとえば、Web サイトの内部構造に関する知識のないテスターは、Web ブラウザを使用して入力を提供し、期待される結果に対して出力を検証することによって Web ページをテストします。

ユーザー受け入れテスト： これは、要件に従ってシステムを認証するためにクライアントによって実行されるテストの一種です。テストの最終段階は、ソフトウェアを市場または運用環境にリリースする前のユーザー受け入れテストです。 UAT は、2 人以上のエンド ユーザーが関与する一種のブラック ボックス テストです。

再テスト: 再テスト これは、最終的な実行で失敗したテスト ケースが、欠陥が修正された後に正常に成功することを確認するために実行されるテストの一種です。通常、テスターは製品またはそのコンポーネントのテスト中にバグを発見すると、そのバグを割り当てます。バグは開発者に割り当てられ、開発者が修正します。修正後、バグは検証のためにテスターに​​割り当てられます。このテストは再テストとして知られています。

データベースのテスト: データベース テストは、テスト対象のデータベースのスキーマ、テーブル、トリガーなどをチェックするテストの一種です。データベースのテストには、データベースの負荷/ストレス テストを行い、その応答性をチェックするための複雑なクエリの作成が含まれる場合があります。データの整合性と一貫性をチェックします。

例: ユーザーが取引を行う銀行アプリケーションを考えてみましょう。ここからはデータベースのテスト以降が重要になります。彼らです：

• アプリケーションはトランザクション情報をアプリケーション データベースに保存し、ユーザーに正しく表示します。
• このプロセスで情報が失われることはありません
• アプリケーションは、部分的に実行された操作または中止された操作の情報を保持しません。
• ユーザー情報は、個人がアクセスすることはできません。

アドホック テスト: アドホック テストは、システムを破壊することを目的とした非公式のテスト タイプです。このタイプのソフトウェア テストは計画外のアクティビティです。テスト デザインに従ってテスト ケースを作成することはありません。アドホック テストは、アプリケーションの任意の部分でランダムに実行されます。構造化されたテスト方法はサポートされていません。

回復テスト: 回復テスト アプリケーションがクラッシュ、ハードウェア障害、その他の問題からどの程度回復できるかを定義するために使用されます。回復テストの目的は、テスト障害点からシステムが回復する能力を検証することです。

静的テスト: 静的テスト ソフトウェアを実際に実行せずに欠陥をチェックできるソフトウェアテスト手法です。静的テストは、開発の初期段階では障害が発見されやすいため、開発の初期段階でのエラーを回避するために実行されます。静的テストは、動的テストでは見つからない可能性のある間違いを検出するために使用されます。

なぜ静的テストを使用するのでしょうか?

静的テスト 初期段階でエラーを発見するのに役立ちます。静的テストの助けを借りて、開発タイムスケールを短縮します。テストのコストと時間を削減します。静的テストは開発の生産性向上にも使用されます。

コンポーネントのテスト: コンポーネントのテスト これも、他の部分と統合せずに各コンポーネントに対して個別にテストを実行するソフトウェア テストの一種です。コンポーネント テストもブラック ボックス テストの一種です。コンポーネント テストは、単体テスト、プログラム テスト、モジュール テストとも呼ばれます。

グレーボックステスト: グレーボックステスト ホワイト ボックス テストとブラック ボックス テストの両方の組み合わせとして定義されます。グレー ボックス テストは、システムの内部機能に関する限られた情報を使用して実行されるテスト手法です。

機能テストツールとは何ですか?

機能テストは手動テスト以外にもさまざまな方法で実行できます。これらのツールはテストのプロセスを簡素化し、正確で有用な結果を得るのに役立ちます。

開発前に決定・仕様化された重要かつ最優先の技術の一つです。

機能テストに使用されるツールは次のとおりです。

Javaのstring.format

機能テストの利点は何ですか?

機能テストの利点は次のとおりです。

• 欠陥のない製品を生み出します。
• それは顧客が満足することを保証します。
• すべての要件が満たされていることを確認します。
• これにより、アプリケーション/ソフトウェア/製品のすべての機能が適切に動作することが保証されます。
• ソフトウェア/製品が期待どおりに動作することを保証します。
• 安心と安全を確保します。
• 製品の品質が向上します。

例: ここでは、銀行ソフトウェアの例を示します。銀行で、銀行 A から銀行 B にお金が送金されたとき、銀行 B が正しい金額を受け取らなかったり、手数料が適用されたり、お金が正しい通貨に変換されなかったり、誤った送金が行われたり、銀行 A が明細通知を受け取らなかったりする場合銀行Bから支払いが受領されました。これらの問題は重大であり、適切な機能テストによって回避できます。

機能テストの欠点は何ですか?

機能テストの欠点は次のとおりです。

• 機能テストでは、システム内の重大な論理エラーを見逃す可能性があります。
• このテストは、ソフトウェアの稼働を保証するものではありません。
• 機能テストでは冗長なテストが行​​われる可能性が高くなります。

まとめ

ここで、トップクラスのソフトウェア製品の強力な基盤を構築するには、機能テストが不可欠であると簡単に結論付けることができます。これは構造の基礎として機能し、あらゆるテスト ルーチンの重要な部分です。