aet - En ligne dans le Cloud

PROGRAMME:

Nom

test égide - exécuter des tests

SYNOPSIS

égide -Tester [ option... ][ prénom=Plus-value ][ nom de fichier...]
égide -Tester -Indépendant [ option... ][ prénom=Plus-value ][ nom de fichier...]
égide -Tester -Lister [ option...]
égide -Tester -Aidez-moi

DESCRIPTION

La égide -Tester La commande est utilisée pour exécuter des tests. Si aucun fichier n'est nommé, tous les tests pertinents
sont exécutés. Par défaut, les tests automatiques et manuels sont exécutés.

Vous pouvez nommer des répertoires sur la ligne de commande et tous les tests pertinents dans ce répertoire
arbre dans le changement sera exécuté. C'est une erreur s'il n'y a pas de tests pertinents.

Chaque architecture doit être testée séparément. C'est parce qu'il peut y avoir des subtilités
problèmes qui ne sont révélés que sur certaines architectures. Certains projets peuvent également avoir
code différent pour différentes architectures.

L'état du dernier test exécuté est mémorisé afin que les tests ne soient pas exécutés s'il n'y a pas
avoir besoin. (Ceci ne s'applique pas à -Régression tests, malheureusement.) Les tests doivent être réexécutés
si le test a échoué précédemment, si le fichier de test a changé, s'il y a eu un build,
et pour chaque architecture.

nom=valeur
Vous pouvez ajouter prénom=Plus-value paires à la ligne de commande, celles-ci seront transmises telles quelles au
commande d'essai. Généralement à la fin de la ligne de commande, mais cela peut être modifié dans le
fichier de configuration du projet.

La -Obliger L'option entraîne l'ajout d'une variable implicite force=1 à la liste des
affectations de variables, et donc ajoutées à la fin de la commande. Ceci est très utile lorsque
utilisant l' batch_test_command déposé du fichier de configuration du projet.

Cela peut initialement ressembler à une fin de processus de développement, permettant aux scripts de test d'être
écrit de manière à ce qu'ils donnent toutes les bonnes réponses sans rien faire. Tu
ont toujours été capables de le faire avec des variables d'environnement, ce n'est donc pas nouveau.

Il est possible de transformer toutes les affectations de variables en variables d'environnement
en mettant $var au Commencer de la commande, avant le nom du shell, plutôt qu'à
l'emplacement par défaut à la fin de la commande.

Déposez votre dernière attestation Nom Interprétation
Le programme égide tentera de déterminer les noms de fichiers du projet à partir des noms de fichiers
donné sur la ligne de commande. Tous les noms de fichiers sont stockés dans les projets égide en tant que relatifs
à la racine de l'arborescence de répertoires de base. L'annuaire de développement et le
répertoire d'intégration sont des ombres de ce répertoire de base, et donc ces noms relatifs
postulez ici aussi. Les fichiers nommés sur la ligne de commande sont d'abord convertis en chemins absolus
si nécessaire. Ils sont ensuite comparés au chemin de référence, le répertoire de développement
chemin et le chemin du répertoire d'intégration, pour déterminer un nom relatif à la ligne de base. Il est
une erreur si le fichier nommé se trouve en dehors de l'une de ces arborescences de répertoires.

La -BAse_RElative L'option peut être utilisée pour que les noms de fichiers relatifs soient interprétés comme
par rapport au chemin de la ligne de base ; les noms de fichiers absolus seront toujours comparés aux différents
chemins afin de déterminer un nom relatif à la ligne de base.

La nom_fichier_relatif_préférence dans le fichier de configuration utilisateur peut être utilisé pour modifier
ce comportement par défaut. Voir aeuconf(5) pour plus d'informations.

TEST PROCESSUS

Chaque changement doit être accompagné de tests, et ces tests doivent être
exécutés sur le répertoire de développement construit, et ils doivent réussir. Cela garantit que les nouveaux
la fonctionnalité est accompagnée de tests pour vérifier son exactitude, et des corrections de bogues sont
accompagné de tests qui confirment que le bogue a été corrigé.

Régression Tests
Les tests sont traités comme tout autre fichier source et sont conservés dans la ligne de base et
historique avec tous les autres fichiers sources. Les tests qui doivent accompagner chaque changement
s'accumulent dans la référence du projet, fournissant une définition de la fonction correcte pour le
ligne de base. Ces tests cumulés peuvent être exécutés à l'aide d'une commande « aegis -REGression »,
pour vérifier que le projet ne « régressera » pas à la suite d'un changement.

Baseline Tests
Des corrections de bugs sont nécessaires pour avoir leurs tests échouer par rapport à la référence du projet (par opposition
dans le répertoire de développement). Cela garantit que le test démontre réellement le bogue
dans la ligne de base, ainsi que de démontrer qu'il est fixé par le changement. Nouveau
la fonctionnalité échoue trivialement par rapport à la ligne de base, et donc aegis ne tente pas de
devinez si un test est un test de correction de bogue ou un test de nouvelle fonctionnalité, il nécessite simplement des tests pour
échouer par rapport à la ligne de base.

Cette exigence s'applique à la fois aux nouveaux tests créés par un changement et également aux tests
qui ont été copiés dans un changement pour modification.

Révision Tests
Les évaluateurs peuvent être sûrs qu'aegis a appliqué les exigences du test ; qu'un changement
doit avoir des tests, que le changement doit construire, que les tests passent contre le développement
répertoire et que les tests échouent par rapport à la ligne de base. Ces conditions sont appliquées
by aede(1) et le changement ne sera pas avancé au va examiné état jusqu'à ce que ces
les conditions sont réunies. Les examinateurs devraient donc examiner les tests pour complétude de couverture de
le code dans le changement, et l'insensibilité aux changements dans l'environnement d'exécution (par exemple
non sensible à la date). Les évaluateurs doivent également utiliser « aegis -list change_details » pour vérifier
qu'un changement a ou n'a pas d'exemptions de test.

