Skip to main content
Created for OutSystems 10. Not working on your version? Tell us about it!

 

 

DevOps

 

 

OutSystems

単体テストおよびAPIテストの自動化

目標

このガイドは、テストに関する経験、知識、パターンを共有することにより、OutSystemsプロジェクトでのテストの導入を容易にすることを目標としています。

このガイドでは、「Cases」デモアプリケーションと「Cases_Tests」アプリケーションを使用します。いずれもForgeからダウンロードできます。

はじめに

テストを効果的に行うには、5つの重要な要素が整っている必要があります。具体的には以下のようなものがあります。

  • テストのタイプと量を定義する適切なテスト戦略

  • テスト戦略を実行するために必要なタスクを示すテスト計画

  • ソフトウェアが要件を満たしていることを確認するために使用する詳細な使用例を含むテストケース

  • テスト実行中に使用する入力データと既存の「本番に近い」データを含むテストデータ定義

  • テスト対象のアプリケーションがデプロイされ、テスト作業に影響を及ぼす可能性のある外部からの干渉を受けることなくテストサイクルが実行されるテスト環境

これらの要素のいずれかが欠けている場合、テスト効率が大幅に低下します。

テストの基本

ソフトウェアシステムは機能のレイヤーを使用して構築されます。現在の多くのシステムでは、100%テストすることは不可能です。テストを効率よく行うには、テストピラミッドに従ってテスト作業を比例的に分散する必要があることが、これまでの実例からわかっています。

testingtriangle.png

テストには多くのタイプがありますが、このガイドでは以下のテストを作成します。

  • 単体テスト(小さな個別の機能単位のテスト)

  • APIテスト(コンポーネントAPIのテスト)

テスト対象のアプリケーションは、AUT(Application Under Test)として指定されます。

テストタイプに応じて様々なツールを使用します。ここでは特定のツールではなく概念をより重視しているため、他のツールを使用して同じ目的を達成できる場合もあります。

このガイドではテストの自動化を目指しているため、手動テストについては説明しません。

OutSystemsプロジェクトにおけるその他のテストガイドについては、OutSystemsのWebサイトをご覧ください。

テスト戦略とテスト計画

アプリケーションがすでに4-Layer Canvasアーキテクチャに基づいて構築されている場合、後述の「単体テストアプローチ」のセクションに進むことができます。それ以外の場合は、テスト戦略の作成方法を理解するために、このまま読み進めてください。

最初のタスクは、アプリケーション機能を単純なものから複雑なものに分割することです。オブジェクトタイプ(サーバーアクション、Web画面など)、フォルダ(またはUIフロー)、名前、リスクの各列を含むスプレッドシートに、モジュール、サーバーアクション、画面、Webブロック、APIメソッドなどのリストを作成します。OutDocを使用してこの情報を取得することもできます。

リストが完成したら、各項目をリスクに基づいて分類します。コンポーネントまたはアクションが失敗した場合、アプリケーションにどの程度の影響があるかを考えます。たとえば、ビジネスエンティティはビジネスルールの基礎となるため高い信頼性が必要ですが、ほとんど使用されない「sysadmin」機能にはそれほど高い信頼性は必要ありません。

アプリケーション機能のリスクが高いほど、より徹底したテストを行う必要があります。

すべてのアプリケーション機能について、1つまたは複数のテストタイプを選択できます。たとえば、サーバーアクションに対しては単体テストもしくは統合テスト(サーバーアクションが他の多くの機能を呼び出すため)によるテスト、またはこれら両方(単体テストの「外部」機能をスキップすることができ、ビジネスプロセスでテストされるため)によるテストを行うことができます。画面のテストはUIテストで行う必要があります。

すべてのアプリケーション機能をカテゴリ分けした後、テストケースを設計します。テストケースの設計についてはインターネット上に多くの情報があります(初歩的なものとしては、tutorialspoint.comstackoverflow.commartinfowler.comがお勧めです)。

テストケースには以下の属性を含めるようにします。

  • タイトル

  • わかりやすい説明

  • 仮定や前提条件

  • テスト手順

  • 機能の実行に使用するテストデータ

  • 予測結果

すべての情報が簡潔かつ正確である必要があります。テストケースは、できる限り簡潔で小さなものにしてください。

大規模なテストケースは管理が難しくなる傾向があるため、通常、少数の大規模なテストケースよりも、多数の小規模なテストケースのほうがうまくいきます。

以下は、Casesアプリケーションのテスト戦略の抜粋です。

