すべてのF5サイトを検索

検索結果の提案

ブログ

テストツールプロファイル: Threat Stack が ThoughtWorks Gauge を使用する理由

2022年3月16日更新

Threat Stack は現在、 F5 Distributed Cloud App Infrastructure Protection (AIP) です。今すぐチームで Distributed Cloud AIP を使い始めましょう。

Threat Stack では、Threat Stack Cloud Security Platform® で期待どおりに動作しているかどうかを確認するために、毎日多数のテストが行われています。ソフトウェアエンジニアの単体テストと統合テストを補完するために、テストエンジニアリングチームは、自動化された回帰テストスイートの一部として次のものを作成しました。

Capybara で記述されたブラウザベースのテストでは、有効なユーザーのみがダッシュボードにログインし、サイトをナビゲートし、AWS フリートによって作成されたイベントの証跡を表示し、これらのイベントに基づいてルールを作成および更新して、セキュリティチームがトリアージできるアラートを生成できることを、Web ベースのユーザーインターフェイスを通じて検証します。 150以上のテスト。

API テストでは、 Net/HTTP Ruby gem を使用してThreat Stack APIと対話し、過去 30 日間の監査ログを取得できること、アラートの重大度とタイプ別にアラートの個別およびグループを一覧表示できること、Threat Stack によって監視および調査されているすべての仮想環境を一覧表示できること、HIPAA、ISO 27001、MPAA、PCI、および SOC 2 の基本コンプライアンスルールセットを表示できることを確認します。テストでは、これらの事前構成済みルールとカスタムルールによって生成されたアラートを、Threat Stack API を通じて表示、抑制、または解除できることも確認します。 130以上のテスト。

約 300 個の受け入れテストを追跡するにはどうすればよいでしょうか? Threat Stack のテストエンジニアは、無料の軽量なクロスプラットフォームテスト自動化フレームワークであるThoughtWorks Gaugeを使用してテストを設定しました。

ゲージテストには主に 2 つの部分があります。

平易な言葉で書かれたテスト仕様は、テストを実行する方法に関する手順を箇条書きで段階的に示したものです。仕様は手動テスト計画のように明確かつ簡潔で、他の人が理解できるほど十分な説明が含まれている必要があります。
step_implementationフォルダーには、テストを実行するコードが含まれており、各ステップは、仕様内で呼び出されるたびに、どこででも再利用できるコードブロックにラップされます。

Gauge でテスト計画をテストを実行するコードから分離することで、テストの可読性と保守性が向上し、テスト間でテスト手順を共有できるようになります。

この投稿の残りの部分では、Gauge の気に入っている 10 の主要な機能に焦点を当てます。

スナップショット:

Webサイト： Gauge.org 、 Github.com/getgauge
発売日： 2018年7月
サポートされている言語: Java、C#、Ruby、Javascript、Go、Python
サポートされているオペレーティングシステム: Linux、macOS、Windows
IDE プラグ: Visual Studio、Visual Studio コード、IntelliJ

1. セットアップの容易さ

ゲージの取り付けは非常に簡単です。 Gauge のインストールページにアクセスし、オペレーティングシステム、プログラミング言語、IDE を選択すると、すべてをインストールする方法に関するカスタマイズされた手順が表示されます。ソースコードからインストールしたくない場合は、MacOS のインストールは HomeBrew で、Linux のインストールは APT_GET で、Windows のインストールは Windows インストーラーで行うことができます。

すべてがダウンロードされたら、コマンドラインで「gauge install ruby」と入力して、Ruby などのプログラミング言語の言語ランナーをインストールできます。

2. サンプルプロジェクトが含まれています

新しいテスト自動化フレームワークでは、どのファイルをどのフォルダーに配置する必要があるか、またテストをどのようにセットアップして開始するかを判断することが困難になる可能性があります。

Gauge は、フレームワークの新規ユーザーが試すことができるいくつかのテストを含むサンプルプロジェクトを組み込むことで、この混乱を回避します。「Gauge」、「Mingle」、「Snap」などの特定の単語があるとします。単語内の母音の数を数え、予想される数と実際の数が一致することを確認するテストをどのように設計すればよいでしょうか?

サンプルテストはデータ駆動型で、入力は「単語」と予想される「母音数」の 2 つの列を持つデータテーブルにキャプチャされます。

サンプルプロジェクトは、インストール後すぐに、コマンドラインからgauge run specを使用して実行できます。

