Ferramenta WEB de Apoio ao planejamento e controle de teste de software Bruna Tatiane Bonecher Orientadora: 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.
Fundamentação Teórica 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.
Fundamentação Teórica Teste de software - Estágios Unidade Integração Sistema Aceitação Instalação Regressão
Fundamentação Teórica Processo de teste de software Ciclo de vida Planejamento Preparação Especificação Execução Entrega
Fundamentação Teórica OpenUP Código aberto Versão otimizada do RUP Disciplina de testes
Fundamentação Teórica Metodologia do CenPRA Treinamento; Processo de teste; Suporte para geração de documentos.
Fundamentação Teórica Padrão IEEE-829 Planejamento de teste plano de teste; Especificação de teste projeto de teste; casos de teste; procedimentos de teste.
Fundamentação Teórica 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.
Fundamentação Teórica Padrão IEEE-829
Fundamentação Teórica 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.
Desenvolvimento - Processo Definição do processo Fases por Bastos et al. (2007, p. 46 47) Planejamento Fases do processo proposto Planejamento Preparação Especificação Execução Execução Entrega Processo de testes Planejamento Execução
Desenvolvimento - Processo Definição do processo Planejamento dos testes Plano de teste Casos de teste Analista Criar plano de testes Criar casos de testes
Desenvolvimento - Processo Definição do processo Casos de teste Execução dos testes Testador Executar testes Registrar resultados Artefato de Resultados dos testes
Desenvolvimento - Especificação Caso de uso - Administração ud PCT02 - Administração Módulo administrativo UC02.01 Manter logins de acesso UC02.02 Manter os sistemas Administrador UC02.03 Manter classificação de erros UC2.04 Manter status
Desenvolvimento - Especificação Caso de uso - Operacional ud PCT01 - Operacional Módulo operacional UC01.01 Manter proj etos UC01.02 Manter plano de teste UC01.03 Manter casos de teste Analista UC01.04 Executar ativ idade pendente UC01.05 Efetuar login UC01.06 Gerar documentos do processo de teste Testador UC01.07 Registrar resultados da execução dos casos de teste
Desenvolvimento Especificação Modelagem Conceitual class Modelo conceitual Proj eto - descricao: String - sistema: Sistema Caso_teste_itens - esperado: String - passo: String pertence 1 * possui 1..* 1 Sistema - descricao: String Plano_teste - ambiente: Stirng - cliente: String - cronograma: String - data: Date - descricao: String - hrs_esforco: int - introducao: String - limitacoes: String - riscos: String gera Resultado_plano - data: Date - descricao: String possui 1 * 1 * 1 possui 1 tem * 1..* possui Caso_teste - data: Date - descricao: String - poscondicao: String - precondicao: String - uc: String Figura 1 possui * - descricao: String - nome: String -resp_planej 1 * contem 1 Pessoa - login: String - nome: String - senha: String * possui 1 1 * -resp_exec contem 1 referencia 1 * pertence 2 Pendencia - descricao: String referencia * tem 1 Status - descricao: String * 1..* Resultado_caso - data: Date - esforco: float - impacto: String - incidente: String possui * * possui Situacao - descricao: String 1 Classificacao_erro 1 - descricao: String 1 Grupo - descricao: String
Desenvolvimento - Implementação 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 XML com estrutura SQL
Desenvolvimento Implementação JSP com os eventos da tela
Operacionalidade da ferramenta Cadastrar projeto
Operacionalidade da ferramenta Cadastrar plano de teste
Operacionalidade da ferramenta Visualizar pendências;
Operacionalidade da ferramenta Cadastrar caso de teste
Operacionalidade da ferramenta Resultado da execução do plano
Desenvolvimento - Resultados Resultados e discussões Contribuições do OpenUP; Contribuições da metodologia do CenPRA; Papéis utilizados; Definição dos artefatos utilizados;
Desenvolvimento - Resultados 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 Contemplado no artefato Caso de teste. 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.
Desenvolvimento - Resultados Tabela comparativa entre os trabalhos correlatos e o trabalho desenvolvido Maraká (Dias Neto; Travassos, 2006) Diferenças Processo utilizado como referência; Usa linguagem PHP; Semelhanças 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;
Conclusão Extensões Reaproveitamento dos casos de teste; Múltipla edição do resultado de execução de um plano de teste; Versionamento dos artefatos.