私は最近この質問に出くわしました。テスターとしての私のアプローチはどうあるべきか、誰か助けてください。
機能が変更された Web サービスがあり、同じドキュメントが入手できないとします。同じことをテストするためのあなたのアプローチは何ですか？
更新：データベースの機能が変更され、ドキュメントがない場合、同じ答えが当てはまりますか。
4 に答える
2
ドキュメントなしで何かをテストすることはできません。どのような結果が期待できるかをどのように知ることができますか?
間違った場所で「ドキュメント」を探しているのかもしれません。誰かがこれらの変更を加えました。彼らは、データベースとサービスにどのような変更を加える必要があるかを示すいくつかの情報を持っていました。要件ドキュメントもあるかもしれませんが、設計ドキュメントもあるかもしれません。
それらを取得し、それらを使用して何が変更されたかを把握します。その情報を使用して、テストの変更方法を決定します。
于 2010-01-13T13:34:13.140 に答える
2
次の 2 つの異なる質問のいずれかを尋ねているようです。
1) ブラックボックス Web サービスの API を検出する方法。
この場合、最良のソースは Web サービスのソース (ドキュメントの存在障害を伴う) であり、代わりに既存のクライアントまたはサービスの ?wsdl を調べます。
2) Web サービスからの正しい応答と正しくない応答を検出する方法。
これには、要件、ドキュメント、または正しいクライアントが必要です。この場合、おそらく最も存在する可能性が高いのはクライアントです。あるいは、Web サービスが何らかの機能を実装していて、その結果を外部で確認できる場合もあります。
于 2010-01-13T13:41:41.713 に答える
1
サービスを有用な方法で使用している場合は、文書化されていない場合でも、既知の結果を返す呼び出しがいくつかあると思われます。この場合、現在のサービスに対する期待を検証するテストを作成します。そうすれば、少なくとも変更が加えられた場合、どのビットが変更されて影響を受けるかを知る可能性が高くなります。
于 2010-01-13T13:38:48.937 に答える
0
一般的に言えば、Web サービスは、提供するサービスと呼び出し元の間で一貫した契約を提供します。バックエンドの実装は変更される可能性がありますが、サービスのインターフェイスは一貫したままであることを指定します。
サービスで利用できる機能を知りたい場合は、利用可能な機能とメッセージ タイプを文書化したメタデータを提供することもできます。通常、これは Web サービスの URL に「?wsdl」を追加することでアクセスできますが、他のスキームも存在します。
使用可能な関数についてよく理解したら、テスト フレームワークを介して関数を呼び出し、通常のテスト プロセスに従って応答を評価することができます。
于 2010-01-13T13:37:59.547 に答える