Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テスト自動化 / Test automation
Search
Cybozu
PRO
May 13, 2021
Technology
4
22k
テスト自動化 / Test automation
Cybozu
PRO
May 13, 2021
Tweet
Share
More Decks by Cybozu
See All by Cybozu
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
45k
テクニカルライティング
cybozuinsideout
PRO
4
300
サイボウズのアジャイルクオリティ2024
cybozuinsideout
PRO
3
270
モブに早く慣れたい人のためのガイド2024
cybozuinsideout
PRO
3
370
モバイル
cybozuinsideout
PRO
3
180
ソフトウェアライセンス
cybozuinsideout
PRO
4
160
ソフトウェアテスト
cybozuinsideout
PRO
3
260
自動テスト
cybozuinsideout
PRO
3
270
Docker入門2024
cybozuinsideout
PRO
3
460
Other Decks in Technology
See All in Technology
TanStack Routerに移行するのかい しないのかい、どっちなんだい! / Are you going to migrate to TanStack Router or not? Which one is it?
kaminashi
0
600
Shopifyアプリ開発における Shopifyの機能活用
sonatard
4
250
生成AIが変えるデータ分析の全体像
ishikawa_satoru
0
170
アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato
shift_evolve
0
170
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
370
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
12k
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.7k
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
10
1.1k
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
8
870
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Writing Fast Ruby
sferik
627
61k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Side Projects
sachag
452
42k
The Pragmatic Product Professional
lauravandoore
31
6.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
It's Worth the Effort
3n
183
27k
Code Review Best Practice
trishagee
64
17k
Transcript
テスト⾃動化 2021-05-13 テストエンジニアリング 園 1
講義の⽬的 ▌テスト⾃動化の基礎的な知識の把握 ▌(E2E)テストの⾃動化を体感する 2
なぜ、テストを⾃動化するのか︖ 3
速い︕安い︕正確︕ ▌テスト⾃動化のメリット l速い ⼈間がテストを⾏うよりも早く結果を出せる l安い プログラムで実⾏するので、⼈的⼯数がかからない l正確 うっかり、⾒落としといった⼈的ミスがなく正確 4
開発プロセスに対する効果 ▌開発物に対する素早いフィードバックが可能 問題に対処するための⼯数を削減できる l 記憶を掘り起こす時間 l 経緯を確認する時間 l (他⼈が作った)プログラムの内容を把握する時間 5
短期間で開発を⾏うAgile開発において 素早いフィードバックを⾏えることは何よりのメリット
活⽤例︓CI (継続的インテグレーション) ▌プログラムの変更後、アーカイブビルドとテストを⾃動的に⾏う l不具合にいち早く気づくことができる l変更点のマージ時にテストが必ず⾃動的に⾏われる →不具合を他⼈に引き継がない ▌レポジトリ内を常に安全な状態に保つ 6 CI :
Continuous Integration
E2E テストを⾃動化してみよう 7 E2E = end to end
Selenium IDE ▌公式サイト https://www.selenium.dev/selenium-ide/ ▌どんなツール︖ l ブラウザで⾏った操作を記録(Recode)して再現(Replay)する l ブラウザのプラグインとして動作する FireFox
/ Chromeに対応 l 記録した操作をCUIで実⾏することも可能 8
Selenium IDE – demo - ▌「ログインを⾃動化」するデモ 1. プロジェクト名を決める 2. 操作をレコーディングする
3. Assertionを設定する 4. ⾃動で実⾏する 9
このツールを使えば簡単にテストを⾃動化できます。 どんどんテストを⾃動化して作業効率を上げましょう。 ご清聴ありがとうございました。 10
end? 11
こんな感じで 意気込んでテストを⾃動化した結果 使われなくなった例が多く存在します 12
なぜ、⾃動化したテストを使わないの︖ 13
⾃動化したテストを使わなくなる理由 ▌動かなくなった l 製品の仕様変更により動かなくなった l ブラウザのバージョンなどの外部変化により動かなくなった ▌メンテナンスできない l メンテナンスできる⼈がいない ▌⼯数が確保できない
l メンテナンスの量が多すぎて⼿が回らない 14
⾃動化したら、それ以上のコストがかからない︖ ▌テスト内容に変化がなくても、メンテナンスを迫られる l 機能や仕様の変化 l ブラウザ・OSの変化などの外的要因 15
⾃動化したテストは繰り返さないと意味がない ▌テストを⾃動化するためには多くのコストが必要 ▌繰り返し使うことで、そのテストにかかる ToC を下げる。 16
テスト⾃動化の恩恵を享受するには、 ⾃動化したテストを 繰り返し⻑く使う 必要がある。 繰り返し⻑く使うためには、 作成やメンテナンスにかかるコストを下げる ことを意識したほうが良い 17
「作成・メンテナンスにかかるコストを下げる」 低コストで試験する 18
作成・メンテナンスのコストが⾼くなる原因は︖ ▌初期実装コストが⾼い l 技術的には⾃動化が可能だが、作成⼯数が⾼い ⇒ 作成⼯数が⾼くないテストだけを⾃動化する ▌仕様変更が多い機能 l いわゆる「枯れていない」機能 ⇒
変更が少ないテストだけを⾃動化する ▌外部仕様の変更 l OSやブラウザ・ライブラリの変化等 ⇒ 回避できない変化 19
メンテナンスの発⽣を抑えてコストを下げよう ▌変更が少ない “枯れている” 機能 l重要度の⾼い機能 l繰り返しテストが実⾏される機能 l⾃動化する難易度が低い機能 20
⾃動化にかかるコストを削減するにも限界がある。 テスト⾃体のコストを削減できないか︖ 21
「テストにかかるコストを下げる」 低コストで試験する 22
開発⼯程毎のテスト ▌実装前の仕様検討 l 仕様を検討して、不具合の作りこみを防⽌する ▌Unitテスト(単体テスト) l 関数やメソッドなど、最⼩単位のプログラムに対するテスト ▌インテグレーション(結合テスト) l 機能に対するUIを⽤いないテスト
▌E2Eテスト(UIテスト) l ユーザー操作に最も近い、ブラウザを⽤いたテスト 23
▌⼯程が進むにつれて、テストに必要なコストは増加する 開発⼯程とテストにかかるコスト 24
例)ユーザー名とパスワードの確認 ※ユーザー名とパスワードが⼀致していければエラーになることを確認 ▌Unitテスト(単体テスト) l 関数にユーザー名とパスワードを渡してエラーになるか確認 ▌インテグレーション(結合テスト) l (テストなし) ▌E2Eテスト(UIテスト) l
(テストなし) 25
例)ユーザー名とパスワードの確認 ※ユーザー名とパスワードが⼀致していければエラーになることを確認 ▌Unitテスト(単体テスト) l (テストなし) ▌インテグレーション(結合テスト) l APIにユーザー名とパスワードを渡してエラーになるか確認 ▌E2Eテスト(UIテスト) l
(テストなし) 26
例)ユーザー名とパスワードの確認 ※ユーザー名とパスワードが⼀致していければエラーになることを確認 ▌Unitテスト(単体テスト) l (テストなし) ▌インテグレーション(結合テスト) l (テストなし) ▌E2Eテスト(UIテスト) l
ブラウザから⼊⼒してエラーが出ることを確認 27
テストに必要な環境 ▌Unitテスト(単体テスト) l 環境作成の必要なし(関数の引数に値を設定) ▌インテグレーション(結合テスト) l APIが動作する環境を作成 l ユーザーデータ ▌E2Eテスト(UIテスト)
l APサーバーを⽤意 l アーカイブを⽤意してインストール l ユーザーデータ 28
テストにかかるコストを削減するために 適切なプロセスで適切なテストを⾏う ことが重要 29
『テストピラミッド』 という概念 ▌テスト実⾏コストが低い層のテストを 厚く⾏うことで全体のコストを抑える戦略 ▌効率のよい開発(テスト)を⾏う上で 重要な概念 ▌Mike Cohn⽒が提唱したモデル https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test- automation-pyramid
30
補⾜) ▌テストの種別にあまり意味はない。 ▌⼤切なのは、 低コストで⾏えるテストを充実させ ⾼コストのテストを少なくする戦略 ▌Small,medium,Largeと分類して、 ⾃分たちにあわせた分類を定義するとよい 31
適切なタイミングでテストを⾏う ▌どの段階のテストも必要なテスト l どの段階のテストが悪い、という話ではない。 ▌各段階のテストの特性を理解することが重要 l 何を⽬的としたテストなのか︖ l テスト準備・テストにかかる⼯数の違い 32
例)ユーザー名とパスワードの確認 ※ユーザー名とパスワードが⼀致していければエラー画⾯に遷移する ▌Unitテスト(単体テスト) l (テストなし) ▌インテグレーション(結合テスト) l (テストなし) ▌E2Eテスト(UIテスト) l
エラー時にエラー画⾯にリダイレクトされていること 33
「チームで取り組む」 34
テストはテスターがやるもの︖ ▌プログラマとテスターが組織的に分かれていた時代 l テストはテスターが実施するもの l テスト⾃動化は、プログラマの詳しい⼈が⼿掛けていた → テスター側でメンテナンスができない → 新規⾃動化もメンテナンスも、プログラマの⼯数頼り
l 協⼒体制を構築するところから開始 → 協⼒を得られなかったり⼯数の融通ができなかったりした結果 ⾃動化したテストが活⽤されないことも多かった 35
製品品質の向上はチーム全体の課題 ▌チームでなければできないことがある l 特定の⼯程だけで品質を向上させるのは限界がある 例) テストピラミッドの概念の実現 ▌あなたにしかできないことがある l プログラマだから実装できるUnitテスト l
UIスペシャリストだからわかるユーザビリティ的な指摘 36
「⼈」に依存しない体制づくり ▌「⼈」はいなくなる 推進する⼈が異動や退職でいなくなる ▌独りで作れても、独りで維持はできない 独りで「熱」を維持するのは難しい ⾃分の⼯数は無限ではない ▌チームのメンバーを巻き込む 37
品質向上をチームの課題と考えて テストやテスト⾃動化に取り組む『⽂化』 を構築していくことが重要 38
チームで共有しよう ▌テスト⾃動化の⽅針 l ⾃動化の⽅法・ツール l 誰が、どのテストを、どのタイミングで実装するのか︖ ▌テスト⾃動化の⼯数 l 作成・メンテナンスに必要な⼯数 ▌テスト⾃動化の知識
39
チームに合わせたツール選び ▌製品とツールの相性 l 開発⾔語 l テスト内容 ▌⽬的に合わせたツール l 静的解析 l
動的テスト ▌チームメンバーのスキルと習得難易度 40
⾃動化したテストを「繰り返し⻑く使う」 ためには、 適切な段階で適切なテストを⾃動化する という ⽂化をチーム内で育成していく ことが重要 41
休憩 (〜14:10) 42
E2E テストを⾃動化しよう (実践) 43
E2Eテストの特徴 ▌エンドユーザーの操作を再現する ▌データなどを事前に準備する必要がある ▌簡単に壊れやすい 44
Selenium IDE ▌公式サイト https://www.selenium.dev/selenium-ide/ ▌どんなツール︖ l ブラウザに対する操作を記録(Recode)して再現(Replay)する l 利点︓GUI操作で初⼼者でもわかりやすく簡単に作成可能 l
難点︓オブジェクト指向ではないので、修正コストが⾼い 45
Autify ▌公式サイト https://autify.com/ja ▌どんなツール︖ l ブラウザに対する操作を記録(Recode)して再現(Replay)する l 利点︓GUI操作で初⼼者でもわかりやすく簡単に作成可能 UIの変更をAIである程度追随して⾃動でテストを修正する l
難点︓オブジェクト指向ではないので、修正コストが⾼い 46
WebDriver IO ▌公式サイト https://webdriver.io/ ▌どんなツール︖ l Selenium WebDriver をNode.js上で動作させるフレームワーク l
利点︓レポート・ Assertionツールを組み合わせて柔軟なテストが可能 l 難点︓プログラムベースのため習得のハードルがやや⾼い 47
TCB (Test Common Base) ▌公式サイト https://github.dev.cybozu.co.jp/pages/te/tcb-wiki/ ▌どんなツール︖ l 内製(TEチーム作成)のWebDriverIOベースのテストツール l
利点︓ページオブジェクト指向でメンテナンスコストが低い l 難点︓プログラミングベースなため、習得のハードルが⾼め 48
Cucumber (Gherkin) ▌公式サイト https://cucumber.io/ ▌どんなツール︖ l テスト⼿順(シナリオ)を⾃然⾔語(⽇本語)で記載する l 利点︓テスト内容などの把握が容易になる l
難点︓シナリオと駆動部を別々のレイヤーで管理するコストが⾼い 49
E2E テストツールを選ぶポイント ▌「誰に」対してわかりやすいツールを選ぶか︖ l 実装者のスキル l テスト結果の視認性 ▌メンテナンス性をどう考えるか︖ l 作りやすさを優先するのか︖
l (ページオブジェクトの)変更への対応⼒を優先するのか︖ 50
チームメンバーの 構成や⼈数、スキルによって最適解は異なる 51
テストを⾃動化してみよう (プログラム編) 52
WebDriverIOで⾃動化する ▌チュートリアルページ https://webdriver.io/docs/gettingstarted.html 53