Slide 1

Slide 1 text

株式会社TRIDENT 玉川紘子 @nkns165 初めてのシステム自動テスト 2020.09.30 BPStudy #157 システムテスト⾃動化を始めよう

Slide 2

Slide 2 text

⾃⼰紹介 Ø ⽟川紘⼦ Ø 株式会社TRIDENT チーフエンジニア Ø AIを活⽤した⾃動テストツール「Magic Pod」の開発 Ø Webサイトテストのサポートなど新機能の開発を担当 Ø 翻訳 / 寄稿させていただいた書籍など

Slide 3

Slide 3 text

今⽇のお話

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

自動テストのピラミッド UI test Integration test Unit test ユーザ操作と同じ、 End to Endのテスト スピード・安定性に⽋ける サービス層(Web APIなど) のテスト UIテストの⽋点を補うが 詳細さには⽋ける 細かいロジックを⾼速にテスト 統合部分のチェックには不向き 「初めての⾃動テスト」 1章

Slide 7

Slide 7 text

自動テストのピラミッド Integration test Unit test UI test 今⽇のテーマは この層

Slide 8

Slide 8 text

自動テストのピラミッド:基本原則 Ø 常に、テストをできる限りピラミッドの下の層に⼊れる Ø 新しいテストを追加するときには常に「ユニットテストでカ バーできないか」を確認する Ø すべてを⾃動化しようとせず、過不⾜なく適切に⾃動化する

Slide 9

Slide 9 text

システムテストの自動化は用法・用量を考えて Ø UIテストを完全になくすことはできない Ø システム全体が適切につながって動作することの確認はリリース前 には必須 Ø 特にシステムの根幹となるフローは絶対に壊れてはいけない Ø (最初は)UIテストを重視しても良い場合 Ø Unitテストを作りづらいレガシーシステム Ø ⽐較的新しいプラットフォームで開発する場合 アイスクリームコーンから ピラミッドへ 「初めての⾃動テスト」 8章

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

自動テストを1から作ってみよう お題︓ログイン機能のテスト 具体的には 何をする︖

Slide 12

Slide 12 text

システム(UI)テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する

Slide 13

Slide 13 text

システム(UI)テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する ü ログイン画⾯を開く ü システムに登録済みのメールアドレスを⼊⼒ する ü 上記メールアドレスに対応するパスワードを ⼊⼒する ü ログインボタンをクリックする ü 遷移先の画⾯に「マイページ」という⽂⾔が あることを確認する 正しいメールアドレスとパスワードで ログインできることを確認する 「初めての⾃動テスト」 2章

Slide 14

Slide 14 text

