PR

 ここまでさまざまなテスト自動化ツールについて解説してきました。今回は連載の最終回となりますので、これまでのまとめをした後で今後のテスト自動化について予想してみたいと思います。

 この連載ではこれまで、テストの作業を軸にして以下のテスト自動化について解説してきました。

  • 静的解析
  • テスト実装・実行(単体テスト/GUIテスト)
  • テスト設計
  • テスト管理

 また前回は、テスト対象を軸にしてスマートフォン向けアプリケーションのテスト自動化のツールや動向について解説しました。

 今回はまず初めに、これまでの連載では詳しく取り上げることができなかったテスト自動化のうち、代表的なものについて簡単にご紹介します。

非機能テストの自動化

 本連載で取り上げたテスト実行の自動化を支援するキャプチャーリプレイツールは、画面に対する入力や操作を行った結果を確認する、いわゆる機能テストの自動化を支援するツールでした。

 一方、このような画面操作のアプリケーションをはじめ、一般的なシステムやソフトウエアに対しては、次のような非機能テストも必要になります。

・性能テスト/負荷テスト
 同時に多くの人がアクセスするなどの負荷をかけたり、処理速度などを測定したりする

・セキュリティテスト
 情報の漏えいや改ざん、システムの不正利用などが起きないかどうか確認する(セキュリティはJIS X 0129(ISO/IEC 9126)では機能性の品質副特性に分類されますが、ここでは非機能として扱います)

・ユーザビリティーテスト/アクセシビリティーテスト
 システムの使い勝手や障がい者に配慮した作りになっているかどうかを確認する

 性能やセキュリティに関しては、静的解析ツールでチェックすることもできますが、ソースコードのレベルでチェックできることには限界があります。したがって、実際にアプリケーションを動かしてテストする必要が出てきます。その場合に、大量の負荷をかけたり、不正なアクセスを疑似的に行ったりといった、人手では困難なテストを自動化するツールがあります。

 また、ユーザビリティーやアクセシビリティーは、特に近年になって重要視されているテストです。人間の感覚に依存する部分が多いため自動化は難しい分野でしたが、HTMLの記述レベルでアクセシビリティーの適合度をチェックするツールや、ユーザーの使用履歴を記録して使い勝手を評価するツールなどが登場しており、今後も注目される領域です。

関連コンポーネントや連携先サブシステムを仮想化

 結合テストやシステムテストでは、テスト対象となるコンポーネントやサブシステム以外に、それらを動作させるための別のコンポーネントや連携先のサブシステムが必要になることがあります。これらのコンポーネントやサブシステムが開発中であったり、実環境で運用中のために使えなかったりといった場合には、テストが止まってしまいます。

 そのため、従来はこれらの代替プログラムとなるスタブやドライバを作ってテストをしていました。ただし、このスタブ作成にも多くの工数がかかります。そこで、スタブ作成を自動化し、テストの周辺系の環境を仮想化するツールが注目を浴びています。米IBMの「Rational Test Workbench」や米Parasoftの「Virtualize」といった製品です。これにより、環境整備のためのテストの待ちをなくした上に、スタブ作成の工数も削減できますので、テストの効率化に大いに役立ちます。