同時実行 (ストレス テスト) とは、同時に同じデータにアクセスしようとする複数のユーザーの処理を指します。問題の鍵は、特に複数のユーザーが共有データにアクセスする多くの現在のシステムにおいて、同時実行の問題に対処するアプリケーションを設計する方法にあります。リソース。一般的な解決策は次のとおりです。
1: 保守的な方法: この同時実行モデルはデータにロックを追加します。たとえば、編集が許可されている環境でユーザーがデータベース内のレコードを操作すると、システムは他のユーザーからのデータの読み取りリクエストを拒否します。この方法は、実装がある程度複雑になりますが、複数のユーザーが同じデータを同時に編集する可能性がある状況に最も適しています。
このモードでの同時実行性のテストは、主に、レコードのロックが正しく取得および解放されていること、およびレコードを更新する可能性のあるアプリケーションのすべての部分が適切に処理されていることを検証することに関係します。
a: ロックの取得: データ レコードまたはデータ項目の更新状態に同時に入ることができるのは 1 人のユーザーだけであるため、重要なのは、システムが最初に要求したユーザーにロックを正しく割り当てる必要があるということです。ロックを取得する操作は操作可能である必要があります。具体的な方法としては、2 人のユーザーが同時に編集状態に入ろうとするか、大量のリクエストを使用します。後者については、スクリプトを使用して複数の同時編集を生成できます。データ リクエスト。これは、1 つのリクエストだけが成功したことを確認するために使用されます。
b: ロックの有効性: ロックの有効性を検証するには、他のユーザーがいかなる方法でもデータを変更 (変更や削除など) できないことを確認する必要があります。具体的な検証方法は次のとおりです: ユーザーにレコードを開かせる(編集モードに入り、この状態を維持します)、他のユーザーが編集や削除など、アプリケーション内のすべての場所でデータを更新しようとしている間、システムは他のユーザーによるデータ更新の試みをすべて拒否する必要があります。
c: ロックの解放: 検証する必要があります: データを編集するユーザーがレコードを解放すると、システムは他のユーザーにレコードの編集を許可できます。注意すべきもう 1 つの側面は、エラー処理、つまりロックを保持しているユーザーです。エラーを使用します (クライアントのクラッシュなど) 場合にシステムがどのような操作を完了する必要があるか、およびロックの解放の失敗からシステムが回復する能力を考慮する必要があります。
2: オープン モード: このモードでは、ユーザーは常にデータの読み取りが許可され、データの更新も許可される場合がありますが、ユーザーがデータを保存しようとすると、システムは、保存以降に他の人がデータを更新したかどうかを自動的にチェックします。ユーザーがデータを取得しましたが、データが変更されている場合、更新は失敗します。このアプローチでは、保守的なモデルよりも多くのユーザーがデータを表示できるため、複数のユーザーが同時に同じデータを変更する可能性が低い状況に適しています。
このモードでは、更新だけが問題となります。テストに最適な方法は、手動テスト手法と自動テスト手法を組み合わせることです。手動テストでは、2 人のテスターがデータを編集し、同時にデータの保存を試みます。1 ユーザー操作は正常に更新されます。最終的に、別のユーザーは、他のユーザーがデータを更新したという内容のメッセージを受け取ります。この時点では、データをリロードして、再度変更操作を完了するだけで済みます。自動一括テスト方法を使用する場合、同様に 1 人のユーザーのみがレコードを更新できますが、他のユーザーはプロンプトを表示されます。他のユーザーがすでにデータを更新しているため、その操作は無効です。
3: 同時実行保護なし。これはすべてのモードの中で最も単純です。平たく言えば、勝利は最後のユーザーに属しますが、2 人のユーザーが同時にレコードを変更すると、データ破損が発生する可能性があります。
このモードでは、更新リクエストの順序に関係なく、すべてのユーザーが更新操作を正常に完了する必要があります。ユーザーがレコードを更新すると、そのレコードは実際に削除されるなど、データの整合性と更新エラーに特別な注意を払う必要があります。
同時実行テストを扱うときも注意してください。同じデータを異なるインターフェイスまたは関数を通じて更新できる場合は、このレコードにアクセスする可能性のあるすべての関数をテストする必要があります。