デバッグの方法を教えてください。経験談等も

質問

会社でデバッグしてと言われています。
デバッグの項目の洗い出し方を教えてください

ホワイトボックステストとかブラックボックステストとか
限界値？境界値テスト等は資格試験の勉強で覚えたつもりです。

具体的にまず何から手おつけてよいのかわかりません
手順とかデバッグのロジック洗い出し方法の
具体的な方法を教えてください。

エクセルか何かに網羅したものを書き出した方がいいのでしょうか

会社にテスト仕様書みたいなものはないとの事です。

また、どうしてもテストデータとかを作るとき正常に
通る簡単なロジックのデータしか作っていないような気がします。
経験不足でテストデータを作るのも一苦労です。
会社で作っているシステム自体よく理解していないので
テストデータを作るのも一苦労です。
ちなみに部署に配属されたばかりの新人です。

回答No.2

KEIS050162 · ベストアンサー

＞エクセルか何かに網羅したものを書き出した方がいいのでしょうか

やはりテスト仕様書はあった方がが良いですね。会社から「ない」と言われたというのはちょっと冷たいですね。自分で作れという意味なのでしょうか。

テスト仕様書を作るということは、そのシステムの仕様が分からないといけないので、逆に言えば、テスト仕様書を作るとシステムが理解出来る、ということになります。

敢えてシステムがバグりそうなデータを与える（即ちホワイトボックステスト）は、中身のロジックが分かっていないと出来ません。
そうでない場合は、ひたすらブラックボックステストを行うことになります。

あまり難しく考えず、また、あまりやみくもにデータを与えるのではなく、システムの挙動を起こさせる各々の項目について、
正常なデータの入力をして正常に期待通りの結果が出ること、
異常なデータを入力して、エラー処理が適切になされること、
を列挙していけば、それがテスト仕様書になります。

大事なことは、システムが異常な振る舞いを起こした時、その振る舞いを起こさせる手順を再現出来るかどうかで、ちゃんとテスト仕様書なり手順書を書いておけば、「テスト仕様書の＃＃番で、手順＃＃番目で　XXXXが起こった」という記録があとでたいへん役に立つはずです。

がんばってくださいね。

回答No.3

kamoz

単純にデバックと言っても、ピンキリです。

というのも、Input となるデータの品質をどこまで信頼できるかという点に
かかっているからです。
たとえば、日付の項目がInputデータとしてあったとします。
極端な話、2月30日というデータがありえるInput なのか？

そんなバカな？　というデータも、ありえるとしてデバックを考えるのか、
それとも、Input として信頼できる項目として、日付チェックはしない。として
ＯＫなのか？

全ては、Input のデータ精度にかかわります。

Inputの品質の前提を見極めて（定義して）仕様書を作成すればいいと思います。

回答No.1

chie65536（@chie65535）

基本は「想定外の事をしてみる」です。

テストデータなども「数値が要求されている部分に、数値じゃない物を入れてみる」とか。

ユーザーインターフェースの部分も同様で「日付を要求する入力に、日付として有り得ない値（１３月３５日、とか）を入れてみる」とか。

このような「要求されている形式と異なる形式を入れてみる」以外に、「何も入れない」とか「形式は合っているけど、限度を超えた長さを入れてみる」とかも有効。

で「きちんとエラー対策してある」ならOKだけど「異常データによってフリーズする」とか「異常データによって後始末をしないで強制終了して不具合が起こる」とかって異常があったら、バグ報告すれば良いでしょう。