aet - Online en la nube

PROGRAMA:

NOMBRE

prueba aegis - ejecutar pruebas

SINOPSIS

égida -Prueba [ opción...] [ nombre =propuesta de ][ nombre del archivo...]
égida -Prueba -Independiente [ opción...] [ nombre =propuesta de ][ nombre del archivo...]
égida -Prueba -Lista [ opción...]
égida -Prueba -Ayudar

DESCRIPCIÓN

El égida -Prueba El comando se usa para ejecutar pruebas. Si no se nombran archivos, todas las pruebas relevantes
se ejecutan. De forma predeterminada, se ejecutan tanto las pruebas automáticas como las manuales.

Puede nombrar directorios en la línea de comando y todas las pruebas relevantes en ese directorio
Se ejecutará el árbol en el cambio. Es un error si no hay pruebas relevantes.

Cada arquitectura debe probarse por separado. Esto se debe a que puede haber sutiles
problemas que solo se revelan en algunas arquitecturas. Algunos proyectos también pueden tener
código diferente para diferentes arquitecturas.

El estado de la última ejecución de prueba se recuerda para que las pruebas no se ejecuten si no hay
necesitar. (Esto no se aplica a -Regresión pruebas, desafortunadamente). Las pruebas deben volver a ejecutarse
si la prueba falló anteriormente, si el archivo de prueba ha cambiado, si ha habido una compilación,
y para cada arquitectura.

Nombre = valor
Puede añadir nombre =propuesta de pares a la línea de comando, estos se pasarán sin cambios a la
comando de prueba. Por lo general, al final de la línea de comando, pero esto se puede cambiar en el
archivo de configuración del proyecto.

El -fuerza La opción da como resultado una fuerza implícita = 1 variable que se agrega a la lista de
asignaciones de variables y, por lo tanto, se agregan al final del comando. Esto es de mayor utilidad cuando
usando el comando_prueba_lote archivado del archivo de configuración del proyecto.

Inicialmente, esto puede parecer un proceso de desarrollo de ejecución final, lo que permite que los scripts de prueba sean
escrito para que den todas las respuestas correctas sin hacer nada. usted
siempre he podido hacer esto con variables de entorno, por lo que esto no es nada nuevo.

Es posible hacer que todas las asignaciones de variables se conviertan en variables de entorno
poniendo $ var en el comienzo del comando, antes del nombre del shell, en lugar de en
la ubicación predeterminada al final del comando.

Archive Nombre Interpretación
El programa aegis intentará determinar los nombres de los archivos del proyecto a partir de los nombres de los archivos.
dado en la línea de comando. Todos los nombres de archivo se almacenan dentro de los proyectos de aegis como relativos
a la raíz del árbol de directorios de la línea base. El directorio de desarrollo y el
directorio de integración son sombras de este directorio de línea base, por lo que estos nombres relativos
aplicar aquí también. Los archivos nombrados en la línea de comando se convierten primero en rutas absolutas
si necesario. Luego se comparan con la ruta de referencia, el directorio de desarrollo
ruta y la ruta del directorio de integración, para determinar un nombre relativo a la línea de base. Está
un error si el archivo nombrado está fuera de uno de estos árboles de directorios.

El -BAse_RElativo La opción se puede utilizar para hacer que los nombres de archivo relativos se interpreten como
en relación con la ruta de la línea de base; Los nombres de archivo absolutos se seguirán comparando con los distintos
rutas para determinar un nombre relativo a la línea de base.

El relativa_de_archivo_de_preferencia en el archivo de configuración del usuario se puede utilizar para modificar
este comportamiento predeterminado. Ver aeuconf(5) para obtener más información.

PROBAR NUESTRO PROCESO

Cada cambio debe ir acompañado de pruebas, y esas pruebas deben ser
se ejecutan en el directorio de desarrollo creado y deben pasar. Esto asegura que los nuevos
La funcionalidad va acompañada de pruebas para verificar su corrección, y las correcciones de errores son
acompañado de pruebas que confirman que el error se ha solucionado.

