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

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

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

445779d85a9be0acd5e9a61cc3848da3?s=128

Hiroko Tamagawa

September 30, 2020
Tweet

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. ご清聴ありがとうございました