Partager via


Reboot

TAEF permet à un test de spécifier qu’il peut provoquer ou exiger le redémarrage de l’ordinateur. La fonctionnalité se compose de deux à trois composants : les métadonnées pour marquer le test comme pouvant provoquer ou nécessiter un redémarrage, une API pour demander à TAEF d’effectuer un redémarrage ou d’informer TAEF d’un redémarrage imminent initié par le test, et une option de commande pour choisir d’exécuter ces tests lors de l’exécution locale.

Comportement

La sémantique particulière du redémarrage de l’ordinateur nécessite certaines modifications du modèle d’exécution TAEF, des garanties des opérations d’installation et de nettoyage, ainsi que du comportement de réussite et d’échec.

  • Le comportement de redémarrage n’est disponible que pour un test (avec les métadonnées appropriées), et non pour les montages (configuration et nettoyage).
  • Si l’API Redémarrage est utilisée à partir d’un autre endroit qu’un test avec le balisage approprié, la fonction ne retourne pas. Au lieu de cela, TAEF tue le processus de test. Cela représente un bogue dans la façon dont le test a été écrit et le code de test doit être corrigé.
  • Les montages de test ne seront pas exécutés sur la limite de redémarrage. Cela signifie que les opérations de démontage ne sont pas exécutées avant le redémarrage (que le test lance le redémarrage ou demande que TAEF provoque le redémarrage lui-même) et que les opérations d’installation ne soient pas exécutées après le redémarrage.
  • La journalisation (et par conséquent les échecs de journalisation) sera ignorée à partir du moment où vous notifiez ou demandez un redémarrage jusqu’à la fin du test.

Métadonnées

Pour activer l’utilisation des API de redémarrage, un test doit être marqué en définissant les métadonnées RebootPossible sur« true ». Ces métadonnées obéissent aux règles habituelles d’héritage des métadonnées, de sorte qu’elles peuvent être spécifiées au niveau de la classe si un test de votre classe peut redémarrer (bien que compte tenu de la nature plutôt lourde du redémarrage, il est recommandé de prendre des décisions explicites sur le test qui peut et ne peut pas lancer des redémarrages). Pour obtenir des exemples de spécification de métadonnées, reportez-vous à la documentation relative à la création de tests en C++ et à la création de tests en C #.

API

Il existe deux fonctions main pour gérer les redémarrages d’ordinateur :

  • Reboot(Option) demande à TAEF de lancer un redémarrage de l’ordinateur de test.
  • RebootCustom(Option) avertit TAEF que le test provoquera un redémarrage de l’ordinateur de test. Cette API prend également en charge les incidents système. TAEF s’assure que les données applicables sont vidées après le retour de l’API.

Le paramètre Option spécifie le comportement du CV, l’un des éléments suivants :

  • Réexécutez, entraînant l’exécution du même test par TAEF après le redémarrage
  • Continuez, entraînant TAEF à exécuter le test suivant après le redémarrage

Natif

Accédez aux API de redémarrage en incluant l’en-tête Interruption.h et en appelant les fonctions dans l’espace de noms WEX::TestExecution::Interruption . Les quatre appels possibles sont les suivants :

using namespace WEX::TestExecution;
Interruption::Reboot(RebootOption::Rerun);
Interruption::Reboot(RebootOption::Continue);
Interruption::RebootCustom(RebootOption::Rerun);
Interruption::RebootCustom(RebootOption::Continue);

Géré

Appelez l’une des deux méthodes de la classe statique Interruption dans le WEX. Espace de noms TestExecution , qui se trouve dans Te.Managed.dll:

using WEX.TestExecution;
Interruption.Reboot(RebootOption.Rerun);
Interruption.Reboot(RebootOption.Continue);
Interruption.RebootCustom(RebootOption.Rerun);
Interruption.RebootCustom(RebootOption.Continue);

Utilisation de l’invite de commandes

L’utilisation idéale pour cette fonctionnalité consiste à exécuter des tests TAEF qui seront potentiellement redémarrés avec l’exécution inter-machine ou via WTT. Dans ce cas, TAEF permet de redémarrer l’exécution implicitement*, car il ne doit pas perturber votre flux de travail. Si vous exécutez un redémarrage manuel des tests sur l’ordinateur local ou si vous devez remplacer le chemin d’accès par défaut utilisé par TAEF pour mettre en cache son état, vous devez explicitement choisir de redémarrer les tests. Si ce n’est pas le cas, tout test de redémarrage sera marqué comme étant bloqué. Pour activer le redémarrage des tests lors de l’exécution locale, utilisez l’argument de commande suivant :

Te.exe /rebootStateFile:MyRestartFile.xml

TAEF crée le fichier spécifié pour stocker son état (quels tests ont déjà été exécutés, toutes les commandes ou options d’environnement TAEF, etc.) et reprend là où il s’est arrêté lorsqu’il reprend après le redémarrage. TAEF gère la ré-exécution de lui-même une fois que l’ordinateur est relancé après le redémarrage.

Notez que cette option ne fonctionne pas sur les ordinateurs Arm en raison de la suppression d’une fonctionnalité dont dépend TAEF pour reprendre les tests après le redémarrage (clé RunOnce).

* Tant que vous n’utilisez pas de fonctionnalités d’exécution incompatibles (actuellement , les modes Parallèle et Test).

Forum Aux Questions

Si je choisis Réexécuter, existe-t-il un moyen de déterminer si le test est appelé pour la première fois ou après un redémarrage ?

TAEF ne fournit aucune fonctionnalité vous permettant d’y parvenir. L’objectif de l’option réexécuter est de vous permettre d’écrire des tests qui peuvent nécessiter un nombre indéterminé de redémarrages en fonction de l’état de l’ordinateur (par exemple, l’exécution de Windows Update à l’achèvement). Envisagez d’utiliser un ExecutionGroup et l’option continuer pour décomposer les tâches en opérations de test distinctes qui se produisent dans l’ordre avant/après le redémarrage.

Quels types de test TAEF sont pris en charge ?

Cette fonctionnalité est disponible pour les tests natifs, managés et de script.