GOTEST-Aula3-Automacao-Processo-Testes.pdf

MAIO 2009
MAIO 2009
Roberto Alves
Automatizando o
Processo de Testes
Automatizando o
Processo de Testes

Roteiro
• Apresentação
• A Disciplina
• Problemas da fase anterior
• Gerenciamento do processo de testes
• O paradigma Open Source vs Proprietário
• Tipos de ferramentas
• Ferramentas padrão(exercícios)
• Outras ferramentas
• Ferramentas Proprietárias
• Vantagens e desvantagens
• Atividade

Apresentação
• Quem sou eu ?
– Roberto Alves: Engenheiro de testes no
C.E.S.A.R (Centro de Estudos e Sistemas
Avançados do Recife) Professor em testes
na Gotest, e Fuctura Tecnologia, IBM
Certified Especialist – Software Quality.
• Quem são vocês?

Apresentação da Disciplina
• Metodologia:
– Foco prático
– Baseada em atividades e apresentações
• Avaliação:
– participação : 2 pontos
– Apresentação : 8 pontos
será avaliado na apresentação:
- organização
- migração da estratégia de teste
- apresentação do grupo
- justificativa da escolha das ferramentas

Atividade
• Encontre o maior número de problemas
que se pode ter ao utilizar o processo de
testes de forma “manual” , sem o auxílio de
ferramentas para gerência de processo e
controle de bugs, atividades e execuções.
• Dividir a turma em equipes.

Gerenciamento do Processo de Testes
• A gestão de testes é a parte principal de
um processo de testes. A gestão
é importante para o planejamento e
controle das atividades de um projeto de
teste.
• Se torna difícil manter grandes projetos
de testes.

O combate mundial:
SW open source x SW proprietário
• Qual usar?
Identificando Aspectos funcionais.
• Quando usar?
– O momento é de crise?
• Por que usar?
– Será que aquele é melhor?
• Vantagens e desvantagens de cada um.
– levantando pontos fortes e fracos.

Tipos de ferramentas
• Gestão de testes
– Ferramentas que automatizam o
gerenciamento dos testes(criação de casos
testes, execução, controle, analise e etc.)
• Gestão de bugs
– ferramentas que automatizam o ciclo de
vida de um bug.

• Controle/gerência da matriz de rastreabilidade
• Rastreabilidade:
– representação visual em forma de matriz
bidimensional onde é feito o relacionamento
entre os artefatos, marcando-se o quadrante das
linhas com as respectivas colunas visando o
correto relacionamento dos itens na matriz. Com
isso cria-se uma visão global de todo
ecossistema de modelos e artefatos do sistema
sendo desenvolvido.

Ferramentas Padrão
• Ferramentas que iremos utilizar como
padrão da disciplina:
gestão de testes : TESTLINK
gestão de bugs : MANTIS

Testlink
• Ferramenta open source web baseada no
Gerenciamento e Execução dos testes;
• Permite criar e gerenciar os casos de
testes, bem como organizá-los nos planos
de testes;
• O time de testes pode executar os CTs,
priorizá-los, associá-los para um
responsável e acompanhar o resultado
dinamicamente, gerando relatórios.

Adaptação ao processo
• Plano de Testes
– Seção de Estratégia deve estar alinhada
com a ferramenta TestLink
• Projeto de Testes
– Ferramenta disponibilza geração automática
do documento.
• Planilha de Resultados dos Testes
– A ferramenta disponibiliza relatórios para os
resultados dos testes.

• Na ferramenta TestLink
– É uma “boa prática” criar suites com o nome do
requisito/caso de uso para facilitar a rastreabilidade
– Para cada Caso de Teste
• Indicar no campo Summary as informações
sobre:
– Tipo de teste, objetivo, cenário, pré e pós-
condições ...
– As baselines devem ser cadastradas como
Builds na ferramenta TestLink
• Os SQAs avaliam o resultado final a partir dos
relatórios disponibilizados na ferramenta

• A ferramenta TestLink não contempla:
– Dependência entre casos de testes
– Não existe o campo de tempo de execução
– Não existe a matriz geral de rastreabilidade

Adaptação plano de testes
• Plano de Execução de Testes (PET) da
ferramenta TestLink
– Estará inserido na Estratégia de Testes
– Deve existir um PET para cada ciclo de testes
planejado
Deve estar alinhado com os PETs do ferramenta TestLink.

Ferramenta TestLink – Tela Inicial

Passo a passo
•
• 1
1º
º : Planejar Testes
: Planejar Testes
–
– Criar os Planos de Execu
Criar os Planos de Execuç
ção de Testes
ão de Testes
• 2º : Criar os CTs
• 3º : Preparando a Execução
• 4º : Executar Testes
• 5º : Exportar Resultados

Criar os PETs
PETs 
Projeto 
Plano de Execução de Testes 

Lista de PETs
Para cada ciclo previsto no Plano de Testes será criado um PET na ferramenta
TestLink.
No Plano de Testes deve ser indicado o mesmo nome para cada ciclo.

Detalhes de um PET
Informar a versão ou do plano de projeto
que contém o planejamento desde ciclo
(PET).

Passo a passo
• 1º : Planejar Testes
•
• 2
2º
º : Projetar Testes
: Projetar Testes
–
– Especificar os requisitos
Especificar os requisitos
–
– Criar casos de testes (
Criar casos de testes (CTs
CTs)
)
–
– Exportar TSTD
Exportar TSTD
• 3º : Preparando a TSTR

Criando Casos de Teste
Especificação
(projeto de testes)

Após vários casos de testes...
Total CTs da suite “mãe”
Total CTs da suite “filha”

Exportar Projeto de Testes
Projeto de
Projeto de
Testes
Testes

Passo a passo
• 2º : Projetar Testes
•
• 3
3º
º : Preparando a Execu
: Preparando a Execuç
ção
ão
–
– Adicionar
Adicionar CTs
CTs ao PET
ao PET
–
– Designar respons
Designar responsá
áveis
veis
–
– Indicar a snapshot ou
Indicar a snapshot ou baseline
baseline

Adicionar Casos de Teses ao PET
PET

Para cada suite de teste, indicar os CTs a serem executados para o ciclo
de testes conforme PET da ferramenta TestLink.
Indicar a versão do CT que entrará em execução (saber qual a versão
revisada).

Indicar quem vai executar o teste

Lista de Builds
No 1º acesso indica que não há builds para o PET.

Criando o label da Build
Deixar o build ativo e aberto
Indicar o nome da snapshot ou baseline onde os
testes serão executados.

Passo a passo
•
• 4
4º
º : Executar Testes
: Executar Testes

Clique no CT para
indicar o resultado
do mesmo na
build.

Ao clicar nas notas, é aberto um pop-up
com as informações indicadas no resultado.
É possível
anexar
arquivos.
Resultado após execução

Passo a passo
•
• 5
5º
º : Exportar Resultados
: Exportar Resultados

Relatórios de Testes
Selecione a opção do formato do relatório e depois clique no
relatório.
Automaticamente abrirá uma tela para salvar o resultado.

Para cada build vai existir uma coluna com os resultados.
Essas builds são do PET-G1, por isso para cada ciclo de
testes é necessário um PET novo.

Outras ferramentas
• Gestão de testes
rth http://www.rth-is-quality.com
TestMaster http://testmaster.sourceforge.net
Test Case Web http://tcw.sourceforge.net
Testopia http://www.mozilla.org/projects/test
opia

RTH
• RTH (Requisitos e Testes Hub) é um sistema open-source
que funciona como instrumento de gestão de testes,
também possui capacidade de gestão de requisitos e de
bug-tracking.
• Algumas funcionalidades:
- Interface gráfica mais intuitiva
- Capacidade de versionar mudanças em requisitos e
documentos anexos
- Visão dos requisitos como uma árvore hierarquizada
- Definição mais granular dos passos de um caso de teste
e das possíveis falhas
- Discussões(estilo fórum) em requisitos

TestMaster
• Ferramenta que apoia a gerenciamento
de casos de testes, bem como suas
execuções.
• Possui suporte a algumas automações
em aplicações web(testes de carga entre
outros).

Test case web
• Ferramenta desenvolvida em PHP e
SQL que dá suporte a gerência de casos
de teste.

Testopia
• Testopia é uma ferramenta de teste gestão
de testes , é extensão para o Bugzilla.
• É concebido para ser um instrumento
genérico para monitorar casos de teste,
permitindo a testagem para integrar os
bugs e os relatórios de casos de teste
executados e seus resultados.

Atividade
• Migrar o projeto de testes feito na
disciplina anterior para o testlink.
1,5h

Mantis
• O mantis é um gerenciador de erros
(bugtracker) desenvolvido e PHP e
trabalha com bando de dados MySQL e
PostgreSQL. Tem uma interface gráfica
voltada para web e é acessado através
de um browser qualquer.
• Automatiza o ciclo de vida de um bug.

Passo a Passo
Abrindo uma nova requisição de
mudança(bug) através do mantis.

Categories/Module
• Deverá ser selecionado uma das
categorias cadastradas previamente no
projeto.

Severity
• Deverá ser escolhida a severidade do BUG
– Not applicable
– Minor
– Normal
– Major
– Critical
– blocker

Normal
Um problema moderado que restringe, mas não impede, o usuário de realizar a
função desejada. O cliente provavelmente ignorará o problema ou encontrará um
caminho alternativo. Os problemas conhecidos com esta severidade podem ser
liberados em um produto somente se os riscos forem avaliados, documentados, e
aprovados pelo gerente de projeto.
Minor
Um problema menor que não impeça o usuário de realizar as funções desejadas. O
cliente pode ou não perceber o problema, e é improvável registrar uma queixa. A
percepção do cliente da qualidade de produto pode ser danificada se diversos
problemas como essa severidade forem evidentes. A correção destes problemas
pode ser adiada para um release seguinte sem justificação formal.
Trivial
Um problema transparente invisível ao cliente. A correção destes problemas pode
ser adiada para o próximo release sem justificação formal.

