私のIT（興味深いテスト）セクションでは、テストへのさまざまな興味深いアプローチと、エラーを見つけるプロセスを刺激的にする便利なツールについてお話します。
今日は以下についてお話します：
- BFT-ビジネスフローテスト、それは何ですか？
- 簡単な例でそれを使用する方法を紹介します。
- このアプローチの利点は何ですか？
- どこで適用できますか
- そして次に何が起こるか
ストリームテスト（BFT-BusinessFlowTesting）
BFTは、特定のケースの観点からではなく、各ポイントでのシステムの動作の観点から製品を調べるテストアプローチです。このアプローチは、データドリブンテストやビヘイビアドリブンテストなどの概念を組み合わせたもので、データ移動グラフで詳しく説明されているビジネスモデルに適用されます。
個々のテストケースをテストするのではなく、システムのパフォーマンスを確認します。テストケースは自分で取得します
比Fig的に言えば、あなたは以下を持っています：
- 多様な入力ビジネスデータのセット
- 検証が必要なビジネスエンティティの状態をテストするために重要に分割されたシステム
- 状態遷移規則
テストケースがありません。 テストケースは、入力データ自体に基づいて生成されます。
テストケースに正しく名前を付ける方法についてこれ以上議論しません。 テストケースの名前は、テストケースとそれらが進むパスを定義する入力データのセットです。 名前は長いですが、このテストを完全に説明しています。 それに加えて、あなたはそれに一秒を費やすことはありません-それはそれ自体で作成されます。
BFTフレームワーク
BFTフレームワークはどのように配置され、自分で作成するのですか？ 簡単な例を見てみましょう。アプリケーションが商品を販売する店であるとしましょう。 主な受入テストは、ユーザーがこの製品をどのように購入し、次に何が起こるかについてのテストです。
事業体：
- ユーザー（名前、支払いの種類（銀行カード、現金、電子マネーなど）、割引カード、購入履歴、プロモーションコードなど）
- 製品（名前、番号、初期価格、最終価格、数量、参加する株式など）
- ショッピングカート（製品、バスケット価格、最終購入価格、購入状況のリスト）
注文状況：
- 形成（作成）
- 承認済み（登録済み）
- 有料（有料）
- 配信済み
- 配信済み
- 配送拒否（Delivering Rejected）
- アーカイブ内（アーカイブ内）
製品移動グラフ
ビジネスで提供される可能性が最も高いチャートがあります。 そうでなければ、あなたは自分でそれを作ることができます、それはそれ自体で多くの利益をもたらします。
この図をテストするために、テスターは各状態を説明します。
状態を説明するには、指定する必要があります。
- チェック この状態で確認するもの
- 遷移 この状態からどこにどのように行くか
各グラフはこのグラフの線形パスであり、入力データによって特徴付けられます。
入力データにはいくつかのタイプがあります。
- ビジネスデータ（ユーザー、製品、バスケットなど）
- 状態チェックに影響
- グラフ内のパスに影響を与える可能性があります（たとえば、登録ユーザーが識別をスキップし、すぐに有料に移行するなど）
- コントロールデータ（たとえば、支払い後に払い戻しを行うか、アーカイブから注文を返す）
テストを書く
基本的な簡単なテスト
ビジネスグラフモデルがあります。 このグラフでは、各状態で何をチェックする必要があるか、次にどこに行くかを、既にプログラミング言語で記述したテストコードを作成します。結論：テストグラフについて説明しました（最初のグラフを完全に説明する必要はありません。たとえば、最初は肯定的なシナリオのみを説明し、必要に応じて他のすべての状態と遷移を追加できます）。
通常、最初のテストはメインのポジティブテストであり、ビジネスストリームの最初から最後までエラーなしで実行されます。
陽性検査の入力データを作成します。
テスト自体は次のようになります。
BusinessGraphは入力データCorrectSimpleDataを使用して、SimpleScenarioを取得する出力グラフに線形スクリプトパス（デフォルトのDefaultControllData）を構築します。var SimpleScenario = BusinessGraph.GetScenario(CorrectSimpleData, DefaultControllData);BFTFramework.Run(SimpleScenario, CorrectSimpleData);
BFTFrameworkは、CorrectSimpleData入力を使用してこのスクリプトを実行します。
その他のテスト
ここで、多くの異なる肯定的なデータをテストする場合は、CorrectOtherDataの他のセットを単純に転送します。たとえば、否定的なテスト（購入の払い戻しなど）を追加する必要がある場合：
- 新しい拒否状態をBusinessGraphに追加します（この状態に切り替えるときに実行する必要があるチェック、および必要に応じてそこから可能なパス）
- 他の状態からこの新しい状態に移行パスを追加します（この場合、これは配信-拒否された配信の矢印です）
- 一連の誤ったデータをテストに渡しますDeliveringRejectedData
いずれかのステップで新しいチェックを行うことにした場合、どのテストでそれが発生するかを考える必要はありません。 これを対応する状態に追加するだけで、通過するすべてのテストが調整されます。
製品が通過する必要がある新しい状態が表示されます。グラフに追加するだけで、それに影響するすべてのテストが新しいパスにリダイレクトされます。
必要な場合にのみ、テストコードをローカルで編集します。
合計：
- テストコードは、データ、「テストアプリケーションインターフェイス」（グラフとチェックの状態）、およびデータ移動パス（トランジショングラフの弧）に分離されます。
- 新しいテストは毎回ゼロから書く必要はありません。 本当に新しく追加されたもののみを追加し、既に記述されたものを最大限に再利用し、コードの重複を回避します
- すべてのテストはグラフ内を移動するため、メトリックを使用して機能をテストでカバーできます。 たとえば、「各パスが少なくとも1回移動された」、「各状態が少なくとも1回訪問された」、またはより複雑なもの（グラフで少なくとも2回巡回するなど）。
- 特定の重要なチェックのレベルで、システムの追加の包括的なドキュメントを取得します。
多くの場合、プロジェクトの最初にビジネスグラフがあっても、新しいUserStoryを追加すると、その関連性が失われます。 テストは常に関連しています。 さらに、ビジネスの説明には、これらの状態で特に重要なものの理解が含まれていません。または、この情報はさまざまなUserStoriesに散在しています。 BFTグラフを見た後は、このステップで何がチェックされ、どこからどのように進むことができるかをいつでも言うことができます - BFTテストは、回路に非常に簡単に収まらない、または非常に乱雑な他のテストと組み合わせることができます。 何を何に使用するかを考えてください。
- テストの任意の時点でBFTフレームワークを正しく記述することで、シナリオ全体（状態と遷移）と現在のステップを確認できます。 このスクリプトは、エラーが発生した場合に簡単にログに記録するか、開発者が「このSimpleTestは何をしますか？」と尋ねたときに開発者に渡すことができます。
- シナリオ全体を知っているので、テスターに追加コストをかけることなく、各新しい状態への移行を自動的にログに記録できます（通常、このような場合、ログは時間不足のために単に無視されます）
- グラフ内を移動するとき、テストに関するすべての情報を含むテストコンテキストを使用します。
- すべての入力
- 現在のシナリオ
- 現在のステップ
- テスト中に保存した追加の変数
- テストが失敗した場合、このすべてのデータを簡単にログに出力するか、デバッグで新しいデータを使用してテストを起動せずに開発者に渡すことができます
応用分野
何かを使用する前に、このツールが適切かどうかを考えてください。このアプローチは、事業体と事業体が住んでいる条件を区別しやすいプロジェクトに適用できます。
次のいずれかです。
- あらゆる種類のお店。 実物、コンテンツ、サービスなどの販売
- 配送サービス
- 銀行プロジェクト、支払い、振替、およびトランザクションを伴うその他のプロジェクト
- インターフェイステスト（UI）。 ユーザーをビジネスエンティティとして、ページを状態として、状態間の遷移の形でユーザーアクションを表すことができます。
次は？
次の記事：
- 入力データセットの生成、交差点と例外の構築について説明し、重要なテストのみを作成します
- メトリクスの詳細と、BFTを使用してテストプロセスを構築する方法について説明します
- 状態、チェック、および遷移の説明については、「擬似コード」の例を使用して詳細に説明します。
- BFTと初めて会ったときに生じる可能性のある落とし穴と問題について説明します
- コメントで生じる問題を強調するつもりです。