Traduzido do Inglês para o Português - www.onlinedoctranslator.

com

Manual do usuário

TestLink versão 1.9

Versão: 1,18
Status: Atualizado para TL 1.9

© 2004 - 2010 Comunidade TestLink

É concedida permissão para copiar, distribuir e/ou modificar este documento sob os termos da GNU Free
Documentation License, Versão 1.2 publicada pela Free Software Foundation; sem Seções Invariantes, sem Textos de
Capa Frontal e sem Textos de Contracapa. A licença está disponível em Página inicial da "Licença de Documentação
Livre GNU".
 Histórico de Revisão

Encontr
# Descrição o Autor

0.x Documentos para TL 1.5 e atualização para TL 1.6 2005 M. Havlát

A. Morsing
F. Mancardi

1,0 Convertido para o formato OO2; 2005/03/12 M. Havlát

1.1 Pequena atualização; CORREÇÃO 372, 352 14/02/2006 M. Havlát

1.2 Atualizado como rascunho para TL 1.7 17/11/2006 M. Havlát

1.3 Termos de TL 1.6 removidos 01/03/2007 F. Mancardi

Adicionadas informações iniciais sobre campos personalizados
Adicionado conteúdo e atualizado o “jumpstart_manual” de Francisco
1,4 e 06/09/2007 M. Havlát
tl_file_format.
Limpeza e atualização geral do estilo.

1,5 Atualização e reestruturação geral; adicionado o capítulo Test Suite; 17/12/2007 M. Havlát
relatório de requisitos

1,6 Revisão geral do idioma 24/01/2008 W. Pollans

Pequena atualização; Adicionada seção Importar casos de teste do
1,7 Excel via XML 02/02/2008 M. Havlat
(preparado por Prem)

1,8 Atualização para o rascunho do TL 1.8 16/04/2008 M. Havlat

1,9 Atualize alguns novos recursos 21/07/2008 M. Havlát

18/08/2008

1.10 Atualização para 1.8 RC3 15/01/09 M. Havlát

1.11 Atualização para 1.8 RC5 15/02/09 M. Havlát

1.12 Atualização para 1.8.0; Importar/Exportar 15/03/09 M. Havlát

1.13 Atualizar de acordo com os problemas 04/01/09 M. Havlát

1,14 Atualizar de acordo com os problemas (TL 1.8.2) 30/04/09 M. Havlát

Capítulo atualizado “Campos personalizados: tempo de execução
1,15 estimado e real” 05/06/09 M. Havlát
por qvii
Números de página adicionados

1,16 Pequenas atualizações de acordo com o feedback do usuário 23/06/09 M. Havlát

09/12/09

1,17 Atualização para 1.9; Plataformas; Inventário 01/08/10 M. Havlat

Importação/Exportação removida, pois esta informação é duplicada
1,18 em 04/03/10 M. Havlat
documento
-2-
Índice
1 Informação geral 5
1.1 Estrutura geral 5
1.2 Terminologia Básica 5
1.3 Exemplo de fluxo de trabalho simples do TestLink 6
1,4 Atalhos 7
2 Projetos de teste 9
2.1 Criando novos projetos de teste 9
2.2 Editar e excluir projetos de teste 9
2.3 Inventário 10
3 Especificação do teste 12
3.1 Conjuntos de teste 12
3.2 Casos de teste 13
3.3 Palavras-chave 16
3.4 Gerar documento de especificação de teste 17
4 Teste baseado em requisitos 18
4.1 Disponibilidade 18
4.2 Documento de Especificação de Requisitos 18
4.3 Requisitos 19
5 Planos de teste 21
5.1 Criar e excluir plano de teste 21
5.2 Construções 21
Conjunto de Testes - adicionando Casos de Teste ao Plano de
5.3 Teste 22
5.4 Removendo casos de teste do conjunto de testes 23
5,5 Atribuição de execução de teste 24
5.6 Plataformas 29
5.7 Priorizar testes 33
5,8 Milestones 34
6 Execução de teste 36
6.1 Em geral 36
6.2 Navegação e configurações 36
6.3 Execução do teste 37
7 Relatórios de teste e métricas 40
7.1 Métricas gerais do plano de teste 40
7.2 Métricas de consulta 41
Relatórios de casos de teste bloqueados, com falha e não
7.3 executados 44
7.4 Relatório de teste 44
7,5 Gráficos 44
7.6 Total de bugs para cada caso de teste 45
7,7 Relatório baseado em requisitos 45
7,8 Como adicionar um novo relatório 45
8 Administração 46
8.1 Configurações da conta do usuário 46
8.2 Permissões de função 46
8.3 Atribuição do plano de teste aos usuários 47
8.4 Os campos personalizados 47
9 Importar e exportar dados 54

-3-
 1 Informações gerais

TestLink é um sistema de gerenciamento de testes baseado na web. Este manual deve servir
como fonte para os usuários entenderem os processos, termos e organização do trabalho com
o TestLink. Consulte o manual de instalação para obter mais informações sobre os requisitos
do sistema, etapas de instalação e configuração. A documentação mais recente está disponível
em www.teamst.org ou testlink.sourceforge.net.
Por favor, use nosso fórum se você tiver dúvidas que o manual não responde.
O código do TestLink geralmente é mais rápido do que a documentação e algumas
contribuições perderam a descrição apropriada. Alguns aprimoramentos não são
descritos por esse motivo aqui. Obrigado por nos avisar via rastreador.

1.1 Estrutura geral

Existem três pilares: Projeto de Teste, Plano de Teste e Usuário. Todos os outros dados são
relações ou atributos desta base. Primeiro, vamos definir termos que são usados em todo o
mundo da documentação e dos testes.

Ilustração 1: Projeto de teste é o componente básico do TestLink

1.2 Terminologia Básica

Caso de testedescreve uma tarefa de teste por meio de etapas (ações, cenário) e resultados
esperados. Os casos de teste são a peça fundamental do TestLink.

-4-
Suíte de teste(Test Case Suite) organiza os casos de teste em unidades. Ele estrutura a
Especificação de Teste em partes lógicas.
O Test Suite substitui os componentes e categorias no TL 1.6 e anteriores.
Plano de testeé criado quando você deseja executar casos de teste. Os Planos de Teste
podem ser compostos dos Casos de Teste do Projeto de Teste atual. O Plano de Teste inclui
Builds, Marcos, atribuição de usuário e Resultados de Teste.
Projeto de testeé algo que existirá para sempre no TestLink. O Projeto de Teste passará por
muitas versões diferentes ao longo de sua vida útil. O Projeto de Teste inclui Especificação de
Teste com Casos de Teste, Requisitos e Palavras-chave. Os usuários dentro do projeto têm
funções definidas.
Projeto de teste foi chamado de Produto no TL 1.6 e anteriores.
Do utilizador: cada usuário do TestLink tem uma função que define os recursos disponíveis
do TestLink. Veja mais no capítulo “Administração de Usuários”. Ilustração2 mostra atividades
comuns de acordo com as funções do usuário.

1.3 Exemplo de fluxo de trabalho simples do TestLink

1. Administrador cria um Projeto de Teste “Fast Food” e dois usuários, Adam com direitos
“Leader” e Bela com direitos “Senior Tester”.
2. O Líder Adam importa os Requisitos de Software e para parte desses requisitos gera
Casos de Teste vazios. Ele os reorganizou em duas suítes de teste: “Fish” e “Chips”.
3. O testador Bela descreve um cenário de teste (criar um conteúdo de casos de teste
vazios) usando essas especificações de teste que são organizadas em suítes de teste.
4. Adam cria a palavra-chave “Teste de regressão” e atribui essa palavra-chave a dez
desses casos de teste.
5. Adam cria um Plano de Teste “Fish & Chips 1”, Build “Fish 0.1” e vincula todos os Casos
de Teste no Conjunto de Testes “Fish” a este Plano de Teste. Ele atribui a si mesmo e a
Bela como recursos para este Plano de Teste também.
6. Agora os desenvolvedores produzem uma primeira compilação. Adam e Bela executam
e registram o teste com o resultado: 5 passaram, 1 falhou e 4 estão bloqueados.
7. Os desenvolvedores fazem uma nova Build “Fish 0.2” e Bela testa apenas os casos de
teste com falha e bloqueados. Desta vez, todos os casos de teste bloqueados e com
falha foram aprovados. Eles também testam novamente todos os Casos de Teste com
as palavras-chave “Teste de regressão”.
8. Um gerente desta equipe gostaria de ver os resultados. O administrador explica a ele
que ele mesmo pode criar uma conta na página de login. Gerente faz isso. Ele tem
direitos padrão de “Convidado” e pode ver Resultados de Testes e Casos de Teste. Ele
pode ver que tudo passou no relatório geral ;-) e problemas no Build “Fish 0.1” em um
relatório para aquele Build específico.1
9. Mais tarde, os desenvolvedores finalmente adicionam também a funcionalidade “Chips”.
Adam cria um Plano de Teste “Peixe
& Fichas 2”. Ele pode reutilizar o primeiro Plano de Teste como modelo. Todos os casos
de teste e funções “Fish” serão adicionados automaticamente. Ele cria um novo Build
“Fish 1.1” e vincula todos os Casos de Teste de “Chips” a este Plano de Teste também.
10. Agora os testes começam normalmente.
11. Mais tarde, o Admin cria um novo Projeto de Teste para outro produto “Hot Dog”. Mas
esta é outra equipe de teste e uma história diferente.

1 Ele, no entanto, não pode editar nada. ;-)

-5-
Ilustração 2: Visão geral da funcionalidade

1.4 Atalhos

