テスト自動化とは? シンプルでわかりやすい入門書

ソフトウェアの世界では、手動と自動の2種類のテストがあります。 発見テストやユーザビリティ テストのようないくつかの種類の手動テストは、非常に貴重なものです。 回帰テストや機能テストのような他の種類のテストも手動で行うことができますが、同じことを何度も何度も繰り返し行うのは、人間にとってかなり無駄な行為です。 4712>

テスト自動化とは、テストを自動的に実行し、テストデータを管理し、結果を活用してソフトウェアの品質を向上させることです。 これは主に品質保証の手段ですが、その活動にはソフトウェア生産チーム全体のコミットメントが必要です。 ビジネスアナリストから開発者、DevOps エンジニアまで、テスト自動化を最大限に活用するには、全員の参加が必要です。

この投稿では、テスト自動化がどのようなものかを大まかに理解することができます。 したがって、テスト自動化の一般的な基準から始めましょう。

自動化の基準

自動化するためには、テストはいくつかの基準を満たす必要があります-さもなければ、節約するよりもコストがかかることになるかもしれません。 結局のところ、自動化の主な目標の 1 つは、時間、労力、およびお金を節約することです。 ここでは、テスト自動化のための一般的な基準をいくつか紹介する。 これらは出発点であることに留意してほしい。

Repeatable

