Est-il raisonnable de ne pas avoir de critères de réussite / d'échec pour un test de résistance

Pour plus de clarté, le test de stress que j'ai écrit augmente régulièrement la charge sur le système jusqu'à ce qu'il atteigne un point de rupture. Il fonctionne théoriquement indéfiniment, mais comme les ressources du système sont limitées, il devrait échouer après un certain temps. J'ai une charge attendue pour le système, mais elle est testée séparément dans un test de charge . Le but de ce test de stress est de savoir quelle charge je peux mettre sur le système avant de devoir implémenter la mise à l'échelle.

Je suis en train d'écrire un test de résistance pour un système, et je me demande s'il est logique d'avoir des critères de réussite / échec. De par la nature du test, la charge augmente régulièrement jusqu'à ce qu'elle atteigne un point de rupture (c'est-à-dire qu'elle échoue ). Évidemment, je ne sais pas ce qu'est ce point de rupture à l'avance, et donc aucune attente de la charge que le système peut supporter (en théorie de toute façon).

Maintenant, j'ai d'autres tests de performance pour tester le système sous une charge attendue, etc., pour lesquels je peux facilement définir des critères de réussite / d'échec, et je pourrais utiliser ces critères comme base pour mon test de stress. En d'autres termes, je pourrais définir une ligne de base minimale pour que mon test de stress atteigne, mais je ne suis pas sûr que ce soit la bonne chose à faire (est-ce que cela "duplique" mon autre test?).

J'espère que quelqu'un avec plus d'expérience dans les tests de performance pourra m'aider ici. Quels critères de réussite / échec les autres ont-ils utilisés lors des tests de résistance (le cas échéant)?

Dans un test de stress, votre travail n'est pas de définir le stress que le sujet devrait être capable de supporter. C'est pour mesurer le stress qu'il faut avant qu'il échoue.

Vous pouvez utiliser les critères de performance pour définir ce qu'est une défaillance sous contrainte. Mais le résultat d'un test de résistance n'est pas réussi / échoué. Il "a échoué après 90 heures d'utilisation inférieure à 100% avec une ventilation compromise à 50%".

Cela dépend des exigences, si vos exigences spécifient que le résultat attendu pour les performances de l'application est X et que vous avez en fait Y, c'est donc un échec.
Si vous n'avez pas défini d'exigences, vous pouvez donc stresser votre système et collecter des données sur les limites, puis déterminer et documenter ces limites.

Vous pouvez facilement mettre à jour votre test de stress principal pour prendre également en charge une vérification de réussite / échec de l'AQ, quelque chose comme «capable d'atteindre / de maintenir la charge X sans se casser». Idéalement, X étant configurable (pour différentes branches de version, par exemple).

Le résultat serait failsi le système se cassait avant que la charge n'atteigne X et passs'il ne se cassait pas. Il suffit d'arrêter d'augmenter la charge une fois qu'elle atteint la valeur X dans un scénario de "maintien".

À mon humble avis, un test automatisé comme celui-ci peut être très utile dans le contexte de CI / CD, en particulier sur les branches de production.