Traitement des incidents de la détection En session

Dans certains cas, il se peut que l'examen détecte qu'il est hors session et qu'il ne peut pas valider son masque en session associé. Durant cette période, le journal d'examen affiche plusieurs demandes de connexion jusqu'à ce que l'examen s'arrête avec l'entrée de journal suivante : "Interruption de l'examen en raison d'une détection hors session".

Cet incident peut survenir pour plusieurs raisons :

1. Le serveur a arrêté de répondre : il se peut que l'examen ne parvienne pas à obtenir une réponse de l'application dans un délai raisonnable car il est surchargé ou provisoirement arrêté. Pour le tester, désélectionnez la case à cocher "Détection en session" puis continuez l'examen.
2. Les paramètres ou les cookies de session requis n'ont pas été automatiquement détectés par l'examen dans la séquence de connexion : l'examen tentera automatiquement de détecter les cookies ou les paramètres dans la séquence de connexion qu'il considère liée à l'état de la session (par exemple "ASP.NET_SessionId", "JSESSIONID"). Ils seront répertoriés dans la liste des ID session de connexion. S'il existe d'autres identificateurs session qui n'ont pas été détectés, ajoutez-les à la liste des ID session et essayez de continuer l'examen. En cas de doute, essayez d'abord d'ajouter tout ce qui apparaît dans la séquence de connexion et si l'examen peut alors rester en session, vous pouvez supprimer certains ID jusqu'à ce que le cookie ou le paramètre spécifique soit isolé. Pour déterminer les cookies ou les paramètres à ajouter, accédez à la liste des ID session de connexion, mettez en évidence chaque adresse URL, cliquez sur le bouton Afficher la requête HTTP, puis examinez les cookies et les paramètres dans l'en-tête HTTP.
3. La page en session n'est pas accessible si elle est demandée hors séquence : étant donné que l'examen interroge la page en session régulièrement pendant son exécution, il interroge la page alors qu'il la visite dans la même session et que ce n'est pas nécessaire, conformément à l'enregistrement de la séquence de connexion. Si vous pensez que l'examen ne reste pas en session en raison de ce type de configuration, essayez de procéder au test en explorant la séquence avec votre navigateur, en copiant l'adresse URL que l'examen utilise comme page en session, puis en explorant rapidement l'application et en forçant le parcours de la page en question. Si vous ne parvenez pas à voir le texte de la réponse que vous avez précédemment marquée (par exemple, vous êtes redirigé vers une page d'erreur personnalisée), essayez de sélectionner d'autres pages comme page en session jusqu'à ce que vous en trouviez une permettant ce type de comportement.
4. La page en session détectée est un POST associé aux paramètres de connexion : si l'examen détecte automatiquement une page comme étant sa page en session et que vous remarquez qu'il ne parvient pas à rester en session pendant son exécution, examinez la page marquée en la mettant en évidence et en cliquant sur le bouton Afficher la requête HTTP. Si la page contient les paramètres de nom d'utilisateur et de mot de passe, essayez de sélectionner une autre page plus bas dans la liste, marquez son masque dans le navigateur puis continuez l'examen. Si aucune autre page ne peut être sélectionnée, essayez d'enregistrer à nouveau la séquence de connexion et incluez une page supplémentaire dans l'exploration puis marquez cette page comme étant votre page en session.
5. Un masque en session ne correspond pas à la réponse réelle. Par exemple, il se peut que vous ayez entré "logout" comme masque mais qu'un utilisateur ait modifié le site et que le texte soit désormais "log out". Utilisez la fonction de requête HTTP pour déterminer les différences entre la réponse attendue "logout" et la réponse réelle "log out". Modifiez le masque si nécessaire et procédez à nouveau à l'examen. Ensuite, vérifiez la réponse de la requête HTTP à nouveau.