メニュー

ソフトウェアテストのテストカバレッジ（テストカバレッジを最大化するためのヒント）

test coverage software testing

問題を排除するために楽器を試してください

ソフトウェアテストテストカバレッジ完全ガイド： より多くのテストを行い、時間を節約し、より良いテスト結果を達成する方法：

ソフトウェアテストは、ソフトウェアの開発と保守のライフサイクルにおいて不可欠なアクティビティです。これは、ソフトウェアの品質を決定および改善するためによく使用される方法です。

最近の開発はより体系的であり、組織はテストの完了基準を示すためにテストの完全性と有効性の測定を求めています。それらすべての中で、カバレッジは特に価値があると考えられています。

学習内容：

テストカバレッジとは何ですか？

簡単に言えば、カバレッジは「何をテストし、どれだけテストするか」です。

テストカバレッジは、テストの品質を監視するのに役立ち、テスターが欠落している領域や検証されていない領域をカバーするテストを作成するのに役立ちます。

テストカバレッジ

クロックインクロックアウトソフトウェア無料

ほとんどのチームは、機能要件のみに基づいてカバレッジ計算を行います。何よりもまず、アプリケーションは本来の機能を実行する必要があるため、これも公平です。そうでない場合は、その速度、セキュリティ、または使いやすさ–それは重要ではありません。

ただし、専用で独立している場合 非機能テスト チームはパフォーマンス、セキュリティ、ユーザビリティテストなどに取り組んでおり、テストカバレッジ分析を通じて実行に至るまで要件を追跡する必要があります。

テストカバレッジとコードカバレッジ

テストカバレッジは、コードカバレッジと混同されることがよくあります。基本的な原則は同じですが、2つの異なるものです。

コードカバレッジ コードのすべての領域を少なくとも1回ターゲットにする必要があり、開発者によって実行される単体テストの実践について実際に話します。

一方、テストカバレッジは すべての要件をテストする 少なくとも1回は、明らかにQAチームの活動です。

対象となる要件として実際に適格となるものは、各チームの解釈によって異なります。

例えば 、一部のチームは、それに対するテストケースが少なくとも1つある場合、対象となる要件を呼び出します。場合によっては、少なくとも1人のチームメンバーが割り当てられているとカバーされます。または、それに関連するすべてのテストケースが実行された場合。

  • 10個の要件と100個のテストが作成されている場合（これらの100個のテストが10個の要件すべてを対象とし、どれも除外しない場合）、これを設計レベルでの適切なテスト範囲と呼びます。
  • 作成されたテストのうち80のみが実行され、要件のうち6つのみを対象とする場合。テストの80％が完了していても、4つの要件はカバーされていないと言います。これは、実行レベルでのカバレッジ統計です。
  • 8つの要件に関連する90のテストのみがテスターを割り当て、残りは割り当てられていない場合、テスト割り当てのカバレッジは80％（10の要件のうち8つ）であると言います。

カバレッジをいつ計算するかについても重要です。

プロセスの早い段階でこれを行うと、物事がまだ不完全であるため、多くのギャップが発生します。したがって、一般的には 最後のビルドまで待つ つまり、最終回帰ビルド。これにより、特定の要件に対して実行されたテストが正しくカバーされます。

また読む=> リリースと展開の管理プロセス

私の経験

8年前のシーン： ソフトウェアテスト業界で2年の経験を積んでいたとき、ソフトウェアテストの基礎を知らなくても、経験を積んで学ぶことができ、私もそうするだろうと思っていました。

私は正しかった-そして間違っていた。

経験を積むことで、より大きな全体像を見ることを学び、「危機的状況」の本当の意味を理解し、エンドユーザーをより理解するからです。

言及されたもののどれも経験を必要としないので間違っていますが、私が非常に遅く理解した早期の学習。それがこの投稿を書くための励みになる要素です。

より短い時間でテストカバレッジを最大化

当時のインタビューの1つからの私の経験は次のとおりです。

テストカバレッジが完全または最大であることをどのように確認しますか？ 聞かれました。

うーん……すべての機能をテストしていることを確認します 、私は言った。

S oすべての機能をテストすると、テストの観点から、アプリケーション/製品の最大数をカバーしたと感じていると言っています 、インタビュアーは裏目に出た。

