A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software com o RUP - Workflow de Testes Parte I Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro.

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software com o RUP - Workflow de Testes Parte I Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro."— Transcrição da apresentação:

1 Engenharia de Software com o RUP - Workflow de Testes Parte I Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro de Informática Universidade Federal de Pernambuco

2 Objetivos: n Entender os conceitos básicos do workflow de Testes n Entender como ler e interpretar os artefatos gerados por este workflow

3 Tópicos Cobertos n Motivação n Introdução n Objetivo dos Testes n Abordagens de Testes n Estratégia de Testes n Estágios de Teste n Ferramentas de Teste n Responsabilidades sobre a Execução dos Testes n Teste x Depuração n Abordagens para a Depuração

4 Motivação n Existe grande possibilidade de injeção de falhas humanas no processo de desenvolvimento de software; n A atividade de teste faz parte da garantia de qualidade de software (SQA); n Os custos associados às falhas de software justificam uma atividade de teste cuidadosa e bem planejada.

5 Introdução n A atividade de testes pode ser vista como “destrutiva” ao invés do desenvolvimento que é “construtivo”; n O engenheiro de software tenta elaborar casos de teste que têm a intenção de “demolir” o software (descobrir erros); n É impossível mostrar a ausência de erros.

6 Objetivo dos Testes n Produzir casos de teste que têm elevada probabilidade de revelar um erro ainda não descoberto com uma quantidade mínima de tempo e esforço; n Comparar o resultado dos testes com os resultados esperados a fim de produzir uma indicação da qualidade e da confiabilidade do software. n O objetivo pode ser alcançado de forma automática e/ou manual

7 Abordagens de Teste n Existem basicamente duas abordagens que podem ser aplicadas a diferentes tipos de teste: u Abordagem funcional (“caixa preta”) - os casos de teste são gerados a partir de uma análise dos relacionamentos entre os dados de entrada e saída, com base nos requisitos levantados com os usuários; u Abordagem estrutural (“caixa branca”) - os casos de teste são gerados a partir de uma análise dos caminhos lógicos possíveis de serem executados, de modo a conhecer o funcionamento interno dos componentes do software. No entanto, é impossível gerar casos de teste para todos os caminhos lógicos.

8 Estratégia de Teste n Descreve: u os passos a serem dados como parte da atividade de teste; u quando esses passos serão planejados e executados; u esforço, tempo e recursos exigidos. n Incorpora: u planejamento de testes; u projeto de casos de teste; u execução de teste; u coleta e avaliação de dados.

9 Estágios de Teste n Teste de unidades: componentes individuais são testados para assegurar que os mesmos operam de forma correta; n Teste de integração: a interface entre as unidades integradas é testada; n Teste de sistema: os elementos de software integrados com outros componentes (hardware, pessoas, etc.) são testados como um todo; n Teste de aceitação (homologação): o software é testado pelo usuário final.

10 Teste de Unidade n São testados: u A interface com a unidade para garantir que as informações fluem para dentro e para fora da mesma; u Estruturas de dados locais (digitação inconsistente ou imprópria, inicialização com valores default/outros valores, overflow/underflow e corretude dos tipos de dados); u Caminhos de controle importantes e de tratamento de erros dentro das fronteiras da unidade (“teste caixa branca”); u Condições de limite para garantir que a unidade opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento.

11 Teste de Unidade n O procedimento para teste de unidades pode ser: u top-down: as unidades são testadas a partir do topo da hierarquia. O teste usa software driver (aceita dados do caso de teste, ativa a unidade a ser testada e imprime dados relevantes) e stubs (substituem as unidades subordinadas simulando o acesso às suas interfaces); u bottom-up: as unidades são testadas a partir do nível mais básico da hierarquia. O teste usa software driver para ativar a unidade a ser testada. As unidades já testadas num nível inferior podem então ser usadas para testar uma unidade específica no nível superior.

