Success, warning, failed
Ce que veut dire un warning, d'où il vient, et comment il remonte d'un step jusqu'à un monitor.
Un test répondait par oui ou par non : il est passé, ou il a cassé. Les checks ont ajouté une troisième réponse. Une page qui met neuf secondes à charger au lieu de deux n'est pas cassée, mais vous voulez le savoir. C'est le rôle du statut warning : quelque chose ne va pas, le parcours fonctionne quand même.
D'où vient un warning
Rien ne déclenche un warning tout seul. Un warning existe parce que vous avez écrit une condition pour lui, dans l'onglet Checks d'un step, qui contient deux groupes :
- Success conditions, qui se lisent "Passes if". Le step échoue dès que l'une d'elles n'est pas remplie.
- Warnings, qui se lisent "Warns if". Le step passe quand même, et l'exécution est signalée.
Déplacez une condition d'un groupe à l'autre par glisser-déposer, ou via son menu (Move to warnings, Move to success conditions), pour changer ce que coûte un problème donné. Chaque groupe a sa propre logique and / or, et les conditions peuvent être imbriquées en sous-groupes quand une règle a besoin des deux.
Les tests existants n'ont aucun check : ils ne peuvent donc rapporter que success ou failed. Un test commence à rapporter des warnings à partir du moment où vous lui ajoutez des conditions.
Ce sur quoi vous pouvez écrire une condition dépend du step :
| Step | Champs disponibles |
|---|---|
| Navigate to starting page | URL, Loading time |
| Tout autre step navigateur | URL, Step duration |
| API Call | Status code, status text, response header, response body et les temps de réponse |
| Get mail | Sender, recipient, CC, subject, content, attachments, attachment name |
| Check PDF | Extracted text, page count, file size, file name |
Les mêmes trois mots à chaque niveau
| Niveau | Success | Warning | Failed |
|---|---|---|---|
| Step | Toutes les success conditions remplies | Une condition du groupe Warnings s'est déclenchée | Une success condition n'est pas remplie |
| Exécution | Tous les tests ont réussi | Tous les tests ont réussi, au moins un avec un warning | Au moins un test a échoué |
| Monitor | Success | Degraded, en jaune | Failed |
Un monitor a trois autres états qui ne disent rien de votre application : Device issue (l'agent ou l'appareil a lâché, l'exécution ne prouve donc rien), Paused, Running et Scheduled.
Ce qu'un warning change vraiment
L'exécution continue. Un warning n'arrête jamais un test, et n'arrête jamais le test suivant dans une campaign.
L'exécution est classée en warning, et la liste des exécutions filtre sur ce statut : un passage en revue hebdomadaire des warnings tient en un clic.
Le monitor passe Degraded, en jaune, dans la liste des monitors et sur le statut en temps réel.
L'intervalle passe au jaune sur Status Details, où un warning prime sur un succès : un intervalle qui contient les deux se lit en warning.
L'uptime compte les warnings comme de l'indisponibilité. Le pourcentage d'uptime, ce sont les exécutions réussies sur l'ensemble des exécutions : un monitor qui ne fait que warner perd quand même de l'uptime. Un warning sert à être prévenu, pas à garder le chiffre au vert.
La sévérité Warning d'une alerte est autre chose. Les sévérités d'alerte viennent des seuils que vous posez sur une métrique, pas des checks d'un test. Un test peut warner sans déclencher aucune alerte, et une alerte peut être critique sur un test qui n'a jamais warné.
Et ensuite ?
Last updated on