佃です。
toru_yamamoto@....jp wrote:
>
> 山本＠エプソンコーワです。
>
> XPracticeの'18. Functional Tests'を訳しました。
> まだちょっとわかりにくいところがあります。
> お気づきの点有りましたらよろしくご指摘ください。
>
> -------------------------------------------------------------------------
>
> C3プロジェクトには、最初から最後までシステムをテストし、入力ファイルから出力
> フ
> ァイルを作成する、文字どおり数百個の機能テストがある。テストケースはユーザー
> に
> より定義され、テストを作成することが仕事とする別のチームにより開発された。
>
> 機能テストはそれら自身の特別なGUIを持っており、テストのステップ、実行時間、
> テス
> トが成功したかどうかを表示する。スコアを表示する。
>
> 機能テストはプロジェクト中は100%を得点する必要がなかった:機能を付加すること
> でそ
> れらのスコアは上昇する。それらはリリース前に100%のスコアを取る必要があり、そ
> し
> てテスト中のどのような現実の変化も注目に値する。
>
> 私達はコードをGemStone等に移動させる前に実行する機能テストの短い一式を持って
> お
> り、開発中すべての機能テストが毎日実行され、スコアはチームに報告された。テス
> ト
> チームは、動作していたテストが失敗したときの認識において積極的であり、何かが
> 悪くなったように見えるとすぐに開発者に知らせる。
>
> 私達が機能テストによって犯した誤りの1つが、それらが十分に全体に及んではいな
> かっ
> たことであった。私達がテストを入力ファイルから出力ファイルに実行した後にさ
> え、
> 私達はそのファイルを使った下流のプログラムの違いを後で発見した。私達がアウト
> プ
下流のプログラム【で】違いを発見した。
differencesは、当初の出力ファイルのデータと正しい出力ファイ
ルのデータの違いのことなんだろうと勝手に解釈しました。
> ットであるはずのものを誤解した時には、これは典型的に起こった;ファイルは私達
> が意
> 図したものを持ち、テストによりその値がチェックされたけれども、Legacy プログ
> ラム
> は何か他のもの要求した。インプットからアウトプットへの機能テスト期間をできる
> 限
> り長くしなさい: 欠陥は、あなたが止まる所どこにでも出現する。
私は、こんなことを言っているのかな、と思いました。
ファイルＡ → プログラムＸ → ファイルＢ → プログラムＹ →
ファイルＣ
とあったとき、Ａ−Ｘ−Ｂのテストではうまく動作したが、その結
果であるＢを使ったＢ−Ｙ−Ｃでバグが検出されることがある。
これはＹで必要とするデータをＸで生成していないことが原因であ
る。このバグは、プログラムＸだけやプログラムＹだけに注目して
テストしても検出されない。
このようなバグを検出するために、できるだけ長い系列（上記の場
合、入力Ａ、中間ファイルＢ、出力Ｃ）でテストをしなさい。
>
> --------------------------------------------------------------------------
訳を投稿するときには、以下の２行を添付することが約束事になっ
ています。
今後は添付して投稿しましょう。
---
オリジナル http://www.xprogramming.com/
Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)
--
佃 軍治 tsukuda@....jp
日立製作所システム開発研究所第２部