1.
INTRODUÇÃO A TESTE DE SOFTWARE Adriana C. Nascimento Danilo Dias Luma da R. Seixas Yuko Mitsuya

2.
TESTE CONCEITO DE TESTE: “ Exame ou prova para avaliar uma capacidade ou aptidão de alguém, ou para determinar a qualidade, natureza ou comportamento de algo. ” (Fonte: Minidicionário da língua Portuguesa)

3.
TESTE DE SOFTWARE CONCEITO: “ É o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado ” . “ É uma das fases do processo de engenharia de software que visa atingir um nível superior da qualidade de software. ”

4.
TESTE DE SOFTWARE É parte de um tema mais amplo chamado Verificação e Validação (V&V), onde: Verificação - refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica, e; Validação - refere-se ao conjunto de atividades que garante que o software que foi construído atende às exigências do cliente.

5.
TESTE DE SOFTWARE Logo, “ Testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. ”

6.
TESTE DE SOFTWARE OBJETIVO: “ Revelar o número máximo de falhas dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos ” .

7.
TESTE DE SOFTWARE IMPORTÂNCIA: Economia: Quanto mais cedo um defeito for encontrado, mais barato é o custo da sua correção; Qualidade: Devem ser encarados como investimento em qualidade.

8.
TESTE DE SOFTWARE DEFEITO, ERRO, FALHAS

9.
TESTE DE SOFTWARE Elementos Essenciais <ul><li>Caso de Teste: </li></ul><ul><ul><li>Condição particular a ser testada; </li></ul></ul><ul><ul><li>Composta por valores de entrada, restrições, e resultado ou comportamento esperado. </li></ul></ul>

10.
TESTE DE SOFTWARE Elementos Essenciais <ul><li>Procedimento de Teste: </li></ul><ul><ul><li>Descrição dos passos necessários para executar um caso de teste, ou grupo de casos; </li></ul></ul>

11.
TESTE DE SOFTWARE Elementos Essenciais <ul><li>Critério de Teste: </li></ul><ul><ul><li>Selecionar e avaliar os casos de teste; </li></ul></ul><ul><ul><li>Estabelecer um nível elevado de confiança na correção do produto. </li></ul></ul>

12.
TESTE DE SOFTWARE Critérios de Teste <ul><li>Cobertura de Testes: </li></ul><ul><ul><li>Identificação de partes do programa que devem ser executadas para garantir a qualidade do software; </li></ul></ul><ul><ul><li>Indicar quando o mesmo foi suficientemente testado. </li></ul></ul>

13.
TESTE DE SOFTWARE Critérios de Teste <ul><li>Adequação de Casos de Teste: </li></ul><ul><ul><li>Verificar se um conjunto de casos de teste satisfaz aos requisitos de teste estabelecidos pelo critério; </li></ul></ul>

14.
TESTE DE SOFTWARE Critérios de Teste <ul><li>Geração de Casos de Teste: </li></ul><ul><ul><li>Quando o critério define regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido. </li></ul></ul>

15.
TIPOS DE TESTE <ul><ul><li>Os tipos de teste normalmente são definidos em função das características ou dimensões da qualidade que serão avaliadas no software. </li></ul></ul><ul><li> </li></ul><ul><ul><li>&quot;A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas&quot;.(NBR 13596) </li></ul></ul>

16.
TIPOS DE TESTE <ul><ul><li>O que são necessidades explícitas e implícitas? </li></ul></ul><ul><li> </li></ul><ul><ul><li> As explícitas são condições e objetivos propostos por aqueles que produzem o software. </li></ul></ul><ul><li> </li></ul><ul><ul><li>As implícitas são necessidades subjetivas dos usuários, devem permitir atingir metas como: efetividade, produtividade, segurança e etc. </li></ul></ul>

17.
TIPOS DE TESTE A ISO/IEC 9126 (NBR 13596) fornece um modelo que define 6 amplas categorias de características de qualidade, por sua vez, sub-divididas em sub-características. Característica Sub-características Funcionalidade: O conjunto de funções satisfaz as necessidades explicitas e implícitas para a finalidade a que se destina o produto? Adequação, acurácia, interoperabilidade, segurança de acesso e conformidade. Confiabilidade: O desempenho se mantém ao longo do tempo e em condições estabelecidas? Maturidade, tolerância a falhas e recuperabilidade. Usabilidade: É fácil utilizar o software? Inteligibilidade, apreensibilidade e operacionalidade. Eficiência: Os recursos e os tempos utilizados são compatíveis com o nível de desempenho requerido para o produto? Comportamento em relação ao tempo e comportamento em relação aos recursos Manutenibilidade: Há facilidade para correções, atualizações e alterações? Analisabilidade, modificabilidade, estabilidade e testabilidade. Portabilidade: É possível utilizar o produto em diversas plataformas com pequeno esforço de adaptação? Adaptabilidade, capacidade para ser instalado, capacidade para substituir e conformidade.

