テスト自動化 / Test_Automation

Slide 1

Slide 1 text

テスト⾃動化 2020-05-08 テストエンジニアリング園 1

Slide 2

Slide 2 text

講義の⽬的 ▌テスト⾃動化の基礎的な知識の把握 ▌(E2E)テストの⾃動化を体感する 2

Slide 3

Slide 3 text

なぜ、テストを⾃動化するのか︖ 3

Slide 4

Slide 4 text

作業効率を⾼める ▌素早くテストができる ▌正確にテストができる ▌繰り返しテストを実⾏できる 4

Slide 5

Slide 5 text

活⽤例︓CI (継続的インテグレーション) ▌プログラムの変更後、アーカイブビルドとテストを⾃動的に⾏う l不具合にいち早く気づくことができる l変更点のマージ時にテストが必ず⾃動的に⾏われる →不具合を他⼈に引き継がない ▌レポジトリ内を常に安全な状態に保つ 5

Slide 6

Slide 6 text

短期間で開発を⾏うAgile開発において素早いフィードバックを⾏えることは何よりのメリット 6

Slide 7

Slide 7 text

テストを⾃動化してみよう 7

Slide 8

Slide 8 text

Selenium IDE ▌公式サイト https://www.selenium.dev/selenium-ide/ ▌どんなツール︖ l ブラウザで⾏った操作を記録(Recode)して再現(Replay)する l ブラウザのプラグインとして動作する FireFox / Chromeに対応 l 記録した操作をCUIで実⾏することも可能 8

Slide 9

Slide 9 text

Selenium IDE – demo - ▌「ログインを⾃動化」するデモ 1. プロジェクト名を決める 2. 操作をレコーディングする 3. Assertionを設定する 4. ⾃動で実⾏する 9

Slide 10

Slide 10 text

このツールを使えば簡単にテストを⾃動化できます。どんどんテストを⾃動化して作業効率を上げましょう。ご清聴ありがとうございました。 10

Slide 11

Slide 11 text

end? 11

Slide 12

Slide 12 text

こんな感じで意気込んでテストを⾃動化した結果使われなくなった例が多く存在します 12

Slide 13

Slide 13 text

なぜ、⾃動化したテストを使わないの︖ 13

Slide 14

Slide 14 text

⾃動化したテストを使わなくなる理由 ▌動かなくなった l製品の仕様変更により動かなくなった lブラウザのバージョンなどの外部変化により動かなくなった ▌メンテナンスできない lメンテナンスできる⼈がいない ▌⼯数が確保できない lメンテナンスの量が多すぎて⼿が回らない 14

Slide 15

Slide 15 text

⾃動化したら、それ以上のコストがかからない︖ ▌テスト内容に変化がなくても、メンテナンスを迫られる l機能や仕様の変化 lブラウザ・OSの変化などの外的要因 15

Slide 16

Slide 16 text

⾃動化したテストは繰り返さないと意味がない ▌テストを⾃動化するためには多くのコストが必要 ▌繰り返し使うことで、そのテストにかかる ToC を下げる。 16

Slide 17

Slide 17 text

テストを⾃動化する際は多くのテストを⾃動化するよりも⾃動化したテストを「繰り返し⻑く使う」ほうが重要 17

Slide 18

Slide 18 text

「繰り返し⻑く使う」にはどうすればいい︖ 18

Slide 19

Slide 19 text

「⻑く使う」ための⼯夫 ▌作成・メンテナンスのコストを下げる ▌チーム全体で取り組む 19

Slide 20

Slide 20 text

「作成・メンテナンスのコストを下げる①」低コストで試験を⾏う 20

Slide 21

Slide 21 text

これから説明するのは「⾃動化」のためだけでなくテスト全体の⼯数を削減するための概念 21

Slide 22

Slide 22 text

開発の過程とテスト ▌実装前の仕様検討 l 仕様を検討して、不具合の作りこみを防⽌する ▌Unitテスト(単体テスト) l 関数やメソッドなど、最⼩単位のプログラムに対するテスト ▌インテグレーション(結合テスト) l 機能に対するUIを⽤いないテスト ▌E2Eテスト(UIテスト) l ユーザー操作に最も近い、ブラウザを⽤いたテスト 22

