Instanciação do RUP para uso da metodologia de testes orientada por modelos da AGEDIS Sidney de Carvalho Nogueira Orientador: Augusto Sampaio.

Apresentação em tema: "Instanciação do RUP para uso da metodologia de testes orientada por modelos da AGEDIS Sidney de Carvalho Nogueira Orientador: Augusto Sampaio."— Transcrição da apresentação:

1 Instanciação do RUP para uso da metodologia de testes orientada por modelos da AGEDIS Sidney de Carvalho Nogueira Orientador: Augusto Sampaio

2 Roteiro  Teste de Software  Processo de Testes  Ferramentas de Teste Usuais  Métodos Formais e Testes  Testes dirigidos por modelos (TDM)  O trabalho e sua contribuição  Testes no RUP 2003  RUP modificado para TDM  Conclusões  Bibliografia

3 Teste de Software  Testes consomem de 30% a 70% do projeto.  Teste é “destrutivo” enquanto desenvolvimento é “construtivo”.  Processo de teste tem relação com ”controle de qualidade”.  Prova a existência dos erros e não a ausência deles.

4 Processo de Testes  Planejado e executado ao longo da vida do produto.  Verificar:  Requisitos corretamente implementados;  Iteração/integração dos componentes;  Correções/manutenções/melhoramentos não afetaram os itens anteriores.

5 Processo de Testes Etapas da construção do software vs Etapas do Teste

6 Processo de Testes  Diferentes estágios: unidade, integração, sistema, aceitação)  Diferentes abordagens: caixa preta/branca/translúcida  Diferentes tipos: funcional, performance, segurança, dados, estresse, interface, documentação, regressão, etc.  Plano dos teste deve responder: quando?, que tipo?, e como?; serão executados os testes.

7 Ferramentas de Teste (não geram casos de teste)  Várias categorias de ferramentas :  Planejamento e projeto de testes (ex: Rational TestManager)  Geração de massas de dados (ex: TestByte)  Teste de unidade (ex: Junit)  Verificação de assertivas (ex: JTest)  Testes de GUI (ex: WinRunner)  Testes de cobertura (ex: PureCoverage)  Inspeção e análise estática de código (ex: IntelliJ IDE)  Testes de carga e estresse (ex: Jmeter)  Testes de desempenho (ex: JProbe)

8 Métodos Formais e Testes  Métodos Formais (MF) - Modelagem matemática do software e sistemas de hardware  MF prova com precisão/consistência matemáticas propriedades do sistema (testes consistem basicamente em provar propriedades do sistema com relação à especificações/modelos )

9 Métodos Formais e Testes  Abordagem formal :  Maior custo  Especialização profissional  Pesquisas em crescente ascensão ex: FORTest (Formal Test).  Nova geração de ferramentas de testes : geração automática de testes e verificação de modelos

10 Testes Dirigidos por Modelo  Model Driven Test (MDT) ou Testes Dirigidos por Modelo (TDM)  Inserir automação (ferramentas) na derivação de casos a partir de modelos  Concentra mais esforço na geração do modelo comportamental  Iniciativa AGEDIS (Automated Generation and Execution of Test Suites for Distributed Component-based Software) :  3 anos de projeto (terminou em 2003)  IBM, Universidade de Oxford, Universidade de Joseph Fourier, France Telecom, etc.

11 Contribuição do artigo  Inicial – a idéia era definir processos de teste dirigidos por modelo  Depois – instanciação do RUP 2003 com alterações para TDM  Agora – instanciação do RUP 2003 com alterações para TDM com arquitetura de ferramentas da AGEDIS

12 Arquitetura AGEDIS

13  Modelagem em AML (UML AGEDIS) + IF (Intermediate Format) – ferramenta proprietária Objectering UML  Diretrivas de geração – estratégias e táticas de teste. Define:  Template para casos de teste;  Modelo de cobertura (cobertura de estados e transições);  Combinação dos parâmetros durante a geração dos testes.  Casos de teste abstratos descritos em XMLs – possuem seqüência de entradas e saídas esperadas

14 Arquitetura AGEDIS  Diretivas de execução – mapeamento de tipos abstratos do XML com a linguagem de programação (inicialmente Java) na qual serão escritos scripts automáticos  O traços de execução também são casos de teste – mesmo XML DTD dos casos de teste

15 Testes no RUP 2003

16 Teste do RUP 2003  Não existe o artefato plano de testes, no entanto vamos manter na proposta esse artefato  Documento das idéias de teste mantido pelo analista de testes  Surge o papel do gerente de testes : acessar e advogar a qualidade dos testes  Aglutinação dos procedimentos de teste com os dados dos testes – test suite

17 Metodologia MDT 1. Construir o modelo comportamental formal 2. Simular e debugar o modelo usando o simulador 3. Construir diretivas geradoras de testes 4. Gerar os grupos de teste 5. Criar interfaces de teste 6. Executar os grupos de teste 7. Analisar os resultados dos testes 8. Se a qualidade obtida é insuficiente, ou defeitos precisam ser analisados então, é são construídas novas diretrizes de geração e volta para o passo 4.

