誤解されることが多い「テスト自動化」の範囲について

1 概要

近年、「テスト自動化」と言う用語が話題になることが多いです。
しかし、特に初学者の方が「テスト自動化」と表現される場合、「単体テストの自動化」のみをターゲットにされている方が多いように感じています。

テストの工程や種類（タイプ）には単体テスト以外にも様々なものがあり、それらの種類を押さえたうえで「どこまでのテストが必要」で、「どこまでが自動化できているか」を把握されることが重要と考え、まとめてみました。

2 テスト工程について

テストの工程には、以下のようなものがあります。
なお、ここでの工程はプロジェクトごとに呼び方が違いますので、一例とお考え下さい。

① 単体テスト

単体テストは、「ユニットテスト」、「コンポーネントテスト」、「モジュールテスト」、「プログラムテスト」などとも表現されます。

テスト対象としては「単体のプログラム」となり、メソッドや関数などの単位でのテストを行います。

単体テストの特徴

• モジュール単位でのテスト
• ローカル環境で実施することが多い
• 開発者が実施することが多い

② 結合テスト

結合テストは、「統合テスト」、「インテグレーション」などとも表現されます。

具体的には、以下の2つの観点におけるテストとなることが多いです。

1. 単体テストで品質担保したモジュールを結合した場合のテスト
2. ローカル環境で実施している単体テスト後のモジュールを、実際のOS、ハードウェア、データベースに近い構成の「結合テスト環境」にてテストする。

Webシステムのような画面をベースにしている機能であれば、

• 入力画面から入力した情報がデータベースに正しく登録される
• データベースの内容が正しく照会画面に表示される

と言うような、複数モジュール間の流れを確認するテストになります。

結合テストの特徴

• モジュールを結合したテストとなる
• 実際の環境に近い構成の「テスト環境」にてテストすることが多い

③ システムテスト

結合テストが、「モジュール間」の流れを確認するものであることに対して、システムテストは「システムの要件を満たしているか」を確認するテストです。

例えば、以下のような観点でテストをします。

• 複数の機能を組み合わせたときに、システムの要件を満たしているか。
• パフォーマンスやセキュリティなどの「非機能要件」を満たしているか（後程説明します）
• 外部システムとの連携が正しく行われるか

システムテストの特徴

• システムとしての要件を満たしているかを確認するテスト
• 結合テストと同じく、実際の環境に近い構成の「テスト環境」にてテストすることが多い

④ その他のテスト

それ以外にも、以下のようなテストがありますが、どちらかと言うと開発側ではなくユーザ側のテストとなります。
詳細は割愛致します。

• 受け入れテスト
  • システムの開発を委託している場合に、クライアント側がシステムを受け入れる際の動作を確認するテストです
• オペレーションテスト
  • ユーザが実際の運用に合わせてシステムを使用してみるテストです。
• ベータテスト
  • よく「ベータ版」と言う言葉を聞くと思いますが、一般公開するパッケージやWebシステムなどを、仮の状態（ベータ版）であることを伝えた上で先に一般ユーザに使ってもらい、フィードバックを受けて改善して行くものです。

3 テストの種類（タイプ）

テストについて、工程の他に「テストの種類（タイプ）」による分類もあります。

テストタイプを説明する前に、まずシステムの要件として「機能要件」と「非機能要件」に分けられると言うことをご説明します。

① 機能要件

機能要件は、その名の通りシステムの「機能」に対する要件です。
どのような画面があり、何を登録して、どのような結果になるのか、と言った、システムが「どのように動作するのか」を要件とします。

機能要件に該当するテストを「機能テスト」と呼びます。

すべてのテスト工程にて、「機能テスト」は登場します。

② 非機能要件

機能要件とは逆に、「システムの機能に該当しない要件」を非機能要件と呼びます。
目に見える要件が「機能要件」、目に見えない要件が「非機能要件」であるとお考えいただいても差し支えないかと思います。

「非機能要件」に該当するテストを「非機能テスト」と呼びます。

すべての工程で非機能テストが登場するわけではなく、ある程度システムの動作が担保されている「システムテスト」工程で実施することが多いです。
ただ、クリティカルな問題が懸念されている場合（例えば、開発当初から動作速度に懸念がある場合など）や、システムテストが本番リリース直前であるなどスケジュール上の理由がある場合は、前工程にて実施する場合も多いです。
プロジェクトによって方法は異なります。

非機能テストとしては以下のようなものが代表的ですが、もちろんシステムの特性によってはそれ以外の非機能要件もありえます。

1) 性能テスト

システムの性能に関するテストです。
もう少し細分化して定義することも多いのですが、ここでは「性能テスト」にまとめています。

