バグなしのプログラムって本当に作れるの？

■掲示板に戻る■ ■過去ログ倉庫めにゅーに戻る■

1 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 16:19: 結構大きめなプログラムでバグなしのプログラムはできるのでしょうか？
スペルミス、異常処理、タイミングなどを考えると全てのチェックはできないと思う。
何かいい方法でもある？
2 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 16:29: バグのないプログラムを組み合わせて作る。
3 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 16:33: >>2
組み合わせにバグがあったら？
4 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 16:35: 例えば、あらゆる数値に対して必ず完璧な処理をこなすプログラムを作る。
それを組み合わせればバグといえるバグは無くなるかと。
なお、予想外の事象が起こった場合、強制終了か、または正常に動く様に
処理をするよう数値を変えてしまうとか。
バグってのは結局のところ、予定外の行動や対処がしっかりとされていなかったために、
プログラムがあらぬ処理をしてしまうことで起こるかと。
5 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 16:35: >>3
組み合わせた奴がバカなだけ。
6 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 16:49: １日だけ健康でいる事は簡単だが、１０年健康でいることは難しい。
数行のプログラムでバグの無いプログラムを作る事は簡単だが、
数万行のプログラムでバグの無いプログラムを作る事は難しい。

だが、日頃の節制により病気になりにくい体を作る事は可能であり、
日頃の修練によりバグの出にくいプログラムを作る事は可能である。
7 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:04: 残念ながら、OSにバグがある。
OSも自分で書けばよいが、
残念ながら、BIOSにバグがある。
BIOSも自分で書けばよいが、
残念ながらCPUにバグがある。
8 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:07: 「組み合わせ」も「あらゆる数値」も、
その数が爆発すれば管理不能になるのは事実上当然。

なので逆にいえば、爆発をいかに抑えるか？が味噌のはず。
バグを皆無にする(それは無理だと思うが)のを目指すにせよ、
バグを少なくするのを目指すにせよ。

ーーーーー

XPじゃないが、単体テストっていう考え方は美味しいよね。
つーかXPが美味しいのは、単体テストとTestFirst
(テスト手順をプログラムより「先に」作る)を
常に組み合わせろっていう所か。

なにかってーと、単体でテストを通すことで
複合体となった後の組み合わせの爆発に
関わらずに済むってのと、
プログラムより先にTest手順を作るってことは、
最大の爆発である「プログラムの実装」ってものを
回避しちまう(笑)ことになるわけで。

仕様(実装ではなく)すなわちテスト手順と連動するようにして、
仕様を守っているかどうか？を個別にテストする。

だから例えば、仕様範囲内の数字だけをテストすりゃ良いわけだ(笑)
9 名前： 1 投稿日： 2001/04/19(木) 17:10: >>4
まず、あらゆる数値に対して必ず完璧な処理をこなすプログラムを作るのが
結構大変だったりして・・・^^;
仮に出来たとしても、予定外の行動や対処についてはその通りかも知れませんが、
予想外の処理に対しての処理は予想できないので正しく動作するようにするのは
難しいのでは？
シュミレーションと言う手もあるけど完全とはいかないし・・・
まずはあらゆる数値に対して必ず完璧な処理をこなすプログラムを作ることから
だとは思うのですが、これもどうやって作ります？
10 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:16: バグがないプログラムを作るというよりも、業務によっては
「このプログラムの難易度はＡクラスだから必ずテストでは
ｎ件のバグを出さなければならない。そしてそのｎ件のバグ
が出なかったら、テスト不足として厳しく糾弾する」
という恐ろしいやり方も現実にあるよ。

そのｎ件を超えたバグを出すと、本人の能力不足として
これまた糾弾。
要するにクビにしたいのかねぇ
11 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:17: 「仕様です」
12 名前： 10 投稿日： 2001/04/19(木) 17:18: 俺は、あるプログラムのテストにおいて、不具合(バグ)を出す
件数を190件と設定された。しかし、それよりずっと少ないバグ
しか検出されず、本番稼動の日まで、他の仕事の傍ら、テスト
不足だのなんだの厳しい追及を受けた。

そして、本番後、バグは一切出なかった。
それまで追求していたヤツは、涼しい顔。
そんなもんです。
13 名前： 1 投稿日： 2001/04/19(木) 17:20: >>6
私もバグ０は出来ないと考えてはいます。
（そう思ったんでスレ立てたんですけど・・・）
たしかに少なくすることは出来そうですね。
テストを先に作るのは想定外を無くす上でも重要なことかもしれません。
（ところでＸＰって何？^^;）
ただ、仕様のレベルって細かいものから大雑把なものまであるので、
仕様範囲内の数値を出すのも結構大変かと・・・
バグと仕様は紙一重？
14 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:29: バグはゼロ件で当たり前という考え方の顧客もいるよ。
だから、プログラムの全パターン試験、全ての使い方
を想定したシナリオ試験、本番環境を仮に作り、実際
の運用を行いながらバクを検出する試験など、何段階
もの試験を経てリリースされる大型プログラムもある。

