Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hiroko Tamagawa
September 30, 2020

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

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

Hiroko Tamagawa

September 30, 2020
Tweet

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 Ø ⽟川紘⼦ Ø 株式会社TRIDENT チーフエンジニア Ø AIを活⽤した⾃動テストツール「Magic Pod」の開発 Ø

    Webサイトテストのサポートなど新機能の開発を担当 Ø 翻訳 / 寄稿させていただいた書籍など
  2. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  3. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  4. 自動テストのピラミッド UI test Integration test Unit test ユーザ操作と同じ、 End to

    Endのテスト スピード・安定性に⽋ける サービス層(Web APIなど) のテスト UIテストの⽋点を補うが 詳細さには⽋ける 細かいロジックを⾼速にテスト 統合部分のチェックには不向き 「初めての⾃動テスト」 1章
  5. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  6. システム(UI)テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する ü ログイン画⾯を開く ü システムに登録済みのメールアドレスを⼊⼒ する

    ü 上記メールアドレスに対応するパスワードを ⼊⼒する ü ログインボタンをクリックする ü 遷移先の画⾯に「マイページ」という⽂⾔が あることを確認する 正しいメールアドレスとパスワードで ログインできることを確認する 「初めての⾃動テスト」 2章
  7. システム(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で実装した場合
  8. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  9. キャプチャーリプレイの功罪 Ø キャプチャーリプレイツール=ユーザが⾏った操作を記録し てテストケースを⾃動⽣成してくれるツール Ø 商⽤の⾃動テストツールの多くがこの形式をサポート Ø フリーではSelenium IDEなどが有名 メリット

    デメリット キャプチャーリプレイ Ø プログラミングスキルが不要 Ø ⽴ち上がりが速い Ø 可読性が低い Ø 変更に弱く、メンテナンス がしづらい 通常のプログラム Ø ⾃由に構造化できるのでメンテ ナンス性を上げやすい Ø スキル・学習期間を要する
  10. キャプチャーリプレイの功罪 Ø Selenium IDEの出⼒例 どこを操作したのか わかりにくい 不要な操作を判断して 削除する必要がある Ø 商⽤ツールはもう少し⼿厚い

    Ø スクリーンショットとの併記で可読 性UP Ø 共通ロジックの呼び出し Ø ⼀般的なロジック(分岐・繰り返し 等)のサポート Ø ※Selenium IDEでもある程度可能 Ø プログラミングの併⽤ Ø ⽴ち上がりの圧倒的な速さを考 えると、切り捨てるのではなく いいとこ取りしたい
  11. スクリプト作成手法 Ø リニアスクリプト Ø キャプチャーリプレイの出⼒とほぼ同義 Ø 構造化スクリプティング Ø 共有スクリプト Ø

    データ駆動スクリプト Ø キーワード駆動スクリプト ⼀般的なプログラミングの 考え⽅と同じなので割愛 「システムテスト⾃動化標準ガイド」 第3章
  12. ü ログイン画⾯を開く ü システムに登録済みのメールアドレスを⼊⼒す る ü 登録済みのパスワードとは異なるパスワードを ⼊⼒する ü ログインボタンをクリックする

    ü 「 メールアドレスもしくはパスワードが正し くありません」というメッセージが表⽰される データ駆動スクリプト ü ログイン画⾯を開く ü システムに登録済みのメールアドレスを⼊⼒す る ü (パスワードは⼊⼒しない) ü ログインボタンをクリックする ü 「パスワードを⼊⼒してください」というメッ セージが表⽰される ü ログイン画⾯を開く ü メールアドレスEMAILを⼊⼒する ü パスワードPASSを⼊⼒する ü ログインボタンをクリックする ü 「MESSAGE」というメッセージ が表⽰される パターン1 パターン2 EMAIL [email protected] [email protected] PASS wrong_pass MESSAGE パスワードを⼊⼒し てください メールアドレスもしく はパスワードが正しく ありません Ø テストの「データ」と「⼿順」を分ける考え⽅
  13. キーワード駆動スクリプト Ø ビジネスロジックとしての意味を持つ「キーワード」を定義 Ø テストスクリプトは「キーワードから成るスクリプト」と「キーワードライ ブラリ」に分けられる ü ログイン画⾯を開く ü メールアドレスEMAILを⼊⼒する

    ü パスワードPASSを⼊⼒する ü ログインボタンをクリックする ü 「MESSAGE」というメッセージ が表⽰される データ駆動の場合: このスクリプト⾃体はリニアに近い ü 認証情報(EMAIL, PASS)を 指定してログインする ü 「MESSAGE」というメッ セージが表⽰される キーワード駆動の場合: 「ログインする」という意味のある区切りで記述 visit ‘https://www.example.com’ fill_in ‘Eメール’, with: EMAIL fill_in ‘パスワード’, with: PASS click_button ‘ログイン’ キーワードライブラリ 認証情報を指定してログインする ※データ駆動のスクリプトは実際にはRubyで 書かれているので読み込むには知識が必要
  14. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  15. 自動化における比較の意義と限界 Ø ⽐較は実⾏と同じくらい重要 Ø ⽐較結果を検証しなければテストとしてはほとんど意味がない Ø ⽬視による検証はミスが起きることもある Ø ⾃動⽐較の限界 Ø

    ⾃動⽐較では「あらかじめ設定された⽐較内容」しか⽐較されない Ø ⼈間のように気を利かせて異常に気づいてくれることはない Ø 「⽐較を含む⾃動テスト実⾏の成功=テスト対象のロジックに不具 合がない」 とは限らない 「システムテスト⾃動化標準ガイド」 第4章
  16. どんな比較があるか? Ø よくあるパターンは画⾯内の要素の⾒た⽬の⽐較 Ø 要素が画⾯に存在するかどうか Ø 要素の持つ値もしくは表⽰されている⽂字列 Ø 要素の表⽰・⾮表⽰ Ø

    要素の活性・不活性 Ø 画⾯全体を画像⽐較(レイアウト崩れチェック等のため) Ø 難易度⾼めの⽐較 Ø ダウンロード / PDF出⼒されたファイルの検証 Ø 動画の再⽣ Ø メール送受信 Ø ファイルやDBの更新 「UIテスト」ではなく 「システムテスト」という 観点ではやりたいことが 多い
  17. 色々なタイプの比較 Ø 静的⽐較と動的⽐較 Ø 動的⽐較:テスト実⾏時に期待値が決まるもの。例:「宿泊予約サイトで 当⽇から3泊の予約をしたので、宿泊期間は当⽇の⽇付〜3⽇後の⽇付にな る。実⾏したのは9/30だから期間は9/30〜10/3」 Ø 単純な⽐較と複雑な⽐較 Ø

    単純な⽐較:⽂字列や数値の完全⼀致 Ø 複雑な⽐較:正規表現による⼀致、数値が範囲内に収まることなど Ø 実⾏中の⽐較と実⾏後⽐較 Ø 実⾏後⽐較:⽐較に時間がかかる際などに、テスト実⾏だけを先に終えて あとでまとめて結果を期待値と⽐較する⼿法
  18. 「センシティブ」vs「ロバスト」 Ø センシティブな⽐較:完全⼀致を基本とし、多くの詳細な項 ⽬を⽐較する Ø ⼩さな差異を⾒逃さないが、実⾏時間がかかる・仕様変更に極端に 弱いといったデメリットもある Ø ロバストな⽐較:⽐較する場所を最⼩限の重要な箇所に絞り、 その他は無視する

    Ø 予想外の不具合を⾒落とす可能性がある Ø システムの性質やテストの役割に応じた使い分けが必要 Ø 最重要フローの回帰テストはセンシティブに⽐較 Ø 個別の機能は機能にフォーカスしてロバストに⽐較
  19. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  20. クリーンなテストの5原則 Ø 元々はUnitテストの⽂脈の⾔葉 Ø 特にIとRが重要 Ø システムテストにおいてFの実現は難しい事が多い Fast ⾼速に実⾏できる Independent

    互いに独⽴している Repeatable 再現性がある Self-Validating ⾃⼰検証可能 Timely 適時性がある 「Clean Code アジャイルソフトウェア達⼈の技」 第9章
  21. なぜ「I」と「R」が重要か Ø システムレベルの⾃動テストの典型的なユースケース 1. 夜間にCI環境で実⾏(のべ数時間かかることも) 2. ⼀部のテストだけが失敗する 3. 失敗したテストのログなどを確認し、原因を特定 4.

    特定しづらい場合はログを追加するなどして再度実⾏(数分程度) 5. 修正後、再度テストを実⾏して成功することを確認 Ø 再現性がないと4以降の作業が⾮常につらくなる Ø 4. で再現しない Ø 幸い3. で原因は特定できたが、他のテストの結果に依存しているた め5. で全ケース流さざるをえない
  22. 「I」と「R」を守るためにできること Ø データの管理 Ø テストケースで使うデータは(特に追加・更新される場合は)極⼒ テストケース内で新規に準備する Ø 名前やIDも実⾏ごとに⼀意になるのがベスト Ø 参照するデータが多い場合にはマスタデータを⽤意しておきテスト

    実⾏前に必要に応じてリストアする Ø 例:「ログインできる認証情報」と「ログインできない認証情報」 を事前に準備しておく Ø 前処理・後処理 Ø DBをテスト⽤の初期状態にする Ø ユーザのログイン状態や遷移している画⾯を揃える Ø 特定のアプリをインストールする
  23. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  24. ツールの導入に必要な要素(1) Ø 導⼊のためのコスト(ツール⾃体よりも⾼コスト) Ø 組織内にツールを売り込む Ø ⽀援と訓練を提供する Ø テスト⾃動化を⽀えるインフラの構築 Ø

    ツールの導⼊・推進のためのロール Ø 推進役(ベンダとユーザの仲⽴ちを含む様々なタスクを遂⾏) Ø 組織上部の⽀援者 Ø ツール管理⼈ Ø 導⼊・教育チーム
  25. ツールの導入に必要な要素(2) Ø 組織幹部のコミットメント Ø 前ページのコストに関する理解 Ø 導⼊期間を⼗分⻑く(〜数ヶ⽉)取ることへの理解 Ø 「短期間ですべてを⾃動化して⼯数削減」のような過度な期待をし ない

    Ø 広報活動 Ø 最初に1-2ヶ⽉程度のパイロットプロジェクトを実施、効果を測定し て社内にプレゼンする Ø 「回帰テストのリードタイム削減◦%」など、具体的な⽬標を定める Ø 運⽤ルールやプロセスの策定 Ø その後のコンスタントな情報提供(悪いニュースも含めて)も重要
  26. 目次 Ø ⾃動テストのピラミッド Ø ⾃動システムテスト はじめの⼀歩 Ø テスト実⾏ How to

    Ø ⽐較・検証 How to Ø 「真に使える」⾃動テストにするためには Ø 技術⾯ Ø 組織への導⼊ Ø ⾃動テストのためのツール・サービス
  27. 自動テストのためのツール・サービス 無償のライブラリ 商⽤ツール・サービス Ø ⾃⼒でコーディングが必要 Ø 商⽤ツールのバックエンドとして使われ ている場合もある Ø ツールがスクリプト作成を⽀援

    Ø 実⾏環境まで準備されている場合もある Ø テストの作成や修復をAIでサポートする ものが多い ブラウザ モバイル ブラウザ モバイル Magic Pod mabl Perfecto testim Autify Selenium Cypress Puppeteer appium Calabash EarlGrey espresso iOS/Android iOS Android クロスブラウザ Chromeのみ