第 1 回 システムテスト自動化標準ガイド読書会

第 2 章　キャプチャーリプレイはテスト自動化ではない

記録、再生、繰り返し実施　≠　テストの自動化

2015/04/18いしじ　あつし

自己紹介

◆ 　あ

名前• いしじ　あつし

現在の仕事• 人事のマネージャ。新卒・中途採用の採用責任者（国内外問わ

ず）

• 自社採用サイト、採用管理システムの開発

• 全社の技術力向上のために、システム戦略を兼任• 占いサービス用レコメンドエンジン設計、 GitHub エンタープラ

イズ導入推進、エンジニア評価制度の策定なども手がける

経歴• 前職はＩＴコンサルで、官公庁・教育機関向けのソフトウェア開

発・業務改善、システムアウトソーシング推進を担当

CONFIDENTIAL Copyright © CA MOBILE,Ltd. 2014

自己紹介＜名前＞　菱　信一郎（ひし　しんいちろう）　

＜人となり＞　 36 歳・♂・かに座・ O 型・双子の弟が一人

＜役割＞　インフラシステム G 　ゼネラルマネージャー　兼　技術 Board （通称：チーム CTO ）メンバー　兼　ネットワーク・エンジニア　兼　感動配達屋

＜好きなもの＞ 　 MEN’S TENORAS 、 Oranje 、はぐれメタル　

＜好きな Cisco 語＞　 PA ｇ P （ぱぐぴぃー）

＜嫌いなプロトコル＞　 STP 全般

＜モットー＞　機器と機器を接続（つな）いで、人と人を繋ぐ。

2.1 　例題のアプリケーション「 Scribble 」

事例としてのワードプロセッサの紹介

テストケースの入力事例

2.2 手動テストのプロセスー何を自動化すべきか ?

◆ テストケースの自動化にかかる工数テストケースの自動化のためには、手動の場合と比較して、少なくとも 5 倍の工数が必要と想定しよう。

工数に影響する 6 個の要素

① 利用されるツール多種多様の機能をそろえている

② テストの自動化のアプローチ• 手動でテストを記録し、それを再生するのが最初のアプロー

チ• テストスクリプトの準備・更新が他のアプローチ後者の方が、新しいテストの実装とメンテナンスコストの削減は容易

③ テストオートメーターの経験レベルツールに精通することが大事

◆ テストケースの自動化にかかる工数 6 個の影響要素（続き）

④ 環境組む込み、リアルタイムソフトウェアにおける環境準備は特に厄介

⑤ テスト対象のソフトウェア• ユーザーとのやり取りがないバッチプログラムのようなソフト

のテスト自動化は環境さえあれば容易• ユーザーとのやりとり、かつそれをプログラムしなければ、テ

スト自動化ができない場合は、負荷は大きくなりかねない• ソフトウェア設計自体が、テスティングの自動化の成功を左右

する

⑥ 既存のテストプロセステストケースが、入力や比較が全て書かれた詳細なドキュメントになっていれば、その自動化にかかる工数はずっと少なくて済む

◆ 質問です

テストケースの自動化は、手動と比較して、実際に、どれくらいの工数を見込みますか？

5倍以上と思われる方、挙手をお願いいたします。

◆ 質問です

プロジェクト現場で、テスティングの自動化を意識して、ソフトウェア設計をされていますか？

もちろんだ！という方いらっしゃいますか？

◆ テストプロセスのカテゴリー

大半のテストプロセスは、次に示すカテゴリーのいずれか、あるいは複数に適合するはず

アドホックテスト

曖昧な手動テストスクリプト

詳細な手動テストスクリプト

◆ アドホックテスト（テストスクリプトなし）

テストケースが設計されていない、またはドキュメント化されていない

• 遅延発生等で、テストなど考えられないプロジェクトではよくある

• 計画や設計を十分にしないで実装してしまうのと同じこと

【手順】• 何をするか、何をテストするかを考える• 具体的な入力を考え出す• 今考え出した入力値を入力する• 画面上の反応で、正常動作をチェック

【短所】• 重要なテストが見落とされているかも• 他の部分が、よりテストが必要かも• テストや欠陥を再現できないかも• 通常は効果的でもないし、効率的でもない

◆ 曖昧な手動テストスクリプトテストケースはドキュメント化されているが、詳細ではない

• 入力値や比較の詳細が記述されていない点で曖昧• 「何からの無効値」のように暗黙的ステップ 入力 期待結果 成功

1

入力チェック ログイン ID 、パスワードが未入力時のまま、ログインボタンを押下

エラーメッセージが表示される 　

2

ログインチェック

登録済のログイン ID 、パスワードを入力して、ログインボタンを押下

画面遷移する 　

3

ログインエラーチェック