18.
TIPOS DE TESTE A escolha do tipo de teste dependerá do grau de importância de cada uma das características de qualidade que serão avaliadas no software. Os tipos de testes mais comuns segundo o Guide to the CSTE Common Body of Knowledge do QAI são: Tipos de testes Descrição Teste de Estresse Avalia o desempenho do sistema com um volume de acesso/trasações acima da média esperada em condições extremas de uso. Teste de Execução Avalia se o sistema atende os requisitos de performance (proficiência) com um volume de acesso/trasanções dentro do esperado. Teste Contigência Avalia se o sistema retorna a um status operacioal após uma falha. Teste de Operação Avalia se o sistema (aplicação, pessoal, procedimentos e manuais) pode ser executado corretamente em ambiente de pré-produção. Teste de Conformidade Avalia se o sistema foi desenvolvido em consônancia com os padões e metodologia estabelecidos no projeto. Teste de Segurança Avalia se o sistema foi desenvolvido em consonância com os padrões de segurança da organização. Teste de Regressão Avalia por meio do ré-teste se uma funcionalidade que estava funcionando ainda funciona após uma modificação no sistema. Teste de Integração Avalia se a interconexão entre as aplicações funciona corretamente.

19.
PROCESSO ESTRUTURA DE TESTE DE SOFTWARE <ul><li> </li></ul><ul><li> </li></ul><ul><ul><li>Um processo estruturado de software tem a finalidade de formalizar as fases, atividades, papéis, artefatos e responsabilidades necessárias para o planejamento e a execução dos testes sistematicamente. </li></ul></ul>

20.
PROCESSO ESTRUTURA DE TESTE DE SOFTWARE <ul><li> </li></ul><ul><li> </li></ul><ul><li> O ciclo de vida do TMAP é dividido em sete fases distintas, como podemos observar a seguir: </li></ul><ul><li> </li></ul><ul><ul><li>Planejamento: Nesta fase é realizada o planejamento e a definição geral da estratégia e planos de testes. </li></ul></ul><ul><li> </li></ul><ul><ul><li>Controle: Nesta fase são realizados o controle e a monitoração das atividades planejadas. </li></ul></ul><ul><li> </li></ul><ul><ul><li>Configuração e manutenção da infra-estrutura: Nesta fase é preparada e mantida a infra-estrutura(software e hardware) necessária para a plena realização dos testes. </li></ul></ul>

21.
PROCESSO ESTRUTURA DE TESTE DE SOFTWARE <ul><ul><li>Preparação: É realizado o refinamento da estratégia de testes e plano de testes criados na fase de planejamento. </li></ul></ul><ul><li> </li></ul><ul><ul><li>Especificação: Nesta fase é realizada a especificação dos casos de testes e demaisdocumentos. </li></ul></ul><ul><li> </li></ul><ul><ul><li>Execução: É realizada a execução dos testes, reporte do progresso e indicadores de qualidade. </li></ul></ul><ul><li> </li></ul><ul><ul><li>Conclusão: Fase do processo de testes é avaliada afim de promover as melhorias para os próximos projetos. </li></ul></ul>

22.
Níveis de Teste <ul><ul><li>As atividades de teste são normalmente divididas em níveis. </li></ul></ul><ul><ul><li>Define a fase do processo de desenvolvimento de software na qual os testes serão realizados. </li></ul></ul><ul><ul><ul><li>Teste de unidade </li></ul></ul></ul><ul><ul><ul><li>Teste de integração </li></ul></ul></ul><ul><ul><ul><li>Teste de sistema </li></ul></ul></ul><ul><ul><ul><li>Teste de aceitação </li></ul></ul></ul>9/29/2010

23.
Níveis de Teste Teste de Unidade 9/29/2010 <ul><ul><li>Objetiva explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeito de lógica e de implementação em cada módulo, separadamente. </li></ul></ul><ul><ul><li>Universo alvo são pequenos trechos de código. </li></ul></ul>

24.
Níveis de Teste Teste de Integração 9/29/2010 <ul><ul><li>Visa provocar falhas associadas às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto. </li></ul></ul><ul><ul><li>Integração entre os componentes do sistema (classes, módulos, sub-sistemas, etc). </li></ul></ul>

25.
Níveis de Teste Teste de Sistema 9/29/2010 <ul><ul><li>Avalia o software em busca de falhas por meio da utilização do mesmo, como se fosse um usuário final. </li></ul></ul><ul><ul><li>Verificação se o produto satisfaz os seus requisitos. </li></ul></ul>