12 Teste de Integração n Unidades testadas em separado não são garantidas de funcionarem em conjunto; n A integração deve ser de forma incremental, ou seja, o programa é construído e testado em pequenos segmentos.

13 Teste de Integração n Integração top-down: u As unidades são integradas movimentando-se de cima para baixo na hierarquia de controle, iniciando-se na unidade de controle principal. n Integração bottom-up: u As unidades são integradas movimentando-se de baixo para cima na hierarquia de controle.

14 Teste de Sistema n A integração dos componentes de software com o ambiente operacional é testada; n Tipos de teste: u Teste funcional - a funcionalidade geral do sistema é testada. u Teste de recuperação - o software é forçado a falhar de diversas maneiras para que seja verificado se a recuperação é adequada. A recuperação pode ser automática ou exigir intervenção humana; u Teste de segurança - tenta verificar se todos os mecanismos de proteção a acesso indevido estão funcionando satisfatoriamente;

15 Teste de Sistema n Tipos de Teste (cont.): u Teste de Estresse - o sistema é testado no seu limite (número de acessos/transações, sobrecarga da memória/disco); F Exemplo: pode-se desejar saber se um sistema de transações bancárias suporta uma carga de 100 transações por segundo ou se um sistema operacional pode manipular 200 terminais remotos. u Teste de Desempenho - tenta avaliar a performance do software (principalmente em software de tempo real); u Teste de Portabilidade - são testes que verificam o grau de portabilidade do software em diferentes ambientes de harware/software.

16 Teste de Aceitação (homologação) n Testes de “caixa preta”que demonstram a conformidade com os requisitos obtidos do cliente: u Requisitos funcionais; u Documentação; u etc.

17 Teste de Aceitação (homologação) n São realizados pelo usuário. Podem ser de dois tipos: u Testes alfa: feito pelo cliente nas instalações do desenvolvedor, que observa e registra erros e/ou problemas; u Testes beta: feito pelo cliente em suas próprias instalações, sem a supervisão do desenvolvedor. Os problemas detectados são então relatados para o desenvolvedor.

18 Ferramentas de Teste n Ferramentas de geração de massa de dados; n Ferramentas de teste de API; n Ferramentas de teste de GUI; n Ferramentas de teste de cobertura; n Ferramentas de teste de carga; n Ferramentas de detecção de deadlocks; n Ferramentas de teste de desempenho/detecção de gargalos

19 Estágio de Testes x Ferramentas n Teste de unidade/Teste de integração u Ferramenta de teste de API u Ferramenta de teste de cobertura n Teste de sistema u Ferramenta de teste de carga u Ferramenta de detecção de deadlocks u Ferramenta de geração de massa de dados u Ferramenta de teste de desempenho/gargalos n Teste de homologação u Geralmente é feito de forma manual, e eventualmente com o auxílio da ferramenta de teste de GUI

20 Responsabilidades sobre a Execução dos Testes n Grupo de Desenvolvimento: u Teste de unidades; u Teste de integração; u Correção de erros; u Assessoria ao grupo de teste. n Grupo de Independente de Teste: u Teste de sistema; u Elaboração de casos de teste; u Preparação de relatórios sobre a qualidade do software. n Usuário u Teste de aceitação

21 Teste x Depuração n Quando um caso de teste ou o uso revela um erro, a depuração é o processo que resulta na remoção do erro; n Muitas vezes a manifestação externa do erro não tem uma relação óbvia com a sua causa; n A remoção de um erro pode inserir outros erros.

22 Abordagens para a Depuração n Força bruta: u Exames de listagens de dump; u Exame de traços de run-time; u Inserção de instruções “WRITE”. n Backtracking: o programa é rastreado para traz a partir do local onde apareceu o erro; n Eliminação da causa: Os dados relacionados à uma provável causa do erro são gerados. Uma hipótese da causa é formulada e os dados são usados para provar ou refutar a hipótese; n Ajuda externa.


Carregar ppt "Engenharia de Software com o RUP - Workflow de Testes Parte I Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro."

Apresentações semelhantes


Anúncios Google