登録されていないログイン ID 、パスワードを入力して、ログインボタンを押下

エラーメッセージが表示される 　

・・・

・・・ ・・・ ・・・ 　

◆ 曖昧な手動テストスクリプトテストケースはドキュメント化されているが、詳細ではない

• 入力値や比較の詳細が記述されていない点で曖昧• 「何からの無効値」のように暗黙的

【手順】• 何をするかを読む• 具体的な入力を考え出す• 今考え出した入力値を入力する• 画面上の反応で、正常動作をチェック

【長所】• テスト担当者が異なっても、同様の欠陥を発見できる可能性がある• テストスクリプトに従っていれば、特定条件は全てテストされる• テストスクリプトが、何をテストするかを示すドキュメントになってい

る• テストケースやレビューをインスペクション（検査。視察。査察）可能• アドホックと比較して、効果的かつ効率的

【短所】• テスト入力が正確には定義されない• テスト担当者が異なると、少し異なった操作をしてしまうかもしれない• 問題を確実に再現できないかもしれない

◆ 詳細な手動テストスクリプト個々の入力と比較が書かれているもの

ステップ 入力 期待結果 成功

1

入力チェック ログイン ID 、パスワードが未入力時のまま、ログインボタンを押下

「ログイン ID とパスワードを入力してください」とのエラーメッセージが表示されること

　

2

ログインチェック

登録済のログイン ID 、パスワードを入力して、ログインボタンを押下

ログイン ID 　：　 DogDogパスワード　：　TEstAutomation 　

レポート画面に遷移する 　

3

ログインエラーチェック

登録されていない以下のログイン ID 、パスワードを入力して、ログインボタンを押下

ログイン ID 　：　 Sqautパスワード　：　Automation1234 　

「無効なログイン ID 、まはたパスワードです。正しいアカウント情報にて、ログインしてください」とのエラーメッセージが表示されること。

　

・・・

・・・ ・・・ ・・・ 　

◆ 詳細な手動テストスクリプト個々の入力と比較が書かれているもの

• テスト担当者がすべきことは全て書かれている• テスト担当者にとっては最もうんざりし、飽き飽きする• なぜなら創造性を発揮する余地がないから

【例】　いくつか無効な値を入力する（ × ）　　⇒　無効な位置番号「 7」を入力する（○）

【手順】• 何をするかを、正確に読み取る• テストスクリプトの入力値を正確に入力する• 画面上の反応で、正常動作をチェック

◆ 詳細な手動テストスクリプト

【長所】• 同じテストスクリプトを使えば、正確に同じテストを実行可能（ただ

しヒューマンエラーを防ぐものではない）• ソフトウェアの故障は、再現できる可能性が高い• 誰でもテスト実行可能• 入力と期待結果の情報が書かれているので、自動化が容易

【短所】• 作成コストが高価• 厳密さが要求されていないのに、たまに冗長なテキストが含まれる• 共通の操作があっても、テストスクリプトが再利用される傾向はない• 冗長なので、メンテナンスが難しい• 創造性を発揮する余地がなく、実行が退屈

◆詳細なテストスクリプト

詳細なテストスクリプトは自動化の出発地点

人間とテストツールの両方が、テストスクリプトを理解できる新しい書式が必要

詳細な手動テストスクリプトを自動化すれば、テストオートメーターがアプリケーションやビジネス、テストケースについて理解する必要がなくなる？？？

◆ 質問です

このケースでは、テスターと、テストオートメーターで、担当が分かれている想定ですが、皆さんの現場ではいかがでしょうか？

担当が分かれているプロジェクトの経験がある方、挙手をお願いいたします。

◆ 質問

テストオートメーターがアプリケーションやビジネス、テストケースについて理解する必要がなくなる。

まずは、このメッセージに、賛成の方、挙手をお願いいたします。

その理由を皆で共有いたしませんか？

2.3 　テスト実行の自動化ー入力

◆ 自動テストスクリプト≠手動テストスクリプト

テストスクリプトが「自分でドキュメント化」することはない

• テストスクリプトは、プログラミングの知識を持った人が書くのがベスト

• どのテストスクリプトでも自動化するのは、テストケース実行時の操作

• テストスクリプトには、確実に理解できるようにコメントを入れるべき

◆ テスト入力だけの自動化のメリットと用途 テスト担当者が行ったことを記録する意義

• 比較的早く、再生可能なテストの形にできるメリットがある

• 実行したテストのドキュメンテーションが、自動提供されるのもメリット。テストで何が行われたかを正確に知る必要がある時に監査証跡として役立つ

• ソフトウェアの U/I が変わらず、編集する必要がない条件付で、テストデータをセットアップした時の記録をとるのも工数削減の面でメリットがある。

• 複雑な一連の入力を正確に行いたい場合、手動テストの１つのステップとして記録を再生して、時間を節約することができる