• ボタンをクリックしてから画面が表示されるまで●●秒以内で完了するか
• データ件数●●件を処理した場合、正常動作するか
• 想定件数以上のデータが登録された場合、システム正常終了 or 速度を制限して正常動作するか

特に想定以上の負荷がかかった場合のテストは重要です。
必ずしも正常動作することだけが期待値ではなく、時には「正常に機能を停止する」であったり、「速度を制限して続行する」など、限界突破時の要件に従います。
例として、「想定外の予約数があったためシステムが異常動作して個人情報流出」のような事態を避けることが重要ですね。

2) ユーザ操作性テスト

ユーザの操作性に関するテストです。
この部分はどうしても自動化できない部分になると思います。

また、個人の主観などによっても変わってくるところです。

例えば、ある程度システムの動作が確認された段階（システムテストなど）で、ユーザや、他チームメンバーなどの第三者に実際に操作してもらって感想を聞くと言うことをよく行います。

3) セキュリティテスト

セキュリティに関する要件を確認します。
数年前までは非機能要件に入らないこともありましたが、近年では必ず必要になる要件になると思います。

セキュリティツールを使用して抜け穴のあるロジックや機能がないかを確認したり、外部業者に委託してセキュリティ診断を受けるなどの方法があります。

セキュリティテストについては、「機能要件」として定義されるプロジェクトもあるようです。
したがって、必ずしも非機能要件になるとは限りませんが、少なくとも外部公開されるシステムに関して、「セキュリティテストを全く行わない」と言うことはないと思います。

5 どこまで自動化するのか

以上のように、テストの種類には様々なものがあります。

通常、「テストを書く」と言う表現をされる場合は、JUnit(Java)、RSpec(Ruby)、PHPUnit(PHP)、unittest(Python）などのツールを使ったロジック単位のテストを想定される方が多いと思います。

これらを導入している場合に「テスト自動化」と表現される方が多いのですが、ここで自動化できている内容は「単体テスト」の「機能要件」のみになります。
（例えば、CircleCIにてRSpecのテストを自動実行できている状態を「テスト自動化している」と言うのは、少し認識が違っていると思っています）

結合テスト、システムテストに関しては、JUnitやRSpecなどのツールでは自動化しきれないです。
（実際の画面操作などを行うことができない）

また、非機能要件に挙げた性能テストとしても不十分ですし、操作性についても確認できません。
セキュリティテストについてはおそらく他のツールが必要になります。

もちろん、すべてを自動化することだけが正解ではありません。

それらを踏まえたうえで、「テスト自動化」を表現するのであれば

• どこまでのテストがシステムとして必要なのかを定義する
• その中で、どの部分を自動化するのかを決める
• 自動化できない部分は、どのタイミングで確認するのかを決める

と言うように、現状を正しく認識することが重要です。

そのほかのテストツール

単体テスト以外にも、各テスト工程やテスト種類ごとに使用できるテストツールが存在します。
代表的なもののみになりますが、いくつか紹介しておきます。

① 結合テストツール：Selenium Web Driver

結合テストツールとして、主に画面操作を自動化する「Selenium Web Driver」が有名かと思います。

簡単なスクリプトを書くことで、画面操作を自動化することができます。

そのため、「手動で」実施していた結合テストやシステムテストの画面操作を自動化することができます。

また、画面表示内容が期待値と一致しているかどうかも確認できるため、検証も含めて自動化できます。

Seleniumについてはこちらの書籍が参考になると思います。

Selenium実践入門 ――自動化による継続的なブラウザテスト WEB+DB PRESS plus 伊藤 望
https://www.amazon.co.jp/dp/B07JHNFB2F/ref=cm_sw_r_tw_dp_U_x_LZ7VDb9M7EZYZ

② 負荷テストツール：Apache JMeter

Apache JMeterは、性能テストを行うためにシステムに負荷をかけることができるツールになります。

管理画面の操作で細かい部分まで負荷をかけることができ、無料で使用できるため性能テストを試してみたい場合に使ってみるのも良いかと思います。

③ セキュリティテストツール

セキュリティテストツールにはいろいろありますので、こちらのサイトを紹介しておきます。

よく聞くのは「OWASP ZAP」あたりかと思います。

④ 操作性テスト：人間

操作性テストを行う上で重要なのは「人間の目」です。
このテストだけは自動化することができません。

結合テスト、システムテスト、性能やセキュリティのテストをすべてツールで自動化できたとしても、必ず一度は人の手で操作することが重要です。

8 まとめ

「テスト自動化」について色々と記載しました。

もちろん、すべてのテスト工程、テスト種類を自動化することだけが正解ではありませんが、

• どこまでのテストがシステムとして必要なのかを定義する
• その中で、どの部分を自動化するのかを決める
• 自動化できない部分は、どのタイミングで確認するのかを決める

と言う点が重要かと思います。

最後までご覧いただきありがとうございます。