0

私は、外部サービスが（テストサーバー上で）チェックアウトできるインベントリデータを提供していることを確認するテストを作成しています。また、キャンセルすることもできます。このテストは旅行/ホテルの世界で行われているため、テストを予約してからキャンセルする必要があります。

私は次の手順を実行します：1）90日後の在庫（ホテルの部屋）を検索します2）最初の結果を取得し、それを使用してテストチェックアウトを行います3）注文をキャンセルしてキャンセル番号を取得したことを確認します4）確認します適切なデータベースエントリが実行されます

このテストはシステムの幅広い部分に影響を与えますが、私には（現在）それぞれを分離するメカニズムがありません。したがって、この単体テストは考慮しません。しかし、これは機能テストと呼ばれるのでしょうか、それとも他の何かと呼ばれるのでしょうか。

フォローアップとして、私が対話しているサブシステムごとにテストを分離して作成することがおそらく役立つでしょう。分離プロセスのどこから始めますか？

4

1 に答える 1

0

あなたがリストしたこれらの各ステップは、分離の良い候補です：

  1. 在庫を取得する
  2. チェックアウト
  3. キャンセル
  4. キャンセルを取得＃

あなたが今しているようにそれらをつなぎ合わせるのは、とにかくそれらのそれぞれが個別に機能する機能にすぎません。

あなたは現在機能性をテストしています（良いです！）が、堅牢性については言及していません。

私は（私がリストしたように）関数ごとに一連のデータを作成し、それを壊してコーナーケースを調査しようとします。過去に予約したり、POSTデータを上書きしたり、部屋を上書きしたり、同じ部屋を2回同時に予約したりします。これはすべて、1つの分離に対して作成したテストの入力パラメーターとして保存されます。あなたのアプリケーションの。

分離株が異なれば、テストに役立つ/意味のあるさまざまなデータが得られますが、変更/コミット/ビルドごとに、各関数に対してテストデータを実行し、結果を有効にすることができるはずです（つまり、クエリを返す、部屋をチェックアウトするか、予約をキャンセルするか、キャンセルを取得します＃）

于 2009-11-13T20:52:48.467 に答える