TestLink tem atalhos para acelerar uma navegação. Use ALT (+ shift) + tecla. 2
Liste os atalhos globais disponíveis:
• [h] Início
• [s] Especificação de teste
• [e] Execução de teste
• [r] Relatórios
• [i] Pessoal
• [q] Sair/sair
• [u] Administração (somente administrador)
O atalho Criar Caso de Teste [t] está disponível na página Visualizar Conjunto de Testes.
Suporte ao navegador: O atributo accesskey usado é atualmente suportado pelos
seguintes

2 O IE seleciona apenas o link. A tecla Enter deve seguir.

-6-
 navegadores da web:
• Raposa de fogo
• Internet Explorer 4+ (Windows) 5+ (Mac)
• Mozila (Windows + Linux)
• Netscape 6.1+ (Windows)
• Opera 7+ (Windows + Linux)

Atalhos do editor FCK

Os próximos atalhos são suportados no modo de edição de texto:

Atalho Açao

Ctrl+A Selecionar tudo

Ctrl + C, Ctrl + Ins Copiar para área de transferência

Ctrl + V, Shift + Ins Colar da área de transferência

Ctrl + X, Shift + Del Cortar

Ctrl+Z Desfazer

Ctrl + Y Refazer

Ctrl+K Inserir link

Ctrl+W Inserir Link sem popup da caixa de diálogo

Ctrl+B Negrito

Ctrl + eu itálico

Ctrl+U Sublinhado

Ctrl + Shift + S Salve 

Ctrl + Alt + Enter Ajustar janela

Ctrl + L Justificar à esquerda

Ctrl+R Justifique direito

Ctrl+E Justificar Centro

Ctrl + J Justificar bloqueio

Ctrl + [1-5] Formato do cabeçalho 1-5

Ctrl + 0, Ctrl + N Formato do parágrafo

Ctrl + Shift + L Alterna entre lista com marcadores, lista numerada e parágrafo

Aumenta e diminui (com Shift) Recuo. Se o cursor estiver dentro do texto e

FCKConfig.DekiTabSpaces > 0, insere os espaços. Dentro das tabelas o cursor salta
para
Tab, Shift + Tab
a célula seguinte/anterior ou insere a nova linha se não houver próxima célula. Se
o cursor estiver em
título ou cabeçalho, pule para o próximo parágrafo.

Shift + Espaço Espaço ininterrupto ( )

-7-
 2 Projetos de Teste

Projetos de teste são a unidade organizacional básica do TestLink. Projetos de teste podem ser
produtos ou soluções de sua empresa que podem alterar seus recursos e funcionalidades ao
longo do tempo, mas na maioria das vezes permanecem os mesmos. O Projeto de Teste inclui
documentação de requisitos, Especificação de Teste, Planos de Teste e direitos de usuário
específicos.
Os projetos de teste são independentes e não compartilham dados. Considere usar apenas um
projeto de teste para uma equipe de teste e/ou um produto.
Por exemplo: há duas equipes de teste para um produto: teste de sistema e teste de
integração. Essas equipes compartilharão alguns casos de teste. Você deve criar um
projeto para o produto. O trabalho de ambas as equipes será estruturado em duas ou
mais árvores na Especificação de Teste e os resultados dos testes serão coletados para
diferentes Planos de Teste.

2.1 Criando novos projetos de teste

A criação de um novo projeto de teste requer direitos de "admin". Selecione o link “Test
Project Management” na página principal e pressione o botão “Create”.
Cada projeto de teste deve ter um nome exclusivo. Há área de texto para caracterizar o
objeto de projeto. Existem vários recursos que são ativados/desativados no nível do projeto
de teste:
1. O administrador pode habilitar a funcionalidade relacionada aos requisitos.
2. As cores de fundo podem ser atribuídas aos modelos de projeto de teste para
distingui-los visualmente.
Nota: O recurso deve ser ativado na configuração primeiro.
3. Priorização de teste pode ser habilitado para selecionar o conjunto de testes
apropriado em tempo limitado.
4. Automação de testes o suporte também pode ser ativado.

Coisas a serem observadas ao criar um novo projeto de teste:

• A exclusão de projetos de teste do sistema não é recomendada, pois isso torna
órfãos um grande número de casos de teste ou exclui os casos de teste do sistema.
• Os Planos de Teste representam o teste de um Projeto de Teste em um
determinado momento. Consequentemente, os Planos de Teste são criados a
partir dos Casos de Teste do Projeto de Teste. Não recomendamos criar
Projetos de Teste separados para versões de um Produto.
• O TestLink suporta a importação de dados XML ou CSV para um Projeto de Teste.
Isso é explicado mais detalhadamente na seção Importação, abaixo.

2.2 Editar e excluir projetos de teste

A edição de projetos de teste requer direitos de "admin". O usuário pode alterar o nome
do projeto de teste, cor de fundo e disponibilidade de funcionalidade de requisitos,
priorização de teste e automação de teste.
O usuário pode desativar o projeto de teste se estiver obsoleto. Isso significa que o Projeto
de Teste não está visível na lista na barra de navegação superior para usuários comuns.
O administrador verá este projeto de teste na lista marcada por '*'.
O usuário também pode excluir um projeto de teste. Esta ação também excluirá todos os
dados relacionados do banco de dados.
esta ação não é reversível. É altamente recomendável usar inactivate em vez de delete.

-8-
 2.3 Inventário

Os usuários podem listar seu hardware na tabela por projeto. O recurso deve ser habilitado na
página “Editar projeto”. Os líderes podem editar esta página por padrão e os testadores podem
apenas navegar nela.3 O link Inventário está disponível na página Projeto Principal no menu
“Testar Projeto”.

Ilustração 3: Navegação para o Inventário

A página de inventário oferece três ações: criar, atualizar e excluir.

Ilustração 4: Ações na tabela de

inventário A tabela mostra todos os dispositivos e permite a
classificação em qualquer campo.

Ilustração 5: Tabela de inventário com classificação

Selecione o botão “Criar” para definir um dispositivo. Os próximos parâmetros são suportados:
• Nome do host (valor obrigatório exclusivo)
• endereço de IP
• Finalidade (texto simples com no máximo 2.000 caracteres)
• Hardware (texto simples com no máximo 2.000 caracteres)
• Notas (texto simples com no máximo 2.000 caracteres)
• Proprietário (opcional) pode ser qualquer pessoa que tenha pelo menos a capacidade de
visualização

3 O administrador pode modificar os direitos das funções para estender esses direitos.
-9-
 Ilustração 6: Criar um novo dispositivo na tabela de

inventário A ação de atualização e exclusão requer uma linha

selecionada.
-10-
 3 Especificação de Teste

O TestLink divide a estrutura de Especificação de Teste em Conjuntos de Testes e Casos de

Teste. Esses níveis são persistentes em todo o aplicativo. Um projeto de teste tem apenas
uma especificação de teste.
Considerações futuras: planejamos implementar as próximas habilidades: Padrões de
teste, processo de revisão e status do caso de teste, estrutura variável do caso de teste
(por exemplo, design passo a passo).

3.1 Conjuntos de Testes

Os usuários organizam os casos de teste em conjuntos de testes (casos). Cada Conjunto de

Testes consiste em um título, uma descrição formatada de Casos de Teste e possivelmente
outros Conjuntos de Testes. TestLink usa estrutura de árvore para Test Suites. A prática
comum é que a descrição contenha informações válidas para a maioria dos dados incluídos.

Ilustração 7: a especificação de teste é estruturada por conjuntos de teste

Por exemplo, o seguinte pode ser especificado: escopo dos testes incluídos, configuração
padrão, pré-condições, links para documentação relacionada, lista de ferramentas, visão geral
da infraestrutura etc.
Criar um ou mais Conjuntos de Testes é um dos primeiros passos ao criar seu Projeto de
Teste. Os usuários (com direito de edição) podem criar, excluir, copiar, mover, exportar e
importar tanto os conjuntos de testes quanto os casos de teste aninhados. O título e a
descrição também podem ser modificados.
Você pode reordenar os casos de teste e as suítes de teste filho por meio de itens de arrastar
e soltar na árvore de navegação.4
Prática: Considere a estrutura de sua especificação de teste. Você pode dividir os testes
por testes funcionais/não funcionais, recursos específicos, componentes. Você pode
alterar a estrutura mais tarde, é claro – mova os conjuntos de testes sem perder
nenhuma informação.
Prática: Versões posteriores do seu produto podem ter alguns recursos obsoletos. Você
pode criar um conjunto de testes especial 'Obsolete' ou 'Your product 0.1' e mover os
casos de teste para lá. A exclusão do caso de teste faz com que os resultados de teste
anteriores também sejam excluídos.
Anexos com documentos externos ou imagens podem ser adicionados em conjuntos de testes
específicos.
4 Requer o componente EXT-JS (padrão).

-11-
 Nota: A funcionalidade deve ser permitida através da configuração do TestLink.
Mais informações sobre importação e exportação estão no apêndice.
Perguntas frequentes: Posso copiar/mover suítes de teste entre projetos? Você não pode
diretamente nesta versão. Projetamos projetos de teste totalmente independentes uns
dos outros. Use importação/exportação como solução alternativa.

3.2 Casos de Teste

Caso de teste é um conjunto de entradas, pré-condições de execução e resultados esperados

