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
4
difit
nikawa2161
0
7
フロントのキャッシュ
nikawa2161
0
4
Dia
nikawa2161
0
2
LLMを拡張機能に
nikawa2161
0
9
経営戦略(人生)
nikawa2161
0
8
コンポーネントとレンダー
nikawa2161
0
4
cursor
nikawa2161
0
6
llm.pdf
nikawa2161
0
4
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
GitHub's CSS Performance
jonrohan
1032
460k
A Tale of Four Properties
chriscoyier
160
23k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Building Applications with DynamoDB
mza
96
6.6k
Git: the NoSQL Database
bkeepers
PRO
431
66k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
Site-Speed That Sticks
csswizardry
10
800
Scaling GitHub
holman
463
140k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
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のテストができている
ブランチカバレッジは網羅という意味では、ステートメントカバレッジより強い テストケースが増えるのが難点 ただ、ステートメントカバレッジだけでテスト終了することは⾮常に危険 バグの多くは、分岐点や例外処理にある
次回
カバレッジ基準
⽬黒エクスタシー