サンプル出力、コマンドライン:

3. テストとテストの実施方法の分離

一連の自動テスト内で実際に何がテストされているのか把握しようとするのは、特にテストの目的、テストが実行する手順、または各テスト手順を実行するコードを解読する前に多数のコードブロックを調べる必要がある場合は、イライラする作業になる可能性があります。

Gauge は、テストプランとテストプランの実行方法を分離することで、この混乱を回避します。 Gauge は、2004 年に Josh Gruber と Aaron Swartz によって作成されたテキスト書式設定言語であるMarkdownファイルで手順を整理します。テスト手順は仕様ファイルに箇条書きとして保存され、 step_implementationsによって実行できます。

仕様: 仕様は、単に製品の機能の仕様を列挙するものではありません。これらは、テストコードを整理し、HTML または XML レポートを設定するための方法です。 *.specファイル内の各要素は、Markdown 内の要素に対応します。仕様は「ビジネスレイヤーのテストケース」であり、機能のドキュメントとしても機能します。これらはビジネス言語で書かれています。通常、仕様または仕様書は、テスト対象のapplicationの特定の機能を説明します」と、 Gauge の公式ドキュメントには記載されています。

各仕様には、実行されるさまざまなテストシナリオを説明するヘッダーがあり、関連するテストシナリオはサブヘッダーとして説明されます。これらのヘッダーとサブヘッダーは、ログを表示して何が成功し何が失敗したかを確認するときに、HTML レポートに含まれます。

ステップの定義: 仕様に記載されている各ステップは、仕様の平易な言語と実行される Java、C#、Javascript、Python、または Ruby コードを組み合わせた概念または再利用可能なステップ定義のいずれかに対応しています。

テストを実行するコードからテストを分離することで、他のテスター、ビジネスアナリスト、製品所有者は、コードの詳細を調べなくても、仕様ファイルを見てテストがどのように構築されたかを明確に把握できるようになります。

4. 仕様は読みやすいようにフォーマットされています

仕様は非常に読みやすいように設定されています。

ヘッダーの先頭にはハッシュタグ (“#”) が付けられ、作成者はここでシナリオで何を行うかを説明できます。
個々のテストシナリオは、二重ハッシュタグ (“##”) で示されるサブヘッダーとしてリストされます。
テスト対象のシナリオを実行するテスト手順の前には、箇条書きのアスタリスク（「*」）が付きます。

仕様ファイルの例が必要ですか? 新しい Gauge プロジェクトを初期化するときに Gauge がインストールするデモプロジェクトの仕様は次のとおりです。

# 仕様見出し
これは実行可能な仕様ファイルです。 このファイルはマークダウン構文に従います。このファイル内のすべての見出しはシナリオを示します。 箇条書きの各ポイントはステップを表します。
* 英語の母音は「aeiou」です。
## 単語 1 つあたりの母音の数
* 「gauge」という単語には「3」個の母音があります。
## 単語 2 つあたりの母音の数
これは、この仕様の 2 番目のシナリオです。 これはテーブルを使用する手順です。
* ほとんどすべての単語に母音があります
|単語 |母音数|
|------|------------|
|ゲージ |3 |
|ミングル |2 |
|スナップ |1 |
|GoCD |1 |

この仕様内の各箇条書きは、step_implementations フォルダーにリストされているテストステップに対応しています。

別の例が必要ですか? specsフォルダーに、サイトにログインするlogin.specというテストがあるとします。

# ログイン テスト
## 有効なユーザーがサイトにログインできることを確認します
* ログイン: ユーザー名を入力してください: “info@threatstack.com”
* ログイン: パスワードを入力してください: 「1234」
* ログイン: [サインイン] を選択

step_implementationsフォルダーに配置された各ステップは、テストによって自動的に検索され、実行されます。

login_spec.rbステップ 'LOGIN: ユーザー名を入力してください: ' do | username | fill_in(EMAIL_TEXTBOX, with: username) end

同じ一連の手順を何度も繰り返し実行していると感じますか? これらの 3 つのログイン手順を、コンセプトファイルのLogin.cptに配置できます。

login.cpt # としてログインし、* LOGIN: ユーザー名を入力してください: * ログイン: パスワードを入力してください: * ログイン: [サインイン]を選択します

他のテストにログインコンポーネントがある場合は、3 つのステップすべてをコピーして貼り付ける代わりに、テストに 1 行だけ挿入できます。 「info@threatstack.com」と「1234」としてログイン

5. 優れたドキュメントとサポート

新しい自動化フレームワークを学習するのは混乱を招く可能性があります。ドキュメントを読むだけでは不十分な場合があります。 Gauge.org の詳細なドキュメントを読んでも答えられない質問はありますか? 開発者は、 StackOverflow 、 Google グループ、 Gitter Chatで非常に反応が良いです。

6. テスト仕様に基づいて作成された HTML レポート

これまで説明したように、テスト仕様はMarkdownで記述されます。仕様に記載されているこれらのテストは、テスト対象のソフトウェア製品がどのように動作するかに関する真のドキュメントとして活用できます。 Markdown で記述されているため、仕様を使用して読みやすいHTML レポートを作成できます。

デモプロジェクトの HTML レポートを見て、単語内の母音の数を数えてみましょう。

HTML レポートには次の内容が含まれていることがわかります。

テストが実行された日時と実行にかかった時間
実行された仕様とシナリオの数
合格した仕様とシナリオと不合格になった仕様とシナリオの数
実行されたステップ。成功したステップは緑色で表示され、失敗したステップは赤色で表示されます。レポートにはエラーメッセージが含まれます。

7. ゲージサプライ実行フック

優れた自動化フレームワークには、テストの前提条件を設定する方法と、テストが完了した後に実行されるティアダウンメソッドが含まれています。

一例として、ブラウザテストに重点を置いた自動化スイートが挙げられます。この自動化スイートには、テストスイートの開始時にブラウザを初期化するセットアップメソッドと、テストの完了時にブラウザを閉じるティアダウンメソッドが含まれます。

Gauge は、自動化テストスイート内の各スイート、仕様、シナリオ、またはステップの前後に実行できる実行フックを提供します。

実行コードを使用することで、Gauge は、すべてのスイート、仕様、シナリオ、またはステップの前に実行する必要があるコードの重複を削除します。

8. コマンドライン機能

Gauge には、IDE とコマンドラインの両方で「ファーストクラスのリファクタリングサポート」と呼ばれる機能があります。たとえば、テストの文言を継続的に調整して、テストが実際に何を実行しているかがより明確になるようにしたい場合は、コマンドラインで次のように入力します。

$ ゲージ --refactor "古いステップ名" "新しいステップ名"

Gauge のコマンドラインツールの詳細については、 manpage.gauge.org を参照してください。

9. テストはデータ駆動型にできる

テストはデータ駆動型としてドラフトされるように設定できるため、単にテーマのバリエーションであるテストに、使用するテストパラメーターのテーブルを提供できます。

API エンドポイントにアクセスしてテストする必要がある一連の Web サービスがあるとします。 Web サービス名、スキーム、ポートを指定して、HTTP 応答が200 OKになることを確認する必要があります。

各テストは互いに類似しているため、データを読みやすい表にフォーマットできます。

webservice_test.スペック

各行の情報がテストステップに入力され、対応するステップ実装によって実行されるため、作成者は作業の重複を回避できます。

10. データはオンザフライで保存可能

場合によっては、テストステップ間でデータを共有し、後で使用するために保存して保管する必要があります。上記の API テストと同様に、エンドポイントにアクセスして応答を受信したら、それが正しい JSON スキーマを使用した有効な形式であることを確認するテスト手順、またはネガティブテストの実行時に適切なエラーメッセージがリストされていることを確認するテスト手順があります。

Gauge は次の 3 種類のデータストアを使用します。 ScenarioStore、SpecStore、および SuiteStore は、シナリオ、仕様、またはテストスイート全体のライフサイクルのキー/値のペアとしてデータを保存します。

例：ステップ実装セクションでは、次のように要素 ID を追加できます。

// 値の追加
scenario_store = DataStoreFactory.scenario_datastore;
scenario_store.put("element-id", "455678");
// 値の取得
element_id = scene_store.get("element-id");

まとめ. . . .

冒頭で述べたように、Threat Stack で毎日実行しているような大量のテストを実行する場合、堅牢かつ俊敏で、特定のテストニーズに対応できる機能と能力を備え、テスト担当者の適切な労力と入力で、妥当な時間枠内で徹底的にテストできる使いやすさと自動化機能を備えた、クロスプラットフォームのテスト自動化フレームワークが必要です。

乞うご期待：今後の記事では、Capybara など、Threat Stack で使用している他のテストツールについても取り上げる予定です。