通常、テストはテストサイクルの中で行われます。テストサイクルの中でテストケースを実行し、実際の結果と予測結果を比較します。テストサイクルの最後に、望ましくない影響が出ないようにする必要があります(「テストのティアダウン」)。

以下は、これらの概念に関する簡略図です。

失敗したテストを分析し、検出した欠陥を欠陥管理ツールに登録する必要があります。

テスト管理

テストの作成を開始する前に、テストの自動化を管理するためにOutSystemsで構築されたTest Frameworkツールを紹介します。Forgeで入手可能なこのツールは、一般的なテストニーズに対応しています。さらに多くのテスト機能が必要な場合は、市販のテストプラットフォームを検討してください。

Test Frameworkは、2つのタイプのテストケースをサポートしています。

  • 単体テスト: 小さな単位のコード(サーバーアクション)に関するフィードバックをすぐに提供します。

  • APIテスト: RESTまたはSOAP APIに関するフィードバックを提供します。

Test Frameworkは、以下の階層に従ってテストを構造化します。

  • 関連するテストケースのグループであるTest Suite(テストスイート)。

  • 実際のテストであるTest Case(テストケース)。各テストケースは1つのテストスイートに含まれ、1つまたは複数のテスト手順を含みます。

  • 「テストエンジン」によって実行されるテストアクションであるTest Step(テスト手順)。

テストスイート用の変数を作成できます。これらを使用して実行中のテストにデータを提供できます。テストスイート変数にはデフォルト値がありますが、テストケースレベルまたはテスト手順レベルで値を再定義できます。

テストスイート内のテストケースは順番に実行されます。Test Frameworkでは、前のテストケースから次のテストケースに出力値を渡すことができます。これはテスト手順レベルで行うこともできます。

テストの自動化はAPIおよび単位レベルのテストにおいて最も有効です。

Test Frameworkでは、[1-Click Test]ボタンを手動で押すか、ビルトインのスケジュールメカニズムを使用してテストを実行できます。継続的統合パイプラインの一部としてTest FrameworkのテストをトリガーできるREST APIも提供されています。このAPIでは、テストを開始してテスト結果を収集することができます。

OutSystemsプロジェクトのテストを高速化する機能がTest Frameworkに追加されました。
これには、BDD eSpaceおよびUTF eSpaceのスキャン、OutSystemsで生成したWebサービスドキュメントからのテストの生成などが含まれます。

単体テストアプローチ

単体テストは小さな単位の機能に対してすばやく実行するテストで、フィードバックを迅速に受け取るのに有効です。通常、このテストは、コードが正しく実装され、安定していることを確認するために開発者によって作成されます。そのため、自動化の対象として最適です。

OutSystemsでは、テストの作成と管理を容易にするために、単体テストにはBDD Frameworkを使用することを推奨しています。
BDD Frameworkを使用して単体テストを作成する方法については、こちらのビデオをご覧ください。

アプリケーションをテスト可能な状態にする

アプリケーションは、適切なアーキテクチャを選択し、機能をテスト可能な小さな単位に分けることにより、テストが容易になるように設計する必要があります。たとえば、すべてのビジネスエンティティをコアモジュール内に配置し(これらの概念については、4 Layer Canvasを参照)、この周囲に、データ、依存関係、計算などが適切であることを検証するサーバーアクションを配置する必要があります。画面アクションは単体テストではテストできないため、画面アクション内にはビジネスロジックを配置しないでください。

複雑なサーバーアクションに「テストモード」パラメータを追加すると、とても便利な場合があります。複雑な計算や検証を実行するサーバーアクションでは、最後に、データベースの変更(アプリケーションの状態の変更)をコミットすることがあります。テストの際に「テストモード」パラメータを使用すると、これらのアクションによって変更がコミットされないようにすることができます。この「テストモード」パラメータでは、オーバーヘッドや複雑さはそれほど増加せず、アプリケーションの状態に影響を及ぼすコードの小さな部分をスキップしながらコードの大部分をテストできるようになります。

単位テストの実行方法

最初に、単位テスト用のeSpaceを作成します。このeSpaceは、本番環境にデプロイされないように、アプリケーションコードを持たないアプリケーション内に配置することがとても重要です。そうすることでテストが本番環境にデプロイされません。機能を持つアプリケーションモジュールと、機能をテストするテストモジュールには、簡潔な命名規則を採用することを推奨します。

デモ用として、Cases Webアプリケーション用にCases_Testsアプリケーションを作成しました。

