AvalSoft_06

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

AVALIAÇÃO DE SOFTWARE
Aula 6- Métodos Estruturados de Teste 
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Conteúdo Programático desta aula
O conceito de casos de teste
Como obter casos de testes pelos métodos da Caixa Preta.
Como refinar casos de testes
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Casos de testes
Testar o caminho de um programa ou verificar o cumprimento de um requisito específico.
 
Conjunto de entradas de teste, 
condições de execução
resultados esperados
Início
X=1
Y=2
Ler variável a;
Ler variável b;
C= c+1;
Imprimir c;
Programa A
Caso de teste
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Casos de testes
Os casos de teste constituem a base do design e do desenvolvimento dos Scripts de Teste. 
Cada caso de teste reflete um cenário. 
A "profundidade" do teste é proporcional ao número de casos de teste, gerando maior confiança no processo de teste e na qualidade do produto. 
A escala do esforço de teste é proporcional ao número de casos de teste, é possível estimar com mais precisão a duração dos estágios subsequentes do ciclo de teste. 
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Abordagens dos casos de testes
Os casos de teste são categorizados ou classificados pelo tipo ou requisito de teste ao qual estão associados:
Positivo: Demonstrar que o requisito foi atendido, 
Negativo: Reflete condições inaceitáveis, anormais ou inesperadas
Positivo
Negativo
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Abordagens dos casos de testes
Requisitos (teste de caixa preta)
Estrutura interna (teste de caixa Branca)
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Abordagens dos casos de testes
Os desafios de um processo de garantia de qualidade
Medir o grau de qualidade alcançado nos teste de software
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Abordagens dos casos de testes
É necessário buscar todas as alternativas possíveis e adiciona-las no processo de teste de software, de forma a refinar e ampliar o nível de cobertura. 
 
 
 
 
Através dos casos de teste é possível monitorar os avanços da qualidade de software, avaliando os históricos de cobertura dos testes nos sucessivos ciclos de interação do desenvolvimento do software
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Abordagens dos casos de testes
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Abordagens dos casos de testes
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Abordagens dos casos de testes
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos Caixa Preta para obtenção dos casos de Testes
Métodos de decomposição de requisitos
Métodos de Análise de Documentos
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos de decomposição de requisitos
Destacam-se os três tipos de cenários que podem estar contidos nos requisitos: 
 
Primário
Exceção
Alternativo 
 
 
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos de decomposição de requisitos
Cenário Primário – É a situação mais básica de compreensão de um requisito de software. Trata-se da representação de um cenário perfeito que será usada como linha mestra para o entendimento de outros cenários existentes.
.
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos de decomposição de requisitos
Cenário Alternativo - São variações possíveis dentro do cenário primário, isto é, os caminhos alternativos ou situações equivalentes que conduzirão ao mesmo objetivo.
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos de decomposição de requisitos
Cenário de Exceção - Trata-se de possíveis problemas e inconsistências que impedem a finalização de determinado requisito. São todas as condições impeditivas que podem ocorrer a qualquer requisito.
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos Caixa Branca para obtenção dos casos de Testes
Cobertura de linha de código
Cobertura de Caminhos
Cobertura de desvios condicionais
Cobertura de laços
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos Caixa Branca para obtenção dos casos de Testes
Cobertura de linha de código 
Forma mais simplificada de medição
Medidos pelo número de linhas que são “adicionais” sempre que determinado conjunto de casos de testes é executado
 O objetivo é conseguir alcançar 100% da execução do código-fonte
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Cobertura de caminhos 
Foca nos fluxos alternativos
Identifica um conjunto de casos de teste que possibilitem exercitar todos os possíveis caminhos de execução
Localizar falhas de iniciação de variáveis ou mesmo fluxos não previstos de processamento, que podem conduzir a erros de execução.
Métodos Caixa Branca para obtenção dos casos de Testes
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Principais Categorias de Teste de Validação
Cobertura de desvios condicionais
Detectar erros nas condições lógicas aplicadas no código-fonte. 
Os casos de teste são construídos de forma a permitir variação dos valores que determinam a execução dos diversos fluxos alternativos existentes no código-fonte. 
O desenho interno do software é o principal elemento para a modelagem dos casos de testes. 
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Principais Categorias de Teste de Validação
Cobertura de desvios condicionais
Cobertura de decisões - Avalia se todas as decisões existentes no código-fonte são exercitadas durante a execução dos testes de caixa branca. 
Cobertura de condições – Foca na expressão que representa a condução de desvio existente no código-fonte
Cobertura de Múltiplas Condições – Emprega o mesmo critério do tópico de cobertura de condições, diferenciando-se apenas pelo fato de que os casos de teste devem contemplar todas as múltiplas combinações possíveis.
 
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Cobertura de laços
Normalmente os erros encontrados em laços de programação são de falta de iniciação de variáveis, quando as variáveis sofrem iniciações contínuas ou quando um laço atinge seu limite de execução. 
Métodos Caixa Branca para obtenção dos casos de Testes
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Métodos Caixa Branca para obtenção dos casos de Testes
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Refinamento de Casos de Testes
Os refinamentos são técnicas que permitem aumentar a extensão de cobertura e ampliar os cenários que representam os casos de testes alternativos e de exceção.
Por partição de Equivalência
Valores-limites
Probabilidade de Erro
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Refinamento de Casos de Testes
Por partição de Equivalência
Este método divide o domínio de entrada de dados em classes, ou seja, grupos de valores.
 Cada classe representa um possível erro a ser identificado, o que irá evitar a redundância de casos de testes. 
