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
software test
Search
fortkle
May 21, 2014
Programming
0
54
software test
fortkle
May 21, 2014
Tweet
Share
More Decks by fortkle
See All by fortkle
無駄な物をなるべく作らないリプレイス戦略 / replace-strategy-phperkaigi2021
fortkle
1
2.1k
フルリモート時代のカンバン運用 / kanban-operation-in-remote
fortkle
0
630
GitHub Actionsで始めるPHPアプリケーションのCI実践入門 / ga-phperkaigi2020
fortkle
3
4.2k
余裕を生み出すコードレビュー 〜レビュイー編〜 / code-review-phpcon-2019
fortkle
8
6.9k
「設計振り返り」を始めてみようと思っている話 / architecture reflection
fortkle
3
530
「ママ向けNo.1アプリ」の 更なる成長を支える仕組み / startup-engineer-night-connehito
fortkle
2
280
良いテストデータ、悪いテストデータ / testdata-antipattern
fortkle
4
6.7k
BackstopJSで始める CSSリグレッションテスト / backstopjs-css-test
fortkle
0
1.5k
PhpStorm導入アンチパターン / phpstorm-anti-pattern
fortkle
0
2k
Other Decks in Programming
See All in Programming
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
3
440
menu基盤チームによるGoogle Cloudの活用事例~Application Integration, Cloud Tasks編~
yoshifumi_ishikura
0
110
CQRS+ES の力を使って効果を感じる / Feel the effects of using the power of CQRS+ES
seike460
PRO
0
130
Amazon S3 NYJavaSIG 2024-12-12
sullis
0
100
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
260
Webエンジニア主体のモバイルチームの 生産性を高く保つためにやったこと
igreenwood
0
340
LLM Supervised Fine-tuningの理論と実践
datanalyticslabo
7
1.3k
競技プログラミングへのお誘い@阪大BOOSTセミナー
kotamanegi
0
360
ブラウザ単体でmp4書き出すまで - muddy-web - 2024-12
yue4u
3
470
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
270
採用事例の少ないSvelteを選んだ理由と それを正解にするためにやっていること
oekazuma
2
1k
Keeping it Ruby: Why Your Product Needs a Ruby SDK - RubyWorld 2024
envek
0
190
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
Statistics for Hackers
jakevdp
796
220k
Become a Pro
speakerdeck
PRO
26
5k
GitHub's CSS Performance
jonrohan
1030
460k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Faster Mobile Websites
deanohume
305
30k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
Gamification - CAS2011
davidbonilla
80
5.1k
A designer walks into a library…
pauljervisheath
204
24k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
98
Bash Introduction
62gerente
608
210k
Transcript
テストのテ テストのテ - テスト初心者の僕がテストについて調べて分かったこと -
テストのテ 今日の発表で目指すところ • テストの流流れを理理解する • 基本的なテスト⽤用語についてはわかるよ うになる
テストのテ なぜテストについて調べたのか • テストが超重要なのは知っている • →ほとんどテストを書いたことがない • →なぜ書けないのか • →SIerに⽐比べてあまりテストをかかない
• →そもそもテストについてよくしらない • 調べた!!←イマココ
テストのテ やったこと • 本を読む – 『知識識ゼロから学ぶ ソフトウェアテスト』 – 『ソフトウェアエンジニアリングの新⼈人研修』 • WEBの記事を読み漁る – @IT連載
– @kyon_̲mm さんのブログ記事 – slideshare, SpeakerDeck • 上司に質問する
テストのテ 今日話すこと • テストの⽬目的について • テストの順序について – 開発の流流れ – テストの流流れ • テストの種類について
• テストの技法について • おわりに
テストのテ 何のためにテストをするのか(目的) • ソフトウェアテストの⽬目的は 1. エラー(バグ、⽋欠陥)を⾒見見つけ出す。 2. ソフトウェアの 品質 を保証する。
テストのテ 何のためにテストをするのか(目的) • ソフトウェアテストの⽬目的は 1. エラー(バグ、⽋欠陥)を⾒見見つけ出す。 2. ソフトウェアの 品質 を保証する。
テストのテ 何のためにテストをするのか(目的) • 1.エラー(バグ、⽋欠陥)を⾒見見つけ出す。 – プログラムを正しく動かすために。 – バグの早期発⾒見見により修正コストを減らす。 • 2.ソフトウェアの品質を保証する。 – 「プログラム品質」→ 仕様書通りか
– 「設計品質」→機能の改修や追加が簡単か
テストのテ 何のためにテストをするのか(目的) • 1.エラー(バグ、⽋欠陥)を⾒見見つけ出す。 • 2.ソフトウェアの品質を保証する。
テストのテ 何のためにテストをするのか(目的) • 1.エラー(バグ、⽋欠陥)を⾒見見つけ出す。 • 2.ソフトウェアの品質を保証する。 • 儲かる
テストのテ 何のためにテストをするのか(目的) • 1.エラー(バグ、⽋欠陥)を⾒見見つけ出す。 • 2.ソフトウェアの品質を保証する。 • 儲かる (→⾚赤字になるならテストは書かない)
テストのテ どのような流れでテストは行われるか (順序) • ソフトウェアテストの順序は 1. 単体テスト 2. 結合テスト 3.
システムテスト 4. 受け⼊入れテスト [選択肢] A. 受け⼊入れテスト B. 単体テスト C. システムテスト D. 結合テスト
テストのテ どのような流れでテストは行われるか (順序) • ソフトウェアテストの順序は 1. 単体テスト
B 2. 結合テスト D 3. システムテスト C 4. 受け⼊入れテスト A [選択肢] A. 受け⼊入れテスト B. 単体テスト C. システムテスト D. 結合テスト
テストのテ どのような流れでテストは行われるか (順序)
テストのテ どのような流れでテストは行われるか (順序) 顧客のやりたいことを 明確化する
テストのテ どのような流れでテストは行われるか (順序) 操作や画⾯面などの 基本的な部分の設計
テストのテ どのような流れでテストは行われるか (順序) 実装に必要な 細かい部分の設計
テストのテ どのような流れでテストは行われるか (順序) コードを書く
テストのテ どのような流れでテストは行われるか (順序) 実装が終わると 対象を⼤大きくしながら テストを進める。
テストのテ どのような流れでテストは行われるか (順序) • 各テストの段階のテスト対象は 単体テスト
→ 結合テスト → システムテスト → 受け⼊入れテスト → [選択肢] A. メソッド(関数) B. 複数モジュール C. 複合システム D. 納品物
テストのテ どのような流れでテストは行われるか (順序) • 各テストの段階のテスト対象は 単体テスト
→ A 結合テスト → B システムテスト → C 受け⼊入れテスト → D [選択肢] A. メソッド(関数) B. 複数モジュール C. 複合システム D. 納品物
テストのテ どのような流れでテストは行われるか (順序) • 単体テスト → メソッド(関数) – 実際の開発では、xUnit系ツールを使う。 – メソッド単位で⾏行行うテスト – メソッドに値を渡し、期待した結果が
返ってくるか確かめる function getMemberAge($id) { $age = $service->getAge($id) return $age; }
テストのテ どのような流れでテストは行われるか (順序) • 結合テスト → 複数のモジュール(メソッド) – 実際の開発では、rspec等のツールを使う。 – 正しくメソッドが結合されているか確かめる
テストのテ どのような流れでテストは行われるか (順序) • システムテスト → 複合システム – 仕様通りに正しく動くかどうか確かめる – 機能だけでなく、パフォーマンスやセキュリ ティなども確かめる
システム
テストのテ どのような流れでテストは行われるか (順序) • 受け⼊入れテスト → 納品物(システム) – テストをするのが発注者(客) – 要望通りの物が納品されたかどうか確認する 納品物
テストのテ どのようなテストがあるのか (種類) • テストの種類は⼤大きく分けて2つある – 機能テスト • ソフトウェアの機能や振る舞いを確かめる – ⾮非機能テスト •
機能以外にも性能や特性などを確かめる
テストのテ • 右の中で⾮非機能 テストに⼊入るのは 単体 [選択肢] A. 負荷テスト B.
ユニットテスト C. インテグレー ションテスト D. パフォーマンス テスト E. セキュリティテ スト どのようなテストがあるのか (種類)
テストのテ • 右の中で⾮非機能 テストに⼊入るのは A.負荷テスト D.パフォーマンステスト E.セキュリティテスト [選択肢] A.
負荷テスト B. ユニットテスト C. インテグレー ションテスト D. パフォーマンス テスト E. セキュリティテ スト どのようなテストがあるのか (種類)
テストのテ どのようなテストがあるのか (種類) • 負荷テスト – 短時間に⾼高い負荷をかけても正常に動作するか テストする • パフォーマンステスト
– 処理理能⼒力力や応答時間などが仕様通りかテストす る • セキュリティテスト – 「悪意のある攻撃」に対し対処できるかテスト する。(この分野は未だテスト⼿手法がない)
テストのテ どうやってテストケースを考えるか(技法) • 演習問題 – 次のプログラムについて、テストケースを 考えて下さい。 • 内容:⼊入⼒力力した三⾓角形の種類を答えるプログラム • 答えるパターン:正三⾓角形、⼆二等辺三⾓角形、普
通の三⾓角形 • 条件:1〜~10の整数のみ受け付ける。 – ※書いていない部分は勝⼿手に想像してOK
テストのテ どうやってテストケースを考えるか(技法) • 答え合わせ lv.1 – 正常系:表⽰示結果確認 • 3辺が同じ⻑⾧長さで「正三⾓角形」と表⽰示 • 2辺のみが同じ⻑⾧長さで「⼆二等辺三⾓角形」と表⽰示
– 3通り実施(5-‐‑‒5-‐‑‒3, 5-‐‑‒3-‐‑‒5, 3-‐‑‒5-‐‑‒5) • 3辺とも違う⻑⾧長さで「普通の三⾓角形」と表⽰示
テストのテ どうやってテストケースを考えるか(技法) • 答え合わせ lv.2 – 異異常系:⼊入⼒力力形式の異異常 • 数値以外の⼊入⼒力力 • 2辺のみ⼊入⼒力力(4辺のみ⼊入⼒力力)
– 異異常系:⼊入⼒力力値の異異常 • それぞれに0を⼊入⼒力力 • それぞれに負の数を⼊入⼒力力 • それぞれに条件より⼤大きい数を⼊入⼒力力
テストのテ どうやってテストケースを考えるか(技法) • 答え合わせ lv.3 – 異異常系:三⾓角形にならない • 2辺の和=残りの1辺 – Ex.)
2,3,5 → 平⾏行行線になる • 2辺の和<残りの1辺 – Ex.) 2,4,8 → 届かない
テストのテ どうやってテストケースを考えるか(技法) • 全部を⼊入⼒力力するわけにはいかない – 10×10×10=1000通り は無理理... • バグのありそうな所を漏漏れなくダブり無 くテストするのがベター。 •
テスト技法について知っておくと便便利利。
テストのテ どうやってテストケースを考えるか(技法) • 同値分割 – 「仕様からデータを“意味のあるグルー プ”(同値クラス)に分類し,各グループか ら代表値を選ぶ⼿手法」
テストのテ どうやってテストケースを考えるか(技法) • 境界値分析 – 「同値クラスの間の境界の値(境界値)を テストデータとして選択する⼿手法」
テストのテ どうやってテストケースを考えるか(技法) • 他にもいろいろ – デシジョンテーブル – 原因結果グラフ →
詳しくは
テストのテ おわりに • まだ調べきれていないこと – アジャイル開発における品質を担保した最 適なテストプランの作り⽅方 – アジャイルテストにおけるTDD,BDDの実践 ⽅方法 • 狩⾕谷さんのwiki読む(『継続的デリバリー』)
• 『実践テスト駆動開発』を読む • 『ドメイン駆動設計』を読む • アプリケーション設計(OOP,デザインパターン)
テストのテ おわり