Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
この記事では、パイプライン テスト レポート と テスト分析で一般的に使用される用語について説明し、Azure Pipelines でのテストを改善するためのヒントを提供します。
| 任期 | Definition |
|---|---|
| Duration | ビルドまたはリリース パイプラインでの テスト、 テスト実行、または テスト実行全体の実行 に経過した時間。 |
| Owner | テストまたはテストの実行の所有者。 テスト所有者は、通常、テスト コードの属性として指定されます。 サポートされているテスト結果形式の Owner 属性のマッピングを表示するには、「テスト結果の発行」タスクを参照してください。 |
| ビルドの失敗 | テスト ケースの連続するエラーが最初に発生する ビルド への参照。 |
| リリースの失敗 | テスト ケースの連続するエラーが最初に発生する リリース への参照。 |
| 結果 | テスト結果には、Aborted、Blocked、Error、Failed、Inconclusive、In progress、None、Not applicable、Not executed、Not impacted、Passed、Paused、Timeout、Unspecified、Warning の 15 個の結果が考えられます。 一般的に使用される結果の一部は次のとおりです。 - 中止: 内部または外部の要因 (不適切なコード、環境の問題など) により、テストの実行が突然終了しました。 - 失敗: 目的の結果を満たしていないテスト。 - 不確定: 確定的な結果を得ずにテストします。 - 未実行: テストは実行のためにスキップ済みとしてマークされています。 - 影響なし: パイプラインをトリガーしたコード変更の影響を受けずテストします。 - 成功: テストが正常に実行されました。 - タイムアウト: 指定したしきい値を超えるテスト実行時間。 |
| 不安定なテスト | 非決定論的な動作を持つテスト。 たとえば、テストでは、同じ構成、コード、または入力に対して異なる結果が得られます。 |
| フィルター | 使用可能な属性を使用して、結果セット内のテスト結果を検索するメカニズム。 詳細については、こちらを参照してください。 |
| グルーピング | 要件、テスト ファイル、優先度などの使用可能な属性に基づいてテスト結果ビューを整理するための支援。 テスト レポートとテスト分析の両方で、テスト結果のグループ化がサポートされます。 |
| 合格率 | 1 つの実行インスタンスまたは一定期間にわたるテスト結果の成功を測定します。 |
| 優先順位 | テストの重要度または重要度を指定します。 優先順位は通常、テスト コードの属性として指定されます。 サポートされているテスト結果形式の Priority 属性のマッピングを表示するには、「テスト結果の発行」タスクを参照してください。 |
| テスト分析 | 意味のある分析 情報を提供するための履歴テスト データのビュー 。 |
| 試金石 | 指定した分岐内の 1 つのテストを一意に識別します。 |
| テスト ファイル | パッケージ化方法に基づいてテストをグループ化する。ファイル、DLL、その他の形式など。 |
| テスト レポート | トラブルシューティング、追跡可能性などの状態とヘルプの詳細を含む、パイプライン内の テスト実行の単一インスタンスのビュー 。 |
| テスト結果 | 特定の結果と詳細を持つテスト ケースの実行の単一インスタンス。 |
| テストの実行 | 以下に基づくテスト結果の論理的なグループ化: - 組み込みタスクを使用して実行されたテスト: Visual Studio Test、 Ant、 Maven、 Gulp、 Grunt 、 Xcode などの 1 つのタスクを使用して実行されたすべてのテストは、1 回のテスト実行で報告されます - テスト結果の発行タスクを使用して発行された結果: 1 つ以上のテスト結果ファイルからすべてのテスト結果を 1 回の実行にグループ化するか、ファイルごとに個々の実行にグループ化するオプションを提供します - API を使用して発行されたテスト結果: API は 、必要に応じてテスト実行を作成し、各実行のテスト結果を整理する柔軟性を提供します。 |
| トレーサビリティ | テスト結果から要件、バグ、またはソース コードまで前方または後方に トレース する機能。 |
ベスト プラクティス
アプリケーションの信頼性を確保するには、Azure Pipelines での 包括的なテスト が必要であり、単体テストと統合テストが不可欠です。 クラウド環境 (特に サーバーレス アプリケーション) での統合のテストは、分散アーキテクチャ、正しく構成されていない IAM アクセス許可、およびサービス間の統合の問題が原因で課題が生じます。
これに対処するには、本物の Azure サービスと対話しながらコードをローカルで実行し、現実的なテストを容易にし、自動テストに適したデバッガー ツールを有効にすることを検討してください。 このアプローチを実装するには、一時的な Azure リソースをプロビジョニングする必要があります。 理想的には、 環境ごとに個別のアカウントを作成します。または、Azure パイプライン内での動的プロビジョニングが可能ですが、これにより実行時間が長くなり、慎重なリソースの使用停止計画が必要になります。 名前付けの競合を最小限に抑えるには、必要でない限り明示的なリソースの名前付けを避け、リソース名に環境名を含めます。
ヘルプとサポート
- トラブルシューティング ページ を 参照してください
- Stack Overflow に関するアドバイスを受け、開発者コミュニティを通じてサポートを受ける