• 入力の正確な表現は、バグの再現においても特に役立つ

• テスト実行のみの自動化は、ほとんど効果がない

◆ 手動テストの記録の短所

記録と再生という方法の短所

• 自動テストの価値は、その再利用にあるが。。。• テストスクリプトに、説明がなかったり• テストスクリプトは、前回の仕様に基づくものだったり• テストスクリプトに、ハードコーディングされていると汎用性が

なかったり

• テスト実行の理由は、アプリケーションの正常動作を確認するためにあるので、テスト入力の記録だけでは、結果の検証は含まれない。記録のためのテストスクリプトも必要になる（ 2.4節にて説明）

◆ 単なる記録によるテスト自動化はお薦めしません

目的に適した効率的で効果的な自動化の枠組みを目指す

• アドホックなテスティングは、いつも効果的であるとは限らない• 入力を記録しただけでは自動テストにはならない。テスト結果の

チェックも自動化されなければ、自動テストとはいえない。それは入力の自動化に留まる

• ソフトウェアが変更されたときに再度記録するというのは無駄になる

アドホックな手動テストしかしていないのなら自動化を検討する前にテスティングプロセスを見直そう

自動テスト + 手動検証

• この節までは、入力の自動化まで。次は、ソフトウェアが正しく動いたかどうかのチェック、という手間のかかる手動のプロセスは残ってしまっている

2.4 　テスト結果の比較の自動化

◆ テスト結果の比較の自動化

動的比較と実行後比較全ての結果を比較するのは非現実的で、最も重要な部分、最も意味がある部分だけを比較したい。比較のアプローチには、以下の 2 種類がある

動的比較画面出力のように、テストを実行している間にできる比較

実行後比較ファイルやデータベースの出力結果など、テストケースの実行が完結した後でのみできる比較

◆ 比較についての考察 テストケースの結果の比較を決定するとき

事例では、画面即座に確認するので、この場合は、この箇所でテストスクリプトに比較を追加する必要がある。以降は、画面キャプチャーし、毎回のテストケース実行時に、同じように動くことを保証しておく

どれだけ比較するか（詳しくは第 4章にて解説）• 何を比較するかによっても、記録結果の範囲（画面全体か、最小限か、

その中間か）は異なってくる。

• 画面キャプチャの範囲・場所に応じて、ツールが誤ってテスト成功の判断をしてしまうケースがある。

• 比較は、よりロバストになるので、予期しないエラーに関してはあまり「センシティブ」とならない

ロバストなテストある特定したバグを狙い撃ちするイメージのテスト

センシティブなテストテストで狙うバグをより広く補足する事を狙うテスト

◆ ツールは比較で差違が見つかっても実行を続ける．．．

動的比較• 最後までテストケースを実行し、他に問題がないかを見た方がメリッ

トがある• 一方で、潜在的な危険に気がつかず、壊滅的な故障が起こるリスクもあ

る

• 複雑なシステムの場合は、実行を中断する方が適切であるデータの間違った変更・削除、大規模なデータ作成・印刷、マシン時間の浪費などを防ぐため

• テストツールの大半は、ダメージが起こる可能性があるところで、実行中止の命令を出せる

• これはテストスクリプトの「プログラミング」である。ただし、このプログラミングにエラーを仕込んでしまい、ソフトウェア単体に問題がないが、テストケースが失敗する可能性もある

◆ 実行後比較の効果

実行後比較• 実行後比較のツールはキャプチャリレーツールに同梱されて提供され

ていることも多く、コンピューターは、ほぼ独立した比較を行えるユーティリティプログラムなどを提供している

• 完璧な比較検討が行われているわけではない

• 事例では、 2 つのプロセスが実行されている。最初のプロセスでテストケースを実行、 2番目のプロセスで比較を実施。これが実行後比較の自動化を困難にしている（第 4章で詳しく説明）

• 商用のテスティングツールでは、動的動作の方に厚いサポートがある

◆ 比較を自動化しても

比較結果のメッセージは、手動でチェックしなくてはならない• 動的比較の場合は、“失敗”のメッセージがログファイルに出ているか

• 実行後比較の場合は、実際と期待結果の間に差異がないか、 1 つ以上のファイルを確認しなくてはならない

• 新規にユーティリティープログラムを作る必要があるかもしれない

• テスト実行者にとって、本当にほしいレポートは、全ての比較結果を考慮に入れつつ、テストケースの成功・失敗の件数が明確であり、失敗したケースがどれかが分かるようなシンプルなレポート（第 9章で詳しく説明）

◆ 比較の自動化は些細なことではない

決定すべき選択が多岐に渡る• 最良の結果を得られるように、動的比較、実行後比較の両方の組み合わせを使用するべき