Regresión Examenes
Las pruebas se tratan como cualquier otro archivo fuente y se mantienen en la línea de base y
historial con todos los demás archivos de origen. Las pruebas que deben acompañar a cada cambio
se acumulan en la línea de base del proyecto, proporcionando una definición de función correcta para el
base. Estas pruebas acumuladas se pueden ejecutar utilizando un comando "aegis -REGression",
para verificar que el proyecto no “retrocederá” como resultado de un cambio.

Base Examenes
Se requieren correcciones de errores para realizar sus pruebas fallar contra la línea de base del proyecto (en contraste
al directorio de desarrollo). Esto asegura que la prueba realmente demuestre el error.
en la línea de base, además de demostrar que está fijado por el cambio. Nuevo
La funcionalidad falla trivialmente con respecto a la línea de base, por lo que la égida no intenta
Supongo que si una prueba es una prueba de corrección de errores o una prueba de funcionalidad nueva, simplemente requiere pruebas para
fallar contra la línea de base.

Este requisito se aplica tanto a las nuevas pruebas creadas por un cambio como a las pruebas
que se han copiado en un cambio para su modificación.

Revisión Examenes
Los revisores pueden estar seguros de que aegis ha hecho cumplir los requisitos de las pruebas; que un cambio
debe tener pruebas, que el cambio debe construir, que las pruebas pasan contra el desarrollo
directorio, y que las pruebas fallan contra la línea de base. Estas condiciones se hacen cumplir
by aede(1) y el cambio no se adelantará al "Ser" revisado estado hasta estos
se cumplen las condiciones. Por lo tanto, los revisores deben revisar las pruebas para lo completo de cobertura de
el código en el cambio, y la insensibilidad a los cambios en el entorno de ejecución (p. ej.
no sensible a la fecha). Los revisores también deben usar "aegis -list change_details" para verificar
que un cambio tiene o no exenciones de prueba.

exenciones
Los administradores de proyectos pueden otorgar varias exenciones de prueba, consulte Aepa(1) y
aepattr(5) para obtener más información. Copiar pruebas en un cambio o agregar nuevas pruebas a una
cambiar, puede cancelar esas exenciones.

PROBAR COMANDO CONFIGURACIÓN

El comando utilizado para ejecutar las pruebas está definido por el prueba_comando campo en el proyecto
archivo de configuración (ver aepconf(5) para obtener más información), por defecto se utiliza el
Shell Bourne si no está configurado. El directorio actual será la parte superior del correspondiente
árbol de directorio. Si las pruebas requieren archivos temporales, deben crearlos en / Tmp, como
prueba no puede esperar tener permiso de escritura en el directorio actual.

Si desea utilizar un motor de prueba más sofisticado, en lugar de un simple script de shell,
pero este motor de prueba no devuelve códigos de resultado adecuados para su uso con aegis, podría
envuélvalo en un script de shell que reescribe el estado de salida en los valores que espera aegis.
También puede lograr los mismos resultados escribiendo una versión más compleja. prueba_comando existentes
proyecto config archivo.

También es posible escribir comandos de prueba que puedan probar más de un archivo en
una vez. Esto está controlado por el comando_prueba_lote campo del proyecto config expediente. En
En este caso, la sustitución $ {salida} indica el nombre de un archivo que el comando de prueba debe
crear en prueba(5) formato, para contener los resultados de las pruebas ejecutadas. Esto se usa a menudo
en sistemas con varias CPU o la capacidad de distribuir trabajos entre varias computadoras
en una red.

Sustituciones
Todas las aesub(5) las sustituciones están disponibles en los comandos de prueba. Algunos de ellos son
de particular interés:

Arquitectura
Esta sustitución se reemplaza por el nombre de la arquitectura que se probará.

ruta_de_búsqueda
Esta sustitución se reemplaza por una lista separada por dos puntos de rutas absolutas a
busque cuando busque archivos de soporte de prueba.

Ruta_de_búsqueda_ejecutable
Esta sustitución se reemplaza por una lista separada por dos puntos de rutas absolutas a
buscar al buscar archivos de soporte ejecutables (archivos de biblioteca y sub-
comandos).