うーん…うーん…。うーん…。はい、すべての機能をテストすると、アプリケーション/製品の動作に自信があるからです。 私は私の答えを支持しました 。

同意しますが、私の質問は、テストの対象範囲が最大または完全であるという確信を与えるでしょうか。 インタビュアーは私を手放す気がなかった。

今、私はソフトウェアテストに関する最も重要なトピックの1つを学ぶつもりだったという事実について知らずに、焦りを感じていました– 「」 テストカバレッジ」 。

インタビューの抜粋を再現するのではなく、その日にカバレッジのテストについて学んだことをここに要約します。ただし、その前に1つの点を明確にしておきましょう。テストの対象範囲は、十分にテストしているかどうかを知ることを意味するのではなく、完全にテストしているかどうかを意味するわけでもありません。

テストカバレッジの意味

カバレッジのテストは、コンテキストによって意味が異なる場合があります。それらのコンテキストを1つずつ発見してみましょう。

製品の範囲–製品のどの側面を見ましたか？

はい、テストカバレッジが製品の観点から測定されている場合、焦点を当てる主な領域は、テストした製品の領域とテストされていない領域です。

例1：

「ナイフ」が製品の場合、テストしています。野菜や果物をきちんと切るかどうかのチェックに集中しないでください。次のような他の側面を探す必要があります–ユーザーはそれを快適に処理できる必要があります。

例2：

「メモ帳」がアプリケーションの場合、テストを行っています。関連する機能を確認する必要があります。

PythonSeleniumはテキストで要素を検索します

ただし、注意が必要な他の側面は次のとおりです。アプリケーションは他のアプリケーションを同時に使用しながら適切に応答し、アプリケーションはクラッシュしません ユーザーが何か変わったことをしようとしたとき 、ユーザーには適切な警告/エラーメッセージが提供され、ユーザーはアプリケーションを簡単に理解して使用でき、必要に応じてヘルプコンテンツを利用できます。

上記のシナリオを検討しないと、アプリケーションのテスト範囲が完了したと主張することはできません。

リスクカバレッジ–どのようなリスクをテストしましたか？

リスクカバレッジは、完全なテストカバレッジを持つためのもう1つの側面です。関連するリスクもテストするまで、製品またはアプリケーションに「テスト済み」のタグを付けることはできません。関連するリスクのカバレッジは、全体的なテストカバレッジの重要な要素です。

例1：

飛行機のテスト中に、テスターが飛行機の内部システムを完全にテストし、正常に動作しているが、テスト中に飛行機の飛行能力のみがカバーされていないと言った場合、どのように反応しますか？

そうですね、それがリスクカバレッジの意味です。アプリケーション/製品ごとにリスクを特定し、それを徹底的にテストすることは、常に良い習慣です。

例2：

eコマースサイトをテストする際、テスターはすべての効果的な要素を考慮しましたが、同時にWebサイトにアクセスするユーザーの数のリスクを考慮していませんでした。スーパーオファーの日に、考慮されなかったリスクは大きな間違いでした。

推奨読書 =>

要件の範囲–どのような要件をテストしましたか？

製品またはアプリケーションが非常によく開発されているが、それが顧客の要件と一致していない場合、それは役に立ちません。テスト中の要件カバレッジは、製品カバレッジと同じくらい重要です。

例1：

家族の機能に興奮して、あなたは仕立て屋にあなたのドレスを縫い合わせて、ネックラインにそれらの孔雀の青いショーボタンを置くように頼みました。

ドレスを縫うとき、仕立て屋はそれらのボタンをネックラインに置くのは見栄えが悪いと思ったので、代わりに金色のボーダーを縫いました。試用日には、間違いなく、不幸な顧客は、要件に固執しなかったために仕立て屋に叫びました。

例2：

チャットアプリケーションをテストしている間、テスターは、グループでチャットする複数のユーザー、独立してチャットする2人のユーザー、利用可能なすべてのタイプの絵文字、ユーザーにすぐに送信される更新など、すべての重要なポイントを処理しましたが、要件ドキュメントを調べるのを忘れていました。 2人のユーザーが個別にチャットする場合は、ビデオ通話オプションを有効にする必要があると述べました。