半年スパンとかの汎用機のプログラムなどはそういう
感じかな。

バグが出ようものなら、出した会社の代表者を顧客が
取り囲み、裁判さながらの大問題に発展。

バグを出したら即死。だから肝臓を壊しながら、血の
しょんべん出しながらテストに命を削る人もいる。

バグは出なくて当たり前。出したら恥と思って覚悟しろ。
これがこれからの常識になる。
15 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:35: これから職業プログラマになろうとしている人へ。
今は、顧客の人が自分でプログラムを組むのも珍しく
ない時代。下手すりゃ、顧客の人に負ける場面もある
のじゃないか？

Excel + VBAとかを馬鹿にしてＣ++の知識を誇るのも
いい。
だが、あなたは顧客が作る以上のExcel + VBAを操れる
だろうか。聞かれて「知りません」と答えるしかないの
だろうか。

今、職業プログラマに求められる知識は幅広く、ほんの
些細な知識不足から「たいしたことねーーーな。帰れ」
と心の中で思われるだろう。

くれぐれも、精進してくれたまえ。
16 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:37: >>14
おれまえに血のしょんべんだしたよ…
０に収束はしていくけれど、０にはならないよね。
17 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 17:38: バグの無いプログラムを作ることは事実上不可能。
だが、月日が立つとバグが仕様に変わってしまう・・・
18 名前： 1 投稿日： 2001/04/19(木) 17:45: >>14
確かにテストを大量にやればバグを少なくする（無くなる？）ことが
できると思うのですが、実際の開発では出荷を早めるために十分に
テストできないのも事実です。
（最近の携帯電話なんかそう思う->発売してすぐにバグで回収）
問題はいかに効率よくテストするかなんですけどこれがまた結構大変。
設計時に出来るだけ問題をなくしてテストの量を減らすみたいなことが
言われているけど、実際どうなんでしょう？
19 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 18:12: 俺のプログラム、１万年問題があるんだよなー。
20 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 18:22: >>10
その話題出たのどこのスレだっけ？
馬鹿げているよね、ということで意見の一致(笑)を見たはず。

どう考えても変なやりかただもの、それって。

＃まぢにそれで有効だと思っているんだろうか？＞該当阿呆会社
21 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 18:23: >>14
それも無茶。無茶というのは、それを実践すると、
担当者の人権を激しく阻害(笑)する割には
バグがたいして取れないので。

裁判ごっこなんぼやっても取れないものは取れないんだから、
取るプロセスを改善しないと全く無意味。
懲罰は悪人を減らすことは有るかも知れないが、
過失者を減らすことは出来ないっしょ。

スパイラルだのXPだのでも言われていることだけど、
要するに客を「お客さん」のままにしている限り
向上は無理なんだろうと思う。
お客も開発に引きずり込むというスタイルが良い
(んじゃないか)と最近は言われているね。

で、引きずり込んで何する(させる)かってーと、
細かい部分の開発＆テストを客に直接見せて、
「これでオッケーですよね」とオッケーを取る…のかな？(笑)

つまり、お客にもまた(開発と同じで)王道は無いってことなんじゃないかと。

>>18
「設計時に問題をなくして」というより
「設計時の問題がアラワになりやすいようにして」っすな、
おそらく有効なのは。
22 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 18:25: バスタブ曲線って一旦収束したあと再びバグが増えるって
やつだったっけ？
23 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 18:35: >>20
>その話題出たのどこのスレだっけ？
>馬鹿げているよね、ということで意見の一致(笑)を見たはず。

どのスレか俺も忘れたが、意見の一致はしていないぞ。

テスト工程の妥当性を客観的に判断する基準として、期待される
バグ数を算出し、それと実際のバグ数を比較するのは、最も
良い、とは言えないが、それなりに意味のある方法だ。

それを「馬鹿げている」というなら、それに代わる方法を提示
しなければならない。

「テスト終わりました～。○行あたり１件のテストをやりました～。
バグはなくなりました～」（ちょっと恣意的か）
では、誰も納得しない。

問題なのは、「バグ数の期待値の算出方法」と「評価方法」なのだ。
24 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 18:39: それに、プログラマが数十人以上の規模になってくると、
馬鹿にされている統計手法も意味のあるものになってくる。

個人ベースで「お前はバグ件数が少ないから、テストが足りない」
と決め付けるのはおろかだが、それをもって、この統計手法が
全く意味の無い、馬鹿げたものだと一蹴するのは早計だろう。
25 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 18:46: >>22
>バスタブ曲線って一旦収束したあと再びバグが増えるって
>やつだったっけ？

「バスタブ曲線」と言われてピンとこない人もいると思う。
だが、情報処理試験の勉強をしたものなら知ってるはずだ。

情報処理試験は、このように「同じドメインで話が出来る」
土壌ともなるのだ。
26 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 19:21: >>23-25
説教ｸｾｰｿﾞ｡ﾅﾝｶ、ﾑｶｼｸ｡
27 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 19:45: >>22
うちでは、横軸に日付、縦軸にバグ件数というグラフで、
バグ件数の期待値とバグ検出数の累計をプロットしているので、
どうやってもバスタブ型にはならない。

