organização para realização de teste de softwaremaria/arqan/2011-1/cap7-vvt.pdf · ausência de...

Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / ©Ian Sommerville 2000 Slide 1Engenharia de Softawre 3º Edição / Roger PressmanEngenharia de Software 1º Edição / Ariadne Carvalho

Organização para Realização de Teste de Software

Quando o teste se inicia há um conflito de interesses:

• Desenvolvedores: interesse em demonstrar que o programa é isento de erros.

• Responsáveis pelos testes: interesse em mostrar que o programa tem erros.

Do ponto de vista psicológico:

• Análise, Projeto e Codificação de Software são tarefasconstrutivas

• Teste é tarefa destrutiva


� Objetivo: assegurar que o software • Cumpra as suas especificações e atenda às

necessidades dos usuários e clientes.

� Verificação:• “Estamos construindo certo o produto?”• O software deve está de acordo com a sua

especificação.

Verificação e Validação


� Validação:• “Estamos construindo o produto certo?”• O software deve atender às necessidades dos

usuários.

� Ocorrem em todo o ciclo de vida completo• Revisões de requisitos, revisões de design, testes de

código

Verificação e Validação


� Fatores de Qualidade Operacionais• Correção• Eficiência ou desempenho• Robustez• Confiabilidade• Usabilidade• Utilidade e validade

� Fatores de Qualidade de Revisão• Relacionados com a manutenção, evolução e avaliação do software

� Fatores de Qualidade de Transição• Relacionados com a instalação, reutilização e interação com outros

produtos

O que deve ser verificado e validado?


� Inspeções de software (V & V estática)• Análise da documentação e código fonte do

software• Pode ser auxiliado por ferramentas de depuração

� Testes de software (V & V dinâmica)• O programa ou um protótipo devem ser executados• Casos de testes deve ser elaborados: dados de

entrada e comportamento esperado.

Técnicas de V & V


V&V estática e dinâmica

Testes do programa

Inspeção de software

Especificação de requisitos

Projeto de alto nível

Especificação Formal

Projeto detalhado

Programas

Protótipo


Metas do processo de Verificação e Validação

• Função de software • O nível de confiança depende de quanto o software é para uma organização

•Expectativas de usuário • Usuários podem ter poucas expectativas em relação ao software

•Ambiente de mercado• verificar o momento exato de colocar o produto no mercado ( com ou sem depuração e teste do produto)


Planejamento deVerificação e Validação

• Um planejamento cuidadoso é necessário para obter o melhor das inspeções e dos testes e para controlar os custos do processo de verificação e validação.

• O planejando de V&V deve se iniciar no começo do processo de desenvolvimento


Planejamento deVerificação e Validação

Especificação de requisitos

Teste de unicidade e de módulo

Plano de teste de aceitação

Especificação de sistema

Projeto de sistema

Projeto detalhado

Operação Teste de aceitação

Teste de integraçãodo sistema

Teste de integração

do subsistema

Plano de teste de integração

de sistema

Plano de teste de integraçãode subsistema


� Características• Técnica preventiva – permite a V & V antes do software ser

codificado• Mais barata• Baseada na experiência do inspetor• Mais aplicada a fatores de revisão e transição• Pouco eficaz para fatores operacionais

� Aplicações mais comuns• Inspeção de programa fonte (estática e dinâmica)• Inspeção de documentos e modelos• Desenvolvimento Cleanroom

Inspeções de Software


Processo de Inspeções

Retrabalho

Introdução

Planejamento

Preparação individual

Reunião deinspeção

Acompanhamento


� Defeitos nos dados:• Todas as variáveis de programa são iniciadas antes de seus valores

serem utilizados?• Todas as constantes foram denominadas?• Existe alguma possibilidade de overflow de buffer ( limite de vetores)?

� Defeitos de controle:• Para cada condição condicional a condição está correta?• As declaração compostas estão corretamente entre parênteses?

� Defeitos de entrada e saída• Todas as variáveis de entrada são utilizadas?• Todas as variáveis de saída têm um valor designado antes de saírem?

Checagem de Inspeções


� Defeitos de interface• Todas as chamadas de funções e métodos têm o número

correto de parâmetros?• Os parâmetros estão em ordem corretas?

� Defeito de gerenciamento de armazenamento• Se o armazenamento dinâmico é utilizado, o espaço foi

alocado corretamente?• O espaço é explicitamente liberado, depois que não é mais

necessário?

Checagem de Inspeções


Teste de software

� É uma atividade crítica na garantia de qualidade de software;

� Quatro dimensões:• Estado do teste (“o momento”);• Técnica do teste (“como vou testar”);• Metas do testes (“o que tenho que testar”);• Onde será o teste (“ambiente do teste”);

14


• Projetar testes que descubram sistematicamente diferentes classes de erros e façam-no com uma quantidade de tempo e esforço mínimos.

• Se a atividade de teste for conduzida com sucesso, ela descobrirá erros no software.

• A atividade de teste não pode mostrar a ausência de bugs; ela só pode mostrar se defeitos de software estão presentes.

Objetivos da Atividade de Teste


• Se erros graves forem encontrados com regularidade ��a qualidade e a confiabilidade de software são suspeitas.

• Se erros facilmente corrigíveis forem encontrados �� a qualidade e a confiabilidade do software estão aceitáveis ou os testes são inadequados para revelar erros graves.

• Se não for encontrado erro �� a configuração de teste não foi suficientemente elaborada e erros estão escondidos no software.

Objetivos da Atividade de Teste


��

��

��

��

��

��

��

��

��

��

��

��

��

��


� Um teste próspero é um teste que descobre um ou mais erros

� Elaboração de casos de testes baseados na especificação funcional• Dados de entradas• Comportamento esperado

� Podem ser classificados• Quanto ao método: defeitos e estatísticos• Quanto ao escopo: unicidade, integração, sistema e aceitação

Teste de Programa


� Testes de defeitos• Tem por objetivo encontrar defeitos – inconsistências entre o

programa e a sua especificação.• Verifica a correção – conhecido também por testes de

correção• Normalmente realizados com protótipos funcionais

� Testes estatísticos• Utilizados para avaliar o desempenho e a confiabilidade –

checar como ele trabalha nas condições operacionais• Exemplos de medições:

» Número de falhas observadas» Tempos de resposta» Tempos de execução

Tipos de Testes – (Método)


Teste de Programa

• Estratégia de caixa preta.• Os testes são aplicados no software como todo.• Não requer conhecimento da estrutura interna do

software.• Requer ambiente muito semelhante ao da

produção.• Deves ser executada pelos usuários finais.

• Funcional• Usabilidade• SegurançaTeste de

Aceitação

• Estratégia de caixa preta.• Os testes são aplicados no software como todo.• Não requer conhecimento da estrutura interna do

software.• Requer ambiente muito semelhante ao da

produção.• Deves ser executada por um grupo de teste

independente.

• Funcionais• Não Funcionais

o Performanceo Instalaçãoo Recuperaçãoo Carga

Teste de sistema

Teste de Alto Nível

• Estratégia de caixa branca e caixa preta.• Testa integrações entre partes de software.• Requer conhecimento da arquitetura interna do

software.• Executada pelo desenvolvedor ou profissional de

teste.

• Interfaces• Dependência entre

ComponentesTeste de Integração

• Estratégia caixa branca e caixa preta.• Testar partes do software.• Requer conhecimento da estrutura interna.• Executada pelo desenvolvedor ou profissional de

teste.

• Estrutura Interna• Funcionalidade• Usabilidade• Segurança

Teste de Unidade

Teste de Baixo Nível

Características da Fase de ValidaçãoCategorias de Testes AplicadasFase de Validação


��Tipos de Unicidade


Tipos de Unicidade


� Concentra-se no projeto e na construção da arquitetura de software

� Conhecidos como testes em ponto grande

� Os componentes são integrados e o conjunto maior é testado –módulo e sub-sistemas.

� Quem faz: Geralmente o programador;

� O que é testado: A integração entre os módulos.

� Quando termina: Quando o programador verifica que a interligação entre os módulos se encontra bem definida.

Testes de Integração


� ��

� � �� !�� " � ��#Big-bang;" � ��#�$��% �" � ��#�&��" ��



� '�� ! ��

� (��)�� " ��*� ��+��,*��-" ��+��,*��-

� ��#�$��%



��

� �! �"

�

�#

��

��!

��"

� ��#�&��+��-Testes de Integração

� � .�� #��/��+��)�� .0��!��-�

� 1�� .0��0�� #��


� � ��#�$��% �" $��%&$�� .��*� #2�� *�%��" ��%& ��

� � ��#�&��" $��%&��

��" ��%&�3�� !��

��0��

4� �� 0� ��



