aet - Online na nuvem

PROGRAMA:

NOME

teste aegis - testes de execução

SINOPSE

Aegis -Teste [ opção...] [ nome=valor ][ nome do arquivo...]
Aegis -Teste -Independente [ opção...] [ nome=valor ][ nome do arquivo...]
Aegis -Teste -Lista [ opção...]
Aegis -Teste -Ajuda

DESCRIÇÃO

A Aegis -Teste comando é usado para executar testes. Se nenhum arquivo for nomeado, todos os testes relevantes
São executados. Por padrão, os testes automáticos e manuais são executados.

Você pode nomear diretórios na linha de comando e todos os testes relevantes nesse diretório
árvore na mudança será executada. É um erro se não houver testes relevantes.

Cada arquitetura deve ser testada separadamente. Isso ocorre porque pode haver sutil
problemas que só são revelados em algumas arquiteturas. Alguns projetos também podem ter
código diferente para arquiteturas diferentes.

O status da última execução de teste é lembrado para que os testes não sejam executados se não houver
necessidade. (Isso não se aplica a -Regressão testes, infelizmente.) Os testes devem ser executados novamente
se o teste falhou anteriormente, se o arquivo de teste foi alterado, se houve uma construção,
e para cada arquitetura.

nome = valor
Você pode adicionar nome=valor pares para a linha de comando, eles serão passados ​​inalterados para o
comando de teste. Normalmente no final da linha de comando, mas isso pode ser alterado no
arquivo de configuração do projeto.

A -força opção resulta em uma variável implícita force = 1 sendo adicionada à lista de
atribuições de variáveis ​​e, portanto, adicionadas ao final do comando. Isso é mais útil quando
usando o batch_test_command arquivado do arquivo de configuração do projeto.

Isso pode inicialmente parecer uma execução final do processo de desenvolvimento, permitindo que os scripts de teste sejam
escrito de forma que dêem todas as respostas certas, sem realmente fazer nada. Vocês
sempre foram capazes de fazer isso com variáveis ​​de ambiente, então isso não é nada novo.

É possível fazer com que todas as atribuições de variáveis ​​se transformem em variáveis ​​de ambiente
colocando $ var no começo do comando, antes do nome do shell, ao invés de em
o local padrão no final do comando.

Envie o Nome Interpretação
O programa aegis tentará determinar os nomes dos arquivos do projeto a partir dos nomes dos arquivos
fornecido na linha de comando. Todos os nomes de arquivo são armazenados em projetos aegis como relativos
para a raiz da árvore de diretórios da linha de base. O diretório de desenvolvimento e o
diretório de integração são sombras deste diretório de linha de base e, portanto, esses nomes relativos
aplique aqui também. Os arquivos nomeados na linha de comando são primeiro convertidos em caminhos absolutos
se necessário. Eles são então comparados com o caminho da linha de base, o diretório de desenvolvimento
caminho e o caminho do diretório de integração, para determinar um nome relativo à linha de base. Isto é
um erro se o arquivo nomeado estiver fora de uma dessas árvores de diretório.

A -BAse_RElativo opção pode ser usada para fazer com que os nomes de arquivos relativos sejam interpretados como
em relação ao caminho da linha de base; nomes de arquivos absolutos ainda serão comparados com os vários
caminhos para determinar um nome relativo à linha de base.

A valor_do_arquivo_relativo no arquivo de configuração do usuário pode ser usado para modificar
este comportamento padrão. Ver Aeuconf(5) para mais informações.

TESTE PROCEDIMENTO:

Cada mudança deve ser acompanhada por testes, e esses testes devem ser
executado no diretório de desenvolvimento construído, e eles devem passar. Isso garante que o novo
a funcionalidade é acompanhada por testes para verificar sua exatidão e as correções de bugs são
acompanhado por testes que confirmam que o bug foi corrigido.

Regressão Testes
Os testes são tratados como qualquer outro arquivo de origem e são mantidos na linha de base e
histórico com todos os outros arquivos de origem. Os testes que devem acompanhar cada mudança
acumular na linha de base do projeto, fornecendo uma definição da função correta para o
linha de base. Esses testes acumulados podem ser executados usando um comando "aegis -REGression",
para verificar se o projeto não “regredirá” como resultado de uma mudança.

Linha de Base Testes
As correções de bugs são necessárias para seus testes falhar contra a linha de base do projeto (em contraste
para o diretório de desenvolvimento). Isso garante que o teste realmente demonstre o bug
na linha de base, bem como demonstrar que é corrigido pela mudança. Novo
funcionalidade falha trivialmente em relação à linha de base e, portanto, aegis não tenta
adivinhe se um teste é um teste de correção de bug ou um novo teste de funcionalidade, ele simplesmente requer testes para
falhar em relação à linha de base.

