バグの確認って

質問

通常、作成したプログラムなどの動作確認というのはどのような方法で行うとほぼ誤りが０になるものですか？
PerlとPHPを独学で学びましたが、プログラム稼働後、思いもよらないミスが見つかったり、動きが正確に動いていなかったり、となかなか自分では全てのデバックをしきれず、苦慮しています。
全てのパタンを網羅、ができるときはよいのですが、それが100通り、200通りとなってくると、、、結局見逃してしまったり、、、
皆さんのコツやアドバイスがありましたら教えてください。

回答No.2

don_go · ベストアンサー

＞それが100通り、200通りとなってくると、、、
100通り、200通り・・・それが例え10000通りであろうと
20000通りであろうと全てのパターンをチェックするのが
業務システムの開発では当り前の事です。
＃コーディング自体よりデバッグの方に、より多くの時間
＃をかけます。

＞皆さんのコツやアドバイスがありましたら教えてください。
デバッグを行う前にチェックする項目と予想される結果の
一覧リストを作成しておくこと。
またテストの手順は予め、ちゃんと決めておくこと。
＃いきあたりばったりではデバッグの効果は薄くなります。

お礼

御礼遅くなりました。
>100通り、200通り・・・それが例え10000通りであろうと
>20000通りであろうと全てのパターンをチェックするのが
>業務システムの開発では当り前の事です。
そうですよね。耳が痛いです・・・

>一覧リストを作成しておくこと。
>またテストの手順は予め、ちゃんと決めておくこと。
これはすぐにも対応できます。
確かにいきあたりばったりでやっていると、前にやったかもしれないことをもう一度やってみたり、やってないことが残ってしまったり、結局時間がかかってしまいますよね。
きちんとリスト化することで整理もできると思うので早速取り入れます。

回答No.6

choconamacream

先日も以下のような質問が、他のカテにてされていました。とりあえず紹介。

バグがない・・・本来、それが普通なの？
http://oshiete1.goo.ne.jp/qa3228987.html

ここからは、さらに踏み込んでグローバルな観点から回答を試みる。

まず始めに、公式サイト。

JSTQB
TOP ＞ シラバス（学習事項）・用語集
http://www.jstqb.jp/syllabus.html

上記のサイトから今だと、「ISTQBテスト技術者資格制度 Foundation Levelシラバス日本語版Ver.1.0.1 (Ver.2005)」のpdfファイルが落とせると思います。このシラバスの３５ページにも書かれてある通り、一般的にテスト設計技法というのは以下の３つに大別できます。

（１）仕様ベース、ブラックボックスのテスト技法（同値分割法や境界値分析など。）
（２）構造ベース、ホワイトボックスのテスト技法（命令網羅や条件網羅など。）
（３）経験ベースのテスト技法（エラー推測、探索的テストなど。）

それと、同様に上記シラバスの３０ページでは、「欠陥の検出」という同じ目的のテスト技法として、以下の３つを挙げています。

・レビュー（仕様書の内容を、関係者でチェックしてコメント。）
・静的解析（対象ソフトウェアを、実行せずにツールで分析。）
・動的テスト（テスト対象のソフトウェアを実行して確認。）

PMの資格も実務経験も全くないのであんまり大それたことは言えませんが、対策としては恐らくコストをどれだけ掛けれるかによって異なってくると思われます。

（a）多少、コストが高くなってもいい場合
→同様のシステムでのテスト経験者を新たに雇って、エラー推測や探索的テストを行ってもらう。

（b）コストを出来るだけ抑えたい場合
→レビューを出来るだけ早く実施して、事前報告に徹する。

お礼

御礼遅くなり申し訳ございません。
大変分かりやすいご丁寧な回答をありがとうございます。
どこまでコストをかけられるかは案件によって異なりますが、全くの他者にテストをしてもらう、という考えは思いついたことがありませんでした。
まず資料を参考にさせていただきます。
ありがとうございました。

回答No.5

W_H

バグの確認で誤りがゼロというのは、ほぼないと思ったほうがいいと思います。
プログラムはいつまでも試行段階。完璧なんてないというのが普通ですから。
一応ぼくの方法は、例えば掲示板のようなものであれば、書き込みができる正規の半角英数データを入れて、動作確認。次に全角文字で動作確認。次に項目を順番に入力せずに動作確認し、ここでエラー処置の仕方を見る。そして仕上げにエラーになるであろうデータを、わざと入れて動作確認をします。
と、まぁ、とにかく上のように攻撃を仕掛けまくります。たまにアドレスをいじって、故意にありもしないデータを送ったりとかもするときがあります。とにかく、プログラムがどんなデータをどのように処理するか、いろいろしなければいけませんね。

ただ、それよりもバグが起こりにくいプログラムを書いたほうがいいと思います。
例えば、よく使う処理を関数にして重複を防ぎ、ごちゃごちゃする処理も関数にして、一つ一つの流れが見えやすくしたり、if文には必ずelseをいれ、そこにはどのパターンにも当てはまらない、処理できないデータが行くようにする、などの工夫措置を加える方がいいと思います。（つまり、予測範囲内のデータはすべて条件式に記す。elseを残った処理の場合に当てない。）
大体バグは見えにくい、分かりにくいコードに多いので、見易さ、理解しやすさを意識すれば、多分バグも減るのではと思います。デバッグも楽になりますし。