クライアントは、2人のユーザーが独立してチャットしている間、通話を許可すると主張してチャットアプリケーションを販売しました。チャットアプリケーションに何が起こったのか想像できます。

また 読んだ => 要件トレーサビリティマトリックスを作成する方法

適切なテストカバレッジ方法を採用するにはどうすればよいですか？

意識がすべてです：

まず最初に、QAチームは、どのくらいの作業が必要で、設計タスクがどこにあるかを知る必要があります。このようにして、彼らはさらにテストが追加されるかどうかを認識します。これを行うには、通常の方法でRTMを使用できます。

=>この記事をチェックして、詳細と使用方法を確認してください。 要件トレーサビリティマトリックスを作成する方法–サンプルテンプレートを使用した正確なプロセス

次に、リソースの割り当てを確認し、 テスト実行プロセス すべてがより効果的な方法でテストされているかどうかを確認します。

以下のような表が役立ちます。

テストタイプ総件数実行されたケース状態コメント
機能的1008050合格、30不合格
互換性1005045合格、5不合格
使いやすさ10010098合格、2不合格
最終回帰10010099合格、1不合格

すべてがテストされていることを確認する方法は？

  • すべてのテスターは、要件とテスト方法を知っている必要があります
  • 要件に優先順位を付け、最も必要な場所にエネルギーを集中させます
  • 特定のリリースが前のリリースとどのように異なるかについて通知されるため、重要な要件をより正確に特定し、最大のポジティブカバレッジに焦点を当てることができます
  • テスト自動化を適応させる
  • テスト管理ツールを使用する 常に知るために
  • スマートな作業の割り当て-重要なタスクに向けて最善のリソースを導き、新しいテスターが新鮮な視点を求めてさらに探索できるようにします
  • 維持する すべてのタスクのチェックリスト およびその他の活動
  • 開発/スクラム/ BAチームとさらに対話して、アプリケーションの動作に関する洞察を得る
  • すべてのビルドサイクルと修正を追跡します
  • 最初のビルド自体で最も影響のある問題を特定し（可能な場合）、後のビルドで安定性を高め、以前の問題によってブロックされた領域に到達できるようにします。

効果的なテストのための重要な領域と方法

効果的なテスト

＃1）リソースのジャンブリング： チームメンバー間でタスクを交換します。これにより、エンゲージメントが向上し、知識の集中が防止されます。

＃二）互換性の範囲： あなたが知っていることを確認し、 さまざまなブラウザ そして プラットフォーム アプリケーションをテストします。

＃3）所有： テスターに​​説明責任を負わせ、彼らが取り組んでいるモジュール/タスクに対して（もちろん監視とサポートを含めて）自由に抑制できるようにします。これは責任を構築するのに役立ち、彼らが道をたどる代わりに創造的な方法を試すことができます。

＃4）締め切り： テストフェーズの開始前にリリース期限を知ることは、効果的な計画に役立ちます

＃5）コミュニケーション ： 開発者や他のチームと連絡を取り合う リリースサイクルの合間に、何が起こっているのかを知ることができます。

＃6）RTMを維持します。 の優れた派生物として機能します 利害関係者またはクライアント 、リリーススケジュールの確認に基づいて

テスターのカバレッジ認識をテストする利点：

  • これは主に、タスクの優先順位付けをテストするのに役立ちます
  • 100％の要件カバレッジを達成するのに役立ちます。つまり、要件のリークを防ぎます。
  • 影響分析 簡単になります
  • を決定するのに役立ちます 終了基準
  • テストリードがクリアを準備できるようにします テスト終了レポート

結論

テストカバレッジは、言及されたコンテキストで終了しません。カバレッジのテストに関して考慮すべき点は他にもたくさんあります。

より多くのテストを行うと、結果が良くなるとは限りません。実際、明確な戦略なしでさらにテストすると、おそらく多くの時間を投資することになります。

より構造化されたアプローチ、100％の要件カバレッジ、効果的なテスト方法を目指して、品質に妥協することはありません。

この記事で概説されているテクニックがあなたにいくつかの指針を与えることを願っています。

ba面接の質問と回答pdf

投稿についてのコメントや意見を入力してください。いつものように、私たちはあなたから話を聞くのが大好きです。

推奨読書

^