Cada entrada deverá identificar um conjunto de valores válidos e inválidos. 
Deste conjunto deverão ser extraídos as classes e consequentemente os casos de teste.
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Refinamento de Casos de Testes
Valores-limites
Complementar à partição por equivalência;
Os valores-limite são os casos de testes de cada classe identificada. 
Métodos Estruturados de Teste - Aula
6
Avaliação de Software
Refinamento de Casos de Testes
Probabilidade de Erro
Baseado na intuição e experiência de testar condições que normalmente provocam erros. 
Essencial histórico de erros bem montado: 
Tabelas vazias ou nulas
Nenhuma ocorrência , ou seja, executamos a operação porém não existe informações a serem processadas;
Primeira execução, ou seja, o erro somente ocorre na primeira vez;
Valores brancos ou nulos;
Valores inválidos e negativos. 
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Exemplo de caso de teste
Caso de uso transferência Bancária
Cenário: Doc para terceiros
Passos:
Consultar o saldo de origem;
Consultar o saldo da conta de destino;
Consultar novamente o saldo da conta de origem, verificando se o saldo inicial menos o valor transferido é igual ao saldo atual;
Consultar o salda da conta de destino, verificando se o saldo acrescido do valor transferido é igual ao saldo atual.
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Exemplo de caso de teste
Caso de uso transferência Bancária
Cenário: Doc para terceiros
Possíveis casos de teste:
CT01 – Preenchimento dos campos obrigatórios na tela de transferência;
CT02 – Validação do CPF; 
CT03 – Conta destino inválida; 
CT04 – Transferência de valores negativos; 
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Explorando o tema
Não esqueça de consultar o material didático e a biblioteca virtual da Estácio!
Participe do fórum!
Métodos Estruturados de Teste - Aula 6
Avaliação de Software
Obrigada
 e até
 a próxima aula!
*
*
*
Nesta aula iremos compreender que não é possível conceber um processo de garantia de software sem integrá-lo ao ciclo de desenvolvimento de software. Iremos estudar que o processo de qualidade está decomposto em fases que se organizam em formato de “U” e que possuem uma relação de “um-para-um” entre suas atividades e as fases do processo de desenvolvimento de software. 
 
O objetivo deste processo é garantir que durante o ciclo de desenvolvimento do software seja produzido todos os produtos previstos na metodologia empregada e que o aplicativo que está sendo construído esteja adequado com os requisitos documentados. 
 
Desta forma iremos compreender que a qualidade do software só ocorre na medida em que existem os testes de verificação e validação. Nesta discussão iremos relacionar as etapas dos testes de verificação e de validação já estudados na aula 3, agora detalhadamente.
 
Iremos ainda identificar os principais problemas que derivam da implantação inadequada do processos de desenvolvimento de software e compreender o conceito de casos de teste, como obtê-los e refiná-los. 
*
*
*
*
*
*
Nós vimos nas aulas anteriores que os métodos de verificação utilizam técnicas de testes estáticos pra avaliar a qualidade dos documentos gerados durante todas as etapas do desenvolvimento do software. 
Porém para avaliarmos a qualidade de um sistema, os testes não podem ser estáticos precisam ser dinâmicos, pois devemos submeter o software a determinadas condições de uso de forma a avaliar se o comportamento está de acordo com o esperado. 
Desta forma torna-se necessário a utilização de uma forma sistémica de trabalho com o objetivo de identificar o maio número possível de situações de testes. Isto é possível através da utilização de algumas técnicas para auxiliar na identificação dos diversos cenários de teste. 
*
*
Os casos de teste refletem os requisitos que devem ser averiguados. A verificação pode ser realizada de forma variada e por profissionais distintos. Torna-se fundamental para o sucesso do projeto selecionar os requisitos mais importantes e adequados para o teste, pois
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Não tem como obtermos um software de qualidade sem a existência de um processo de desenvolvimento que assegure o comportamento do software comparando-o com requisitos funcionais estabelecidos no projeto. 
Os testes da caixa preta, já estudados na aula 4, são uma abordagem complementar aos testes de caixa branca, com a finalidade de identificar um conjunto de situações que serão empregadas em forma de testes para a identificação de erros.
É importante perceber que a variedade de cenários permitirá o maior conjunto de simulações que serão avaliadas e comparadas com os requisitos contratados, sendo então fundamental a utilização de métodos que permitam identificar o maior número de casos de testes, garantindo ampla variedade de cenários para a execução do sistema. 
*
*
*
*
*
*
*
*
*
*
*
*
, ou seja, todas as linhas serão exercitadas ao menos uma vez durante a execução dos testes.
*
*
*
*
*
*
Cobertura de decisões - Avalia se todas as decisões existentes no código-fonte são exercitadas durante a execução dos testes de caixa branca. Em cada IF...THEN...ELSE...ENDIF, ou comando similar encontramos fontes, terão casos de testes que assumirão valores verdadeiro ou falso, isso garante que toda decisão de processamento tenha seus possíveis caminhos exercitados adequadamente.
Cobertura de condições – Focaliza a expressão que representa a condução de desvio existente no código-fonte, levando em consideração apenas os comandos que executam desvios de processamento.
Por exemplo: uma condição de desvio do tipo:
 IF idade >= 18 and sexo=”M” then....
Os casos de teste deverão cobrir individualmente todas as condições possíveis. Neste caso precisaríamos de três casos de testes para atendermos a todos os cenários de execução possíveis:
Caso teste 1= [i=17, s=”M”]
Caso teste 2= [i=18, s=”F”]
Caso teste 3= [i=19, s=”F”]
 
Cobertura de Múltiplas Condições – Emprega o mesmo critério do tópico de cobertura de condições, diferenciando-se apenas pelo fato de que os casos de teste devem contemplar todas as múltiplas combinações possíveis.
 
*
*
Laços simples – não existe um limite de execução, podendo ser infinitamente processado. Para teste de laços simples os casos de testes são números, pois contemplam os testes com o controle de limitação do laço.
*
*
Laços simples – não existe um limite de execução, podendo ser infinitamente processado. Para teste de laços simples os casos de testes são números, pois contemplam os testes com o controle de limitação do 
Laços aninhados – são estruturas de laços montadas uma dentro da outra, criando uma verdadeira árvore logica de execução. Neste caso para evitar o elevado número de casos de testes, o que poderá inviabilizar os testes, deve-se iniciar os teste a partir do laço mais interno para o mais externo. 
Laços concatenados – são estruturas de laços sequencializados pela logica definida na estrutura do código-fonte. Caso os laços seja independentes entre si recomenda-se a utilização da técnica de laços simples. Caso sejam dependentes, recomenda-se a utilização da técnica de laços aninhados.
Laços não estruturados – conhecido como desvio “não condicional”, apresenta-se na forma do comando GOTO, os fontes que utilizam esse recurso invariavelmente são difíceis de entender e manter, propiciando a introdução de erros nas eventuais manutenções do código. Este tipo de laço revela uma má prática de programação e deve ser evitado.
*
*
*
*
*
*
*
*
*
*
*
*
*