Este requisito se aplica a novos testes sendo criados por uma mudança e também a testes
que foram copiados em uma mudança para modificação.

Revendo Testes
Os revisores podem estar confiantes de que aegis cumpriu os requisitos de teste; que uma mudança
deve haver testes, que a mudança deve ser construída, que os testes passam contra o desenvolvimento
diretório e que os testes falham em relação à linha de base. Essas condições são aplicadas
by aede(1) e a mudança não será avançada para o ser Comentários estado até estes
condições sejam atendidas. Os revisores devem, portanto, revisar os testes para perfeição de cobertura de
o código na mudança e insensibilidade às mudanças no ambiente de execução (por exemplo
não é sensível a datas). Os revisores também devem usar “aegis -list change_details” para verificar
que uma mudança tem ou não isenções de teste.

isenções
Várias isenções de teste podem ser concedidas por administradores de projeto, consulte aepa(1) e
aepattr(5) para mais informações. Copiar testes em uma mudança ou adicionar novos testes a um
mudança, pode cancelar essas isenções.

TESTE COMANDO CONFIGURAÇÃO

O comando usado para executar os testes é definido pelo comando_teste campo no projeto
arquivo de configuração (ver aepconf(5) para obter mais informações), o padrão é usar o
Shell Bourne se não estiver definido. O diretório atual será o topo do diretório apropriado
árvore de diretórios. Se os testes exigirem arquivos temporários, eles devem criá-los em / Tmp, Como um
o teste não pode esperar ter permissão de gravação no diretório atual.

Se você quiser usar um mecanismo de teste mais sofisticado, em vez de um simples script de shell,
mas este mecanismo de teste não retorna códigos de resultado adequados para uso com aegis, você poderia
envolva-o em um script de shell que reescreve o status de saída nos valores que aegis espera.
Você também pode obter os mesmos resultados escrevendo um texto mais complexo comando_teste no
projeto configuração arquivo.

Também é possível escrever comandos de teste que são capazes de testar mais de um arquivo em
uma vez. Isso é controlado pelo batch_test_command campo do projeto configuração Arquivo. No
neste caso, a substituição $ {output} indica o nome de um arquivo que o comando de teste deve
criar, em teste(5) formato, para conter os resultados dos testes executados. Isso é freqüentemente usado
em sistemas com várias CPUs ou a capacidade de distribuir trabalhos em vários computadores
em uma rede.

substituições
Todo o aesub(5) substituições estão disponíveis nos comandos de teste. Alguns deles são
de particular atenção:

Arquitetura
Essa substituição é substituída pelo nome da arquitetura a ser testada.

Caminho_pesquisa
Esta substituição é substituída por uma lista separada por dois pontos de caminhos absolutos para
pesquisa ao procurar arquivos de suporte de teste.

Caminho_de_pesquisa_Executável
Esta substituição é substituída por uma lista separada por dois pontos de caminhos absolutos para
pesquisa ao procurar arquivos de suporte executáveis ​​(arquivos de biblioteca e sub-
comandos).

A maior parte do tempo $ Search_Path_Executable são exatamente os mesmos. No entanto, durante “aegis -t
-bl ”eles serão diferentes, com $ Seach_Path começando no diretório de desenvolvimento (o
teste sendo executado) e $ Seach_Path_Executable começando na linha de base (o executável sendo
corre).

Test Resultado códigos
À medida que cada teste é executado (por meio do comando_teste campo no projeto configuração arquivo), aegis
determina se o teste foi bem-sucedido ou falhou observando seu status de saída. Esta saída
o status é principalmente o esperado para comandos UNIX.

RESULTADOS
Um teste deve sair de 0 para indicar sucesso, ou seja, que a função específica em teste
funcionou conforme o esperado.

Falha
Um teste deve sair 1 para indicar falha, ou seja, que a função específica em teste
não funcionou como esperado.

Nenhum Resultado
Um teste deve sair 2 para indicar nenhum resultado, ou seja que a função específica sob
o teste não pôde ser executado porque algo deu errado. Por exemplo, correr
sem espaço em disco ao criar os arquivos de entrada de teste no / Tmp diretório.

Pulado
Um teste deve sair de 77 para indicar que foi ignorado. Isso geralmente tem a ver com
a arquitetura atual não é significativa. Sempre que possível, use “Sem resultado”
em vez de. (O valor foi escolhido para compatibilidade com outros sistemas de teste.)

Na verdade, qualquer código de saída diferente de 0, 1 ou 77 será interpretado como “sem resultado”.
No entanto, sempre usando 0, 1, 2 ou 77 significa que se um novo código de resultado for exigido por um
versão posterior do Aegis, seus testes existentes continuarão a funcionar.

TESTE CORRELAÇÕES