La mayor parte del tiempo $ Search_Path_Executable son exactamente iguales. Sin embargo, durante "aegis -t
-bl ”serán diferentes, con $ Seach_Path comenzando en el directorio de desarrollo (el
prueba en ejecución) y $ Seach_Path_Executable comenzando en la línea de base (el ejecutable es
correr).

Probar Resultado Códigos
A medida que se ejecuta cada prueba (a través del prueba_comando campo en el proyecto config archivo), aegis
determina si la prueba tuvo éxito o falló al observar su estado de salida. Esta salida
el estado es principalmente el esperado para los comandos de UNIX.

éxito
Una prueba debe salir de 0 para indicar éxito, es decir, que la función específica bajo prueba
funcionó como se esperaba.

Fracaso
Una prueba debe salir 1 para indicar falla, es decir, que la función específica bajo prueba
no funcionó como se esperaba.

Sin resultado
Una prueba debe salir de 2 para indicar que no hay resultado, es decir, que la función específica bajo
no se pudo realizar la prueba porque algo más salió mal. Por ejemplo, corriendo
espacio en disco al crear los archivos de entrada de prueba en el / Tmp directorio.

Saltado
Una prueba debe salir de 77 para indicar que se omitió. Esto suele tener que ver con
la arquitectura actual no es significativa. Siempre que sea posible, use "Sin resultado"
en lugar de. (El valor se eligió por compatibilidad con otros sistemas de prueba).

En realidad, cualquier código de salida que no sea 0, 1 o 77 se interpretará como "sin resultado".
Sin embargo, usar siempre 0, 1, 2 o 77 significa que si un nuevo código de resultado es requerido por un
En una versión posterior de Aegis, las pruebas existentes seguirán funcionando.

PROBAR CORRELACIONES

El comando "aegis -Test -SUGgest" se puede utilizar para que aegis sugiera una regresión adecuada
pruebas para su cambio, según los archivos de origen de su cambio. Esto automáticamente
concentra el esfuerzo de prueba en pruebas relevantes, reduciendo el número de pruebas de regresión
necesario estar seguro de que no ha introducido un error.

Las correlaciones de prueba son generadas por el comando "aegis -Integrate_Pass", que
asocia cada prueba del cambio con cada archivo fuente del cambio. Por lo tanto, cada
El archivo de origen acumula una lista de pruebas que se han asociado con él en el pasado.
Esto no es tan exacto como el análisis de cobertura de código, pero es una aproximación razonable en
práctica.

El aecp(1) y aenf(1) los comandos se utilizan para asociar archivos con un cambio. Mientras ellos
no realizan activamente la asociación, estos son los archivos utilizados por aeipass(1) y
aet(1) para determinar qué archivos fuente están asociados con qué pruebas.

Probar La correlación Exactitud
Suponiendo que las correlaciones de las pruebas son precisas y que las pruebas son uniformes
distribuidos en todo el espacio funcional, habrá menos de 1 / número posibilidad de que un
la prueba relevante no ha sido ejecutada por el "aegis -Test -SUGgest número"Comando. Un pequeño
Se agrega una cantidad de ruido a la ponderación de prueba, por lo que a veces se producen cosas inesperadas.
probado, y las mismas pruebas no se ejecutan siempre.

La precisión de la correlación de la prueba se puede mejorar asegurándose de que:

· Cada cambio debe estar fuertemente enfocado, sin inclusiones de archivos gratuitas. Esta
evita correlaciones falsas.

· Cada elemento de nueva funcionalidad debe agregarse en un cambio individual, en lugar de
varios juntos. Esto correlaciona fuertemente las pruebas con la funcionalidad.

· Cada error debe corregirse en un cambio individual, en lugar de varios juntos. Esta
correlaciona fuertemente las pruebas con la funcionalidad.

· Las correlaciones de prueba se perderán si se mueven los archivos. Esto se debe a que las correlaciones son por
nombre.

La mejor manera de que las pruebas se correlacionen con precisión con los archivos de origen es cuando se produce un cambio
contiene una prueba y exactamente los archivos relacionados con la funcionalidad bajo prueba. También
muchos archivos falsos debilitarán la utilidad de las correlaciones de prueba.