テスト用のeSpaceを作成した後、BDD Frameworkへの参照を追加します(BDD Frameworkのインストールの詳細については、Forgeをご覧ください)。このeSpaceでテストするアプリケーションモジュールへの参照も追加する必要があります。

以下は、Cases_UnitTests eSpaceの参照です。

Unit01.png

BDD Frameworkでは、テストケースごとのシナリオを使用します。BDDシナリオはWebブロックであるため、Web画面上に存在します。わかりやすい名前を使用して、関連性が高いテスト対象のサーバーアクショングループに対してWeb画面を作成することを推奨します。サーバーアクションがアプリケーションモジュール内に存在しているフォルダと同じ名前を使用して、Web画面をUIフローで構成する必要があります。BDD Frameworkのビデオで説明されているとおり、各テストケースのシナリオとすべてのテストケースが成功したかどうかを確認する「最終結果」を作成します。

Web画面で、GivenWhenThenの各画面アクションを作成します。画面に複数のシナリオがある場合、Create_GivenCreate_WhenCreate_ThenDelete_GivenDelete_WhenDelete_Thenのように、シナリオごとに3つの画面アクションを作成することがあります。

「BDD手順」を各「BDDシナリオ」にドラッグ&ドロップして、適切な画面アクションを割り当てます。

以下は、CRUD(「ケースの作成、(読み取り)、更新、削除」)テストケースの例です(「ケース」の場合、「削除」は「ケース」の終了です。「ケース」の読み取りに対する特定のシナリオはありません)。

Unit02.png

Given画面アクションを開きます。システムが初期状態であることを確認するコードを作成します。次のようになります。

CreateGiven.png

  • Contactが存在することを確認します

  • ケースの履歴が適切な状態であることを検証します

  • オープンのケースの数など、さらに情報を取得して検証します

  • その他

Case_Createテストケースでは、「Antonio Moreno」という名前の連絡先のIDと「Antonio Moreno」によってオープンになったケースの数が、特定のアクションによって取得・保存されます。

「Contact Id」は新しいケースを作成するときに使用します。ケースの数は検証で使用します。

次に、When画面アクションを開き、ターゲットアプリケーションのサーバーアクションを呼び出します。通常、Whenアクションはとてもシンプルであり、設定パラメータによってサーバーアクションを呼び出し、最小限の検証結果を保存します(Thenアクション内に配置されます)。

Unit03_when.png

動作の仕様のみに基づいてテストを行う、ブラックボックスアプローチを推奨します。テストでは各入力データに対する取得結果を考慮する必要はありますが、テスト対象のサーバーアクション「内」のコードに関する知識を考慮する必要はありません。 テストは1つのみを実行する必要があります。つまり、1つのサーバーアクションの呼び出しのみを行います。

「ケース」を作成してグローバルカウンタを増やすなど、アプリケーションが他のサーバーアクションを順番に呼び出す場合、別の方法を検討する必要があります。

  • アプリケーションを変更し、すべての呼び出しを別の「上位の」サーバーアクションにカプセル化する。

  • 呼び出されるサーバーアクションの順番をテストする「統合テスト」を作成する。

Whenアクション内では絶対に検証を実行しないでください。

最後に、Then画面アクションを開き、検証を追加します。これは難しいですが、重要な手順です。すべての必要な検証を実行し、テストが有効であることを確認します。このテストは回帰テストとして使用されるため、単純な検証も含める必要があります。

Unit03_then.png

検証が失敗したときにどの検証が失敗したかを簡単に特定できるようにするため、Assert条件に正確な名前を付けます。

条件がTrueになることを想定している場合は肯定的な名前を付け、Falseになることを想定している場合は否定的な名前を付けます。

肯定的な場合の例: 「Case was created」

否定的な場合の例: 「History not empty」

「作成日時」の値の検証など、検証によってはとても難しい場合があります。このような場合、ある間隔内で値を検証してこのタスクを支援する検証関数を使用します。〇これには、「IsToday(作成日)」などがあります。

Case_Createでは、エンティティレコードが作成されたこと(Id <> NullIdentifier())、連絡先に1つ以上の「ケース」があること(NrCases_OK)、入力したデータが実際に「ケース」に含まれること、つまり、無視されたデータや想定外のデータの切り捨てなどがないこと(CaseData_OK)を検証します。

適切なテストデータの重要性

テストを適切に行うには、テストデータが適切であることが極めて重要です。そのため、すべての画面にテストデータに関連する2つの画面アクション(TestData_CreateおよびTestData_CleanUp)を含めることを推奨します。

