Opções para a geração do documento

Esta tabela permite ao usuário filtrar os casos de teste antes de serem visualizados. Se selecionado (marcado) os dados serão exibidos. Para alterar os dados apresentados, marque ou desmarque clicando no Filtro, e selecione o nível desejado na árvore de dados.

Cabeçalho do Documento: Os usuários podem filtrar informações no cabeçalho do documento. As informações do cabeçalho do documento incluem: Introdução, Escopo, Referências, Metodologia de Teste, e Limitações de Teste.

Corpo do Caso de Teste: Os usuários podem filtrar informações do corpo do Caso de Teste. As informações do corpo do Caso de Teste incluem: Resumo, Passos, Resultados Esperados, e Palavras-chave

Resumo do Caso de Teste: Os usuários podem filtrar informações do Resumo do Caso de Teste através do Título do Caso de Teste, no entanto, eles não podem filtrar informações do Resumo do Caso de Teste através do Corpo de um Caso de Teste. O resumo do Caso de Teste foi apenas parcialmente separado do corpo do Caso de Teste a fim de apoiar a visualização do Título com um breve resumo e a ausência de Passos, Resultados Esperados, e Palavras-chave. Se um usuário decidir ver o corpo do Caso de Teste, o Resumo do Caso de Teste será sempre incluído.

Tabela de Conteúdo: O TestLink insere uma lista com todos os títulos com seus links internos checados.

Formatos de Saída: Existem várias possibilidades: HTML, OpenOffice Writer, OpenOffice Calc, Excel, Word ou por E-mail (HTML).

"; // testPlan.html $TLS_hlp_testPlan = "

Plano de Teste

Geral

O Plano de Teste é uma abordagem sistemática ao teste de um sistema de software. Você pode organizar a atividade de teste com versões particulares do produto em tempo e resultados rastreáveis.

Execução do Teste

Esta é a seção onde os usuários podem executar os Casos de Teste (escrever os resultados dos testes) e imprimir a Suíte de Casos de Teste do Plano de Teste. Nesta seção os usuários podem acompanhar os resultados da sua execução dos Caso de Teste.

Gerenciamento do Plano de Teste

Esta seção, somente acessível aos líderes, permite que os usuários possam administrar os planos de teste. A administração de planos de teste envolve a criação/edição/exclusão de planos, acréscimo/edição /exclusão/atualização dos casos de teste dos planos, criando versões, bem como definindo quem pode ver qual plano.
Usuários com permissão de líder poderão também definir a prioridade/risco e a propriedade das suites de caso de teste (categorias) e criar marcos de teste.

Nota: É possível que os usuários não possam ver uma lista suspensa que contenha os planos de teste. Nesta situação, todos os links (exceto para os líderes ativos) serão desvinculados. Se você estiver nesta situação, contate a administração do TestLink para lhe conceder os direitos de projeto adequado ou criar um Plano de Teste para você.

"; // custom_fields.html $TLS_hlp_customFields = "

Campos Personalizados

Segue alguns fatos sobre a implementação de campos personalizados:

Campos personalizados são definidos para todo o sistema.
Campos personalizados são associados ao tipo do elemento (Suíte de Teste, Caso de Teste).
Campos personalizados podem ser associados a múltiplos Projetos de Teste.
A sequência em que os campos personalizados serão exibidos pode ser diferente para cada Projeto de Teste.
Campos personalizados podem ser inativados para um Projeto de Teste específico.
O número de Campos personalizados não é restrito.

A definição de um campo personalizado inclui os seguintes atributos:

Nome do Campo personalizado.
Capturar o nome da variável (ex: Este é o valor que é fornecido para a API lang_get(), ou exibido como se não for encontrado no arquivo de linguagem).
Tipo do Campo personalizado (string, numérico, float, enum, email).
Possibilidade de enumerar os valores (ex: RED|YELLOW|BLUE), aplicável a uma lista, lista de multiseleção e tipos de combo.
Utilize o caractere pipe ('|') para separar os possíveis valores para uma enumeração. Um dos possíveis valores pode ser uma string vazia.
Valor default: NÃO IMPLEMENTADO AINDA.
Tamanho Mínimo/máximo para o valor do campo personalizado (utilize 0 para desativar). (NÃO IMPLEMENTADO AINDA).
Utilizar uma expressão regular para validar a entrada do usuário (use ereg() syntax). (NÃO IMPLEMENTADO AINDA)
Todos os campos personalizados são salvos como VARCHAR(255) na base de dados.
Exibição na Especificação do Teste.
Habilitado na Especificação do Teste. O usuário pode alterar o valor durante a Especificação do Caso de Teste.
Exibição na Execução do Teste.
Habilitado na Execução do Teste. O usuário pode alterar o valor durante a Execução do Caso de Teste.
Exibição no Planejamento do Plano de Teste.
Habilitado no Planejamento do Plano de Teste. O usuário pode alterar o valor durante o planejamento do Plano de Teste (adicionar Casos de Teste ao Plano de Teste).
Disponível para o usuário escolher o tipo de campo.

