『システムテスト自動化 標準ガイド』の第3章 ～ テストを自動化するスクリプティング技法の最新事情と取り組みの事例

はじめに

　『システムテスト自動化 標準ガイド』（通称『ギア本』）第1部の監訳と第3章の翻訳を担当した、テスト自動化研究会の鈴木一裕と申します。2015年末は本業と翻訳プロジェクトのはざまでもがいておりましたが、無事出版され、母親のまなざしで同書の行く末を見守っております。

　私は元々、株式会社 日立製作所で、主にエンタープライズ系システムの検査を生業としていましたが、昨年秋より所属が変わり、現在は組み込みソフトウェアの評価の仕事をしております。新しい職場ではテストの自動化業務も担当することになり、あらためてギア本を拾い読みしているところです。

　本稿では、私が翻訳を担当したギア本の第3章「スクリプティングの技法」が、現在までにどのように変わってきているかについて述べたいと思います。

テストを自動実行するための5つのスクリプティング技法

　第3章では、テストを自動実行するためのスクリプティングの「技法」として、5つのアプローチを解説しています。表現に少々一貫性がないように感じられるのですが、原書どおりなのでお許しください。

• リニアスクリプト
• 構造化スクリプティング
• 共有スクリプト
• データ駆動スクリプト
• キーワード駆動スクリプト

　簡単におさらいしてみましょう。詳しくはぜひ、本書を買って読んでくださいね！

　「リニアスクリプト」は、キャプチャーリプレイツールで操作を記録することで自動生成されたスクリプトを、ほとんどそのまま使うものです。1つのテストケースが1つのテストスクリプトに対応するため、テストケースの数が10倍になればスクリプトの数も10倍と、「線形に（リニアに）」増加してしまいます。

　「構造化スクリプティング」では、分岐・反復といった、プログラミングの基本的な構造を使ってスクリプトを表現することで、スクリプトの保守性・可読性を向上させることができます。

　リニアスクリプトや構造化スクリプティングのアプローチでは、複数のテストケースに共通の操作（たとえばログイン／ログアウト、特定の画面への遷移など）に対応するスクリプトがテストケースごとに現れるため、操作に変更が発生した場合、そのすべてを修正する必要があります。

　「共有スクリプト」のアプローチでは、テストケース間で重複して現れるスクリプトを部品として切り出し、それらを複数のテストケースから呼び出すことで、テストスクリプトの保守性や可読性をさらに向上させることができます。また、部品同士を組み合わせた新しいテストケースを組み立てることもできるので、リニアスクリプトが抱えていた「線形」の問題から逃れられることになります。

　共有スクリプトでは一連の操作を分割することでスクリプトを部品化したのに対し、「データ駆動スクリプト」ではスクリプトとデータを分離します。これによって、「手順は同じだが、入力する値は異なる」テストケースを、1つのスクリプトと複数のデータのセットで実現することができます。

　「キーワード駆動スクリプト」では、スクリプトの部品化、スクリプトとデータの分離を行った上で、さらにそれらの部品を、自然言語に近い「キーワード」として抽象化します。ドメインエキスパートやテストエンジニアは、それらのキーワードを使うことで、スクリプトの内部構造を意識せずに自動テストケースを記述できるようになります。ここで、抽象化の度合いについては何も言及していないことに注意してください。

　なお、ギア本では、テスト自動化において目指すべき最初のアプローチはデータ駆動であるとしています。それと同時に、それぞれのアプローチは排他的なものではないとし、状況に応じて併用することを否定していません。