TestData_Createアクションは、Web画面のすべてのテストケース(シナリオ)に必要なすべてのデータを作成します。これによりテストデータの作成の複雑さが軽減され、テストデータのクリーンアップに必要な最小限の情報(通常、「エンティティ識別子」)が画面レベルで保存されます。

TestData_CleanUpアクションは、使用したテストデータをクリーンアップします。

不適切なデータの作成やクリーンアップを避けるために、テストデータの設定アクションとクリーンアップアクションがデータベースに直接アクセスしないようにします。AUTから利用可能なサーバーアクションを使用します。

保守の観点から、Web画面のPreparationでテストデータを作成しないことを推奨します。

ただし、この方法が適切な場合もあります。「高度な単体テスト手法」をご覧ください。このような場合は、そのためのサーバーアクションを作成してPreparationで呼び出します。ServerActionsフォルダにTestDataフォルダを作成し、フォルダ内にこれらのサーバーアクションを配置します。

最初のテストシナリオの設定ではTestData_Createアクションを呼び出す必要があり、最後のテストシナリオのティアダウンではTestData_CleanUpアクションを呼び出す必要があります(ビデオで説明されているとおり、「SetupOrTeardownStep」Webブロックをご覧ください)。

テストデータを作成するアクション内で例外ハンドラを使用しないでください。テストの設定が失敗した場合、テストが実行され、時間と手間を減らすことができます。テストを実行して失敗するたびに、何が起きたかを把握するために追加の作業が必要になります。問題がテストデータの作成中に起きた場合、例外ハンドラによってその問題が隠され、不要な分析タスクが発生します。

一部の高度なシナリオでは、テストデータの作成を簡略化するためのサーバーアクションを作成すると便利です。これらの補助アクションはTestDataフォルダ内に配置します。これらのアクションは他のテストeSpaceと共有されることがありますが(「ビジネステストフレームワーク」の一種を作成)、アクションを共有するとテストeSpace間の依存関係が高まるため、推奨されません。

高度な単体テスト手法

単体テストは、実際にはOutSystemsのコードを使用します。これは同じ言語を使用して単体テストを作成する他の開発プラットフォームと同様です。OutSystemsのビジュアル言語で単体テストが作成されるため、ローコードで単体テストのロジックを作成する場合と同じような高い生産性が実現します。

テスト作成時には、Table Recordsなどで同じ言語構造を使用できます。複数の変数の組み合わせを検証する場合、異なるテストケース用のデータを含むレコードのリストを作成し、そのリストをTable Recordsウィジェットに設定できます。行にBDDシナリオを配置することで、最小限の労力で複数のテストケースが実際に実行されます。次のTest Framework単体テストの例では、「Table Records」内に「シナリオ」が配置されています。

これはコードです。Table Records内にシナリオがあることがわかります。
Unit04.png
これは実行結果です。多くのシナリオが実行されたことがわかります。
Unit04_result.png

Test Frameworkに単体テストを追加する

Test Frameworkに単体テストを追加します。

  1. 最初に、回帰テスト用の新しいテストスイートを作成します。これを行うには、最上部メニューの[Define]を押して右側の[New Test Suite]を押します。以下の画面が表示されます。

    TestSuiteNew01.png

  2. データを入力して[Create Test Suite]ボタンを押します。画面は以下の画像のようになります。

    TestSuiteNew03.png

  3. 次に、単体テストケースを作成できます。これを行うには、右上の[Unit Test]ボタンを押します。以下の画面が表示されます。

    TestCaseNew01.png

  4. テストケースの情報を入力して[Create Test Case]ボタンを押します。画面が更新され、テスト手順を作成できるようになります。

    TestCaseNew02.png

  5. 次に、新しいテスト手順を作成できます。これを行うには、左側の[New Test Step]ボタンを押します。以下の画面が表示されます。

    TestStepNew01.png

  6. 単体テスト手順を作成するには、ターゲットURLに「https://<ご利用のサーバー>/Cases_UnitTests/Case_CRUD.aspx」のような有効なURLを入力します。[Update Step]ボタンを押すと、実行の準備が完了します。

    TestStepNew02.png

既存の単体テストを使用する

単体テストの数が多いと、時間がかかる場合があります。テストの作成時間を短縮するために、アプリケーションを参照するすべての単体テストeSpaceをTest Frameworkで収集できます。これを行うには、[Test Case]画面で、[Load BDD Tests]ボタンを押します。

LoadBDD.png

