ストレステストの合否基準がないのは妥当ですか

わかりやすくするために、私が作成したストレステストは、システムが限界点に達するまで、システムの負荷を徐々に増やしていきます。理論的には無期限に実行されますが、システムリソースは有限であるため、しばらくすると障害が発生することが予想されます。システムに予想される負荷がありますが、これは負荷テストで個別にテストされます。このストレステストの目的は、スケーリングを実装する必要がある前に、システムにどれだけの負荷をかけることができるかを調べることです。

私はシステムのストレステストを作成している最中です。合格/不合格の基準があるのが理にかなっているのではないかと思っています。テストの性質上、負荷は、ブレークポイントに到達する（つまり、失敗する）まで着実に増加します。私は明らかに、この限界点が事前に何であるかを知らないので、システムが処理できる負荷は（とにかく）期待できません。

現在、予想される負荷などでシステムをテストする他のパフォーマンステストがあります。これは、合格/不合格の基準を簡単に設定でき、これらの基準をストレステストの基礎として使用できます。言い換えれば、ストレステストに到達するための最小ベースラインを設定することはできますが、これが正しいことかどうかはわかりません（これが他のテストを「複製」していますか？）。

パフォーマンステストの経験が豊富な方に協力していただければ幸いです。ストレステスト（ある場合）の際に、他のどの合格/不合格基準を使用しましたか？

ストレステストであなたの仕事は、被験者が受けることができるはずのストレスを定義することではありません。それが失敗する前にかかるストレスを測定することです。

パフォーマンス基準を使用して、ストレス障害とは何かを定義できます。しかし、ストレステストの結果は合格/不合格ではありません。それは、「100％の使用率の下で90時間後に失敗し、換気が50％低下しました」。

要件によって異なりますが、アプリのパフォーマンスの期待される結果がXであり、実際にはYであることが要件で指定されている場合、失敗です。
要件が定義されていない場合は、システムに負荷をかけて境界データを収集し、これらの制限を把握して文書化することができます。

主なストレステストを簡単に更新して、「X負荷に到達する/維持する」など、QA合格/不合格の検証もサポートできます。Xが構成可能であることが理想的です（たとえば、異なるリリースブランチに対して）。

結果はfail、負荷がXに到達する前にシステムが壊れて、壊れpassない場合です。「持続」シナリオでX値に達したら、負荷の増加を停止する必要があります。

このような自動テストのIMHOは、CI / CDのコンテキスト、特に本番ブランチで非常に役立ちます。