Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
自動テストについて / Automated Testing
Search
mnuma
April 06, 2023
Technology
260
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
自動テストについて / Automated Testing
mnuma
April 06, 2023
More Decks by mnuma
See All by mnuma
セキュリティチェックシートの話 / Security Check Sheet
mnuma
0
45
Datadogで始めるユーザー行動分析 / Getting Started with User Behavior Analysis Using Datadog
mnuma
0
110
Kubernetesの自動アップグレードについて / Upgrading GKE cluster
mnuma
0
230
AWS Auroraのスロークエリを Datadogで扱うまで / How to handle slow_queries_logs in AWS Aurora with Datadog
mnuma
0
1k
Googleに学ぶDesign Docs / Learn from Google on Design Docs
mnuma
0
190
Observabilityを実践する / Pragmatic observability
mnuma
2
250
Kubernetes Case Studies #1@Makuake KubeCon NA 2019 Recap
mnuma
0
180
カオスエンジニアリングについてヤホーで調べてきました / Enter the chaos engineering
mnuma
0
140
Chaos Engineering 現状把握 / History Of Chaos Engineering
mnuma
0
400
Other Decks in Technology
See All in Technology
ペアプロの価値はコードを書くことだけじゃない
codmoninc
PRO
0
160
GuardDuty 検知対応を DevOps Agent で効率化しようとしている話 / GuardDuty Investigations with DevOps Agent
masahirokawahara
1
350
GoにおけるFFIのこれまでとこれから
goccy
5
2.3k
プロダクト思考 × 基盤思考を AIで実現する Compound Engineering
tkc66buzz
1
310
株式会社シーエーシー エンジニア向け会社紹介資料
cac
0
57k
20260906 「AWS運用入門」著者が教える、運用業務への生成AI活用入門
masaruogura
0
260
作品が生態系になった ─ Mini Tokyo 3D から世界へ
nagix
0
150
Driving AI Adoption Using In-House GPUs to Serve Qwen
po3rin
2
480
OpenTelemetryのメトリクスをCloudWatchに送ってPromQLで見てみた
ota1022
0
120
「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―
go0517go
PRO
0
280
なぜSRE・セキュリティは評価されないのか?守りの組織を事業成長エンジンに変えた実践
cscengineer
PRO
3
2.4k
多層防御と最⼩権限で実現する、安全なAIエージェント設計パターン
lycorptech_jp
PRO
1
260
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
My Coaching Mixtape
mlcsv
0
310
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
440
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
460
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
520
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
730
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.5k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
560
Statistics for Hackers
jakevdp
799
230k
YesSQL, Process and Tooling at Scale
rocio
174
15k
A Tale of Four Properties
chriscoyier
163
24k
Transcript
2023.04.05 Makuake 社内LT @mnuma 自動テストについて
@mnuma タモリ倶楽部が終了してしまって悲しいです。 自己紹介
信頼性の高い自動化テストの実施 開発者が主体となった承認テストの作成・管理、およ び承認テストの容易な複製・修正 「テスト自動化」は ハイパフォーマー達 のプラクティス インプレス出版「LeanとDevOpsの科学」 p.65
自動テストの「信頼性」
None
正しい 間違ってる 成功 OK 偽陰性 失敗 偽陽性 OK テスト結果 コード
テストにおける偽陽性と偽陰性
テストにおける偽陽性と偽陰性 偽陽性: コードが正しいがテスト結果が失敗してしまう。誤検知。 ・脆いテスト (brittle test, fragile test) ・信頼不能テスト (flaky
test) 偽陰性: プロダクトコードが誤っているにもかかわらずテストが成功してしまう。 ・空振り ・カバレッジ不足
https://testing.googleblog.com/2010/12/test-sizes.html テストサイズ における分類
「結合テスト」とは? 連携されるシステム動作全般? 「ユニットテスト」とは? ロンドン学派 vs デトロイト学派 「テストサイズ」 曖昧な概念なので計測可能な定義付けを行ったもの。 テスト範囲で語ると混乱が起きがち
Small Medium Large 単一プロセスで実行されるテスト。 上限: 60秒 単一マシン上で実行されるテスト。 上限: 300秒 制約なし。
上限: 900秒+ Enormous もっとやばいやつ
Small Medium Large 言語の実行環境だけで動かせるテスト コンテナを組み合わせて実行するテスト 本番同等の環境にデプロイして実施するテスト Enormous もっとやばいやつ
「忠実性」 どんどん本番 に近くなる Small Medium Large 単一プロセスで実行されるテスト。 上限: 60秒 単一マシン上で実行されるテスト。
上限: 300秒 制約なし。 上限: 900秒+ Enormous もっとやばいやつ 「スピード」 どんどん 遅くなる 「非決定的」 複雑化し 予測出来なくなる
「忠実性」 どんどん本番 に近くなる Small Medium Large 単一プロセスで実行されるテスト。 上限: 60秒 単一マシン上で実行されるテスト。
上限: 300秒 制約なし。 上限: 900秒+ Enormous もっとやばいやつ 「スピード」 どんどん 遅くなる 「非決定的」 複雑化し 予測出来なくなる より本番に近い状況でテスト可能になる反面、 準備が難しく、動作は遅く、非決定的になりがち。 テスト失敗時分析も難しくなる。
テストのコスパ ✗ ✗ ✗
理想的なテスト
テストピラミッド 70% 20% 10% https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html くらいの 比率が望 ましい
Manual base Manual base Large Medium Smalll
Manual base Large Medium Smalll 速度 決定性 70% 20% 10%
コスト 忠実性
Inverted pyramid ice cream cone ✗ Hourglass pyramid ✗ ◦
実際には色々な変遷を辿ると思う
Manual base Large Medium Smalll 速度 決定性 70% 20% 10%
コスト 忠実性 サイズダウン 戦略
テスト自動化の 原則
テスト自動化の8原則 5. 自動テストシステムの開発は継続的 におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかる ことは稀である 8.
「テスト結果の分析」という新たな タスクが生まれる 1. 手動テストはなくならない 2. 手動でおこなって効果のないテス トを自動化しても無駄である 3. 自動テストは書いたことしかテス トしない 4. テスト自動化の効用はコスト削減 だけではない テスト自動化研究会 https://sites.google.com/site/testautomationresearch/test_automation_principle
繰り返し使われるテストのコストを削減 開発アクティビティへの効用 動いたはずの機能が壊れることを発見出来る 手動で実施したほうがテストの品質が高い 記述されたことしかテスト出来ない 運用に時間がかかる 最初から自動化が考慮されてない場合大変 テスト結果分析という新たなタスクが生まれる メリット (Pros)
デメリット (Cons)
手動テストはなくならない ユーザビリティテストなど、そもそも自動化できないテストタイプが存在する。 システムに対してはじめて実行されるテストはテストケース自体の成熟度の観点 から、手動で実施したほうがテスト実行の品質が高いケースが多い。また、自動 化がうまく進行している機能テストの残り数%など、テストを自動化するコスト とベネフィットが釣り合わないケースもある。これらの事情によって、手動で実 施されるテストが無くなることはない。
まとめ 自動テストを行ってハイパフォーマーの仲間入りをしよう 偽陰性 / 偽陽性 でテストの信頼性を意識しよう テストサイズを意識してコスパのいいテストをしよう ピラミッド型を意識したテスト戦略を立てよう 高品質である手動テストを活かせるようにしよう
END