Exemptions
Diverses exemptions de tests peuvent être accordées par les administrateurs de projet, voir aepade Géographie (1) et avec la
aepattr(5) pour plus d'informations. Copier des tests dans un changement ou ajouter de nouveaux tests à un
changement, peut annuler ces exemptions.

TEST COMMAND CONFIGURATION

La commande utilisée pour exécuter les tests est définie par le test_commande terrain dans le projet
fichier de configuration (voir aepconf(5) pour plus d'informations), cela utilise par défaut le
Bourne shell s'il n'est pas défini. Le répertoire courant sera le haut du répertoire approprié
arborescence de répertoires. Si les tests nécessitent des fichiers temporaires, ils doivent les créer dans / Tmp, comme un
test ne peut pas s'attendre à avoir une autorisation d'écriture dans le répertoire actuel.

Si vous souhaitez utiliser un moteur de test plus sophistiqué, plutôt qu'un simple script shell,
mais ce moteur de test ne renvoie pas de codes de résultat adaptés à une utilisation avec aegis, vous pouvez
enveloppez-le dans un script shell qui réécrit l'état de sortie dans les valeurs attendues par aegis.
Vous pouvez également obtenir les mêmes résultats en écrivant un texte plus complexe test_commande dans l'
Projet config fichier.

Il est également possible d'écrire des commandes de test capables de tester plus d'un fichier à
une fois que. Ceci est contrôlé par le batch_test_command domaine du projet config déposer. Dans
dans ce cas, la substitution ${output} indique le nom d'un fichier que la commande de test doit
créer, dans etest(5) format, pour contenir les résultats des tests exécutés. Ceci est souvent utilisé
sur des systèmes avec plusieurs processeurs ou la possibilité de répartir les tâches sur plusieurs ordinateurs
sur un réseau.

remplacements
Toutes les aesub(5) des substitutions sont disponibles dans les commandes de test. Certains d'entre eux sont
à noter en particulier :

Architecture
Cette substitution est remplacée par le nom de l'architecture à tester.

Chemin_recherche
Cette substitution est remplacée par une liste de chemins absolus séparés par deux points vers
rechercher lors de la recherche de fichiers de support de test.

Search_Path_Executable
Cette substitution est remplacée par une liste de chemins absolus séparés par deux points vers
rechercher lors de la recherche de fichiers de support exécutables (fichiers de bibliothèque et sous-
commandes).

La plupart du temps $Chemin_Recherche_Exécutable sont exactement les mêmes. Cependant, pendant « égide -t
-bl" ils seront différents, avec $Chemin_Recherche en commençant par le répertoire de développement (le
test en cours) et $Search_Path_Executable à partir de la ligne de base (l'exécutable étant
Cours).

