ferramenta web de apoio ao planejamento e controle de...

Ferramenta WEB de Apoio ao planejamento e controle de teste

de software

Bruna Tatiane BonecherOrientadora: Fabiane Barreto Vavassori Benitti

Roteiro de Apresentação

Introdução• Objetivo do trabalho

Fundamentação Teórica

Desenvolvimento do trabalho• Definição do processo

• Especificação

• Implementação

• Operacionalidade

• Resultados e discussões

Conclusão• Extensões

Introdução

• Atraso de cronograma dos projetos;

• Dificuldade pra localizar os casos de teste;

• Falta de padronização dos artefatos;

• Incerteza sobre o que está sendo testado;

• Solução: processo e automação das atividades e artefatos;

Objetivos

• Desenvolver uma ferramenta visando auxiliar no planejamento e controle dos testes de integração, sistema e regressão.

– Definir um processo de testes observando OpenUP, metodologia do CenPRA e real necessidade de uma empresa de desenvolvimento de software;

– Gerar artefatos baseados no padrão IEEE-829;

– Disponibilizar funcionalidades para automatizar as atividades do processo e geração dos artefatos.

Teste de software

• “Processo de executar um programa com o objetivo de encontrar erros.” (Myers)

• Riscos pro negócio e imagem da empresa;

• Software liberado com erros o prejuízo é exponencial;

• Processo de teste alinhado com o processo de desenvolvimento desde o início.


• Unidade

• Integração


Teste de software - Estágios

• Sistema

• Aceitação

• Instalação

• Regressão

Processo de teste de softwareCiclo de vida

• Planejamento

• Preparação


• Especificação

• Execução

• Entrega

OpenUP

• Código aberto

• Versão otimizada do RUP

• Disciplina de testes


Metodologia do CenPRA

• Treinamento;

• Processo de teste;

• Suporte para geração de documentos.


Padrão IEEE-829

• Planejamento de teste

– plano de teste;

• Especificação de teste

– projeto de teste;

– casos de teste;

– procedimentos de teste.


Padrão IEEE-829

• Relatório de teste:

– relatório de encaminhamento de itens de teste;

– relatório de incidente de teste;

– relatório de sumário de teste.


Padrão IEEE-829


Notação para modelagem de processos

• Villela, Travassos e Rocha (2004);

• Linguagem gráfica de fácil entendimento;


Desenvolvimento

• Definição do processo;

• Requisitos;

• Casos de uso;

• Modelagem conceitual / MER;

• Implementação da ferramenta.

Definição do processo

Desenvolvimento - Processo

Planejamento Execução

Processo de testes

Fases por Bastos et al. (2007, p. 46 – 47) Fases do processo proposto

Planejamento Planejamento

Preparação

Especificação

Execução Execução

Entrega



Plano de teste Casos de teste

Analista

Planejamento dos testes

Criar plano de testes Criar casos de

testes


Executar testes

Artefato de

Resultados dos

testes

Registrar

resultadosTestador

Execução dos testes

Casos de teste


Caso de uso - Administração

Desenvolvimento - Especificação

ud PCT02 - Administração

Módulo administrativo

Administrador

UC02.01 Manter

logins de acesso

UC02.02 Manter

os sistemas

UC02.03 Manter

classificação de

erros

UC2.04 Manter

status

Caso de uso - Operacional

Desenvolvimento - Especificação

ud PCT01 - Operacional

Módulo operacional

Analista

Testador

UC01.02 Manter

plano de teste

UC01.03 Manter

casos de teste

UC01.05 Efetuar

login

UC01.06 Gerar

documentos do

processo de teste

UC01.07 Registrar

resultados da

execução dos casos de

teste

UC01.01 Manter

projetos

UC01.04 Executar

ativ idade pendente

Desenvolvimento – Especificação – Modelagem Conceitualclass Modelo conceitual

Plano_teste

- ambiente: Stirng

- cliente: String

- cronograma: String

- data: Date

- descricao: String

- hrs_esforco: int

- introducao: String

- l imitacoes: String

- riscos: String

Caso_teste

- data: Date

- descricao: String

- poscondicao: String

- precondicao: String

- uc: String

Projeto

- descricao: String

- sistema: Sistema

Sistema