最後に、ユーザーは最高のテスターと誰かが言いました。プログラムの構造を知る人間がいくら実験したところで、何も知らないユーザーがプログラマーでさえ見落としていたバグを見つけます。なぜなら、ユーザーには先入観（データと内部処理の関係）がないからです。なので、自分がユーザーとしてプログラムを使う。もしくは協力者に使ってもらうのが、一番楽なバグの確認法だと思います。人間、先入観が多い生き物ですから。

お礼

御礼遅くなり申し訳ございません。
具体的な方法をご教示頂き大変ありがとうございます。
わたしも大変な先入観の持ち主で、いつもどこかで自分が作ったから間違いない、、とかたくなに信じちゃっています。
それでは見つけられないですよね。
見やすさ、理解しやすさを意識したプログラムが作れるよう、勉強もしていきたいと思います。
ありがとうございました。

回答No.4

zwi

経験則で言える事は、まめにテストすることですかね。
・機能単位・関数単位の試験を作成中にキッチリと行う。
全体が出来てから一気にテストしようとしない事。
・各機能・各関数のテストが合格したら全体の機能の試験を行う。
・機能単位・関数単位の試験で条件分岐の閾値試験を行う。
・全体の機能の試験試験項目の一覧を作成してテストを行う。
異常値・例外値の動作試験の項目を必ず盛り込むこと。

それとソースコード自体にバグを発見する工夫をすることです。
・例外値で異常動作しないように必ずガードを掛けておく。
switch～caseのdefaultやif～elsifならelseなどを省略せずに必ずエラーとして表示するように書くと異常動作していていも気づかない場合をあるていど防ぐことが出来ます。
・関数のパラメータも想定外の値をガードする。
あんまりやりすぎると動作が重くなるので、テスト時だけ有効にするなどの工夫が必要。

お礼

御礼遅くなり申し訳ございません。
>例外値で異常動作しないように必ずガードを掛けておく。
これはぜひ取り入れてみようと思います。
例外値でなんどかひどい思いをしました。。。
ありがとうございました。

回答No.3

lv4u

>>PerlとPHPを独学で学びましたが、プログラム稼働後、思いもよらないミスが見つかったり、動きが正確に動いていなかったり、となかなか自分では全てのデバックをしきれず、苦慮しています。

バグって、他人が結果を見れば「ここ明白にエラーじゃないか！」と、一目瞭然の見落としから、最近では原発耐震設計でもありましたが「想定外！」っていうような、そういうケースがあるって設計時点で「聞いてないよ！」というものまでありますからね。（原発の場合は、聞こえていたけど、真面目にやったら原発建設が不可になるのが見えていたから、３０年以上も昔から知らんぷりするのがお約束だったようですが・・・まあ、いいかげんですね）

アメリカで大陸間弾道弾の防衛システムが始めて稼動したとき、敵味方識別信号に応答しないので、「ミサイル攻撃！」って、のぼり来る「月」に対して迎撃体制に入ったとかね。ユーザからすれば、明らかにバグだけど、プログラマにとっては、これは「バグじゃない！！」って言いたいものまでイロイロあります。

さし当たっては、「一晩寝て頭すっきりして、他人の目で結果を見る」とバグが一目瞭然に判明ってことあります。

>>全てのパタンを網羅、ができるときはよいのですが、それが100通り、200通りとなってくると、、、結局見逃してしまったり、、、

そのとおりです。小さなプログラムでも全てのケースをカバーしようと、「徹底的経路テスト」でテストケースを作成すると、１００通り、２００通りじゃあなく、１００兆にもなったりして、数千回も転生輪廻してテスト人生をおくっても完了しないとかね。

>>皆さんのコツやアドバイスがありましたら教えてください。

まじめにテストを考えると、テストケースの設計って、とても難しいのです。この分野では,Glenford J.Myers氏の著作がとても参考になります。同氏の「ソフトウエアの信頼性」「高信頼性ソフトウエア」や「ソフトウェアテストの技法（第二版）」（いずれも近代科学社）などを読まれるといいと思います。

ただ、もっと簡単で直感的なやり方は、「テストが不可能と思えるような複雑な（大きな）プログラム単位でテストをしない（作らない）」ってことですね。テスト単位が小さな関数になるように設計すれば、比較的綿密なテストケースの設計をやっても、ケース数の爆発的増大には、ならないでしょうから。

テストの計画って、単純にマニュアルに沿ってチェックするってのじゃあなく、あらゆるケースを想像しないといけないという創造的で大変な仕事なんです。

お礼

御礼遅くなり申し訳ございません。
>テストが不可能と思えるような複雑な（大きな）プログラム単位でテ
>ストをしない（作らない）
そうですね。まず作る時に極力簡素化するといいのですね。
超初心者の私はどうしても力技でチェックどころ満載のプログラムしか書けません。。。
しっかり勉強してチェックもしやすいプログラム作りに努めたいと思います。

回答No.1

noname#39970

http://www.google.co.jp/search?q=%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%20%E5%8B%95%E4%BD%9C%E6%A4%9C%E8%A8%BC%E6%8A%80%E8%A1%93&hl=ja&lr=lang_ja

お礼

御礼遅くなりました。
参考URLありがとうございました。
参考にさせていただきます。