バグなしのプログラムって本当に作れるの？
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGスペルミス、異常処理、タイミングなどを考えると全てのチェックはできないと思う。
何かいい方法でもある？
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNG組み合わせにバグがあったら？
0004デフォルトの名無しさん
NGNGそれを組み合わせればバグといえるバグは無くなるかと。
なお、予想外の事象が起こった場合、強制終了か、または正常に動く様に
処理をするよう数値を変えてしまうとか。
バグってのは結局のところ、予定外の行動や対処がしっかりとされていなかったために、
プログラムがあらぬ処理をしてしまうことで起こるかと。
0005デフォルトの名無しさん
NGNG組み合わせた奴がバカなだけ。
0006デフォルトの名無しさん
NGNG数行のプログラムでバグの無いプログラムを作る事は簡単だが、
数万行のプログラムでバグの無いプログラムを作る事は難しい。
だが、日頃の節制により病気になりにくい体を作る事は可能であり、
日頃の修練によりバグの出にくいプログラムを作る事は可能である。
0007デフォルトの名無しさん
NGNGOSも自分で書けばよいが、
残念ながら、BIOSにバグがある。
BIOSも自分で書けばよいが、
残念ながらCPUにバグがある。
0008デフォルトの名無しさん
NGNGその数が爆発すれば管理不能になるのは事実上当然。
なので逆にいえば、爆発をいかに抑えるか？が味噌のはず。
バグを皆無にする(それは無理だと思うが)のを目指すにせよ、
バグを少なくするのを目指すにせよ。
ーーーーー
XPじゃないが、単体テストっていう考え方は美味しいよね。
つーかXPが美味しいのは、単体テストとTestFirst
(テスト手順をプログラムより「先に」作る)を
常に組み合わせろっていう所か。
なにかってーと、単体でテストを通すことで
複合体となった後の組み合わせの爆発に
関わらずに済むってのと、
プログラムより先にTest手順を作るってことは、
最大の爆発である「プログラムの実装」ってものを
回避しちまう(笑)ことになるわけで。
仕様(実装ではなく)すなわちテスト手順と連動するようにして、
仕様を守っているかどうか？を個別にテストする。
だから例えば、仕様範囲内の数字だけをテストすりゃ良いわけだ(笑)
00091
NGNGまず、あらゆる数値に対して必ず完璧な処理をこなすプログラムを作るのが
結構大変だったりして・・・^^;
仮に出来たとしても、予定外の行動や対処についてはその通りかも知れませんが、
予想外の処理に対しての処理は予想できないので正しく動作するようにするのは
難しいのでは？
シュミレーションと言う手もあるけど完全とはいかないし・・・
まずはあらゆる数値に対して必ず完璧な処理をこなすプログラムを作ることから
だとは思うのですが、これもどうやって作ります？
0010デフォルトの名無しさん
NGNG「このプログラムの難易度はＡクラスだから必ずテストでは
ｎ件のバグを出さなければならない。そしてそのｎ件のバグ
が出なかったら、テスト不足として厳しく糾弾する」
という恐ろしいやり方も現実にあるよ。
そのｎ件を超えたバグを出すと、本人の能力不足として
これまた糾弾。
要するにクビにしたいのかねぇ
0011デフォルトの名無しさん
NGNG001210
NGNG件数を190件と設定された。しかし、それよりずっと少ないバグ
しか検出されず、本番稼動の日まで、他の仕事の傍ら、テスト
不足だのなんだの厳しい追及を受けた。
そして、本番後、バグは一切出なかった。
それまで追求していたヤツは、涼しい顔。
そんなもんです。
00131
NGNG私もバグ０は出来ないと考えてはいます。
（そう思ったんでスレ立てたんですけど・・・）
たしかに少なくすることは出来そうですね。
テストを先に作るのは想定外を無くす上でも重要なことかもしれません。
（ところでＸＰって何？^^;）
ただ、仕様のレベルって細かいものから大雑把なものまであるので、
仕様範囲内の数値を出すのも結構大変かと・・・
バグと仕様は紙一重？
0014デフォルトの名無しさん
NGNGだから、プログラムの全パターン試験、全ての使い方
を想定したシナリオ試験、本番環境を仮に作り、実際
の運用を行いながらバクを検出する試験など、何段階
もの試験を経てリリースされる大型プログラムもある。
半年スパンとかの汎用機のプログラムなどはそういう
感じかな。
バグが出ようものなら、出した会社の代表者を顧客が
取り囲み、裁判さながらの大問題に発展。
バグを出したら即死。だから肝臓を壊しながら、血の
しょんべん出しながらテストに命を削る人もいる。
バグは出なくて当たり前。出したら恥と思って覚悟しろ。
これがこれからの常識になる。
0015デフォルトの名無しさん
NGNG今は、顧客の人が自分でプログラムを組むのも珍しく
ない時代。下手すりゃ、顧客の人に負ける場面もある
のじゃないか？
Excel + VBAとかを馬鹿にしてＣ++の知識を誇るのも
いい。
だが、あなたは顧客が作る以上のExcel + VBAを操れる
だろうか。聞かれて「知りません」と答えるしかないの
だろうか。
今、職業プログラマに求められる知識は幅広く、ほんの
些細な知識不足から「たいしたことねーーーな。帰れ」
と心の中で思われるだろう。
くれぐれも、精進してくれたまえ。
0016デフォルトの名無しさん
NGNGおれまえに血のしょんべんだしたよ…
０に収束はしていくけれど、０にはならないよね。
0017デフォルトの名無しさん
NGNGだが、月日が立つとバグが仕様に変わってしまう・・・
00181
NGNG確かにテストを大量にやればバグを少なくする（無くなる？）ことが
できると思うのですが、実際の開発では出荷を早めるために十分に
テストできないのも事実です。
（最近の携帯電話なんかそう思う->発売してすぐにバグで回収）
問題はいかに効率よくテストするかなんですけどこれがまた結構大変。
設計時に出来るだけ問題をなくしてテストの量を減らすみたいなことが
言われているけど、実際どうなんでしょう？
0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNGその話題出たのどこのスレだっけ？
馬鹿げているよね、ということで意見の一致(笑)を見たはず。
どう考えても変なやりかただもの、それって。
＃まぢにそれで有効だと思っているんだろうか？＞該当阿呆会社
0021デフォルトの名無しさん
NGNGそれも無茶。無茶というのは、それを実践すると、
担当者の人権を激しく阻害(笑)する割には
バグがたいして取れないので。
裁判ごっこなんぼやっても取れないものは取れないんだから、
取るプロセスを改善しないと全く無意味。
懲罰は悪人を減らすことは有るかも知れないが、
過失者を減らすことは出来ないっしょ。
スパイラルだのXPだのでも言われていることだけど、
要するに客を「お客さん」のままにしている限り
向上は無理なんだろうと思う。
お客も開発に引きずり込むというスタイルが良い
(んじゃないか)と最近は言われているね。
で、引きずり込んで何する(させる)かってーと、
細かい部分の開発＆テストを客に直接見せて、
「これでオッケーですよね」とオッケーを取る…のかな？(笑)
つまり、お客にもまた(開発と同じで)王道は無いってことなんじゃないかと。
>>18
「設計時に問題をなくして」というより
「設計時の問題がアラワになりやすいようにして」っすな、
おそらく有効なのは。
0022デフォルトの名無しさん
NGNGやつだったっけ？
0023デフォルトの名無しさん
NGNG>その話題出たのどこのスレだっけ？
>馬鹿げているよね、ということで意見の一致(笑)を見たはず。
どのスレか俺も忘れたが、意見の一致はしていないぞ。
テスト工程の妥当性を客観的に判断する基準として、期待される
バグ数を算出し、それと実際のバグ数を比較するのは、最も
良い、とは言えないが、それなりに意味のある方法だ。
それを「馬鹿げている」というなら、それに代わる方法を提示
しなければならない。
「テスト終わりました〜。○行あたり１件のテストをやりました〜。
バグはなくなりました〜」（ちょっと恣意的か）
では、誰も納得しない。
問題なのは、「バグ数の期待値の算出方法」と「評価方法」なのだ。
0024デフォルトの名無しさん
NGNG馬鹿にされている統計手法も意味のあるものになってくる。
個人ベースで「お前はバグ件数が少ないから、テストが足りない」
と決め付けるのはおろかだが、それをもって、この統計手法が
全く意味の無い、馬鹿げたものだと一蹴するのは早計だろう。
0025デフォルトの名無しさん
NGNG>バスタブ曲線って一旦収束したあと再びバグが増えるって
>やつだったっけ？
「バスタブ曲線」と言われてピンとこない人もいると思う。
だが、情報処理試験の勉強をしたものなら知ってるはずだ。
情報処理試験は、このように「同じドメインで話が出来る」
土壌ともなるのだ。
0026デフォルトの名無しさん
NGNG説教ｸｾｰｿﾞ｡ﾅﾝｶ、ﾑｶｼｸ｡
0027デフォルトの名無しさん
NGNGうちでは、横軸に日付、縦軸にバグ件数というグラフで、
バグ件数の期待値とバグ検出数の累計をプロットしているので、
どうやってもバスタブ型にはならない。
みんなの所はどんなグラフ書いてるんですか？
0028デフォルトの名無しさん
NGNG>>23
>問題なのは、「バグ数の期待値の算出方法」と「評価方法」なのだ。
だからさ、バグの数を期待値で計ることの価値は？
>テスト工程の妥当性を客観的に判断する基準として、
客観的な「だけ」で、基準としての必要条件を
満たすわけでもないでしょう。
たかが客観的なだけで、その基準が
(採用するに十分なほど)妥当だと言えるの？
>期待される
>バグ数を算出し、それと実際のバグ数を比較するのは、最も
>良い、とは言えないが、それなりに意味のある方法だ。
そうか？「的外れ」って言葉知っているか？
期待値を使うことが的外れかどうかを「まず」検証してから
その発言を言っているか？なんでも提示すれば良いってもんじゃないぞ？
>それを「馬鹿げている」というなら、それに代わる方法を提示
>しなければならない。
そんな無茶な。
代替案が無かったらゴミで見切り発進しろっての？
あーゆー使えない案を臆面もなく使いつづける奴ってのは、
つまり自分の馬鹿さ(=より良い手を用意できなかった)から
目をそむけてるだけだよ。
「説教くさい」って感想は、直接は正しくないかも知れないけど、
直感レベルではイイセンだと思われる。
説教くささを感じるときってのはつまり、説教が的外れなとき
なんだよな(笑)
それはさておき。 XPってよさそうだよね。
＃って俺もその良さをまだ検証(笑)してないんだから駄目駄目だが。
少なくとも、バグを「数」で捉えるなんて馬鹿はしてない。
「正しい動作はコレである」という定義を積み重ね、
それを直接テストに焼きこむから、そのテストに合格
するかどうか？をもってバグかどうかの必要十分判定を
するわけだ。つまり、バグの数なんてものは、
仕様の数つーかテストの数(笑)から結果的に生まれるだけのものに
すぎないわけよ。
な？少なくともアッチよりは遥かにマシな考えかただろ？
0029デフォルトの名無しさん
NGNG>それに、プログラマが数十人以上の規模になってくると、
>馬鹿にされている統計手法も意味のあるものになってくる。
ところで、統計的手法ということは、その結果得られる情報を
決定論的に使うことは、そもそもナンセンスだよね？
というわけで、個々のプログラマや外注企業に対して、
「バグの期待数を満たしてないから却下」とヤルのは
ナンセンスってことなわけだ。
でも、情報を個々に対して還元(つまり時として却下)しないと、
プログラムってものの性質上、そもそも手法を使う意味がない。
還元できない情報を還元しようとしてるわけだ。
変でない？
0030デフォルトの名無しさん
NGNGそして、現実的にはバグ無しのプログラムは不可能だから
バグの出にくい設計／プログラム方法と
バグの出しやすいテスト方法を語り合いたいな。
内容が無くてスマン。
003123-25
NGNG・・・という意見もある、という風に受け取って下さい。
でも、「テスト工程がきちんと終了した」ことを、客観的に判断できる
基準というのは必要だとは思いませんか？
今の所、件の統計的手法以外には思いつかない。
あったら、是非教えて欲しい。
*
XPは、個人的に取り入れてるので、UnitTestのありがたさは
良く判る。
ただ、これがうまくいってるのは、少人数で小さな短期間の
システムをやってるからだとも思う。
しかも、自分が作ったUnitTestのコードは正しい、と思って
いるし。
これが、10人ほどのプロジェクトになり、ペアプログラミングが
出来ない場合（有効性が良く判らないので、どこでも導入に
躊躇されると思われる）、他人のUnitTestが正しく、抜けが
無いことをどうやって知ればいいのだろうか。
プログラマが100人とか、そういうプロジェクトではファウラーも
言ってるようにXPはなじまない。
そういう場合に、統計的手法が生きてくると思うのだが、どうだろう？
0032デフォルトの名無しさん
NGNGそんなの開発側の勝手な言い分。
バグなんて無くて当然！
そう考える顧客は増えているよ。
IT革命(笑)で、我々の常識なんか
通用しない時代になる感触。
0033デフォルトの名無しさん
NGNGってゆうか厨房は以前より増えている。
003423-25
NGNGステップ数で（というのもアレなんだが）合計200Kステップの
コードがあるとする。
で、単体テスト工程が終わって、
「テスト項目数は2000件、バグは100件でした」
という報告を受けたとする。
さて、この場合、このテスト工程はうまくいったのだろうか？
*
あ、それからさっき書き忘れたんだけど、XPが有効なのは
UnitTestまでで、結合テスト以降はまた別のテスト方法を
取らないといけない、と俺は理解してるけど、それで正しい？
0035デフォルトの名無しさん
NGNGって考えを世間に定着させたMSﾏﾝｾｰ！
て意見がどこかにあったよね
003623-25
NGNG・まず、完成したコードに、故意にバグを埋め込む。
・元コードとのdiffは禁止する（ｗ
・埋め込んだバグがいくつ発見されるかを調べる。
もちろん、全てが発見されなければテスト完にならないのは
言うまでも無い。
さっきの例で行くと、1Kステップあたり1個のバグを埋め込めば、
進捗状況は、(発見数/200) で計算できる。
この手法に名前が付いているかどうかは知らない。
何かの書籍か、雑誌か、Webかで読んだものです。
もちろん、そんなうざいことは、俺はしたことありません。
0037デフォルトの名無しさん
NGNG>・まず、完成したコードに、故意にバグを埋め込む。
>・元コードとのdiffは禁止する（ｗ
それは、そのバグ取り職人の、
「統計的(笑)な」バグ発見能力を
計っているにすぎないと思うのだが。
つまりだ。そのテストで好成績を出しても、
明日の本番テストで「全部」のバグを
取れる保証は無いわけで。
そーゆーことをやらないための、XPのあの手法
なのだと思うが。
具体的にいえば、ツールを使うことを否定しているのが、
上記の手法の致命的欠点だと思う。
XPはそれどころかバグ取りツールの自作すら
させるわけじゃん(笑)。彼我の差は大きいと思う。
ところで。
よしんば統計手法で良いとしても、
それこそ係数を出す方法が問題だな。
少なくとも行数なんてゴミつーか
逆効果ですらある恐れがないか？
0038デフォルトの名無しさん
NGNG> 「テスト項目数は2000件、バグは100件でした」
> という報告を受けたとする。
> さて、この場合、このテスト工程はうまくいったのだろうか？
その日毎のバグ件数をグラフに表し、
上昇しつづけているようならば、まだ続ける必要がある。
下降しているようならば、そろそろ収束する。
003923-25
NGNG>それは、そのバグ取り職人の、
>「統計的(笑)な」バグ発見能力を
>計っているにすぎないと思うのだが。
いえ、そうじゃありません。
元々全部のバグがいくつあるかは関係なく、例えは埋め込んだ
バグのうち50個見つけた段階で、全体の25%の進捗があった、
とするわけです。
ここには係数も、統計的手法も出てきません。
また、200個全部見つかったことをもって、テスト工程が妥当で
あったことの、「一応」の保証とするわけです。
元々あったバグ全てを見つけたという保証ではありません。
>>31
>でも、「テスト工程がきちんと終了した」ことを、客観的に判断できる
>基準というのは必要だとは思いませんか？
のひとつの例としてあげました。
>つまりだ。そのテストで好成績を出しても、
>明日の本番テストで「全部」のバグを
>取れる保証は無いわけで。
もちろんそうですが、テスト担当者の「できました宣言」を何の根拠
もなく信用するよりは、ましです。
何度も言ってますが、
・テスト工程は終わったのか、まだなのか。
・テスト内容は妥当なものだったのか、そうでないのか。
ということを、なるべく管理工数をかけずに知る手段なんですね。
0040デフォルトの名無しさん
NGNG> つまりだ。そのテストで好成績を出しても、
> 明日の本番テストで「全部」のバグを
> 取れる保証は無いわけで。
ＸＰでも「全部」のバグを取れる保証は無い。
つーか、「全部」のバグを取れる保証がある方法があれば
土下座してでも、いくらお金払っても、何年かかってもいいから
その方法を教えて欲しい。
004123-25
NGNG>その日毎のバグ件数をグラフに表し、
>上昇しつづけているようならば、まだ続ける必要がある。
>下降しているようならば、そろそろ収束する。
なるほど、そういう判断もありですね。
ただ、難点は、バグを解決しつつ（というのが単体テスト工程では
普通だとおもうんですが）テストを続行する場合、簡単に解決する
バグと、そうでないものとの「解決速度」に差があるため、
「本当に収束しているのか？解決できないバグにあたってる
だけじゃないのか？」
ということが判断できづらいのでは、と思います。
0042デフォルトの名無しさん
NGNG「完全にこちらの不手際で顧客を煩わせてしまうような商品に商品としての価値は無いものと思え」
ということで
0043デフォルトの名無しさん
NGNG個人差・開発環境そのたもろもろの条件で
一桁から二桁くらいのオーダーが軽くかわってしまうから
0044デフォルトの名無しさん
NGNG解りやすく教えてたもれ。
0045デフォルトの名無しさん
NGNGステップ数とバグ数は、ある関係があるから
今度の開発は、これだけバグが出るはずだとか
推測するやりかたです。
0046デフォルトの名無しさん
NGNG明日も東から昇だろう
というのが統計的手法ですかね
0047デフォルトの名無しさん
NGNGそうじゃなくなったら大変なことに。（ｗ
0048デフォルトの名無しさん
NGNGこの業界は､いろんなところから太陽がいっぱい上がって
太陽同士で喧嘩します。困ったもんだ。
0049デフォルトの名無しさん
NGNG矢継ぎ早なバージョンアップを拒否することで、
そのソフトウェアの寿命が長くなり、
バグも減少していく。
開発側の都合で作り出された新機能を
拒否することで安定した環境が得られるのである。
0050びるげーつ
NGNG安定する前にかならず製品名を変えます。
0051デフォルトの名無しさん
NGNG0052デフォルトの名無しさん
NGNG頼むから、Win2000のSP8までを出した後に、
XPの開発に着手してくれ。
0053デフォルトの名無しさん
NGNGUnitTestも万能ではない。XPのUnitTestで保証されるのは、
「テストを書いたものの機能」だけが保証されるのだ。
例えば、一つのintを取る関数を考えてみる。
0,1,nの法則で三つのテストを書く。例えば0,1,100の場合の。
これで保証できるのは、正に0,1,100の場合だけなのだ。
関数の性格やロジックによっては、これで、「0と正の整数」
で正しく動くことが保証されるかもしれない。
TestFirstなので、テストを先に書く。
そして、テストが通るような実装をする。
はたして、これでOKなのか？
しかし、intを引数に取るのであれば、負の値も渡される
可能性がある。上の例だと、このことを全く考慮していない
にもかかわらず、UnitTestは合格する。
XPとはそういうものなのだ。
0054デフォルトの名無しさん
NGNGである。上の例だと、-5,-1,0,1,100等。まぁ、この例は簡単
すぎるので、負の値のテストを思いつかないなんてことは、
ちょっと考えられないが、多くの関数があれば、抜けも出てくる
だろう。
XPでは、この「テスト項目の抜け」が検出できない。
ペアプログラミングをすれば、一人が監視役（というと語弊が
あるが）でテストケースのコードを書くので、一人でやるよりも
抜けは少なくなる。ただこれも、お互いの、あるいは、一方の
能力に依存した話なのだ。
0055デフォルトの名無しさん
NGNGTestFirstなので、テストコードが存在することが保証する。
これは、第三者でも事前知識無しにテストを実行出来る事を
意味する。
また、継続的なリグレッションテストを行えるのも良い。
あなたの周りでも、リグレッションテストを怠ったがために、
ここをバグフィックスしたら、関係無いところでデグレード
していた、なんてことがあると思う。
XPのUnitTestはこのデグレードを検出してくれる。
以上、XPのUnitTestについて、思ったことを書いてみた。
＜なげーよ(by 三村）
0056デフォルトの名無しさん
NGNG中でもカバレッジテストは不可欠だろう。
市販のカバレッジツールもいくつか存在する。
ただ、ここで注意しなければならないのは、「全ての
行を実行した（これをC0カバレッジと言う）」こと
で満足してはいけない。これは必要最小限のテスト
である。
市販ツールの中には、このC0カバレッジしかテスト
出来ないものもある。
実は重要なのは「すべての条件分岐をする（これを
C1カバレッジと言う）」テストなのだ。
このテストデータを思いつくのも･･･経験と資質だな、
やっぱり。
市販のツールで、C1カバレッジテストを行えるものを
俺は知らない。
0057デフォルトの名無しさん
NGNGDBから取ってきたデータをレポートにするとか、UIとか、DBのデータ
を更新するとかそういったもののテストはねぇ。
でそんな物を作るのが俺の仕事なわけよ。
0058名無しさん＠お腹減った
NGNG0059デフォルトの名無しさん
NGNG「テストしやすいコードを書く」ということを
忘れてはいけない。
XPのTestFirstだと、テストしやすいコードもクソも
ないが、後付けのテストをする場合は、これが必要に
なる。
例えば、
if ((ret = foo(arg)) == NULL) {
// (1)
}
というコードを書くと、簡単にfoo()がNULLを返すような
argを与えることが出来ない、あるいは、そのような状況を
作り出すのが難しい場合に、(1)を実行するテストを行う
ことが難しくなる。
ret = foo(arg);
if (ret == NULL) {
// (1)
}
と書いておけば、最悪デバッガでretの値を書き換えれば、
(1)のコードのテストを行うことが出来る。
また、C1カバレッジを行うことを考え、1関数内で多くの
条件分岐をすることを避けるようにする。つまりリファクタリング
する訳だ。
何らかの理由で、XPのxUnitを後付けで行う場合も同様である。
xUnitの性格を事前に知っておき、xUnitし易いコードを
書くように心がける。
後付けのxUnitも、リグレッションテストを行える、などの
利点があるので、無いよりもずっとましなのだ。
0060デフォルトの名無しさん
NGNGバグ0にしたくなるよ。
0061デフォルトの名無しさん
NGNG>はっきり言ってさー、テストが書ける関数なんてほとんどないのよね。
>DBから取ってきたデータをレポートにするとか、UIとか、DBのデータ
>を更新するとかそういったもののテストはねぇ。
いや、書ける。
というか、テストしやすい構造にしておくのだ。
俺は今、PostgreSQLとPHPでWebアプリケーションを作っているが、
DB関連は全てRubyでUnitTestを書いてるし、PHPの方はWebUnitで
テストしている。
Oracleを使っていたときは、RubyのUnitTestとutPLSQLを使っていた。
構造をn階層にするのと、ビジネスロジックを、それが許されるの
ならば、DBサーバ内に構築するようにする。出来なければ2階層目
に置く。
こうして、なるべくテストしやすい構造にするのだ。
0062デフォルトの名無しさん
NGNG00631
NGNGカバレッジテストは有効と思いますが、
>実は重要なのは「すべての条件分岐をする（これを
>C1カバレッジと言う）」テストなのだ。
>このテストデータを思いつくのも･･･経験と資質だな
やっぱり経験と資質（職人的技術）に頼らないといけないのでしょうか？
私は特に何もやっていないので、実際の有効性がわからないのですが、
バグにも色々原因があり、それぞれに対して有効なツールやテストが
あるように思います。
私が今まで出たバグの原因は、
１．スペルミスによるバグ
２．想定外のデータ処理が間違っていたバグ
３．想定しないタイミングが発生し、バグとなった
４．仕様の取り違え
５．潜在的にバグがあり、テスト時は問題なかったが、別のところを修正したら
そのバグが出てきた
６．関係の無い関数がデータを破壊していた
うーん。思い出せるのはこのくらいかな。
0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNG上の方で話してた人、誰か登場きぼーん。
0066デフォルトの名無しさん
NGNG0067デフォルトの名無しさん
NGNG0068ミトコンドリ子
NGNG一番期待している効果は、あるモジュールを変更したときに他のモジュールの動作結果が変わってしまうことを
早期発見できそうなことよ。
テストコードを書いてもどうしてもバグはでるわ。でもバグとりのたびにテストコードを増やして網の目を細かく
してゆくことで、UnitTestを使わない開発体制よりはより早くより高品質のコードが書けると期待しているわ。
0069デフォルトの名無しさん
NGNGint main(int argc, char **argv)
{
return EXIT_SUCCESS;
}
0070デフォルトの名無しさん
NGNGお前がリンクしてるライブラリのバグは無視してるの？
0071デフォルトの名無しさん
NGNGmain()
[
]
0072>69
NGNG0073デフォルトの名無しさん
NGNGしかも一回コンパイルがうまくいったからって
次回のコンパイルもうまくいく保証はないだろ？
その前に
>結構大きめなプログラムで
て書いてあったの知ってる？
0074デフォルトの名無しさん
NGNGいえ、判定は出来ます。
コンパイルすら通らないので、不可。
0075デフォルトの名無しさん
NGNG[
]
ドス窓が立ち上がりその直後なにもせず終了する
0076デフォルトの名無しさん
NGNG0077デフォルトの名無しさん
NGNGそもそもそれは口内に塗布するものじゃない。
口内専用は「ベスパ」ってのがある。
異様な感覚を覚えたら即座に医師に相談を
0079学者（うそ）
NGNG0080aho
NGNGFormalMethod?
nandesuka koreha?
0081aho
NGNGhttp://dir.yahoo.com/Science/Computer_Science/Formal_Methods/
0082aho
NGNGhttp://www.afm.sbu.ac.uk/
0083デフォルトの名無しさん
NGNGコンパイル通らねぇよ、ヴァカ。
0084デフォルトの名無しさん
NGNGそれは俺とお前のコンパイラとその他の環境が違うからだ。
俺のはMSvisualC++のコンソールアプリケーション追加無しで通る。
0085デフォルトの名無しさん
NGNGﾊｧ?
0086デフォルトの名無しさん
NGNG------
vaka.c
C:\Program Files\DevStudio\MyProjects\vaka\vaka.c(3) : error C2065: 'EXIT_SUCCESS' : 定義されていない識別子です。
cl.exe の実行ｴﾗｰ
vaka.obj - ｴﾗｰ 1、警告 0
------
0087デフォルトの名無しさん
NGNG0088デフォルトの名無しさん
NGNGﾊｧ ﾊｧﾊｧﾊｧ ﾊｧﾊｧ
ﾊｧﾊｧ ﾊｧﾊｧﾊｧ ﾊｧﾊｧ ﾊｧﾊｧﾊｧﾊｧ!
<同時通訳>
お前なあ そういう態度がいかん
社会に通用しないよ 出直して来い！
0089デフォルトの名無しさん
NGNG--
vaka2.c
C:\Program Files\DevStudio\MyProjects\vaka\vaka2.c(3) : error C2090: 関数は配列を返せません。
C:\Program Files\DevStudio\MyProjects\vaka\vaka2.c(4) : fatal error C1004: 予期せぬ EOF が検出されました。
cl.exe の実行ｴﾗｰ
vaka2.obj - ｴﾗｰ 2、警告 0
--
手間取らせやがって。
0090デフォルトの名無しさん
NGNG0091デフォルトの名無しさん
NGNG既存のものを用意させてもらうが・・・
俺の環境はちと特殊だからね。
0092デフォルトの名無しさん
NGNGそもそも脳みそが特殊と思われ。
0093>91
NGNG0094デフォルトの名無しさん
NGNG0095デフォルトの名無しさん
NGNG{
}
この程度のプログラムがかけるからバグは問題ないという認識があるのだとしたら
なかなか素敵な御仁だと思います。ぜひ２ちゃんねるで活躍しつづけてください。
バグで地獄見れば、バグを減らすようになると思うんだけど、減らさないとダメだ
と気がついても、従来と同じ手法に頼るような勉強が出来ないダメプログラマーも
存在します。適性の有無が問われるのは、しょうがないと思ったよ。
0096デフォルトの名無しさん
NGNGどうすればいいか考えてみるとよいかも。
009756
NGNG>やっぱり経験と資質（職人的技術）に頼らないといけないのでしょうか？
というか、基本が出来てない人が多いんですよね。
別に「ソフトウェアテスト技法」なんて本を読む必要はありません。
「ライティングソリッドコード」くらいは読んでて欲しいけど。
信頼度成長曲線や限界値分析はおろか、ホワイトボックステストや、
ブラックボックステストすら知らない人がいるんですよ。実際に。
>私が今まで出たバグの原因は、
>１．スペルミスによるバグ
strcmp()等で比較対照に文字列リテラルを使ってて、それを間違えた
とかですか？
これは、カバレッジテストで見つけることが出来ると思うんですが。
>２．想定外のデータ処理が間違っていたバグ
これは、二つに分けて考えないといけませんね。
「想定外のデータの場合の実装をしていなかった」
「実装はしていたが、その実装に誤りがあった」
前者は、限界値分析で、後者はカバレッジテストで発見できると思います。
# 念の為言っておくと、限界値分析とは、取り得る定義域の
# 境界値付近を詳しくテストすることです。
# 例えば、0 〜 100の値を取る場合は、-1,0,1,99,100,101を調べる。
>３．想定しないタイミングが発生し、バグとなった
これは、単体テスト、UnitTestではなかなか発見できませんね。
これを事前にテストできるかどうか（いつも出来るとは限りませんけど）が
経験なんでしょう、きっと。
>４．仕様の取り違え
これは、ブラックボックステストで検出。
当然、テストケースは、プログラマが書いちゃいけません。
>５．潜在的にバグがあり、テスト時は問題なかったが、別のところを修正したら
>そのバグが出てきた
これは、テストスィートを用意して、いつでもリグレッションテストを行える
環境を作っておけば発見できますね。
>６．関係の無い関数がデータを破壊していた
私はPurifyを使ってます。UnitTestのテストスィートと、ブラックボックステストの
テストスィートを流して、エラーがないかどうかチェックしてます。
うーん、なんかご期待に添える内容じゃなかったかな？
009856
NGNG「これを修正して、他がおかしくならないかな？」という不安が
100%ではないにせよ、かなり軽減されるのが、大きなメリット
です。
また、某コピペじゃありませんが、
「よっしゃー、100テスト、200テストクリア」とか
「300assert OK, 400 assert OK」とか、正しく動く塊が増えていく
のも実感できますし。
xUnitを使ったテスト自動化をやったことが無い人は、部分的
にでも、後付けでも良いですから、やってみることをお勧めします。
んじゃ、寝る。
0100デフォルトの名無しさん
NGNGいろいろと検索したけど、オブジェクトモデルとか情報モデルとかしか
引っかかりませんでした。
0101デフォルトの名無しさん
NGNG01021
NGNG色々とありがとうございます。
参考になりました。
私ごとではありますが、組み込み系のソフトを扱っていますので、
なかなかデバッグが進みません。^^;
誰かこの辺についていい方法知ってませんか？
0103デフォルトの名無しさん
NGNGバグをバグだと思わないってのはどうです？
そういうものなんだというのが前提で・・・。
0104デフォルトの名無しさん
NGNGドラゴンボールのスカウターみたいに？
あれ、ほとんどの人は欠陥品だと思ってないんだよね。
オーバーフローごときで爆発しちゃうような代物なのに。
0106デフォルトの名無しさん
NGNGうん、そうだね・・・。
君の発言にはちょっと笑ってしまったが。
バグ（不具合）を、そういうものだと思ってしまえば、
バグじゃないんだけどね・・・。
自分の思い通りには絶対にならないのなら、
やはりそれはそういうものだという、そういう仕様だという
ことで諦めるしか・・・。
そしてそれがバグ無しのプログラム（笑）
0107デフォルトの名無しさん
NGNG俺は「バグは０にできます」というプログラマは信用しない
そいつがどんな能書きたれてもだ
ところで
>>75
のやつは括弧が "[" と "]" なんだけど…
0108デフォルトの名無しさん
NGNGあれって機械に組み込まれたプログラムがだめだと言うよりも、
あの機械が持つ最大の能力を超えた使い方がされたから、
壊れたというべきでは？
0109デフォルトの名無しさん
NGNGハード的な問題なら、ヒューズみたいなリミッターをかませばいいんじゃないのか？
ソフト的な問題ならバグだね。
どちらにしても欠陥商品ということで。
0110デフォルトの名無しさん
NGNGおれもそう思うけど
納品のときは、バグはありませんと言わないとまずい
わかってくれーー
0111デフォルトの名無しさん
NGNG「今はバグ件数０です」
と言う
0112デフォルトの名無しさん
NGNGと呼んでいたが、件数を操作したことも多々あったような気がする。
（今日のバグを明日に持ち越す）
バグ曲線が急角度になると、客先の印象が悪いからだって。
0113デフォルトの名無しさん
NGNGすべてのエンジニアはバグを常時２５以下にしておかなければならなず、
テストは継続的に行っていく。バグが２５を超えた場合は、その解決を
開発における最優先課題とする。
・・・
それぞれの機能を完成させてから次に移ること。品質検査はプロダクトの
ライフサイクルの間いつでもやっている。開発担当の技術者よりも品質検査
の技術者の方が数が多い。このような開発方法によって、リリースする価値
がある機能を実装できたら開発を取り止め、シュリンクして出荷する。
だってさ
0114デフォルトの名無しさん
NGNGそれよか10000人に1時間デバッグさせるほうがずっと良さそう。
バザールモデルまんせー
>>112
印象が介在しているようじゃ、完璧に敗北してるね、その曲線って。
0115デフォルトの名無しさん
NGNG「発覚していないバグはバグではない。」
0116デフォルトの名無しさん
NGNG変な理屈。
ああ神様、こういう人がY2K問題を作ったのですね。
教えてくれてありがとう。
0117デフォルトの名無しさん
NGNGなぜか？（藁
0118デフォルトの名無しさん
NGNGボウヤじゃないからさ
0120デフォルトの名無しさん
NGNG0121デフォルトの名無しさん
NGNG一見まともに見えるけど、ここまでいうなら、
「仕様の」バグをどう撲滅しているのか？も
組み合わせて知りたいものだ、と思ったです。
モトネタどこで見れますですか？
0122デフォルトの名無しさん
NGNG薬にかぶれてめちゃくちゃ痒いの
これは薬のバグか
0123デフォルトの名無しさん
NGNG相性問題です。
足をアップデートしてください。
0124デフォルトの名無しさん
NGNG0125ふざけて言ってるわけではないが
NGNG0126デフォルトの名無しさん
NGNGゴルゴ13にその辺の分かりやすい解説が載ってたな・・・
マジレスね。
0127ふざけて言ってるわけではないが
NGNG0128中途半端くん
NGNG多分この話だと思う。立ち読みして調べてね。違ったらごめんね。
63巻(ロックフォードの野望) 206話 「デバッグ」
ttp://www4.plala.or.jp/saito_world/Research/Golgo13/061-090/golgo13_063.htm#63-2
0129すまん
NGNG■ このスレッドは過去ログ倉庫に格納されています