1

特定のWebアプリケーションのBLが意図したとおりに機能していることを確認するために、いくつかの手動テストケースをまとめることに興味があります。

残念ながら、UIとBLレイヤーの結合は十分に高いため、Fitnessなどのツールを使用して自動テストを実行する場合は、かなりの時間を費やす必要があります。これは、価値のある支出とは見なされません。現在の期限などを考慮した時間の

私の質問は、上記のシナリオで手動テスト（テストは ここで定義されているとおり）を実行するのが合理的かどうかです。その場合は、次のようになります。

  • BL層のシステムテストはどの程度詳細にする必要がありますか？
  • 一般的なシステムテストとスモークテストの場合、特定の要件をカバーするように各テストを設計することで、カバレッジを十分に満たすことができますか？

例：

REQUIREMENT: If a user provides two cost entries for the same type of
       item, the application will take the higher of the two costs, and zero
       the second.
TEST: Add two cost entries, both for vehicle use, submit the ticket. 
      Verify that the invoice for the ticket only shows the higher of the two.
  • 手動テストを設計するときに考慮すべき他のことはありますか？
4

1 に答える 1

3

BL層のシステムテストはどの程度詳細にする必要がありますか？

システムをサポートする必要がある期間はどれくらいですか？あなたがこれを出荷した後、誰かがそれを再び回帰テストする必要がありますか？その場合、ドキュメントに基づいてテストを実行できるように、テストは十分に詳細である必要があります。そうでなければ、なぜそれらを書き留めるのも面倒なのですか？

適切なツールを使用すると、UIとBLが結合されている場合でも、UIを介してブラックボックステストを自動化できます。システムが何年も存在し、リグレッションのコストが大きい場合は、UIを介してテストを自動化することを検討する必要があります。実行可能なテストケースは、書かれたテストケースのドキュメントよりもはるかに価値があります。

一般的なシステムテストとスモークテストの場合、特定の要件をカバーするように各テストを設計することで、カバレッジを十分に満たすことができますか？

少なくとも、手動テストの場合にROIを最大化するために、探索的テストを実行し、エッジケースでプログラムを中断する必要があります。ハッピーパスをテストすると、エッジケースでそれを破ろうとするよりもはるかに少ないバグが発生します。

また、要件の欠落も考慮してください。要件の抽象化レベルによっては、多くのシナリオが省略される可能性があります。

Anything else I should take into consideration when designing manual tests?

テストフィクスチャのセットアップとシステムの実行を自動化するためにできることを実行します。自動化されたテストにその余分なステップを加えることができない場合でも、テストフィクスチャを即座にセットアップできれば、時間を大幅に節約できます。

于 2012-04-20T18:03:50.067 に答える