Slide 23

Slide 23 text

テストの種類とコスト(1) ▌仕様検討 l ⼝頭レベル l 話し合いにより、不具合の作りこみを防⽌できる l ⾃動化することが不可能 ▌Unitテスト(単体テスト) l プログラムレベル l 関係する要因が最も少ない。 l 仕様変更による影響が最も少ない 23

Slide 24

Slide 24 text

テストの種類とコスト(2) ▌インテグレーション(結合テスト) l プログラムレベル・コマンドラインレベル l リクエストを受け⼊れる機能が必要 l 検証内容によってはデータの作りこみなどが必要。 ▌E2Eテスト(UIテスト) l ブラウザレベル。ユーザーの操作に最も近いテストが可能 l ブラウザを操作するためのコードが必要 l 検証内容によってはデータの作りこみなどが必要。 l 仕様変更の影響をを受けやすい。 l 関係する要因が多い(ブラウザ等) 24

Slide 25

Slide 25 text

⼯程が進むとテストにかかるコストが⾼くなる︖ 25

Slide 26

Slide 26 text

テストの特性を理解し、低コストで⾏えるテストを充実させて⾼コストなテストを削減できることが理想 26

Slide 27

Slide 27 text

適切なタイミングでテストを⾏う ▌どの段階のテストも必要なテスト l どの段階のテストが悪い、という話ではない。 ▌各段階のテストの特性を理解することが重要 l 何を⽬的としたテストなのか︖ l テスト準備・テストにかかる⼯数の違い 27

Slide 28

Slide 28 text

『テストピラミッド』という概念 ▌テスト実⾏コストが低い層のテストを厚く⾏うことで全体のコストを抑える戦略 ▌効率のよい開発(テスト)を⾏う上で重要な概念 ▌Mike Cohn⽒が提唱したモデル https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test- automation-pyramid 28

Slide 29

Slide 29 text

補⾜） ▌テストの種別にあまり意味はない。 ▌⼤切なのは、低コストで⾏えるテストを充実させ⾼コストのテストを少なくする戦略 ▌Small,medium,Largeと分類して、⾃分たちにあわせた分類を定義するとよい 29

Slide 30

Slide 30 text

「作成・メンテナンスのコストを下げる②」⾃動化するテストを選ぶ 30

Slide 31

Slide 31 text

⾃動化に向いていないテストとは︖ ▌仕様変更が多い機能 l いわゆる「枯れていない」機能 ▌初期実装コストが⾼い l 技術的には⾃動化が可能だが、作成⼯数が⾼い例) 証明書の登録のようなOS依存性が⾼い操作 31

Slide 32

Slide 32 text

⾃動化に向いているテストとは︖ ▌繰り返しテストが実⾏される機能 ▌重要度の⾼い機能 ▌変更が少ない機能 ▌⾃動化する難易度が低い機能 32

Slide 33

Slide 33 text

「チームで取り組む」 33

Slide 34

Slide 34 text

「⼈」に依存しない体制づくり ▌「⼈」はいなくなる推進する⼈が異動や退職でいなくなる ▌独りで作れても、独りで維持はできない独りで「熱」を維持するのは難しい⾃分の⼯数は無限ではない ▌チームのメンバーを巻き込む 34

Slide 35

Slide 35 text

テストはテスターがやるもの︖ ▌プログラマとテスターが組織的に分かれていた時代 l テストはテスターが実施するもの l テスト⾃動化は、プログラマの詳しい⼈が⼿掛けていた → テスター側でメンテナンスができない → 新規⾃動化もメンテナンスも、プログラマの⼯数頼り l 協⼒体制を構築するところから開始 → 協⼒を得られなかったり⼯数の融通ができなかったりした結果⾃動化したテストが活⽤されないことも多かった 35

Slide 36

Slide 36 text

製品品質の向上はチーム全体の課題 ▌チームでなければできないことがある l 特定の⼯程だけで品質を向上させるのは限界がある例) テストピラミッドの概念の実現 ▌あなたにしかできないことがある l プログラマだから実装できるUnitテスト l UIスペシャリストだからわかるユーザビリティ的な指摘 36

Slide 37

Slide 37 text

品質向上をチームの課題と考えてテストやテスト⾃動化に取り組む『⽂化』を構築していくことが重要 37