O comando “aegis -Test -SUGgest” pode ser usado para que a égide sugira uma regressão adequada
testa sua alteração, com base nos arquivos de origem em sua alteração. Isso automaticamente
concentra o esforço de teste em testes relevantes, reduzindo o número de testes de regressão
necessário ter certeza de que você não introduziu um bug.

As correlações de teste são geradas pelo comando “aegis -Integrate_Pass”, que
associa cada teste na mudança a cada arquivo de origem na mudança. Assim, cada
o arquivo de origem acumula uma lista de testes que foram associados a ele no passado.
Isso não é tão exato quanto a análise de cobertura de código, mas é uma aproximação razoável em
prática.

A aecp(1) e aenf(1) comandos são usados ​​para associar arquivos a uma mudança. Enquanto eles
não realizam ativamente a associação, estes são os arquivos usados ​​por aeipass(1) e
aet(1) para determinar quais arquivos de origem estão associados a quais testes.

Test Correlação Precisão
Supondo que as correlações de teste sejam precisas e que os testes sejam uniformemente
distribuído por todo o espaço de função, haverá menos de 1 / número chance de que um
o teste relevante não foi executado pelo “aegis -Test -SUGgest número”Comando. Um pequeno
quantidade de ruído é adicionada à ponderação de teste, de modo que coisas inesperadas às vezes são
testado e os mesmos testes não são executados todas as vezes.

A precisão da correlação de teste pode ser melhorada garantindo que:

· Cada mudança deve ser fortemente focada, sem inclusões gratuitas de arquivos. Esse
evita correlações espúrias.

· Cada item de nova funcionalidade deve ser adicionado em uma mudança individual, ao invés de
vários juntos. Isso correlaciona fortemente os testes com a funcionalidade.

· Cada bug deve ser corrigido em uma mudança individual, ao invés de várias juntas. Esse
correlaciona fortemente os testes com a funcionalidade.

· As correlações de teste serão perdidas se os arquivos forem movidos. Isso ocorre porque as correlações são por
nome.

A melhor maneira para os testes se correlacionarem com precisão com os arquivos de origem é quando uma mudança
contém um teste e exatamente os arquivos relacionados à funcionalidade em teste. Também
muitos arquivos espúrios enfraquecerão a utilidade das correlações de teste.

OPÇÕES

As seguintes opções são compreendidas:

-Automático
Esta opção pode ser usada para especificar testes automáticos. Os testes automáticos não exigem
assistência humana.

-Linha de base
Esta opção pode ser usada para especificar que a linha de base do projeto é o assunto de
o comando.

-BAse_RElativo
Esta opção pode ser usada para fazer com que nomes de arquivos relativos sejam considerados relativos a
a base da árvore de origem. Ver Aeuconf(5) para o usuário correspondente
preferência.

-CUrrent_RElative
Esta opção pode ser usada para fazer com que nomes de arquivos relativos sejam considerados relativos a
o diretório atual. Normalmente, este é o padrão. Ver Aeuconf(5) para o
preferência do usuário correspondente.

-Mudar número
Esta opção pode ser usada para especificar uma mudança particular dentro de um projeto. Ver
Aegis(1) para uma descrição completa desta opção.

-Força Esta opção pode ser usada para especificar que todos os testes devem ser executados, mesmo se o
o status da última execução de teste indica que não há necessidade de executar um
teste.

-Ajuda
Esta opção pode ser usada para obter mais informações sobre como usar o Aegis
.

-Independente
Esta opção é usada para especificar que o teste deve ser executado independentemente de qualquer
mudança particular. Se nenhum teste for nomeado, todos os testes da linha de base serão executados.

-Lista
Esta opção pode ser usada para obter uma lista de assuntos adequados para este comando.
A lista pode ser mais geral do que o esperado.

-Manual Esta opção pode ser usada para especificar testes manuais. Os testes manuais requerem algum humano
intervenção, por exemplo: confirmação de algum comportamento da tela (X11, por exemplo), ou
alguma ação do usuário, "desconecte o cabo Ethernet agora".

-Not_Logging
Esta opção pode ser usada para desativar o registro automático de saída e erros para
um arquivo. Isso geralmente é útil quando vários comandos aegis são combinados em um shell
script.

-Perseverar
Esta opção pode ser usada para especificar que todos os testes devem ser executados, mesmo se alguns
falhou. Padrões para o usuário perseverar_preferência se não for especificado, veja
Aeuconf(5) para mais informações.

-No_PErevere
Esta opção pode ser usada para especificar que a execução do teste deve parar após o primeiro
fracasso. Padrões para o usuário perseverar_preferência se não for especificado, veja
Aeuconf(5) para mais informações.

-Projeto nome
Esta opção pode ser usada para selecionar o projeto de interesse. Quando não -Projeto
opção é especificada, o AEGIS_PROJECT variável de ambiente é consultada. Se
que não existe, o usuário $ HOME / .aegisrc arquivo é examinado para um padrão
campo do projeto (ver Aeuconf(5) para mais informações). Se isso não existe,
quando o usuário está trabalhando apenas nas mudanças dentro de um único projeto, o projeto
nome padrão para esse projeto. Caso contrário, é um erro.

