要件定義の不安をなくす。要件定義の不安をなくす。ユニファのバックエンド分割に学ぶイノベーションメタバース開発に必要な技術の基本知識をおさらい。Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。標準ガイド』(通称『ギア本』)第4章の翻訳を担当した、テスト自動化研究会の永田敦と申します。Graham氏に出会ったのがきっかけで、翻訳を承諾してもらい、テスト自動化研究会のメンバーの協力で翻訳して生まれたのが本書です。本稿では、私が翻訳を担当した第4章「自動比較」とそれに関連したトピックをお話しします。978-4-7981-3921-0自動比較とは比較というと、地味だという印象を受ける人がいるかもしれませんね。テスト自動化でまず話題になるのは、第3章で述べられているテストスクリプトです。Selenium[1]を使ってWebアプリケーションのテストをしている人にとっては、比較はテストスクリプトの一部になっており、あまり意識しないかもしれません。JUnit[2]のassertで簡単に自動比較ができるからです。原著が刊行された1999年当時、比較を自動化するというのは、テスト実行の自動化と同等かそれ以上に考えなければならない部分でした。刊行から15年以上経った現在でも、これらのようなツールの恩恵を受けられない場合があります。そのような場合も踏まえながら、本稿では比較の自動化とそれにまつわるお話をしていきたいと思います。ブラウザ上でWebアプリケーションをテストするためのツール。ユーザー操作を人の手に変わって行ってくれます。Javaプログラムのテスティングフレームワーク。テストの実行と比較テストの検証というのは「ソフトウェアの出力が正しいかどうかを確認するプロセスである」と、本書では述べられています。確認というのは、テスト実行の後に、実行結果と期待結果を比較することです。言い換えると、自動テストには、テストケースをテスト対象に対して実行する実行結果と期待結果を比較するという2つの自動化があるということです。本書では前者を第3章、後者を第4章で解説しています(図1)。図1:自動テスト別の観点から比較の話をしてみましょう。テストケースの実行後、実行結果と期待結果を比較しますと、比較が失敗(NG)することがあります。「しめた、バグを見つけた!」と判断するのは少し待ってください。このとき、以下のようなことが想定されます。問題)実行結果が用意できていないのに比較をした(比較するタイミングが外れている)このように、比較が失敗したとき、それがテスト対象プログラムのバグである確率は6分の1なのです。あとはテスト側の問題で、そのうち半分(4、5、6)は比較に関わるものです。考えると、テストを実行するスクリプトを考えるのも大事ですが、「比較の自動化をどう実現するか」を考えることも重要であることがお分かりになる思います。これがなかなか奥深く、本書でも自動比較が一番長い章になっています。それでは比較の自動化について考えてみましょう。比較には「動的比較」と「実行後比較」の2種類があります。実行結果をファイルなどに保存しておき、後でじっくり期待結果と比較するという方法です。原著が刊行された当時はコンピュータが貧弱で、比較によるリソースの消費がばかになりませんでした。そのため、比較によるリソースの消費が、テストの実行自身に影響することが懸念される場合には、実行後比較を用いていました。現在では、コンピュータリソースがずっと潤沢になりました。Selenium(IDEおよびWebDriver)をはじめとするOSSのテスト自動化ツールは、動的比較を用いるものがほとんどです。GUIでの比較を自動化するキャプチャーリプレイ20年以上前、コンピュータのユーザーインタフェースはキャラクタ端末(つまりCUI)が主流でした。CUIでは文字列を読み書きできればよいので、コンピュータにユーザ操作をシミュレートさせることが容易でした。実行結果はキャラクタなので、比較も単純な処理で行うことができました。95が登場して以降、GUIを使うソフトウェアが爆発的に増えました。GUIでは、ユーザ操作(テストデータやボタンイベントの入力など)のシミュレーションが難しく、実行結果を取り出して比較する処理も複雑になります。そこで考え出されたのが、「キャプチャーリプレイ」です。キャプチャーリプレイでは、マウス操作やキーボード入力を丸ごと記録(キャプチャー)しておき、テスト時にはそれを再生(リプレイ)することで、GUI上でのユーザ操作をシミュレートします。リプレイによって得た実行結果はビットマップデータとして取り出し、あらかじめ記録しておいたビットマップデータ(期待結果)と比較したり、画像認識で比較し、動的比較を行います。キャプチャーリプレイは画期的なテスト自動化機能として、まず商用ツールベンダーがサポートしました。その後、OSSでもキャプチャーリプレイ機能を持つものが現れました。キャプチャーリプレイが抱えていた課題しかし、キャプチャーリプレイにはいろいろな問題がありました。今回のテーマである比較の観点から述べれば、「保守性」と「比較精度」に問題があります。次バージョンで行うテストで再利用しようとしても、GUIに変更があったらそれはできません。キャプチャーと期待結果を取り直すことになりますが、それにかかるコスト(保守コスト)はばかになりません。保守コストは、自動化によるテストの効率化を阻むものの1つです。キャプチャーリプレイはこの保守性おいて不利です。ウインドウの拡大/縮小や縦横比の変更、画面の解像度の変更が行われた場合にも、期待結果を新規に用意する必要が出てきます。画像認識においても、誤認識を起こさないように精度を高めていくと、システムへの負荷や処理時間が過大になる恐れがあります。解決のカギは「実行結果と期待結果を適切に抽象化すること」にあります。「あるフィールドに1234.54という数字が実行結果として表示されていることを確かめたい」というテストの要求があったとします。その要求の目的は何でしょう。1234.54という文字列が期待した場所に正しく表示されていることを、ビット(ピクセル)単位で図形的に確認することでしょうか。それとも、「1234.54」という値が出力されていることを確認することのでしょうか。比較すべきことは、テストの目的によって大きく変わります。出力の値を確かめることが目的なのに、表示されたビットマップまで比較していては、効率や精度が下がりますし、コストも時間もかかります。自動化の目的は、効率を高めつつコストを下げることです。そのためには、テストの目的に適った抽象度の情報を入出力できなければならないのです。アツシ)組み込みおよび業務用システムのQA部門で、今はもっぱら品質改善活動を行っている。リスクベースドテスト、アジャイルインスペクションを経て、今はアジャイルテスティング、そしてアジャイルRCAに夢中。3.12」の最初のベータ版がリリース新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。