- descricao: String

Situacao

- descricao: String

Classificacao_erro

- descricao: String

Pendencia

- descricao: String

Pessoa

- login: String

- nome: String

- senha: String

Grupo

- descricao: String

Caso_teste_itens

- esperado: String

- passo: String

Resultado_plano

- data: Date

- descricao: String

Resultado_caso

- data: Date

- esforco: float

- impacto: String

- incidente: String

Figura

- descricao: String

- nome: String

Status

- descricao: String

1

possui

*

*possui

1

*

pertence

1

* possui 1

-resp_planej

*

contem1

1

referencia

2

1

tem

*

*

possui

1

-resp_exec

*

contem

1

*

pertence

11..*

possui

1

1..*

tem

1

*

gera

1

1..*

possui

1

*

possui

1

1

referencia

*

1

possui

*

Ferramentas utilizadas

• CodeCharge Studio 3.0

• Eclipse

• iReport (JasperReports)

• Enterprise Architect

Desenvolvimento - Implementação

Implementação

• Gerado o Modelo Entidade-Relacionamento;

• CodeCharge fez a geração dos XML com atributos e operações de inclusão/alteração/exclusão correspondente as tabelas;

• Geração dos jsp com interface das telas;

• Geração dos eventos(customizações);

• Implementação para integrar o jasperReports.

Desenvolvimento - Implementação

Desenvolvimento – Implementação – XML com estrutura SQL

Desenvolvimento – Implementação – JSP com os eventos da tela

• Cadastrar projeto

Operacionalidade da ferramenta

• Cadastrar plano de teste


• Visualizar pendências;


• Cadastrar caso de testeOperacionalidade da ferramenta

• Resultado da execução do plano


• Contribuições do OpenUP;

• Contribuições da metodologia do CenPRA;

• Papéis utilizados;

• Definição dos artefatos utilizados;

Desenvolvimento - Resultados

Resultados e discussões


Tabela comparativa de artefatos OpenUP, IEEE-829 e novo processo

Artefatos OpenUP Artefatos IEEE-829 Artefatos do novo processo

Não contempla Plano de teste Plano de teste

- Itens de caso de teste

Não contempla Especificação de Projeto teste Contemplado no artefato Plano de teste.

Caso de teste Especificação de Casos de teste Caso de teste

- Passos do caso de teste

Scripts de teste Especificação de Procedimento

teste

Contemplado no artefato Caso de teste.

Logs de teste Diário de teste Não contemplado no novo processo.

O registro das ocorrências de execução é feito

no artefato Resultados da execução.

Não contempla Relatório Incidente de teste Resultados da execução

- Resultado de cada caso de teste

Não contempla Relatório de sumário Não contemplado no novo processo. Pois as

atividades de teste de cada projeto podem ser

visualizadas nas Pendências do sistema.

Não contempla Relatório Encaminhamento de

Item de teste

Não contemplado no novo processo. O

encaminhamento é feito de forma informal.


Tabela comparativa entre os trabalhos correlatos e o trabalho desenvolvido

Diferenças Semelhanças

Maraká

(Dias Neto;

Travassos,

2006)

• Processo utilizado como

referência;

• Usa linguagem PHP;

• Ambiente WEB;

• Utiliza padrão IEEE-829;

• Sub-processos de

planejamento e execução;

TestCen

(Bianchini,

2004)

• Casos de teste gerados a partir

dos UC (importado de outra

ferramenta .xmi);

• Usa linguagem desktop Delphi;

• Utiliza o padrão IEEE-829;

Gteste

(Sander, 2002)

• Segue metodologia proposta pela

ISO;

• Ambiente Dataflex (DOS);

• Gera relatórios de plano de

teste e resultado dos testes;

Conclusão

• Estudo de processos;

• Levantamento de necessidades de uma empresa de desenvolvimento de software;

• Notação para especificar o processo;

• Levantamento de artefatos;

• Processo adotado na empresa bem como a ferramenta;

• Objetivos propostos atingidos;

Extensões

• Reaproveitamento dos casos de teste;

• Múltipla edição do resultado de execução de um plano de teste;

• Versionamento dos artefatos.

Conclusão

ferramenta web de apoio ao planejamento e controle de...

Documents