テストは反復可能でなければなりません。 一度しか実行できないテストを自動化する意味はありません。

  • 関数を実行し、結果を測定する。
  • データと環境をクリーンアップする。
  • 最初のステップでは、環境を一貫した状態にすることができるようにします。 言い換えると、既存のユーザーの追加を試みるテストがある場合、テストを実行する前に、ユーザーが存在することを確認する必要があります。 テストが完了したら、環境を基本状態に戻す必要があります。

    Determinant

    関数が決定式である場合、同じ入力で実行するたびに結果が同じであることを意味します。 同じことが、自動化できるテストにも当てはまります。 たとえば、足し算の関数をテストしたいとします。 1 + 1 = 2 であることと、394.19 + 5.81 = 400.00 であることは分かっています。 一方、ソフトウェアでは、非常に多くの変数入力を使用するため、時間が経過しても同じ結果になることは困難です。 一部の変数はランダムである可能性さえあり、特定の結果を決定することが困難になる場合があります。 ソフトウェア設計では、テスト ハーネスによるテスト入力を可能にすることで、これを補うことができます。

    アプリケーションの他の機能は、たとえば、新しいユーザーの作成はユーザー数を増加させるかもしれません。 少なくとも、ユーザーを追加するとき、ユーザーの数は 1 つだけ増加するはずであることが分かっています。 しかし、テストを並行して実行すると、予期せぬ結果を引き起こす可能性があります。 分離することで、このような誤検出を防ぐことができます。

    無個性

    意見の事柄を自動化することはできません。 これは、ユーザビリティ テスト、ベータ テストなどが本当に輝くところです。 ユーザーからのフィードバックは重要ですが、自動化することはできません……すみません!

    自動化テストの種類

    非常に多くの種類のテストがあり、その多くが自動化できますが、1 つの記事にすべてを掲載することは実際不可能です。 しかし、ここでは、良い出発点を与えるのに十分なものを紹介します。

    コード解析

    静的解析や動的解析など、実際には多くの異なるタイプのコード解析ツールがあります。 これらのテストの中には、セキュリティ上の欠陥を探すものもあれば、スタイルやフォームをチェックするものもあります。 これらのテストは、開発者がコードをチェックインするときに実行されます。 ルールを構成し、ツールを最新の状態に保つこと以外には、これらの自動テストで行うべきテスト記述はあまりありません。 単体テストは、単一の機能、または操作の単位を分離してテストするように設計されています。 これらは通常、ビルド サーバー上で実行されます。 これらのテストは、データベース、外部 API、またはファイル ストレージに依存しません。 これらのテストは高速である必要があり、外部の依存関係ではなくコードのみをテストするように設計されています。

    Integration Tests

    Integration Test は自動化に関して言えば、異なる種類の動物です。 統合テスト (エンドツーエンド テストと呼ばれることもあります) は外部の依存関係と相互作用する必要があるため、セットアップがより複雑になります。 たとえば、ベンダーからの Web サービスに依存する物流アプリがある場合、ベンダーのサービスがダウンすると、テストは予期せず失敗する可能性があります。 これは、アプリが壊れていることを意味するのでしょうか? しかし、各シナリオを明示的に作成するために、テスト環境全体を十分に制御する必要があります。 テスト シナリオの結果を決定するために外部要因に依存してはなりません。

    Automated Acceptance Tests

    今日、自動化された受け入れテスト (AAT) を使用するプラクティスがいくつかありますが、基本的に同じことを行っています。 行動駆動開発 (BDD) と自動化された受け入れテスト駆動開発 (AATDD) は似ています。 どちらも、機能が開発される前に受け入れテストを作成するという同じプラクティスに従います。

    最終的に、自動受け入れテストは、機能が合意されたものを提供するかどうかを判断するために実行されます。 したがって、開発者、ビジネス、および QA がこれらのテストを一緒に作成することは非常に重要です。 これらは、将来の回帰テストとして機能し、機能が期待されるものを保持していることを確認します。

    Regression Tests

    AAT がない場合、事後的に回帰テストを書かなければなりません。 どちらも機能テストの一形態ですが、どのように書くか、いつ書くか、そして、誰が書くかは、大きく異なっています。 AATのように、機能テストはコードやUIによってAPIを動かすことができる。 GUI を使用してこれらのテストを記述するツールがあります。

    Performance Tests

    多くの種類のパフォーマンス テストが存在しますが、それらはすべてアプリケーションのパフォーマンスのいくつかの側面をテストします。 極端な圧力に耐えられるか? 高熱に耐えられるかどうかをテストしているのでしょうか。 私たちが追い求めているのは、負荷のかかった状態での単純な応答時間でしょうか。 スケーラビリティはどうでしょうか。

    これらのテストでは、大量のユーザーのエミュレーションが必要になることがあります。 この場合、そのような偉業を実行できる環境を持つことが重要です。 この種のテストを支援するためにクラウドのリソースが利用できますが、オンプレミスのリソースも使用できます。 これは、通常、デプロイメントまたはメンテナンス ウィンドウの後に実行される基本的なテストです。 スモーク テストの目的は、すべてのサービスおよび依存関係が稼働していることを確認することです。 スモークテストは全面的な機能テストを意味するものではありません。 4712>

    一般的なテスト自動化プロセス

    さて、自動化の基準と、物事を理解するのに十分な自動テストの種類を見てきましたが、ここでは、テスト自動化の一般的なプロセスを説明します。 テスト自動化には、準備、実行、結果の報告の 3 つの主要なステップがあります。

    準備

    最初に、状態、テスト データ、およびテストが行われる環境を準備する必要があります。 これまで見てきたように、ほとんどのテストは、アクションが行われる前に環境が特定の状態であることを必要とします。 典型的なシナリオでは、これには何らかの設定が必要です。 データを操作する必要があるか、アプリケーションを特定の状態にする必要があるか、またはその両方です!

    Take Action

    状態または環境があらかじめ定義された状態になったら、今度はアクションを実行する番です!

    Take Action

    状態または環境が定義済みの状態になったら、今度はアクションを実行します。 テスト ドライバは、アプリケーションの API やユーザー インターフェイスを呼び出したり、コードを直接実行したりして、テストを実行します。 テスト ドライバはテストを「駆動」する責任がありますが、テスト管理システムは結果の報告を含むすべてを調整する責任を負います。 これらの結果は、多くの異なるフォーマットで提供され、作業追跡システムで問題チケットやバグを作成することもあります。 しかし、基本的な結果は、合格または不合格です。 通常、各テスト シナリオには、合格または不合格を示す緑または赤のインジケータがあります。

    時には、テストが決定的でない、または何らかの理由で実行されないことがあります。 このような場合、自動化システムには、開発者がレビューできるように、出力の完全なログが記録されます。 このログは、開発者が問題を追跡するのに役立ちます。 理想的には、修正プログラムを配置したら、シナリオを再生できるようにします。 しかし、すべてのテストを自動化できるわけではありません。 間違いなく投資が必要です。 非常に多くの種類のテストがあるため、適切な組み合わせを得ることが重要です。 テストピラミッドは、これを正しく行うための簡単な経験則です。 ほとんどのテストはユニット テストであるべきで、次にサービス テスト、そして UI テストと続きます。

    テスト自動化システムは、テスト データの管理、テストの実行、および結果の追跡など、テストに関する事柄を調整します。 テスト自動化は、自動化されるべき同じ手動テストの繰り返しの負担に圧倒されつつあるチームのための次のステップである。

    著者略歴。 この投稿は Phil Vuollet 氏によって書かれました。 Phil は、効率性と再現性を向上させるために、ソフトウェアを使用してプロセスを自動化します。 彼は、テクノロジーとビジネスに関連するトピックについて執筆し、時折同じトピックについて講演を行い、子供たちとサッカーやボードゲームを楽しむ家庭人です。

    コメントを残す

    メールアドレスが公開されることはありません。