BDDテストをバッチシナリオに適用しますか？

Question

私は自分の組織にBDDのプラクティスを適用しようとしています。私は夜間のバッチジョブがバッチジョブを実行してお互いの間でデータを渡す巨大なオーケストレーションのマルチシステムフローである銀行で働いています。

私たちのテストでは、インタラクティブなオンラインテストはおそらくテストシナリオの40-50％しか占めておらず、残りはバッチジョブの中に組み込まれています。一例として、テストシナリオは次のようになります。私の貯金は、夜間バッチがバッチ実行後3AMに続いて午後11時

で実行されると午後10時

のよう$ 100のバランスを持っている占めていることを考えると

1. 私は$ 0.001の追加の未収利息があることを確認して戻ってきてください。
2. また、銀行の総勘定元帳には、未払利息$ 0.001を追加入力する必要があります。

このように、これは非常に非同期のシナリオです。私がキュウリを使ってトリガーするのであれば、ステップ定義を作成して$ 100の残高を10PMでアカウントに入れることができますが、キュウバーを使って11PMでバッチをトリガーするのは現実的ではありません通常、Control-Mなどの独自のスケジューリングツールを使用してオペレータによって実行されます。そして、キュウリをして、数時間待って、未払いの金利を確認する前に、私はタイムアウトに遭遇するかどうかわからない。

これは単なるシナリオの1つです。バッチランは銀行にとって非常に高価であり、できるだけ多くのシナリオを1回のバッチランに乗せることを常に追求しています。定期預金期末の最終的な利息が正しいかどうかを確認するために、6ヶ月のバッチを実行する必要がある時代遅れのシナリオもあります（私はきっとキュウリを待ち受けることができません。

私の質問は、BDDのプラクティスがこれらのような大きなバッチシナリオに適用された例はありますか？どのようにこれにアプローチしますか？

編集私はコントロールで午前孤立テストシナリオを実行するためにターゲットわけではない理由を説明します（私たちは私の銀行でシステムテストそれを呼び出す）私たちは、試験レベルの一つで分離されたシナリオを行う

とBDDは実際にそのような状況で機能します。しかし、最終的には、エンドツーエンドの環境全体（通常はSIT）を持つテストレベルに到達する必要があります。この環境では、複数のテストシナリオを並列に実行するための基準であり、いずれも環境を完全に制御することはできません。プロジェクトの範囲に応じて、この環境は最大200のアプリケーションを実行できます。したがって、インターネットバンキングなどの顧客チャネルは、コアバンキングシステムでは、利息計算や自動転送などのシナリオが実行されるトランザクションシナリオを実行します。総勘定元帳システムが環境内のすべてのアカウントを統合してバランスをとる会計シナリオもあります。この環境で手動テストを行うには、頻繁に少なくとも30〜50人の人員がトランザクションを実行し、結果を確認する必要があります。

私がしようとしているのは、BDDフレームワークを活用してテストの実行を自動化し、その結果をキャプチャして、環境内で手動でトラッキングする必要がない方法を見つけることです。

Answer 1

シナリオの実行を制御できないかのように聞こえます。

結果を検証する前に数時間待つのは良いことではないことは明らかです。

それは、このシナリオで面白いですバッチの部分だけを抽出することは可能ですか？可能であれば、実行時間は4〜6時間になるとは思っていません。

それが単独で目的の機能を実行することはできません場合は、あなたのシステムのテスト・能力に関する問題を抱えています。これは非常に一般的であり、本当に対処したいことです。テストする唯一の方法は、システム全体を実行するだけであれば、テストを必要とするすべての組み合わせが実行するのが難しく、時には不可能でもあるため、適切に動作していると自信を持って伝えることができません。

残念ながら、迅速な修正を存在していないようです。システムの小さな部分を検証して、迅速かつ確実に検証できる位置にいる必要があります。キュウリや他のツールを使って検証しても、すべてのツールに同じ問題があります。あなたが考えるかもしれません

Answer 2

一つのアプローチは、各バッチ実行の結果を照会報告プロセスを持っているだろう。次に、興味のある結果（つまり、テストの結果）をテスト分析データベースに保存します。

私は、各バッチの実行が一意の識別子を持っていることを前提としています。この識別子は、テスト結果のキーとして使用されます。ここで

はそれがうまくいくかもしれない方法の例です：

• バッチを実行すると（これは午前4時にあると言う）が終了したら、私たちは知っています。 Googleでは、テストアカウントを分析するバッチ実行の完了後（例：午前5時）にレポート作成ジョブを開始するようにスケジュールします。
• レポートジョブでは、勘定Xと勘定Yが表示されます。勘定科目の金額は、バッチ実行の一意の識別子とともにテーブルに記録されます。この情報は、テスト結果データベースに格納されます。
• 別のプロセスでは、テストシナリオとテスト結果が一致します。テストシナリオ29はバッチ実行ZZ20に結び付けられていたので、バッチ実行ZZ20からの分析のためにテスト結果データベースを調べます。
• 朝、テストエンジニアは実行結果をチェックします。テストシナリオ29が失敗したのは、予想された£100.001ではなく、Account Xに£100しかなかったからです。

このセットアップでは、同期、非同期バッチ実行を処理できるようになります。しかし、テストシナリオとテスト結果とのレポート作成やリンクについて多くの自動化を行う必要があるため、構成は難しいでしょう。