(outcomes) desenvolvidos para um determinado objetivo, como exercer um determinado
caminho de programa ou verificar o cumprimento de um requisito específico.
Os casos de teste têm as seguintes partes:
• Identificadorde um Caso de Teste é atribuído automaticamente pelo TestLink e não pode ser
alterado pelos usuários. Este ID é composto pelo prefixo do Projeto de Teste e um contador
relacionado ao Projeto de Teste no qual o Caso de Teste é criado. 5
• Título: pode incluir uma breve descrição ou abreviação (por exemplo, TL-USER-LOGIN)
• Resumo: deve ser muito curto; apenas para visão geral, introdução e referências.
• Degraus: descreve o cenário de teste (ações de entrada); também pode incluir
informações de pré-condição e limpeza aqui.
FAQ: Nossas etapas de teste são bastante detalhadas e usam muita formatação
vinda do Word. Use o recurso "Colar do msword" do FCKeditor. Ele limpa o lixo.
(Configure a barra de ferramentas se não estiver disponível.)
• Resultados esperados: descrevem os pontos de verificação e o comportamento
esperado de um produto ou sistema testado.
• Anexos: pode ser adicionado se a configuração permitir.
• Importância:O designer de teste pode definir a importância do teste [HIGH, MEDIUM e LOW]. O
valor é usado para calcular a prioridade no Plano de Teste. 6
• Tipo de execução: O designer de teste pode definir o suporte de automação do teste
[MANUAL/AUTOMATADO].6
• Os campos personalizados: O administrador pode definir parâmetros próprios para aprimorar a
descrição ou categorização do Caso de Teste. Ver8.4 para mais.
Campos personalizados grandes (mais de 250 caracteres) não são possíveis. Mas as informações
podem ser adicionadas ao Test Suite pai e referidas por meio de campos personalizados. Por
exemplo, você pode descrever a configuração 'padrão', 'desempenho', 'padrão_2' e fazer
referência via CF a esses rótulos.

Nota: O desenvolvimento está planejado para tornar a estrutura do TC mais flexível no

futuro.

Caso de Teste - Atributo Ativo

Se existirem várias versões de um Caso de Teste, seria útil ter um novo atributo,
Ativo/Inativo, para usar desta forma:
• Toda versão de Caso de Teste é criada ATIVO
• Uma Versão de Caso de Teste Inativo não estará disponível em "Adicionar Casos de
Teste ao Plano de Teste". Isso pode ser útil para designers de teste. Eles podem editar
ou alterar a Versão do Caso de Teste e somente quando decidir que está concluído,
alterar o Status para ATIVO para que fique disponível para ser usado em um Plano de
Teste.
• Uma vez que uma Versão de Caso de Teste tenha sido vinculada a um Plano de Teste e
tenha resultados, ela não pode ser
5TestLink 1.7 e versões anteriores tinham esse ID como um contador global independente
do Projeto de Teste. O TestLink 1.8 ainda usa esse ID exclusivo para chamadas de API.

6 O recurso deve ser ativado no gerenciamento de projetos de teste.

-12-
 ficou INATIVO.

Verificador ortográfico

Você pode usar a capacidade do navegador da web. Firefox tem add-on por exemplo "British
English Dictionary" ou dicionários de quantidade para outros idiomas.
FCKeditor suporta solução própria. Veja seus Guia do desenvolvedor para mais.

Ilustração 8: O que você vê na especificação do Caso de Teste

Ilustração 9: O que você vê ao tentar adicionar Casos de Teste a um Plano de Teste

Como você pode notar, o número próximo ao nome do Projeto de Teste (neste exemplo:
toaster_xl5) é 2, mas o Projeto de Teste tem 3 Casos de Teste. O Caso de Teste TC1 não é
contado porque está inativo.

Removendo casos de teste

Casos de teste e suítes de teste podem ser removidos de um plano de teste por usuários com
permissões de “lead”.
Esta operação pode ser útil ao criar um Plano de Teste pela primeira vez, pois não há
resultados.
No entanto, a remoção de Casos de Teste causará a perda de todos os resultados associados a
eles.
Portanto, é recomendado extremo cuidado ao usar essa funcionalidade.
-13-
 Relação de requisitos

Casos de teste podem estar relacionados a requisitos de software/sistema como n a n. A

funcionalidade “requisitos” deve ser habilitada para um Projeto de Teste. O usuário pode
atribuir Casos de Teste e Requisitos por meio do link “Atribuir Requisitos” na tela principal.

Relação do plano de teste

Casos de teste podem ser atribuídos a planos de teste específicos para execução. O Líder de
Teste usa o link “Adicionar/Remover Casos de Teste” na página principal para selecionar o
conjunto de teste apropriado. A lista de Planos de Teste relacionados está listada na página
Visualizar Caso de Teste sob o título “Uso do Plano de Teste”. Veja a imagem abaixo.

Ilustração 10: A lista de Planos de Teste relacionados está listada na página "Visualizar Caso
de Teste"

Pesquisar casos de teste

Selecione um link “Pesquisar Casos de Teste” na página principal (seção: Especificação de

Teste). O usuário pode usar os próximos itens para compor a consulta necessária:
• Identificador do caso de teste

-14-
 • Versão do caso de teste
• Palavra-chave no título
• Palavra-chave em Resumo, Etapas e/ou Resultados Esperados (Aviso: esta pesquisa
simplesmente analisa textos incluindo tags HTML. Por exemplo, a palavra-chave "olá
palavra" não encontra um texto "<p>olá <b> palavra</b></ p>”).
• Palavra-chave atribuída.
• ID do requisito atribuído.
A lista resultante de inclusões para cada caso de teste: Conjunto(s) de teste parental
relacionado(s) e um link para uma página de caso de teste.

3.3 Palavras-chave

As palavras-chave foram criadas para dar aos usuários outro nível de profundidade ao
categorizar os casos de teste. Palavras-chave são ideais para filtragem. Palavras-chave servem
como um meio de agrupar Casos de Teste com algum atributo dentro de uma Especificação de
Teste. Por exemplo, você pode usá-lo para definir:
• Conjunto de regressão (ou Sanidade para capacidade de filtrar testes obrigatórios)
• Casos de teste revisados (para indicar status formal)
• Solaris (conjunto de casos de teste válidos para uma plataforma)
• Solicitação de alteração 12345 (relacionado a novos recursos em uma versão específica)
• Seu_produto 3.2.1 (relacionado a determinada versão do produto)
Nota: Você também pode usar campos personalizados se precisar de um uso mais
sofisticado.

Criar uma palavra-chave

Neste momento, as palavras-chave só podem ser criadas por usuários com os direitos
mgt_modify_key. Esses direitos são atualmente detidos pela função Leader. Após a criação de
uma palavra-chave ou agrupamento de palavras-chave, os usuários podem atribuí-las a Casos
de Teste.
Cada projeto tem seu próprio conjunto de palavras-chave.

Atribuindo palavras-chave

As palavras-chave podem ser atribuídas aos casos de teste na tela de atribuição de palavras-
chave (em lote) ou por meio do gerenciamento de casos de teste (individualmente).

Filtrar por palavra-chave

Os usuários podem filtrar por palavras-chave em:

• Árvore de navegação da especificação de teste.
• Pesquisar casos de teste na especificação de teste.
• Adicionar casos de teste em um conjunto de testes (plano de teste).
• página “Executar teste”.
Alguns relatórios também fornecem resultados com relação às palavras-chave.
-15-
 3.4 Gerar documento de Especificação de Teste

Os usuários podem gerar a especificação de teste atual como um documento. Use um link da
página principal. Há opções estruturais e possibilidade de selecionar um Conjunto de Testes
necessário ou obter todo o conteúdo.

Ilustração 11: Opções para Teste gerado

Especificação

O usuário pode escolher o formato do documento (HTML, documento de texto do OpenOffice

ou documento msword), TOC, dados do conjunto de testes, resumo do caso de teste, etapas +
resultados esperados e lista de palavras-chave e/ou requisitos relacionados.

-16-
 4 Teste baseado em requisitos

Para provar que um sistema é construído conforme especificado, os testadores usam testes
baseados em requisitos. Para cada requisito, eles projetam um ou mais Casos de Teste. Ao
final da execução do teste, um gerente de teste relata os testes executados e os requisitos
cobertos. Com base nessas informações, o cliente e os diversos stakeholders decidem se um
sistema pode ser transferido para a próxima fase de teste ou se pode entrar em operação. Os
gerentes de teste usam uma combinação de testes baseados em riscos e requisitos para
garantir que um sistema seja construído conforme especificado da perspectiva do cliente e das
partes interessadas. Como resultado, este teste completo oferece as seguintes vantagens:
• A vinculação de riscos e requisitos revelará requisitos vagos ou ausentes. Isso é
especialmente interessante para riscos com alta prioridade.
• Os testes podem ser focados primeiro nas partes mais importantes de um sistema de
informação: cobrir os riscos com a mais alta prioridade.
• Comunicar-se na mesma linguagem do cliente e das partes interessadas. Isso torna
mais fácil relatar o status do Projeto de Teste. Então, uma decisão mais bem
fundamentada pode ser tomada se investir mais em testes ou assumir o risco.
• Os riscos e sua prioridade facilitam a negociação do Projeto Teste em tempos de
pressão. Quais riscos devem ser cobertos neste Projeto de Teste e quais podem ser
adiados. Testes baseados em riscos e requisitos resultam em um projeto de teste
melhor controlado. A comunicação com o cliente e os stakeholders é melhorada. O
gerente de teste começa a testar os riscos com a prioridade mais alta. O processo é
simplificado e o resultado final é de maior qualidade.

4.1 Disponibilidade

A funcionalidade está disponível no nível do Projeto de Teste. Ou seja, o administrador deve

habilitá-lo para um projeto de teste especificado (link Editar projeto de teste na janela
principal). Caso contrário, os links não serão exibidos.
Existem dois níveis de usuário para este recurso. A maioria das funções pode exibir os
requisitos, mas não modificá-los. Consulte a seção Usuário para obter mais detalhes.

4.2 Documento de Especificação de Requisitos

Os requisitos são agrupados em uma ou mais Especificações de Requisitos de

Sistema/Software/Usuário.

Ilustração 12: Dependências entre objetos relacionados a requisitos

-17-
Ilustração 13: Gerenciar uma Especificação de Requisitos

Crie um documento com Requisitos:

