Downloaded 23 times
More Related Content
![[デブサミ2015] スクラムならうまくいく？ 〜グリーのネイティブゲーム作りの歴史をひもとく、 そして未来へ〜](https://cdn.slidesharecdn.com/ss_thumbnails/2015021919-b-6-150301195028-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
20150418 システムテスト自動化 第二章
- 1. 第1回 システムテスト自動化標準ガイド 読書会 第2章 キャプチャーリプレイはテスト自動化ではない 記録、再生、繰り返し実施≠ テストの自動化 2015/04/18 いしじ あつし
- 2.
- 3. ◆ あ 名前 •いしじ あつし 現在の仕事 • 人事のマネージャ。新卒・中途採用の採用責任者（国内外問わず） • 自社採用サイト、採用管理システムの開発 • 全社の技術力向上のために、システム戦略を兼任 • 占いサービス用レコメンドエンジン設計、GitHubエンタープライズ導入 推進、エンジニア評価制度の策定なども手がける 経歴 • 前職はＩＴコンサルで、官公庁・教育機関向けのソフトウェア開発・業務 改善、システムアウトソーシング推進を担当
- 4. CONFIDENTIAL Copyright ©CA MOBILE,Ltd. 2014 自己紹介 ＜名前＞ 菱 信一郎（ひし しんいちろう） ＜人となり＞ 36歳・♂・かに座・O型・双子の弟が一人 ＜役割＞ インフラシステムG ゼネラルマネージャー 兼 技術Board（通称：チームCTO）メンバー 兼 ネットワーク・エンジニア 兼 感動配達屋 ＜好きなもの＞ MEN’S TENORAS、Oranje、はぐれメタル ＜好きなCisco語＞ PAｇP（ぱぐぴぃー） ＜嫌いなプロトコル＞ STP全般 ＜モットー＞ 機器と機器を接続（つな）いで、人と人を 繋ぐ。
- 5.
- 6.
- 7. ◆テストケースの自動化にかかる工数 テストケースの自動化のためには、手動の場合と比較して、少な くとも5倍の工数が必要と想定しよう。 工数に影響する6個の要素 ① 利用されるツール 多種多様の機能をそろえている ②テストの自動化のアプローチ • 手動でテストを記録し、それを再生するのが最初のアプローチ • テストスクリプトの準備・更新が他のアプローチ 後者の方が、新しいテストの実装とメンテナンスコストの削減は容易 ③ テストオートメーターの経験レベル ツールに精通することが大事
- 8. ◆テストケースの自動化にかかる工数 6個の影響要素（続き） ④ 環境 組む込み、リアルタイムソフトウェアにおける環境準備は特に厄介 ⑤テスト対象のソフトウェア • ユーザーとのやり取りがないバッチプログラムのようなソフトのテスト 自動化は環境さえあれば容易 • ユーザーとのやりとり、かつそれをプログラムしなければ、テスト自動 化ができない場合は、負荷は大きくなりかねない • ソフトウェア設計自体が、テスティングの自動化の成功を左右する ⑥ 既存のテストプロセス テストケースが、入力や比較が全て書かれた詳細なドキュメントになって いれば、その自動化にかかる工数はずっと少なくて済む
- 9.
- 10.
- 11.
- 12. ◆アドホックテスト（テストスクリプトなし） テストケースが設計されていない、またはドキュメント化され ていない • 遅延発生等で、テストなど考えられないプロジェクトではよくある • 計画や設計を十分にしないで実装してしまうのと同じこと 【手順】 •何をするか、何をテストするかを考える • 具体的な入力を考え出す • 今考え出した入力値を入力する • 画面上の反応で、正常動作をチェック 【短所】 • 重要なテストが見落とされているかも • 他の部分が、よりテストが必要かも • テストや欠陥を再現できないかも • 通常は効果的でもないし、効率的でもない
- 13. ◆曖昧な手動テストスクリプト テストケースはドキュメント化されているが、詳細ではない • 入力値や比較の詳細が記述されていない点で曖昧 • 「何からの無効値」のように暗黙的 ステップ入力 期待結果 成功 1 入力チェック ログインID、パスワードが未入力時 のまま、ログインボタンを押下 エラーメッセージが表示される 2 ログインチェック 登録済のログインID、パスワードを 入力して、ログインボタンを押下 画面遷移する 3 ログインエラー チェック 登録されていないログインID、パス ワードを入力して、ログインボタンを 押下 エラーメッセージが表示される ・・・ ・・・ ・・・ ・・・
- 14. ◆曖昧な手動テストスクリプト テストケースはドキュメント化されているが、詳細ではない • 入力値や比較の詳細が記述されていない点で曖昧 • 「何からの無効値」のように暗黙的 【手順】 •何をするかを読む • 具体的な入力を考え出す • 今考え出した入力値を入力する • 画面上の反応で、正常動作をチェック 【長所】 • テスト担当者が異なっても、同様の欠陥を発見できる可能性がある • テストスクリプトに従っていれば、特定条件は全てテストされる • テストスクリプトが、何をテストするかを示すドキュメントになっている • テストケースやレビューをインスペクション（検査。視察。査察）可能 • アドホックと比較して、効果的かつ効率的 【短所】 • テスト入力が正確には定義されない • テスト担当者が異なると、少し異なった操作をしてしまうかもしれない • 問題を確実に再現できないかもしれない
- 15. ◆詳細な手動テストスクリプト 個々の入力と比較が書かれているもの ステップ 入力 期待結果成功 1 入力チェック ログインID、パスワードが未入力 時のまま、ログインボタンを押下 「ログインIDとパスワードを入力してくださ い」とのエラーメッセージが表示されること 2 ログインチェック 登録済のログインID、パスワードを 入力して、ログインボタンを押下 ログインID ： DogDog パスワード ： TEstAutomation レポート画面に遷移する 3 ログインエラー チェック 登録されていない以下のログイン ID、パスワードを入力して、ログイ ンボタンを押下 ログインID ： Sqaut パスワード ： Automation1234 「無効なログインID、まはたパスワードです。 正しいアカウント情報にて、ログインしてくだ さい」とのエラーメッセージが表示されること。 ・・・ ・・・ ・・・ ・・・
- 16. ◆詳細な手動テストスクリプト 個々の入力と比較が書かれているもの • テスト担当者がすべきことは全て書かれている • テスト担当者にとっては最もうんざりし、飽き飽きする •なぜなら創造性を発揮する余地がないから 【例】 いくつか無効な値を入力する（×） ⇒ 無効な位置番号「7」を入力する（○） 【手順】 • 何をするかを、正確に読み取る • テストスクリプトの入力値を正確に入力する • 画面上の反応で、正常動作をチェック
- 17. ◆詳細な手動テストスクリプト 【長所】 • 同じテストスクリプトを使えば、正確に同じテストを実行可能（ただしヒューマン エラーを防ぐものではない） • ソフトウェアの故障は、再現できる可能性が高い •誰でもテスト実行可能 • 入力と期待結果の情報が書かれているので、自動化が容易 【短所】 • 作成コストが高価 • 厳密さが要求されていないのに、たまに冗長なテキストが含まれる • 共通の操作があっても、テストスクリプトが再利用される傾向はない • 冗長なので、メンテナンスが難しい • 創造性を発揮する余地がなく、実行が退屈
- 18.
- 19.
- 20.
- 21.
- 22. ◆自動テストスクリプト≠手動テストスクリプト テストスクリプトが「自分でドキュメント化」することはない • テストスクリプトは、プログラミングの知識を持った人が書くのがベスト •どのテストスクリプトでも自動化するのは、テストケース実行時の操作 • テストスクリプトには、確実に理解できるようにコメントを入れるべき
- 23. ◆テスト入力だけの自動化のメリットと用途 テスト担当者が行ったことを記録する意義 • 比較的早く、再生可能なテストの形にできるメリットがある •実行したテストのドキュメンテーションが、自動提供されるのもメリット。テスト で何が行われたかを正確に知る必要がある時に監査証跡として役立つ • ソフトウェアのU/Iが変わらず、編集する必要がない条件付で、テストデータを セットアップした時の記録をとるのも工数削減の面でメリットがある。 • 複雑な一連の入力を正確に行いたい場合、手動テストの１つのステップとして 記録を再生して、時間を節約することができる • 入力の正確な表現は、バグの再現においても特に役立つ • テスト実行のみの自動化は、ほとんど効果がない
- 24. ◆手動テストの記録の短所 記録と再生という方法の短所 • 自動テストの価値は、その再利用にあるが。。。 •テストスクリプトに、説明がなかったり • テストスクリプトは、前回の仕様に基づくものだったり • テストスクリプトに、ハードコーディングされていると汎用性がなかったり • テスト実行の理由は、アプリケーションの正常動作を確認するためにあるので、 テスト入力の記録だけでは、結果の検証は含まれない。記録のためのテスト スクリプトも必要になる（2.4節にて説明）
- 25. ◆単なる記録によるテスト自動化はお薦めしません 目的に適した効率的で効果的な自動化の枠組みを目指す • アドホックなテスティングは、いつも効果的であるとは限らない •入力を記録しただけでは自動テストにはならない。テスト結果のチェックも自 動化されなければ、自動テストとはいえない。それは入力の自動化に留まる • ソフトウェアが変更されたときに再度記録するというのは無駄になる アドホックな手動テストしかしていないのなら 自動化を検討する前にテスティングプロセスを見直そう 自動テスト + 手動検証 • この節までは、入力の自動化まで。次は、ソフトウェアが正しく動いたかどうか のチェック、という手間のかかる手動のプロセスは残ってしまっている
- 26.
- 27.
- 28. ◆比較についての考察 テストケースの結果の比較を決定するとき 事例では、画面即座に確認するので、この場合は、この箇所でテストスクリプトに 比較を追加する必要がある。以降は、画面キャプチャーし、毎回のテストケース 実行時に、同じように動くことを保証しておく どれだけ比較するか（詳しくは第4章にて解説） •何を比較するかによっても、記録結果の範囲（画面全体か、最小限か、その中 間か）は異なってくる。 • 画面キャプチャの範囲・場所に応じて、ツールが誤ってテスト成功の判断をし てしまうケースがある。 • 比較は、よりロバストになるので、予期しないエラーに関してはあまり「センシ ティブ」とならない ロバストなテスト ある特定したバグを狙い撃ちするイメージのテスト センシティブなテスト テストで狙うバグをより広く補足する事を狙うテスト
- 29. ◆ツールは比較で差違が見つかっても実行を続ける．．． 動的比較 • 最後までテストケースを実行し、他に問題がないかを見た方がメリットがある •一方で、潜在的な危険に気がつかず、壊滅的な故障が起こるリスクもある • 複雑なシステムの場合は、実行を中断する方が適切である データの間違った変更・削除、大規模なデータ作成・印刷、マシン時間の浪 費などを防ぐため • テストツールの大半は、ダメージが起こる可能性があるところで、実行中止の 命令を出せる • これはテストスクリプトの「プログラミング」である。ただし、このプログラミング にエラーを仕込んでしまい、ソフトウェア単体に問題がないが、テストケースが 失敗する可能性もある
- 30. ◆実行後比較の効果 実行後比較 • 実行後比較のツールはキャプチャリレーツールに同梱されて提供されているこ とも多く、コンピューターは、ほぼ独立した比較を行えるユーティリティプログラ ムなどを提供している •完璧な比較検討が行われているわけではない • 事例では、2つのプロセスが実行されている。最初のプロセスでテストケースを 実行、2番目のプロセスで比較を実施。これが実行後比較の自動化を困難に している（第4章で詳しく説明） • 商用のテスティングツールでは、動的動作の方に厚いサポートがある
- 31. ◆比較を自動化しても 比較結果のメッセージは、手動でチェックしなくてはならない • 動的比較の場合は、“失敗”のメッセージがログファイルに出ているか •実行後比較の場合は、実際と期待結果の間に差異がないか、1つ以上のファ イルを確認しなくてはならない • 新規にユーティリティープログラムを作る必要があるかもしれない • テスト実行者にとって、本当にほしいレポートは、全ての比較結果を考慮に入 れつつ、テストケースの成功・失敗の件数が明確であり、失敗したケースがど れかが分かるようなシンプルなレポート（第9章で詳しく説明）
- 32. ◆比較の自動化は些細なことではない 決定すべき選択が多岐に渡る • 最良の結果を得られるように、動的比較、実行後比較の両方の組み合わせを 使用するべき •他には、「一度に多くの情報を比較するか、情報の小さな一部分を毎回比較す るか」「回数を多く比較するか、少しにとどめるか」など（第4章にて詳細説明） • 「ソフトウェアの変更に対するテストの柔軟性」、「テストが不一致を検出した時 ときに欠陥を見つけやすいかどうか」のトレードオフで、比較方法の選択をする テストスクリプトは、すぐに非常に複雑になる • テスティング完全自動化には、テストケースに比較を組み込むことが不可欠 • 複雑になればなるほど、変化の影響を受けやすくなる（テスト対象のソフトウェ ア、テストケース自体の変化） • テストスクリプトのコスト削減方法は、次章で詳しく説明
- 33.
- 34.
- 35. ◆残念。2回目は失敗。その理由 環境面でつまづく 事例では、2回目を実行するとテスト結果のファイルが、保存先に既に存在してい るため、保存できないというエラーメッセージが表示されている 【ここから得られる教訓】 • テストツールは本質的に、実際に何が起きているかを「知らない」。 •自動テストに知っておいてほしいことは全てツールに明確に命じる必要がある • 前処理が必要。環境要因を、ここで全て扱うようにする 【テストをつまづかせない要因はたくさんある】 • この詳細は、第6章にて説明される
- 36. ◆残念。2回目は失敗。その理由 解決策は、多くの要因のトレードオフ 1. 実装の工数 2.将来の保守性 3. テストケースの故障を分析する工数 4. デバックの工数 5. これまでの話と同じような状況に対処するテストケースの能力 6. ロバストネス ※）限定された情報を比較するテスト。想定する差分に狙いを定めて、 効率よく検出しようとするアプローチのテスト 7. 他の自動テストのために行うこと
- 37. ◆検証について それは良いテストケースか？ みすぼらしいテストケースの自動化には意味がない。比較の処理について、チェッ クすべきものはチェックしたか、テストケースによって見つけられるはずの欠陥をす べて明らかにできたか • テストケースを手動実行するテスト担当者は、多数のチェックを意識して行う •自動テストは、テストスクリプトとしてプログラムされたものしかチェックしない 次のような結果を考慮することになると予想される • 作成または変更された可能性のあるファイル • 変更された可能性のあるデータベース • プリンタ、ネットワーク、通信装置などの出力 • 画面の属性の変化 • 内部のデータ構造の作成または変更 ファイルまたはデータベースの変更を検証する方法 • テスト自動化の枠組みが効果的であるかが肝 全てのファイルをどこに置く？ • 保守性に影響。第5章で説明
- 38.
- 39. ◆ 結論 長い道のりの最初のステップ– まだ手動が残っている • テストの自動化の目的にふさわしいアプローチを選ぶことが重要 手の込んだアプローチは、最終的な生産性も高いが、時間コストも高い。一度 使われて終わりのソフトウェアに、長期的なメンテナンスコストを最小化しよう とするのは意味がない。 • テストとは、実行だけがすべてではない。セットアップ・後片付けもある • 検証対象は、最初に考えていたものよりも多いのが普通 • 効果的・効率的なテスト自動化の実現するには、メンテナンスが容易で品質も 高くなるように「テストウェア」を設計する必要がある 【自動化の優れた枠組みが持つ重要な特徴】 • 実行するテストのセットを選択するのがとても簡単 • セットアップや終了作業など段取りの処理している。テストが自律している • 自動化されたテストの集まりへ新しいテストの追加が、手動実行よりも簡単 自動テスティングの枠組み全体を、継続的に改善することによってのみ達成できる
- 40.
- 41. ◆ まとめ テスティング自動化の開始ポイント •詳細なテストスクリプトから行うのが最も簡単 • アドホックテストの自動化はお勧めしない。無秩序の自動化は、もっと無秩序に テスティング自動化のステップ • 最初のステップは、テストをキャプチャーすること • キャプチャーだけでは、テスト入力になるだけ。ソフトウェアが正しく動いている か、チェックが必要になる（画面や生成ファイルを通じて） テストの比較の自動化 • 比較には、動的比較、実行後比較がある • 動的比較では、メンテナンスと欠陥識別の容易性、見つけられたはずの欠陥を 見逃す度合いに影響を与える • 比較を自動化しても、テストの自動化に組み込むことを考慮する余地が数多く あるに注意する • 自動テストが使用するファイル、生成ファイルの置き場も決定する必要がある 優れたテスト自動化の枠組み • テストの実行が容易で自己完結 • 新しい自動テストを追加することが、同じテストを手動で実行するよりも容易