みんなの所はどんなグラフ書いてるんですか？
28 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 19:49: のこのこのこのこ。

>>23
>問題なのは、「バグ数の期待値の算出方法」と「評価方法」なのだ。

だからさ、バグの数を期待値で計ることの価値は？

>テスト工程の妥当性を客観的に判断する基準として、

客観的な「だけ」で、基準としての必要条件を
満たすわけでもないでしょう。
たかが客観的なだけで、その基準が
(採用するに十分なほど)妥当だと言えるの？

>期待される
>バグ数を算出し、それと実際のバグ数を比較するのは、最も
>良い、とは言えないが、それなりに意味のある方法だ。

そうか？「的外れ」って言葉知っているか？
期待値を使うことが的外れかどうかを「まず」検証してから
その発言を言っているか？なんでも提示すれば良いってもんじゃないぞ？

>それを「馬鹿げている」というなら、それに代わる方法を提示
>しなければならない。

そんな無茶な。
代替案が無かったらゴミで見切り発進しろっての？

あーゆー使えない案を臆面もなく使いつづける奴ってのは、
つまり自分の馬鹿さ(=より良い手を用意できなかった)から
目をそむけてるだけだよ。

「説教くさい」って感想は、直接は正しくないかも知れないけど、
直感レベルではイイセンだと思われる。
説教くささを感じるときってのはつまり、説教が的外れなとき
なんだよな(笑)

それはさておき。 XPってよさそうだよね。
＃って俺もその良さをまだ検証(笑)してないんだから駄目駄目だが。
少なくとも、バグを「数」で捉えるなんて馬鹿はしてない。
「正しい動作はコレである」という定義を積み重ね、
それを直接テストに焼きこむから、そのテストに合格
するかどうか？をもってバグかどうかの必要十分判定を
するわけだ。つまり、バグの数なんてものは、
仕様の数つーかテストの数(笑)から結果的に生まれるだけのものに
すぎないわけよ。
な？少なくともアッチよりは遥かにマシな考えかただろ？
29 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:00: >>24
>それに、プログラマが数十人以上の規模になってくると、
>馬鹿にされている統計手法も意味のあるものになってくる。

ところで、統計的手法ということは、その結果得られる情報を
決定論的に使うことは、そもそもナンセンスだよね？

というわけで、個々のプログラマや外注企業に対して、
「バグの期待数を満たしてないから却下」とヤルのは
ナンセンスってことなわけだ。

でも、情報を個々に対して還元(つまり時として却下)しないと、
プログラムってものの性質上、そもそも手法を使う意味がない。

還元できない情報を還元しようとしてるわけだ。
変でない？
30 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:07: ここは技術版なんだから、アホな客の話とか寒い現場の報告はしたくないな

そして、現実的にはバグ無しのプログラムは不可能だから
バグの出にくい設計／プログラム方法と
バグの出しやすいテスト方法を語り合いたいな。

内容が無くてスマン。
31 名前： 23-25 投稿日： 2001/04/19(木) 20:13: いや、そうむきになって反論されても困るのだが。
・・・という意見もある、という風に受け取って下さい。

でも、「テスト工程がきちんと終了した」ことを、客観的に判断できる
基準というのは必要だとは思いませんか？

今の所、件の統計的手法以外には思いつかない。
あったら、是非教えて欲しい。

*

XPは、個人的に取り入れてるので、UnitTestのありがたさは
良く判る。
ただ、これがうまくいってるのは、少人数で小さな短期間の
システムをやってるからだとも思う。
しかも、自分が作ったUnitTestのコードは正しい、と思って
いるし。
これが、10人ほどのプロジェクトになり、ペアプログラミングが
出来ない場合（有効性が良く判らないので、どこでも導入に
躊躇されると思われる）、他人のUnitTestが正しく、抜けが
無いことをどうやって知ればいいのだろうか。

プログラマが100人とか、そういうプロジェクトではファウラーも
言ってるようにXPはなじまない。
そういう場合に、統計的手法が生きてくると思うのだが、どうだろう？
32 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:13: >>30
そんなの開発側の勝手な言い分。
バグなんて無くて当然！
そう考える顧客は増えているよ。
IT革命(笑)で、我々の常識なんか
通用しない時代になる感触。
33 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:16: 開発の現場はさして革命は起こっていない・・・
ってゆうか厨房は以前より増えている。
34 名前： 23-25 投稿日： 2001/04/19(木) 20:24: 例えばさ、10人で１年のプロジェクトをするとする。

ステップ数で（というのもアレなんだが）合計200Kステップの
コードがあるとする。

で、単体テスト工程が終わって、
「テスト項目数は2000件、バグは100件でした」
という報告を受けたとする。

さて、この場合、このテスト工程はうまくいったのだろうか？

*

あ、それからさっき書き忘れたんだけど、XPが有効なのは
UnitTestまでで、結合テスト以降はまた別のテスト方法を
取らないといけない、と俺は理解してるけど、それで正しい？
35 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:30: バグなんて有って当然！
って考えを世間に定着させたMSﾏﾝｾｰ！
て意見がどこかにあったよね
36 名前： 23-25 投稿日： 2001/04/19(木) 20:33: テスト工程の妥当性・進捗管理の為に、次のような方法もある。