CAMPUS

Se entienden las siguientes opciones:

-Automático
Esta opción se puede utilizar para especificar pruebas automáticas. Las pruebas automáticas no requieren
asistencia humana.

-Base
Esta opción puede usarse para especificar que la línea de base del proyecto es el tema de
El comando.

-BAse_RElativo
Esta opción se puede utilizar para hacer que los nombres de archivo relativos se consideren relativos a
la base del árbol de origen. Ver aeuconf(5) para el usuario correspondiente
preferencia.

-CURrent_RElativo
Esta opción se puede utilizar para hacer que los nombres de archivo relativos se consideren relativos a
el directorio actual. Suele ser el predeterminado. Ver aeuconf(5) para el
preferencia del usuario correspondiente.

-Cambio número
Esta opción puede usarse para especificar un cambio particular dentro de un proyecto. Ver
égida(1) para obtener una descripción completa de esta opción.

-Fuerza Esta opción se puede utilizar para especificar que se deben ejecutar todas las pruebas, incluso si el
El estado de la última ejecución de prueba indica que no es necesario ejecutar una
.

-Ayudar
Esta opción se puede utilizar para obtener más información sobre cómo utilizar el égida
.

-Independiente
Esta opción se utiliza para especificar que la prueba se ejecutará independientemente de cualquier
cambio particular. Si no se nombra ninguna prueba, se ejecutarán todas las pruebas de la línea base.

-Lista
Esta opción se puede utilizar para obtener una lista de temas adecuados para este comando.
La lista puede ser más general de lo esperado.

-Manual Esta opción se puede utilizar para especificar pruebas manuales. Las pruebas manuales requieren algunos
intervención, por ejemplo: confirmación de algún comportamiento de la pantalla (X11, por ejemplo), o
alguna acción del usuario, "desenchufe el cable ethernet ahora".

-No_Logging
Esta opción se puede utilizar para deshabilitar el registro automático de resultados y errores para
un archivo. Esto suele ser útil cuando se combinan varios comandos aegis en un shell.
guión.

-Perseverar
Esta opción se puede utilizar para especificar que se deben ejecutar todas las pruebas, incluso si algunas
fallar. Predeterminado para el usuario perseverar_preferencia si no se especifica, consulte
aeuconf(5) para obtener más información.

-No_PEsevero
Esta opción se puede utilizar para especificar que la ejecución de prueba debe detenerse después de la primera
falla. Predeterminado para el usuario perseverar_preferencia si no se especifica, consulte
aeuconf(5) para obtener más información.

-Proyecto nombre
Esta opción se puede utilizar para seleccionar el proyecto de interés. Cuando no -Proyecto
se especifica la opción, la AEGIS_PROJECT se consulta la variable de entorno. Si
que no existe, el usuario $ INICIO / .aegisrc el archivo se examina por defecto
campo del proyecto (ver aeuconf(5) para obtener más información). Si eso no existe,
cuando el usuario solo está trabajando en cambios dentro de un solo proyecto, el proyecto
nombre predeterminado para ese proyecto. De lo contrario, es un error.

-Progreso
Esta opción se puede utilizar para especificar que los mensajes de progreso se deben emitir antes
cada ejecución de prueba o antes de cada ejecución de prueba de lote en caso de comando_prueba_lote campo
especificado en el proyecto config archivo (ver aeuconf(5) para obtener más información).

-Sin progreso
Esta opción se puede utilizar para especificar que se deben suprimir los mensajes de progreso.
Este es el predeterminado.

-Regresión
Esta opción se utiliza para especificar que se ejecutará el conjunto de pruebas de regresión. los
El conjunto de pruebas de regresión consta de todas las pruebas en la línea de base que no aparecen
en el cambio. Es un error si no hay pruebas de regresión. No deberias
pruebas de nombre en la línea de comando cuando se usa la opción -REGresión. Puedes nombrar
pruebas individuales que se ejecutarán en la línea de comando, sin utilizar la opción -REGression
opción; si no son parte del cambio, las pruebas del mismo nombre en el
se ejecutará la línea de base.