"; // execMain.html $TLS_hlp_executeMain = "

Executar Casos de Teste

Permite aos usuários 'executar' os Casos de Teste. Execução propriamente dita é apenas a atribuição do resultado de um Caso de Teste (Passou, Com Falha ou Bloqueado) de uma compilação selecionada.

O acesso a um Bugtracking pode ser configurado. O usuário pode adicionar diretamente novos bugs e navegar pelos existentes. Consulte o manual de instalação para maiores detalhes.

"; //bug_add.html $TLS_hlp_btsIntegration = "

Adicionar Bugs ao Caso de Teste

(Somente se estiver configurado) O TestLink possui uma integração muito simples com os sistemas de Bugtracking, mas não é capaz de enviar um pedido de abertura de bug ao Bugtracking ou receber de volta o ID do Bug. A integração é feita utilizando um link para a página do Bugtracking, com as seguintes características:

Inserir novo Bug.
Exibição das informações do bug.

Processo para adicionar um novo bug

Passo 1: Utilize o link para abrir o Bugtracking e inserir um novo bug.
Passo 2: Anote o ID do Bug gerado pelo Bugtracking.
Passo 3: Escreva o ID do Bug no campo de entrada.
Passo 4: Clique no botão Adicionar Bug

Depois de fechar a página de Adição de Bug, os dados relevantes do bug serão exibidos na página de execução.

"; // execFilter.html $TLS_hlp_executeFilter = "

Configurações

Em Configurações é possível que você selecione o plano de teste, a build e a plataforma (se disponível) para ser executado.

Plano de Teste

Você pode escolher o Plano de Teste necessário. De acordo com o plano de teste escolhido, as apropriadas builds serão exibidas. Depois de escolher um plano de teste, os filtros serão reiniciados.

Plataformas

Se o recurso de plataformas é usado, você deve selecionar a plataforma apropriada antes da execução.

Execução do Build

Você pode escolher o Build em que deseja executar os Casos de Teste.

Filtros

Filtros proporcionam a oportunidade de influenciar ainda mais o conjunto de casos de teste mostrados. Através dos Filtros é possível diminuir o conjunto de Casos de Teste exibidos. Selecione os filtros desejados e clique no botão \"Aplicar\".

Os Filtros Avançados permitem que você especifique um conjunto de valores para filtros aplicáveis usando Ctrl + Clique dentro de cada ListBox.

Filtro de Palavra-chave

