Académique Documents
Professionnel Documents
Culture Documents
É 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 24
bloqueados.......................................................................................................................................
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.
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. 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
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.
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.
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
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).
4.1 Disponibilidade
Especificação de requisitos
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.
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
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
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.
Illustration 7: Frame for modifying content of test cases within Test Plan
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.
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
6.2 Navegação
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.
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 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
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
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.
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 teste
Os 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.
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.
Etapa 3: Navegue para o arquivo XML, apresente-o e você terá feita a importação.
Histórico de Revisão: