1.仕様書の通りデータが変換されるか否かをチェックする。
2.仕様書で想定していないデータを入力し、システムダウンしないか否かを検証する。
3.初期設計等ユーザー側が提示した内容で、リスク回避をしなければならない事項を明確にし、当該リスク回避がシステム上機能するか否かを確認する。
大体この程度で検証し、残りはバグとしてその都度検証ですね。
・まずは、コンパイラーのエラーチェック。プログラムが文法的に正しいかどうか
・次に、試験を行って、自分がこう作ったつもり通りの動作をするかどうかを確認
基本はこの2種類です。
それに加えて
・他人にプログラムを見てもらって、「こう作ったつもり(仕様の実装)」がそもそも間違っていないかなどをチェック
なんてことも行います。
昔、PGをやっておりましたが、エラーチェックは、最終的には、全部をみる!しかないとおもいます。
あと、他の人に見てもらうと、比較的簡単に見つかりますが、みんな忙しくって、なかなか見てもらえなかったな・・・。
・画面から遷移するすべてのパターン試験
・入力個所の場合は、でたらめな入力をする。
・LANなど用いるものは、実行中に LANケーブルを抜いたりする。
・保存する場合は、保存先の容量を少なくする。
・IntegerやLongの型の限界の値となることがあるのかテストする。
・連打する。
PGって何ですか?
一応文脈からプログラム と仮定します。
とりあえずコンパイルは通る(言語仕様としてはとりあえず解釈できる)状況の話をします。
プログラム検査手法としては、限界値テストを行ないます。
仕様として許される入力の限界値を超えるもの、あるいはぎりぎりのものを入力して正常な出力がされるかを検定します。
基本的には小構造から検査していって、検査済みの小構造をもとにより大きな構造の検査をします。
GUIアプリや大規模アプリなどではどうしようもないので、そこそこのテストが済んだら人に渡してバグレポートさせます。
Microsoftなんかもそういう開発手法ですよね。
1.仕様書の通りデータが変換されるか否かをチェックする。
2.仕様書で想定していないデータを入力し、システムダウンしないか否かを検証する。
3.初期設計等ユーザー側が提示した内容で、リスク回避をしなければならない事項を明確にし、当該リスク回避がシステム上機能するか否かを確認する。
大体この程度で検証し、残りはバグとしてその都度検証ですね。
コメント(0件)