1. Clique em Especificação de Requisitos na janela Principal. A lista de Especificações de
Requisitos é exibida.
2. Pressione o botão Criar para criar um documento.
3. Ajustar Título, Alcance e eventualmente Contagem de casos de teste. O último
parâmetro é usado para estatísticas. Use apenas se você tiver um documento de
requisitos válido, mas nem todos os requisitos estiverem disponíveis no momento no
TestLink. O valor padrão '0' significa que a contagem atual de requisitos em uma
especificação é usada.
4. Pressione o botão Criar para adicionar dados ao banco de dados. Você pode ver o título
do seu novo documento criado na tabela de lista de especificações de requisitos.
5. Clique no título do documento para o próximo trabalho. A janela Especificação do
Requisito é mostrada.
Cada Especificação de Requisito possui estatísticas e relatórios próprios relacionados aos dados
incluídos.
Todas as especificações podem ser impressas usando o botão "Imprimir" na janela "Especificação
de requisitos". O administrador pode definir empresa, direitos autorais e texto confiável por meio de
arquivos de configuração.
Aviso: TestLink 1.8 traz suporte de estrutura de árvore n-profundidade para requisitos
(deve ser habilitado pela configuração). No entanto, alguns recursos relacionados (por
exemplo, importação/exportação, geração de documentos) ainda não são compatíveis
com essas configurações. Esses recursos se comportam como se apenas existissem
requisitos filho diretos e todas as subpastas internas fossem ignoradas.

4.3 Requisitos

Cada requisito tem Título, Escopo (formato html) e Status. O título deve ser único e ter no
máximo. 100 caracteres. Alcance parâmetro é texto em formato HTML. Statuspode ter os
valores VALID ou NOT_TESTABLE. Um requisito NOT_TESTABLE não é contado nas métricas.
Os requisitos podem ser criados/modificados ou excluídos manualmente através da interface
TestLink ou importados como arquivo CSV.
-18-
 Requisitos de importação

O TestLink suporta dois tipos de CSV. O primeiro 'simples' é composto de título e escopo em
cada linha. O segundo 'Export from Doors' tenta detectar o cabeçalho e escolher os campos
corretos. Import compara títulos e tenta resolver conflitos. Existem três maneiras de fazer
isso: atualizar, criar requisitos com o mesmo título e pular a adição dos conflitantes.

Requisitos para relação do Caso de Teste

Os casos de teste estão relacionados com os requisitos de software/sistema de * a *. Ou seja,

você pode atribuir um ou mais Casos de Teste a um Requisito e um ou mais requisitos podem
ser cobertos por um Caso de Teste. O usuário pode atribuir Requisitos a Casos de Teste por
meio do link Atribuir Requisitos na janela Principal.
A cobertura da Especificação de Teste pode ser visualizada pressionando o botão Analisar na
janela Especificação de Requisito.

Relatório baseado em requisitos

Navegue até o menu Relatórios e Métricas. Há um link de relatório baseado em requisitos. Os

requisitos na Especificação de Requisitos e Plano de Testes atuais são analisados para este
relatório. Os resultados mais recentes dos Casos de Teste (disponíveis no Plano de Teste) são
processados para cada requisito. O resultado com a prioridade mais alta é aplicado ao
requisito. As prioridades, da mais alta para a mais baixa, são: Falha, Bloqueado, Não
Executado e Aprovado.
Exemplo de cobertura de requisitos
Um requisito é coberto por três casos de teste. Dois deles estão incluídos no atual
Conjunto de Testes. Um passou e um não foi testado para o Build 1. Agora
Requirement tem resultado geral de Not Run. O segundo caso de teste foi testado com
o Build 2 e aprovado. Então Requisito passou também.

-19-
 5 Planos de Teste

“Um registro do processo de planejamento de teste detalhando o grau de envolvimento

do testador, o ambiente de teste, as técnicas de projeto do Caso de Teste e as técnicas
de medição de teste a serem usadas e a justificativa para sua escolha.”

Planos de testesão a base para a atividade de execução de teste. Um Plano de Teste contém
nome, descrição, coleção de Casos de Teste escolhidos, Builds, Resultados de Teste, marcos,
atribuição do testador e definição de prioridade. Cada Plano de Teste está relacionado ao
Projeto de Teste atual.

5.1 Criar e excluir Plano de Teste

Os Planos de Teste podem ser criados “Gerenciamento do Plano de Testes” página por
a partir dos privilégios do Projeto de usuários com lead Pressione o botão “Criar” e insira os
Teste atual. dados.
A definição do Plano de Teste consiste em título, descrição (formato html) e check-box de
status “Ativo”. A descrição deve incluir as próximas informações com relação aos processos da
empresa:
• Resumo/Escopo
• Recursos a serem testados
• Funcionalidades que não devem ser testadas
• Critérios de teste (para passar no produto testado)
• Ambiente de teste, Infraestrutura
• Ferramentas de teste
• Riscos
• Referências (plano de produto ou solicitação de mudança, documento(s) de qualidade,
etc.)
Os Planos de Teste são compostos de Casos de Teste importados de uma Especificação de
Teste em um ponto específico do tempo. Planos de Teste podem ser criados a partir de outros
Planos de Teste. Isso permite que os usuários criem Planos de Teste a partir de Casos de Teste
que existem em um momento desejado. Isso pode ser necessário ao criar um Plano de Teste
para um patch. Para que um usuário veja um Plano de Teste, ele deve ter os direitos
apropriados. Os direitos podem ser atribuídos (por leads) na seção definir direitos de
usuário/projeto. Isso é importante lembrar quando os usuários dizem que não podem ver o
projeto em que estão trabalhando.
Os Planos de Teste podem ser excluídos por usuários com privilégios de lead. A exclusão de
Planos de Teste exclui permanentemente o Plano de Teste e todos os seus dados
correspondentes, incluindo Casos de Teste (não na Especificação de Teste), resultados, etc.
Isso deve ser reservado apenas para casos especiais. Alternativamente, os Planos de Teste
podem ser desativados na mesma página, o que suprime a exibição nos menus de seleção nas
páginas “principal” e “Executar”.

5.2 Construções

Um usuário com privilégios de lead pode seguir o link “Build management” na página principal.
As compilações são uma versão específica do software. Cada projeto em uma empresa é
provavelmente composto de muitas construções diferentes. No TestLink, a execução é
composta de Builds e Casos de Teste. Se não houver Builds criados para um projeto, a tela de
execução não permitirá a execução. A tela de métricas também ficará completamente em
branco.

-20-
Ilustração 14: Gerenciamento de compilação

Cada Build é identificada por meio do título. Inclui descrição (formato html) e dois estados:
• Ativo/ Inativo – define se o Build está disponível para a funcionalidade TestLink. A
compilação inativa não está listada nas páginas de execução ou de relatórios.
• Aberto / Fechado – define se os resultados do teste podem ser modificados para a
compilação.
As compilações podem ser editadas (através de um link sob o título de uma compilação) e
excluídas (clicando no ícone “bin” apropriado) na tabela de compilações existentes.

5.3 Conjunto de Testes - adicionando Casos de Teste ao Plano de

Teste

O conteúdo do Plano de Teste é definido pela adição de um conjunto de Testes (de Casos de
Teste) da Especificação de Teste. Use um link “Adicionar/Remover Casos de Teste” na página
inicial. Os dados da Especificação de Teste podem ser filtrados por palavras-chave (ajustadas
no painel de navegação). Assim que os dados forem vinculados a um Plano de Teste, eles
serão marcados com uma marca de seleção.

Ilustração 15: Navegação do caso de teste: selecione um

Conjunto de Testes apropriado
-21-
O usuário pode escolher os casos de teste por meio da caixa de seleção e clicar no botão
"Adicionar selecionado" para definir o conjunto de teste. Clique no ícone 'verificar' para
selecionar todos os Casos de Teste em cada Conjunto de Testes. Todos os casos de teste
podem ser adicionados clicando no rótulo no título do conjunto de testes.
A determinada versão do Caso de Teste é atribuída a um Plano de Teste. O usuário pode
atualizar a versão para testes posteriores se o Caso de Teste for atualizado. O conteúdo da
versão do caso de teste executado não pôde ser modificado.
Nota: Existe uma regra básica: Um Plano de Teste tem apenas um conjunto de Casos de
Teste. Assim, você pode adicionar durante o teste mais novos casos de teste. E isso
afeta as métricas de compilações mais antigas. Na maioria dos casos, esta não é uma
diferença importante. Você pode duas possibilidades se você se importa com:
- Crie um novo Plano de Teste para a segunda rodada.
- Use palavras-chave para reconhecer fases de teste em um plano de teste.

Ilustração 16: Quadro para adicionar casos de teste ao plano de teste

O usuário pode reordenar os casos de teste no conjunto de testes. Esta modificação não tem
influência na Especificação de Teste. Modifique os números na coluna “Ordem de execução” e
pressione o botão “Salvar ordem”.

5.4 Removendo Casos de Teste do Conjunto de Testes

Casos de teste e suítes de teste podem ser removidos de um plano de teste por usuários com
permissões de lead na página "Adicionar/remover casos de teste". A remoção de dados pode
ser útil ao criar um Plano de Teste pela primeira vez, pois não há resultados. No entanto, a
remoção de Casos de Teste causará a perda de todos os resultados associados a eles.
Portanto, é recomendado extremo cuidado ao usar essa funcionalidade.
-22-
 Ilustração 17: Quadro para modificar o conteúdo dos casos de teste no Plano de Teste

5.5 Atribuição de execução de teste

