manual testlink 1.7 (beta)
TRANSCRIPT
Manual do usuárioTest Link versão 1.7
É concedida a autorização para copiar, distribuir e/ou modificar esse documento sob os termos
da licença de documentação livre GNU, versão 1.2, publicada pela Free Software Foundation,
sem seções invariantes, sem capa nem contracapa de textos. A licença está disponível na página
“GNU Free Documentation License”.
Tabela de conteúdos
1 Informações gerais........................................................................................................................... 4
1.1 Estruturas Globais...................................................................................................................... 4
1.2 Terminologia.............................................................................................................................. 4
1.3 Exemplos de fluxo de trabalho do Test Link............................................................................. 5
2 Projetos de Teste.............................................................................................................................. 7
2.1 Criando novos projetos de teste................................................................................................ 7
2.2 Editar e Apagar Projetos de teste............................................................................................ 7
3 Especificação de Testes................................................................................................................... 8
3.1 Caso de Teste de Suite............................................................................................................... 8
3.2 Casos de Testes.......................................................................................................................... 8
3.3 Atribuindo palavras-chave......................................................................................................... 9
4 Requisitos baseados em testes......................................................................................................... 11
4.1 Disponibilidade.......................................................................................................................... 11
4.2 Requisitos de especificação....................................................................................................... 11
4.3 Requisitos................................................................................................................................... 12
5 Planos de Testes............................................................................................................................... 14
5.1 Criar e deletar Planos de testes.................................................................................................. 14
5.2 Construção................................................................................................................................. 14
5.3 Populando Planos de testes – adicionando Casos de Testes...................................................... 14
5.4 Atribuição de testes de execução............................................................................................... 16
5.5 Prioridade................................................................................................................................... 16
5.6 Marcos........................................................................................................................................ 16
6 Teste de execução............................................................................................................................ 18
6.1 Geral........................................................................................................................................... 18
6.2 Navegação.................................................................................................................................. 18
6.3 Execução.................................................................................................................................... 19
7 Personalizar campos......................................................................................................................... 21
8 Teste de relatórios e métricas........................................................................................................... 22
8.1 Métricas Gerais do Plano de Teste............................................................................................. 22
8.2 Status das Construções Globais................................................................................................. 23
8.3 Métricas de Busca...................................................................................................................... 23
8.4 Relatórios de Casos de Testes que não ocorrem, fracassados ou
bloqueados.......................................................................................................................................
24
8.5 Relatório de teste........................................................................................................................ 24
8.6 Diagramas.................................................................................................................................. 24
8.7 Perda Total para cada Teste de Caso...................................................................................... 25
8.8 Requisitos baseados em relatório............................................................................................... 25
8.9 Como criar um novo relatório.................................................................................................... 25
9 Administração do usuário................................................................................................................ 26
9.1 Permissão de papéis................................................................................................................... 26
9.2 Papéis do Usuário...................................................................................................................... 26
9.3 Definições de direitos................................................................................................................ 27
9.4 Contribuições do Plano de Teste................................................................................................ 28
10 Importando e exportando dados....................................................................................................... 29
10.1 Importando/Exportando Palavras-Chave................................................................................. 29
10.2 Exportando/ Importando Projeto de Teste............................................................................... 30
10.3 Importando/Exportando Teste de Suite................................................................................... 31
10.4 Apenas um Caso de Teste........................................................................................................ 32
10.5 Todos os Casos de Testes em um Teste de Suite..................................................................... 33
10.6 Importando/Exportando Requisitos de Software..................................................................... 33
10.7 Importando Casos de Testes para o Excel via XML................................................................ 34
1- Informação Geral
O TestLink é baseado no Sistema de Gerenciamento de Teste. Esse manual deve servir como
fonte para os usuários entenderem os processos, termos e organização do trabalho com o
TesteLink. Veja o manual de instalação para mais informações sobre o sistema de requisitos,
passos de instalação e configuração. A documentação mais recente está disponível em
www.teamest.org ou testlink.sourceforge.net.
1.1 Estruturas Globais
Aqui estão os três pilares: Projeto de Teste, Plano de Teste e Usuário. Todos os outros dados
são relações ou atributos para esta base. Primeiro, definiremos alguns termos que são usados
em todas as partes do mundo de testes e documentações.
1.2 Terminologia
O Caso de Teste descreve uma tarefa de testes via passos (ações, cenário) e resultados
esperados. Os Casos de testes são uma parte fundamental do TestLink.
O Caso de Teste de Suite organiza os casos de testes em unidades, o que estrutura a
especificação dos testes em partes lógicas.
O Caso de Teste de Suite era chamado de componentes e categorias antigamente em TL 1.6.
Os Planos de Testes são criados quando você gostaria de executar Casos de Testes. Os Planos
de Testes podem ser inventados a partir dos Casos de Testes de um ou muitos Projetos de
Testes. O Plano de teste inclui construção, marcos, atribuições de testes e resultados de
testes.
O Projeto de Teste é algo que existirá para sempre no Testlink. O Projeto de Teste sofre
muitas diferentes versões por todo o seu ciclo de vida e inclui a especificação de teste com os
casos de testes, requisitos e palavras-chave. Os usuários, dentro do projeto, deverão ter
funções definidas.
O Projeto de Teste era chamado Product antigamente no TL1.6.
Usuário: Cada usuário TestLink tem uma função, que define as características disponíveis do
TestLink. Veja mais no capítulo “Administração do Usuário”. A figura 2 mostra atividades
comuns de acordo com as funções do usuário.
1.3 Exemplos de fluxo de trabalho do Testlink
1. O administrador cria um projeto de teste Fast Food e dois usuários: Adam com
direitos “Líder” e Bela com direitos “Testador Sênior”.
2. O líder Adam importa requisitos de software e, parte destes requisitos, cria casos de
testes vazios.
3. A testadora Bela descreve um cenário de testes (cria um conteúdo vazio de testes de
casos), utilizando este Test Stecification que é organizado dentro dos Testes de
Suítes.
4. Adam cria uma palavra-chave “Regression testing” e atribui esta palavra-chave a dez
destes casos de testes.
5. Adam cria um plano de teste Fish & Chips 1, constrói o Fish 0.1 e adiciona todos os
links no Teste de Suite Fish deste Plano de Teste. Ele aloca Bela como recurso para
este plano de teste também.
6. Agora desenvolvedores produzem um primeiro build. Adam e Bela executam e
gravam o teste com o resultado: 5 passaram, 1 falhou e 4 foram bloqueados.
7. Descobridores fazem um novo build Fish 0.2 e Bela testa apenas os casos de testes
que falharam e que foram bloqueados. Desta vez, todos os testes que foram
bloqueados e falharam passaram. Eles também retestaram todos os casos de testes
com as palavras-chave "Regressão testing" em complemento.
8. Um gerente desse time gostaria de ver os resultados. O administrador explica-lhe que
ele mesmo pode criar uma conta na página de acesso. O gerente o faz. Ele tem como
default direitos de guest (convidado) e pode ver os resultados dos testes e os casos de
testes. Ele pode ver que tudo que passou está no relatório geral e problemas no Fish
0.1 em um relatório particular da criação.
9. Mais tarde, os desenvolvedores finalmente acrescentam também Chips de
funcionalidade. Adam cria um plano de teste Fish&Chips 2. Ele pode reutilizar o
primeiro plano de teste como modelo. Todos os casos de testes Fish e permissões
serão adicionados automaticamente. Ele cria um novo build Fish 1.1 e todos os links
dos casos de testes Chips são inseridos neste plano de testes também.
10. Agora, os testes são iniciados como habitualmente.
11. Mais tarde, a administração cria um novo teste de projeto para outro produto Hot
Dog. Mas isto é outro teste, outra equipe e outra história.
Figura 2 – Visão geral da funcionalidade.
2. Projetos de Teste
Os projetos de teste são a base organizacional da unidade de TestLink. Os projetos de
teste são lançamentos da sua empresa que podem alterar as suas características e funcionalidades
ao longo do tempo, mas, na maior parte dos casos, continuam a ser os mesmos. O projeto de
teste inclui requisitos de documentação, especificação de testes, planos de testes e direitos
específicos dos usuários.
2.1 Criando um novo Projeto de Teste
Criar um novo projeto de teste exige direitos de administrador. Cada projeto deve ter um
nome exclusivo. As cores de fundo podem ser atribuídas a modelos de projeto de teste para
distingui-los visualmente. O administrador pode permitir requisitos relacionados com a
funcionalidade.
Algumas observações para a criação de um novo projeto de teste:
Apagar projetos de testes do sistema não é recomendado, pois deixará um grande
número de casos de testes órfãos ou deletar caso de teste do sistema.
Planos de testes representam testar um projeto de teste até um determinado ponto.
Conseqüentemente, planos de testes são criados a partir de projeto de testes de
casos de testes. Não recomendamos criar projetos de testes separados para versões
de um produto.
TestLink suporta importação de dados em XML ou CSV dentro do Projeto de
Teste. Isto é explicado na seção de importação, a seguir.
2.2 Editar e Apagar Projetos de Teste
A edição de projetos de testes requer direitos de administrador. O usuário pode mudar o
nome do projeto de teste, cores de fundo e a disponibilidade dos requisitos funcionais.
O usuário pode desativar o projeto de teste se ele estiver obsoleto. Isto significa que o
projeto de teste não ficará visível na lista dentro da barra de navegação superior (o
administrador verá este Projeto de Teste na lista marcada por “*”). O usuário pode
apagar também um projeto de teste. Esta ação também vai apagar todos os dados
relacionados com os da base de dados. Esta ação não é reversível. Recomendamos o uso
“inativar” em vez de “excluir”.
3. Especificação de testes
O Testlink decompõe a estrutura do caso de teste em testes de suites e casos de testes. Esses
níveis persistem em todas as partes da aplicação.
3.1 Teste de Suite
Os usuários organizam os casos de testes em testes(casos) de suites. Cada teste de suite
consiste de um título, descrição formatada dos casos de testes e, possivelmente, outros testes de
suites. TestLink utiliza estrutura de árvore para teste de suites. A prática comum é a de que a
descrição detenha informação válida para a maioria dos dados incluídos. Por exemplo, o seguinte
pode ser especificado: escopo, configuração, pré-condição, documentação relacionada,
ferramentas, infra-estrutura etc. Criar um ou mais testes de suite é um dos primeiros passos ao
criar o seu projeto de teste.
Os usuários (com direitos de edição) podem criar, apagar, copiar, mover, exportar e
importar ambos os testes de suites e casos de testes aninhados. Título e descrição podem ser
modificados também. Anexos com documentos ou imagens poderão ser adicionados em teste de
suites particulares. A funcionalidade deve ser permitida através da configuração do Testlink.
3.2 Casos de Testes
O teste de processo é um conjunto de fatores de produção, condições prévias de execução e
resultados esperados (outcomes), desenvolvidos para um objetivo particular, como o de
exercer um programa em particular ou caminho, a fim de verificar o cumprimento de um
requisitos específico.
Os casos de testes constituem-se da seguinte maneira:
Título: poderia incluir uma descrição breve ou abreviatura(por exemplo: TL-
USUARIO- LOGIN).
Sumário: deve ser realmente curto, apenas para uma visão geral.
Etapas: descreve o cenário do teste (ações de entrada). Pode também incluir pré-
condições e limpeza das informações.
Resultados esperados: descrevem a verificação e o comportamento esperados de um
produto ou sistema testado.
O número do ID de um caso de teste é atribuído, automaticamente, pelo TestLink e
não pode ser alterado pelos usuários. Este ID é um sistema amplo, o que significa que
quando um caso de teste é criado, um contador global é utilizado, independente do
projeto de teste no qual o caso de teste foi criado.
Anexos: poderia ser acrescentado se a configuração permitisse.
Caso de Teste- Atributo Ativo
Se várias versões de um caso de teste existirem, seria útil dispor de um novo atributo,
Ativo/Inativo e utilizar desta forma:
Cada versão do caso de teste é criada ATIVA.
Uma versão do caso de teste inativa não deverá estar disponível em “Adicionar casos
de testes a plano de teste”. Isto pode ser útil para os projetistas (designers) de testes.
Eles podem editar ou alterar a versão do caso de teste e somente quando ele/ela
decidir que está concluído, então muda o status para ATIVO e então estará disponível
para ser incluído e usado em um plano de teste.
Uma vez que a versão do caso de teste foi linkada ao plano de teste e tem resultados,
ela não pode se tornar INATIVA.
Figura 3: O que você pode visualizar na especificação de casos de teste.
Figura 4:
Como você pode observar, 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 testes. O caso de teste TC1 não é
contado porque está inativo.
Removendo Casos de Testes
Os casos de testes e testes de suites podem ser removidos de um plano de teste por usuários
com esta permissão. Esta operação pode ser útil em uma primeira criação de um plano de
teste, desde que não haja nenhum resultado. Entretanto, remover casos de testes causará a
perda de todos os resultados associados a eles. Por isso, é recomendado um cuidado extremo
no uso desta funcionalidade.
Relação de requisitos
Os casos de testes poderiam estar relacionados a requisitos de software/sistema como “n”
para “n”. A funcionalidade deve ser capacitada para um projeto de teste. O usuário pode
atribuir os casos de testes e requisitos via o link de atribuição de requisitos na tela principal.
3.3 Palavras-chave
Palavras-chave foram criadas para fornecer aos usuários um outro nível de profundidade quando
categorizados os casos de testes.
Palavras-chave servem como um meio de agrupamento de casos de testes com alguns atributos
dentro de uma especificação de teste. Por exemplo, você pode usá-las para definir:
Regressão ou sanity set.
Revisão dos casos de testes.
Conjunto de casos de testes válidos para uma plataforma.
Criação da palavra-chave No momento, as palavras-chave podem apenas ser criadas por usuários com os direitos
mgt_modify_key. Esses direitos são atualmente mantidos pelos líderes. Uma vez que uma
palavra-chave ou um grupo de palavras-chave foi criada por usuários, estes podem atribuí-las aos
casos de testes.
Atribuindo palavras-chave
Palavras-chave podem ser atribuídas em um caso de teste a partir da tela da palavra-chave ou via
gerenciamento de caso de teste (individualmente).
Filtrar por palavra-chave
Os usuários têm habilidade para filtrar por palavra-chave para:
Pesquisar casos de testes em especificação de testes.
Adicionar grupos de casos de testes em casos de testes de suites (plano de teste).
Executar teste na tela.
4 Testes baseados em requisitos
Para provar que um sistema é construído como o especificado, os testadores usam o teste
baseado em requisitos. Para cada requisito, eles desenham um ou mais casos de testes.
No fim da execução do teste, um gerente de testes relata sobre os testes que são executados e
se os requisitos são atendidos. Baseado nesta informação, o cliente e os vários envolvidos
decidem se um sistema pode ser transferido para a próxima fase de teste ou (can go live).
Para garantir que um sistema é construído como previsto, os gerenciadores de testes utilizam
uma combinação de risco e requisitos baseados em testes para garantir que um sistema é
construído conforme o especificado para a perspectiva do cliente e dos envolvidos no
sistema. Como resultado, isto oferece as seguintes vantagens:
Vinculação de riscos e os requisitos irão revelar requisitos vagos ou ausentes. Isto
é especialmente interessante para os riscos de alta prioridade.
Os testes podem ser focados nas partes mais importantes de um sistema de
informações: cobrindo os riscos com a mais alta prioridade.
Comunicar na mesma linguagem o cliente e as partes interessadas. Isso torna mais
fácil de apresentar um relatório sobre o estado do projeto de teste. Em seguida,
uma decisão pode ser mais bem fundada se investir mais em testes ou assumir o
risco.
Os riscos e suas prioridades podem ser negociados mais fácil no projeto de teste
em momentos de pressão. Quais os riscos têm que ser terminados no âmbito deste
projeto de teste e quais podem ser adiados. Risco e teste baseado em requisitos
resultam em um projeto de teste melhor controlado. A comunicação com os
clientes e os envolvidos é melhorada. O gerenciamento do teste inicia com testes
de riscos que possuem a maior prioridade. O processo é simplificado e o resultado
final é de alta qualidade.
4.1 Disponibilidade
A funcionalidade está disponível no nível de projeto de teste. Por exemplo: o administrador
deve capacitá-lo para um projeto de teste específico (link “Editar projeto de teste” na janela
principal). Caso contrário, os links não são mostrados.
Existem 2 níveis de usuários para este recurso. A maioria das funções pode visualizar
requisitos, mas não modificá-los. Consulte a seção do usuário para mais informações.
Especificação de requisitos
Os requisitos são agrupados para uma ou mais sistemas/software/especificação de requisitos
do usuário.
Figura 5: Dependências entre requisitos e objetos relacionados.
Criar um documento com requisitos:
1 Clicar em especificação de requisitos na janela principal. A lista das especificações de
requisitos é mostrada.
2 Aperte o botão “Criar” para criar um documento.
3 Ajuste título, escopo e, eventualmente, o número de casos de testes. O último parâmetro é
usado para as estatísticas. Use somente se você tiver um documento de requisitos válido, mas
nem todos os requisitos estão disponíveis no momento no Testlink. O valor padrão “n/a”
significa que a contagem dos atuais requisitos em uma especificação é utilizado.
4 Pressione o botão “Criar” e adicione dados na base de dados. Você pode ver o título do
novo documento criado na tabela da lista de especificação de requisitos.
5 Clique no título do documento para o próximo trabalho. A janela de especificação de
requisitos é mostrada. Cada especificação de requisitos tem seu próprio relatório e estatísticas
relacionados com os 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 a empresa, autor e texto
confidencial através de arquivos de configuração.
4.3 Requisitos
Cada demanda tem título, escopo (formato html) e status (posição). O título não deve ser
único e ter, no máximo, 100 caracteres. O parâmetro escopo é um texto no formato html. O
status deve ter valor válido ou não testável. Os requisitos não testáveis não são contados para
métricas.
Os requisitos devem ser criados/modificados ou apagadas manualmente, via interface do
Testlink ou importadas como arquivo CSV.
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 ‘exportação para portas’ tenta detectar o cabeçalho e escolhe campos
corretos. Importa e compara títulos e tenta resolver conflitos. Existem três maneiras de fazer
isso: atualizar, criar requisitos com o mesmo título e omitir somas the conflicted ones.
Requisitos para relação de casos de testes
Os casos de testes estão relacionados com requisitos de software/sistema como “para”. Isto é,
você pode nomear um ou mais casos de testes para um requisito e um ou mais requisitos
podem ser cobertos por um caso de teste. O usuário pode nomear requisitos para casos de
testes via link ‘Requisitos Assignados’ na janela principal.
Uma cobertura da especificação de teste poderá ser visualizada pressionando o botão
“Analisar” na janela de especificação de requisitos.
Requisito baseado em relatório
Navegar até o menu ‘Relatórios e métricas’. Existe um link ‘Requisitos’ baseado em
relatório. Requisitos, na atual especificação de requisitos e planos de testes são analisados
para este relatório. Os últimos resultados dos casos de testes (disponível no plano de teste)
são processados para cada requisito. O resultado com a maior prioridade é aplicado para o
requisito. As prioridades da mais alta para a mais baixa são: fracassado, bloqueado, não
executado e passou.
Exemplo de cobertura de requisitos
Um requisito é coberto por três casos de teste. Dois deles são incluídos no teste de suite atual.
Um passou e não foi testado para o build 1. Agora tem o resultado global: não compilado. O
segundo caso de teste foi testado com build 2 e passou. Então o requisito passou também.
5 Planos de teste
Um registro do processo de planejamento de teste, detalhando o grau de envolvimento do
testador, o teste de ambiente, o desenho de técnicas de casos de testes e testes de técnicas de
medição são utilizados, bem como a justificativa para a sua escolha.
Planos de teste são a base para a execução de casos de testes. Os Planos de Testes contém nome,
descrição,coleção de Casos de Testes escolhidos, builds, resultados dos testes, marcos, testador e
sessão de definição de prioridade.
5.1 Criar e apagar Planos de Testes
Planos de teste podem ser criados a partir da página "Gerenciamento de plano de teste", por
usuários com privilégios de líder para os atuais projetos de testes. Pressione o botão "Criar" e
digite os dados.
Planos de teste são compostos de casos de testes importados de uma especificação de testes em
um ponto específico de tempo. Planos de teste podem ser criados a partir de outros planos de
teste. Isso permite que os usuários criem planos de testes para casos de testes que existem em um
ponto no tempo desejado. Isto pode ser necessário para criação de um plano de teste para um
patch. Para que um usuário veja um plano de teste, eles devem ter este direito. Os direitos podem
ser atribuídos (por líderes) na seção de definição de direitos usuário/projeto. Esta é uma coisa
importante para se lembrar quando os usuários dizem que não podem ver o projeto em que eles
estão trabalhando.
Planos de teste podem ser excluídos pelos usuários com privilégios de líderes. Excluindo planos
de testes permanentemente, apagará tanto o Plano de Teste e todos os seus dados
correspondentes, incluindo os casos de testes (não em especificação de teste), resultados etc. Isto
deve ser reservado apenas para casos especiais. Alternativamente, planos de testes podem ser
desativados na mesma página que suprime a exibição, em menus de seleção na página principal.
5.2 Builds
Um usuário com privilégios de líder poderia seguir o link "Gerenciamento de build", na página
principal. Builds são um release específico do software. Cada projeto em uma companhia é
provavelmente feito de muitos diferentes builds. A execução do Testlink é feita de builds e casos
de testes. Se não existirem builds criados para um projeto, a tela não permitirá executá-lo. A tela
de métrica também ficará completamente branca.
Cada construção é identificada via título. Isto inclui descrição (formato html) e dois estados:
Ativo/Inativo - define se a construção está disponível para a funcionalidade do Testlink.
O build inativo não é listado nem na execução e nem na página de relatórios.
Aberto/fechado - define se os resultados do teste podem ser modificados para o build.
Builds podem ser editados (via link under a build title) e excluídos (por um clique sobre o ícone
"bin" apropriado) no quadro das atuais Builds.
5.3 Povoando planos de testes – Adicionando casos de Testes
Os dados de múltiplos Projetos de Testes podem ser adicionados em um Plano de Teste.Os dados
da especificação de testes podem ser filtrados por palavras-chave (ajustado no painel navegação).
Uma vez que os dados tiverem sido ligados a um plano de teste , ele será marcado com uma
marca de checagem. Se um caso de teste já tiver sido importado ele será ignorado se for
importado de novo.
Illustration 6: Frame for Adding Test Cases into Test Plan
Illustration 7: Frame for modifying content of test cases within Test Plan
Removendo casos de testes do plano de teste
Os casos de teste e testes de suites podem ser removidos de um plano de teste por usuários com
permissões de líder da página “Remover casos de teste”. Remover dados pode ser útil quando na
criação de um plano de teste não há resultados. Porém, remover casos de teste causará a perda de
todos os resultados associados a eles. Por isso, cuidado extremo é recomendado ao usar essa
funcionalidade.
Tree in left pane, shows only the Test Cases present in Test Plan.
5.4 Teste de execução assignment
O Teste de execução assignment afeta tanto a execução como as telas de métricas. Na execução
da tela, os usuários têm a capacidade de classificar os casos de testes executáveis para ver the
ones they have been assigned. Nas principais telas de métricas existe uma tabela que mostra os
processos restantes por testador. Se não houver caso de teste do testador, o padrão atribuído é
nenhum.
A Tester can also see the metrics of his/her own executed tests in main page if these metrics are enabled (see Installation manual).
5.5 Prioridade
Este recurso está indisponível temporariamente na versão 1.7. Ele precisa de uma atualização
para permitir a habilidade especial nos casos de testes.
O TestLink dá aos usuários o direito de assignar a Importância dos casos de testes. O risco geral
é feito no nível de teste de suite com um plano de teste particular.
TestLink combina estes dois atributos com prioridade. Estes atributos (risco, importância e
prioridade) têm três níveis (baixo, médio e alto). O médio é o valor padrão.
Nomear riscos, importância e prioridade são todos opcionais. Poderia ser permitido pelo
administrador um teste escolhido para o projeto.
5.6 Marcos Nota: A versão 1.7 não inclui relatório padrão para marcos.
O líder do teste pode definir o percentual final de testes com relação a uma data definida. A
solução atual espera definir prioridades.
Illustration 8: Test leader can define one or more milestones for a Test Plan
6 Execução de teste
6.1 Geral
A execução do teste está disponível quando:
1- A especificação do teste está escrita.
2- O plano de teste é criado.
3- Os casos de testes são adicionados a plano de testes.
4- Um build é criado.
5- O plano de teste é nomeado aos testadores (caso contrário eles não podem navegar para
esse plano de teste).
Selecionar um plano de teste na página principal e navegar para o link “Executar testes”. O
painel esquerdo permite a navegação no caso de teste de suite, via menu da árvore, filtrando
por palavra-chave, resultado, build e testador.
6.2 Navegação
O painel de navegação consiste de uma caixa “Filtro&Configurações” e um menu da árvore
de casos de testes de suites.
Filtrando casos de teste
Essa tabela permite ao usuário filtrar os casos de testes para uma navegação inteligente antes
que eles sejam executados.
Testador – os usuários podem filtrar casos de testes por seus testadores.
Palavra-chave – os usuários podem filtrar casos de testes por palavra-chave. As palavras-
chave são definidas usando o Criar/Editar/Deletar casos de testes ou pelo Atribuir
palavras-chave para múltiplos casos. Palavras-chave só podem ser criadas, editadas ou
apagadas pelo líder, mas podem ser renomeadas aos casos de testes por testadores.
Resultado- os usuários podem filtrar casos de teste por resultados. Os resultados referem-
se ao que aconteceu a esses casos de teste durante um determinado build. O caso de teste
pode passar, ser bloqueado ou não ser executado.
Definir um teste de Build
Os usuários podem filtrar casos de teste por builds. Builds são os componentes básicos de como
os casos de testes são monitorados. Cada caso de teste pode ser executado uma vez e apenas uma
vez por build. Builds podem ser criados por usuários líderes na página “Criar Novo Build”.
Menu da árvore
O menu da árvore no painel de navegação inclui casos de testes de suites colorida por resultados.
Menu colorido: Por default, a árvore será classificada por resultados para o build definido, que é
escolhido de uma caixa dropdrown.
Exemplo TC coloridas de acordo com o Build
O usuário seleciona Build 2 da dropdown box e não se verifica o check da caixa mais atual.
Todos os casos de teste serão exibidos com o seu status de Build 2. Portanto, se o caso de teste 1
for aprovado no Build 2, será colorido de verde.
Uma segunda possibilidade é a de que o menu será colorido de acordo com os últimos resultados
dos testes.
Exemplo TC colorido de acordo com o resultado mais recente
O usuário seleciona Build 2 na dropdown box e this time checks the “most current” check box.
Todos os casos de testes serão mostrados com o status mais atual. Então, se o caso de teste 1
passou em Build 3, mesmo que o usuário tenha também selecionado Build 2, será colorido de
verde.
6.3- Execução
Status do teste
A execução é o processo de nomear um resultado (passou, falhou, bloqueado) ao caso de teste
para um build específico. O caso de teste ‘bloqueado’ não é possível testar por alguma razão (por
exemplo: um problema na configuração não permite executar a funcionalidade testada).
Inserir resultados do teste
A tela de resultados de testes é mostrada via clique sobre um teste de suite ou caso de teste na
tela de navegação. O título mostra o build atual e o proprietário. A barra colorida indica o status
do caso de teste. A caixa amarela inclui o cenário do caso de teste.
Illustration 9: Frame with several results of one Test Case
Illustration 10: User can select to print only the last result
Illustration 11: The last result could be printed only
A indicação de que o caso de teste foi atualizado ou excluído na especificação do teste não é
suportada após a versão 1.5.
Casos de testes atualizados: a versão TL 1.0.4 tem indicação por flag, que é perdida na versão
1.6. Se os usuários tiverem direitos próprios, eles podem ir á página “Modificação atualizada de
caso de teste”, através do link na página principal. Não é necessário que os usuários atualizem os
casos de testes se tiver existido mudança (versão mais nova ou deletada).
7 Personalizar campos
As definições de campos personalizados consistem em um sistema amplo, ou seja, não é possível
definir dois campos com o mesmo ID. Depois de ter criado um campo personalizado, você
precisa associá-lo ao Projeto de Teste que você deseja usar.
O campo personalizado foi implementado utilizando uma mistura de funcionalidade dos modelos
Mantis (http://www.mantisbt.org/) e dotproject (http://www.dotproject.net/).
Mostrar/Exibir atributos
Mostrar em design:
O campo personalizado será exibido durante a especificação do caso de teste.
Exibido na execução:
O usuário será capaz de atribuir/alterar o valor do campo personalizado durante a especificação
do caso de teste:
Os campos personalizados deverão ser exibidos durante a execução do caso de teste.
Permitir em execução:
O usuário será capaz de atribuir/alterar o campo personalizado durante a execução do caso de
teste. Os valores atribuídos serão salvos.
Example 1. Custom Field: Additional Notes
Type: string
applicable to test suites, to be edited ONLY during Test Case specification, but useful to be seen during test execution.
show on design = YES
enable on design = YES show on execution = YES enable on execution = NO
Example 2.Custom Field: Operating System Type: list
applicable to Test Cases, to be edited ONLY during Test Case EXECUTION, unused during Test Case DESIGN.
show on design =NO
enable on design = NO
show on execution = YES enable on execution = NO
8 Relatórios de Testes e Métricas
Os relatórios de testes e métricas são acessados clicando em "Resultados" ou "Relatórios de testes e
métricas" nos links na página principal. Relatórios e métricas baseiam-se no Plano de Teste
selecionado (do menu da combobox). A página que é mostrada ao 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 por cada relatório e por controles operacionais que
controlam o efeito e o comportamento dos relatórios que são mostrados. 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 1 de 3 formatos:
1-Normal: relatório é exibido na página web (html).
2-MS Excel: relatório é exportado para o Microsoft Excel.
3-HTML e-mail: relatório é enviado ao endereço de e-mail do usuário.
Existem atualmente nove relatórios separados para escolher sua finalidade e suas funções são
explicadas a seguir. Atualmente, não há relatórios que compilam os resultados de vários planos de
testes.
8.1 Métricas gerais de Planos de Testes
Esta página mostra-lhe apenas o mais atual status de um Plano de teste para testes de suite,
proprietário e palavra-chave. A maioria dos "status atual" são determinadas pelos mais recentes
casos de testes de build executadas no dia. Por exemplo, se um caso de teste foi executado durante
vários builds, apenas o mais recente resultado é tido em conta. "Último Resultado do teste" é um
conceito usado em muitos relatórios e é determinado como se segue:
1) A ordem na qual os builds são adicionados no plano de teste determina qual build é mais recente.
Os resultados do mais recente build terá precendentes de builds mais velhos.
Por exemplo, se você marcar um teste como "falha" no Build 1 e marcá-lo como "passou" no Build
2, seu último resultado será “passou”.
2) Se um caso de teste é executado múltiplas vezes, sobre o mesmo build, a execução mais recente
terá precedência. Por exemplo, se Build 3 é liberado para a sua equipe e o testador 1 marca como
"passou" 2 horas da tarde e o testador 2 marca como "falha" 3 horas da tarde, ele aparecerá como
“falhou”.
3) Casos de testes classificados como "não executados" contra um build não são tidos em conta. Por
exemplo, se você marca um caso como "passou" no Build1e não executá-lo em Build 2, o último
resultado será considerado como "passou".
As tabelas a seguir são exibidas:
Resultados de nível superior em testes de suites
A lista dos resultados de cada nível superior suite. Total de casos, passou, falhou, bloqueados, não
executados e o percentual completo. Um caso de teste "completo" é um processo que tem sido
marcado como passou, falhou ou bloqueado. Resultados de nível superior de suites incluem todas as
suítes mais novas.
Resultados por palavra-chave
Lista todas as palavras-chave que são atribuídas a processos no Plano de teste atual e os resultados
que lhes estão associados.
Resultados por proprietário
Lista cada proprietário que tem casos de testes atribuídos no atual Plano de Teste. Casos de testes
que não são atribuídos são tallied under the “unassigned” heading.
8.2 Visão geral do status do Build
Lista a execução de resultado para cada build. Para cada build, o total de casos de testes, total que
passou, % que passou, total que falhou, % que falhou, bloqueados, % bloqueados, não executados e
% de não executados são exibidos. Se um caso de teste foi executado duas vezes, no mesmo build, a
mais recente execução será tomada em conta.
8.3 Métricas da Query
Este relatório é constituído por um formulário de página de consulta e uma página de consulta de
resultados que contém os dados questionados.
Formulário da página de consulta:
O usuário é apresentado com uma página de consulta com quatro controles. Cada controle é definido
para um padrão o qual maximiza o número de casos de teste e builds que a consulta deverá be
performed against.
Alterando os controles, permite ao usuário filtrar os resultados e gerar relatórios específicos para
proprietário específico, palavra-chave, suite e combinações de build.
Palavra-chave - 0→1 palavras-chave podem ser selecionadas. Por padrão- nenhuma palavra-chave é
selecionada. Se uma palavra-chave não está selecionada, então todos os casos de teste serão
considerados independente das atribuições das palavras-chaves.
As palavras-chave são atribuídas na especificação de testes ou nas páginas de gerenciamento de
palavra-chave.
Palavras-chave, atribuídas aos casos de testes, abrangerão todos os planos de testes e abrangem a
todas as versões de um caso de teste. Se você está interessado no resultado de uma determinada
palavra-chave, então você deve alterar esse controle.
Proprietário: 0→1 proprietários podem ser selecionados. Por padrão, nenhum proprietário é
selecionado. Se um proprietário não é selecionado, então todos os casos de testes serão considerados
independentemente do proprietário assignado. Atualmente, não há nenhuma funcionalidade de
pesquisa de casos de testes para "não atribuído". A propriedade é atribuída através de execução de
"Atribuir Casos de Testes" e é feito em uma base per Plano de Teste. Se você estiver interessado no
trabalho realizado por um determinado testador, você deve alterar esse controle.
Nível superior de suite: 0→n nível superior de suites podem ser selecionados. Por padrão, todas as
suites são selecionadas.
Apenas suites, que são selecionadas, serão consultadas para resultar métricas. Se você estiver apenas
no intested dos resultados de uma determinada suite, você deve alterar esse controle.
Baseia - 1→n builds podem ser selecionados. Por padrão - todos os Builds são selecionados. Apenas
execuções realizadas em Builds que você selecionar serão tidos em conta quando se produzir
métricas. Por exemplo: se você quiser ver quantos casos de teste foram executados nos últimos 3
Builds, você altera este controle.
Palavra-chave, proprietário e nível superior de seleções de suite irão ditar o número de casos de teste
a partir do seu Plano de teste que são usados para calcular por suite e por métricas de planos de
testes. Por exemplo: se você seleciona proprietário = "Greg", palavra-chave = "Prioridade 1" e todos
os testes de suite disponíveis, apenas o casod de teste de Prioridade 1 atribuído a Greg serão
considerados. O "# Casos de Teste" totais que serão vistos no relatório serão influenciados por estes
3 controles.
Seleções de build irão influenciar se um processo considerado "passou", "falhou", "bloqueou" ou
"não foi executado“. Refira-se a "Resultado do último teste" de regras que aparecem acima.
Pressione o "enviar" para avançar com a consulta e exibir a página de saída.
Página do relatório de dados:
A página do relatório exibirá:
1 Os parâmetros utilizados para criar o relatório.
2 Totais de todo o plano de teste.
3 Uma discriminação dos totais por suite (soma/passou/falhou/bloqueados/não executados) e todas
as execuções realizadas nessa suite. Se um Caso de Teste foi executado mais de uma vez em
múltiplos Builds, serão exibidas todas as execuções que foram registradas contra os Builds
selecionados. Contudo, faça um resumo para que suite só inclua o "Resultado do último teste" para
os builds selecionados.
8.4 Relatórios de casos de testes bloqueados, com falha e não executados
Estes relatórios mostram todos os casos de testes bloqueados, com falha e não executados
atualmente. A lógica do "Resultadodo último teste" (o que é descrito acima em Métricas gerais dos
planos de teste) é novamente empregada para determinar se um Caso de Teste deve ser considerado
bloqueado, com falha ou não executado. Relatórios de casos de teste bloqueados ou com falha
exibirão os bugs associados se o usuário estiver usando uma abordagem de bug integrada no sistema
de monitoramento.
8.5 Relatório de Testes
Ver estatuto de cada casos de teste em cada Build. Se um Caso de Teste foi executado várias vezes
no mesmo Build, o resultado da mais recente execução será utilizado. É recomendado exportar este
relatório no formato Excel para facilitar a navegação se um grande conjunto de dados está sendo
usado.
8.6 Gráficos
Esta página de relatório requer que o navegador tenha um plugin flash. A lógica do "Resultado do
último teste" é usada para os quatro gráficos que você verá. Os gráficos estão animados para ajudar
o usuário visualizar as métricas do plano de teste atual.
Os quatro gráficos fornecidos são:
1. Gráfico de pie com a visão geral do que passou/falhou/bloqueou e não executado nos casos de
testes
2. Gráfico de barras com os resultados por palavra-chave.
3. Gráfico de barras com os resultados por proprietário.
4. Gráfico de barras com os resultados por nível superior de Suite.
As barras, no gráfico de barras, são coloridas para que o usuário possa identificar o número
aproximado dos casos que passaram, falharam, bloqueados e não executados.
Ele utiliza tecnologia flash fornecidas por http://www.maani.us apresentando os resultados em um
Formato gráfico.
8.7 Total de bugs para cada caso de teste
Esse relatório mostra cada caso de teste com todos os bugs associados a ele para todo o projeto. Este
relatório está disponível somente se o Sistema de Bug Tracking estiver conectado.
8.8 Requisitos baseados em relatório
Este relatório está disponível se os requisitos são permitidos para os atuais projetos de testes. O
relatório é gerado contra um documento de especificação de requisito escolhido de um menu de
combo box.
Há duas seções: métricas e resultados panorâmicos.
Estão disponíveis as seguintes estatísticas:
- Número total de requisitos.
- Requisitos dentro do TestLink.
- Requisitos abrangidos pelo caso de teste.
- Requisitos não abrangidos pelo caso de teste.
- Requisitos não cobertos ou não testados.
- Requisitos não testados.
Os requisitos estão divididos em quatro seções. Cada requisito é listado em conjunto com todos os
casos de testes relacionados (coloridos de acordo com o resulatdo do caso de teste):
- Requisitos aprovados.
- Requisitos com falha.
- Requisitos bloqueados.
- Requisitos não executados.
8.9 Como adicionar um novo relatório
Copie um dos atuais relatórios e modifique-o de acordo com a sua necessidade. Não se esqueça que
usamos modelos de renderização(<testlink_root>/gui/templates/<report_name>.tpl) e
lógica(<testlink_root>/lib/resultados/<report_name>.php). Recomendamos reutilizar as funções
existentes para colher dados para o relatório, ao invés de criar novas.
Editar <testlink_root>/lib/resultados/resultsNavigator.php para adicionar um link para o seu novo
relatório.
Existe um array que poderia ser facilmente melhorado. Você deve adicionar uma nova URL e
"nome da palavra-chave" do relatório.
Você pode modificar o estilo CSS de um relatório. Sugerimos criar novas classes, em vez de
modificar os atuais (para evitar alterações indesejadas em outras páginas).
Se você contribuir, seu(s) novo(s) relatório(s) através do nosso tracker, você pode encontrá-lo
também nas próximas versões... Caso contrário, corre o risco de que não irá trabalhar para a próxima
versão principal.
9 User Administration
9.1 Configurações da conta
Cada usuário do sistema será capaz de editar suas próprias informações através da Conta
configurações da janela (link “personal” na barra de menu).
O TestLink permite usuários, com direitos de administrador, de criar, editar e excluir usuários dentro
do sistema. No entanto, TestLink não permite que os administradores visualizem ou editem senhas
do usuário. Se os usuários esquecem suas senhas, há um link, na tela de login, que irá enviar suas
senhas utilizadas com base em seu nome de usuário e endereço de e-mail que entrou.
9.2 Permissões dos papéis
O TestLink é construído com 6 diferentes níveis de permissão padrões. Alterando esses direitos de
manipulação pelo link de administração do usuário que pode ser acessado pelo administrador. Estes
níveis de permissão são os seguintes:
• Guest: Um guest só tem permissão para visualizar casos de testes e métricas do projeto.
• Executor de teste: Um testador fora da empresa que só tem permissões para executar testes
atribuídos a eles. (Inicialmente em 1.0.4 - otester)
• Teste Designer: Um usuário pode funcionar completamente com especificação de testes e
requisitos.
• Analista de Testes: Um testador pode ver, criar, editar e excluir casos de testes, bem como
executá-los. Faltam testadores para as permissões de gerir planos de testes, gerir projetos de testes,
criar marcos ou ceder direitos. Inicialmente testador, testador sênior.
• Líder de teste: Um líder tem todas as permissões como um testador, mas também as capacidades
de ganho para gerir planos de testes, atribuir direitos, criar marcos e gerenciar palavras-chave.
• Admininstrator: Um administrador tem todas as possíveis permissões (líder plus com a
capacidade de gerenciar projetos de testes e usuários).
Nota:as necessidades de planos de testes são relacionadas com características de também atribuir um
Plano de Teste para estar disponível. Veja Atribuição de Plano de Teste.
Funções de usuário
Há papéis pré-definidos de usuários. O administrador tem a capacidade adequada de alterar os dados
dentro do TestLink. Cada usuário tem atribuído apenas um desses papéis.
Se você ver a tabela você verá linhas para cada um dos níveis de permissões(guest, testador, testador
sênior, líder, administrador). A segunda coluna contém todos os direitos dos diferentes níveis que
serão definidos abaixo. Estes níveis foram determinados como norma para o uso, mas eles podem
ser editados para definir novas funções (por um administrador experiente). A tabela do usuário
contém uma chave estrangeira que aponta para o nível de permissão adequado na tabela dos direitos.
Estudo de caso – restrições de acesso por default
Situação
Em nossa organização gostaríamos de restringir o acesso a projetos a menos que seja
especificamente concedidos. Temos, atualmente, cerca de 150 usuários com pouco mais de 90
diferentes projetos. Muitos dos usuários não são QA, mas são analistas de negócios e, em alguns
casos, os usuários finais fazem UAT. Desde já, posso dizer que todos os direitos são herdados com
base em como o usuário foi instalado. Mas nós não queremos um analista de negócios, que está
trabalhando em um único projeto, tenha acesso a todas as 90 soluções.
Solução
Definir esses usuários com o papel global <Sem direitos> e conceder um papel apropriado em um
projeto de teste ou na base de um plano de teste. Em const.inc.php você também pode definir o
papel padrão id para <sem direitos> (parâmetro $g_default_roleid). Você pode mudar também o
nome de um papel "Sem direitos" para algo mais educado.
9.3 Definições de direitos
Palavras-chave são utilizadas para a definição do papel de habilidades.
9.4 Atribuição de plano de testeOs usuários podem ver apenas os planos de testes atribuídos. Para ganhar permissões de Planos de testes um usuário líder ou administrador deve dar-lhes direitos através do link "Definir direitos de usuário/projeto" dentro de "Gerenciamento de Plano de teste". Todos os usuários do sistema, por padrão, não têm permissão para ver planos de testes recém-criados(exceto para a criação de Plano de testes que que podem ser criados por eles mesmos). As permissões de Planos de Testes Zero significa que os usuários não verão nenhum Plano de teste no combo box na tela principal.Existe uma tabela com os direitos do plano de teste(ou seja, onde os usuários poderão ver qual Plano de teste). Esta tabela é constituída de uma combinação de id de usuários e id de projeto. A página principal contém um código que verifica se o usuário efetuou login nas permissões adequadas (e, em seguida, mostra os projetos permitidos. Não é recomendado que este seja cortado.
10 Importação e exportação de dados
TestLink suporta diversas maneiras de compartilhar dados.
10.1 Importação e Exportação de palavras-chave
Exemplo de XML com palavras-chave:
10.2 Importação e exportação de projetos de testes
O usuário pode importar ou exportar projetos de testes incluindo a descrição do projeto, a
especificação de testes e palavras-chave. As próximas duas fotos mostram a árvore de menu com os
dados e os mesmos dados do arquivo XML.
10.3 Importação e exportação de testes de suites
Exemplo de XML – Teste de suite dentro de palavras-chave
Exemplo de XML – Teste de suíte com palavras-chave
10.4 Just one Caso de Teste
Exemplo de arquivo de XML:
10.5 Todos os casos de testes no teste de suite
10.6 Importação/Exportação de requisitos de software
10.7 Importando casos de testes para o Excel via XML
Criando arquivo XML para importação no TestLink
Etapa 1: Exportar um ou mais casos de testes do TestLink dentro de um arquivo XML.
Etapa 2: Abrir novo documento em branco spread sheet document file.
Etapa 3: Navegue através do menu Dados> XML> Importação e selecione o arquivo XML. Cria
estrutura adequada em Excel.
Etapa 4: Depois aparecerá uma caixa de diálogo perguntando "Onde você deseja colocar os dados?"
Etapa 5: Escolha uma opção "Escolher um XML existente da lista" com a primeira célula $A$1.
Etapa 6: Você será capaz de ver as seguintes colunas: nome, resumo, etapas e resultados esperados.
Etapa 7: Copie este arquivo em seus dados nesse sentido e salve o arquivo de dados em formato
XML (*.XML).
Etapa 8: Verifique se o arquivo XML pode ser aberto com a ajuda do internet explorer.
Importando arquivo XML no TestLink
Etapa 1: Entrar no TestLink > Selecione seu projeto na lista dropdown.
Etapa 2: Clique na Especificação > Criar Nova Suite > Escolha Suite > Clique em Importar casos
de testes.
Etapa 3: Navegue para o arquivo XML, apresente-o e você terá feita a importação.
Histórico de Revisão: