- ベストアンサー
デバッグ方法と手順の具体的なロジック洗い出し方法
- デバッグの方法や手順について、経験談を含めて教えてください。ホワイトボックステストとブラックボックステスト、限界値テストなどの考え方を活用して、具体的な方法をご教示いただけると助かります。
- デバッグにおいて、どのように手をつけるか具体的な方法がわからない状況です。デバッグのロジックを洗い出す手順や方法を詳しく教えていただけると助かります。エクセルや他のツールを使って洗い出した内容をまとめることが良いアプローチなのかも教えていただけると幸いです。
- デバッグにおいて、まず何から始めれば良いかわからないという状況です。具体的な手順やロジック洗い出し方法を教えていただけると有難いです。また、新人であり、会社のシステムやテストデータの作成にも慣れていないため、経験不足を補う方法についてもアドバイスいただければ幸いです。
- tkwavek
- お礼率11% (103/930)
- SE・インフラ・Webエンジニア
- 回答数3
- ありがとう数1
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
＞エクセルか何かに網羅したものを書き出した方がいいのでしょうか やはりテスト仕様書はあった方がが良いですね。会社から「ない」と言われたというのはちょっと冷たいですね。自分で作れという意味なのでしょうか。 テスト仕様書を作るということは、そのシステムの仕様が分からないといけないので、逆に言えば、テスト仕様書を作るとシステムが理解出来る、ということになります。 敢えてシステムがバグりそうなデータを与える（即ちホワイトボックステスト）は、中身のロジックが分かっていないと出来ません。 そうでない場合は、ひたすらブラックボックステストを行うことになります。 あまり難しく考えず、また、あまりやみくもにデータを与えるのではなく、システムの挙動を起こさせる各々の項目について、 正常なデータの入力をして正常に期待通りの結果が出ること、 異常なデータを入力して、エラー処理が適切になされること、 を列挙していけば、それがテスト仕様書になります。 大事なことは、システムが異常な振る舞いを起こした時、その振る舞いを起こさせる手順を再現出来るかどうかで、ちゃんとテスト仕様書なり手順書を書いておけば、「テスト仕様書の＃＃番で、手順＃＃番目で XXXXが起こった」という記録があとでたいへん役に立つはずです。 がんばってくださいね。
その他の回答 (2)
- kamoz
- ベストアンサー率22% (2/9)
単純にデバックと言っても、ピンキリです。 というのも、Input となるデータの品質をどこまで信頼できるかという点に かかっているからです。 たとえば、日付の項目がInputデータとしてあったとします。 極端な話、2月30日というデータがありえるInput なのか？ そんなバカな？ というデータも、ありえるとしてデバックを考えるのか、 それとも、Input として信頼できる項目として、日付チェックはしない。として ＯＫなのか？ 全ては、Input のデータ精度にかかわります。 Inputの品質の前提を見極めて（定義して）仕様書を作成すればいいと思います。
- chie65536（@chie65535）
- ベストアンサー率44% (8742/19841)
基本は「想定外の事をしてみる」です。 テストデータなども「数値が要求されている部分に、数値じゃない物を入れてみる」とか。 ユーザーインターフェースの部分も同様で「日付を要求する入力に、日付として有り得ない値（１３月３５日、とか）を入れてみる」とか。 このような「要求されている形式と異なる形式を入れてみる」以外に、「何も入れない」とか「形式は合っているけど、限度を超えた長さを入れてみる」とかも有効。 で「きちんとエラー対策してある」ならOKだけど「異常データによってフリーズする」とか「異常データによって後始末をしないで強制終了して不具合が起こる」とかって異常があったら、バグ報告すれば良いでしょう。