Você pode atribuir Caso de Teste para execução a diferentes usuários. A atribuição de
execução de teste afeta a execução e os relatórios. Na tela de execução, os usuários têm a
capacidade de classificar os Casos de Teste executáveis para ver os que foram atribuídos. Nos
relatórios há uma tabela que mostra os Casos de Teste restantes por testador. Se não houver
nenhum testador de Caso de Teste atribuído, o padrão será nenhum. Um Testador também pode
ver as métricas de seus próprios testes executados na página principal se essas métricas estiverem
habilitadas (consulte o manual de instalação).

Navegue na página inicial:

Usando o menu em árvore no quadro esquerdo, você pode escolher um conjunto de testes
completo, que será exibido em detalhes no quadro direito.

-23-
Neste exemplo, clicar em Transporte produzirá:

Para atribuir um caso de teste a um usuário, as seguintes etapas

devem ser seguidas: 1. selecione o caso de teste, usando a caixa
de seleção à esquerda do ID do caso de teste.

-24-
 2. escolha o usuário, usando a caixa de combinação colocada na coluna com o rótulo
'Atribuir a'.
3. Use o botão 'Salvar' para gravar a seleção no banco de dados
Para simplifique essa tarefa quando você precisar atribuir um conjunto de testes inteiro a um
usuário, o recurso de atribuição de usuários em massa foi desenvolvido.
O usuário pode notificar os testadores atribuídos - marque a caixa de seleção "Enviar
notificação por email para o testador".

Atribuição de usuário em massa

A atribuição de usuário em massa não é realmente diferente daquela atribuição normal.

Usando imagens clicáveis, você pode alternar o estado de várias caixas de seleção com um
clique. Na imagem exibida acima, você pode ver a ajuda a seguir, quando você coloca o cursor
sobre a imagem presente à esquerda do nome do conjunto de testes.

Clicar nesta imagem resultará em todos os casos de teste presentes em “Transporte” suíte de
testes e seus conjuntos de testes filhos, sejam selecionados conforme exibido na imagem a
seguir:
-25-
O próximo passo é escolher o usuário, isso será feito usando a seção de atribuição em massa
sob o nome do conjunto de testes. Em seguida, usando o botão 'Do', as caixas de combinação
de todas as caixas de seleção marcadas serão definidas como 'admin'.

-26-
Último passo, para salvar este trabalho é clicar no botão 'Salvar'

Após a atualização da tela, você verá:

-27-
A atribuição em massa também pode ser feita apenas em casos de teste pertencentes a um
conjunto de testes sem afetar os conjuntos de testes filhos.
Como exemplo, se você deseja alterar a atribuição, apenas em casos de teste filhos do
conjunto de testes “HyperSpace”, em vez de usar a imagem à esquerda do nome do conjunto
de testes:

Ilustração 18: Clique na caixa de seleção da suíte

imagem para selecionar todos incluem casos de teste

5.6 Plataformas

Plataformadescreve uma “unidade” na qual os casos de teste podem ser executados.

Por exemplo, uma plataforma pode ser um navegador da Web, sistema operacional, nave
espacial, dispositivo de hardware ou configuração. Um plano de teste pode ter
plataformas associadas que são escolhidas quando um caso de teste é executado.
Um projeto de teste pode ter várias plataformas que precisam ser testadas. Por exemplo, um
site precisa ser testado em diferentes navegadores ou um software precisa ser executado em
diferentes sistemas operacionais ou dispositivos de hardware. TestLink chama esse conceito de
Plataformas. Plataformas são uma forma de conectar Test
-28-
casos em um plano de teste para uma plataforma de software, dispositivo ou configuração
específica.
Para usar o recurso de plataformas, algumas plataformas devem primeiro ser criadas em
“Gerenciamento de plataforma” (acessível na página Projeto). Requer o direito de
“gerenciamento de plataforma” (somente o administrador pode, por padrão). As plataformas
criadas podem ser atribuídas a planos de teste específicos. (Se você ainda não criou um plano
de teste, faça isso primeiro.)

Ilustração 19: Criar plataformas no Platform Management

Selecione um plano de teste e clique em “Adicionar/Remover Plataformas”. Atribua plataformas

a um plano de teste movendo-as para o painel direito e salve.

Ilustração 20: Atribuir plataformas ao plano de teste

Agora os casos de teste podem ser adicionados ao plano de teste. Isso é feito da mesma
forma que o normal, com a exceção de que um caso de teste deve ser verificado uma vez para
cada plataforma em que deve ser executado. Por exemplo: um caso de teste deve ser
executado em ambas as plataformas USS Enterprise e USS Voyager, ele deve ser verificado
para todas essas plataformas. Ver ilustração20 abaixo.
-29-
 Ilustração 21: Adicionar caso de teste ao plano de teste

O próximo passo é designar usuários para executar os casos de teste. Você é livre para
associar usuários como desejar. Uma possibilidade é ter um usuário para executar um caso de
teste em todas as plataformas. Outra maneira é permitir que um usuário execute todos os
casos de teste em uma plataforma ou uma mistura das duas.

Ilustração 22: Atribuir usuários

-30-
Quando várias plataformas são usadas, a etapa de execução do TestLink obtém uma opção de
filtro adicional. Certifique-se de que a seleção de plataforma esteja definida para a plataforma
na qual você executará os casos de teste. Como visto emIlustração 19 a árvore abaixo mostra
apenas os casos de teste para a plataforma selecionada no momento.

Ilustração 23: Filtro na plataforma no navegador de execução

Após a execução os resultados utilizam as métricas da plataforma nos relatórios. Aviso: um

caso de teste vinculado a três plataformas contará como três casos de teste diferentes nos
relatórios. A razão para isso é que ele deve ser executado uma vez por plataforma para
cobertura total de teste e isso se reflete nos resultados.

5.7 Priorize os testes

A prioridade de teste é um recurso opcional. Geralmente, alguns recursos são novos ou o

desenvolvimento pesado foi feito. Deve receber mais atenção. Por outro lado, algumas
funcionalidades ficaram praticamente intocadas na fase de desenvolvimento e apenas os
testes de maior importância fazem sentido para serem executados.
Configuração: Este recurso deve ser permitido no nível do projeto de teste pelo
administrador (link "Gerenciamento do projeto de teste" na página principal).
A prioridade de teste de parâmetro é definida como a combinação de importância do caso de
teste e urgência do conjunto em um plano de teste. A prioridade de teste pode ser usada como
configurações de filtro para execução de teste e também relatada em métricas.
O TestLink oferece aos usuários a Importânciapara casos de teste. Existem três
capacidade de atribuir Baixo, Médio níveis:
(padrão) e Alto. Esta Especificação. valor é ajustável durante um projeto de teste em
Teste
-31-
Urgênciaé o segundo parâmetro que afeta a Prioridade de Teste resultante. A urgência é
definida para um determinado Plano de Teste e não depende da Importância do Teste. Siga o
link “Definir Urgência” no menu Plano de teste (lado direito da página do projeto). Há também
três níveis: Baixo, Médio (padrão) e Alto.
A urgência não é copiada se você copiar um Plano de Teste. Um conjunto diferente de
urgência é esperado.
O TestLink combina esses dois atributos em níveis de prioridade Alta, Média e Baixa. A
prioridade deve ajudar a escolher o conjunto certo de execução para testar em primeiro lugar.
O relatório de teste “Métricas do plano de teste” inclui os resultados priorizados. Marcos
permite definir metas para esses três níveis também.
Exemplo:Um produto servidor-cliente “Tam-tam” possui duas interfaces GUI e web-GUI.
Cada interface de usuário permite o login e, pressione o botão “Bum” e defina a cor de
fundo da interface. Os testadores projetam três Casos de Teste para ambas as interfaces
(cada interface tem seu próprio Conjunto de Testes):
• Login (importância média)
• Ação de vagabundo (alta importância)
• Cor de fundo (baixa importância)
A A versão 1.0 do Tam-tam tem bug na interface web e hot-fix é criado. Os testadores
precisam testar o produto em um tempo realmente curto de entrega. Um gerente decide
testar apenas testes com alta prioridade antes da entrega e outros depois. O plano de
teste para hot-fix é copiado do plano de teste para a versão 1.0. Os testadores têm o
mesmo conjunto de testes, mas o líder de teste define a urgência do teste da suíte de
testes “Web GUI” como alta e “GU do aplicativo” como baixa (porque não há alteração).
Agora, dois testes têm alta prioridade: Login e ação “Bum” via interfaces web. A ação
Bum via GUI do aplicativo recebe prioridade Média (Alta Importância, mas baixa
urgência).

5,8 Marcos

O líder de teste pode definir um marco para determinada data com uma meta de porcentagem
esperada de testes concluídos. Essa meta pode ser definida para três níveis de prioridade caso
a priorização de teste seja permitida.
Consulte o relatório “Métricas do Plano de Testes” para verificar a satisfação dessas metas.
-32-
Ilustração 24: O líder de teste pode definir um ou mais marcos para um Plano de Teste

-33-
 6 Execução de Teste

6.1 Geral

A execução do teste está disponível após:

1. Uma Especificação de Teste é escrita.
2. Um Plano de Teste é criado.
3. Os casos de teste são adicionados ao plano de teste.
4. Pelo menos um Build é criado.
5. Os testadores têm direitos apropriados para execução para trabalhar com este Plano de
Teste.
Selecione o link “Execute” no menu superior ou o link “Execute Tests” na página principal para
navegar até a janela “Test Execution”. O painel esquerdo permite a navegação em Casos de
Teste por meio de um menu em árvore e configuração de configurações e filtros. A janela de
execução mostra informações relevantes e permite adicionar resultados de teste.

6.2 Navegação e configurações

O painel de navegação consiste em uma caixa 'Filtro e configurações' e um menu em árvore

com o Test Case Suite.

Definir uma compilação testada

Os usuários devem especificar um de todos os Builds ativos para adicionar resultados. A

