complete functional testing guide with its types
タイプ、テクニック、および例を含む詳細な包括的な機能テストチュートリアル：
機能テストとは何ですか？
機能テストは、アプリケーションまたはシステムの機能が期待どおりに動作していることを確認するために実行される一種のブラックボックステストです。
これは、アプリケーションのすべての機能を検証するために行われます。
このシリーズでカバーされているチュートリアルのリスト：
チュートリアル＃1： 機能テストとは （このチュートリアル）
チュートリアル＃2： 機能テストの面接の質問
チュートリアル＃3： トップ機能自動化テストツール
チュートリアル＃4： 非機能テストとは何ですか？
チュートリアル＃5： 単位、機能、およびの違い 統合 テスト
チュートリアル＃6 ： 機能テストとパフォーマンステストを同時に実行する必要がある理由
ツール：
チュートリアル＃7： RanorexStudioによる機能テストの自動化
チュートリアル＃8： UFT機能ツールの新機能
チュートリアル＃9： ParrotQAツールを使用したクロスブラウザ機能自動化
チュートリアル＃10： 機能テストのためのJubulaオープンソースツールチュートリアル
学習内容：
機能テストの概要
許容できる動作と許容できない動作を定義する何かが必要です。
これは、機能仕様または要件仕様で指定されています。これは、ユーザーがアプリケーションまたはシステムの適合性を判断できるように、ユーザーに許可されていることを説明するドキュメントです。さらに、これには、実際のビジネスサイドシナリオの検証が必要になる場合もあります。
したがって、機能テストは次の方法で実行できます。 2つの人気のあるテクニック ：
- 要件に基づくテスト： 実行されるすべてのテストの基礎を形成するすべての機能仕様が含まれています。
- ビジネスシナリオに基づくテスト： ビジネスプロセスの観点からシステムがどのように認識されるかについての情報が含まれています。
テストと品質保証は、SDLCプロセスの大きな部分を占めています。テスターとして、私たちは毎日直接関与していなくても、すべての種類のテストを認識する必要があります。
テストは海であるため、その範囲は確かに広大であり、私たちは実行する専用のテスターを持っています さまざまな種類のテスト 。ほとんどの場合、私たち全員がほとんどの概念に精通している必要がありますが、ここですべてを整理しても問題はありません。
機能テストの種類
機能テストには多くのカテゴリがあり、これらはシナリオに基づいて使用できます。
最も顕著なタイプについて、以下で簡単に説明します。
ユニットテスト ：
単体テストは通常、特定の機能を実現するために関連または非関連の可能性があるさまざまなコードユニットを作成する開発者によって実行されます。彼は、これは通常、各ユニットのメソッドを呼び出し、必要なパラメーターが渡されたときにそれらを検証するユニットテストを作成することを伴い、その戻り値は期待どおりです。
コードカバレッジは、以下の3つをカバーするためにテストケースが存在する必要がある単体テストの重要な部分です。
i）ラインカバレッジ
ii）コードパスカバレッジ
iii）メソッドカバレッジ
健全性テスト ： アプリケーション/システムのすべての主要で重要な機能が正しく機能していることを確認するために行われるテスト。これは通常、スモークテストの後に行われます。
スモークテスト ： ビルドの安定性を確認するために、各ビルドがリリースされた後に実行されるテスト。ビルド検証テストとも呼ばれます。
回帰テスト ： 新しいコードの追加、拡張機能、バグの修正が既存の機能を壊したり、不安定さを引き起こしたりせず、仕様に従って機能することを確認するために実行されたテスト。
回帰テストは、実際の機能テストほど広範囲である必要はありませんが、機能が安定していることを証明するために、カバレッジの量だけを確認する必要があります。
統合テスト ： システムが、個別に完全に機能する可能性がある複数の機能モジュールに依存しているが、エンドツーエンドのシナリオを実現するために一緒にクラブを組むときに一貫して機能する必要がある場合、そのようなシナリオの検証は統合テストと呼ばれます。
ベータ/ユーザビリティテスト ： 製品は、環境のようなプロダクションで実際の顧客に公開され、製品をテストします。ユーザーの快適さはこれから導き出され、フィードバックが得られます。これは、ユーザー受け入れテストのテストと似ています。
これを簡単なフローチャートで表現しましょう。
機能システムテスト：
システムテスト は、すべてのモジュールまたはコンポーネントが統合された後、期待どおりに機能するかどうかを検証するために、システム全体で実行されるテストです。
エンドツーエンドのテスト 製品の機能を検証するために実行されます。このテストは、機能要件と非機能要件の両方を含むシステム統合テストが完了した場合にのみ実行されます。
処理する
このテストプロセスには、3つの主要なステップがあります。
アプローチ、テクニック、および例
機能テストまたは動作テストは、指定された入力に基づいて出力を生成し、システムが仕様に従って正しく機能しているかどうかを判断します。
したがって、画像表現は次のようになります。
入退場基準
エントリー基準：
- 要件仕様書が定義され、承認されています。
- テストケースが用意されています。
- テストデータが作成されました。
- テスト用の環境は準備ができており、必要なすべてのツールが利用可能で準備ができています。
- 完全または部分的なアプリケーションが開発され、単体テストが行われ、テストの準備が整います。
終了基準：
- すべての機能テストケースの実行が完了しました。
- 重大なバグやP1、P2のバグはありません。
- 報告されたバグは確認済みです。
関係するステップ
このテストに含まれるさまざまな手順を以下に示します。
- 関係する最初のステップは、テストする必要のある製品の機能を決定することです。これには、主な機能、エラー状態、メッセージのテスト、ユーザビリティテスト（製品がユーザーフレンドリーかどうかなど）が含まれます。
- 次のステップは、要件仕様に従ってテストする機能の入力データを作成することです。
- その後、要件仕様から、テスト対象の機能の出力が決定されます。
- 準備されたテストケースが実行されます。
- 実際の出力、つまりテストケースの実行後の出力と期待される出力（要件仕様から決定）を比較して、機能が期待どおりに機能しているかどうかを確認します。
アプローチ
さまざまな種類のシナリオを「テストケース」の形で考えて作成することができます。 QAの人々として、私たちは皆、テストケースの骨組みがどのように見えるかを知っています。
それは主にそれに4つの部分があります：
- テストの概要
- 前提条件
- テスト手順と
- 予想された結果。
あらゆる種類のテストを作成しようとすることは不可能であるだけでなく、時間と費用もかかります。
通常、既存のテストでエスケープせずに最大のバグを発見したいと思います。したがって、QAは最適化手法を使用し、テストへのアプローチ方法を戦略化する必要があります。
これを説明しましょう 例。
機能テストのユースケースの例：
従業員が自分のユーザーアカウントとパスワードでログインするオンラインHRMSポータルを利用します。ログインページには、ユーザー名とパスワード用の2つのテキストフィールドと、(ログイン)と(キャンセル)の2つのボタンがあります。ログインに成功すると、ユーザーはHRMSホームページに移動し、キャンセルするとログインがキャンセルされます。
仕様は以下のとおりです。
＃1） ユーザーIDフィールドは、最小6文字、最大10文字、数字（0〜9）、文字（a〜z、A〜z）、特殊文字（アンダースコア、ピリオド、ハイフンのみ使用可能）を取り、空白のままにすることはできません。ユーザーIDは、特殊文字ではなく、文字または数字で始まる必要があります。
＃二） パスワードフィールドは、最小6文字、最大8文字、数字（0〜9）、文字（a〜z、A〜Z）、特殊文字（すべて）を取り、空白にすることはできません。
このシナリオをテストするための基本的なアプローチは、大きく2つのカテゴリに分類できます。
- ポジティブテストと
- ネガティブテスト
もちろん、これらの各カテゴリには、実行されるテストのサブセクションがあります。
陽性テスト 製品が満たされていることを確認するために行われるハッピーパステストです。少なくとも、顧客の使用に不可欠な基本要件です。
ネガティブシナリオ 予期しないデータが発生した場合でも、製品が適切に動作することを確認してください。
推奨読書=> ネガティブテストとは何ですか？ネガティブテストケースの書き方
それでは、以下のフローチャートを使用してテスト手法を構築してみましょう。これらの各テストの詳細について説明します。
機能テスト技術
＃1）エンドユーザーベース/システムテスト
テスト対象のシステムには、結合するとユーザーシナリオを実現する多くのコンポーネントが含まれる場合があります。
の中に 例 、顧客のシナリオには、HRMSアプリケーションのロード、正しい資格情報の入力、ホームページへの移動、いくつかのアクションの実行、システムからのログアウトなどのタスクが含まれます。この特定のフローは、基本的なビジネスシナリオではエラーなしで機能する必要があります。
ジェンキンスは経験豊富な人のための質問と回答をインタビューします
いくつかのサンプルを以下に示します。
| Slいいえ | 概要 | 前提条件 | テストケース | 予想された結果。 |
|---|---|---|---|---|
| 1.1。 | 完全な特権ユーザーはアカウントを変更できます | 1）ユーザーアカウントが存在する必要があります 2）ユーザーは必要な権限を持っている必要があります | 1）ユーザーがユーザーIDとパスワードを入力します 2）ユーザーにはアカウント自体を変更するための編集権限が表示されます 3）ユーザーがアカウント情報を変更して保存します。 4）ユーザーがログアウトします。 | 1）ユーザーがホームページにログインしている 2）編集画面がユーザーに表示されます。 3）アカウント情報が保存されます 4）ユーザーはログインページに戻ります |
| 2.2。 | 完全な権限を持たない別の有効なユーザー | 1）ユーザーアカウントが存在する必要があります 2）ユーザーは最小限の権限を持っている必要があります | 1）ユーザーがユーザーIDとパスワードを入力します 2）ユーザーには、特定のフィールドのみを変更するための編集権限が表示されます。 3）ユーザーはそれらのフィールドのみを変更して保存します。 4）ユーザーがログアウトします。 | 1）ユーザーがホームページにログインしている 2）編集画面は特定のフィールドでのみユーザーに表示されます。アカウントフィールドはグレー表示されます。 3）変更されたフィールドは保存されます 4）ユーザーはログインページに戻ります |
これは、状況に応じてテストケースを作成する方法の基本的な例です。上記の形式は、以下のすべてのテストにも適用されます。強力な概念的根拠のために、私は上下にいくつかの簡単なテストのみを入れました。
＃2）同等性テスト
に 等価分割 、テストデータは、等価データクラスと呼ばれるさまざまなパーティションに分離されます。各パーティションのデータは同じように動作する必要があるため、1つの条件のみをテストする必要があります。同様に、パーティション内の1つの条件が機能しない場合、他の条件はいずれも機能しません。
例えば 、上記のシナリオでは、ユーザーIDフィールドに最大10文字を含めることができるため、10を超えるデータを入力しても同じように動作するはずです。
＃3）境界値テスト
境界テストは、アプリケーションに対するデータ制限を意味し、アプリケーションの動作を検証します。
したがって、入力が境界値を超えて供給された場合、それはネガティブテストと見なされます。したがって、ユーザーの最低6文字が境界制限を設定します。ユーザーIDを持つように作成されたテスト<6 characters are boundary analysis tests.
＃4）意思決定ベースのテスト
意思決定ベースのテストは、特定の条件が満たされたときにシステムの考えられる結果のイデオロギーを中心にしています。
上記のシナリオでは、次の意思決定ベースのテストをすぐに導き出すことができます。
- 間違った資格情報が入力された場合、それはユーザーにそれを示し、ログインページをリロードする必要があります。
- ユーザーが正しい資格情報を入力すると、ユーザーは次のUIに移動するはずです。
- ユーザーが正しい資格情報を入力したが、ログインをキャンセルしたい場合は、ユーザーを次のUIに移動して、ログインページをリロードしないでください。
＃5）代替フローテスト
代替パステストは、機能を実行するためのメインフロー以外に、存在する可能性のあるすべての方法を検証するために実行されます。
＃6）アドホックテスト
上記の手法でほとんどのバグが発見されたら、 アドホックテスト 以前に観察されなかった不一致を明らかにするための優れた方法です。これらは、システムを破壊し、システムが正常に応答するかどうかを確認するという考え方で実行されます。
例えば 、サンプルテストケースは次のようになります。
- ユーザーはログインしていますが、管理者はいくつかの操作を実行しているときにユーザーアカウントを削除します。アプリケーションがこれをどのように適切に処理するかを見るのは興味深いでしょう。
機能テストと非機能テスト：
非機能テスト アプリケーション/システム全体の品質に焦点を合わせます。したがって、システムが実行する機能とは対照的に、顧客の要件に従ってシステムがどの程度うまく機能するかを推測しようとします。
機能テストの自動化
機能テストを自動化できますか？
自動化により、手作業を減らし、時間を節約し、バグのずれを回避し、効率を高めることができます。
ただし、すべてを自動化することはできません。このテストは自動化できますが、自動化を行うには、ユーザーがテストケースを検討する必要があります。適切なツールとともに自動化する適切なテストケースを見つけることが重要です。
機能ケースの自動化には、テストケースの数がはるかに多く、何度もリグレッションが発生する場合（実行する必要があります）などの欠点があり、開発者はコードへの変更をコミットする際に問題に直面する可能性があります。
欠陥エスケープ分析を実行している間、多くの場合、エスケープの顕著な永続的な原因は、特定の機能のテストカバレッジが不足しているようです。
繰り返しになりますが、これが発生する原因はいくつかあります。たとえば、環境の欠如、テスターの欠如、提供される機能が多すぎる、すべてのテストの側面をカバーする時間が短い、場合によっては単に見落としているなどです。
専任のテストチームが各スプリントまたは各テストサイクルで詳細なテストを行う場合がありますが、欠陥は常に存在し、見逃される可能性のある欠陥が常に存在します。これは、テストの自動化を実施するための基本的なニーズの1つであり、それによって、テストプロセス全体とテストケースカバレッジの効率が大幅に向上します。
自動テストが手動テストに取って代わることは決してありませんが、ソフトウェアプロジェクトで望ましい品質を実現するには、2つの理想的な組み合わせが不可欠であることがわかります。
自動化に関する考慮事項：
＃1） 正しい自動化ツールを選択してください ： 市場にはいくつかのツールがありますが、自動化ツールを選択するのは非常に困難な作業です。ただし、使用する自動化ツールを選択できる要件のリストを作成することもできます。
考えるべきいくつかの主要な側面は次のとおりです。
- チームのすべてのQAメンバーが必要なスキルをまだ持っていない場合は、使いやすいツールを選択してください。
- このツールは、さまざまな環境で使用できます。ために 例 ：スクリプトを1つのOSプラットフォームで作成し、別のOSプラットフォームで実行できますか？ CLI自動化、UI自動化、モバイルアプリケーション自動化、またはすべてが必要ですか？
- ツールには、必要なすべての機能が必要です。ために 例 ：一部のテスターがスクリプト言語に精通していない場合、ツールには記録および再生機能があり、記録されたスクリプトの目的のスクリプト言語への変換をサポートする必要があります。同様に、自動ビルドテスト、特定のレポート、およびログ記録をサポートするツールも必要な場合は、それも実行できる必要があります。
- ツールは、UIが変更された場合に、テストケースの再利用性をサポートできる必要があります。
自動化ツール ：機能の自動化に利用できるツールはかなりたくさんあります。 Seleniumはおそらく人気がありますが、Sahi、Watir、Robotium、AutoItなどの他のオープンソースツールもあります。
いくつかのテスト自動化ツールが市場で入手可能です。しかし、適切なツールを選択することは、組織にとって非常に重要です。それは要件、使いやすさに依存するかもしれません、そしてコストはここで主要な役割を果たします。
以下に、主要な機能テストツールの一部を示します。
- セレン
- QTP
- JUnit
- ロードランナー
- 石鹸
- TestComplete
=> トップ機能自動化ツールのこの完全なリストを確認してください
＃二） 自動化する適切なテストケースを選択する ： 自動化を最大限に活用したい場合は、自動化するために選択するテストの種類について賢くすることが重要です。テストの実行中にいくつかのセットアップと構成のオンとオフを必要とするテストがある場合、それらは自動化されないままにしておくのが最善です。
したがって、次のようなテストを自動化できます。
- 繰り返し実行する必要があります。
- さまざまな種類のデータで実行します。
- 一部のP1、P2テストケースは多くの労力と時間を要します。
- エラーが発生しやすいテスト。
- さまざまな環境、ブラウザなどで実行する必要がある一連のテスト。
＃3）専用の自動化チーム ：これはおそらくほとんどの組織で見過ごされており、自動化はQAチームのすべてのメンバーに課せられています。
各チームメンバーは、さまざまな経験レベル、スキルセット、関心レベル、自動化をサポートする帯域幅などを持っています。手動テストの実行に熟練している人もいれば、スクリプトおよび自動化ツールを知っている人もいます。
このような状況では、チームのすべてのメンバーを分析し、一部のメンバーに自動化のみを行うことに専念させることをお勧めします。
自動化アクティビティには、時間、労力、知識、およびチームのすべてのメンバーを手動テストと自動化テストの両方で過負荷にするのではなく、必要な結果を達成するのに役立つ専用チームが必要です。
＃4） データ駆動型テスト： 複数のデータセットを必要とする自動テストケースは、再利用できるように適切に作成する必要があります。データは、テキストやプロパティファイル、XMLファイルなどのソースに書き込んだり、データベースから読み取ったりすることができます。
データソースが何であれ、適切に構造化された自動化データを作成すると、フレームワークの保守が容易になり、既存のテストスクリプトを最大限に活用できるようになります。
＃5）UIの変更はテストを破ってはなりません： 選択したツールを使用して作成するテストケースは、潜在的なUIの変更に対応できる必要があります。たとえば、以前のバージョンのセレンは、場所を使用してページ要素を識別していました。
したがって、UIが変更された場合、それらの要素はそれらの場所で検出されなくなり、テストの大規模な失敗につながります。
したがって、ツールの欠点を事前に理解し、UIが変更された場合に必要な変更が最小限になるように、テストケースを作成することが重要です。
＃6）頻繁なテスト： 基本的な自動化テストバケットの準備ができたら、このバケットをより頻繁に実行するように計画します。これには双方向の利点があります。1つは自動化フレームワークを強化してより堅牢にすることができること、もう1つはプロセスでより多くのバグをキャッチできることです。
利点
以下に、機能テストのさまざまな利点を示します。
- このテストは、実際のシステムが何であるかを再現するか、レプリカです。つまり、製品が実際の環境にあるもののレプリカです。テストは、お客様の使用状況に応じた仕様、つまりシステム仕様、オペレーティングシステム、ブラウザなどに焦点を当てています。
- それは、システムの構造に関するif andbutsまたは仮定では機能しません。
- このテストにより、顧客の要件を満たす高品質の製品を確実に提供し、顧客が最終結果に満足していることを確認します。
- これにより、顧客の要件に従ってすべての機能が機能するバグのない製品を確実に提供できます。
- リスクベーステストは、製品にあらゆる種類のリスクが発生する可能性を減らすために行われます。
制限事項
このテストは、製品が期待どおりに機能し、要件全体が実装され、製品が顧客の要件に正確に準拠していることを確認するために行われます。
ただし、製品のパフォーマンス、つまり応答性、スループット時間など、製品をリリースする前にテストの一部として重要であり、非常に必要とされる他の要因は考慮されていません。
短所
- 冗長なテストを実行する可能性はたくさんあります。
- 製品では論理エラーを見逃す可能性があります。
- このテストは要件に基づいています。要件が完全でない、複雑である、または明確でない場合、このようなシナリオでこのテストを実行することは困難になり、時間もかかる可能性があります。
したがって、基本的に、これらのタイプのテストは両方とも高品質の製品に必要です。
結論
このチュートリアルでは、基本から機能テストについて知っておく必要のあるすべてのことを包括的に説明しました。
機能テストは、製品またはアプリケーションの最も必要な、そして実際に重要な側面である製品の機能を検証するため、重要なテストプロセスの1つです。
著者について： Sanjay Zalavadia –クライアントサービス担当副社長として ゼファー 、ITおよびテクニカルサポートサービスで15年以上のリーダーシップの経験をもたらします。
私たちが提案したテクニックのいくつかがすべての読者に役立つことを願っています。以下のコメントであなたの考えを教えてください。
推奨読書=> 機能テストチュートリアル