{Why,How} should we do testing ?

某所でのソフトウェアテスト入門資料

Transcript

1. {Why ,How } should we do testing ? by @izumin 5210 2016/12/10
2. Masayuki Izumi (@izumin 5210) Rekimoto Lab . @ The Univ . of Tokyo Ruby , JavaScript , CSS and Android application Engineer
3. Today 's Goal なぜテストを書くかを知る どうやってテストを書くかを知る（ 簡単に！） テストへの抵抗をなくす 2016/12/10 3
4. What is "Testing " ? 2016/12/10 4
5. DEMO はじめてのテスト！ 一緒に書いてみよう！ $ g i t c l o n e https :/ /github .com /M e n t o r s S c h o o l / t e s t i n g s - for - b e g i n n e r s $ c d t e s t i n g s - for - b e g i n n e r s $ b u n d l e i n s t a l l 2016/12/10 5
6. ここで扱う「 テスト」 とは Developer Test Customer Test QA Test 2016/12/10 6
7. Developer Testing (1/2) Developer Testing は， 開発者が開発者のために， 自分自身のために， もしくはチー ムメンバー のために行うテストです。 via 第3 回 ... 和田卓人の “ テスト駆動開発 ” 講座（ 強調引用者） 2016/12/10 7
8. Developer Testing (2/2) たとえば， 自分が書いたコー ドは自分でテストします。 そして， テス トを書くことで， フィー ドバックを得ることができます。「 次はこう しなきゃいけないはずだ」「 こういうコー ドのほうがいいんじゃな いか」―― テストがもたらしてくれる情報をもとにコー ドをより良く していこうというのが， テスト駆動開発におけるテスト， つまり Developer Testing の役割です。 via 第3 回 ... 和田卓人の “ テスト駆動開発 ” 講座（ 強調引用者） 2016/12/10 8
9. Why should we do testing ? 2016/12/10 9
10. 2016/12/10 10
11. テストを書くメリット テストが揃っていれば、 機能停止に陥るような回帰バグ (Regression Bug : 以前のバグが再発したり機能の追加/ 変更に副作 用が生じたりすること) を防止できる。 テストが揃っていれば、 コー ドを安全にリファクタリング ( 機能 を変更せずにコー ドを改善すること) できる。 テストコー ドは、 アプリケー ションコー ドから見ればクライア ントとして動作するので、 アプリケー ションの設計やシステムの 他の部分とのインター フェイスを決めるときにも役に立つ。 via 結局テストはいつ行えばよいのか - Ruby on Rails T utorial （ 強調筆者） 2016/12/10 11
12. How should we do testing ? 2016/12/10 12
13. TDD : Test -Driven Development TDD とはテストファー ストによる追加・ 変更と、 リファクタリングに よる設計改善の2 つの活動を超短期で繰り返して開発を進めていく手 法です。 via いまさら聞けない TDD/BDD 超入門（1）： テスト駆動開発／ 振る舞い駆動開発を始め るための基礎知識 ( 1/ 3) - ＠IT 2016/12/10 13
14. TDD のサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる（Red [Fail ]） 4. 目的のコー ドを書く 5. 2 で書いたテストを成功させる（Green [Pass ]） 6. テストが通るままでリファクタリングを行う（Refactor ） 7. 1∼6 を繰り返す via TDD のこころ @ OSH 2014（ [ ] 内引用者） 2016/12/10 14
15. Demo 2016/12/10 15
16. via TDD のこころ @ OSH 2014 2016/12/10 16
17. TDD Cycle http ://www .planetgeek .ch/wp-content/uploads/ 2012/ 06/A TDD-cycle .png 2016/12/10 17
18. TDD や Developer Testing に ソフトウェア工学的なメリットはいろいろ あるけれど、 最大の理由は工学的なものではない。 最大の理由は心 理的なもの 即座にフィー ドバックを得るため 書いたコー ドに自信を持つため これから書くコー ドに自信を持つため via TDD のこころ @ OSH 2014 2016/12/10 18
19. TDD を体験してみよう！ 2016/12/10 19
20. ex . 1: 閏年？ 数値を1 つ引数に取る l e a p _ y e a r ? 関数 引数の年（ 西暦） が閏年なら t r u e ， それ以外だと f a l s e を 返す 2016/12/10 20
21. テストを書く上で意識すること 2016/12/10 21
22. 漏れのないテスト？ White -box testing Black -box testing 2016/12/10 22
23. White -box testing テスト対象の構造に着目してテストケー スを作る カバレッジ（ 網羅率）: どれだけの処理経路を網羅したか 命令網羅: 命令を網羅したか 分岐網羅: 分岐条件の判定結果を網羅したか 条件網羅: 分岐ルー トを網羅したか TDD 的？ 2016/12/10 23
24. Black -box testing テスト対象の仕様に着目してテストケー スを作る どんな入力/ 出力があるか どんなデー タが保存されるか どんな計算を行うか etc . 仕様の分析 同値分割 境界値分析 デシジョンテー ブル（ 説明は割愛） etc . 2016/12/10 24
25. 同値分割 入力値をグルー プに分けて， その代表値でテストケー スを作 る e .g . 月と日を引数にとる関数 月のグルー プ: 1 未満，1 以上12 以下，12 超 日のグルー プ: 1 未満，1 以上31 以下，31 超 2016/12/10 25
26. 境界値分析 同値クラスの境界はエラー が起きやすいので， そこをテスト する e .g . お酒飲めますか？ 19 歳: 飲めない, 20 歳: 飲める r e t u r n a g e > 2 0 って書いちゃってて20 歳なのに飲めな いパター ンを防ぐ 2016/12/10 26
27. 実際にテストを書いてみよう！ 2016/12/10 27
28. ex . 2: FizzBuzz 数値を1 つ引数に取る f i z z b u z z 関数 引数が3 の倍数なら f i z z ，5 の倍数なら b u z z ，3 と5 の公倍数 なら f i z z b u z z という文字列を返す 上記のいずれにも該当しない場合は数値をそのまま返却する 2016/12/10 28
29. ex . 3: そのクレジットカー ド番号， あってる？ カー ド番号（ 文字列） を受け取り， 正しいかどうかを返 す v a l i d _ c a r d ? 関数を実装する Luhn アルゴリズム 1. 一の位から数えて奇数番目の場合はそのまま、 偶数番目の場合 は数を2 倍する 2. 2 倍にした偶数番目の数が10 以上の場合は、 その各桁を足して1 桁 にする 例) 18 の 場合は 1 + 8 = 9 とする 3. 得られた桁の数を全部足す 4. 10 で割り切れれば正当な番号 via クレジットカー ド番号の入力誤り確認について - mo-fu note 2016/12/10 29
30. ex . 4: 定番カウントアプリ C o u n t e r クラスを作る 初期値は 0 # i n c r e m e n t でカウントアップ # c l e a r で0 に初期化 # c o u n t で現在の値を取得 2016/12/10 30
31. 実プロダクトにおけるテスト 2016/12/10 31
32. Testing levels Unit testing 関数・ メソッドなど小さい単位でのテスト Integration testing 複数のモジュー ルが関係するテスト System testing システムを通してのテスト 2016/12/10 32
33. Testing Pyramid via Google T esting Blog : Just Say No to More End-to-End T ests 2016/12/10 33
34. e .g . TodoMVC シンプルな Todo 管理アプリ どんなテストを書いていく？ 2016/12/10 34
35. Small testings 単機能/ モジュー ルが責任範囲 よくある機能に対する不具合、 エラー ケー スに対するテストな どがここ mock や stub を使い、 早く回すことを重視する 開発の中に組み込んでいく via 続・ テストの種類に関して振り返ってみた、Google の S/M/L もね – 徒然なるままに 2016/12/10 35
36. e .g . Small testings for TodoMVC 「 タスクを作成する」 関数 新規タスクを DB に保存 外部 API に新タスクを通知 etc . Use mocks for external dependencies like DB , Web API call , etc . Test targets include "bussiness logic ", etc . Unit testings はだいたい Small testings 2016/12/10 36
37. Medium testings 2 個以上の相互に影響のある機能をテストする時の区分 それぞれの機能のつながりに対してテストすることに焦点を当 てる 開発の中に組み込んでいく via 続・ テストの種類に関して振り返ってみた、Google の S/M/L もね – 徒然なるままに Integration testings はだいたい Medium testings 2016/12/10 37
38. e .g . Medium testings for TodoMVC チェックボックスが押されたら タスクを完了状態にする関数が呼ば れる 編集ボタンが押されたら タスク名変更フォー ムが開く etc . Use mocks for dependencies 「 タスクを完了状態にする関数」 が mock だと楽 Test targets include "ui logic ", "view state ", etc . 2016/12/10 38
39. Large testings E 2E とよく呼ばれるように、 システム全体で目的を達成するかな どを確認するための区分 すべてが自動化できるわけではなく、xxx 性試験のような、 アジ ャイル4 象限では第2, 3, 4 に区分されるような領域の試験が主 テスト対象の規模も大きくなり、 テストの実施に関しても時間 がかかるようになる。 via 続・ テストの種類に関して振り返ってみた、Google の S/M/L もね – 徒然なるままに ※ E 2E （End -to -end ）: 雑に言うと「 最初から終わりまで」 System testings , E 2E testings , Feature testings と呼ばれるものは Large testings と言えるかも 2016/12/10 39
40. e .g . Large testings for TodoMVC チェックボックスが押されたら タスクを完了状態にする関数が呼ば れ タスクが完了済みのリストに移動し DB に変更が保存されている 実際のユー ザの操作の流れ（ シナリオ） をなぞるイメー ジ コンポー ネントも mock じゃなく本物を利 用 （ ほんとに外部とのやり取りは別） 2016/12/10 40
41. A set of data -driven naming conventions for tests via Google T esting Blog : T est Sizes 2016/12/10 41
42. Test double 「 本物のふりをするニセモノのプログラム」 via 使える RSpec 入門・ その3「 ゼロからわかるモック（mock ） を使ったテストの書き 方」 - Qiita Stub 関数の返り値を予め設定しておき， 振る舞いを変更する Mock 関数の実行回数・ 引数の期待値を設定しておく Spy 関数の呼び出され方を記録する 2016/12/10 42
43. xUnit 形式と Spec 形式 2016/12/10 43
44. xUnit class CalculatorTest < Minitest ::Test def setup @ c a l c u l a t o r = C a l c u l a t o r . n e w end def test _ 足し算ができる a s s e r t _ e q u a l ( @ c a l c u l a t o r . a d d ( 1, 3) , 4) end # snip . end JUnit (Java ), XCTest (XCode ), minitest (Ruby ), etc . 2016/12/10 44
45. Spec d e s c r i b e C a l c u l a t o r do d e s c r i b e "#add " do i t " 足し算ができる" do e x p e c t ( a d d ( 1, 3) ) . t o e q 4 end end # snip . end Spock (Groovy ), Quick (Swi ), RSpec (Ruby ), etc . ※ minitest は xUnit ・Spec いずれでも書ける 2016/12/10 45
46. 余談 2016/12/10 46
47. 「 師匠やメンター を見つければエネルギー を節約できる」 自分の師匠やメンター を見つけることは、 生きる上ですごい重要な 事だと思っています。 生きる上で、 自分で考える事、 決断することは すごく重要なことです。 ですが、 同時にすごくエネルギー を使うこと でもあります。 そんな時、 自分よりも一歩先にいる人生の先輩を、 師 匠やメンター として観察することで、 何かを考えるときや決断する時 のエネルギー を減らすことができます。 こうして、 エネルギー を節約した分、 また別のことに向ければ将来的 にはそのメンター よりも上に行けると僕は考えています。 via 中高生のうちに知れると楽だったかもしれないエンジニア的な考え方 - Qiita （ 強調 引用者） 2016/12/10 47
48. 「 自分の師匠を見つけたら、 勝手に弟子入りすればいい」 僕はこれまで、 １年間や半年などの期間で新しい師匠となる人を見つ けては、 その師匠を見てその期間に学ぶことを考えてきました。 で すが、 今まで１度として弟子入りをさせてくださいと言ったことは ありません。 今の世の中、SNS やブログなど、 色んな発言の場があり、 直接話さな くても多くの考えを知ることができます。 何処かに通ったりする必要 はありません。 ただ、 自分の師匠にしたい人を見つけたら、 図々 しく SNS やブログを フォロー して、 勉強会などでたまに会える機会を作れれば、 その時点 で弟子入り完了です。 via 中高生のうちに知れると楽だったかもしれないエンジニア的な考え方 - Qiita 2016/12/10 48
49. 最初はかなりハー ドルが高いかもしれない 2016/12/10 49
50. まずはお手本・ 師匠を見つけて真似するところから！ 2016/12/10 50
51. 新人は、 先輩が描いた動きのパター ンを掴んで真似する。 自分なり の表現っていうのはそれから。 パター ン…。 学ぶっていうのは、 真似ぶっていうじゃん？ みんな最初は誰かの真 似。 おんなじおんなじ。 via ムサニ看板アニメー ター 井口祐未の魅力 | TRIAL DANCE 2016/12/10 51
52. Enjoy so ware testing @izumin 5210 2016/12/10 52
53. References 2016/12/10 53
54. 基礎 知識ゼロから学ぶソフトウェアテスト 【 改訂版】 関連: 『 知識ゼロから学ぶソフトウェアテスト』 読んだ - ✘╹◡╹✘ 第3 回 「 テスト」 という言葉について ── Developer Testing ，Customer Testing ，QA Testing ：［ 動画で解説］ 和田卓人の“ テスト駆動開発” 講座｜gihyo .jp … 技術評論社 TDD TDD のこころ @ OSH 2014 TDD を学ぶべき10 の理由 #TddAdventJp - やさしいデスマー チ いまさら聞けない TDD /BDD 超入門（1）： テスト駆動開発／ 振る舞い駆動開発を 始めるための基礎知識 (1/3) - ＠IT 2016/12/10 54
55. テストの区分について Google Testing Blog : Test Sizes Google Testing Blog : Just Say No to More End -to -End Tests テストの種類に関して振り返ってみた and Web /Mobile アプリ業界の品質管理と は？ – 徒然なるままに 続・ テストの種類に関して振り返ってみた、Google の S /M /L もね – 徒然なるまま に その他 Testing approach in android // Speaker Deck 使える RSpec 入門・ その3「 ゼロからわかるモック（mock ） を使ったテストの書 き方」 - Qiita 組織にテストを書く文化を根付かせる戦略と戦術 中高生のうちに知れると楽だったかもしれないエンジニア的な考え方 - Qiita ムサニ看板アニメー ター 井口祐未の魅力 | TRIAL DANCE 2016/12/10 55
56. Next step Ruby / Ruby on Rails なひと Ruby on Rails チュー トリアル： 実例を使って Rails を学ぼう 初学者がテストも含め全部やろうとするのはかなりしんどい 最初はテストと難しいのは飛ばして，2 周目以降がんばるのが吉 Everyday Rails … by Aaron Sumner et al . [Leanpub PDF /iPad /Kindle ] RSpec の入門とその一歩先へ ～RSpec 3 バー ジョン～ - Qiita Android なひと Testing approach in android // Speaker Deck JUnit 実践入門 ~ 体系的に学ぶユニットテストの技法 (WEB +DB PRESS plus ) googlesamples /android -testing : A collection of samples demonstrating di fferent frameworks and techniques for automated testing JS なひと ここに書くには余白が足りない（ 困ったら気軽に聞いてください） その他のひと がんばって （ 師匠にはなれないけど相談にはのります） 2016/12/10 56