Transcript Document

プログラミング／単体試験
について
ハノイ工科大学 ＨＥＤＳＰＩ
ＩＴ日本語 講師： 権代 祥一
1
プログラミング／単体試験の
位置付け(例)
顧客要求
要件定義
外部設計
内部設計
検証
検証
検証
検証
受入試験
運用試験
総合試験
結合試験
プログラミング/単体試験
2
プログラミングの際の注意
• コメントを日本語で書くこと
• コメントを多く入れること
• 何のプログラミング言語でもよ
い。
• 他のマシンでソースコードが
見られること。
3
単体（モジュール）試験
• ホワイトボックス試験
• ブラックボックス試験
を実施する。
4
ホワイトボックス試験
• モジュールの内部構造に着目
して行なう試験のこと
• デバグログを活用すると効率
が上がる。
5
ブラックボックス試験
• モジュールの入力と出力に着
目して行なう試験のこと。
• ドライバやスタブを活用する。
• ドライバやスタブからデバグロ
グを出力して確認すると効率
が上がる。
6
単体試験での指針
• バグ原因の多くは初期化忘れと
資源解放忘れが最も多い。
• バグは動かしたことのないロジッ
クに存在し、確認ミスで見逃され
る。
• 微妙な違いや異変や違和感を無
視せず原因を追求する。
7
結合試験の位置付け(例)
顧客要求
要件定義
外部設計
内部設計
検証
検証
検証
検証
受入試験
運用試験
総合試験
結合試験
プログラミング/単体試験
8
結合試験は・・・
• 内部設計が正しいかどうかを
検証するための試験
• プログラミング工程の時に
結合試験仕様書を作成しておく。
• 内部設計書を元に作成する。
9
結合試験仕様書に何を書くか？
• 試験日、確認日
• 試験カテゴリ（大、中、小項目）
• 試験項目、試験方法、試験デー
タ概要、試験者
• 確認項目、確認方法、確認者
• 試験合否欄
10
結合試験仕様書作成での指針
• 少ないテストで多くの確認をす
るように工夫する。
• 網羅性を高くするように工夫
する。
• 常に５Ｗ１Ｈを意識して書く。
11
結合試験仕様書をどう書くか？
各チームで工夫して
書いてください。
12
バグの潜んでいる場所
• 初めて動かしたロジックに潜
む。
• 試験時の確認ミスに潜む。
• メンバのコミュニケーションミス
に潜む。
• 自分の鈍感さの中に潜む。
13
納品について
•単体試験済みのソースコー
ドをCD-Rなどに焼く（１枚）。
•結合試験仕様書を２部印刷
３月２８日（水）１８：００締切
ＩＴ日本語教員室に提出する
こと。
14
その他の試験仕様書
今後、要件定義書や外部設計書
の検証を行なうので、
• 総合試験仕様書（外部設計の検
証用）
• 運用試験仕様書（要件定義の検
証用）
を作成しておくべきである。
15
•
•
•
•
総合試験仕様書
（外部設計の検証用）
最大値、最大負荷など極端な事象
の確認を書く。
性能の確認について書く。応答時
間や処理速度など。
操作性の確認、誤操作に対するふ
るまいの確認について書く。
例外処理系の試験と確認について
書く。
16
運用試験仕様書
（要件定義の検証用）
• シナリオを作成する。
• 書く場面での操作と出力の確
認事項を書く。
• 全ての運用を網羅できるよう
にシナリオを工夫して書く。
17
障害票（バグ票）の記入と管理
• バグを発見したら、必ず障害票に
記入すること。
• 障害票をプログラムの担当者に渡
す。
• プログラムの担当者がバグの原因
を記入し、修正する。
• バグ発見者がもう一度試験をし、バ
グが無いことを確認する。
18
障害票（バグ票）の監査
• 障害票は後で送りますので、
各チームで管理してください。
• 時々障害票のチェック（監査）
を行います。
• 管理できていないチームは減
点対象とします。
19