[Update Test Case]ボタンを押すと、データベース内の情報がすべて更新されます。テスト手順が編集可能になり、これに応じてすべてのカウンタが更新されます。

単体テストを実行する

  1. テストスイートを実行するには、[Define]メニューボタンを押してテストスイートのリストに移動します。

    TestSuiteList.png

  2. 実行するテストスイートの[1-Click Test]ボタンを押します。バックグラウンドでテストの実行が開始します。

  3. [Analyze]メニューを押すと、テストスイートの実行結果が表示されます。以下に例を示します。

    TestResults01.png

  4. テスト実行を展開すると詳細が表示されます。以下に例を示します。

    TestResults02.png

テストの実行を分類する

テストは、アプリケーションが予測どおりに動作していることを確認するために実行します。テストに成功しなかった場合、それが欠陥によるものであるか、不適切なロジックやデータなど、テスト自体の問題によるものであるかを特定することが重要です。

テストの失敗の原因を自動的に分類することは不可能です。そのため、テストが失敗するたびに手動で分類する必要があります。欠陥が原因である場合、テスターはできる限り詳細な情報を記録する必要があります。詳細な説明、実行手順、使用データ、取得結果、予測結果、添付ログ、画像などを追加します。アサーションの誤りなどテスト自体の誤りが原因である場合、テスターは失敗が再発しないように修正するか、少なくとも、テストが修正されるまでは分類の負担が増えないように隔離する必要があります。

Test Frameworkではすべてのテストが自動的に分類されます。成功したテストは「Passed」に分類され、失敗したテストは「Unclassified」に分類されます。未分類のテストについては、この画面に表示されているような詳細な情報をテスターが設定する必要があります。

TestResults03.png

アプリケーションの異常によってテストが失敗した場合は、アプリケーションに欠陥があります。テスターは欠陥管理ツールに欠陥を登録し、できる限り詳細な情報を提供する必要があります。

TestResults05.png

すべての欠陥はワークフローに従って処理します。以下は、一般的な「欠陥ワークフロー」の例です。

DefectWF.png

通常、欠陥ワークフローの構成は欠陥管理ツールで行います(ここではデモのため、欠陥管理ツールとしてJIRAを使用します)。

JIRAで欠陥を作成し、このテスト実行にリンクします。[Add Defect]ボタンを押し、欠陥の名前とJIRAからのURLを追加してリンクを設定します。

LinkDefect02.png

テストがテスト自体の誤りのために失敗した場合、テスターはテストを「Broken」に分類する必要があります。テスト自体が原因である場合や、使用したテストデータが原因である場合があります。

TestResults04.png

テスターがテスト手順をすぐに修正できない場合は、テストを隔離する必要があります。例として、以下の画面をご覧ください。

Quarantine01.png

APIテストアプローチ

最新のアーキテクチャでは、システムの相互運用、複合、再利用が支持されています。新たな開発ソフトウェアプロジェクトでは、特定のビジネス目標を持ち、小型でバージョン管理が独立し、拡張性の高い顧客中心型のサービスを作成することに重点が置かれます。これらのサービスは、明確に定義されたインターフェイス(API)を使用した標準プロトコルを介して相互に通信します。こうした新しいソフトウェアアーキテクチャの例としてはマイクロサービスなどがあり、幅広いプラットフォームとデバイス(Web、モバイル、IoT、ウェアラブル機器など)をサポートするのに理想的であると考えられています。これらはアプリケーションの異なる開発スピードをサポートし、多くの同時ユーザーに対応できます。

また、効果的なソフトウェア生産のためのAPIセマンティクスの検証に不可欠になっています。これはAPIテストによって行うことができます。通常、これらのテストは、開発者によってAPIメソッドを使用する際に作成されます。APIには高い安定性が必要であるため、これらのテストは自動化の対象として最適です。

APIテストは、設定(APIメソッドを呼び出すためのデータの準備)、APIメソッドの呼び出し、結果の確認が単体テストと似ています。セマンティクスでは複数のAPIの呼び出しが必要な場合があり、この場合は複数の手順を含むテストを作成します。

Test FrameworkでのネイティブAPIテスト

Test Frameworkは、RESTメソッドまたはSOAPメソッドを公開するAPIのAPIテストをネイティブでサポートします。APIテストケースを作成するには、[Cases Regression Tests]テストスイートに移動します。次に、[API Test]ボタンを押します。新しいテストケースの情報を入力します。APIエンドポイントURLはService Studioで確認できます。[Update Test Case]ボタンを押すと、以下の画面が表示されます。