・まず、完成したコードに、故意にバグを埋め込む。
・元コードとのdiffは禁止する（ｗ
・埋め込んだバグがいくつ発見されるかを調べる。

もちろん、全てが発見されなければテスト完にならないのは
言うまでも無い。
さっきの例で行くと、1Kステップあたり1個のバグを埋め込めば、
進捗状況は、(発見数/200) で計算できる。

この手法に名前が付いているかどうかは知らない。
何かの書籍か、雑誌か、Webかで読んだものです。
もちろん、そんなうざいことは、俺はしたことありません。
37 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:47: >>36
>・まず、完成したコードに、故意にバグを埋め込む。
>・元コードとのdiffは禁止する（ｗ

それは、そのバグ取り職人の、
「統計的(笑)な」バグ発見能力を
計っているにすぎないと思うのだが。

つまりだ。そのテストで好成績を出しても、
明日の本番テストで「全部」のバグを
取れる保証は無いわけで。

そーゆーことをやらないための、XPのあの手法
なのだと思うが。

具体的にいえば、ツールを使うことを否定しているのが、
上記の手法の致命的欠点だと思う。
XPはそれどころかバグ取りツールの自作すら
させるわけじゃん(笑)。彼我の差は大きいと思う。

ところで。
よしんば統計手法で良いとしても、
それこそ係数を出す方法が問題だな。
少なくとも行数なんてゴミつーか
逆効果ですらある恐れがないか？
38 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:54: >>31
> 「テスト項目数は2000件、バグは100件でした」
> という報告を受けたとする。
> さて、この場合、このテスト工程はうまくいったのだろうか？

その日毎のバグ件数をグラフに表し、
上昇しつづけているようならば、まだ続ける必要がある。
下降しているようならば、そろそろ収束する。
39 名前： 23-25 投稿日： 2001/04/19(木) 20:56: >>37
>それは、そのバグ取り職人の、
>「統計的(笑)な」バグ発見能力を
>計っているにすぎないと思うのだが。

いえ、そうじゃありません。
元々全部のバグがいくつあるかは関係なく、例えは埋め込んだ
バグのうち50個見つけた段階で、全体の25%の進捗があった、
とするわけです。
ここには係数も、統計的手法も出てきません。

また、200個全部見つかったことをもって、テスト工程が妥当で
あったことの、「一応」の保証とするわけです。
元々あったバグ全てを見つけたという保証ではありません。

>>31
>でも、「テスト工程がきちんと終了した」ことを、客観的に判断できる
>基準というのは必要だとは思いませんか？
のひとつの例としてあげました。

>つまりだ。そのテストで好成績を出しても、
>明日の本番テストで「全部」のバグを
>取れる保証は無いわけで。

もちろんそうですが、テスト担当者の「できました宣言」を何の根拠
もなく信用するよりは、ましです。

何度も言ってますが、

・テスト工程は終わったのか、まだなのか。
・テスト内容は妥当なものだったのか、そうでないのか。

ということを、なるべく管理工数をかけずに知る手段なんですね。
40 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 20:58: >>37
> つまりだ。そのテストで好成績を出しても、
> 明日の本番テストで「全部」のバグを
> 取れる保証は無いわけで。
ＸＰでも「全部」のバグを取れる保証は無い。

つーか、「全部」のバグを取れる保証がある方法があれば
土下座してでも、いくらお金払っても、何年かかってもいいから
その方法を教えて欲しい。
41 名前： 23-25 投稿日： 2001/04/19(木) 21:00: >>38
>その日毎のバグ件数をグラフに表し、
>上昇しつづけているようならば、まだ続ける必要がある。
>下降しているようならば、そろそろ収束する。

なるほど、そういう判断もありですね。
ただ、難点は、バグを解決しつつ（というのが単体テスト工程では
普通だとおもうんですが）テストを続行する場合、簡単に解決する
バグと、そうでないものとの「解決速度」に差があるため、
「本当に収束しているのか？解決できないバグにあたってる
だけじゃないのか？」
ということが判断できづらいのでは、と思います。
42 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 21:10: とりあえず、
「完全にこちらの不手際で顧客を煩わせてしまうような商品に商品としての価値は無いものと思え」
ということで
43 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 21:16: 統計的手法はまだつかえない
個人差・開発環境そのたもろもろの条件で
一桁から二桁くらいのオーダーが軽くかわってしまうから
44 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 21:56: っていうか、統計的手法って何なのさっ？
解りやすく教えてたもれ。
45 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 22:12: 今までの経験から
ステップ数とバグ数は、ある関係があるから
今度の開発は、これだけバグが出るはずだとか
推測するやりかたです。
46 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 22:14: 太陽は、毎日東の空から昇から
明日も東から昇だろう
というのが統計的手法ですかね
47 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 22:20: >>46
そうじゃなくなったら大変なことに。（ｗ
48 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 23:51: >>47
この業界は､いろんなところから太陽がいっぱい上がって
太陽同士で喧嘩します。困ったもんだ。
49 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 00:28: MS Windows&Officeについて言えば、
矢継ぎ早なバージョンアップを拒否することで、
そのソフトウェアの寿命が長くなり、
バグも減少していく。