-Sugerir [ número ]
Los "égida -Integrar_PasarEl comando "recopila estadísticas de correlación de prueba cuando
los cambios están integrados. Esta opción se puede utilizar para solicitar que aegis sugiera
qué pruebas deben ejecutarse, utilizando estas correlaciones de prueba. Si ningún número es
especificado, se propondrán 10 pruebas. Esta opción implica la -Regresión
.

-SUGgest_Limit minutos
Esta opción se puede utilizar para limitar el número de pruebas a un cierto número de
minutos. Se ejecutarán desde el más relevante al menos relevante.

-SUGgest_Ruido número
Esta opción se puede utilizar para controlar la cantidad de ruido inyectado en la prueba.
selección realizada por el -Sugerir opción. El número es un porcentaje de ruido.
para ser inyectado. El valor predeterminado es 10 si no se especifica. La inyección de ruido asegura
que se ejecutan una variedad de pruebas en ejecuciones posteriores, y también algunas desde el campo izquierdo
como prueba de cordura.

-Breve
Esta opción puede usarse para hacer que los listados produzcan el mínimo de
información. Suele ser útil para scripts de shell.

-Verboso
Esta opción puede usarse para hacer que aegis produzca más resultados. Por defecto aegis
solo produce salida sobre errores. Cuando se usa con el -Lista opción esta opción
hace que se agreguen encabezados de columna.

-Esperar Esta opción puede usarse para requerir que los comandos Aegis esperen los bloqueos de acceso, si
no se pueden obtener de inmediato. Predeterminado para el usuario preferencia_lock_wait
si no se especifica, consulte aeuconf(5) para obtener más información.

-No, espera
Esta opción puede usarse para requerir que los comandos Aegis emitan un error fatal si el acceso
las cerraduras no se pueden obtener inmediatamente. Predeterminado para el usuario
preferencia_lock_wait si no se especifica, consulte aeuconf(5) para obtener más información.

Vea también égida(1) para opciones comunes a todos los comandos de aegis.

Todas las opciones pueden abreviarse; la abreviatura está documentada como letras mayúsculas,
todas las letras minúsculas y los guiones bajos (_) son opcionales. Debes usar consecutivo
secuencias de letras opcionales.

Todas las opciones no distinguen entre mayúsculas y minúsculas, puede escribirlas en mayúsculas, minúsculas o
combinación de ambos, el caso no es importante.

Por ejemplo: los argumentos "-proyecto," -PROJ "y" -p "se interpretan en el sentido de
-Proyecto opción. El argumento "-prj" no se entenderá, porque consecutivo
no se proporcionaron caracteres opcionales.

Las opciones y otros argumentos de la línea de comando se pueden mezclar arbitrariamente en la línea de comando,
después de los selectores de funciones.

Se entienden los nombres largos de las opciones de GNU. Dado que todos los nombres de opciones para égida son largos,
esto significa ignorar el interlineado adicional '-'. Los "--opción=propuesta de"la convención también es
entendido.

RECOMENDADO ALIAS

El alias recomendado para este comando es
csh% alias aet 'aegis -t \! * -v'
sh $ aet () {aegis -t "$ @" -v}

ERRORES

Es un error si el cambio no está en uno de los "Ser" desarrollado or "Ser" COMPLETAMENTE
, pioneros en BreatheLife.
Es un error si el cambio no se asigna al usuario actual.
Es un error si no tiene pruebas relevantes ni exenciones relevantes.

SALIR ESTADO

El égida El comando saldrá con un estado de 1 en cualquier error. los égida el comando solo
salir con un estado de 0 si no hay errores.

MEDIO AMBIENTE VARIABLES

See égida(1) para obtener una lista de variables de entorno que pueden afectar este comando. Ver
aepconf(5) para el archivo de configuración del proyecto Proyecto específico campo para saber cómo configurar
variables de entorno para todos los comandos ejecutados por Aegis.

Use aet en línea usando los servicios de onworks.net