-Progresso
Esta opção pode ser usada para especificar que as mensagens de progresso devem ser emitidas antes
cada teste executado ou antes de cada teste em lote, caso batch_test_command campo
especificado no projeto configuração arquivo (ver Aeuconf(5) para mais informações).

-No_PROGress
Esta opção pode ser usada para especificar que as mensagens de progresso devem ser suprimidas.
Este é o padrão.

-Regressão
Esta opção é usada para especificar que o conjunto de testes de regressão deve ser executado. o
suíte de teste de regressão consiste em todos os testes na linha de base que não aparecem
na mudança. É um erro se não houver testes de regressão. Talvez você não
testes de nome na linha de comando ao usar a opção -REGression. Você pode nomear
testes individuais a serem executados na linha de comando, sem usar o -REGression
opção; se não fizerem parte da mudança, os testes de mesmo nome no
a linha de base será executada.

-SUGERIR [ número ]
A "Aegis -Integrar_Pass”Comando coleta estatísticas de correlação de teste quando
as mudanças são integradas. Esta opção pode ser usada para solicitar que aegis sugira
quais testes devem ser executados, usando essas correlações de teste. Se nenhum número for
especificado, 10 testes serão sugeridos. Esta opção implica o -Regressão
opção.

-SUGgest_Limit minutos
Esta opção pode ser usada para limitar o número de testes a um certo número de
minutos. Eles serão executados do mais relevante para o menos relevante.

-SUGgest_Noise número
Esta opção pode ser usada para controlar a quantidade de ruído injetado no teste
seleção realizada pelo -SUGERIR opção. O número é uma porcentagem do ruído
para ser injetado. O padrão é 10 se não for especificado. A injeção de ruído garante
que uma variedade de testes são executados em execuções subsequentes, e também alguns do campo esquerdo
como uma verificação de sanidade.

-TERse
Esta opção pode ser usada para fazer com que as listagens produzam o mínimo de
em formação. Geralmente é útil para scripts de shell.

-Detalhado
Esta opção pode ser usada para fazer com que aegis produza mais saída. Por padrão égide
só produz saída em caso de erros. Quando usado com o -Lista escolha esta opção
faz com que os cabeçalhos das colunas sejam adicionados.

-Espere Esta opção pode ser usada para exigir que os comandos Aegis esperem pelos bloqueios de acesso, se
eles não podem ser obtidos imediatamente. Padrões para o usuário lock_wait_preference
se não for especificado, veja Aeuconf(5) para mais informações.

-Não_Espere
Esta opção pode ser usada para exigir que os comandos Aegis emitam um erro fatal se o acesso
os bloqueios não podem ser obtidos imediatamente. Padrões para o usuário
lock_wait_preference se não for especificado, veja Aeuconf(5) para mais informações.

Veja também Aegis(1) para opções comuns a todos os comandos aegis.

Todas as opções podem ser abreviadas; a abreviatura é documentada em letras maiúsculas,
todas as letras minúsculas e sublinhados (_) são opcionais. Você deve usar consecutivos
sequências de letras opcionais.

Todas as opções não diferenciam maiúsculas de minúsculas, você pode digitá-las em maiúsculas ou minúsculas ou um
combinação de ambos, o caso não é importante.

Por exemplo: os argumentos "-project," -PROJ "e" -p "são todos interpretados como significando o
-Projeto opção. O argumento "-prj" não será compreendido, pois consecutivo
caracteres opcionais não foram fornecidos.

As opções e outros argumentos da linha de comando podem ser misturados arbitrariamente na linha de comando,
após os seletores de função.

Os nomes de opção longos GNU são compreendidos. Uma vez que todos os nomes de opções para Aegis são longos,
isso significa ignorar o inicial extra '-'. O "--opção=valor"convenção também é
Entendido.

RECOMENDADO ALIAS

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

ERROS

É um erro se a mudança não estiver em um dos ser desenvolvido or ser integrado
estados.
É um erro se a mudança não for atribuída ao usuário atual.
É um erro se você não tiver testes relevantes e nenhuma isenção relevante.

SAIR STATUS

A Aegis o comando sairá com um status de 1 em qualquer erro. o Aegis comando vai apenas
saia com um status de 0 se não houver erros.

MEIO AMBIENTE VARIÁVEIS

See Aegis(1) para uma lista de variáveis ​​de ambiente que podem afetar este comando. Ver
aepconf(5) para o arquivo de configuração do projeto projeto_específico campo para saber como definir
variáveis ​​de ambiente para todos os comandos executados pelo Aegis.

Use aet online usando serviços onworks.net