2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

テストしろ!!

1 :仕様書無しさん:05/02/21 22:57:50
おまえらちゃんとテストしろ!!

2 :仕様書無しさん:05/02/21 23:20:52
ちゃんとしたよ。


脳内で。

3 :(^ー')b ◆EoOYgmEaZE :05/02/21 23:36:47
御社に指摘頂いたテストが正常に終了していないとの一文ですが、
当方の調査によりテストの内容に不備はなくテスト環境が食い違っていることが
原因だと思われる可能性が高いとの結果が出ました。
つきましては御社に行って頂いたテストの環境と当社のテスト環境との食い違いを
列挙するべきだとの意見が多く出ておりますので、お手数ですが御社において
テストされた時点での環境をお教え頂きたいのですがよろしいでしょうか。

↓ 要約

(´・ω・`) 知らんがな

4 :仕様書無しさん:05/02/21 23:48:08
したかどうかどうやって判断したんだ?

5 :仕様書無しさん:05/02/22 00:02:42
ロジック見りゃわかるんじゃボケ!












と思ってる箇所に限ってNG

6 :仕様書無しさん:05/02/22 00:44:32
当方テスト中。。。

7 :仕様書無しさん:05/02/22 00:45:02
当方、障害修正中。。。

8 :仕様書無しさん:05/02/22 06:23:37
当方、バグ生産中

9 :仕様書無しさん:05/02/22 13:37:22
【テスト】品質管理について語ろう【QA】
http://pc5.2ch.net/test/read.cgi/prog/1088135300/
テストしかやってないよ!!
http://pc5.2ch.net/test/read.cgi/prog/1054985486/


10 :仕様書無しさん:05/02/22 19:13:39
検査仕様のほうがバグだらけなんだよ!

11 :仕様書無しさん:05/02/22 22:06:21
めんどくせーからテストやめた

12 :仕様書無しさん:05/02/22 22:08:36
人力で全パス洗うテストなんて不可能

13 :仕様書無しさん:05/02/22 23:32:09
>>3
xUnitくらい使え

14 :仕様書無しさん:05/02/22 23:44:33
>>4
ふつうはテストコードを実行すればわかるはずなんだがな。

アジャイル開発ではテスト駆動開発、テストファーストを実践
することは常識だ。

それなのに>>3の奴は偉そうに御託を並べて
他人に責任転嫁しようとしプロジェクトの成功から逃げている。



15 :69式フリーPG ◆hND3Lufios :05/02/23 00:02:21
仕変の度に試験要領書を書きなおすのがウザイです。

16 :仕様書無しさん:05/02/23 00:26:31
ちゃんとしたよ。



全裸で。

17 :仕様書無しさん:05/02/23 01:29:27
>>15
build.xmlで自動化しろ


18 :仕様書無しさん:05/02/23 11:47:26
どうせ完成するまでにテストのほうが変更されるほどの仕様変更があるよ。

19 :仕様書無しさん:05/02/23 19:08:36
テストしたら完成できぬから禁止

20 :仕様書無しさん:05/02/24 23:07:08
かわいいアノ娘をテストしてよかとですか?

21 :仕様書無しさん:05/02/25 02:00:18
MSに言え!

22 :仕様書無しさん:05/02/25 02:38:11
if( x == 1 )
{
 x == 0;
}
else
{
 x == 1;
}

こんなバグが残ってたり。

23 :仕様書無しさん:05/02/25 06:42:48
public Object parse(Object o) {
  // 引数oと戻り値の型誰か適切な型に直しておいてください

  try {
    // ここ重要だったはず!手が空いたら誰かやっておくこと!
    // 忘れてもそれほど致命的じゃないと思うけど

  } catch(Exception ex) {
    // 時間にに余裕ができた場合のみ誰かお願い

  } finally {
    // 今日の昼飯味噌ラーメンと餃子食った
  }

  return null;
}

24 :仕様書無しさん:05/02/26 22:59:23
うるせーな!!
テストファーストとか言ってんじゃねぇよ!!

こちとら「動くものファースト」でずっとやってきてんだよ!
動いてるんだから文句言うな!!

25 :仕様書無しさん:05/02/26 23:38:56
DibohThunders本部
http://tmp4.2ch.net/test/read.cgi/lobby/1109409728/l50
完成しました!
おれのなやみ、相談うけつけ中!

26 :仕様書無しさん:05/02/27 00:23:41
>>24
実際そうだからわらえねーな。
仕様どおりに作るとうごかねーんだもんよ。

27 :仕様書無しさん:05/02/27 00:26:08
>>22 Warningレベルを上げとけばそんなのコンパイル時に見つかるんじゃないのか?

28 :仕様書無しさん:05/02/27 01:58:09
なんで3時間で終る処理が17時間かかるんだよ!テスト汁!!

29 :仕様書無しさん:05/02/27 06:06:21
テスタにバグ発見orz

30 :仕様書無しさん:05/02/28 02:49:13
>>18
ネガティブだな。
そういう思い込みとやる気のなさが
デスマーチを生む原因になる。
上司に進言する勇気を持て。

お前さんはテストコードを変更しなくてもすむような
方法を知らないだけだ。
デザインパターンを使え。
Facadeパターン、 Generation Gap パターンなどをうまく使えば
お前の問題も避けられる。

実コードを変更してもテストコードを変更する手間は省ける。
実コードを追加したために、追加すべきテストコードが増えるということがあるが。
しかし、そのときもさきにテストコードを書くことを怠るな。
あらたな仕様変更がきたとき、その仕様に従ってテストコードを追加せよ。
それからそのテストコードに倣って実コードを書き加えよ。
テストコードは雛形みたいなものだ。
まずは型(テストコード)を作ってその型にあわせて実コードをつくるといった手法だ。

縫い物でいえばまずはしつけ縫い(テストコード)をしてから
ミシンで実際の糸を縫う(実コード)手法にも似ているな。
ただししつけ縫いの場合は分離はされていないが、考え方としてはそれほどわかりにくくはないほうだろうか。




31 :仕様書無しさん:05/02/28 03:00:47
>>29
テストコードを書くときはしっかりやれ。
テストコードのバグを減らすには
なるべくわざとハードコーディングをすること。
なるべくforやwhileなどのループ文の使用も避けて
できるかぎり展開すること。

このように実コードでは許されない(推奨されない)行為は
テストコードではあえて行使することが望ましい。

そうすることでコードをみただけで実プログラムの
クラスやメソッドの使い方がよくわかり、
どうやって動くのか顧客も初心者も理解しやすい。
ようするに見本を作れということだ。
テストコードとは実コードのクラス、メソッドをどうやって
動かすかの見本になるのだ。

テストコードには間違いは書かないこと。
テストが間違えれば本末転倒だ。
だからこそテストファーストが重要視される。
テストコードにはしっかりとコメントを書くことが望ましいとされている。
テストコードにコメントを書けば実コードにはほとんどコメントはいらないとも言われている。
(ただし、実コードにはクラス、メソッドの概要、どういう役割を果たすクラスなのか、メソッドの入出力などの
コメントだけはちゃんと書いておく)


32 :仕様書無しさん:05/02/28 03:00:57

先に実コードを書いてからテストコードを書いてからではどちらが正しいのか
わからなくなって混乱する者もいることだろう。
どうしてもテストファーストがしずらいなら
テスト駆動開発をするのがお勧めだ。
テストしながら開発できるのだ
テストコードを書いてはテストを実行(レッドフェーズ)、実コードをかいては実行
赤いバーが緑のバーになるまで何度もコードを書き直すのだ。
緑のバーになったらテストコードにさらに追加したい機能を書き加える。
ここでは大抵ほぼ必ずレッドフェース赤いバー)だ。
そしたらまた実コードに機能を追加。
グリーンフェーズがやってくるまで緑のバーがでるまで
何度も実コードを修正し、何度もテストケースを実行する。
これを繰り返すのがテストファーストだ。



33 :仕様書無しさん:05/02/28 03:34:03
時間がいくらあっても足りねぇなw
トータルで考えると早いってか?いやいやトータルで考えても十分遅いよ。
TFが経済的に有効なのは大規模かつミスが一つも許されない案件に対してのみ。

34 :仕様書無しさん:05/02/28 03:45:34
>>33
ふうむ。そうなのか。俺も常々そうなんじゃないかと思っていたが。サンクス
貴重な一意見として拝聴しておく。
納期が短くなるという業界の傾向と決定的に対立しているのかも知れないね。

35 :仕様書無しさん:05/02/28 07:05:15
つかぬことを聞くが、「ミスが許される案件」ってのはどんな案件だ?

36 :仕様書無しさん:05/02/28 09:16:56
使われることの無いシステム
若しくは
途中放棄が決定されている案件



37 :仕様書無しさん:05/02/28 09:24:04
>>33
> 時間がいくらあっても足りねぇなw
> トータルで考えると早いってか?いやいやトータルで考えても十分遅いよ。
> TFが経済的に有効なのは大規模かつミスが一つも許されない案件に対してのみ。

ミスが許されないとはどの程度のどの種類のミスが許されないものをいっているのか?
ミッションクリティカル系のことならわかるが
クリティカルでないものでもテストは役に立つ。
あるコードを修正したとき、その修正が間違っているかどうかは
テストコードを実行すればすぐわかる。
実コードを修正すれば修正するほどテストファースト、テスト駆動開発の
威力が見えてくる。修正が一切なく、作ったら終わり、テストもろくにしない、
顧客からのバグ報告もほとんど無いというならテストファーストは時間がなくもったいない
と感じるかもしれない。
しかし実際にはバグ報告は多い。テストファーストを怠ると間違いの早期発見がしづらくなる。
自分のコードの間違いを速めに見つけることで自信がわいてくる。
そのコードの信頼性も高まるしコードをどのように修正変更したら良くないかは
テストコードを実行すればすぐにわかる。
それがテストファーストの威力だ。
長期開発や引継ぎが必要な開発ではテストファースト、テスト駆動開発は重宝する。
自分のプロジェクトが将来誰かに引き継がれる可能性があるなら、
ぜひともテストファースト、テスト駆動開発をすることをお勧めする。
そうすることによって引継ぎ人から何か恩を返されるかもしれないぞ。



38 :仕様書無しさん:05/02/28 09:24:59
>>33
テストケースクラスをつくるのかそんなに大変か?
getString()というメソッドがあるなら
testGetString()というメソッドに
assertなんたらというメソッドを呼び出すコードを書くだけでいいんだぞ。
どんなassertを書くkは仕様次第。
かといって仕様変更に弱いわけではない。仕様変更に耐えられる手段は上でも述べられている。

テストケースクラスを管理する方法も知らないんじゃなかろうな。
テストを自動化する方法も知らないがために時間がないと叫んでいるんじゃなかろうか。

テストをつくるのがそんなに嫌だったら
まずは実コードで空のクラス、空のメソッドを作れ。
入出力だけはわかっているが実装は無いクラス。

それを作ったらそこで初めてテストケースクラスを作れ。

そうすれば大体見通しが見えてくる。


39 :仕様書無しさん:05/02/28 09:26:30
>>36
そんな仕事ばかりやっているのか?
そんな仕事ばかりだったらテストファーストをする必要性もほとんどないわな。

顧客が突然気が変わることがなければ。
突然、やっぱり破棄せず運用を継続するなんて言い出す顧客は迷惑だからな

40 :仕様書無しさん:05/02/28 11:29:09
TDD厨のニオイがする

41 :仕様書無しさん:05/03/01 00:53:12
>グリーンフェーズがやってくるまで緑のバーがでるまで
>何度も実コードを修正し、何度もテストケースを実行する。

ばか?
ふぇきと汁!

42 :仕様書無しさん:05/03/02 23:48:58
今、IT業界でテストの重要性が非常に大きく認知されてきている。
とくにインド、中国はその勢いが非常に激しい。
日本はものを作ることだけを考えていたため
ソフトウェア管理品質についてはろくに考える能力がなかった。
そのため日本はテスト開発についてインド、中国に後れを取っている。
このままでは、日本のソフトウェアの信頼度がインド、中国に負けてしまい、
日本のソフトウェアの人気が低下し、価値が下がってしまう。
それは大変なことだ。日本のプログラマをますます窮地に陥れることになってしまう。

さあ、いまこそテストファースト、テスト駆動開発を実践しよう!!!!!

43 :仕様書無しさん:05/03/03 00:07:08
かと言って、見積もりにテスト工数入れると難色示すんだよな。

44 :仕様書無しさん:05/03/03 00:15:45
どうせ輸出なんてしないから無問題。

45 :仕様書無しさん:05/03/03 03:08:08
テストファースト? この新しモノ好きが!!!!!!!

ってJUnit使う前は思ってたんだよ。
意外と手間じゃないんだよな、テストコード書くのって。
今はC#で開発してるんだが、xUnitがあれば・・・って思う事が死ぬほどあるぞ。
1つ修正する度に最初からテストやりなおしってめんどくさすぎる。

46 :仕様書無しさん:05/03/03 03:15:07
>>45
マインスイーパーを作りたいので、
そのテストコードを書いてくれませんか?

それが手間じゃないんなら俺もJUnit使う。

47 :仕様書無しさん:05/03/03 03:20:22
>>46
テストコードを書くのでまず仕様書を書いてもらえませんか?

48 :仕様書無しさん:05/03/03 03:30:47
XPに仕様書などない!

49 :仕様書無しさん:05/03/03 04:53:45
中国とインドとの競争が怖いなら、2chをそれぞれの国に作ればいい。
能率がた落ちになること間違いなし。

50 :仕様書無しさん:05/03/03 05:09:41
中国は規制されるから無理ぽ

51 :仕様書無しさん:05/03/03 08:18:03
>>45
C#ならNUNitがあるだろ

52 :仕様書無しさん:05/03/03 08:18:45
Perl厨はPerlUnit
PHP厨はPHPUnit
C++厨はCppUnit
VB厨はVBUnit


53 :仕様書無しさん:05/03/03 08:19:38
JunitX
Jakarta Cactus
MockObject
HttpUnit
XMLUnit
HtmlUNit
DbUnit


これらを使いこなせ!

54 :仕様書無しさん:05/03/03 08:21:34
COBOLUnit

55 :仕様書無しさん:05/03/03 23:58:53
さあ、単体テストをしろ!

56 :仕様書無しさん:05/03/04 00:59:01
C厨ですが、何ユニットを使えばよろしかとですか

57 :仕様書無しさん:05/03/04 01:15:24
cUnit

58 :仕様書無しさん:05/03/04 01:15:47
CUnitがあるだろ

59 :仕様書無しさん:05/03/04 01:44:38
>>54
マジであるの?

60 :仕様書無しさん:05/03/06 01:07:10
10人半年のC案件ですがcunitって言葉出る気配ありません
テストパッケージ自作してデバグはGDBでやれとのこと

ドキュンですか?


61 :仕様書無しさん:05/03/06 01:22:21
             /    ,       `ヽ.
            /〃//,. ,ィl/|l ト、 !、 、  ヽ
          ー'´| | l |1 | !l. l| ! | l.|ヽ ! !、 ',
             YレV!ヒエ「! |l.「_ト!Ll」| l l  l
           ! lハイJ |  ´|_jヽ. リ,! ! l. l |
             |l |l.} ー ,   L _,ハl.lトl l. | l   ?
             |l ilト、   n  ''  ,1l|ィ| |l l |
           _ 二,ニ^tュ--ェ_t1」l.|l !リ|_lノ
       r7´   f r┐| 〔/ミヽ>,-、 ̄´
       Y       ー个‐'t  ハ-、_'ゝ、
        ヽ ._・ rく ̄ヽト-'丿  ヽ l

62 :仕様書無しさん:05/03/06 01:42:22
JUnitがOKでNUnitがNG
意味わかんねぇ!

63 :仕様書無しさん:05/03/06 06:08:59
いっつも余所が作ったライブラリやDLLの不具合で出荷の判定で引っかかる。
なんか俺が悪いみたいに見られる。
しかも期日どおりに出てこなくて、やっと出てきたと思ったら
仕様と食い違ったり漏れたりしている。
結局自分で直せるところ直して使うが、最終的にもっと致命的で手が出ない場所のバグに遭遇する。

いい加減にしろ。


64 :仕様書無しさん:05/03/06 11:57:07
>>56
CppUnitで補え


65 :仕様書無しさん:05/03/06 11:57:53
http://blues.se.uec.ac.jp/mt/swtest/

テストの自動化による改善



テストが単純作業だと思っているマネジャーは、今でも少なくありません。
新人でも使えない奴でもいいから、とにかく人員を投入して残業をさせろ、
という指示を出すタイプですね。こうしたマネジャーの興味を強く惹くのは、
大きくわけて2つの誘惑です。一つは、とにかく安い外注を使うこと。パートでも、
オフショアでも構いません。外注を叩いて叩いて、同じ予算でなるべく多くの人員
を投入しようとします。もちろん技術力の評価など二の次で、せいぜい過去に同種
のプロジェクトをこなしたかどうか程度しか確認しません。

もう一つは、テストの自動化です。テストツールを買いさえすれば、ノウハウいらずで
大量のテストができるようになるのではないか、という発想ですね。皆さんの周りには、
こうしたマネジャーはいらっしゃいませんか?

しかし、テストを自動化するだけでテストが楽になる、というのは幻想に過ぎません。
最近はテストツールのベンダやリセラの営業さんだって、そんなヒドイ嘘はつきません
(うちのツールを買えば万事オッケー、などという営業さんは追い返しましょう)。テストの
自動化は、使いこなせば大きな効果を挙げられますが、何もしないと宝の持ち腐れになってしまいます。

17 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)