- 1 名前：仕様書無しさん [2008/06/28(土) 19:49:20 ]
- 何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
って...
コーディングが終わってやっと３割終わったかどうかってところだろが。
コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、
正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。
本当に理解してんのか？ コーディングが終わってやっとスタートラインに立ったぐらいの気持ち
でいろよ、ってくヘラヘラしやがって。
こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、
徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。
どんな優秀な奴だって、人間だもの、間違いを犯す。バグを生み出す。それを極力未然に防ぐのが
テストだろ。いつバグが判明するかとドキドキしながら納品後の時間を過ごすか、自信と満足感を
もって笑顔で過ごすか。どちらがいいか自明のことだろ。
プログラミングはなぁ、テストに始まりテストに終わるんだよ。要件を理解し、その中に潜む異常
パターンを見抜き、どんだけ抜かりなくテストをやれるかが一流とカスを分かつ分水嶺だ。
コーディングなんかできてあたり前、肝心なのはテストだ。テストを極めてこそ、一流のプログラ
マーって呼べるんだよ。
この馬鹿者どもが。
- 205 名前：166 mailto:sage [2008/07/06(日) 02:10:28 ]
- >>199
>外部仕様書に相当するものは、うちではインターフェース仕様書と
>呼んでいる。
>インターフェース仕様書は、その実現を記した「設計書」と区別される。
>さらに、インターフェース仕様書の実現方法は複数あるので、
>インターフェース仕様書１つに対して、複数の設計書が存在することもある。
だから何？
テストケースは、インターフェース仕様の一部にすべきという
のが私の論旨なのだが・・・
なぜに、80さんのプロジェクトのドキュメント体型の話をなさる？
>外部仕様書と内部仕様書という言葉を使っているということは、
>オブジェクト指向とか使ってないの？言語は何？
オブジェクト指向だろうが何だろうが、
−プログラムには外部仕様と内部仕様とがある
−−外部仕様はこのプログラムをどう使うかを定義するモノで、
入力・出力・副作用(+前提条件・例外)で表される
−−内部仕様は外部仕様の実現手段
というのは変わらないと思けど、、、
何が言いたいのかよく分かりません。
- 206 名前：80 mailto:sage [2008/07/06(日) 08:03:32 ]
- >>202
銀行とか証券とかそういうのじゃないよ。って言うか全く違う。
- 207 名前：80 mailto:sage [2008/07/06(日) 08:25:39 ]
- >>205
ちゃんと整理しよう。
システムの内部＝内部仕様書
システムの外部＝外部仕様書
だろ。まぁ、一見とてもわかりやすいよな。
では質問
１．システム内部とシステム外部の境界は、どちらの仕様書に書くの？
２．開発するシステムに対しして内部と外部があるわな。
開発範囲＝システムとした場合、外部とは、開発範囲の外側と言う
ことにならないか？
たぶん。
205 の頭の中を整理すると
-> 外部仕様書＝インターフェース仕様書、ユースケース仕様書
内部仕様書＝設計書
なんだと思う。
問題点１
システムの外部は、開発対象ではない。
問題店２
レイヤー、サブシステムに分割されているシステムの場合、
あるサブシステムの外部仕様は、上位のサブシステムの内部仕様書
になる（全く一緒ではないが）。つまり、外部と内部でわけると
仕様書に重複が生じる。
また、インターフェースは、レイヤーやサブシステムに縛られない。
つまり、単に外部仕様とすることはできない。
問題点３
インターフェースを誤解している。
インターフェースは、極めて外部に近い内部ということになる。
- 208 名前：80 mailto:sage [2008/07/06(日) 08:33:20 ]
- >>205
うちは、インターフェースに対するテストを重視している。これを
うちは、システムテスト（サブシステム）テストと呼んでいる。
システムの実現側つまり、ソースコードの隅積みまで
行うテスト（単体テスト、ユニットテスト）は、普通にやってる。
システムテストほど重要視していない。
>>205
の最大の矛盾は、外部仕様書に基づいてテストを単体テストとかユニットテスト
と呼んでいることだ。単体テストは、内部のテストじゃないのか？
外部仕様書が書かれていることがちゃんとできているか＝システムテスト
内部仕様書に書かれていることがちゃんとできているか＝ユニットテスト
だと思うが？だとすると、205は単体テストをやっていないことになるな。
- 209 名前：仕様書無しさん mailto:sage [2008/07/06(日) 09:07:05 ]
- としたら、学術系か軍事系か宇宙・航空系か・・・。
まあ
166の言いたい単体・ユニットテストは
>システムのテスト手法の一つで、個々のモジュール(部品)のみを対象としたテスト。
>対象のモジュールが仕様書で要求された機能や性能を満たしているかどうかをテストする。
>複数のモジュールを組み合わせて行なうテストは結合テスト、システム全体を対象に行なうテストはシステムテストという。
80の言いたいのは単体・ユニットテストは
>単体テストとは、プログラムを検証する作業の中でも、プログラムを手続きや関数といった個々の機能ごとに分割し、
>そのそれぞれについて動作検証を行う手法のことである。
大体こんな感じだろ、粒度の問題でその辺変わるので双方間違ってないように見えるけどな。
双方ともシステムやサブシステム”未満”のテストを言っているが、粒度によっては、外部インターフェースとのやり取り
をするレベルだと外部仕様書レベル元に単体・ユニットテストやったりするわけだし。
- 210 名前：80 mailto:sage [2008/07/06(日) 09:27:55 ]
- 仕様書・・・システムが、ユーザー（人、外部システム）に提供する利益
が記されている。
設計書・・・システムが、仕様をどのように実現するかが記されている
仕様書に基づいたテスト・・・システムテスト
設計書に基づいたテスト・・・ユニットテスト
仕様書や設計書はシステム、サブシステム、コンポーネントといった
開発対象それぞれに対して作成される。
○○システム仕様書、○○システム設計書という具合
で、インターフェース仕様書は、インターフェースのことだけ書いた
仕様書。
仕様書と設計書だと、仕様書の方が重要。
人と人とのコミュニケーションやレビューの対象は、おもに仕様書。
設計書は、開発スタイルによるが、自分で設計書書いてプログラミングする
場合は、事細かに書かずに、ユニットテスト（xUnit）で代用することもできる。
ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
それに、テストコードを書くのはコスト高だ。
これを解決するのに何年か前から試行錯誤を繰り返している。
その解決方法のひとつが、xUnit以外の専用のテストツールを使ったテスト
と第三者によるユニットテストだ。
- 211 名前：80 mailto:sage [2008/07/06(日) 09:31:50 ]
- >>209
粒度は、開発範囲（スコープ）と詳細度（レベル）の２次元で定義すると。
今回のケースをとらえやすくなる。
今、ごちゃごちゃになっているのは、スコープを無視して話をしているからだ
。外部と内部という簡単な方法で開発対象を規定しようとしているところに
無理があると思ったから、粒度（スコープとレベル）を物差しに加えてみた。
- 212 名前：80 mailto:sage [2008/07/06(日) 10:17:18 ]
- >>166 の言ってるユニットテストは、
スコープ＝小さなシステム（サブシステム、コンポーネント、ライブラリ）
のシステムテスト（外部から見たふるまいのテスト）だと思う。
- 213 名前：80 mailto:sage [2008/07/06(日) 10:18:37 ]
- >>209
の言うとおり、粒度に惑わされるが、どんなにスコープが小さくとも
仕様書に基づいたテストは、全部、システムテストだ。
つまり、システムテストは、システム（サブシステム、コンポーネント）の
境界をテストすることだと言える。
システムをサブシステムやコンポーネントに分割すれば、
システムテストの件数が増大する。分割しなければ、ユニットテストの
件数が増大する。
分割していないという事は、システムの詳細を仕様化していない
ことになりテスト工数が増大する。
よーは、システムを適度に分割して、分割した境界についてテストを行う
ことが重要で、単純にユニットテストを強化しても不具合は減らないと
言いたいのだ。
まぁ、よくよく聞けば。同じ事を言っているみたいなので安心した。
要点は、
・テストファースト
→仕様をテスト可能かどうか検証してから設計する。
・粒度が高い場合
システムを分割して、分割したサブシステムを仕様化する。
そして、その際にテストファーストを実施する。
・粒度が低い場合
一人で切り盛りできるレベルになったら、プログラマーに任せる。
あと、俺のミスだが、
ユニットテストをテスターが行うというのは、厳密には、
「粒度の小さいシステムテストもテスターが行う。」だ。
粒度の小さいシステムテスト＝ユニットテストと混同してたな。
- 214 名前：仕様書無しさん mailto:sage [2008/07/06(日) 12:44:42 ]
- お前はまず開発工程の定義から勉強して出直して来い
- 215 名前：仕様書無しさん mailto:sage [2008/07/06(日) 13:20:18 ]
- >>214
ウォーターフォールに慣れすぎた古き人々よ
落として焼かねば変わらんのか？
- 216 名前：仕様書無しさん mailto:sage [2008/07/06(日) 13:52:45 ]
- 要求仕様を満たしているかをテストするって考えがまるっきり無いんだな。
自社製品ならまだ知らず、顧客から注文された製品なら、重要な事なのに。
- 217 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:18:27 ]
- > 仕様書に基づいたテストは、全部、システムテストだ。
なら、ユニットテストは全部システムテストってことになるな。
- 218 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:23:08 ]
- ユニットテスト以外で、
どうやってシステムテストをやっているのだろうか？
いや、果たしてやれるのだろうか？
- 219 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:23:56 ]
- > ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
その点、システムテストは、レベルが低くてもやることができる。と？
- 220 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:24:48 ]
- ＞ これを解決するのに何年か前から試行錯誤を繰り返している。
＞ その解決方法のひとつが、xUnit以外の専用のテストツールを使ったテスト
＞ と第三者によるユニットテストだ。
残念ながらユニットテストをやることは必須。
システムテストでは、ユニットテストの代用にはならない。
なぜなら、システムテストは適当なテストだから。
- 221 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:26:58 ]
- 「適当なテスト」の意味は、レベルが低いやつでもできるテストであり
バグがないことを保障していない。
値を入れて、それらしい値がでてくれば、それでオッケー的なもの。
例外的なことを考慮していない。異常な値を入れたときどうなるかは
一切考えていない。
- 222 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:28:48 ]
- システムテストでどんな内容をテストしているかを
具体的にいってくれれば、それがユニットテストでやれるってことを
証明できるのになぁｗ
- 223 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:42:03 ]
- >>222
そりゃないんじゃないか？
名前が違うのかも知れないけど、うちのシステムテストって
・チームAが作ったデータベース周り
・チームBが作った入出力周り
・チームCが作った夜間バッチ周り
を、一斉に動かしてどこがボトルネックになってるか調べるテストだけども。
（データベースと入出力のAPIとか応答速度は決めて、その速度出るのはテスト済み）
- 224 名前：仕様書無しさん mailto:sage [2008/07/06(日) 16:59:40 ]
- システムテストとユニットテストはやることの対象が違うんだから、
システムテストをいくらしたところで
ユニットテストの工数は減らないよ。
そもそも減らしてはいけない。減らす = サボるってことだから。
システムテストはユニットテストの代わりにはならない。
システムテストをさぼることで、無駄なユニットテストをやらされたとしたら、
それはユニットテストが問題なのではなく、システムテストやったやつがヘボで、
そのとばっちりを食らっただけの話。
- 225 名前：仕様書無しさん mailto:sage [2008/07/06(日) 17:04:33 ]
- >>223
ボトルネックになっているとわかった後どうする？
修正するよね？
そのときユニットテストがあれば、
不具合を入れることなくパフォーマンスのみを
あげることができたって自信が持てるよね？
ほらどうだい。ユニットテストってすばらしいだろう？
それにボトルネックになっているのを見極めるために、
同じ条件で同じ操作を何度も繰り返すものだ。
どうだい。ユニットテストで自動化されていればそれも可能だろう？
- 226 名前：仕様書無しさん mailto:sage [2008/07/06(日) 17:06:18 ]
- >>225
だからよ。ユニットテストはやってるって書いてるだろう？
>（データベースと入出力のAPIとか応答速度は決めて、その速度出るのはテスト済み）
>システムテストでどんな内容をテストしているかを
>具体的にいってくれれば、それがユニットテストでやれるってことを
>証明できるのになぁｗ
↑は、おかしいだろ。
ユニットテストで出来ることと、システムテストでできることは別じゃね？
- 227 名前：80 mailto:sage [2008/07/06(日) 17:20:08 ]
- >>217
そもそも、ユニットテストという言葉が微妙なんだ。
>>219
システムテストは複数のテスターによって実行できる。
テスターは単価が安い。
- 228 名前：80 mailto:sage [2008/07/06(日) 17:26:31 ]
- >>225
の言っているユニットテストはなんなの？
「テスト用のプログラムと結合して自動的にテストを行う」事か？
- 229 名前：80 mailto:sage [2008/07/06(日) 18:10:30 ]
- >>225
>システムテストでどんな内容をテストしているかを
>具体的にいってくれれば、それがユニットテストでやれるってことを
>証明できるのになぁｗ
もし証明できるなら、逆も証明することになる。
システムテストとユニットテストは等価変換できるという、
相当、大それたことを言っていることに気づこう。
- 230 名前：仕様書無しさん mailto:sage [2008/07/06(日) 18:47:53 ]
- 80は色々いっているけどプログラムの動作レベルに関して言及していない、
テストは概ねブラックボックスに関して述べている。
よりはっきりいえば、詳細なホワイトボックステストをテスターがやるのは意味が無いといっているとも思われる。
設計がパーペキなら問題ないし(バグはプログラマーの問題)
設計にバグがあるなら差し戻ししてそこからグラマーが直せばよいとの事。
設計通りにすればとりあえずうまくいうと言う考え。
ホワイトボックスのテストはテストツールでやるとかともいっているねー。
それだけの話。
- 231 名前：80 mailto:sage [2008/07/06(日) 19:01:54 ]
- >>230
残念ながら全然違う。
俺が言ってるのは、ホワイトボックステストを最小限にするという戦略。
部品化を進めて、各部品の仕様書を書く。仕様書に基づいて各部品の
ブラックボックステストを行うのだ。
ホワイトボックステストを最小限にするのに部品化のほかに
「インクリメンタル型の開発」がある。簡単に言えば一気に作り上げて
一気にテストをするのではなく、少しづつ作って少しづつテストをする
のだ。そうすることで、ブラックボックステストとホワイトボックステストの
乖離を最小限にする。
以下の２つを実現したのち、ブラックボックステストが効果的になる。
１．ホワイトボックステストの規模を最小化する。
２．ホワイトボックステストとブラックボックステストの乖離を最少化する。
「問題の難しさ」を「問題の量」に転化したのだから、当然、
ブラックボックステストの件数がかなり多くなる。
これを、テスト自動化によりコストを減らしているわけだ。
まぁ、全部が完全にうまくいっているわけではないが、これ以外に
良い方法を俺は知らない。勉強不足かもしれないので、ヒントを
探しているところさ。
- 232 名前：仕様書無しさん mailto:sage [2008/07/06(日) 20:23:46 ]
- 一言で言えば、粒度を上げて問題の均質化を狙ったわけね。
でもそれって、改良やパフォーマンスチューニング等で崩れそうなもんだけど。
マルチスレッドに起因するバグ発生したら地獄だな。
- 233 名前：仕様書無しさん mailto:sage [2008/07/07(月) 03:22:05 ]
- テストを軽視するのは御役所もいっしょ。
特殊なケースと無理矢理な変数当てはめて机上ではうまくいく。
うまくいくから道路作れ。それ、レッツらゴーってなもんでしょ。
日本という体質そのものがテスト軽視の傾向があるんだよ。
- 234 名前：仕様書無しさん mailto:sage [2008/07/07(月) 05:35:05 ]
- >>231
机上の空論。
実戦経験をつめ。
- 235 名前：仕様書無しさん mailto:sage [2008/07/07(月) 08:11:18 ]
- おまいら一生懸命語ってるけどテストなんて
そんなに重視してないよ
- 236 名前：仕様書無しさん mailto:sage [2008/07/07(月) 08:26:33 ]
- でもテストって大事なんだぜ？
今の現場も結合テスト甘くみやがったせいで
客にブチ切れられて納期延ばし、
メンバーも増員毎日深夜まで再テストだ
そう、つまり黒から一気に赤化
- 237 名前：仕様書無しさん mailto:sage [2008/07/07(月) 11:40:51 ]
- >>235
マ辞めちまえ。おまい迷惑。
- 238 名前：仕様書無しさん mailto:sage [2008/07/07(月) 11:45:04 ]
- >>237
俺が辞めたら客が困るんだぜ
- 239 名前：仕様書無しさん mailto:sage [2008/07/07(月) 11:47:57 ]
- >>238
そう思っているのはおまいだけw
- 240 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:01:08 ]
- >>239
言うと思ったｗ
- 241 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:30:29 ]
- わたしが死んでもわたしの代わり(にテストさせられる可哀想なヤツ)は居るもの
- 242 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:40:45 ]
- >>239
勘違いも甚だしいな。
お前が辞めた方が客は喜ぶぞ。
テストの不十分な商品渡されるよりよっぽど安心だろ。
- 243 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:43:34 ]
- レス先間違えてね？
- 244 名前：仕様書無しさん mailto:sage [2008/07/07(月) 12:55:08 ]
- 専ブラの番号ズレたんじゃね？
- 245 名前：仕様書無しさん mailto:sage [2008/07/07(月) 16:29:11 ]
- >>241
そんな（おれらに被害が及ぶような）こと言うなよ
- 246 名前：仕様書無しさん mailto:sage [2008/07/07(月) 16:34:17 ]
- >>245
だって（めんどくさいんだもの）仕方ないじゃない
- 247 名前：仕様書無しさん mailto:sage [2008/07/07(月) 19:53:15 ]
- >>210
> 仕様書・・・システムが、ユーザー（人、外部システム）に提供する利益
> が記されている。
世間では、その部分を要件定義書と外部設計書にわけてるんだよ。
例えばユーザインターフェース仕様。これはクライアントが要件として出す場合もあるが
それはまれで、普通はシステムを作る方が設計する。
> 仕様書に基づいたテスト・・・システムテスト
> 設計書に基づいたテスト・・・ユニットテスト
なるほど、「俺定義」で今まで話してたのはわかった。
> 仕様書や設計書はシステム、サブシステム、コンポーネントといった
> 開発対象それぞれに対して作成される。
サブシステム分割や、何をコンポーネント化するかというのは、内部設計と普通は言う。
なので顧客レビューはせず、80定義で言う所の仕様書は書かない。
> ユニットテストはもろ刃の剣で、プログラマーのレベルが高い事が前提だ。
> それに、テストコードを書くのはコスト高だ。
ユニットテストのケースレビューやコードレビューをするという概念は全くないの？
顧客はユニットテストにはお金を出さないというようなことを繰り返し言ってるが、
まったくそんなことない。顧客は品質にもお金を払ってる。
ユニットテストでバグを潰そうが、システムテストでバグを潰そうが、顧客が知ったこっちゃ
ないのは同意する。
- 248 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:02:58 ]
- （続き）
「効率の悪いユニットテスト」や「品質の低いユニットテスト」は確かに否定されるべきだが、
だからと言って、ユニットテストが否定されるものではない。
バグは潰すのが早ければ早いほど、その修正コストは低くなる。これには80も同意してくれる
ものと思う。
「効率の悪いユニットテスト」や「品質の低いユニットテスト」が、開発コストを押し上げている
のであれば、「効率の良いユニットテスト」「品質の高いユニットテスト」に出来ないかを考えるのが
まず第一だ。なぜなら、バグは潰すのが早ければ早いほど修正コストが低いからだ。
修正コストが低ければ、開発コスト全体も低くなり、それが顧客のメリットになる。
ユニットテストをほとんどやらずに、第三者によるシステムテストに力を入れるという方法論も
あるだろう。
俺自身は、この方法論を全く支持しないが、スキルの低いプログラマが多数いるチームであれば
そのような方法論を取った方が、全体のコストが下がるのかもしれない。
しかし、方法論として提示するのであれば、システムテスト重視の方が品質が高くなる理由（根拠）と
ある程度のメトリクスを提示しなければ、第三者を納得させることはできないと思う。
- 249 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:18:40 ]
- サブシステムやコンポーネントやレイヤーを合わせてテストするのは、普通、結合テストと言います。
- 250 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:28:37 ]
- （少し追加）
>>231
> これを、テスト自動化によりコストを減らしているわけだ。
今のところ、80の発言から読み取れる「削減できているもの」は、このシステムテスト
（ブラックボックステスト）実行コストのみだ。
本気でテストの自動化をやってるところは、自動化されたテストの実行コストなど、
テスト全体のコストにほとんど影響を与えないことを知っている。
つまり、本当に自動化されているなら、実行するPCの台数を増やし、夜間に動作
させればよいのである。
問題は、自動化にかかるコストと、第三者検証の場合は、テスタ−プログラマ間の
コミュニケーションコスト、プログラマチームからテスタチームへ引き渡すリソース管理、
出荷判定（100%バグを修正できない場合の判定という意味での）などのコストをどう
減らすかなんだよ。
- 251 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:31:23 ]
- （書き忘れ）
テストのコストを引き上げる要因をひとつ忘れていた。
自動化テストの場合、それが正しいテストかどうかのチェックに非常に時間を取られる。
事前条件は正しいのか、テストの内容は正しいのか、事後条件は正しいのか、（自動）確認は
正しく行えているかなど。
- 252 名前：仕様書無しさん mailto:sage [2008/07/07(月) 20:43:11 ]
- ・PGが作ったものが「作ったとおりに」動く事（あるパス通したら落ちる、ボタンはあるけど反応がない、など）
単体としてはまともに動く事を確認するのが単体テスト
・１PGから複数PG、はては複数チームが作ったものが、ちゃんと連動すること
お客様にうたった仕様どおりの動作をしている事を確認するのが結合テスト
・（結合との位置づけがあいまいなんだけど）
お客様レベルでの操作をしてもらって、「うん、ちゃんと動いてますね」
って確認を本番環境、現地レベルで取るのがシステムテスト、そして最終的な運用テスト
とか位置づけちゃってたわ、ワタシ
>>248の言うように、単体レベルでの不備はテスト初期（というか開発途中）のレベルで
とっておいた方がいいと思う、コストというより、後の方のテストはざるの目が粗いから
思わぬ不具合（ある異常系パスを通るとシステム全体がダウンしてしまう、など）を
見逃してしまう可能性が高い（下位のレベルの不具合は上位のテストからはブラックボックスなので）
- 253 名前：仕様書無しさん mailto:sage [2008/07/07(月) 21:08:02 ]
- 最後のは、普通、受け入れテストと言いますね。
- 254 名前：仕様書無しさん mailto:sage [2008/07/07(月) 21:17:01 ]
- >>253
thx
- 255 名前：仕様書無しさん mailto:sage [2008/07/07(月) 21:58:28 ]
- テストが億劫になるｽﾚだなぁ
- 256 名前：仕様書無しさん mailto:sage [2008/07/07(月) 23:25:27 ]
- 「システムテスト」が設計(design)ではなく、仕様(specification)に基づくものだという80の意見には同意する。
80が言う方法論には同意しないが。
依然として機能テスト以外のテストに関する話が出てこないが、よくまとまっているページを見つけたので
紹介しておく。
en.wikipedia.org/wiki/System_testing
システムテストでは、機能的に要件とマッチしていることを保証するとともに、上記ページにあるようなテストを
行うのが一般的だと思う。
まぁ普通は機能外要件を要件定義書に書けるチームはほとんど無いと思うが、「システムテスト」工程で
行うもんなんだよね。
また、いわゆる「内部設計」以外を「仕様書」におこして、それをクライアントレビューにかけるというのは、
双方にとって負担が大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、業界的に合意が
形成されていくのかもしれないね。
- 257 名前：仕様書無しさん mailto:sage [2008/07/08(火) 00:11:34 ]
- >>256
wikiを良く纏まったページって紹介するのはなんだと思う。
80の言っている事だけど
一つの方法論だけど・・・、
>「問題の難しさ」を「問題の量」に転化したのだから、当然、
>ブラックボックステストの件数がかなり多くなる。
>これを、テスト自動化によりコストを減らしているわけだ。
テスト項目表作成も自動化しないとコストかかるね。
正確には「正しい｣テスト項目表の作成。
ぶっちゃけ、テストにコストがかかるのではなくて、
テスト項目の洗い出しにコストがかかり、
さらにその妥当性をだすのにコストがかかる。
半年後のユーザの意見を聞きたいな、ボトルネックが山に
様にできてそうだ。
（まあ、最近のPCは出来が良いので問題おこんないって前提だろうけど）
- 258 名前：80 mailto:sage [2008/07/08(火) 01:01:27 ]
- >>256
■機能要件
機能要件は、インクリメンタル型で開発している。仕様書に基づいて
要求が満たされているかをチェックするのに重点が置かれる。
■フレームワーク
非機能要件は、フレームワークに含まれるのがほとんどで、イテレーティブ
型で開発をしている。
実際には、リファクタリングをしまくるわけだ。つまり、外的な
ふるまいだけをテストして、内部はガンガン変えていくのだ。
なので、単体テストは軽視され回帰テストが重要視される傾向がある。
■再利用可能なコンポーネント
レイヤーの低い位置にいる、再利用可能なコンポーネントは、
不具合が全体に波及するので、ユニットテストからコツコツ積み上げる。
ユニットテストは低レベルのコンポーネント（ライブラリ）開発で役に立つ。
- 259 名前：80 mailto:sage [2008/07/08(火) 01:09:01 ]
- >>256
>また、いわゆる「内部設計」以外を「仕様書」におこして、それを
>クライアントレビューにかけるというのは、 双方にとって負担が
>大きいと思うね。工事進行基準が始まれば、「要件定義書」の範囲も、
>業界的に合意が形成されていくのかもしれないね。
開発プロジェクト内で閉じるレビューがほとんど。レビューは、一種の
テストだから軽視してはいけない。それに、ドキュメント
に関しては、CMMとかISOとかやってるので結局書かなくてはいけない。
- 260 名前：仕様書無しさん mailto:sage [2008/07/08(火) 01:58:40 ]
- 80は一体誰と闘い、何が目的なんだ
- 261 名前：仕様書無しさん mailto:sage [2008/07/08(火) 02:10:45 ]
- >>259
>>210の内容と、思いっきり矛盾してるのに気がつかないのか？
- 262 名前：仕様書無しさん mailto:sage [2008/07/08(火) 02:22:06 ]
- 80をやり込めても、誰も何も得しないよ。逆もまた真なり。
- 263 名前：仕様書無しさん mailto:sage [2008/07/08(火) 03:28:11 ]
- つまり、80にやり込められても、誰も何も得しないw
- 264 名前：仕様書無しさん mailto:sage [2008/07/08(火) 08:41:06 ]
- >>257
システム／ネットワークのパフォーマンス的なボトルネックは生まれにくくなってきてるけど
利用するライブラリ／パッケージ自体は未だに流行に合わせどんどん入れ替わり立ち替わりな
うちのPrjでは、半年以内に「原因不明系」のトラブルが多発してるよ。
ImageGear許すマジ
- 265 名前：仕様書無しさん mailto:sage [2008/07/08(火) 08:43:02 ]
- >>260、これな
＿,====ミミﾐヽ、
,,==≡ミヽミヾミミミ、ヾ、
_=≡≡三ミミﾐ ミﾐヾ、ソ)),,》 .
彡彡二二三≡ミ-_ ﾐﾐ|ノﾉj )||ヽ, )、
__,,,,,,,,,／彡二二二 ,- __ﾐ|/ﾉ ﾉﾉﾉﾉ) ||
-=二ミミミミ----==--'彡 ∠ミﾐ_ソノノノﾉ ﾉ
/／＞=''"二二=-'"_／ ノ''''')λ彡／
,,/￣''l 彡/-'''""￣-=彡彡／ ,,-''",,,,,,,ノ .彡''"
(, ,--( 彡 ,,-- ===彡彡彡"_,-＿ ヽ Υ
ヾ-( r'''''＼ ／／=二二''''''彡ｿ￣ ∠__＼ .＼ｿ .|
＼;;;; ＼ Ζ彡≡彡-'''',r-､> l_"t。ﾐ＼ﾉ,,r-v ／￣￣￣￣￣￣
＼;;;; ＼ 彡""彡彡-//ヽ" ''''''""￣'''""(ｴｱ/ ／
＼;; ＼'''''')彡ヽ// | (tv ／| , r_>'| ＜一体みんな誰と戦っているんだ
＼;;; ＼'" ＼ ,,"''-,,ﾉ,r-", / r'''-, .j ＼
＼;;; ＼ ／,,>--'''二"''' r-| 二'" / __ ＼＿＿＿＿＿＿
＼;;r'""彡_l:::::::::::::::::::::: /./_ " ／￣￣"===-,
)''／／rl_--::::::::::::::::/:/ヽ"'=--":
- 266 名前：仕様書無しさん mailto:sage [2008/07/09(水) 00:48:04 ]
- 作業指示出してる人が「テスト嫌い。あんなもん無駄だしやってると苛々してくんだよね。」とか言っててこっちが苛々ですよ。
- 267 名前：仕様書無しさん mailto:sage [2008/07/09(水) 01:13:20 ]
- 結局結論としては80の言ってるシステムテストと他の人の考えるシステムテストの定義が違ったってことでいい？
俺的には80が言ってるシステムテストは単体テストレベル。
一般的にテストはUT、IT、STという順番でやっていくはず。
だからSTの観点はITより上のレベル。分割したモジュールをテストしてシステムテストとか、一般的じゃない。
- 268 名前：仕様書無しさん mailto:sage [2008/07/09(水) 01:16:38 ]
- >>267
同じ同じ。
UTってMTと一緒なのかな？
- 269 名前：仕様書無しさん mailto:sage [2008/07/09(水) 01:40:34 ]
- 80は業務系じゃないらしいから考え方が違うんだと思う。
UT：作ったものが仕様書どおりだよねってことをIF含めて確認するテスト。
⇒コードのチェック
IT：それぞれが作ったものをつなげても動くよね？ってことを確認するテスト。
⇒仕様書の整合性のチェック
ST：とりあえず動くもの作ったけど、そもそもこんなんでよかったんだっけ？ってのを確認するテスト。
⇒要件を満たしてることのチェック。
受け入れテスト：STまでやってるけど、レビューとか適当な客もいるので後で文句を言わせないために
実際に動かしてもらって、確かに要件満たしてますよね？って確認するテスト。
⇒保険。
- 270 名前：仕様書無しさん mailto:sage [2008/07/09(水) 06:36:32 ]
- MT?
- 271 名前：仕様書無しさん mailto:sage [2008/07/09(水) 07:00:15 ]
- いやいやいや、
>「問題の難しさ」を「問題の量」に転化したのだから
なんの証明も根拠もなしに、転化できましたなどと無邪気に主張されてもとても納得できない。
80の中で完結しているロジックが存在するとすれば、それはまだこの場では語られていない。
語ったつもりになっているとすれば、それは表現能力に問題があると言わざるを得ない。
- 272 名前：仕様書無しさん mailto:sage [2008/07/09(水) 19:17:24 ]
- 80来ないとつまんないね
- 273 名前：仕様書無しさん mailto:sage [2008/07/09(水) 22:41:42 ]
- そもそも、UTとかMTとか、
必ずしも企業間で、示す実作業の統一が取れているとは言い切れない、
曖昧模糊とした略語で話を進めようとするのが問題ではないか？
- 274 名前：仕様書無しさん mailto:sage [2008/07/09(水) 23:10:36 ]
- 実作業としては統一されてないだろうけど、UTの概念は統一されてるだろ。知らない奴は論外。
MTは知らんｗ
- 275 名前：仕様書無しさん mailto:sage [2008/07/10(木) 02:47:55 ]
- あとはPGはあると思う（ｗ。
UTとかPTとかは辺りも曖昧だし、当然それ以上はも場所によって違うだろうし。
- 276 名前：仕様書無しさん mailto:sage [2008/07/10(木) 03:12:38 ]
- 世の中にはテスト技術者資格認定とかいう資格があってだな、そこで公開されている
シラバスとか標準用語集位の事を知っておいてもらえるとありがたいなぁと思ったり
するわけですよ。
80みたいに自分理論で色々言われてもねぇ。
ttp://www.jstqb.jp/syllabus.html
- 277 名前：仕様書無しさん mailto:sage [2008/07/10(木) 23:31:11 ]
- あら…
一つのモジュールがちゃんと動くかどうか…みたいなテストを
モジュールテストとかMTとか呼んでるんだけど一般的じゃないのかｗ
テストの種類は基本情報の勉強で覚えたくらいだな。
ユニットテストとか現場でのレベル感で縛られるな。
- 278 名前：80 mailto:sage [2008/07/11(金) 00:05:27 ]
- >>267
> 結局結論としては80の言ってるシステムテストと他の人の考えるシステムテストの定義が違ったってことでいい？
よいです。
> 一般的にテストはUT、IT、STという順番でやっていくはず。
> だからSTの観点はITより上のレベル。分割したモジュールを
> テストしてシステムテストとか、一般的じゃない。
UT, IT, STという３段階が一般的なのは理解している。
ただし、うちでは、これでは、うまくテストを定義できなかった。
質問１
巨大なシステムでも小さなシステムでも等しく
この3段階でテストを進めるので良いと考えているのか？
俺が聞きたいのは、一般論ではない。過去の経験から判断してほしい。
質問２
小規模の場合、UT->IT->STとするなら大規模だとどうなる？
1. UT->UT->UT->UT->UT->UT->UT->UT->UT->IT->ST
2. UT->IT->IT->IT->IT->IT->IT->IT->IT->IT->ST
3. UT->IT->ST->ST->ST->ST->ST->ST->ST->ST->ST
4. UT->IT->ST->IT->ST->IT->ST->IT->ST->IT->ST
5. UT->IT->ST->UT->IT->ST->UT->IT->ST->UT->IT
6. そのた。
- 279 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:14:23 ]
- >>278
１．同じでないと困る。
２．テスト結果による。
全体的にはどんなプロジェクトも同じ工程じゃないと困るが、
そのテスト工程で発覚する不具合の深刻度と混入工程によって、
それぞれ小さな部分テストの反復があるんだよ。
修正する度に、部分的にUT→IT→が間に幾つも入るのさ。
- 280 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:15:46 ]
- 場合によっちゃSTまでを反復で何度も行う事だってあるしな。
- 281 名前：80 mailto:sage [2008/07/11(金) 00:23:30 ]
- つまり、仕様や性能を満たせているかを確認するテスト（ST）が
ずいぶん後回しになるやり方を皆は支持しているわけだ。
そもそも、仕様書は、システム全体に対してのみ書かれるのか？
- 282 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:29:52 ]
- >>281
皆っておい、俺一人しか答えてねえよwww
279も280も俺、俺俺www
- 283 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:31:51 ]
- >>282
いや、オレオレwww
- 284 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:34:56 ]
- >>278
工程として考えたいのか、テスト手順と考えたいのかがよくわからない。
工程なら大規模小規模かかわらずUT＞IT＞STとなるべきだが、
実際に行われてるテストはいくらでも入り組むだろう。
バグ対応入った時とか。
もし工程として(もしくは工程に近いレベルで)
質問２みたいな手順になっているなら
>>78の言うとおり、機能単位で分けるべき。
すごく今更なんだが、>>80の
> 分割すると管理コストが増えるし組織が複雑になる。
> そして、意思疎通が難しくなる。
> 問題が形を変えるだけで何も解決したことにはならない。
なんというか…オブジェクト指向じゃない感じみたいな…
モジュール一つで表示から処理から遷移から何から何までって感じがする…
- 285 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:40:03 ]
- >>80の言っている>>258には同意できる。
■機能要件
開発スタイルにもよるんだろうけどうちの顧客はころころ機能要件を
修正してくるから、機能にマッピングされるモジュール内の関数構成や
実装はそのたびに修正される。
=> ホワイトボックステストはコスト的に合わないので、モジュールの
入出力に相当するAPIだけをブラックボックステスト。
■再利用可能なコンポーネント
タスク・タスク間通信・メモリ管理周りといった部分がそれに含まれる？
不具合が全体に波及するのは勿論だし、そういったモジュールは
関数構成や実装が大きく変わることは無い。
=> ユニットテストで関数ごとにホワイトボックステスト。
コスト的に許されるんなら、全てにホワイトボックステストを用意するに
越した事は無いんだけど。
- 286 名前：仕様書無しさん mailto:sage [2008/07/11(金) 00:48:20 ]
- >>258はよくわからなかったけど>>285には納得できる。
> => ホワイトボックステストはコスト的に合わないので、モジュールの
> 入出力に相当するAPIだけをブラックボックステスト。
コスト的にかどうか知らないんだけど、これが一番理想とするテストだと思ってる。
APIの所だけホワイトな、穴あきブラックボックステストみたいな。
- 287 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:03:04 ]
- >>278
スパイラル型でもない限り結合超えてUTに戻る、ってのはないんじゃないの？
上位テストフェーズで不具合が見つかった瞬間はともかく
おれはスパイラルスキーなんだけどね。
ちなみに今関わってるPrjは大規模であっても
UT->IT->ST
これだけ。そして受け入れフェーズで多々トラブル。
おれ、どうしたらいい？
あ、
１．よくない。お客様との要件詰めが完全合致していて、仕様変更などが絶対入らない
前提でもない限りUT->IT->STのみではうまくいかない。
なぜなら、UT後に仕様変更なぞ入ろうものなら品質面での保証がまったく出来なくなってしまう、
客は触って初めて「違うぞこれ？」とか言い出す生き物、などなど。
２．同じことの繰り返し、と考えてしまうと、６．その他、が正解だと思う。
自動テストをUT,IT,STのくくりにいれず同時並行すべきかなー、とか。
- 288 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:04:19 ]
- みんな考え方は現場経験や本人の考え方により違うんだろうけど
こうやってテストフェーズについて色々活発に話せることはよいことだナァ。
- 289 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:05:31 ]
- >>288
なー。おれはよくわからんから読んでるだけだけどなー。
- 290 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:14:59 ]
- >>289
実際現場でテストやその後フェーズで苦労しだすと結構分かってくるんじゃない？
ってか品質面で問題でない現場ならそれが一番の幸せだよ｡゜（ﾟ´Д｀ﾟ)゜｡
- 291 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:15:27 ]
- >>281
仕様書はもちろん個々の機能についても書かれる。
そしてその仕様どおりの入出力を満たしていることの確認もする。
ただし、業務系ではそれをシステムテストとは呼ばない。
個々の機能の入出力を重点的にテストして、それより下位のテストは適当にするっていうのは
いいと思うよ。
本当にただ言葉の定義が違うために言ってることが分かりづらいだけ。
- 292 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:20:39 ]
- 今回うけた仕事、システム全体の中の1カ所の開発(というかリファクタ)なんだが
自分たちが受けた部分はともかく、他のところはいきなりシステムテストらしい。
ちゃんとモジュールテストされてない・・・
そのせいで、システムテストで
他の会社が作った部分のデバッグをやらされてる。
- 293 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:22:10 ]
- >>292
そういう段取り／スケジュール考えた奴は軽蔑していいよ
- 294 名前：仕様書無しさん mailto:sage [2008/07/11(金) 02:33:59 ]
- >>290
テスト後フェーズは幾度となく経験してるし、
修正後のテスト堂々巡りも経験してるけど、
大規模開発というものを経験したことがないので、
UT→IT→ST が同時進行ならまだしも、何度も巡る
というのが理解できず、議論についていけないｗ
というかあれだな、読んでいて思ったけど、
言葉の定義や論点がずれているだけで、
本質はみんな同じ認識の様な気がする。
- 295 名前：仕様書無しさん mailto:sage [2008/07/11(金) 06:03:21 ]
- >言葉の定義や論点がずれているだけで、
>本質はみんな同じ認識の様な気がする。
いや、違うね。俺だけが違ってるという可能性もあるが。
>>281
テストフェーズの定義について、素直に間違っていたと認めた80は評価する。
同じように「仕様書」に関しても、他とずれていると認識してほしいのだが。
そうでないと、>>281の後半部分には答えられない。
>つまり、仕様や性能を満たせているかを確認するテスト（ST）が
>ずいぶん後回しになるやり方を皆は支持しているわけだ。
何度も言うように、システムテストは機能テストと「性能を測る」テストだけではない。
後回しになる（後でやらないと意味がない）テスト（ケース）もあれば、先にやるものもある。
機能テストのことをずいぶん気にしているようだが、「皆」がどう取り組んでいるかは、
「受け入れテスト 自動化」でググってみるとわかるかもね。
- 296 名前：仕様書無しさん mailto:sage [2008/07/11(金) 06:12:26 ]
- 俺が80と違っている（と思っている）点は、
・ユニットテストは軽視してはならない。むしろ重視すべき。
・ユニットテストはプログラマが行うべき
・ユニットテストを重視することは、顧客のメリットになる
・（おまけ）外部設計と内部設計という考え方はある
80に同意する点もいくつもあるが、それは列挙しない。
- 297 名前：仕様書無しさん [2008/07/11(金) 19:44:58 ]
- 適当でいいんだよ適当で。
- 298 名前：仕様書無しさん mailto:sage [2008/07/12(土) 02:15:00 ]
- 適当、よりも、適度、がいいと思うんだ
- 299 名前：仕様書無しさん mailto:sage [2008/07/12(土) 15:17:35 ]
- 適当≠手抜き
- 300 名前：仕様書無しさん mailto:sage [2008/07/12(土) 19:29:48 ]
- サンビャク！
- 301 名前：80 mailto:sage [2008/07/13(日) 08:07:03 ]
- >>296
>・ユニットテストは軽視してはならない。むしろ重視すべき。
->軽視はしていない。重視もしていない。
おれは、テスターじゃなくて、プログラマー上がりなので、
ユニットテストの大切さを知っている。ただ、組織としてユニットテストを
成功させる場合は、以下の前提条件を満たせないとだめだ。
1. バグが減ったことを評価して、ボーナス査定をUPさせる。
2. 機能実装よりバグが少ないことを重視する。
重要なのは、2 だ。ユニットテストを重視した結果開発のスピードが
落ちたのだ。つまり、機能的要件（フレームワーク、下位コンポーネント
を除く）を実装するチームに関しては、ユニットテストがボトルネックになる。
よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
>・ユニットテストはプログラマが行うべき
-> ユニットテスト＝ホワイトボックステストなら同意。
>・ユニットテストを重視することは、顧客のメリットになる
-> 大規模開発では、顧客には理解されない。
業務系ではないうちでは、専門的すぎて説明するのが難しい。
>・（おまけ）外部設計と内部設計という考え方はある
-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
間違っているのに気がついた。
確かに、システムというものを対象にした時にそれの外部について
記述したドキュメントと内部について記述したドキュメントはある。
ただ、外部か内部かという言葉は、対象物を前提としている。
システム、サブシステム、コンポーネント、ライブラリ・・・・などだ。
そして、これらは、整然と関連付けられる。内部設計とか外部設計という
言葉をこれに当てはめると間違いである事が理解できる。
外部は仕様書で、内部は設計書なんだ。これでもわからないなら。
仕様書と設計書の違いを説明してくれないか
- 302 名前：80 mailto:sage [2008/07/13(日) 08:17:57 ]
- 補足だが、プログラマーとテスターの作業量を新規開発の初めから
終わりまで時間を追ってグラフにしてみると俺の言っていることが
分かるかもしれない。
理想を言えば、一番初めのインテグレートの時にテスターが
チームに参加すれば、コスト的にOKなのだが。
大抵は
1. 一番初めのインテグレートは遅れる。つまりテスターが遊ぶ。
2. テスターが開発初期から参加している場合、テスターは
プログラマーよりも暇である。
3. 機能要件は、よく変わる。せっかくユニットテストをばっちりしても
作り直しが多数発生する。さっさと、要求者に「うごく」ソフトを
見せるのは重要だ。
テスターを遊ばせないで、機能要件の間違いを早期に発見できる方法
を俺は支持しているんだ。
- 303 名前：80 mailto:sage [2008/07/13(日) 08:29:15 ]
- >>285
だいたい、同じ考えだ。
機能要件と再利用可能なコンポーネントでは、テストのやり方
を変えないとだめだ。
再利用可能なコンポーネントは、下位の層で人目につかない。
テスターに通信プロトコルや各種規格をすべて理解してもらうことは無理
なので、プログラマーしか「テストができない」と俺は思う。
違うところは、再利用可能なコンポーネントのテストは、
ホワイトボックステストと加えて回帰テスト（ブラックボックス）を
重視するところだ。
再利用可能コンポーネントは、最適化を繰り返すので、ソースコードが激変する。
つまり、ホワイトボックステストは毎回変わってしまう。
ホワイトボックステスト事態の品質を維持することは非常に難しい、
なので、回帰テストとの合わせ技が重要になる。
- 304 名前：80 mailto:sage [2008/07/13(日) 09:11:20 ]
- 開発工程の中のボトルネックはどこにあるのか？によってやり方は異なる。
プログラマーのスキルが高い場合、テスターのスキルが高い場合など
状況は様々だ。
うちのボトルネックは、「実装」フェーズだった。
スケジュールの遅れは、プログラマーの責任だという認識が多数を占めていた。
なので、ユニットテストが流行したが、結局、失敗に終わった。
ボトルネックにさらに仕事を増やした（人は増えない）結果、開発そのもの
が遅れ、テスターが遊び始めた。設計者は次の設計に入っている。
しかし、ボトルネックが解消されなければ、実装されない設計が溜まる
ばかりだ。テスターは、空いた時間で別のプロジェクトのテストをしている。
リソースが有効活用されていないのは明らかだ。
ボトルネックを解消するのに設計者にテスターにできることはないのか？
そう考えるのが普通だろう。
設計者には、設計を洗練させた。結果、不要なソースコードをプログラマー
が書かなくても良いようになった。
ユニットテストを強要することはやめた。その代りテスターの負担が増えた
が、もともとテスターは遊んでいたのでプロジェクト全体のスループットは
向上した。テスターのストレスは増えたが・・・。
ユニットテストを完璧にやるという事は、ウォーターフォールの考え方
に近い。うちは、繰り返し型の開発をやっているので、たとえバグが残っても
開発の最後の方でプログラマーの手が空いてきたころに網羅性の高いテストを
行うので実質品質が下がるようなことはない。
ユニットテストは有効だが、使い方を間違ってはいけないと思う。
重要なのは、部分最適化（ユニットテストだけを協調する）のではなく
全体最適化（全ての開発工程を見直す）の方だと思う。
- 305 名前：80 mailto:sage [2008/07/13(日) 09:30:44 ]
- >>291
業務系は、書籍などで知っているだけで現場は知らない。
うちは、メカトロニクス。半分は制御系。ただし、大規模な制御系だ。
Web技術、データーベース、各種通信、など色々開発要素も多い、
言語もC++, C#, Java, その他が入り乱れている。
うちのシステムは、多層になっているシステムの集合体だ。
担当者は、自分の担当範囲だけどをシステムと呼んでいる。
つまり、人によって、システムの範囲（スコープ）が違うんだ。
そして、多段階にインテグレートしてテストを行う。
なので、スコープとレベルの違うシステムテストはチーム内の複数存在
することになる。
見方を変えれば、下位のシステムは、ユニットとも言えなくもないが、
よほどの下位でもない限り「一般論で言うユニット」とは違う。
うちでは以下のように定義している。
・（粒度はともかく）機能的要件を実現する単位をシステム
（サブシステム）と呼んでいる
・下位の原始的なメカニズムを提供するものを、ユニットと呼んでいる。
・機能外要求や、システムのアーキテクチャーをつかさどるものを
フレームワークと呼んでいる。
|
 |