compilação mais recente é definida por padrão. Construa o rótulo do pacote exato especificado
do produto em teste para fins de rastreamento. Cada Caso de Teste pode ser executado mais
vezes por um Build. No entanto, é uma prática comum que apenas uma rodada de teste seja
executada em um Build para um caso de teste.
Builds podem ser criados pelo Test Leader usando a página Create New Build.
-34-
 Pesquisar um caso de teste

Os usuários podem especificar o identificador exato do Caso de Teste para uma navegação
mais rápida.

Filtrando casos de teste

Esta tabela permite que o usuário filtre os Casos de Teste para navegação inteligente antes de
serem executados.
Você deve clicar no botão “Aplicar filtro” para propagar uma nova configuração de filtro.
• Testador: os usuários podem filtrar os casos de teste por seu testador. Há também
uma caixa de seleção para ver o testador escolhido e os casos de teste não atribuídos.
• Palavra-chave: os usuários podem filtrar os casos de teste por palavra-chave. Ver 3.3
Palavras-chave.
• Resultado: os usuários podem filtrar os casos de teste por resultados. Os resultados
são o que aconteceu com esse caso de teste durante uma compilação específica. Casos
de teste podem ser aprovados, reprovados, bloqueados ou não executados.
• Prioridade de teste: Os usuários podem priorizar os casos de teste.

Menu em árvore

O menu em árvore no painel de navegação mostra a lista escolhida de Casos de Teste no Plano
de Teste. Ele permite abrir Caso(s) de Teste apropriado(s) para execução de teste no quadro
correto. As suítes de teste no menu são aprimoradas por uma breve visão geral do status do
teste atrás de um título (contagem de casos de teste, contador aprovado, reprovado,
bloqueado e não executado) colorido pelos resultados.
O menu em árvore pode ser colorido apenas para alguns tipos de componentes de menu
usados. Por padrão, a árvore será classificada pelos resultados para a construção definida que
é escolhido na caixa suspensa.

Exemplo de TC colorido de acordo com o Build:

O usuário seleciona Build 2 na caixa suspensa e não marca a caixa de seleção "mais
atual". Todos os Casos de Teste serão mostrados com seus status do Build 2. Portanto,
se o Caso de Teste 1 for aprovado no Build 2, ele será colorido em verde.
Uma segunda possibilidade é que o menu seja colorido de acordo com o último resultado do
teste.

Exemplo TC colorido de acordo com o resultado mais recente

O usuário seleciona Build 2 na caixa suspensa e desta vez marca a caixa de seleção
"mais atual". Todos os casos de teste serão mostrados com o status mais atual.
Portanto, se o Caso de Teste 1 for aprovado no Build 3, mesmo que o usuário
também tenha selecionado o Build 2, ele será colorido em verde.

6.3 Execução de teste

Status do teste

Execução é o processo de atribuição de um resultado (aprovado, reprovado, bloqueado) a um

Caso de Teste para um Build específico. Um Caso de Teste 'Bloqueado' não é possível testar
por algum motivo (por exemplo, um problema na configuração não permite executar uma
funcionalidade testada).

Inserir resultados de teste

A tela de Resultados do Teste é mostrada clicando em um Conjunto de Testes ou Caso de
Teste apropriado no painel de navegação. O título mostra o Build e o proprietário atuais. A
barra colorida indica o status do Caso de Teste. A caixa amarela inclui o cenário de teste do
Caso de Teste.

-35-
Ilustração 25: Quadro com vários resultados de um Caso de Teste

Ilustração 26: O usuário pode selecionar

imprimir apenas o último resultado

Ilustração 27: O último resultado só pode ser impresso

A indicação de que o Caso de Teste foi atualizado ou excluído na Especificação de teste

não é suportada após a versão 1.5.
Casos de teste atualizados: A versão TL 1.0.4 tem indicação por flag, que está
faltando na versão 1.6. Se os usuários tiverem os direitos adequados, eles podem ir para
o "Atualizar caso de teste modificado"

-36-
página através do link na página principal. Não é necessário que os usuários atualizem
os Casos de Teste se houver uma alteração (versão mais recente ou excluída).

-37-
 7 Relatórios e Métricas de Teste

Os Relatórios e Métricas de Teste são acessados clicando nos links “Resultados” ou “Relatórios
e Métricas de Teste” na página principal. Relatórios e Métricas são baseados no Plano de Teste
selecionado (no menu da caixa de combinação). A página que é exibida para o usuário inclui:
O painel direito será preenchido com instruções sobre como usar os controles e como cada
relatório é produzido.
O painel esquerdo é usado para navegar para cada relatório e controles operacionais que
afetam como os relatórios se comportam e são exibidos. O botão “Imprimir” inicializa a
impressão do painel direito (nenhuma navegação será impressa).
Todos os relatórios de teste (exceto gráficos) podem ser gerados em formato 1 de 3:
1. Normal - o relatório é exibido em uma página da web (html)
2. OpenOffice Writer – chama OO Writer para mostrar um relatório
3. OpenOffice Calc - chama OO Calc para mostrar um relatório baseado em tabela
4. MS Excel – chama o Microsoft Excel para mostrar um relatório baseado em tabela
5. MS Word - chama o microsoft word para mostrar um relatório
6. E-mail HTML – enviar relatório para o endereço de e-mail do usuário
Existem atualmente 11 relatórios separados para escolher, sua finalidade e função são
explicadas abaixo. Atualmente, não há relatórios que compilam resultados em vários Planos de
Teste.

7.1 Métricas Gerais do Plano de Teste

Esta página mostra apenas o status mais atual de um Plano de Teste por conjunto de testes,
proprietário, marco, prioridade e palavra-chave. Além disso, também há métricas básicas para
todas as compilações habilitadas.
O “status mais atual” é determinado pelos casos de teste de construção mais recentes em que
foram executados. Por exemplo, se um Caso de Teste foi executado em vários Builds, apenas
o resultado mais recente é levado em consideração. “Último resultado do teste” é um conceito
usado em muitos relatórios e é determinado da seguinte forma:
1) A ordem em que as compilações são adicionadas a um plano de teste determina qual
compilação é mais recente. Os resultados do Build mais recente terão precedência
sobre os Builds mais antigos. Por exemplo, se você marcar um teste como "reprovado"
no Build 1 e marcá-lo como "aprovado" no Build 2, o resultado mais recente será
"aprovado".
2) Se um Caso de Teste for executado várias vezes no mesmo Build, a execução mais
recente terá precedência. Por exemplo, se o Build 3 for lançado para sua equipe e o
testador 1 o marcar como "aprovado" às 14h e o testador 2 o marcar como "reprovado"
às 15h - ele aparecerá como "reprovado".
3) Casos de teste listados como “não executados” em um Build não são levados em
consideração. Por exemplo, se você marcar um caso como “aprovado” no Build 1 e não
executá-lo no Build 2, seu último resultado será considerado como “aprovado”.

As seguintes tabelas são exibidas:

-38-
 Resultados por suítes de teste de nível superior

Lista os resultados de cada suíte de nível superior. O total de casos com status é
listado: aprovado, reprovado, bloqueado, não executado e percentual concluído. Um Caso de
Teste “concluído” é aquele que foi marcado como aprovado, reprovado ou bloqueado. Os
resultados das suítes de nível superior incluem todas as suítes para crianças.

Resultados por compilação

Lista os resultados da execução para cada Build. Para cada Build, o total de Casos de Teste,
total aprovado, % aprovado, total reprovado, % reprovado, bloqueado, % bloqueado, não
executado e % não executado são exibidos. Caso um Caso de Teste tenha sido executado duas
vezes no mesmo Build, a execução mais recente será considerada.

Resultados por palavra-chave

Lista todas as palavras-chave atribuídas a casos no Plano de Teste atual e os resultados

associados a elas.

Exemplo :

Total de palavras-chave aprovadas falhou Bloqueado Não executado Concluído [%]

P3 1128 346 47 55 680 39,72
P2 585 372 25 31 157 73,16
P1 328 257 6 51 14 95,73

Resultados por proprietário

Lista cada proprietário que possui Casos de Teste atribuídos a eles no Plano de Teste
atual. Os casos de teste que não são atribuídos são contabilizados sob o título “não
atribuídos”.

Exemplo:

Testado Passad Fraca Bloquea Não

r Total o ssado do correr Concluído [%]
Dominika 579 217 34 47 281 51,47
Maomé 246 82 9 2 153 37,80
não atribuído 35 19 0 1 15 57,14
Ken 289 110 1 21 157 45,67
Mallik 430 269 5 18 138 67,91
Todos 227 123 28 13 63 72,25
Mike 24 22 0 0 2 91,67
Alex 272 155 1 36 80 70,59

7.2 Métricas de consulta

