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
2
4.9k
ソフトウェアテスト第2章
nikawa2161
September 16, 2024
Tweet
Share
More Decks by nikawa2161
See All by nikawa2161
error-marp.pdf
nikawa2161
0
1
difit
nikawa2161
0
2
フロントのキャッシュ
nikawa2161
0
4
Dia
nikawa2161
0
2
LLMを拡張機能に
nikawa2161
0
7
経営戦略(人生)
nikawa2161
0
7
コンポーネントとレンダー
nikawa2161
0
4
cursor
nikawa2161
0
6
llm.pdf
nikawa2161
0
4
Featured
See All Featured
Practical Orchestrator
shlominoach
190
11k
Become a Pro
speakerdeck
PRO
29
5.5k
4 Signs Your Business is Dying
shpigford
184
22k
Music & Morning Musume
bryan
46
6.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Balancing Empowerment & Direction
lara
1
530
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Six Lessons from altMBA
skipperchong
28
3.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Building Applications with DynamoDB
mza
95
6.5k
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のテストができている
ブランチカバレッジは網羅という意味では、ステートメントカバレッジより強い テストケースが増えるのが難点 ただ、ステートメントカバレッジだけでテスト終了することは⾮常に危険 バグの多くは、分岐点や例外処理にある
次回
カバレッジ基準
⽬黒エクスタシー