73626
フォームを作成しているんですが、送信ボタンが2回押された場合、2つ登録されないか見た方がよい。との記述をみたので、やってみたいと思っています。  
f12押下→sources→でjsファイルを見てたんですが、何を基準にどこでブレークポイントを置けば多重確認ができますか？  
何をしてどの時点でどういう結果がかえってくるのがこのテストの内容なんでしょうか？

追記  
失礼しました。  
実装内容は  
・リフレッシュトークンとPOSTトークンの照合チェックです。  
その後最後にセッション削除しています。
CC BY-SA 4.0
2021-01-27T08:29:20.333
73603
2021-01-28T04:10:19.317
2021-01-27T09:19:06.483
41150
41150
question
javascript php
devtoolsで多重送信されてないか確認したい。
フロントエンドの多重投稿テストの説明をしましたが、追記をみるとサーバサイド実装のテストのようです。  
なのでフロントエンドでChromeブラウザの開発者ツールでテストは合わない可能性があります。  
サーバサイドでのテストを改めて説明します。

まずテスト項目の定義をしましょう。

フォームのテスト項目を定義するとすれば  
「クリックの誤操作や何らかの原因でリクエストが多重に走ることに伴う多投稿ができないか？」

サーバサイド側から書くならば  
「クライアントからのPOSTリクエストを多重かつ連続して受け入れることを拒否しているか？」

さらに専門的にいうと  
「POSTリクエストが排他制御されているか？」  
ということになります。

これはなぜ問題かというと  
例えば、POSTによって決済を実行するような動作がある場合には  
間違ってクライアントがブラウザで2回ボタンを押してしまい、かつアプリケーションが2回連続で受け入れる可能性がある実装になっていた場合、通常は1回の決済処理が走るべきところが2回走ってしまいます。

テスト項目について理解できたら  
次にテストの必要性を考えましょう。

今回のアプリケーションについては排他制御の必要性はありますか？このPOSTリクエストは多重で走っても問題ないですか？もし多重で投稿されてもプロダクトやプロジェクトのリスクとして許容されるものですか？

すべてのフォームに排他制御は入れる必要はないと思っています。  
例えば、企業の問い合わせフォームは2回送信されたところで、データの削除すれば問題なしが多いと思います。  
運用でカバーできるor運用でコストが支払えるという判断ができれば、このテストは必要ありません。  
これについては外部から提案できるものではなく、プロダクトオーナーやプロジェクトマネージャーによる判断が必要な場合もあります。よく検討してみてください。

もし排他制御が必要で実装しあり、さらにテストしなければならないとなった時は、  
全く同じ状態でPOSTを複数送信できるようにテストを組み立てる必要があります。  
テスト方法の検討です。

今回はセッションを利用しているようですので、同じブラウザ内（例えばタブ等）で複数フォームを開き、同じ条件で同時に送信ボタンを押してみるというのがテストの方法になります。

ここでいう「同じ条件」は定義が難しいのですが、  
わかりやすい例としてECシステムにおける、カートを想像してみてください。  
ECの購入時のフォーム送信で排他制御のテストをする場合は、カートに商品を入れた状態で複数のタブを開き同時に購入ボタンを押すことになります。  
同じ条件というのがカートに商品を入れた状態になります。  
排他制御を入れている場合は同時に送信されてもどちらからのリクエストは必ず弾かれるはずです。

「同じ条件」にするためには、アプリケーションによって方法が変わります。  
仕様ごとにテスト方法を検討してみてください。
CC BY-SA 4.0
2021-01-28T04:10:19.317
73626
2021-01-28T04:10:19.317
22665
73603
answer