26.
Níveis de Teste Teste de Aceitação 9/29/2010 <ul><ul><li>É feita uma simulação, por um grupo restrito de usuários, para a realização de operações de rotina do sistema de modo a verificar se o seu comportamento está de acordo com o solicitado. </li></ul></ul><ul><ul><li>Verifica se o sistema satisfaz os requisitos (funcionais e não funcionais), sob o ponto de vista do usuário final. </li></ul></ul>

27.
Modelo V 9/29/2010 <ul><ul><li>Planejamento e projeto devem ocorrer de cima para baixo. </li></ul></ul>

28.
Técnica de Teste de Software 9/29/2010 <ul><ul><li>Objetiva encontrar falhas no software. </li></ul></ul><ul><ul><li>São classificadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de teste. </li></ul></ul><ul><ul><li>Pode-se estabelecer uma estratégia de teste que contenple as vantagens e os aspectos complementares dessas técnicas. </li></ul></ul><ul><ul><ul><li>Técnica Estrutural </li></ul></ul></ul><ul><ul><ul><li>Técnica Funcional </li></ul></ul></ul>

29.
Técnica Estrutural 9/29/2010 <ul><ul><li>Também chamado teste caixa-branca </li></ul></ul><ul><ul><li>Técnica de teste que avalia o comportamento interno do componente de software. </li></ul></ul><ul><ul><li>Trabalha diretamente sobre o código fonte do componente de software e avalia: </li></ul></ul><ul><ul><ul><li>Teste condição; </li></ul></ul></ul><ul><ul><ul><li>Teste de fluxo de dados; </li></ul></ul></ul><ul><ul><ul><li>Teste de ciclos; e </li></ul></ul></ul><ul><ul><ul><li>Teste de caminhos lógicos. </li></ul></ul></ul>

30.
Técnica Estrutural 9/29/2010 <ul><ul><li>Os aspectos válidos dependem: </li></ul></ul><ul><ul><ul><li>Da complexidade </li></ul></ul></ul><ul><ul><ul><li>Da tecnologia </li></ul></ul></ul><ul><ul><li>É desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software. </li></ul></ul><ul><ul><li>Todas as variações de estruturas de condição são testadas. </li></ul></ul>

31.
Técnica Estrutural 9/29/2010 <ul><ul><li>Técnica recomendada para os níveis de Teste de Unidade e Teste de Integração. </li></ul></ul><ul><ul><li>A responsabilidade principal fica a cargo dos desenvolvedores do sistema. </li></ul></ul><ul><ul><li>Auxilia na redução de problemas existentes nas pequenas funções ou unidades que compõem o software. </li></ul></ul>

32.
Técnica Funcional 9/29/2010 <ul><ul><li>Também chamada de teste caixa-preta. </li></ul></ul><ul><ul><li>NÃO considera o comportamento interno do software. </li></ul></ul><ul><ul><li>Os dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado. </li></ul></ul>

33.
Técnica Funcional 9/29/2010 <ul><ul><li>O componete de software a ser testado pode ser um método, uma função interna, um programa, um componete, um conjunto de componentes ou mesmo uma funcionalidade. </li></ul></ul><ul><ul><li>É aplicável a todos os níveis de teste. </li></ul></ul>

34.
Critérios de teste Particionamento de classes de equivalência 9/29/2010 <ul><ul><li>Divide o domínio da entrada de um programa em classes de equivalência. A partir das quais os casos de teste são derivados </li></ul></ul><ul><ul><li>Minimiza o número de casos de teste de cada classe, pois em princípio todos os elementos de uma classe devem se comportar de maneira equivalente. </li></ul></ul><ul><ul><li>Classe equivalente representa um conjunto de estados válidos e inválidos para uma condição de entrada. </li></ul></ul>

35.
Critérios de teste Análise de Valor Limite 9/29/2010 <ul><ul><li>Erros tendem a ocorrer nos limites do domínio de entrada ao invés do centro. </li></ul></ul><ul><ul><li>Explorar os limites dos valores de cada classe de equivalência para preparar os casos de teste. </li></ul></ul>

36.
Critérios de teste Grafo de Causa-efeito 9/29/2010 <ul><ul><li>Verifica o efeito combinado de dados de entrada. </li></ul></ul><ul><ul><li>As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo. </li></ul></ul>

37.
Critérios de teste Grafo de Causa-efeito 9/29/2010 <ul><ul><li>Esse critério é baseado em quatro passos: </li></ul></ul><ul><ul><ul><li>Para cada módulo de causa e efeito são relacionados, atribuindo-se um identificador para cada um. </li></ul></ul></ul><ul><ul><ul><li>O grafo de causa-efeito é elaborado. </li></ul></ul></ul><ul><ul><ul><li>Transforma-se o grafo de causa-efeito numa tabela de decisão. </li></ul></ul></ul><ul><ul><ul><li>As regras da tabela são convertidas em casos de teste. </li></ul></ul></ul>