� Verificar se as funções estão de acordo com a especificação e se todos os elementos do sistema combinam-se adequadamente

� '��%��(&5.��6

� )�*��+ ��&�� *� �� *��6

� '��% �&�� 6

� ��#��&&��7��

Teste de Sistema


� � 0�0��*�� /�� 8 ��0��

� 9��0��" $��:��#6" $��6" $��;�� ,6" $��9�� #��

Teste de Sistema


� Teste de Recuperação" < ��*�#��*�%��*��,��0�� 0��*��#�� !��

� Teste de Estresse" � *� ��#2�� *��=> �� 0��

" (��)��#2��0��#��?��@�

Teste de Sistema


� Teste de Desempenho" $��

" (�� A ��

� Teste de Segurança " $� ��0��*�� #�� *�� 0��

" ��0��*�� 0�0��*�%��

" 3��0�� 0��0��*�� #�� ,��

Teste de Sistema


� )�,�� &�0��6

� '��%��(&�� *� ��6

� )�*��+ ��&B� #2�� #�� 6

� '��% �&�� 0 ��

Teste de Aceitação


:�0�� *��#Teste de Aceitação


� � ��&" ��&< *�� #2�� 0�0��3��*�%�� 0�0��C�,� ��? ��

" -��&�< ��)�� #2�� *� ��*�%��3�� 0�0�� 0�0��

Teste de Aceitação


oferecem uma abordagem sistemática ao teste e um mecanismo que ajuda a garantira mais alta probabilidade de revelar erros nosoftware com uma quantidade mínima de tempo e esforço

Projeto de Casos de Teste


� Teste de Caixa Preta (teste funcional)� Teste de Caixa Branca (teste estrutural)

• Teste de Caminho Básico»Caminho Independente »Complexidade Ciclomática

• Teste de Estrutura de Controle»Teste de Condição»Teste de Fluxo de Dados»Teste de Laços

• Teste no contexto de OO

Projeto de Casos de Teste


��.��# ��/# ��0

Entradasque provocam comportamento anômalo

Ie

Oe

Sistema

Entrada de dados de teste

Saída dos resultados de teste

Saídas que revelam apresença de defeitos

� Problema

• Dificuldade em quantificar a atividade de teste: não se pode garantir que partes essenciais ou críticas do software foram executadas

• Dificuldade de automatização


� O programa é uma caixa preta cujo comportamento é determinado estudando-se as suas entradas e saídas.

� Os casos de testes são derivados da especificação funcional.

� A escolha dos dados de entrada podem ser feitas com várias técnicas:• Partição de domínio• Análise de valor limite

� Envolve dois passos principais:• Identificar as funções que o software deve realizar (especificação dos

requisitos)• Criar casos de teste capazes de checar se essas funções estão sendo

executadas corretamente

��.��# ��/# ��0


� 9�� ,��0��*�%�� *� �� 2��8��0�� .*�� #2��D��#��

� �!�� 0��6

� �!��#��*� ��6

� �!��2��0��*��0��

��/# ��#0


��/# ��#0

Código de componente

Saídas doteste

Dados de teste

testa Deriva


Teste de Caminho Básico

O método de caminho básico possibilita que o projetista do caso de teste derive uma medida de complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução.


Teste de Caminho Básico


7 8

4

5

6

3

1

2

119

10

.��%��1��.��

.��% 1��

2

3

4, 56

78

109

11

1


Técnicas no contexto OO

� Estrategicamente similar ao teste de sistemas convencionais, mas étaticamente diferente;

� Técnicas no contexto OO:• Unidade:

» Teste aleatório para classe;» Teste de partição no nível de classe.

• Integração:» Teste de várias classes;» Teste derivado dos modelos de comportamentos.

• Sistema:» Teste baseado em erro;» Teste baseado em cenário;» Teste da estrutura superficial e profunda.

44


.��%��%� (�� E�� *�� )� �� 0� #�,�� 0��0�� *�� *��*�%��

� ��0��" (��)�� 6

" 5��0��)�#�


� ��.��%��

� ��0��*��

� ;� F��A ' ��!��#�� G��0�)��#�*��!��

� 9��A �� 0��!��


� ��.��%��

� 7�� A �� !��#��

� 7��A ��

� 3��A ��0��2��+��-�


� ��.��%��

� ��0��A ��

� 7��A *� ��#��

organização para realização de teste de softwaremaria/arqan/2011-1/cap7-vvt.pdf · ausência de...

Documents