システム(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で実装した場合

Slide 15

Slide 15 text

システム(UI)テスト自動化の大まかな手順 テストの⼿順を書き出す ⾃動テストツールで 実装する 実⾏し、動作確認する これでOK…なはず

Slide 16

Slide 16 text

これで本当にOK? 繰り返し実⾏できる? → 実⾏前にCookie削除が必要 環境が変わっても実⾏できる? → URLと認証情報を可変に… ログインできない場合のテストもしたい マイページの構成が変わったら? レイアウト崩れのチェックもしたい HTMLとかうざい

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

キャプチャーリプレイの功罪 Ø キャプチャーリプレイツール=ユーザが⾏った操作を記録し てテストケースを⾃動⽣成してくれるツール Ø 商⽤の⾃動テストツールの多くがこの形式をサポート Ø フリーではSelenium IDEなどが有名 メリット デメリット キャプチャーリプレイ Ø プログラミングスキルが不要 Ø ⽴ち上がりが速い Ø 可読性が低い Ø 変更に弱く、メンテナンス がしづらい 通常のプログラム Ø ⾃由に構造化できるのでメンテ ナンス性を上げやすい Ø スキル・学習期間を要する

Slide 19

Slide 19 text

キャプチャーリプレイの功罪 Ø Selenium IDEの出⼒例 どこを操作したのか わかりにくい 不要な操作を判断して 削除する必要がある Ø 商⽤ツールはもう少し⼿厚い Ø スクリーンショットとの併記で可読 性UP Ø 共通ロジックの呼び出し Ø ⼀般的なロジック(分岐・繰り返し 等)のサポート Ø ※Selenium IDEでもある程度可能 Ø プログラミングの併⽤ Ø ⽴ち上がりの圧倒的な速さを考 えると、切り捨てるのではなく いいとこ取りしたい

Slide 20

Slide 20 text

スクリプト作成手法 Ø リニアスクリプト Ø キャプチャーリプレイの出⼒とほぼ同義 Ø 構造化スクリプティング Ø 共有スクリプト Ø データ駆動スクリプト Ø キーワード駆動スクリプト ⼀般的なプログラミングの 考え⽅と同じなので割愛 「システムテスト⾃動化標準ガイド」 第3章

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

データ駆動スクリプト Ø ⾃動テスト⽤のツールではExcelやCSV等を⽤いたデータ駆動テストがサポー トされていることがほとんど Ø データ追加にはほとんど⼯数がかからないため、低コストで多くのテストを 実装できる Ø 最初に⾃動化するテストはデータ駆動でできるものがおすすめ Ø やりすぎると結局テスト⼿順側が複雑になるため、適度な切り分けが必要 Ø 前ページの例で⾔うと、正常系まで混ぜるとテスト⼿順にif⽂が出てくる ので若⼲やりすぎ感

Slide 23

Slide 23 text

キーワード駆動スクリプト Ø ビジネスロジックとしての意味を持つ「キーワード」を定義 Ø テストスクリプトは「キーワードから成るスクリプト」と「キーワードライ ブラリ」に分けられる ü ログイン画⾯を開く ü メールアドレスEMAILを⼊⼒する ü パスワードPASSを⼊⼒する ü ログインボタンをクリックする ü 「MESSAGE」というメッセージ が表⽰される データ駆動の場合: このスクリプト⾃体はリニアに近い ü 認証情報(EMAIL, PASS)を 指定してログインする ü 「MESSAGE」というメッ セージが表⽰される キーワード駆動の場合: 「ログインする」という意味のある区切りで記述 visit ‘https://www.example.com’ fill_in ‘Eメール’, with: EMAIL fill_in ‘パスワード’, with: PASS click_button ‘ログイン’ キーワードライブラリ 認証情報を指定してログインする ※データ駆動のスクリプトは実際にはRubyで 書かれているので読み込むには知識が必要

Slide 24

Slide 24 text

キーワード駆動スクリプト Ø ⼈間が読めるキーワードでスクリプトが記述できるため可読性が⾼い Ø キーワードは対象システム内でよく使われる単位で作られるため、使い回す ことにより新しいスクリプトの作成⼯数が⼩さくできる Ø キーワード実装はプログラマ、キーワードを使ったスクリプト作成はテス ター(⾮プログラマ)というふうに効率的な⼈員配置ができる Ø キーワードの切り⽅にはある程度経験知が必要 Ø とりあえず⼩さく始めたいときにはややしんどい Ø 実際のツールでいうとこのへんの機能に近い →

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

自動化における比較の意義と限界 Ø ⽐較は実⾏と同じくらい重要 Ø ⽐較結果を検証しなければテストとしてはほとんど意味がない Ø ⽬視による検証はミスが起きることもある Ø ⾃動⽐較の限界 Ø ⾃動⽐較では「あらかじめ設定された⽐較内容」しか⽐較されない Ø ⼈間のように気を利かせて異常に気づいてくれることはない Ø 「⽐較を含む⾃動テスト実⾏の成功=テスト対象のロジックに不具 合がない」 とは限らない 「システムテスト⾃動化標準ガイド」 第4章

Slide 27

Slide 27 text

どんな比較があるか? Ø よくあるパターンは画⾯内の要素の⾒た⽬の⽐較 Ø 要素が画⾯に存在するかどうか Ø 要素の持つ値もしくは表⽰されている⽂字列 Ø 要素の表⽰・⾮表⽰ Ø 要素の活性・不活性 Ø 画⾯全体を画像⽐較(レイアウト崩れチェック等のため) Ø 難易度⾼めの⽐較 Ø ダウンロード / PDF出⼒されたファイルの検証 Ø 動画の再⽣ Ø メール送受信 Ø ファイルやDBの更新 「UIテスト」ではなく 「システムテスト」という 観点ではやりたいことが 多い

Slide 28

Slide 28 text

色々なタイプの比較 Ø 静的⽐較と動的⽐較 Ø 動的⽐較:テスト実⾏時に期待値が決まるもの。例:「宿泊予約サイトで 当⽇から3泊の予約をしたので、宿泊期間は当⽇の⽇付〜3⽇後の⽇付にな る。実⾏したのは9/30だから期間は9/30〜10/3」 Ø 単純な⽐較と複雑な⽐較 Ø 単純な⽐較:⽂字列や数値の完全⼀致 Ø 複雑な⽐較:正規表現による⼀致、数値が範囲内に収まることなど Ø 実⾏中の⽐較と実⾏後⽐較 Ø 実⾏後⽐較:⽐較に時間がかかる際などに、テスト実⾏だけを先に終えて あとでまとめて結果を期待値と⽐較する⼿法

Slide 29

Slide 29 text

「センシティブ」vs「ロバスト」 Ø センシティブな⽐較:完全⼀致を基本とし、多くの詳細な項 ⽬を⽐較する Ø ⼩さな差異を⾒逃さないが、実⾏時間がかかる・仕様変更に極端に 弱いといったデメリットもある Ø ロバストな⽐較:⽐較する場所を最⼩限の重要な箇所に絞り、 その他は無視する Ø 予想外の不具合を⾒落とす可能性がある Ø システムの性質やテストの役割に応じた使い分けが必要 Ø 最重要フローの回帰テストはセンシティブに⽐較 Ø 個別の機能は機能にフォーカスしてロバストに⽐較

Slide 30

Slide 30 text

Magic Podの場合 Ø センシティブ・かつ意外にロバストなテスト Ø 重要フローのテストを毎⽇実⾏し、途中取得したスクリーンショットを 別ツールで実⾏後⽐較 Ø 仕様変更/レイアウト変更でスクリーンショットに差異が出たら⽬視確 認してベースラインを更新するだけ → センシティブだがメンテナンスコ ストは低い 右側が最新のソースのUI レイアウトが変わっている が不具合は特にない 左側がベースライン (予め準備した 「正解」画像)

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

クリーンなテストの5原則 Ø 元々はUnitテストの⽂脈の⾔葉 Ø 特にIとRが重要 Ø システムテストにおいてFの実現は難しい事が多い Fast ⾼速に実⾏できる Independent 互いに独⽴している Repeatable 再現性がある Self-Validating ⾃⼰検証可能 Timely 適時性がある 「Clean Code アジャイルソフトウェア達⼈の技」 第9章

Slide 33

Slide 33 text

なぜ「I」と「R」が重要か Ø システムレベルの⾃動テストの典型的なユースケース 1. 夜間にCI環境で実⾏(のべ数時間かかることも) 2. ⼀部のテストだけが失敗する 3. 失敗したテストのログなどを確認し、原因を特定 4. 特定しづらい場合はログを追加するなどして再度実⾏(数分程度) 5. 修正後、再度テストを実⾏して成功することを確認

Slide 34

Slide 34 text

なぜ「I」と「R」が重要か Ø システムレベルの⾃動テストの典型的なユースケース 1. 夜間にCI環境で実⾏(のべ数時間かかることも) 2. ⼀部のテストだけが失敗する 3. 失敗したテストのログなどを確認し、原因を特定 4. 特定しづらい場合はログを追加するなどして再度実⾏(数分程度) 5. 修正後、再度テストを実⾏して成功することを確認 Ø 再現性がないと4以降の作業が⾮常につらくなる Ø 4. で再現しない Ø 幸い3. で原因は特定できたが、他のテストの結果に依存しているた め5. で全ケース流さざるをえない

Slide 35

Slide 35 text

他にも役立つケース Ø テストケースごとの独⽴性が担保されていると Ø テストの追加・削除・並べ替えが容易 Ø 並列実⾏でリードタイム削減も可能

Slide 36

Slide 36 text

「I」と「R」を守るためにできること Ø データの管理 Ø テストケースで使うデータは(特に追加・更新される場合は)極⼒ テストケース内で新規に準備する Ø 名前やIDも実⾏ごとに⼀意になるのがベスト Ø 参照するデータが多い場合にはマスタデータを⽤意しておきテスト 実⾏前に必要に応じてリストアする Ø 例:「ログインできる認証情報」と「ログインできない認証情報」 を事前に準備しておく Ø 前処理・後処理 Ø DBをテスト⽤の初期状態にする Ø ユーザのログイン状態や遷移している画⾯を揃える Ø 特定のアプリをインストールする

Slide 37

Slide 37 text

デバッグ容易性の確保も重要 Ø ⼈がテスト実⾏を監視していないのでログが重要 Ø 各種ログ(どのステップまで実⾏したか、エラー内容等) Ø スクリーンショット・動画 Ø 実⾏時の環境(OSとバージョン、ブラウザとバージョン、各ライブ ラリのバージョン、実機orシミュレータ、等) Ø ⾒やすく揃っていればバグレポートにはテストレポートのリ ンクを貼るだけでOK

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

ツールの選択・購入は自動テスト導入の氷山の一角 ツールの 購⼊ 組織内への ツールの売り込み ⾃動化のインフラ ストラクチャ構築 ⽀援の提供 「システムテスト⾃動化標準ガイド」 第11章

Slide 40

Slide 40 text

ツールの導入に必要な要素(1) Ø 導⼊のためのコスト(ツール⾃体よりも⾼コスト) Ø 組織内にツールを売り込む Ø ⽀援と訓練を提供する Ø テスト⾃動化を⽀えるインフラの構築 Ø ツールの導⼊・推進のためのロール Ø 推進役(ベンダとユーザの仲⽴ちを含む様々なタスクを遂⾏) Ø 組織上部の⽀援者 Ø ツール管理⼈ Ø 導⼊・教育チーム

Slide 41

Slide 41 text

ツールの導入に必要な要素(2) Ø 組織幹部のコミットメント Ø 前ページのコストに関する理解 Ø 導⼊期間を⼗分⻑く(〜数ヶ⽉)取ることへの理解 Ø 「短期間ですべてを⾃動化して⼯数削減」のような過度な期待をし ない Ø 広報活動 Ø 最初に1-2ヶ⽉程度のパイロットプロジェクトを実施、効果を測定し て社内にプレゼンする Ø 「回帰テストのリードタイム削減○%」など、具体的な⽬標を定める Ø 運⽤ルールやプロセスの策定 Ø その後のコンスタントな情報提供(悪いニュースも含めて)も重要

Slide 42

Slide 42 text

ツールの導入に必要な要素(3) Ø 「⼈の問題」を無視しない:仕事のやり⽅を変えてもらうた めに共有する必要のあるポイント Ø 現在の⼿動テストへの不満 Ø 将来できるようになること(=パイロットプロジェクトの成果) Ø 変⾰のために必要な最初のステップ(=導⼊⽀援など)

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

自動テストのためのツール・サービス 無償のライブラリ 商⽤ツール・サービス Ø ⾃⼒でコーディングが必要 Ø 商⽤ツールのバックエンドとして使われ ている場合もある Ø ツールがスクリプト作成を⽀援 Ø 実⾏環境まで準備されている場合もある Ø テストの作成や修復をAIでサポートする ものが多い ブラウザ モバイル ブラウザ モバイル Magic Pod mabl Perfecto testim Autify Selenium Cypress Puppeteer appium Calabash EarlGrey espresso iOS/Android iOS Android クロスブラウザ Chromeのみ

Slide 45

Slide 45 text

周辺でサポートするツール CIツール 実⾏環境の提供 Ø アプリのビルドに合わせてテストするな ど、ワークフローにテストを組み合わせ るためのツール Ø クロスプラットフォームやクロスブラウザの環 境を提供 モバイルに特化 Windows/macOSのビルドが 安価に可能 ブラウザ モバイル CircleCI Jenkins bitrise AppVeyor BrowserStack Remote TestKit SauceLabs headspin

Slide 46

Slide 46 text

ご清聴ありがとうございました