18 RUP modificado para TDM  Aplicação da metodologia de maneira incremental ao longo do ciclo de vida do software.  Atividades da metodologia acontecem num grau de intensidade e freqüência diferentes ao longo de cada etapa da vida do software.  Adaptação de alguns artefatos do RUP por outros utilizados pelas ferramentas AGEDIS

19 Artefatos RUP vs AGEDIS Artefato RUPArtefato AGEDISPapel Relacionado Documento de Requisitos, Modelo de Analise e Modelo de Projeto Modelo comportamentalAnalista de sistemas e desenvolvedor Procedimento de Teste, Documento de Casos de Teste, Entradas dos Testes Teste AbstratoProjetista de testes (test designer) Suíte de testesSuíte de teste abstrataProjetista de testes Documento de Estratégia de Teste Diretivas de geraçãoProjetista de testes Scripts AutomáticosTestes abstratos e diretivas de execução Projetista de teste e desenvolvedor Log de testeTraces de execuçãoTestador (Tester)

20 Construir o modelo comportamental formal  Construído ainda na concepção, mesmo sem haver implementação  Na concepção : apenas propriedades alto nível do sistema (estímulos e respostas ao sistema), valida comportamento de caso de uso de alta complexidade  Na elaboração e construção : diagramas estruturais do sistema são “refinadas” e modelagem formal passa a detalhar estados internos do sistema  Priorizados os casos de uso a serem modelados formalmente, decididos pelos de maior risco e necessidade de confiabilidade

21 Construir o modelo comportamental formal  Modelagem formal da AGEDIS é contituida de diagramas de classe e diagramas de estado (para cada componente).  IF é utilizada como linguagem de ação para o diagrama de estados.  Usando os modelos de análise modelos são aplicados aos métodos e atributos da classe estereótipos específicos utilizadas para gerar teste : > e >.  > é usado para os métodos e atributos que se quer interagir com estímulo (sinal ou entrada)  > usado nos métodos e atributos que ser quer observar o valor de resposta produzido pelo sistema (ou saída).

22 Simular e depurar o modelo usando o simulador  Antes de gerar testes é possível simular animar o modelo fornecendo entradas e verificando as saídas  Realizado em todas fases do desenvolvimento  Simulador e depurar o modelo para corrigir erros do modelo  Usado para facilitar o entendimento da modelagem, principalmente para os que não conheçam métodos formais

23 Construir diretivas geradoras de testes  Baseado no plano de testes, na estratégia do teste e nas idéias de teste é são geradas as primeiras diretivas  Diretivas são ajustadas com feedback da geração (quantidade e qualidade) e execução dos testes  Diretivas em acordo com os objetivos do teste para a iteração corrente  Mudança somente realizadas após estudo do impacto na qualidade

24 Gerar os grupos de teste  Novos testes são gerados em grande quantidade a cada combinação de modelo e diretivas de geração – alguns repetidos outros novos  Projetista e analista de testes decidem quais testes gerados são mais úteis baseados no sumário de avaliação dos testes (defeitos escapados, cobertura dos requisitos alcançada, etc)  Testes aceitos (aprovados e executados) não devem ser descartados  Geração automática vai sugerir novos testes e não determinar quais os testes que devem ser executados  Teste abstratos podem ou não ter execução automática

25 Criar interfaces de teste  Decididos quais testes serão executados automaticamente, são geradas as interfaces de teste  Geralmente os teste de regressão são os candidatos potenciais de serem automatizados pois serão re-executados com freqüência  O desenvolvedor irá criar as interfaces de teste e todo código relacionado a automação da execução

26 Executar os grupos de teste e Analisar os resultados  Execução dos testes e analise dos resultados vai dar entrada para ajuste no modelo e diretivas  Parte será executada manualmente e outra automaticamente  Casos de teste podem ser aglutinado para apanhar mais defeitos com menos testes  Os critérios

27 Conclusões  O RUP pode suportar de maneira natural a metodologia MDT - poucas adaptações  Há muito o que evoluir nas ferramentas MDT para que sejam usadas comercialmente, ausência de processos apropriados também é critica  Uso da metodologia justificado em sistemas onde requisitos não funcionais como alta confiabilidade são exigidos  Uso comedido da metodologia : artefatos gerados automaticamente não devem substituir os artefatos de teste habituais

28 Conclusões  Esforço transferido da criação dos testes para criação do modelo e manipulação da ferramentas para criar testes  Geração automática vs Execução manual andam juntas

29 Bibliografia  [Whi00] William E. Lewis, Software Testing and Continuous Quality Improvement, Auerbach, pags. 3 a 18, 2000.  [Tret] Jan Tretmans and Axel Belinfante, Automatic Testing with Formal Methods  [Phi00] Philippe Kruchten, The Rational Unified Process An Introduction, Second Edition, Addison-Wesley, pags. 193 a 205, 2000.

30 Bibliografia  [Brian.B.Majdi] Model Driven Testing, DNA Enterprises, Inc. By: Brian Berger, Majdi Abuelbassal  [Hartman.A.Nag.Ken] Alan Hartman and Kenneth Nagin, Model Driven Testing, AGEDIS Architecture Interfaces and Tools, IBM Haifa Research Laboratory.  [Joh.T.Ales.C.02] Johannes Trost, Alessandra Cavarra, AGEDIS Modeling Language (AML) Tutorial, AGEDIS 2002, Deliverable D9.1.1.