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
ソフトウェアテスト第2章
Search
nikawa2161
September 16, 2024
1
3
ソフトウェアテスト第2章
nikawa2161
September 16, 2024
Tweet
Share
More Decks by nikawa2161
See All by nikawa2161
レプリカ遅延
nikawa2161
1
1
vitest
nikawa2161
1
2
ロードテスト
nikawa2161
1
6
Typescriptドメインモデリング
nikawa2161
1
7
ソフトウェアテスト第4章
nikawa2161
1
4
テスト駆動開発の定義
nikawa2161
1
9
ソフトウェアテスト第3章
nikawa2161
1
6
ハッカソン
nikawa2161
1
2.4k
ソフトウェアテスト第1章
nikawa2161
2
6
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
How STYLIGHT went responsive
nonsquared
95
5.2k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
It's Worth the Effort
3n
183
27k
Rails Girls Zürich Keynote
gr2m
94
13k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
Embracing the Ebb and Flow
colly
84
4.5k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Transcript
知識ゼロから学ぶ ソフトウェアテスト 第2章 created by: Ô @nikawa2161 | @nikawa2161 |
✉
[email protected]
This is t-wada
Table of contents ⏪ どんなテスト⼿法が有効か ⏪ プログラムの振る舞いをテストする 制御パステスト法 ⏪ ステートメントカバレッジ
⏪ ブランチカバレッジ
よろしくお願いします
どんなテスト⼿法が有効か
ホワイトボックス 論理構造が正しいかを解析するテスト →プログラムの中にある if ⽂やループの部分がきちんと動作してい るか ブラックボックス 外部から⾒た動作や機能に焦点を当てたテスト →フォームに正しい⼊⼒を⾏った際に、期待した結果が得られるか
ホワイトボックス 論理構造が正しいかを解析するテスト →プログラムの中にある if ⽂やループの部分がきちんと動作してい るか ブラックボックス 外部から⾒た動作や機能に焦点を当てたテスト →フォームに正しい⼊⼒を⾏った際に、期待した結果が得られるか
ホワイトボックステストは 何⼗年にもわたって研究され、ソフトウェアの品質が改善されると証明されている
どのテスト⼿法を適⽤すべきなのか
テストは最⼤公約数的な作業 限られた時間で ·プログラミングは、⼀部の機能を削除することで帳尻を合わせられる ·テストは、ある機能をテストせずに出荷することはできない テストを始める前にテスト⼿法は吟味する必要がある
プログラムの振る舞いを テストする
制御パステスト プログラムがどのような振る舞いをして、どのように制御、実⾏されるかをテスト テスト⼿法の中でも基礎的かつ必須のテスト 網羅率の値を取るために利⽤される
事例 ファイナルファンタジー 以下の条件が重なった時にバグになった 「トラビア渓⾕」をクリア 1. 1の後に「セントラ遺跡」での制限付きイベントに臨む 2. 戦闘中に制限時間に達し、 「やめる·ゲームオーバー」を選ばない 3.
フローチャートにすると複雑ではない 制御パステストの本質は、このようなフローチャートをカバーする ことにある
ステートメントカバレッジ 制御パステスト
ステートメントカバレッジ 命令⽂を少なくとも⼀回は実⾏するテスト ①②のステートメント(命令⽂)を対処する if (const1 == 0) { x =
x + 1; //① } if (const2 > 1) { x = x * 1; //② }
ňテスト結果 bのテストができている cのテストができている dのテストができている eのテストができている コード内でconst2 > 0と記述した場合に、バグを⾒つけられない
⾮常に弱いテスト 分岐条件などのカバーできない部分をどうするか
ブランチカバレッジ 制御パステスト
ブランチカバレッジテスト 分岐コードに対してそれぞれの判定条件が True,Flaseの結果を少なくとも⼀回ずつ持つようにする
const1 = 0 と const2 = 2 const1 = 1
と const2 = 1 ňテスト結果 bのテストができている cのテストができている dのテストができている eのテストができている
ブランチカバレッジは網羅という意味では、ステートメントカバレッジより強い テストケースが増えるのが難点 ただ、ステートメントカバレッジだけでテスト終了することは⾮常に危険 バグの多くは、分岐点や例外処理にある
次回
カバレッジ基準
⽬黒エクスタシー