Este relatório consiste em uma página de formulário de consulta e uma página de resultados
de consulta que contém os dados consultados.
Página do formulário de consulta:
O usuário é apresentado a uma página de consulta com 4 controles. Cada controle é definido
como um padrão que maximiza o número de casos de teste e compilações em que a consulta
deve ser executada.
-39-
Alterar os controles permite que o usuário filtre os resultados e gere relatórios específicos para
combinações específicas de proprietário, palavra-chave, suíte e Build.
palavra-chave– 0->1 palavras-chave podem ser selecionadas. Por padrão – nenhuma palavra-
chave é selecionada. Se uma palavra-chave não for selecionada, todos os Casos de Teste serão
considerados, independentemente das atribuições de palavra-chave. As palavras-chave são
atribuídas nas páginas Especificação de teste ou Gerenciamento de palavras-chave. As
palavras-chave atribuídas aos casos de teste abrangem todos os planos de teste e abrangem
todas as versões de um caso de teste. Se você estiver interessado nos resultados de uma
palavra-chave específica, altere esse controle.
proprietário– 0->1 proprietários podem ser selecionados. Por padrão – nenhum proprietário é
selecionado. Se um proprietário não for selecionado, todos os Casos de Teste serão
considerados, independentemente da atribuição do proprietário. Atualmente, não há
funcionalidade para pesquisar casos de teste “não atribuídos”. A propriedade é atribuída por
meio da página "Atribuir execução do caso de teste" e é feita por plano de teste. Se você
estiver interessado no trabalho feito por um testador específico, altere esse controle.
suíte de nível superior- 0-> n suítes de nível superior podem ser selecionadas. Por padrão –
todas as suítes são selecionadas. Apenas as suítes selecionadas serão consultadas para
métricas de resultados. Se você estiver interessado apenas nos resultados de um conjunto
específico, altere esse controle.
Construções– 1->n Builds podem ser selecionados. Por padrão – todas as construções são
selecionadas. Apenas as execuções realizadas em Builds que você selecionar serão levadas em
consideração ao produzir métricas. Por exemplo – se você quiser ver quantos Casos de Teste
foram executados nos últimos 3 Builds – você alteraria este controle.
As seleções de palavra-chave, proprietário e suíte de nível superior ditarão o número de Casos
de Teste do seu Plano de Teste que são usados para calcular por suíte e por métricas de Plano
de Teste. Por exemplo, se você selecionar proprietário=“Greg”, Palavra-chave=”Prioridade 1” e
todos os conjuntos de testes disponíveis – somente os Casos de Teste de Prioridade 1
atribuídos a Greg serão considerados. Os totais de “Nº de Casos de Teste” que você verá no
relatório serão influenciados por esses 3 controles.
As seleções de compilação influenciarão se um caso é considerado "aprovado", "reprovado",
"bloqueado" ou "não executado". Consulte as regras do “Último Resultado do Teste” conforme
aparecem acima.
Pressione o botão “enviar” para prosseguir com a consulta e exibir a página de saída.
-40-
 Ilustração 28: Métricas de consulta - Parâmetros de entrada

Página do relatório de consulta:

A página do relatório exibirá:
1. os parâmetros de consulta usados para criar o relatório
2. totais para todo o Plano de Teste
3. um detalhamento por suíte de totais (soma / aprovação / reprovação / bloqueado / não
executado) e todas as execuções realizadas nesse conjunto. Se um Caso de Teste tiver
sido executado mais de uma vez em vários Builds - todas as execuções que foram
registradas nos Builds selecionados serão exibidas. No entanto, o resumo desse
conjunto incluirá apenas o "Último resultado do teste" para as compilações
selecionadas.

-41-
Ilustração 29: Métricas de consulta - resultados

7.3 Relatórios de casos de teste bloqueados, com falha e não

executados

Esses relatórios mostram todos os Casos de Teste atualmente bloqueados, com falha ou não
executados. A lógica do “Último Resultado do Teste” (que é descrita acima em Métricas Gerais
do Plano de Teste) é novamente empregada para determinar se um Caso de Teste deve ser
considerado bloqueado, com falha ou não executado. Os relatórios de casos de teste
bloqueados e com falha exibirão os bugs associados se o usuário estiver usando um sistema
integrado de rastreamento de bugs.

7.4 Relatório de Teste

Visualize o status de cada Caso de Teste em cada Build. Se um Caso de Teste foi executado
várias vezes no mesmo Build – o resultado da execução mais recente será usado. É
recomendável exportar este relatório para o formato Excel para facilitar a navegação se um
grande conjunto de dados estiver sendo usado.

7.5 Gráficos

Esta página de relatório requer biblioteca gráfica instalada em seu servidor web. A lógica
"Último resultado do teste" é usada para todos os 4 gráficos que você verá.
Os quatro gráficos fornecidos são:
1. Gráfico de pizza de aprovação geral / reprovação / bloqueado / e não executa casos de
teste
2. Gráfico de barras de resultados por palavra-chave
3. Gráfico de barras de resultados por proprietário
4. Gráfico de barras de resultados por suíte de nível superior
As barras nos gráficos de barras são coloridas de forma que o usuário possa identificar o valor
aproximado

-42-
número de casos aprovados, reprovados, bloqueados e não executados.

7.6 Total de Bugs para cada Caso de Teste

Este relatório mostra cada Caso de Teste com todos os bugs arquivados para todo o projeto.
Este relatório só está disponível se um sistema de rastreamento de bugs estiver conectado.

7.7 Relatório baseado em requisitos

Este relatório está disponível se os requisitos forem permitidos para o Projeto de Teste atual. O
relatório é gerado em relação a um documento de Especificação de Requisito escolhido no
menu da caixa de combinação.
Há duas seções: visão geral de métricas e resultados.
As seguintes métricas estão disponíveis:
• Número total de requisitos
• Requisitos no TestLink
• Requisitos cobertos pelos casos de teste
• Requisitos não cobertos pelos casos de teste
• Requisitos não cobertos ou não testados
• Requisitos não testados
Os requisitos são divididos em quatro seções. Cada requisito é listado junto com todos os
Casos de teste (coloridos de acordo com o resultado do caso de teste):
• Requisitos aprovados
• Requisitos com falha
• Requisitos bloqueados
• Requisitos não executados

7.8 Como adicionar um novo relatório

Copie um dos relatórios atuais e modifique-o de acordo com sua necessidade. Não esqueça
que usamos templates para renderização
(<testlink_root>/gui/templates/<report_name>.tpl) e lógica
(<testlink_root>/lib/results/<report_name>.php). Recomendamos a reutilização de
funções existentes para coletar dados para relatório em vez de criar novas.
Editar <testlink_root>/lib/results/resultsNavigator.php para adicionar um link ao seu
novo relatório.
Existe uma matriz, que poderia ser facilmente aprimorada. Você deve adicionar um novo URL
e “nome da palavra-chave”7 de relatório.
Você pode modificar o estilo CSS de um relatório. Sugerimos criar novas classes ao invés de
modificar as atuais (para evitar alterações indesejadas em outras páginas).

Se você contribuir com seu(s) novo(s) relatório(s) através do nosso rastreador, você
poderá encontrá-lo também nas próximas versões... caso contrário, você corre o risco de
que ele não funcione para a próxima versão principal.

7 A string deve ser definida em locale/en_gb/string.txt

- 43 -
 8 Administração

8.1 Configurações da conta do usuário

Cada convidado pode criar sua própria conta na página de login.

O recurso de criação automática pode ser desabilitado pela configuração. Há também um
parâmetro de função padrão configurável ('convidado' por padrão).
Cada usuário do sistema poderá editar suas próprias informações através da janela de
configurações da conta (link 'Pessoal' na barra de menu). Ele pode modificar o próprio nome,
endereço de e-mail, senha e gerar chave de API (se habilitado).
O TestLink permite que usuários com direitos de administrador criem, editem e excluam
usuários no sistema. No entanto, o TestLink não permite que os administradores visualizem ou
editem as senhas dos usuários. Se os usuários esquecerem suas senhas, há um link na tela de
login, que enviará ao usuário sua senha com base em seu nome de usuário e no endereço de
e-mail inserido.

8.2 Permissões de Função

O usuário pode ver a função atual na linha superior da janela do TestLink. Cada usuário tem
'função genérica' que se aplica a todos os projetos. O administrador pode atribuir uma função
de projeto específica para um projeto específico. Os usuários também podem ter funções
modificadas para um Plano de Teste específico.

Por exemplo, Jack pode ser convidado por padrão (pode ver todos os casos de teste e
relatórios) e líder de teste no projeto 'XYZ' para liderar este teste de projeto.

O TestLink é construído com 6 níveis de permissão padrão diferentes integrados. Esses níveis
de permissão são os seguintes:
• Hóspede: um convidado só tem permissão para visualizar casos de teste, relatórios e
métricas. Ele não pode modificar nada.
• Executor de teste: um testador tem permissões para ver e executar testes alocados a
ele.
• Designer de teste: Um usuário pode trabalhar totalmente (visualizar e modificar) com
Especificação e Requisitos de Teste.
• Analista de teste: um testador pode visualizar, criar, editar e excluir casos de teste,
bem como executá-los. Os testadores não têm permissões para gerenciar planos de
teste, gerenciar projetos de teste, criar marcos ou atribuir direitos. (inicialmente
testador sênior).
• Líder de teste: um lead tem todas as mesmas permissões que um Testador, mas
também ganha a capacidade de gerenciar Planos de Teste, atribuir direitos, criar
marcos e gerenciar palavras-chave.
• Administrador: Um administrador tem todas as permissões possíveis (líder mais a
capacidade de gerenciar projetos de teste e usuários).
A alteração desses direitos é feita pelo link de administração do usuário, acessível pelos
administradores. O administrador pode adicionar novas funções personalizadas e modificar as
existentes via GUI.
Consulte o Guia do desenvolvedor para entender mais.
Se você visualizar a tabela, verá linhas para cada um dos níveis de permissão (convidado,
testador, testador sênior, líder, administrador). A segunda coluna contém todos os diferentes
níveis de direitos que serão definidos abaixo. Esses níveis foram determinados como padrão
para uso, mas podem ser editados para definir novas funções (para administrador experiente).
A tabela de usuários contém uma chave estrangeira que aponta para o nível de permissão
apropriado na tabela de direitos.

-44-
 Nota: Os recursos relacionados ao Plano de Teste também precisam atribuir um Plano de
Teste para estar disponível. Ver Teste Atribuição do Plano.

Estudo de caso - restringir o acesso por padrão