TestCaseRESTNew01.png

OutSystemsプラットフォームでは、一般的なプロトコルであるRESTおよびSOAPを利用するWebサービスAPIを作成できます。

REST APIの場合、OutSystemsではswagger.json形式のドキュメントファイルを生成します。APIエンドポイントURLに/swagger.jsonを追加します。

SOAP APIの場合、OutSystemsでは“?WSDL”を追加してAPIエンドポイントURLからWSDL形式のドキュメントファイルを生成します。

APIテスト手順を手動で追加する場合がありますが、Test FrameworkにはRESTインターフェイス用とSOAPインターフェイス用のAPIディスカバリビルトインが組み込まれています。

REST APIドキュメントからすべてのメソッドを読み込むには、[Load API methods from Swagger Definition]ボタンを押します。

Test Frameworkはすべてのメソッドをインポートし、メソッド内で使用されるすべてのパラメータ用の変数を作成します。これらの変数を使用して各呼び出しの値を定義することや、予測される戻り値を指定することができます。これについては後で詳しく説明します。

すべてのAPIメソッドを読み込んだ後、画面は次のようになります。

TestCaseRESTNew03.png

使用しないAPIメソッドがある場合、不要なものを削除します。いずれかのメソッドを選択すると、以下の画面が表示されます。

TestCaseRESTNew04.png

[Remove - Don’t import automatically]ボタンを押すと、メソッドはインポートされません。除外するすべてのAPIメソッドについてこの操作を繰り返します。[Save Test Case]ボタンを押すと、テスト手順として目的のメソッドがインポートされ、各パラメータ用の変数が作成されます。

TestCaseRESTNew07.png

各テスト手順の入力値と予測値を定義する必要があります。目的の変数を選択し、入力値または予測値(出力パラメータの場合)を指定します。[Save]ボタンを押して変数を保存します。

${<変数名>}を入力値として使用すると、前のテスト手順の変数値を使用できます。

以下は、テスト手順の最終構成の例です。

TestCaseRESTNew08.png

高度なAPIテスト手法

APIメソッドの呼び出しでは不十分なシナリオがあります。メソッドの呼び出し間に複雑なオペレーションを実行する必要がある場合があります。Test Frameworkのネイティブサポートでは、そういったシナリオを実装するには不十分です。

単体テストとよく似た方法で、BDD Frameworkを使用してAPIテストを作成できます。これにより、高度なAPIテストでローコードを使用できます。サーバーアクションを使用する代わりに、RESTエンドポイントまたはSOAPエンドポイントを使用してAPIをインポートした後、単体テストの章の説明に従ってテストを作成する必要があります。

この方法が単体テストに似ていることを示すため、REST APIを利用するケース作成テストのGivenWhenThenの各アクションを以下に示します。

CreateGivenREST.png CreateWhenREST.png CreateThenREST.png

Test FrameworkのOverview画面

テスト結果は、[Overview]画面に日付別で表示されます。この画面を使用すると、テストの傾向を簡単に追跡できます。[Overview]メニューオプションを押すと、以下の画面が表示されます。

Overview01.png

左側に、テスト実行が日付別で表示されます。日付を展開すると、その日に実行された各テストケースのテスト実行に簡単にアクセスできます。詳細リストからテスト実行をドリルダウンして詳細を分析できます。

右側の上のグラフは、テストケース実行の成功と失敗の推移を示しています。テストケースは実際のテストを表しており、それぞれが複数のテスト手順で構成されています。

テストプロジェクトの早い段階では、アプリケーションの新しい領域のテストが作成されるにつれて、テストケースの合計数が増加するのが普通です。作業が進むと、失敗したテストケースの数が減少し、成功するテストケースの数が増加することが予測されます。これは、品質が向上していることを意味します。

下のグラフは、実行されたテスト手順の合計数とその分類を示しています。テスト手順は、実際に成功または失敗したテスト実行単位です。失敗の場合、欠陥または不備のいずれかに分類できます。

このグラフで以下の傾向がわかる場合があります。

  • 成功するテスト手順の数が多いほど、テストプロジェクトが網羅的になる。

  • 未分類のテスト手順の数が多いほど、テスターが実行を分類するために要する作業(「テストの技術的負債」)が多くなる。

  • 不備のあるテスト手順の数が多いほど、テストを修正して再度利用できるようにするために必要な作業が多くなる。

  • 欠陥が見つかったテスト手順の数が多いほど、アプリケーションの品質は低くなる。