Você pode filtrar os Casos de Teste pelas Palavras-chave que foram atribuídas. Você pode escolher " . "múltiplas Palavras-chave utilizando Ctrl + Clique. Se você escolher mais de uma palavra-chave, você pode " . "decidir se somente serão exibidos os Casos de Teste que contém todas as Palavras-chave aselecionadas " . "(botão \"E\") ou pelo menos uma das Palavras-chave escolhidas (botão \"OU\").

Filtro de Prioridade

Você pode filtrar os Casos de Teste pela prioridade do Teste. A proridade do Teste é a \"importância do Caso de Teste\" " . "combinado com \"a urgência do Teste\" dentro do Plano de Teste atual.

Filtro de Usuário

Você pode filtrar os Casos de Teste que não estão atribuídos (\"Ninguém\") ou atribuídos a \"Alguém\". " . "Você também pode filtrar os Casos de Teste que são atribuídos a um testador específico. Se você escolheu um testador " . "específico, também existe a possibilidade de mostrar os Casos de Teste que estão por serem atribuídos " . "(Filtros avançados estão disponíveis).

Filtro de Resultado

Você pode filtrar os Casos de Teste pelos resultados (Filtros avançados estão disponíveis). Você pode filtrar por " . "resultado \"na build escolhida para a execução\", \"na última execução\", \"em TODAS as Builds\", " . "\"em QUALQUER build\" e \"em uma build específica\". Se \"uma build específica\" for escolhida, então você pode " . "especificar a build.

"; // newest_tcversions.html $TLS_hlp_planTcModified = "

Versões mais recentes do Caso de Teste

Todo o conjunto de Casos de Teste ligados ao Plano de Teste é analisado, e uma lista de Casos de Teste que têm uma versão mais recente é exibida (contra o conjunto atual do Plano de Teste).

"; // requirementsCoverage.html $TLS_hlp_requirementsCoverage = "

Cobertura de Requisitos

Este recurso permite mapear uma cobertura de usuário ou requisitos do sistema por Casos de Teste. Navegue através do link \"Especificar Requisitos\" na tela principal.

Especificação de Requisitos

Os Requisitos estão agrupados no documento 'Especificação de Requisitos' que está relacionado ao Projeto de Teste.
O TestLink ainda não suporta versões para a Especificação de Requisitos e também para os Requisitos. Assim, a versão do documento deve ser adicionada depois do Título da Especificação. O usuário pode adicionar uma descrição simples ou uma nota no campo Escopo.

Sobrescrever o contador de Requisitos serve para avaliar a cobertura dos requisitos no caso de nem todos os requisitos estarem adicionados ao TestLink.

O valor 0 significa que a contagem atual de requisitos é usado para métricas.

Ex: SRS inclui 200 requisitos, mas somente 50 são adicionados ao Plano de Teste. A cobertura de testes é de 25% (se todos estes requisitos forem testados).

Requisitos

Clique no título para criar uma Especificação de Requisitos. Você pode criar, editar, deletar ou importar requisitos para este documento. Cada Requisito tem título, escopo e status. O status deve ser \"Válido\" ou \"Não testado\". Requisitos não testados não são contabilizados para as métricas. Este parâmetro deve ser utilizado para características não implementadas e requisitos modelados incorretamente.

Você pode criar novos Casos de Teste para os requisitos utilizando multi ações para os requisitos ativos na tela de especificação de requisitos. Estes Casos de Teste são criados dentro da Suíte de Teste com nome definido na configuração (padrão é: $tlCfg->req_cfg->default_testsuite_name = \"Test suite created by Requirement - Auto\";). Título e Escopo são copiados destes Casos de Teste.

"; $TLS_hlp_req_coverage_table = "

Cobertura:

Um valor por ex. de \"40% (8/20)\" significa que 20 Casos de Teste devem ser criados para testar completamente este Requisito. 8 destes já foram criados e associados ao Requisito, com a cobertura de 40 %. "; // req_edit $TLS_hlp_req_edit = "

Links internos no Escopo:

Links internos servem ao propósito da criação de links a outros requisitos / especificações de requisitos com uma sintaxe especial. O comportamento dos Links internos pode ser alterado no arquivo de configuração.

Uso:
Link para Requisitos: [req]req_doc_id[/req]
Link para Especificação de Requisitos: [req_spec]req_spec_doc_id[/req_spec]

O Projeto de Teste do Requisito / Especificação de Requisitos, uma versão e uma âncora também podem ser especificados:
[req tproj=<tproj_prefix> anchor=<anchor_name> version=<version_number>]req_doc_id[/req]
Esta sintaxe também funciona para as especificações de requisito (atributos de versão não tem nenhum efeito).
Se você não especificar a versão do Requisito completo, todas as versões serão exibidas.

Log para mudanças:

Sempre que uma alteração é feita, o Testlink irá pedir uma mensagem de log. Esta mensagem de log serve como rastreabilidade. Se apenas o escopo do Requisito mudou, você pode decidir se deseja criar uma nova revisão ou não. Sempre que alguma coisa além do escopo é alterado, você é forçado a criar uma nova revisão.

"; // req_view $TLS_hlp_req_view = "

Links Diretos:

É fácil compartilhar este documento com outros, basta clicar no ícone do globo no topo deste documento para criar um link direto.

Ver Histórico:

Este recurso permite comparar revisões/versões de requisitos, se mais de uma revisão/versão de requisitos existir. A visão geral fornece uma mensagem de log para cada revisão/versão, um timestamp e autor da última alteração.

Cobertura:

Exibir todos os Casos de Teste associados para este Requisito.

Relações:

Relações de Requisitos são usados para relacionamentos de modelos entre os requisitos. Relações personalizadas e a opção de permitir relações entre os requisitos de diferentes projetos de teste podem ser configurados no arquivo de configuração. Se você definir a relação \"Requisito A é pai do Requisito B\", o Testlink irá definir a relação \"Requisito B é filho do Requisito A\" implicitamente.

"; // req_spec_edit $TLS_hlp_req_spec_edit = "

Links internos no Escopo:

"; // planAddTC_m1.tpl $TLS_hlp_planAddTC = "

Sobre 'Campos personalizados salvos'

Se você tiver definido e atribuído ao Projeto de Teste,
Campos Personalizados com:
'Exibição no desenho do Plano de Teste=true' e
'Habilitar no desenho do Plano de Teste=true'
você irá ver nesta página APENAS os Casos de Teste ligados ao Plano de Teste. "; // resultsByTesterPerBuild.tpl $TLS_hlp_results_by_tester_per_build_table = "Mais informações sobre os testadores
Se você clicar no nome do testador nesta tabela, você irá ter uma visão mais detalhada sobre todos os Casos de Teste atribuídos para esse usuário e o seu progresso de teste.

Nota:
Este relatório mostra os casos de teste, que são atribuídos a um usuário específico e foram executados com base em cada build ativo. Mesmo se um caso de teste foi executado por outro usuário que não o usuário atribuído, o caso de teste irá aparecer como executado pelo usuário atribuído. "; // xxx.html //$TLS_hlp_xxx = ""; // ----- END ------------------------------------------------------------------ ?>