- 1 名前：仕様書無しさん [2008/06/28(土) 19:49:20 ]
- 何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
って...
コーディングが終わってやっと３割終わったかどうかってところだろが。
コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、
正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。
本当に理解してんのか？ コーディングが終わってやっとスタートラインに立ったぐらいの気持ち
でいろよ、ってくヘラヘラしやがって。
こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、
徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。
どんな優秀な奴だって、人間だもの、間違いを犯す。バグを生み出す。それを極力未然に防ぐのが
テストだろ。いつバグが判明するかとドキドキしながら納品後の時間を過ごすか、自信と満足感を
もって笑顔で過ごすか。どちらがいいか自明のことだろ。
プログラミングはなぁ、テストに始まりテストに終わるんだよ。要件を理解し、その中に潜む異常
パターンを見抜き、どんだけ抜かりなくテストをやれるかが一流とカスを分かつ分水嶺だ。
コーディングなんかできてあたり前、肝心なのはテストだ。テストを極めてこそ、一流のプログラ
マーって呼べるんだよ。
この馬鹿者どもが。
- 366 名前：仕様書無しさん mailto:sage [2008/07/19(土) 13:00:56 ]
- ttp://itpro.nikkeibp.co.jp/article/OPINION/20080423/299886/
6000人のSEが同時期に集まったのであって，「6000人月」ではない。
開発工数は先に書いた通り，11万人月である。
このSEパワーは開発だけではなく，テストに惜しみなく使われた。
ざっと5000人が8カ月テストをしたとするとこれだけで4万人月，開発工数の3分の1がテストに費やされた計算になる。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
- 367 名前：80 mailto:sage [2008/07/19(土) 17:11:42 ]
- ttp://sankei.jp.msn.com/economy/finance/080512/fnc0805122000013-n1.htm
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テストに開発工数の 1/3 を費やしてもシステム障害で行政処分。
部分最適化のもろさを露呈してしまう結果になった。
「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
カバーできないってこと。間違った仕様を完璧にコーディングしても
それは、バグ。
- 368 名前：仕様書無しさん mailto:sage [2008/07/19(土) 17:22:10 ]
- 6000人全員が派遣でしたwww って話？？
- 369 名前：仕様書無しさん mailto:sage [2008/07/19(土) 20:48:04 ]
- コーディングは終わったので、あとは人海戦術で手動テストしてくださいって
パターンなら最初からうまくいくはずないよ。
- 370 名前：仕様書無しさん mailto:sage [2008/07/19(土) 22:14:17 ]
- なんか、ぶっちゃけ私の方法ならうまくいくと間接的に言ってるように
見えるけど、ほんとそうなの？
- 371 名前：仕様書無しさん mailto:sage [2008/07/19(土) 22:22:01 ]
- >>369
テストの際に出てくる不具合報告を眺めてるだけじゃ完成しないがなw
テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
- 372 名前：仕様書無しさん mailto:sage [2008/07/20(日) 02:22:31 ]
- >>371
メガプロジェクトじゃ、そんなの通用しないし。
- 373 名前：仕様書無しさん mailto:sage [2008/07/20(日) 02:34:44 ]
- >>372
はあ？
メガプロジェクトじゃ、最後までコーディングしてる部署が必ずあるよ。
つうか、不具合改修はやらねえの？
- 374 名前：仕様書無しさん [2008/07/20(日) 03:14:48 ]
- 普通、やるでしょ
PSPの海腹川背みたいな例もあるけどw
- 375 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:12:05 ]
- >>371
> テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
だから、無駄なテスト前コーディングをしないで、
テストをやってコーディングをするんだよね。
- 376 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:16:01 ]
- >>367
> 「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
> カバーできないってこと。間違った仕様を完璧にコーディングしても
> それは、バグ。
ですよね。だからちゃんと想定して、
その想定した内容をテストとして書くんですよね。
これであなたもユニットテストの重要性を理解したと思います。
- 377 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:20:56 ]
- ついにマ板にも夏が来たか・・・
- 378 名前：仕様書無しさん mailto:sage [2008/07/20(日) 14:21:36 ]
- >>376
ユニットテストじゃ、要求定義や設計時のミスは取り除けないよ。
それを元にテストが作られるんだからね。
だいたい、設計時の矛盾は最終的な総合テストまで残る。
要求定義の矛盾は製品にまで残る。
- 379 名前：仕様書無しさん mailto:sage [2008/07/20(日) 15:00:32 ]
- >>373
「本当のコーディング作業」の定義次第だな。
そして、その定義を云々するのはくだらねー。
- 380 名前：仕様書無しさん mailto:sage [2008/07/20(日) 17:13:26 ]
- 80の言い分だけど、
うちの会社は1000万のコードで、
次に、基本証券・金融系では無い。制御系だといって、
最後に、国内最大の金融系の仕様段階での問題点を出している。
あ、あとシリコンバレーと仕事しているってのもあったな。
で、別に仕事のやり方は全否定する要素は無いが、具体例は
全否定されても仕方ないほど妄想力に満ちていると感じたの漏れだけ？
- 381 名前：仕様書無しさん mailto:sage [2008/07/20(日) 19:23:59 ]
- >>374
あれは、「仕様です」
- 382 名前：仕様書無しさん [2008/07/23(水) 01:01:35 ]
- とりあえずユニットテストやファンンクショナルテストをちゃんと書いていけば
設計時の矛盾とか普通にたくさんでてくるよ。
んで、短いサイクルでどんどんリファクタしていけばいい。
もちろん手動テストもするけど、ばかげた規模での人海戦術テストとかにはならないでしょ。
- 383 名前：仕様書無しさん [2008/07/23(水) 01:06:30 ]
- またまた富士通！東証システム障害 プログラムミスが原因 2008/7/22
headlines.yahoo.co.jp/hl?a=20080722-00000027-maip-brf
41 名前：仕様書無しさん 投稿日：2008/07/23(水) 00:00:22
∧∧
富 ( ･ω･) ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
士 （つ/￣￣/ ＜ 1銘柄当たり1280バイトの作業用メモリー領域だから、
通 /＿＿/ ＼ ＼ 2万8000銘柄分、合計3万5000Kバイト・・・
||＼ TOWNS ＼ ＼ 4万バイトということで"PIC 9(40M)"ってことだな
||＼||￣￣￣￣￣|| ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
|| ||￣￣￣￣￣||
.|| ||
え〜と40M・・と、 それ、ポチっとな
000230 01 WORKAREA.
000240 03 WORK PIC 9(04). <--- 4バイト
∧東∧
∧富∧ （´<_｀ ） さすがだな富士通
（ ´_ゝ`）/ ⌒i
＿(__つ/￣￣￣/i |＿ そんなこと言ってないで、チェックお願いしますよ、東証&NTTデータさん
＼/＿＿＿/ ヽ⊃
そして・・・・
. . : : : :: : : :: : ::: :: : :::: :: ::: ::: ::::::::::::::::::::::::::::::::::::::
. . .... ..: : :: :: ::: :::::: :::::::::::: : :::::::::::::::::::::::::::::::::::::::::::::
Λ＿Λ . . . .: : : ::: : :: ::::::::: :::::::::::::::::::::::::::::
/:彡ミ゛ヽ;）ー､ . . .: : : :::::: :::::::::::::::::::::::::::::::::
/ :::/:: ヽ、ヽ、 ::i . .:: :.: ::: . :::::::::::::::::::::::::::::::::::::::
/ :::/;;: ヽ ヽ ::ｌ . :. :. .:: : :: :: :::::::: : ::::::::::::::::::
￣￣￣（_,ノ ￣￣￣ヽ､_ノ￣￣￣￣
- 384 名前：仕様書無しさん [2008/07/23(水) 01:06:41 ]
- 【東証のシステム障害、設定ミスをテストでも見抜けず 2008/07/22 】
鈴木CIOは「設定をミスしたのはベンダーの富士通」とした上で、「多数の銘柄に対し板情報の
問い合わせがあった場合をテストケースに含んでいなかったのは我々の責任。もっと幅広く
テストすべきだった」と陳謝した。
itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/
【富士通の開発ミスの全責任は東証にある」とみずほ証券、株誤発注裁判 2008/05/09 】
2005年12月にみずほ証券がジェイコム株の誤発注で出した損失を巡って東京証券取引所を
訴えた裁判の第9回口頭弁論が2008年5月9日、東京地方裁判所で開かれた。
原告のみずほ証券側は、被告の東京証券取引所にシステムの発注者としての注意義務違反と
重過失があったことを改めて主張する準備書面を地裁に提出した。
みずほ証券側は「東証はシステムの発注者として、業務上の要求を富士通に伝え、富士通が
開発したプログラムが要求と整合しているかをテストする責任がある」と訴え、「誤発注の
取り消しができなかったのは東証の重過失だ」と主張した。
：
次回口頭弁論は2008年7月25日の予定だ。
~~~~~~~~~~~~~~~~~~~~~~~~~~
itpro.nikkeibp.co.jp/article/NEWS/20080509/301077/
【「短期間で2回のシステム障害は、痛恨の極み」東証社長が会見 2008/03/25 】
証は2月8日の金融派生商品の取り引きを担う新派生売買システムの障害に続き、3月10日にも
株式売買システムで障害を起こした。
先月22日に新派生売買システムを中心とした障害の再発防止策を発表したばかりだが・・・
itpro.nikkeibp.co.jp/article/NEWS/20080325/297067/
【特集・東証システム問題リンク】
itpro.nikkeibp.co.jp/99/tousyou/index.html
- 385 名前：仕様書無しさん mailto:sage [2008/07/25(金) 03:00:06 ]
- ユニットテストは詳細設計どおりにプログラムが稼働するテストと認識しているんだが、
詳細設計が１ＳＴＥＰ対応の設計書でない場合、全パステストの結果って
どういう扱いになるのかな？
- 386 名前：仕様書無しさん mailto:sage [2008/07/26(土) 01:44:42 ]
- >詳細設計
の確認はうちではユニット-ユニットの結合テストだな
ユニットテスト対象はプログラム設計
ここ→ttp://msugai.fc2web.com/pgm/test.html
のV字モデルに近い
なので全パステストなんて結合テストで考えない
- 387 名前：386 mailto:sage [2008/07/26(土) 01:57:35 ]
- ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/
の図1もプログラム設計が書いてないけど同じっぽい
- 388 名前：仕様書無しさん mailto:sage [2008/07/28(月) 11:42:25 ]
- 今日初めて見たが、みんな何か勘違いしてないか？
テストで信頼性は上げられない、テストは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。
テストでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、テストをしない開発手法もある。
- 389 名前：仕様書無しさん mailto:sage [2008/07/28(月) 15:31:02 ]
- >>388
asshole
- 390 名前：仕様書無しさん [2008/07/28(月) 18:11:43 ]
- >>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
kwsk
- 391 名前：仕様書無しさん mailto:sage [2008/07/28(月) 18:23:16 ]
- 耐震偽装と同じレベルだろwww
- 392 名前：388 mailto:sage [2008/07/29(火) 00:35:28 ]
- >>390
有名な所では、ダーリントン原子力発電所の緊急炉停止システム
- 393 名前：仕様書無しさん mailto:sage [2008/07/29(火) 00:43:53 ]
- >>388
ソフトウェアの信頼性を定義してみな
- 394 名前：仕様書無しさん mailto:sage [2008/07/29(火) 02:52:18 ]
- IEC読んで言ってるなら凄いけどね・・・
- 395 名前：388 mailto:sage [2008/07/29(火) 21:00:07 ]
- >>393,394
俺をテストしてどうする。しかし、なぜムキになるか分からん？
ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88
>ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。
Wikipediaにもにも書いてあるし、大半の「テスト」関連の書籍にも同じような意味の事が書かれている
いままで、その辺りの知識もなしにレスを書いていたのか？
- 396 名前：仕様書無しさん mailto:sage [2008/07/29(火) 21:28:57 ]
- >>395
それは394への答えにはならないよ。
- 397 名前：仕様書無しさん mailto:sage [2008/07/29(火) 21:32:30 ]
- >>395
だから、普通テストは
要求された機能が特定の条件下で要求通りの結果を示せるかをテストするんだぜ？
要求されてない（テストされてない）機能がどのように振る舞おうが知ったこっちゃ無いのはあたりまえ。
だからその理論は正しいが、そんな事は誰も要求していないんだよ。
想定外の欠陥は許されるが、想定内の欠陥はダメなの。
- 398 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:31:54 ]
- >>397
＞想定外の欠陥は許されるが、想定内の欠陥はダメなの。
現実は想定外の欠陥でも許さない人間が大半だがな。 相乗りしている他システムが
異様にリソース使いまくって、それに巻き込まれて不具合起きて、それでも不具合が
おきない様にしろと言われかけたときは頭抱えたよ、、、
- 399 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:34:35 ]
- >>398
もちろん納品前に発覚した不具合は想定内だよ。
- 400 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:36:13 ]
- 予想GUYダ！
- 401 名前：仕様書無しさん mailto:sage [2008/07/30(水) 00:52:25 ]
- よそう、GAYﾀﾞ!
- 402 名前：仕様書無しさん mailto:sage [2008/07/30(水) 02:14:08 ]
- >>399
納品後ですが、何か？
しかも納品後すぐとかじゃなくて、数ヶ月たってとかだったり、他の納品先だと
そんなこと起きなかったりとかで調査だけでも結構かかりましたが。
- 403 名前：仕様書無しさん mailto:sage [2008/07/30(水) 02:16:01 ]
- >>402
受け入れ検査終了後なら別料金もらってんだろ。
いいじゃん仕事あって。
- 404 名前：仕様書無しさん [2008/07/30(水) 18:45:40 ]
- >>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
ネタにしてはよく出来てる手口。
- 405 名前：仕様書無しさん mailto:sage [2008/07/30(水) 21:15:43 ]
- >>395
で、信頼性はどう定義するんだ？
- 406 名前：388 mailto:sage [2008/07/30(水) 23:03:31 ]
- >>397
限られた前提条件・限られた入力値・限られた入力値組み合わせでテストをして
その機能が、全て正しく動くと思ってる？ テストが何たる物か分かっていない証拠だな
>>404
自分の知識で分からないものはネタか！やっぱりこんな奴がいるんだ
例を出したんだから、調べれば分かると思うが。
>>405
俺に聞いても、プログラムの信頼性は上がらんだろう、自分で考えないと。
- 407 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:07:51 ]
- >>406
誰も信頼性の上がる方法なんて聞いてない。
信頼性の定義を聞いているのがわからないのか？
- 408 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:09:50 ]
- >>406
お前もちゃんと調べてから例出しな
- 409 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:10:08 ]
- >>406
全て動くなんて言ってないが。
ファビョるのもたいがいにしろよ。
- 410 名前：388 mailto:sage [2008/07/30(水) 23:19:22 ]
- >>407
>信頼性の定義を聞いているのがわからないのか？
分かって書いているんだが、分からないのか？
>>408
調べても分からなかったのか？俺はこれ以上教えるつもりはないから
>>409
>全て動くなんて言ってないが。
だから、テストでは信頼性は確保出来
- 411 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:20:59 ]
- >>信頼性の定義を聞いているのがわからないのか？
>分かって書いているんだが、分からないのか？
どこに書いたんだ？
- 412 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:21:48 ]
- 駄目だこいつ。
- 413 名前：仕様書無しさん [2008/07/30(水) 23:22:33 ]
- テストの前にソースの読み直しをお願いします
先輩
- 414 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:23:52 ]
- 単純リプレースとか言って営業がとってくる仕事ほど
前の機能をちゃんと満たしてるか（正しく動作するか？）って意味で
テストが重要、
って口をすっぱくして言ったんだがヌルーされた。
マシン->マシンでコピーして、簡単に動作確認すればいい
だってさ
まぁ、うまくいけばいいんだけどね。。。その時期夏休みとって携帯電源切っとこう
- 415 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:23:58 ]
- 原子力発電所のソフトウェア開発について議論するスレじゃないよ
- 416 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:24:26 ]
- >>410
394にまともに答えられない人に教えてもらう事無いと思うよｗ
- 417 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:25:44 ]
- 何手法だか知らないが、その手法でぬるいメガプロジェクトでも回してみればいいさ。
- 418 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:40:28 ]
- KKDは勘と経験と度胸による見積もり法です
- 419 名前：仕様書無しさん mailto:sage [2008/07/30(水) 23:40:45 ]
- それ
なんて
みずぽ？
- 420 名前：388 mailto:sage [2008/07/31(木) 00:05:03 ]
- >>411
>>どこに書いたんだ？
信頼性の定義は書いていない
>>412
>駄目だこいつ。
そうだな
>>413
>テストの前にソースの読み直しをお願いします
読み直しは大事だと思う、テストよりも
>>414
何処でも営業は同じ、そんなもん
>>415
ソフトウェアの話じゃないのか？
>>416
教えるつもりもないから大丈夫
>>417
そこまで信頼性を求められるプロジェクトは、ほとんどない
>>418
勘・経験・度胸は大切だと思うよ、マネジメントは人間性が一番重要だと思う
>>419
???
- 421 名前：仕様書無しさん mailto:sage [2008/07/31(木) 00:10:24 ]
- >>420
聖徳太子現る
明日は合コンだってさ、木曜だしなーーー
女の子たちの接客上手をテストしてやるぜ〜
- 422 名前：仕様書無しさん mailto:sage [2008/07/31(木) 13:06:27 ]
- >>420 からおじゃば臭がするのは気のせいか？
- 423 名前：仕様書無しさん mailto:sage [2008/07/31(木) 19:21:50 ]
- 気のせいじゃなくね
- 424 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:04:06 ]
- >>421
どこのキャバでやんの？
- 425 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:39:41 ]
- >>420
おじゃばとしては、どういうテスト手法を理想としてんの？
- 426 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:43:06 ]
- >>422
いや、ハカセじゃないのかシステム工学を語りたいんだろう
でもハカセはアホだから違うかｗ
- 427 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:48:28 ]
- >>425
教えてやろう君にはすばらしい餌だなｗ
- 428 名前：仕様書無しさん mailto:sage [2008/07/31(木) 20:52:52 ]
- >>426
お前、おじゃばだろ
- 429 名前：仕様書無しさん mailto:sage [2008/07/31(木) 22:14:57 ]
- >>424
キャバじゃないし、今日でもなかった・・・
だれかおれの視力、聴力、記憶力をテストしてくれ
- 430 名前：仕様書無しさん mailto:sage [2008/07/31(木) 22:18:40 ]
- >>429
つ homepage3.nifty.com/funahashi/game/game693.html
- 431 名前：仕様書無しさん mailto:sage [2008/08/01(金) 03:03:06 ]
- テストしてほしけりゃ金よこせ
- 432 名前：仕様書無しさん mailto:sage [2008/08/01(金) 03:36:48 ]
- まともにテストできるか能力を示せ。
- 433 名前：388 mailto:sage [2008/08/02(土) 15:13:28 ]
- テストは限られたリソースの中で、いかに効率良く不具合を見つけるかが重要
例えば、同じプログラムをテストして
「Aは１０件のテストケースで５件のバグが見つけた」
「Bは１００件のテストケースで１０件のバグが見つけた」
では、Bの方がAより残りのバグも少ないので信頼性のあるプログラムになるが
テストとしては、半分の確率でバグを見つけたAの方が、「良いテスト」と言える
つまり、テストは効率性が重要で、プログラムの信頼性は考えない
（バグを多く見つけるかでは無く、「"効率的"」にバグを多く見つけるかが重要)
同値テストや限界値テストなどのテストテクニックも、バグを効率に見つける為に考え出されたもの
- 434 名前：仕様書無しさん mailto:sage [2008/08/02(土) 16:18:18 ]
- なるほどね。
おじゃばという人物は、コミュニケートする気はないわけだ。
相手とちゃんとやりとりしたい訳じゃない。
単に「自分は知識があるのだ、おまえらより優れているのだ」と思っていて、
その優れた俺様の知識をひけらかし(たつもりになっ)て、気持ちよくなってるだけ。
その過剰な自己過信が揺らぐことも、基本的にはなくて、
それ故に、主張が基本的にいつでも一方的で、言いたいことを言うだけ。
使いようによっては、存在に意味を持たせる事は可能かもしれないけど、
人間的にはゴミだなぁ。ｗ
- 435 名前：仕様書無しさん mailto:sage [2008/08/02(土) 16:23:25 ]
- Aの方が効率悪いじゃん？
なんでBは100件もこなせてるのに
Ａは10件しかこなせなかったんだ？
リソース一緒なのに。
- 436 名前：仕様書無しさん mailto:sage [2008/08/02(土) 16:44:08 ]
- >>388
節子、それ、テストやない。デバッグや。
- 437 名前：仕様書無しさん mailto:sage [2008/08/02(土) 19:52:15 ]
- >>435
１０件辺り５件も不具合出りゃあ、テスト中止だろwww
５０％なんてどんだけボロボロなんだよwww
- 438 名前：80 mailto:sage [2008/08/03(日) 00:48:44 ]
- >>437
>>435 の例は、
・同じプログラムなら網羅できたとしてテストケースの数は同じになる。
・テストケース数＝1000件
・実際の不具合の数＝20件
テストA：
テストケースの中から10件を選択してテストを実施->不具合5件発見
テストB：
テストケースの中から100件を選択してテストを実施->不具合10件発見
プログラマーが嫌うような意地悪なテストから実施すると不具合は見つかり
やすいとか、やりようによっては早期に不具合を発見できるという意味なのでは？
さらに、テストケースの粒度や内容をコントロールすれば効率はさらに
上がると思う。
- 439 名前：80 mailto:sage [2008/08/03(日) 01:17:35 ]
- 屁理屈といわれそうだが、言葉の定義だけで言うなら
「信頼性＝故障しにくい事」
故障とは
1. 機械や身体などの機能が正常に働かなくなること。
2. 物事の進行が損なわれるような事情。
3. 異議。苦情。
1. の意味だと
ハードウェアシステムの場合は、劣化などでそのうち故障する。
ソフトウェアシステム（プログラム）の場合は、劣化などはしないので
故障しない。
ソフトウェアの不具合は、2. の意味と考えられる。で、実際には、
3の苦情を指すんじゃなかろうか？
つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
で、
A. 頻繁に使用されるある1つの機能に不具合がある
B. たまに使用されるある2つの機能に不具合がある
C. 滅多に使用されないある10の機能に不具合がある
を考えた場合、A, B, Cのどれを見つけるのが実際に利益があるのか？
を考えるとわかりやすいかもしれない。
なので、 >>435 の言う「テストの効率」は、もっと深く考慮されるべき
だと思う。
蛇足だが、
あるボタンを連打すると発生する不具合をテスト自動化で見つけたが
人間業では決して発生させることができない不具合だったので修正を
見送った経験がある。
- 440 名前：仕様書無しさん mailto:sage [2008/08/03(日) 01:21:11 ]
- >>435じゃなくて>>433な。
- 441 名前：仕様書無しさん mailto:sage [2008/08/03(日) 01:25:14 ]
- >>438
そんな机上論、幾ら並べても無意味。
何故って？
不具合の数に全容なんて無いからさ
その「実際の不具合の数」自体が空論
テスト方法変えて出てくるのは、異なる不具合であり、全容の一部が見えたわけではない。
- 442 名前：80 mailto:sage [2008/08/03(日) 01:36:54 ]
- >>440
訂正サンキュー。
ついでに補足
滅多に使用されない機能に致命的な不具合がある場合が一番厄介。
しかも、要求にはない機能が盛り込まれる場合、つまり、想定外の使い方
をされるのは、本当に厄介だ。
要求に無い機能（設計の段階で暗に入り込んだ機能）は、テストから漏れる
事が多いと思う。で、うちでは、繰り返し型なので、この手の潜在的な機能は、
（気付けば）要求としてとらえることにしている。
- 443 名前：80 mailto:sage [2008/08/03(日) 01:53:57 ]
- >>441
「ソフトウェアの信頼性ほど信頼性の低いものはない」と俺も思う。
不具合密度がどーとか経営陣や顧客に嘘くさい説明はできても自分自身は
納得していない。なので、実際には、統計的な手法からは距離を置いている。
持論で申し訳ないが、俺は、
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
と考えている。
極論すると
・ユーザが発見できない不具合は不具合とはみなさない。
（無実ではないが無罪。飲酒運転も逮捕されなければOK的な・・・）
・要求にない機能は、一切入り込まないようにする。
てな感じかな。
- 444 名前：仕様書無しさん mailto:sage [2008/08/03(日) 02:21:12 ]
- >>443
そういうプログラム引き継がされて爆弾爆発させたら
爆弾仕込んだヤツは無罪で爆発させたヤツが
全部罪をかぶることになる
この図式はなんとかならないかなあ
- 445 名前：仕様書無しさん mailto:sage [2008/08/03(日) 02:24:47 ]
- まあ、完全にBUGを潰す作業をいつまでも行っていたら、永久に製品が出せないからね。
完全にBUGの無いプログラムなんて存在しないからね。
もしBUGが一切無いプログラムがあったとしたら、それは検査方法が間違っているかテスト結果にねつ造があるかのどちらかさ。
- 446 名前：80 mailto:sage [2008/08/03(日) 02:45:56 ]
- 以前にも書いたけど、テストだけを頑張るだけではだめだと思う。
部分最適化じゃなくて全体最適化ね。
以下は、テストではなく設計で逃げたケースの事例。
要求
「何年も24時間連続稼働させないといけないシステム」
設計
・非稼働時に定期的にこっそり再起動
・異常終了した場合はこっそり再起動
100%絶対に異常終了しない設計にするとテストが大変（証明できない）ので
設計で対策をこうじた。画面はあれ？ってな感じになるけどしばらくすると
復帰する。今のところクレームは無い。
- 447 名前：仕様書無しさん mailto:sage [2008/08/03(日) 10:42:24 ]
- >>80
能書き垂れる前に、1000万行のシステムで何件のテストケースを実行して、何件のバグが発生したのか早く教えろ
- 448 名前：仕様書無しさん mailto:sage [2008/08/03(日) 10:56:30 ]
- >>446
死ぬほどよくあるインフラ構成を偉そうに語る辺り働いてないか末端PGでしょ。
しかも、いきなり「非稼働時」とかまともに説明出来てないしｗ
インフラ構成に頼ったシステム安定性なんて無いに等しい
- 449 名前：仕様書無しさん mailto:sage [2008/08/03(日) 11:04:28 ]
- >>436
なるほど。>>388を直してみた。
--------
今日初めて見たが、みんな何か勘違いしてないか？
デバッグで信頼性は上げられない、デバッグは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。
デバッグでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、デバッグをしない開発手法もある。
- 450 名前：仕様書無しさん mailto:sage [2008/08/03(日) 11:45:31 ]
- >>449
あ すげーまともな文章になったww
- 451 名前：80 mailto:sage [2008/08/03(日) 16:25:33 ]
- >>448
インフラじゃないけど・・・。全然、意味通じてないみたい。
俺、文章力自信なくしてきた。
- 452 名前：80 mailto:sage [2008/08/03(日) 16:51:01 ]
- >>448
真面目に読んでくれているみたいだな。
非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない
隙間の時間ということ。
あと、システムと書いたけど厳密には、ソフトウェアシステムね。
自己診断機能と自己修復機能を連携させてるよーな感じのシステム。
実際には、ソフトが原因で異常終了することはないんだけど、
うちは、デバイスがくっついてるからそいつらのせいでシステムが
落ちたりする。
デバイス側の不具合により通信系が異常をきたした場合・・・・
ごめん、長文になりそうだから説明止めとく。
- 453 名前：388 mailto:sage [2008/08/03(日) 18:19:20 ]
- >>439
>つまり、苦情の件数が少ないほど信頼性が高いと考えられる。
それは違う「原子力発電所の緊急炉停止システム」みたいな
稼動する事がまれで、稼動での不具合が致命的になるケースもある
苦情の件数など関係なく、信頼性は稼動前から求められている
>>436,449,450
テストとデバッグは別もの
- 454 名前：448 mailto:sage [2008/08/03(日) 18:41:06 ]
- >>452
余計おかしいだろ。
>要求「何年も24時間連続稼働させないといけないシステム」
>非稼働ってのは変だな。よーは、ユーザーがシステムを使用していない隙間の時間ということ。
要求満たしてないのはお話しにならないよね？
上の文が出るって事は仕様を修正した訳でもないし。
>うちは、デバイスがくっついてるからそいつらのせいでシステムが
>落ちたりする。
この1行でもうお腹一杯です・・・
- 455 名前：仕様書無しさん mailto:sage [2008/08/03(日) 19:18:07 ]
- 最近話題の地震速報とかか？
- 456 名前：仕様書無しさん mailto:sage [2008/08/03(日) 20:03:05 ]
- >>453
> テストとデバッグは別もの
正解。よくできました。
お前自分が書いたレスよく読んでみろ。
テストとデバッグの違いの何たるかが解ってない奴の発言だ。
勉強して出直して来い。
- 457 名前：388 mailto:sage [2008/08/03(日) 22:14:06 ]
- >>456
それは間違い、俺が書いたものを理解出来ないだけの話
- 458 名前：仕様書無しさん mailto:sage [2008/08/03(日) 22:33:42 ]
- >>457
だとしたら日本語の書き方を勉強して出直して来い。
- 459 名前：388 mailto:sage [2008/08/03(日) 23:17:19 ]
- >>458
それも違う、そっちが知識が無いから理解出来ないだけの話
システム工学系の話だから、知識がない人とは話が噛み合わない
- 460 名前：仕様書無しさん mailto:sage [2008/08/03(日) 23:27:23 ]
- 理解出来てたら簡潔に説明できる。
理解出来てないから伝わらないと教わった俺はいい先生に出会えてたんだなｗ
- 461 名前：仕様書無しさん mailto:sage [2008/08/03(日) 23:35:54 ]
- なんかいつのまにか80：その他大勢
みたいな流れになってしまったな
おれとしては80みたいな特異な例よりも
ふつーに自分の現場では・・・みたいなノリが好きなんだが・
- 462 名前：仕様書無しさん mailto:sage [2008/08/04(月) 00:34:05 ]
- 自分の話が分かってもらえないなら
まずどうすれば分かってもらうかを考えるべき
分かってもらいたいのであればな。
- 463 名前：仕様書無しさん mailto:sage [2008/08/04(月) 01:15:35 ]
- 「信頼性」の定義が述べられない以上
>>388の話には何の主張も存在していない。
故に誰にも理解できるはずがない。
- 464 名前：仕様書無しさん [2008/08/04(月) 01:27:15 ]
- 『HAYST法』ってなんて読むのか知っている方いますか？？
- 465 名前：80 mailto:sage [2008/08/04(月) 07:01:35 ]
- >>453
繰り返すが、ソフトの信頼性は、苦情の件数ではなくて以下と
俺は、考えている。
「ソフトウェアの信頼性＝クレーム処理にかかった費用の少なさ」
「原子力発電所の緊急炉停止システム」のような重要な機能は、
不具合が現実のものとなった時、クレーム処理に相当金がかかるだろう。
よって、網羅的にテストすべきだと思う。
対投資効果的に
誤解があるようだけど、クレームは、あくまでも結果。
「クレーム処理費用が高くつきそうな不具合を発生させる可能性のある
機能のテストケースをきっちりやれば、絶望的な数のテストケース全部
はやらなくてもいいんじゃないか？」と言ってるだけ。
クレーム処理で高くつく機能は、顧客要求にある機能とリスクに関する機能
とかね。
- 466 名前：80 mailto:sage [2008/08/04(月) 07:04:16 ]
- >>454
悪いが、たぶん俺と >>454 はドメインが違いすぎると思う。
「顧客要求≒真の要求」とだけ書いとく。
|
 |
