こんにちは、品質向上の木下です。
この記事では、弊社で実施している総合テストのうちの一つ、サイクルテストについて紹介します。
サイクルテストの位置づけ
サイクルテストは、以下図にあるV字モデルのテスト工程、総合テスト(ST)の中の一つのテストとして実施しています。
v字モデル
サイクルテストでは、1日の業務的な意味合いを持つポイントでのジョブの実行や、その影響でユーザーが直接目にするサービスサイト、モバイルアプリでの挙動、そして社内業務を扱う基幹システムでの挙動について確認しています。
テスト実施時の観点としては、特定の業務やジョブ実行の結果について、以下の観点で確認しています。
- バッチ処理が正常に処理を行えているか
- バッチ処理でエラーが発生した際に、エラーが発生したバッチから再実行してデータの冪等性を担保できているか
- 特定の業務やジョブ実行後に、サービスサイトやモバイルアプリ、社内の基幹システムで想定した表示結果となっているか
サイクルテストでは、仮想の日時を設定して、バッチ処理や社内の基幹システムの操作を行い、仮想的に日時を進め、現実想定での挙動の確認を行います。
そのため、決まった日時の断面での確認となる単体テスト(UT)や結合テスト(IT)で発見できない、ユーザーの操作と複数のジョブ、基幹システムでの操作の間で発生する、不具合を発見することが目的です。
サイクルテストの実際の流れ
弊社でサイクルテストを実施する際には、以下の事前準備を行います。
- サイクルテスト専用DBを用意
- サービスサイト、モバイルアプリのモジュールを用意
- 基幹システムを用意
- 統合運用管理ツールに、ジョブを用意
- テストケースにあう属性を持つアカウントを作成
- サイクルテストを実施する仮想の業務日時を設定
サイクルテスト実施に向けた準備が完了すれば、以下の流れで、サイクルテストを実施します。
- サービスサイトやモバイルアプリで操作
- ジョブの実行や基幹システムの操作
- サービスサイトやモバイルアプリで表示内容を確認
サイクルテスト中は、日時を進めながら、上記の操作を繰り返し行います。
例として、弊社でのWealthNaviのサービスで口座開設から運用開始までの一連の主要な流れ[1] について、サービスサイトでの操作や基幹システムでの操作、ジョブの実行によるバッチ処理を以下に図示します。
例
運用開始までの流れとして、ユーザーがサービスサイト画面で口座開設の申し込みを行った後、日時が進み、WealthNaviで口座開設の手続きを行います。その後、ユーザーが入金などの操作を行い、日時が進み、WealthNaviでのバッチ処理でETFが購入され運用が開始されます。
統合管理運用ツールでジョブ実行
テストを実施する際には、以下図のようにいくつかの時間単位で、複数のバッチ処理をまとめたジョブ、複数のジョブをまとめたジョブネットを用意して、統合運用管理ツールに登録します。
統合管理運用ツール
テスト時の統合管理運用ツールの操作回数を減らすことで、テスト実施の効率化を図っています。
クエリ実行で仮想データを生成
またサイクルテストは、未来の日付でテストを実施することがあり、ジョブの中にはテスト実行時の日付を含むデータが必要な場合もあります。
そのためサイクルテストの実施では、仮想データ((祝日カレンダーなどがあります。))を用意し、補完目的でクエリを実行してデータを登録し、テストを進めます。クエリ実行でも、時間単位で複数のクエリを用意し、テスト実施の効率化を図っています。
DB
サイクルテストで得られた成果例
サイクルテストの成果として、以下のような、UTやIT、またSTのリグレッションテストでは検出できない不具合を発見できています。
- バッチの実行タイミングの不備
- 当該バッチ以前のバッチ処理の結果を考慮できておらず、入力値にその変化を反映できていなかった
- バッチ処理の計算ロジックの間違い
- ユーザーの特殊な属性を考慮できておらず、計算式に反映できていなかった
- インフラ構築手順の間違い
- パラメーターが別の類似した名称のものが、テスト環境に設定されていた
- SQLの反映不足
- リリース対象とすべきSQL群のうち、あるSQLを反映できていなかった
さいごに
サイクルテストの困難な点
サイクルテストの実施で一番大変と感じる点は、バッチやクエリの実行を間違えずに実行する点です。テスト中にバッチの実行やクエリの実行を間違えると、誤ってDBのデータが書き換えられ、データを復旧する手戻りが発生します。
そのため、サイクルテストを実行する際には、他のタスクは並行して実施せず、テストのみに集中するよう調整しています。
今後の改善点
現在、サイクルテストは、実施前に、DBやサービスサイト、モバイルアプリ、統合運用管理ツール、基幹システムと業務全体に関連あるシステムを、単体テストや結合テストなどとは別に構築する必要があり、実施までの準備に時間がかかります。そのためサイクルテストの実施は、改修範囲が広く、業務観点でデグレの発生可能性が高い場合に行っています。
今後の改善点としては、小・中規模案件においても、手軽にテストを開始できるよう、環境準備の自動化を推進していく必要があります。
サイクルテストを実施する意義
サイクルテストで発見できる不具合の一部は、リリース対象のバッチ処理のプログラム改修、実行すべきタイミングの変更や既存のバッチ処理への改修など、大きな改修が求められる場合があります。
もし本番環境のバッチ処理で障害が発生すると、バッチ処理で書き換えられたデータを障害発生前に戻すなど、困難な対応を求められる場合があります。
そのためバッチ処理などの重要なプログラムに変更が入る際には、サイクルテストなどで潜在不具合の発見を行い、品質を担保しています。
明日は、インフラエンジニア 和田 の「開発環境の稼働スケジュールをNotionとecspressoで管理してみた」です！
お楽しみに！
📣ウェルスナビは一緒に働く仲間を募集しています📣
著者プロフィール
木下智弘(きのした ともひろ)
2015年10月にウェルスナビに、エンジニアとして入社。
プライベートでは、Google Cloudを好んで利用しています。
Goのシンプルな考えが好きです。
-
運用開始までの詳細な解説は以下でご確認ください。
https://support.wealthnavi.com/hc/ja/articles/900007208943 ↩︎
Discussion