AltaVista
Google

Capítulo 26. Testes de regressão

Sumário
26.1. Execução dos testes
26.2. Avaliação dos testes
26.2.1. Diferenças nas mensagens de erro
26.2.2. Diferenças no idioma
26.2.3. Diferenças na data e hora
26.2.4. Diferenças no ponto flutuante
26.2.5. Diferenças na ordem das linhas
26.2.6. O teste "random"
26.3. Arquivos de comparação específicos de plataformas

Os testes de regressão compõem um conjunto detalhado de testes da implementação da linguagem SQL no PostgreSQL. São testadas as operações SQL padrão, assim como as funcionalidades estendidas do PostgreSQL.

26.1. Execução dos testes

Os testes de regressão podem ser executados em um servidor já instalado e em funcionamento, ou utilizando uma instalação temporária dentro da árvore de construção. Além disso, existem os modos "paralelo" e "seqüencial" para execução dos testes. O modo seqüencial executa cada um dos scripts de teste por vez, enquanto o modo paralelo inicia vários processos servidor para executar grupos de teste em paralelo. Os testes em paralelo dão a confiança de que a comunicação entre processos e os bloqueios estão funcionando de forma correta. Por motivos históricos, os testes seqüenciais são geralmente executados em uma instalação existente, e o modo paralelo em uma instalação temporária, mas não há motivo técnico para ser feito assim.

Para executar os testes de regressão após construir, mas antes de instalar, deve ser digitado

gmake check

no diretório de nível mais alto (Ou o diretório src/test/regress pode ser tornado o diretório corrente e o comando executado neste diretório). Primeiro serão construídos vários arquivos auxiliares, como algumas funções de gatilho de exemplo definidas pelo usuário e, depois, executado o script condutor do teste. Ao final deve ser visto algo parecido com

======================
 All 96 tests passed.
======================

ou, senão, uma nota sobre quais testes falharam. Deve ser vista a Seção 26.2 abaixo antes de assumir que "failure" representa um problema sério.

Uma vez que este método executa um servidor temporário, não funciona quando se está logado como o usuário root (uma vez que o servidor não inicializa sob o root). Se foi feita a construção como root, não será necessário começar tudo novamente. Em vez disto, deve ser feito com que o diretório do teste de regressão possa ser escrito por algum outro usuário, se conectar como este usuário, e recomeçar os testes. Por exemplo:

root# chmod -R a+w src/test/regress
root# chmod -R a+w contrib/spi
root# su - joeuser
joeuser$ cd diretório_de_construção_de_nível_mais_alto
joeuser$ gmake check

(O único "risco de segurança" possível neste caso é a possibilidade de outro usuário alterar os resultados do teste de regressão sem que se saiba. Use o bom senso ao gerenciar permissões para usuários).

Como alternativa, os testes podem ser executados após a instalação.

Se o PostgreSQL for configurado para ser instalado em um local onde existe uma instalação mais antiga do PostgreSQL, e for executado gmake check antes de instalar a nova versão, pode ser que os testes falhem devido aos novos programas tentarem utilizar as bibliotecas compartilhadas já instaladas (O sintoma típico é a reclamação sobre símbolos não definidos). Se for desejado executar os testes antes de sobrescrever a instalação antiga, será necessário fazer a construção utilizando configure --disable-rpath. Entretanto, não se recomenda que esta opção seja utilizada na instalação final.

O teste de regressão paralelo inicia alguns processos sob o ID do usuário. Atualmente, a simultaneidade máxima são vinte scripts de teste em paralelo, o que significa sessenta processos: para cada script de teste existe um processo servidor, o psql e, geralmente, o processo ancestral do interpretador de comandos que chamou o psql. Portanto, se o sistema impõe limite para o número de processos por usuário, certifique-se que este limite é de setenta e cinco ou mais, senão podem acontecer falhas aleatórias no teste paralelo. Se não houver condição de aumentar este limite, pode ser diminuído o grau de paralelismo definindo o parâmetro MAX_CONNECTIONS. Por exemplo,

gmake MAX_CONNECTIONS=10 check

não executa mais de dez testes ao mesmo tempo.

Em alguns sistemas o interpretador de comandos padrão compatível com o Bourne (/bin/sh) se confunde ao gerenciar tantos processos descendentes em paralelo, podendo fazer com que o teste paralelo trave ou falhe. Neste caso, deve ser especificado na linha de comandos um interpretador de comandos compatível com o Bourne diferente como, por exemplo:

gmake SHELL=/bin/ksh check

Se não estiver disponível nenhum interpretador de comandos que não apresente este problema, então este problema poderá ser contornado limitando o número de conexões, conforme mostrado acima.

Para executar os testes após a instalação (consulte o Capítulo 14), deve ser inicializada a área de dados e ativado o servidor e depois, conforme explicado no Capítulo 16, deve ser digitado:

gmake installcheck

ou para o teste em paralelo

gmake installcheck-parallel

Os testes esperam fazer contato com o servidor no hospedeiro local no número de porta padrão, a menos que esteja especificado o contrário nas variáveis de ambiente PGHOST e PGPORT.

SourceForge.net Logo CSS válido!