初めてのシステム自動テスト / The first step of system test automation

「BPStudy#157〜システムテスト自動化を始めよう」の発表資料です。オライリー・ジャパン「初めての自動テスト」と翔泳社「システムテスト自動化標準ガイド」をベースに、システムテストの自動化の初歩についてお話しました。

Transcript

1. 株式会社TRIDENT 玉川紘子 @nkns165 初めてのシステム自動テスト 2020.09.30 BPStudy #157 システムテスト⾃動化を始めよう
2. ⾃⼰紹介 Ø ⽟川紘⼦ Ø 株式会社TRIDENT チーフエンジニア Ø AIを活⽤した⾃動テストツール「Magic Pod」の開発 Ø Webサイトテストのサポートなど新機能の開発を担当 Ø 翻訳 / 寄稿させていただいた書籍など
3. 今⽇のお話
4. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
5. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
6. 自動テストのピラミッド UI test Integration test Unit test ユーザ操作と同じ、 End to Endのテスト スピード・安定性に⽋ける サービス層(Web APIなど) のテスト UIテストの⽋点を補うが 詳細さには⽋ける 細かいロジックを⾼速にテスト 統合部分のチェックには不向き 「初めての⾃動テスト」 1章
7. 自動テストのピラミッド Integration test Unit test UI test 今⽇のテーマは この層
8. 自動テストのピラミッド：基本原則 Ø 常に、テストをできる限りピラミッドの下の層に⼊れる Ø 新しいテストを追加するときには常に「ユニットテストでカ バーできないか」を確認する Ø すべてを⾃動化しようとせず、過不⾜なく適切に⾃動化する
9. システムテストの自動化は用法・用量を考えて Ø UIテストを完全になくすことはできない Ø システム全体が適切につながって動作することの確認はリリース前 には必須 Ø 特にシステムの根幹となるフローは絶対に壊れてはいけない Ø （最初は）UIテストを重視しても良い場合 Ø Unitテストを作りづらいレガシーシステム Ø ⽐較的新しいプラットフォームで開発する場合 アイスクリームコーンから ピラミッドへ 「初めての⾃動テスト」 8章
10. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
11. 自動テストを1から作ってみよう お題︓ログイン機能のテスト 具体的には 何をする︖
12. システム（UI）テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する
13. システム（UI）テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する ü ログイン画⾯を開く ü システムに登録済みのメールアドレスを⼊⼒ する ü 上記メールアドレスに対応するパスワードを ⼊⼒する ü ログインボタンをクリックする ü 遷移先の画⾯に「マイページ」という⽂⾔が あることを確認する 正しいメールアドレスとパスワードで ログインできることを確認する 「初めての⾃動テスト」 2章
14. システム（UI）テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する describe ‘正しい認証情報を⼊⼒してログインできる’ do let user = … (略) // ログイン画⾯を開く visit ‘https://www.example.com’ // システムに登録済みのメールアドレスを⼊⼒する fill_in ‘Eメール’, with: user.email // 上記メールアドレスに対応するパスワードを⼊⼒する fill_in ‘パスワード’, with: user.password // ログインボタンをクリックする click_button ‘ログイン’ // 遷移先の画⾯に「マイページ」という⽂⾔があることを確認する it { should have_selector(‘h1’, text: ‘マイページ’) } end 作成した⼿順をRSpec / Capybaraで実装した場合
15. システム（UI）テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する これでOK…なはず
16. これで本当にOK？ 繰り返し実⾏できる？ → 実⾏前にCookie削除が必要 環境が変わっても実⾏できる？ → URLと認証情報を可変に… ログインできない場合のテストもしたい マイページの構成が変わったら？ レイアウト崩れのチェックもしたい HTMLとかうざい
17. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
18. キャプチャーリプレイの功罪 Ø キャプチャーリプレイツール＝ユーザが⾏った操作を記録し てテストケースを⾃動⽣成してくれるツール Ø 商⽤の⾃動テストツールの多くがこの形式をサポート Ø フリーではSelenium IDEなどが有名 メリット デメリット キャプチャーリプレイ Ø プログラミングスキルが不要 Ø ⽴ち上がりが速い Ø 可読性が低い Ø 変更に弱く、メンテナンス がしづらい 通常のプログラム Ø ⾃由に構造化できるのでメンテ ナンス性を上げやすい Ø スキル・学習期間を要する
19. キャプチャーリプレイの功罪 Ø Selenium IDEの出⼒例 どこを操作したのか わかりにくい 不要な操作を判断して 削除する必要がある Ø 商⽤ツールはもう少し⼿厚い Ø スクリーンショットとの併記で可読 性UP Ø 共通ロジックの呼び出し Ø ⼀般的なロジック（分岐・繰り返し 等）のサポート Ø ※Selenium IDEでもある程度可能 Ø プログラミングの併⽤ Ø ⽴ち上がりの圧倒的な速さを考 えると、切り捨てるのではなく いいとこ取りしたい
20. スクリプト作成手法 Ø リニアスクリプト Ø キャプチャーリプレイの出⼒とほぼ同義 Ø 構造化スクリプティング Ø 共有スクリプト Ø データ駆動スクリプト Ø キーワード駆動スクリプト ⼀般的なプログラミングの 考え⽅と同じなので割愛 「システムテスト⾃動化標準ガイド」 第3章
21. ü ログイン画⾯を開く ü システムに登録済みのメールアドレスを⼊⼒す る ü 登録済みのパスワードとは異なるパスワードを ⼊⼒する ü ログインボタンをクリックする ü 「 メールアドレスもしくはパスワードが正し くありません」というメッセージが表⽰される データ駆動スクリプト ü ログイン画⾯を開く ü システムに登録済みのメールアドレスを⼊⼒す る ü (パスワードは⼊⼒しない) ü ログインボタンをクリックする ü 「パスワードを⼊⼒してください」というメッ セージが表⽰される ü ログイン画⾯を開く ü メールアドレスEMAILを⼊⼒する ü パスワードPASSを⼊⼒する ü ログインボタンをクリックする ü 「MESSAGE」というメッセージ が表⽰される パターン1 パターン2 EMAIL aaa@example.com aaa@example.com PASS wrong_pass MESSAGE パスワードを⼊⼒し てください メールアドレスもしく はパスワードが正しく ありません Ø テストの「データ」と「⼿順」を分ける考え⽅
22. データ駆動スクリプト Ø ⾃動テスト⽤のツールではExcelやCSV等を⽤いたデータ駆動テストがサポー トされていることがほとんど Ø データ追加にはほとんど⼯数がかからないため、低コストで多くのテストを 実装できる Ø 最初に⾃動化するテストはデータ駆動でできるものがおすすめ Ø やりすぎると結局テスト⼿順側が複雑になるため、適度な切り分けが必要 Ø 前ページの例で⾔うと、正常系まで混ぜるとテスト⼿順にif⽂が出てくる ので若⼲やりすぎ感
23. キーワード駆動スクリプト Ø ビジネスロジックとしての意味を持つ「キーワード」を定義 Ø テストスクリプトは「キーワードから成るスクリプト」と「キーワードライ ブラリ」に分けられる ü ログイン画⾯を開く ü メールアドレスEMAILを⼊⼒する ü パスワードPASSを⼊⼒する ü ログインボタンをクリックする ü 「MESSAGE」というメッセージ が表⽰される データ駆動の場合： このスクリプト⾃体はリニアに近い ü 認証情報(EMAIL, PASS)を 指定してログインする ü 「MESSAGE」というメッ セージが表⽰される キーワード駆動の場合： 「ログインする」という意味のある区切りで記述 visit ‘https://www.example.com’ fill_in ‘Eメール’, with: EMAIL fill_in ‘パスワード’, with: PASS click_button ‘ログイン’ キーワードライブラリ 認証情報を指定してログインする ※データ駆動のスクリプトは実際にはRubyで 書かれているので読み込むには知識が必要
24. キーワード駆動スクリプト Ø ⼈間が読めるキーワードでスクリプトが記述できるため可読性が⾼い Ø キーワードは対象システム内でよく使われる単位で作られるため、使い回す ことにより新しいスクリプトの作成⼯数が⼩さくできる Ø キーワード実装はプログラマ、キーワードを使ったスクリプト作成はテス ター（⾮プログラマ）というふうに効率的な⼈員配置ができる Ø キーワードの切り⽅にはある程度経験知が必要 Ø とりあえず⼩さく始めたいときにはややしんどい Ø 実際のツールでいうとこのへんの機能に近い →
25. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
26. 自動化における比較の意義と限界 Ø ⽐較は実⾏と同じくらい重要 Ø ⽐較結果を検証しなければテストとしてはほとんど意味がない Ø ⽬視による検証はミスが起きることもある Ø ⾃動⽐較の限界 Ø ⾃動⽐較では「あらかじめ設定された⽐較内容」しか⽐較されない Ø ⼈間のように気を利かせて異常に気づいてくれることはない Ø 「⽐較を含む⾃動テスト実⾏の成功＝テスト対象のロジックに不具 合がない」 とは限らない 「システムテスト⾃動化標準ガイド」 第4章
27. どんな比較があるか？ Ø よくあるパターンは画⾯内の要素の⾒た⽬の⽐較 Ø 要素が画⾯に存在するかどうか Ø 要素の持つ値もしくは表⽰されている⽂字列 Ø 要素の表⽰・⾮表⽰ Ø 要素の活性・不活性 Ø 画⾯全体を画像⽐較（レイアウト崩れチェック等のため） Ø 難易度⾼めの⽐較 Ø ダウンロード / PDF出⼒されたファイルの検証 Ø 動画の再⽣ Ø メール送受信 Ø ファイルやDBの更新 「UIテスト」ではなく 「システムテスト」という 観点ではやりたいことが 多い
28. 色々なタイプの比較 Ø 静的⽐較と動的⽐較 Ø 動的⽐較：テスト実⾏時に期待値が決まるもの。例：「宿泊予約サイトで 当⽇から3泊の予約をしたので、宿泊期間は当⽇の⽇付〜3⽇後の⽇付にな る。実⾏したのは9/30だから期間は9/30〜10/3」 Ø 単純な⽐較と複雑な⽐較 Ø 単純な⽐較：⽂字列や数値の完全⼀致 Ø 複雑な⽐較：正規表現による⼀致、数値が範囲内に収まることなど Ø 実⾏中の⽐較と実⾏後⽐較 Ø 実⾏後⽐較：⽐較に時間がかかる際などに、テスト実⾏だけを先に終えて あとでまとめて結果を期待値と⽐較する⼿法
29. 「センシティブ」vs「ロバスト」 Ø センシティブな⽐較：完全⼀致を基本とし、多くの詳細な項 ⽬を⽐較する Ø ⼩さな差異を⾒逃さないが、実⾏時間がかかる・仕様変更に極端に 弱いといったデメリットもある Ø ロバストな⽐較：⽐較する場所を最⼩限の重要な箇所に絞り、 その他は無視する Ø 予想外の不具合を⾒落とす可能性がある Ø システムの性質やテストの役割に応じた使い分けが必要 Ø 最重要フローの回帰テストはセンシティブに⽐較 Ø 個別の機能は機能にフォーカスしてロバストに⽐較
30. Magic Podの場合 Ø センシティブ・かつ意外にロバストなテスト Ø 重要フローのテストを毎⽇実⾏し、途中取得したスクリーンショットを 別ツールで実⾏後⽐較 Ø 仕様変更/レイアウト変更でスクリーンショットに差異が出たら⽬視確 認してベースラインを更新するだけ → センシティブだがメンテナンスコ ストは低い 右側が最新のソースのUI レイアウトが変わっている が不具合は特にない 左側がベースライン （予め準備した 「正解」画像）
31. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
32. クリーンなテストの5原則 Ø 元々はUnitテストの⽂脈の⾔葉 Ø 特にIとRが重要 Ø システムテストにおいてFの実現は難しい事が多い Fast ⾼速に実⾏できる Independent 互いに独⽴している Repeatable 再現性がある Self-Validating ⾃⼰検証可能 Timely 適時性がある 「Clean Code アジャイルソフトウェア達⼈の技」 第9章
33. なぜ「I」と「R」が重要か Ø システムレベルの⾃動テストの典型的なユースケース 1. 夜間にCI環境で実⾏（のべ数時間かかることも） 2. ⼀部のテストだけが失敗する 3. 失敗したテストのログなどを確認し、原因を特定 4. 特定しづらい場合はログを追加するなどして再度実⾏（数分程度） 5. 修正後、再度テストを実⾏して成功することを確認
34. なぜ「I」と「R」が重要か Ø システムレベルの⾃動テストの典型的なユースケース 1. 夜間にCI環境で実⾏（のべ数時間かかることも） 2. ⼀部のテストだけが失敗する 3. 失敗したテストのログなどを確認し、原因を特定 4. 特定しづらい場合はログを追加するなどして再度実⾏（数分程度） 5. 修正後、再度テストを実⾏して成功することを確認 Ø 再現性がないと4以降の作業が⾮常につらくなる Ø 4. で再現しない Ø 幸い3. で原因は特定できたが、他のテストの結果に依存しているた め5. で全ケース流さざるをえない
35. 他にも役立つケース Ø テストケースごとの独⽴性が担保されていると Ø テストの追加・削除・並べ替えが容易 Ø 並列実⾏でリードタイム削減も可能
36. 「I」と「R」を守るためにできること Ø データの管理 Ø テストケースで使うデータは（特に追加・更新される場合は）極⼒ テストケース内で新規に準備する Ø 名前やIDも実⾏ごとに⼀意になるのがベスト Ø 参照するデータが多い場合にはマスタデータを⽤意しておきテスト 実⾏前に必要に応じてリストアする Ø 例：「ログインできる認証情報」と「ログインできない認証情報」 を事前に準備しておく Ø 前処理・後処理 Ø DBをテスト⽤の初期状態にする Ø ユーザのログイン状態や遷移している画⾯を揃える Ø 特定のアプリをインストールする
37. デバッグ容易性の確保も重要 Ø ⼈がテスト実⾏を監視していないのでログが重要 Ø 各種ログ（どのステップまで実⾏したか、エラー内容等） Ø スクリーンショット・動画 Ø 実⾏時の環境（OSとバージョン、ブラウザとバージョン、各ライブ ラリのバージョン、実機orシミュレータ、等） Ø ⾒やすく揃っていればバグレポートにはテストレポートのリ ンクを貼るだけでOK
38. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
39. ツールの選択・購入は自動テスト導入の氷山の一角 ツールの 購⼊ 組織内への ツールの売り込み ⾃動化のインフラ ストラクチャ構築 ⽀援の提供 「システムテスト⾃動化標準ガイド」 第11章
40. ツールの導入に必要な要素(1) Ø 導⼊のためのコスト（ツール⾃体よりも⾼コスト） Ø 組織内にツールを売り込む Ø ⽀援と訓練を提供する Ø テスト⾃動化を⽀えるインフラの構築 Ø ツールの導⼊・推進のためのロール Ø 推進役（ベンダとユーザの仲⽴ちを含む様々なタスクを遂⾏） Ø 組織上部の⽀援者 Ø ツール管理⼈ Ø 導⼊・教育チーム
41. ツールの導入に必要な要素(2) Ø 組織幹部のコミットメント Ø 前ページのコストに関する理解 Ø 導⼊期間を⼗分⻑く（〜数ヶ⽉）取ることへの理解 Ø 「短期間ですべてを⾃動化して⼯数削減」のような過度な期待をし ない Ø 広報活動 Ø 最初に1-2ヶ⽉程度のパイロットプロジェクトを実施、効果を測定し て社内にプレゼンする Ø 「回帰テストのリードタイム削減◦%」など、具体的な⽬標を定める Ø 運⽤ルールやプロセスの策定 Ø その後のコンスタントな情報提供（悪いニュースも含めて）も重要
42. ツールの導入に必要な要素(3) Ø 「⼈の問題」を無視しない：仕事のやり⽅を変えてもらうた めに共有する必要のあるポイント Ø 現在の⼿動テストへの不満 Ø 将来できるようになること（＝パイロットプロジェクトの成果） Ø 変⾰のために必要な最初のステップ（＝導⼊⽀援など）
43. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
44. 自動テストのためのツール・サービス 無償のライブラリ 商⽤ツール・サービス Ø ⾃⼒でコーディングが必要 Ø 商⽤ツールのバックエンドとして使われ ている場合もある Ø ツールがスクリプト作成を⽀援 Ø 実⾏環境まで準備されている場合もある Ø テストの作成や修復をAIでサポートする ものが多い ブラウザ モバイル ブラウザ モバイル Magic Pod mabl Perfecto testim Autify Selenium Cypress Puppeteer appium Calabash EarlGrey espresso iOS/Android iOS Android クロスブラウザ Chromeのみ
45. 周辺でサポートするツール CIツール 実⾏環境の提供 Ø アプリのビルドに合わせてテストするな ど、ワークフローにテストを組み合わせ るためのツール Ø クロスプラットフォームやクロスブラウザの環 境を提供 モバイルに特化 Windows/macOSのビルドが 安価に可能 ブラウザ モバイル CircleCI Jenkins bitrise AppVeyor BrowserStack Remote TestKit SauceLabs headspin
46. ご清聴ありがとうございました