開発側の都合で作り出された新機能を
拒否することで安定した環境が得られるのである。
50 名前： びるげーつ 投稿日： 2001/04/20(金) 01:07: 安定した環境ができてしまったら新製品が売れなくなってしまうので、
安定する前にかならず製品名を変えます。
51 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 02:14: 作れるに決まってるじゃん（藁
52 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 03:34: びるげーつさまへ。
頼むから、Win2000のSP8までを出した後に、
XPの開発に着手してくれ。
53 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:13: XPは銀の弾ではない。

UnitTestも万能ではない。XPのUnitTestで保証されるのは、
「テストを書いたものの機能」だけが保証されるのだ。

例えば、一つのintを取る関数を考えてみる。
0,1,nの法則で三つのテストを書く。例えば0,1,100の場合の。
これで保証できるのは、正に0,1,100の場合だけなのだ。
関数の性格やロジックによっては、これで、「0と正の整数」
で正しく動くことが保証されるかもしれない。

TestFirstなので、テストを先に書く。
そして、テストが通るような実装をする。
はたして、これでOKなのか？

しかし、intを引数に取るのであれば、負の値も渡される
可能性がある。上の例だと、このことを全く考慮していない
にもかかわらず、UnitTestは合格する。

XPとはそういうものなのだ。
54 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:13: XPで求められるのは、「網羅的なテストケースを思いつく能力」
である。上の例だと、-5,-1,0,1,100等。まぁ、この例は簡単
すぎるので、負の値のテストを思いつかないなんてことは、
ちょっと考えられないが、多くの関数があれば、抜けも出てくる
だろう。

XPでは、この「テスト項目の抜け」が検出できない。

ペアプログラミングをすれば、一人が監視役（というと語弊が
あるが）でテストケースのコードを書くので、一人でやるよりも
抜けは少なくなる。ただこれも、お互いの、あるいは、一方の
能力に依存した話なのだ。
55 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:13: 一方でXPのUnitTestのいい面もある。
TestFirstなので、テストコードが存在することが保証する。
これは、第三者でも事前知識無しにテストを実行出来る事を
意味する。
また、継続的なリグレッションテストを行えるのも良い。
あなたの周りでも、リグレッションテストを怠ったがために、
ここをバグフィックスしたら、関係無いところでデグレード
していた、なんてことがあると思う。

XPのUnitTestはこのデグレードを検出してくれる。

以上、XPのUnitTestについて、思ったことを書いてみた。