• 他には、「一度に多くの情報を比較するか、情報の小さな一部分を毎回比較するか」「回数を多く比較するか、少しにとどめるか」など（第 4章にて詳細説明）

• 「ソフトウェアの変更に対するテストの柔軟性」、「テストが不一致を検出した時ときに欠陥を見つけやすいかどうか」のトレードオフで、比較方法の選択をする

テストスクリプトは、すぐに非常に複雑になる• テスティング完全自動化には、テストケースに比較を組み込むことが不可欠

• 複雑になればなるほど、変化の影響を受けやすくなる（テスト対象のソフトウェア、テストケース自体の変化）

• テストスクリプトのコスト削減方法は、次章で詳しく説明

2.5 　テスト自動化の進化における次のステップ

◆ テスト実行と比較を自動化した！だから

後は、楽になると思ったが。。。

このテストは今や完全に自動化された

ほら、完全に動いている

◆ 残念。 2 回目は失敗。その理由 環境面でつまづく

事例では、 2回目を実行するとテスト結果のファイルが、保存先に既に存在しているため、保存できないというエラーメッセージが表示されている

【ここから得られる教訓】• テストツールは本質的に、実際に何が起きているかを「知らない」。• 自動テストに知っておいてほしいことは全てツールに明確に命じる必要

がある• 前処理が必要。環境要因を、ここで全て扱うようにする

【テストをつまづかせない要因はたくさんある】• この詳細は、第 6章にて説明される

◆ 残念。 2 回目は失敗。その理由

解決策は、多くの要因のトレードオフ

1. 実装の工数2. 将来の保守性3. テストケースの故障を分析する工数4. デバックの工数5. これまでの話と同じような状況に対処するテストケースの能力6. ロバストネス※）限定された情報を比較するテスト。想定する差分に狙いを定めて、効率よく検出しようとするアプローチのテスト

7. 他の自動テストのために行うこと

◆ 検証について

それは良いテストケースか？みすぼらしいテストケースの自動化には意味がない。比較の処理について、チェックすべきものはチェックしたか、テストケースによって見つけられるはずの欠陥をすべて明らかにできたか

• テストケースを手動実行するテスト担当者は、多数のチェックを意識して行う

• 自動テストは、テストスクリプトとしてプログラムされたものしかチェックしない

次のような結果を考慮することになると予想される• 作成または変更された可能性のあるファイル• 変更された可能性のあるデータベース• プリンタ、ネットワーク、通信装置などの出力• 画面の属性の変化• 内部のデータ構造の作成または変更

ファイルまたはデータベースの変更を検証する方法• テスト自動化の枠組みが効果的であるかが肝

全てのファイルをどこに置く？• 保守性に影響。第 5章で説明

2.6 　結論ー自動化は自動的に行われない

◆ 　結論

長い道のりの最初のステップ – まだ手動が残っている

• テストの自動化の目的にふさわしいアプローチを選ぶことが重要手の込んだアプローチは、最終的な生産性も高いが、時間コストも高い。一度使われて終わりのソフトウェアに、長期的なメンテナンスコストを最小化しようとするのは意味がない。

• テストとは、実行だけがすべてではない。セットアップ・後片付けもある

• 検証対象は、最初に考えていたものよりも多いのが普通• 効果的・効率的なテスト自動化の実現するには、メンテナンスが容易で品質も高くなるように「テストウェア」を設計する必要がある

【自動化の優れた枠組みが持つ重要な特徴】• 実行するテストのセットを選択するのがとても簡単• セットアップや終了作業など段取りの処理している。テストが自律して

いる• 自動化されたテストの集まりへ新しいテストの追加が、手動実行よりも簡単

自動テスティングの枠組み全体を、継続的に改善することによってのみ達成できる

2.7 　まとめ

◆ 　まとめ

テスティング自動化の開始ポイント• 詳細なテストスクリプトから行うのが最も簡単• アドホックテストの自動化はお勧めしない。無秩序の自動化は、もっと無秩序に

テスティング自動化のステップ• 最初のステップは、テストをキャプチャーすること• キャプチャーだけでは、テスト入力になるだけ。ソフトウェアが正しく

動いているか、チェックが必要になる（画面や生成ファイルを通じて）

テストの比較の自動化• 比較には、動的比較、実行後比較がある• 動的比較では、メンテナンスと欠陥識別の容易性、見つけられたはずの欠陥を見逃す度合いに影響を与える

• 比較を自動化しても、テストの自動化に組み込むことを考慮する余地が数多くあるに注意する

• 自動テストが使用するファイル、生成ファイルの置き場も決定する必要がある

優れたテスト自動化の枠組み• テストの実行が容易で自己完結• 新しい自動テストを追加することが、同じテストを手動で実行するより

も容易