Slide 38

Slide 38 text

チームで共有しよう ▌テスト⾃動化の⽅針 l ⾃動化の⽅法・ツール l 誰が、どのテストを、どのタイミングで実装するのか︖ ▌テスト⾃動化の⼯数 l 作成・メンテナンスに必要な⼯数 ▌テスト⾃動化の知識 38

Slide 39

Slide 39 text

チームに合わせたツール選び ▌製品とツールの相性 l 開発⾔語 l テスト内容 ▌⽬的に合わせたツール l 静的解析 l 動的テスト ▌チームメンバーのスキルと習得難易度 39

Slide 40

Slide 40 text

⾃動化したテストを「繰り返し⻑く使う」ためには、適切な段階で適切なテストを⾃動化するという⽂化をチーム内で育成していくことが重要 40

Slide 41

Slide 41 text

休憩 (〜14:10) 41

Slide 42

Slide 42 text

E2E テストを⾃動化しよう (実践) 42

Slide 43

Slide 43 text

E2Eテストの特徴 ▌エンドユーザーの操作を再現する ▌データなどを事前に準備する必要がある ▌簡単に壊れやすい 43

Slide 44

Slide 44 text

Selenium IDE ▌公式サイト https://www.selenium.dev/selenium-ide/ ▌どんなツール︖ l ブラウザに対する操作を記録(Recode)して再現(Replay)する l 利点︓GUI操作で初⼼者でもわかりやすく簡単に作成可能 l 難点︓オブジェクト指向ではないので、修正コストが⾼い 44

Slide 45

Slide 45 text

WebDriver IO ▌公式サイト https://webdriver.io/ ▌どんなツール︖ l Selenium WebDriver をNode.js上で動作させるフレームワーク l 利点︓レポート・ Assertionツールを組み合わせて柔軟なテストが可能 l 難点︓プログラムベースのため習得のハードルがやや⾼い 45

Slide 46

Slide 46 text

TCB (Test Common Base) ▌公式サイト https://github.dev.cybozu.co.jp/pages/te/tcb-wiki/ ▌どんなツール︖ l 内製(TEチーム作成)のWebDriverIOベースのテストツール l 利点︓ページオブジェクト指向でメンテナンスコストが低い l 難点︓プログラミングベースなため、習得のハードルが⾼め 46

Slide 47

Slide 47 text

Cucumber (Gherkin) ▌公式サイト https://cucumber.io/ ▌どんなツール︖ l テスト⼿順(シナリオ)を⾃然⾔語(⽇本語)で記載する l 利点︓テスト内容などの把握が容易になる l 難点︓シナリオと駆動部を別々のレイヤーで管理するコストが⾼い 47

Slide 48

Slide 48 text

E2E テストツールを選ぶポイント ▌「誰に」対してわかりやすいツールを選ぶか︖ l 実装者のスキル l テスト結果の視認性 ▌メンテナンス性をどう考えるか︖ l 作りやすさを優先するのか︖ l (ページオブジェクトの)変更への対応⼒を優先するのか︖ 48

Slide 49

Slide 49 text

チームメンバーの構成や⼈数、スキルによって最適解は異なる 49

Slide 50

Slide 50 text

テストを⾃動化してみよう (プログラム編) 50

Slide 51

Slide 51 text

WebDriverIOで⾃動化する ▌チュートリアルページ https://webdriver.io/docs/gettingstarted.html 51

Slide 52

Slide 52 text

WedDriverIO – demo - ▌「ページタイトルを確認」するデモ 1. Webページを開く 2. ブラウザに表⽰されているタイトルを取得 3. タイトルがあっているか確認 52

Slide 53

Slide 53 text

WebDriverIOで⾃動化する const assert = require('assert') describe('webdriver.io page', () => { it('should have the right title', () => { browser.url('https://webdriver.io') const title = browser.getTitle() assert.strictEqual(title, 'WebdriverIO · Next-gen browser automation test framework for Node.js') }) }) # テストグループ名 # テストタイトル # WebDriver.io のページを表⽰ # ブラウザのタイトルバーの⽂字列を title変数に⼊れる # title変数の⽂字列が指定の⽂字列と同じか確認 53