2019年6月7日 / 最終更新日時 : 2020年9月3日 user 事例・ソリューション

テスト自動化における 10 のベストプラクティス #7: CI パイプラインとの統合

継続的インテグレーション (CI)、継続的デプロイ (CD)、DevOpsなどの迅速なアプリケーション開発では、高品質なソフトウェアを小規模かつ頻繁にリリースするという共通の目的があります。開発のサイクルが数週間であっても数日であっても、統合された自動化テストは開発ペースを保つ上で非常に重要です。

CI パイプラインでの自動化テスト

以下の図は、一般的な CI パイプラインです。開発者は、Git、TFS（Team Foundation Server）、Subversion といったバージョン管理システムの共有リポジトリからコードをチェックアウトします。開発者がコードの変更を行い、変更をバージョン管理システムにコミットしたタイミングで、CIジョブが実行されます。CI環境では、テスト対象アプリケーションをビルド後、自動化テストを実行して新しいコードを検証します。また、アプリケーションのデプロイの可否を判断するために、テスト結果が開発チーム全体にレポートされます。そして、CD 環境では、アプリケーションは本番環境に自動的にデプロイされます。

継続的インテグレーションのパイプライン

自動化テストを伴う継続的インテグレーションは、以下のメリットを組織にもたらします。

開発者は、コードの変更に伴う品質面、機能面、システム全体への影響について迅速にフィードバックを得ることができます。これにより、不具合の修正をより容易に低コストでおこなえます。
小さな変更を頻繁に統合することで、複数の開発者が1つのアプリケーションを開発する場合に生じるマージの競合が減少します。また、マージの競合が発生した場合でも、その解決が容易になります。
チーム全員がビルド状況を明確に把握できます。
テスト、実証、リリースにおいて常に「良いビルド」を使用できます。

CIパイプラインでの自動化テストの推奨事項

以下に、CIパイプラインでの自動化テストにおける推奨事項を挙げます。なお、推奨事項の一部は、CIプロセス自体のペストプラクティスでもあります。CIプロセスのベストプラクティスについては、WikipediaのContinuous Integrationをご参照ください。

単体テストだけに頼らない

個々の開発者のローカル環境における単体テストでは、本番環境に導入されたコードの動作について十分に分かりません。新規または修正されたコードの統合は、さまざまな理由からビルドを失敗させることがあります。たとえば、他の開発者による変更が新しいコードと競合しているかもしれません。また、開発者のローカル環境と本番環境に違いがあるかもしれません。そのため、ビルド検証プロセスの一部として統合テスト、回帰テスト、および優先度の高い機能 UI テストを実行することが重要です。

ビルドを自己テストする

コンポーネントテストでは個々のコードユニットをテストします。また、コンポーネントテストは単体テストと呼ばれることが多く、それ以外にもモジュールテストやプログラムテストと呼ばれることもあります。開発者は、単体テストを作成および実行し、できる限り開発プロセスの早い段階でコード中の欠陥を発見して修正します。これはアジャイル開発環境では重要です。アジャイル開発環境は、リリースサイクルが短く、迅速なテストフィードバックを必要とします。

自動化テストをリファクタリングする

完了までに時間のかかるビルドはCIプロセスを中断させます。テストを効率的な状態に保つには、自動化テストのコードを、アプリケーション開発のコードと同じように扱うことです。たとえば、同じ機能をチェックしている複数のテストや、重複したテストデータを使用しているデータ駆動型テストなど、削除できる冗長なコードがないかを、定期的に確認してください。境界値分析や同値分割といった技法は、重要なケースだけにデータ駆動型テストを削減するのに役立ちます。

ビルドを高速に保つ

開発者が頻繁にコミットすることに消極的にならないよう、できる限りビルドテストを迅速に完了することが重要です。このプロセスを高速化するには、ビルドの検証に必要な最小の自動化テストを実行します。統合テストは、その複雑さから、一般的に単体テストよりも時間を要するため、まずスモークテストとサニティテストを行い、ビルドが失敗しないことを確認しましょう。

また、頻繁にマージする場合は、マージごとではなく、日次ビルドにのみ統合テストを実行するのが効率的かもしれません。そして、全ての回帰テストを実行するのは、本番環境へのデプロイなど、本当に必要な場合だけにしましょう。

※Ranorexでは、テストの一部分だけ (スモークテストや、変更があったアプリケーションの機能/モジュールだけのテストなど) を実行するよう設定することができます。何回かのテストサイクルで欠陥が発見されていない、優先度の低い回帰テストケースは、ビルドテストから除外しましょう。

自動化テストにソース管理を利用する

コードと同じリポジトリで自動化テストを管理しましょう。同じリポジトリで管理すると、「テストの正しいバージョン」と「ソースコードのバージョン」を一致させるのが容易になります。

※Ranorexは、Git、TFS、Subversion をはじめ、一般的なソース管理システムと連携できます。

正しい環境でテストする

誤ったOSバージョンの使用や、サービスが不足しているなどの問題によるテストの失敗を最小限にするために、安定した環境でテストを実行しましょう。理想としては、テスト専用の独立したテスト環境を用意することです。また、本番環境と同等のテスト環境を用意するべきですが、これには難しい場合があります。

現実問題として、サードパーティ製アプリケーションなど、テストが依存するいくつかの環境を仮想化する必要があるかもしれません。複雑なテスト環境では、Dockerコンテナなどの仮想化環境や、ソリューションを使用することが、本番環境を効率的に用意できる方法かもしれません。

並列テストを行う

CI/CD 環境ではスピードが求められます。Selenium Gridによるテスト実行の分散化や、複数の物理環境または、仮想環境でのテスト実行の並列化を行うことで、テストに掛かる時間を節約することができます。

UIテストと探索的テストを含める

アプリケーションを本番環境にデプロイする準備が整ったことを確認するには、複数の自動化テスト手法を組み合わせて使用します。自動化された単体テストと統合テストに加え、UIテストによって、メイン機能を検証し、アプリケーション全体で共通のユーザーパスの確認と、複雑なワークフローを検証します。また、探索的テストは、自動化テストが見逃す欠陥を発見します。

デプロイを検証する

新しいビルドを本番環境にデプロイした後、デプロイが成功したかどうかを簡単に確認する方法として、本番環境でスモークテストを実行します。

CIパイプラインにRanorexのテストを統合する方法については、Ranorex Blogの「Integrate Automated Testing into Jenkins」を参照してください。この記事は JenkinsのCIツールに特化していますが、Ranorex のテストはあらゆるCI環境から実行できます。

（この記事は、開発元 Ranorex 社 Blog 「10 Best Practices in Test Automation #7: Integrate with a CI Pipeline」2018年6月11日の記事を元にしています。）