Teste Résultat Codes
Au fur et à mesure que chaque test est exécuté (via le test_commande terrain dans le projet config dossier), égide
détermine si le test a réussi ou échoué en regardant son état de sortie. Cette sortie
l'état est principalement celui attendu pour les commandes UNIX.

en ligne
Un test doit quitter 0 pour indiquer le succès, c'est-à-dire que la fonction spécifique testée
a fonctionné comme prévu.

Échec
Un test doit sortir 1 pour indiquer l'échec, c'est-à-dire que la fonction spécifique testée
n'a pas fonctionné comme prévu.

Pas de résultat
Un test doit sortir 2 pour indiquer aucun résultat, à que la fonction spécifique sous
le test n'a pas pu être exercé parce que quelque chose d'autre s'est mal passé. Par exemple, courir
manque d'espace disque lors de la création des fichiers d'entrée de test dans le / Tmp répertoire.

Ignoré
Un test doit quitter 77 pour indiquer qu'il a été ignoré. Cela a généralement à voir avec
l'architecture actuelle n'étant pas significative. Dans la mesure du possible, utilisez « Aucun résultat »
au lieu. (La valeur a été choisie pour la compatibilité avec d'autres systèmes de test.)

En fait, tout code de sortie autre que 0, 1 ou 77 sera interprété comme « pas de résultat ».
Cependant, toujours utiliser 0, 1, 2 ou 77 signifie que si un nouveau code de résultat est requis par un
version ultérieure d'Aegis, vos tests existants continueront de fonctionner.

TEST CORRÉLATIONS

La commande « aegis -Test -SUGgest » peut être utilisée pour que aegis suggère une régression appropriée
teste votre modification, en fonction des fichiers source de votre modification. Ceci automatiquement
concentre les efforts de test sur des tests pertinents, réduisant le nombre de tests de régression
nécessaire d'être sûr que vous n'avez pas introduit de bogue.

Les corrélations de test sont générées par la commande "aegis -Integrate_Pass", qui
associe chaque test de la modification à chaque fichier source de la modification. Ainsi, chaque
Le fichier source accumule une liste de tests qui lui ont été associés dans le passé.
Ce n'est pas aussi exact que l'analyse de couverture de code, mais c'est une approximation raisonnable dans
entraine toi.

La aecpde Géographie (1) et avec la aenf(1) les commandes sont utilisées pour associer des fichiers à une modification. Pendant qu'ils
n'effectuez pas activement l'association, ce sont les fichiers utilisés par aeipassde Géographie (1) et avec la
aet(1) pour déterminer quels fichiers sources sont associés à quels tests.

Teste Corrélation Précision
En supposant que les corrélations de test sont exactes et que les tests sont uniformément
répartis dans l'espace fonctionnel, il y aura moins de 1/nombre chance qu'un
le test pertinent n'a pas été exécuté par le "aegis -Test -SUGgest nombre" commande. Un petit
quantité de bruit est ajoutée à la pondération de test, de sorte que des choses inattendues sont parfois
testé, et les mêmes tests ne sont pas exécutés à chaque fois.

La précision de la corrélation des tests peut être améliorée en s'assurant que :

· Chaque changement doit être fortement ciblé, sans inclusions de fichiers gratuites. Cette
évite les fausses corrélations.

· Chaque élément de nouvelle fonctionnalité doit être ajouté dans un changement individuel, plutôt que
plusieurs ensemble. Cela corrèle fortement les tests avec la fonctionnalité.

· Chaque bogue devrait être corrigé dans un changement individuel, plutôt que plusieurs ensemble. Cette
corrèle fortement les tests avec la fonctionnalité.

· Les corrélations de test seront perdues si les fichiers sont déplacés. C'est parce que les corrélations sont par
nom.

Le meilleur moyen pour les tests d'établir une corrélation précise avec les fichiers source est lorsqu'un changement
contient un test et exactement les fichiers relatifs à la fonctionnalité testée. Trop
de nombreux fichiers parasites affaibliront l'utilité des tests de corrélation.

OPTIONS

Les options suivantes sont comprises :

-Automatique
Cette option peut être utilisée pour spécifier des tests automatiques. Les tests automatiques ne nécessitent aucun
aide humaine.

-Ligne de base
Cette option peut être utilisée pour spécifier que le référentiel du projet fait l'objet d'un
la commande.

-BAse_RElative
Cette option peut être utilisée pour que les noms de fichiers relatifs soient considérés par rapport à
la base de l'arbre source. Voir aeuconf(5) pour l'utilisateur correspondant
préférence.

-Current_RElative
Cette option peut être utilisée pour que les noms de fichiers relatifs soient considérés par rapport à
le répertoire courant. C'est généralement la valeur par défaut. Voir aeuconf(5) pour le
préférence correspondante de l'utilisateur.

-Changer nombre
Cette option peut être utilisée pour spécifier un changement particulier dans un projet. Voir
égide(1) pour une description complète de cette option.

-Obliger Cette option peut être utilisée pour spécifier que tous les tests doivent être exécutés, même si le
l'état du dernier test indique qu'il n'est pas nécessaire d'exécuter un
test.

-Aidez-moi
Cette option peut être utilisée pour obtenir plus d'informations sur la façon d'utiliser le égide
.

-Indépendant
Cette option est utilisée pour spécifier que le test doit être exécuté indépendamment de tout
changement particulier. Si aucun test n'est nommé, tous les tests de la ligne de base seront exécutés.

-Lister
Cette option peut être utilisée pour obtenir une liste de sujets appropriés pour cette commande.
La liste peut être plus générale que prévu.

-Manuel Cette option peut être utilisée pour spécifier des tests manuels. Les tests manuels nécessitent un peu d'humain
intervention, ex : confirmation d'un certain comportement d'écran (X11, par exemple), ou
une action de l'utilisateur, "débranchez le câble Ethernet maintenant".

-Not_Logging
Cette option peut être utilisée pour désactiver l'enregistrement automatique de la sortie et des erreurs à
un fichier. Ceci est souvent utile lorsque plusieurs commandes aegis sont combinées dans un shell
scripts.

-Persévérer
Cette option peut être utilisée pour spécifier que tous les tests doivent être exécutés, même si certains
échouer. Par défaut à l'utilisateur persévérer_préférence si non spécifié, voir
aeuconf(5) pour plus d'informations.

-No_PERsevere
Cette option peut être utilisée pour spécifier que le test doit s'arrêter après le premier
échec. Par défaut à l'utilisateur persévérer_préférence si non spécifié, voir
aeuconf(5) pour plus d'informations.

-Projet prénom
Cette option peut être utilisée pour sélectionner le projet d'intérêt. Quand non -Projet
l'option est spécifiée, le AEGIS_PROJET variable d'environnement est consultée. Si
qui n'existe pas, l'utilisateur $HOME/.aegisrc le fichier est examiné pour un défaut
domaine du projet (voir aeuconf(5) pour plus d'informations). Si cela n'existe pas,
lorsque l'utilisateur ne travaille que sur des modifications au sein d'un même projet, le projet
nom par défaut à ce projet. Sinon, c'est une erreur.

-Le progrès
Cette option peut être utilisée pour spécifier que les messages de progression doivent être émis avant
chaque essai ou avant chaque essai par lots au cas où batch_test_command champ
spécifié dans le projet config fichier (voir aeuconf(5) pour plus d'informations).

-Pas de progrès
Cette option peut être utilisée pour spécifier que les messages de progression doivent être supprimés.
C'est la valeur par défaut.

-Régression
Cette option est utilisée pour spécifier que la suite de tests de régression doit être exécutée. Les
la suite de tests de régression se compose de tous les tests de la ligne de base qui n'apparaissent pas
dans le changement. C'est une erreur s'il n'y a pas de tests de régression. Vous ne pouvez pas
name teste sur la ligne de commande lors de l'utilisation de l'option -REGression. Vous pouvez nommer
tests individuels à exécuter sur la ligne de commande, sans utiliser le -REGression
option; s'ils ne font pas partie du changement, les tests du même nom dans le
la ligne de base sera exécutée.

-Suggérer [ nombre ]
Le "égide -Intégrer_PassLa commande ” collecte les statistiques de corrélation de test lorsque
les changements sont intégrés. Cette option peut être utilisée pour demander qu'aegis suggère
quels tests doivent être exécutés, en utilisant ces corrélations de test. Si aucun numéro n'est
spécifié, 10 tests seront proposés. Cette option implique la -Régression
option.

-SUGgest_Limit minutes
Cette option peut être utilisée pour limiter le nombre de tests à un certain nombre de
minutes. Ils seront exécutés du plus pertinent au moins pertinent.

-SUGgest_Noise nombre
Cette option peut être utilisée pour contrôler la quantité de bruit injecté dans le test
sélection effectuée par le -Suggérer option. Le nombre est un pourcentage de bruit
à injecter. La valeur par défaut est 10 si non spécifié. L'injection de bruit assure
qu'une variété de tests sont exécutés sur les exécutions suivantes, ainsi que certains à partir du champ gauche
comme un test de santé mentale.

-Laconique
Cette option peut être utilisée pour que les annonces produisent le strict minimum de
informations. Il est généralement utile pour les scripts shell.

-Verbeux
Cette option peut être utilisée pour amener aegis à produire plus de sortie. Par défaut égide
ne produit une sortie que sur les erreurs. Lorsqu'il est utilisé avec le -Lister option cette option
provoque l'ajout d'en-têtes de colonnes.

-Attendez Cette option peut être utilisée pour exiger que les commandes Aegis attendent les verrous d'accès, si
ils ne peuvent pas être obtenus immédiatement. Par défaut à l'utilisateur lock_wait_preference
si non spécifié, voir aeuconf(5) pour plus d'informations.

-Non attends
Cette option peut être utilisée pour exiger que les commandes Aegis émettent une erreur fatale si l'accès
les serrures ne peuvent pas être obtenues immédiatement. Par défaut à l'utilisateur
lock_wait_preference si non spécifié, voir aeuconf(5) pour plus d'informations.

Voir aussi égide(1) pour les options communes à toutes les commandes aegis.

Toutes les options peuvent être abrégées ; l'abréviation est documentée en lettres majuscules,
toutes les lettres minuscules et les traits de soulignement (_) sont facultatifs. Vous devez utiliser consécutivement
séquences de lettres facultatives.

Toutes les options sont insensibles à la casse, vous pouvez les saisir en majuscules ou en minuscules ou un
combinaison des deux, la casse n'a pas d'importance.

Par exemple : les arguments "-project, "-PROJ" et "-p" sont tous interprétés comme signifiant le
-Projet option. L'argument "-prj" ne sera pas compris, car consécutifs
les caractères facultatifs n'ont pas été fournis.

Les options et autres arguments de ligne de commande peuvent être mélangés arbitrairement sur la ligne de commande,
après les sélecteurs de fonction.

Les noms d'options longs GNU sont compris. Étant donné que tous les noms d'option pour égide sont longues,
cela signifie ignorer le "-" de début supplémentaire. Les "--option=Plus-value" la convention est aussi
compris.

RECOMMANDÉ ALIAS

L'alias recommandé pour cette commande est
csh% alias aet 'aegis -t \!* -v'
sh$ aet(){aegis -t "$@" -v}

LES ERREURS

C'est une erreur si le changement n'est pas dans l'un des va développé or va des services
États.
C'est une erreur si la modification n'est pas attribuée à l'utilisateur actuel.
C'est une erreur si vous n'avez pas de tests pertinents et aucune exemption pertinente.

EXIT STATUT

La égide La commande se terminera avec un statut de 1 en cas d'erreur. Les égide la commande ne fera que
quitter avec un statut de 0 s'il n'y a pas d'erreurs.

ENVIRONNEMENT VARIABLES

See égide(1) pour une liste des variables d'environnement qui peuvent affecter cette commande. Voir
aepconf(5) pour le fichier de configuration du projet projet_spécifique champ pour savoir comment définir
variables d'environnement pour toutes les commandes exécutées par Aegis.

Utiliser aet en ligne en utilisant les services onworks.net