＜なげーよ(by 三村）
56 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:26: 網羅的なテストと言えば、ホワイトボックステスト、
中でもカバレッジテストは不可欠だろう。
市販のカバレッジツールもいくつか存在する。

ただ、ここで注意しなければならないのは、「全ての
行を実行した（これをC0カバレッジと言う）」こと
で満足してはいけない。これは必要最小限のテスト
である。
市販ツールの中には、このC0カバレッジしかテスト
出来ないものもある。

実は重要なのは「すべての条件分岐をする（これを
C1カバレッジと言う）」テストなのだ。
このテストデータを思いつくのも･･･経験と資質だな、
やっぱり。
市販のツールで、C1カバレッジテストを行えるものを
俺は知らない。
57 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:28: はっきり言ってさー、テストが書ける関数なんてほとんどないのよね。
DBから取ってきたデータをレポートにするとか、UIとか、DBのデータ
を更新するとかそういったもののテストはねぇ。
でそんな物を作るのが俺の仕事なわけよ。
58 名前： 名無しさん＠お腹減った 投稿日： 2001/04/20(金) 09:28: まぁ、Hello Worldなら
59 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:35: 単体テスト、UnitTestということを考えるときに、
「テストしやすいコードを書く」ということを
忘れてはいけない。
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も、リグレッションテストを行える、などの
利点があるので、無いよりもずっとましなのだ。
60 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:41: ROMになるプログラムにバグを入れて、何千万円分も廃棄すれば、
バグ0にしたくなるよ。
61 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:41: >>57
>はっきり言ってさー、テストが書ける関数なんてほとんどないのよね。
>DBから取ってきたデータをレポートにするとか、UIとか、DBのデータ
>を更新するとかそういったもののテストはねぇ。

いや、書ける。
というか、テストしやすい構造にしておくのだ。
俺は今、PostgreSQLとPHPでWebアプリケーションを作っているが、
DB関連は全てRubyでUnitTestを書いてるし、PHPの方はWebUnitで
テストしている。

Oracleを使っていたときは、RubyのUnitTestとutPLSQLを使っていた。

構造をn階層にするのと、ビジネスロジックを、それが許されるの
ならば、DBサーバ内に構築するようにする。出来なければ2階層目
に置く。
こうして、なるべくテストしやすい構造にするのだ。
62 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 09:55: さて、そろそろ仕事するか（ｗ
63 名前： 1 投稿日： 2001/04/20(金) 10:06: >>56
カバレッジテストは有効と思いますが、

>実は重要なのは「すべての条件分岐をする（これを
>C1カバレッジと言う）」テストなのだ。
>このテストデータを思いつくのも･･･経験と資質だな

やっぱり経験と資質（職人的技術）に頼らないといけないのでしょうか？
私は特に何もやっていないので、実際の有効性がわからないのですが、
バグにも色々原因があり、それぞれに対して有効なツールやテストが
あるように思います。
私が今まで出たバグの原因は、
１．スペルミスによるバグ
２．想定外のデータ処理が間違っていたバグ
３．想定しないタイミングが発生し、バグとなった
４．仕様の取り違え
５．潜在的にバグがあり、テスト時は問題なかったが、別のところを修正したら
そのバグが出てきた
６．関係の無い関数がデータを破壊していた
うーん。思い出せるのはこのくらいかな。
64 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 10:21: なんかこのスレ為になる。このまま育って欲しい・・・。
65 名前： デフォルトの名無しさん 投稿日： 2001/04/20(金) 20:40: うーん、話がはずまないにゃ～。
上の方で話してた人、誰か登場きぼーん。
66 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 16:45: age
67 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 16:45: a, sage de kaite simouta
68 名前： ミトコンドリ子 投稿日： 2001/04/21(土) 17:34: UnitTestは部分的に導入してます。
一番期待している効果は、あるモジュールを変更したときに他のモジュールの動作結果が変わってしまうことを
早期発見できそうなことよ。

テストコードを書いてもどうしてもバグはでるわ。でもバグとりのたびにテストコードを増やして網の目を細かく
してゆくことで、UnitTestを使わない開発体制よりはより早くより高品質のコードが書けると期待しているわ。
69 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 17:50: バグの無いプログラム

int main(int argc, char **argv)
{
　return EXIT_SUCCESS;
}
70 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:05: ＞６９

お前がリンクしてるライブラリのバグは無視してるの？
71 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:09: バグのないプログラム
main()
[
]
72 名前： >69 投稿日： 2001/04/21(土) 18:11: 何のプログラムか書かないとバグかどうか判定不能。
73 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:13: >>69
しかも一回コンパイルがうまくいったからって
次回のコンパイルもうまくいく保証はないだろ？

その前に
>結構大きめなプログラムで
て書いてあったの知ってる？
74 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:14: >>72
いえ、判定は出来ます。

コンパイルすら通らないので、不可。
75 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:14: main()
[
]

ドス窓が立ち上がりその直後なにもせず終了する
76 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:20: オロナイン軟膏を歯茎に塗ったらひりひりします。
77 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:25: >>76
そもそもそれは口内に塗布するものじゃない。
口内専用は「ベスパ」ってのがある。
異様な感覚を覚えたら即座に医師に相談を
78 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 18:57: >>76,>>77
話が高度すぎてついていけません（；；）
誰か説明して。
79 名前： 学者（うそ） 投稿日： 2001/04/21(土) 19:22: フォーマルメソッドマンセー
80 名前： aho 投稿日： 2001/04/21(土) 20:51: >79
FormalMethod?
nandesuka koreha?
81 名前： aho 投稿日： 2001/04/21(土) 20:54: >79 ここのリンクで勉強できますか？
http://dir.yahoo.com/Science/Computer_Science/Formal_Methods/
82 名前： aho 投稿日： 2001/04/21(土) 20:59: 間違えた、こっちの方がいい。
http://www.afm.sbu.ac.uk/
83 名前： デフォルトの名無しさん 投稿日： 2001/04/21(土) 21:16: >>75
コンパイル通らねぇよ、ヴァカ。
84 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:34: >>83
それは俺とお前のコンパイラとその他の環境が違うからだ。
俺のはMSvisualC++のコンソールアプリケーション追加無しで通る。
85 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:38: >>84
ﾊｧ?
86 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:41: めんどくさいけど、試してやったよ。

------
vaka.c
C:\Program Files\DevStudio\MyProjects\vaka\vaka.c(3) : error C2065: 'EXIT_SUCCESS' : 定義されていない識別子です。
cl.exe の実行ｴﾗｰ

vaka.obj - ｴﾗｰ 1、警告 0
------
87 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:42: つーか、そんな低レヴェルの話してて面白いんか？
88 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:42: >>85
ﾊｧ　ﾊｧﾊｧﾊｧ　ﾊｧﾊｧ
ﾊｧﾊｧ　ﾊｧﾊｧﾊｧ　ﾊｧﾊｧ　ﾊｧﾊｧﾊｧﾊｧ!

<同時通訳>
お前なあ　そういう態度がいかん
社会に通用しないよ　出直して来い！
89 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:44: あ、こっちの方だったか。めんどくせー。
--
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
--

手間取らせやがって。
90 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:45: :69,89:d
91 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 00:45: 俺は本気出せばちょっとしたゲームぐらい作れるさ。もちろん画像やらその他は、
既存のものを用意させてもらうが・・・
俺の環境はちと特殊だからね。
92 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 01:39: >>91
そもそも脳みそが特殊と思われ。
93 名前： >91 投稿日： 2001/04/22(日) 01:45: 特殊さん、いらしゃーい
94 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 03:03: 10000時間デバッグすればなんとかなるだろ（ｗ
95 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 03:07: main
{
}
この程度のプログラムがかけるからバグは問題ないという認識があるのだとしたら
なかなか素敵な御仁だと思います。ぜひ２ちゃんねるで活躍しつづけてください。

バグで地獄見れば、バグを減らすようになると思うんだけど、減らさないとダメだ
と気がついても、従来と同じ手法に頼るような勉強が出来ないダメプログラマーも
存在します。適性の有無が問われるのは、しょうがないと思ったよ。
96 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 03:15: 逆に，バグだらけなプログラムを書くには
どうすればいいか考えてみるとよいかも。
97 名前： 56 投稿日： 2001/04/22(日) 03:28: >>63
>やっぱり経験と資質（職人的技術）に頼らないといけないのでしょうか？

というか、基本が出来てない人が多いんですよね。
別に「ソフトウェアテスト技法」なんて本を読む必要はありません。
「ライティングソリッドコード」くらいは読んでて欲しいけど。

信頼度成長曲線や限界値分析はおろか、ホワイトボックステストや、
ブラックボックステストすら知らない人がいるんですよ。実際に。

>私が今まで出たバグの原因は、
>１．スペルミスによるバグ

strcmp()等で比較対照に文字列リテラルを使ってて、それを間違えた
とかですか？
これは、カバレッジテストで見つけることが出来ると思うんですが。

>２．想定外のデータ処理が間違っていたバグ

これは、二つに分けて考えないといけませんね。
「想定外のデータの場合の実装をしていなかった」
「実装はしていたが、その実装に誤りがあった」

前者は、限界値分析で、後者はカバレッジテストで発見できると思います。

# 念の為言っておくと、限界値分析とは、取り得る定義域の
# 境界値付近を詳しくテストすることです。
# 例えば、0 ～ 100の値を取る場合は、-1,0,1,99,100,101を調べる。

>３．想定しないタイミングが発生し、バグとなった

これは、単体テスト、UnitTestではなかなか発見できませんね。
これを事前にテストできるかどうか（いつも出来るとは限りませんけど）が
経験なんでしょう、きっと。

>４．仕様の取り違え

これは、ブラックボックステストで検出。
当然、テストケースは、プログラマが書いちゃいけません。

>５．潜在的にバグがあり、テスト時は問題なかったが、別のところを修正したら
>そのバグが出てきた

これは、テストスィートを用意して、いつでもリグレッションテストを行える
環境を作っておけば発見できますね。

>６．関係の無い関数がデータを破壊していた

私はPurifyを使ってます。UnitTestのテストスィートと、ブラックボックステストの
テストスィートを流して、エラーがないかどうかチェックしてます。

うーん、なんかご期待に添える内容じゃなかったかな？
98 名前： 56 投稿日： 2001/04/22(日) 03:37: 最近思うのは、XPのUnitTestはかなり有効だな、ということ。

「これを修正して、他がおかしくならないかな？」という不安が
100%ではないにせよ、かなり軽減されるのが、大きなメリット
です。
また、某コピペじゃありませんが、
「よっしゃー、100テスト、200テストクリア」とか
「300assert OK, 400 assert OK」とか、正しく動く塊が増えていく
のも実感できますし。

xUnitを使ったテスト自動化をやったことが無い人は、部分的
にでも、後付けでも良いですから、やってみることをお勧めします。

んじゃ、寝る。
99 名前：謎投稿日： 2001/04/22(日) 05:50: >>97
SDMの授業みたいだ。
100 名前： デフォルトの名無しさん 投稿日： 2001/04/22(日) 06:32: SDMってなんですか？
いろいろと検索したけど、オブジェクトモデルとか情報モデルとかしか
引っかかりませんでした。
101 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 03:14: あげ
102 名前： 1 投稿日： 2001/04/23(月) 10:08: >>97
色々とありがとうございます。
参考になりました。

私ごとではありますが、組み込み系のソフトを扱っていますので、
なかなかデバッグが進みません。^^;
誰かこの辺についていい方法知ってませんか？
103 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 19:16: あのぉ・・・。
バグをバグだと思わないってのはどうです？
そういうものなんだというのが前提で・・・。
104 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 19:50: >>103
ドラゴンボールのスカウターみたいに？
あれ、ほとんどの人は欠陥品だと思ってないんだよね。
オーバーフローごときで爆発しちゃうような代物なのに。
105 名前： 1 投稿日： 2001/04/23(月) 19:54: >>103
何度もそう思ったことある。
「これは仕様って言うことで・・・」
「うっ、これは目の錯覚に違いない・・・」（テスト中に）
106 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 19:59: >>105
うん、そうだね・・・。
君の発言にはちょっと笑ってしまったが。
バグ（不具合）を、そういうものだと思ってしまえば、
バグじゃないんだけどね・・・。
自分の思い通りには絶対にならないのなら、
やはりそれはそういうものだという、そういう仕様だという
ことで諦めるしか・・・。
そしてそれがバグ無しのプログラム（笑）
107 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 20:06: 個人的な意見で批判も多いだろうけど
俺は「バグは０にできます」というプログラマは信用しない
そいつがどんな能書きたれてもだ

ところで
>>75
のやつは括弧が　"["　と　"]"　なんだけど…
108 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 20:12: >>104
あれって機械に組み込まれたプログラムがだめだと言うよりも、
あの機械が持つ最大の能力を超えた使い方がされたから、
壊れたというべきでは？
109 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 20:24: >>108
ハード的な問題なら、ヒューズみたいなリミッターをかませばいいんじゃないのか？
ソフト的な問題ならバグだね。
どちらにしても欠陥商品ということで。
110 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 22:16: >>俺は「バグは０にできます」というプログラマは信用しない
おれもそう思うけど
納品のときは、バグはありませんと言わないとまずい
わかってくれーー
111 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 22:24: >>110
「今はバグ件数０です」
と言う
112 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 22:30: 以前の関わった仕事では、バグの日ごとの件数をグラフにして、「バグ曲線」
と呼んでいたが、件数を操作したことも多々あったような気がする。
（今日のバグを明日に持ち越す）
バグ曲線が急角度になると、客先の印象が悪いからだって。
113 名前： デフォルトの名無しさん 投稿日： 2001/04/23(月) 23:52: Adobeいわく

すべてのエンジニアはバグを常時２５以下にしておかなければならなず、
テストは継続的に行っていく。バグが２５を超えた場合は、その解決を
開発における最優先課題とする。

・・・

それぞれの機能を完成させてから次に移ること。品質検査はプロダクトの
ライフサイクルの間いつでもやっている。開発担当の技術者よりも品質検査
の技術者の方が数が多い。このような開発方法によって、リリースする価値
がある機能を実装できたら開発を取り止め、シュリンクして出荷する。

だってさ
114 名前： デフォルトの名無しさん 投稿日： 2001/04/24(火) 02:48: >>94
それよか10000人に1時間デバッグさせるほうがずっと良さそう。
バザールモデルまんせー

>>112
印象が介在しているようじゃ、完璧に敗北してるね、その曲線って。
115 名前： デフォルトの名無しさん 投稿日： 2001/04/24(火) 03:24: >>111
「発覚していないバグはバグではない。」
116 名前： デフォルトの名無しさん 投稿日： 2001/04/24(火) 05:43: >>115
変な理屈。
ああ神様、こういう人がY2K問題を作ったのですね。
教えてくれてありがとう。
117 名前： デフォルトの名無しさん 投稿日： 2001/04/24(火) 10:29: 開発に関わった人間は新製品に決して飛びつかないという。
なぜか？（藁
118 名前： デフォルトの名無しさん 投稿日： 2001/04/24(火) 10:40: >>117
ボウヤじゃないからさ
119 名前： 1 投稿日： 2001/04/24(火) 12:20: >>117
第２ロットまで待て！
120 名前： デフォルトの名無しさん 投稿日： 2001/04/25(水) 17:43: age
121 名前： デフォルトの名無しさん 投稿日： 2001/04/26(木) 00:39: >>113
一見まともに見えるけど、ここまでいうなら、
「仕様の」バグをどう撲滅しているのか？も
組み合わせて知りたいものだ、と思ったです。

モトネタどこで見れますですか？
122 名前： デフォルトの名無しさん 投稿日： 2001/04/26(木) 00:55: 水虫の薬買ってつかったんだけど
薬にかぶれてめちゃくちゃ痒いの
これは薬のバグか
123 名前： デフォルトの名無しさん 投稿日： 2001/04/26(木) 00:58: >>122
相性問題です。
足をアップデートしてください。
124 名前： デフォルトの名無しさん 投稿日： 2001/04/26(木) 01:17: プログラミング言語で足の水虫を撃つには…
125 名前： ふざけて言ってるわけではないが 投稿日： 2001/04/26(木) 01:22: バグって何？マジで概念を知りたい。
126 名前： デフォルトの名無しさん 投稿日： 2001/04/26(木) 01:28: >>125
ゴルゴ13にその辺の分かりやすい解説が載ってたな・・・
マジレスね。
127 名前： ふざけて言ってるわけではないが 投稿日： 2001/04/26(木) 01:30: え　何巻？　ゴルゴ最高　俺の後ろにカキコするな　
128 名前： 中途半端くん 投稿日： 2001/04/26(木) 01:37: ちょっと調べてみた。
多分この話だと思う。立ち読みして調べてね。違ったらごめんね。

63巻(ロックフォードの野望)　206話「デバッグ」
ttp://www4.plala.or.jp/saito_world/Research/Golgo13/061-090/golgo13_063.htm#63-2
129 名前： すまん 投稿日： 2001/05/02(水) 04:02: ７６と７７に死ぬほど笑ったのでage