Situação
Em nossa organização, gostaríamos de restringir o acesso a projetos, a menos que seja
especificamente concedido. Atualmente temos cerca de 150 usuários com pouco mais de 90
projetos diferentes. Muitos dos usuários não são QA, mas são analistas de negócios e, em
alguns casos, usuários finais fazendo UAT. Pelo que posso dizer, todos os direitos são herdados
com base em como o usuário foi configurado.
Mas não queremos que um Analista de Negócios que esteja trabalhando em apenas um projeto
tenha acesso a todos os 90. Solução
Defina esses usuários com a função global <Sem direitos> e conceda uma função apropriada
em um projeto de teste ou base de plano de teste. Em custom_config.inc.php você também
pode definir o ID de função padrão para <Sem direitos>:
$tlCfg->default_roleid = TL_ROLES_NO_RIGHTS;

Você também pode renomear uma função como "Sem direitos" para algo mais educado.

8.3 Atribuição do Plano de Teste aos usuários

Os usuários podem executar apenas os Planos de Teste atribuídos. Para obter permissões de
Plano de Teste, um usuário com status de líder ou administrador deve conceder direitos a ele
por meio do link "Definir direitos de usuário/projeto" em "Gerenciamento de plano de teste".
Todos os usuários no sistema, por padrão, não terão permissões para visualizar os Planos de
Teste recém-criados (exceto os criadores do Plano de Teste que podem se conceder
permissões na criação). As permissões de Plano de Teste Zero significam que os usuários não
verão nenhum Plano de Teste na caixa suspensa Plano de Teste na tela principal.
No entanto, ele pode navegar pelos relatórios.

8.4 Campos personalizados

Os usuários podem estender os objetos mais importantes (casos de teste, suítes, planos) no
TestLink com campos personalizados. Depois de criar um campo personalizado, você precisa
atribuí-lo ao projeto de teste no qual deseja usá-lo. Assim, cada projeto tem seu próprio
conjunto de campos adicionais.
Prática comum: Caso de teste CF pode ser: notas de revisão ou status, tempo de
execução estimado ou real, plataforma (SO, HW, ...), nome ou proprietário do script de
teste, etc.
Navegue até o link "Gerenciamento de campo personalizado" na página principal. Esta página
é o ponto base para gerenciar o pool de campos personalizados. Ele lista os campos
personalizados definidos no sistema. As definições de campos personalizados abrangem todo o
sistema, ou seja, você não pode definir dois campos personalizados com o mesmo ID de
campo.

O botão "Criar" leva você a uma página onde você pode definir os detalhes de um campo
personalizado. Estes incluem seu nome, tipo, valor e informações de disponibilidade/exibição.
Na página de edição, as seguintes informações são definidas para controlar o campo
personalizado:
• nome
• modelo - os valores possíveis estão listados abaixo.
• Restrições de valor (Valores possíveis, valor padrão, expressão regular, comprimento
mínimo, comprimento máximo).
• Disponibilidade/controle de exibição (onde o campo aparecerá e deverá ser
preenchido

-45-
Todos os campos são comparados em comprimento para serem maiores ou iguais ao
comprimento mínimo e menores ou iguais ao comprimento máximo, a menos que esses
valores sejam 0. Se os valores forem 0, a verificação será ignorada. Todos os campos também
são comparados com a expressão regular. Se o valor corresponder à expressão, o valor será
armazenado. Por exemplo, a expressão "/^-?([0-9])*$/" pode ser usada para restringir um
número inteiro.

Há verificação de formato de dados para os tipos numérico, float e email. Ao enviar (quando
criado um caso de teste ou durante a execução) CFs desse tipo são controlados. Valor vazio
OK, mas se o valor não estiver vazio, mas não estiver de acordo com uma expressão regular
(NÃO DEFINIDO POR USUÁRIO, mas codificado) o envio será bloqueado com mensagem na
tela.
A tabela abaixo descreve os tipos de campo e as restrições de valor.

Conteúdo do
Modelo campo Restrições de valor
cadeia de texto até
Corda 255
personagens
Numérico um inteiro
Flutuador um ponto flutuante
número
um endereço de e- Quando exibido, o valor também será encapsulado em uma referência
E-mail mail mailto:.
corda até 255
personagens
Caixa de seleção zero ou mais de uma Insira a lista de strings de texto separadas por "|" (caractere de barra vertical)
lista no campo Valores Possíveis. O valor padrão também deve corresponder a uma
de cadeias de texto dessas strings. Isso será exibido como uma lista de strings de texto com uma
caixa de seleção ao lado delas.
Lista um de uma lista de Insira a lista de strings de texto separadas por "|" (caractere de barra
texto vertical) no campo Valores Possíveis. O valor padrão também deve
cordas corresponder a uma dessas strings. Isso será exibido como um menu
suspenso de várias linhas.
Lista de seleção múltipla zero ou mais Insira a lista de strings de texto separadas por "|" (caractere de barra
de uma lista vertical) no campo Valores Possíveis. O valor padrão também deve
de cadeias de texto corresponder a uma dessas strings. Isso será exibido como um menu
suspenso de várias linhas.

Encontro string de texto definindo um Isso é exibido como um conjunto de menus suspensos para dia, mês
e ano.
encontro Os padrões devem ser definidos no formato aaaa-mm-dd.
Área de texto Rich text

Tabela 1: Tipos de campos personalizados

As entradas de exibição são usadas da seguinte forma:

Entrada Significado
Exibir ativado Se marcado, o campo será mostrado na árvore de Especificação de Teste
especificação do teste
Ativar Se marcado, o campo será editável (atribuir/alterar) na Especificação de Teste
especificação do teste
Exibir ativado Se marcado, o campo será mostrado em Execução de Teste
execução do teste
Ativar Se marcado, o campo será editável em Execução de Teste
execução do teste
Disponível para Caso de teste, plano de teste ou conjunto de testes

Tabela 2: Campos personalizados: Atributos de disponibilidade/exibição

Exemplo 1.
Campo personalizado: notas adicionais

-46-
 Modelo : corda

aplicável a suítes de teste, a ser editado SOMENTE durante

Especificação do caso de teste, mas útil para ser visto durante a execução do teste.

mostrar no design = SIM

habilitar no projeto = SIM
mostrar na execução = SIM
habilitar na execução = NÃO

Exemplo 2.
Campo personalizado: sistema operacional
Modelo : Lista

aplicável aos Casos de Teste, a ser editado SOMENTE durante

EXECUÇÃO do Caso de Teste, não utilizado durante o PROJETO do Caso de Teste.

mostrar no design = NÃO

habilitar no projeto = NÃO
mostrar na execução = SIM
habilitar na execução = NÃO

O recurso de campo personalizado foi implementado usando uma funcionalidade de

mistura do Mantis (http://www.mantisbt.org/) e dotproject
(http://www.dotproject.net/) modelos.

Campos personalizados: tempo de execução estimado e real

Os campos personalizados “Tempo estimado de execução” e “Tempo real de execução” podem

ser adicionados a qualquer projeto e o TestLink resumirá automaticamente esses campos
durante o processo de relatório.

Passo 1 – Crie os campos personalizados

NOTA: O usuário deve ter permissões (ou seja, "Gerenciamento de campo

personalizado" deve estar ativado para a função do usuário) para definir e atribuir
campos personalizados.
Primeiro selecione “Definir campos
personalizados” no grupo Projeto de teste,
conforme mostrado abaixo.
Em seguida, selecione o botão “Criar”.
É muito importante que o campo Nome seja
exatamente CF_ESTIMATED_EXEC_TIME devido
às consultas internas projetadas para este campo.
O campo Tipo deve
ser Numeric, String ou Float, pois as consultas criadas funcionarão apenas em dados
numéricos. Sugere-se o tipo Float, pois permite maior flexibilidade.
-47-
Depois de concluído, clique em “Adicionar” para criar o novo campo personalizado no sistema.
Em seguida, repita o processo para CF_EXEC_TIME como visto abaixo.

-48-
Os novos campos personalizados estarão disponíveis para atribuição a QUALQUER projeto no
TestLink. Certifique-se de que o projeto de teste esteja definido para o projeto desejado antes
de atribuir os campos personalizados.

Passo 2 – Atribuir campos personalizados

Selecione “Atribuir campos personalizados” no

grupo Projeto de teste, conforme mostrado
abaixo.
Selecione cada um dos campos personalizados e
clique em “Atribuir”.
Agora, cada um dos campos personalizados foi
atribuído ao projeto atual.

Ao criar um novo caso de teste (ou editar um caso de teste inserido anteriormente), acima da
seção Palavras-chave, você observará os campos personalizados.

-49-
Adicione o tempo estimado e clique em “Criar” (ou “Salvar” em uma edição).
Localizações: Use “ . “ (ponto) como separador decimal ou soma estará errado.

Passo 3 – Adicione os casos de teste ao Plano de Teste

Ver capítulo 5.3 para detalhes.

Passo 4 – Soma das Estimativas

Selecione “Relatórios e Métricas de Teste” no

grupo Execução de Teste, conforme mostrado
abaixo.

Selecionar
"Teste
Relatório"
a partir de a
cardápio, então
marque a opção "Métricas"

Por fim, selecione o Conjunto de Testes ou Caso de Teste

que você deseja criar o relatório.

Na parte inferior do relatório haverá um resumo do

tempo de execução estimado para todos os casos de
teste.

-50-
NOTA: A hora inserida nos campos personalizados não precisa estar em unidades de
minutos, as horas também podem ser usadas. As strings $TLS_estimated_time_hours e
$TLS_estimated_time_min são strings predefinidas que podem ser selecionadas com
base em sua preferência.

-51-
 9 Importar e exportar dados

O TestLink suporta várias maneiras de compartilhar dados. O formato de dados é descrito no

documento extra <testlink>/docs/tl-file-format.pdf. Além disso, você pode usar a API
TestLink para fornecer dados de script ou ferramenta externa.
Há uma quantidade de exemplos de arquivos no diretório <testlink>/docs/file_examples/.

-52-