Blocker:
Um problema que impede a continuação dos trabalhos sobre o produto
até seja resolvido.
Critical
Um problema crítico que faz o produto do trabalho inadequado para o
uso e/ou ser incapaz prestar os serviços. Os problemas desta severidade resultam
geralmente na substituição ou no reparo de todos os produtos que contêm o artigo
defeituoso. Se o produto não ainda tiver sido enviado com o defeito, o defeito fará
com que o produto fique inadequado para a entrega até que esteja resolvido.
Major
Um problema sério que produza a perda intermitente das funcionalidades
ou degrade o desempenho. Os problemas desta severidade usualmente resultam
numa descontinuação da produção e distribuição do produto até que o problema
seja corrigido.

Priority
• Deverá ser escolhida a prioridade do BUG
– None
– Low
– Normal
– Hight
– Urgent
– immediate

Found in
• Deverá ser informado o LABEL do release onde o
problema foi encontrado.
Baselined in
Baselined in
 Campo não obrigatório, particular de cada projeto, ou
estratégia.

Assign To
• Todo BUG deve ser atribuído a alguém pra ser
solucinado seja para um desenvolvedor , ou até mesmo
para um gerente.
Target Version
Target Version
 Não necessário

Summary
• Título do problema encontrado
Description
Description
 Descrição detalhada do problema

Steps To Reproduce
• Informações para reproduzir o erro, se necessário.
CCB Comments
CCB Comments
 Não necessário(no momento)
Review Records
Review Records
 Não necessário(no momento)

Type
• Deverá ser escolhida tipo do BUG, usar
apenas os tipos:
– Software Defect
– Document Defect

Upload File
• Anexar arquivo a requisição, se necessário
View Status
View Status
 (x) private (restringe a visualização por projeto)
Report Stay
Report Stay
 [ ] Não necessário

Submit Report
• Clique no botão para submeter o Bug

Bug Status
• O estado dos BUGs são descritos
conforme as cores acima.

Outras ferramentas
• Gerência de bugs:
Scarab http://scarab.tigris.org
BugNET http://www.bugnetproject.com
TRAC http://trac.edgewall.org

Scarab
• Scarab é um sistema de monitoramento
de artefatos altamente personalizável.
• Scarab é construída utilizando tecnologia
Java Servlet para velocidade,
escalabilidade, capacidade de
manutenção e facilidade de instalação.

Bugnet
• BugNET é uma ferremaneta de
monitoramento e solução da gestão de
projetos construída usando ASP.NET.
• Diponibiliza :
– Notificações por e-mail
– Elaboração de relatórios por projeto e
configuração de campos e valores.
– Permite uma gestão eficiente de bugs,
característica pedidos, e outros temas para
projetos de qualquer escala.

Trac
• Sistema de monitoramento de bugs,
gerenciamento de projetos e wiki
intergrado.
• fornece uma interface para Subversion
(ou outros sistemas de controle de
versão).

Atividade
• Migrar bugs encontrados na disciplina
anterior para o mantis.
30min

Ferramenta sobre rastreabilidade
• Durante a criação de um projeto de
software que use metodologias como,
por exemplo, RUP e OpenUP, são
criados muitos artefatos como diagramas
e documentação. E nesta grande
quantidade de artefatos é necessário
saber quais têm relação entre si. Isso é
feito utilizando-se das matrizes de
rastreabilidade.

TRAMA
• Ferramenta desenvolvida em java que
automatiza a criação de matrizes de
rastreabilidade.
• Trabalha com foco em projetos, podendo
ser salvos e exportados.
• Permiti customização e criação de
plugins

Atividade
• Utilizando a ferrementa TRAMA crie uma
matriz de rastreabilidade dos seus teste
ligados com seus requisitos.
• Utilizando a ferrementa TRAMA crie uma
matriz de rastreabilidade dos seus bugs
ligados com seus Testes.

Ferramentas proprietárias
• Atividade:
pesquisar para cada tipo de ferramenta
mostrado(gestão de testes e Controle de
bug) ferramentas pagas que se igualam
ou superem as ferramentas mostradas,
identificar vantagens e desvantagens( no
mínimo 5 de cada).

Apresentação
• Migrar o projeto de testes para a
ferramenta que o grupo escolher. Fazer
no mínimo 3 ciclos de execução para
apresentação do relatório de testes.
Entregar antes da apresentação uma
cópia do Plano de Testes feito na
disciplina anterior.

GOTEST-Aula3-Automacao-Processo-Testes.pdf

Mais conteúdo relacionado

Semelhante a GOTEST-Aula3-Automacao-Processo-Testes.pdf

Mais de RodolphoCesar2

Último

GOTEST-Aula3-Automacao-Processo-Testes.pdf