Buscar

revisaoav1[1]

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

*
TESTES DE SOFTWARE – REVISÃO AV1
Prof. ULISSES SPERLE GRAÇA
Rio de Janeiro, setembro de 2011
*
Por causa da inabilidade humana de realizar e de se comunicar com perfeição, o desenvolvimento é acompanhado de garantia de qualidade.
A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação.
*
A IMPORTÂNCIA DO TESTE
*
CUSTO DO REPARO
*
Custo
Estágio de
desenvolvimento
Requisitos
Codificação
Entrega
*
A IMPORTÂNCIA DO TESTE
Não é raro gastarmos entre 30 e 40% do esforço total do projeto no Teste de Software.
O Teste de Software para ambientes críticos pode custar de três a cinco vezes mais do que todos os outros passos de engenharia de software combinados.
*
*
*
*
Segundo Myers, é o processo de executar um programa ou sistema com a intenção de encontrar defeitos;
Segundo Pressman, o teste de software é um conjunto de atividades que podem ser planejadas com antecedência e executadas sistematicamente. 
*
DEFININDO O TESTE DE SOFTWARE
*
A atividade de teste é um passo do processo de Engenharia de Software que visa encontrar/corrigir erros ao longo do software que foi construído.
Testes podem ser usados para descobrir a presença de erros, mas não para mostrar a sua ausência.
Testes de software é o processo de executar o software de uma maneira controlada com o objetivo de descobrir dife-renças entre o comportamento previsto e o comportamento observado.
*
DEFININDO O TESTE DE SOFTWARE
*
Todas estratégias fornecem um modelo para o teste e têm basicamente as seguintes características:
 Para executar um teste eficaz, proceder a revisões técnicas eficazes. Fazendo isso, muitos erros serão eliminados antes do começo do teste.
O teste começa no nível do componente e progride em direção à integração do sistema computacional como um todo.
*
ESTRATÉGIAS DE TESTE
*
Todas estratégias fornecem um modelo para o teste e têm basicamente as seguintes características:
 Diferentes técnicas de teste são apropriadas para diferentes abordagens de engenharia de software e em diferentes momentos
 O teste é feito pelo desenvolvedor do software e (para grandes projetos) por um grupo independente de teste.
 O teste e a depuração são atividades diferentes, mas a depuração ocorre em consequência de um teste.
*
ESTRATÉGIAS DE TESTE
*
O PROCESSO DE TESTE
O processo de teste de software deve basear-se em uma metodologia aderente ao processo de desenvolvimento, com pessoal técnico qualificado, ambiente e ferramentas adequadas.
Esta metodologia de teste deve ser o documento básico para organizar a atividade de testar aplicações no contexto da empresa. Assim como o processo de desenvolvimento de software, teste de software também possui um ciclo de vida: 
*
*
O PROCESSO DE TESTE – Ciclo de Vida
Planejamento: Elaboração e revisão da Estratégia e do Plano de teste.
Preparação: Preparação do ambiente.
Procedimentos iniciais: Elaboração do documento com o acordo entre as partes envolvidas (usuários e técnicos)
Especificação: Elaboração e revisão dos casos de teste.
Execução: Execução dos testes planejados.
Entrega: conclusão do processo de testes com a entrega do sistema para o ambiente de produção.
*
*
O PROCESSO DE TESTE
Uma das estratégias de teste que é preferida pela maioria das equipes é a visão incremental do teste, começando com o teste das unidades individuais de programa, passando para os testes destinados a facilitar a integração de unidades e culminando com testes que usam o sistema concluído. 
*
*
O PROCESSO DE TESTE
Ao tratar os testes como um processo organizado e muitas vezes paralelo e integrado ao processo de desenvolvimento, os custos de manutenção serão reduzidos.
Segundo Myers, o custo de correção de defeitos tende a aumentar quanto mais tarde o defeito é detectado.
Defeitos encontrados durante a produção tendem a custar muito mais que defeitos encontrados em modelos de dados e em outros documentos do projeto do software.
*
*
O PROCESSO DE TESTE
Os testes unitários podem remover entre 30% e 50 % dos defeitos dos programas;
 Os testes de sistemas podem remover entre 30% e 50% dos defeitos remanescentes.
 Desse modo, os sistemas podem ir para produção ainda com aproximadamente 49% de defeitos.
 Por últimos, as revisões de códigos podem reduzir entre 20% e 30% desses defeitos.
*
*
 À medida que o trabalho da engenharia de software é desenvolvido, é normal que ocorram erros. É importante que estes erros sejam encontrados e corrigidos antes que sejam passados para os usuários finais.
Um dos métodos utilizados para a detecção destes erros logo no início do processo de desenvolvimento são as revisões de software.
Elas são aplicadas em várias etapas durante o processo de engenharia de software. 
*
REVISÕES DE SOFTWARE
*
Lembre-se: Errar é humano e, embora algumas pessoas captem bem alguns de seus erros, outros tantos escapam mais facilmente a quem lhe deu origem do que a outras pessoas.
Uma revisão – genericamente falando, é uma forma de usar a diversidade de um grupo de pessoas para: 
 
*
REVISÕES DE SOFTWARE
*
Apontar aperfeiçoamentos necessários no produto de uma única pessoa ou de uma equipe.
Confirmar aquelas partes de um produto em que aperfeiçoamentos são indispensáveis ou desnecessários.
Obter trabalho técnico de qualidade mais uniforme, ou pelo menos mais previsível, que possa ser alcançada sem revisões, de modo a tornar o trabalho técnico mais gerenciável.
*
REVISÕES DE SOFTWARE
*
Impacto dos defeitos de software nos custos
O benefício das revisões é a descoberta precoce dos defeitos de software, de forma que possam ser corrigidos antes do passo seguinte.
Ao detectar e suprimir estes erros, o processo de revisão reduz substancialmente o custo dos passos subsequentes.
*
REVISÕES TÉCNICAS
*
Uma RTF é uma atividade de garantia de qualidade de software executada por engenheiros de software e outros profissionais.
Cada RTF é realizada como um encontro e somente será bem sucedida se for adequadamente planejada, controlada e assessorada.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Objetivos:
Descobrir erros na função, lógica ou implementação
Verificar se o software atende aos requisitos
Garantir que o software foi representado de acordo com os padrões
Obter um software que seja desenvolvido uniformemente
Tornar os projetos mais gerenciáveis
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Fases principais:
Planejamento
Kick-off
Preparação individual
Reunião de revisão
Retrabalho
Acompanhamento
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Tipicamente uma reunião é programada para o dia seguinte ao da preparação, e conta com o produtor e os revisores.
Durante a RTF, um revisor registra ativamente todos os problemas levantados. Estes são sintetizados no final da reunião de revisão e é produzida uma lista de problemas de revisão, além do relatório sintetizado da revisão técnica formal. Normalmente o relatório sintetizado é um formulário de uma página, cujo anexo é a lista de problemas de revisão.
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
Ao final, os participantes devem decidir se:
 
Aceitam o produto sem modificações adicionais;
Rejeitam o produto devido a erros graves (uma vez corrigidos, outra revisão deve ser realizada);
Aceitam o produto provisoriamente (erros menores foram encontrados e devem ser corrigidos, sem revisão adicional).
*
REVISÕES TÉCNICAS FORMAIS (RTF)
*
*
TESTE NO PROGRAMA - DEPURAÇÃO
*
O processo de depuração frequentemente ocorre em consequência de um teste. Quando um caso de teste descobre um erro, a depuração será o processo que irá resultar na remoção deste erro.
 
O Processo de depuração tenta combinar o sintoma com a causa, levando assim à correção do erro. Normalmente apresentará um dentre dois resultados:
A causa será encontrada
e corrigida;
A causa não será encontrada;
*
TESTE NO PROGRAMA - DEPURAÇÃO
*
Um dos modelos existentes é o modelo genérico de depuração chamado de Hipóteses-Validação. O modelo define a atividade de depuração como um processo interativo de síntese, verificação e refinamento de hipótese.
*
ABORDAGENS DA DEPURAÇÃO
*
*
Inicie conjunto de hipóteses
Modifique conjunto de hipóteses
Selecione hipótese
Verifique hipótese
Corrigido?
Não
Sim
ABORDAGENS DA DEPURAÇÃO
*
Myers descreve basicamente três estratégias:
 Força bruta
Método mais comum e menos eficiente;
Usado quando os outros métodos falham;
Faz-se imensa quantidade de teste, mas sem planejamento.
*
ABORDAGENS DA DEPURAÇÃO
*
Rastreamento (backtracking)
 
A partir do local do sintoma descoberto, rastreia-se para trás até encontrar a causa;
Bastante comum, porém restrita a programas pequenos, pois o número de caminhos retroativos potenciais pode ser muito alto;
Em sistemas/programas médios/grandes é ineficiente;
*
ABORDAGENS DA DEPURAÇÃO
*
Eliminação da causa
 
Os dados relacionados à ocorrência de erros são organizados para isolar causas em potencial;
Uma “hipótese de causa” é imaginada e dados acima são usados para provar ou reprovar a hipótese;
Uma lista de todas as causas possíveis é desenvolvida e testes são realizados para eliminar cada uma.
*
ABORDAGENS DA DEPURAÇÃO
*
Segundo Van Vleck, três perguntas devem ser feitas antes de fazer a “correção” que remove a causa de um defeito:
 
 1. A causa do defeito é reproduzida em outra parte do programa?
 Em muitas situações, o defeito é provocado por um padrão de lógica errôneo que pode ser reproduzido em outro lugar.
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 2. Qual o próximo defeito que poderia ser introduzido pelo reparo que estou prestes a fazer?
 Se a correção tiver de ser feita em um módulo com alto acoplamento, deve-se tomar um cuidado especial.
*
CORREÇÃO DO ERRO
*
Questionamentos de Van Vlek:
 
 3. O que poderíamos ter feito para eliminar este defeito já no início?
 Se corrigirmos o processo, bem como o produto, o defeito pode ser eliminado de todos os programa futuros. 
*
CORREÇÃO DO ERRO
*
 Uma vez gerado o código-fonte, o software deve ser testado para descobrir (e corrigir) tantos erros quanto possível antes de fornecê-lo ao cliente.
O objetivo do teste é encontrar erros, e um bom teste é aquele que tem alta probabilidade de encontrar um erro. 
 Devemos projetar testes que tenham a mais alta probabilidade de descobrir a maioria dos erros com uma quantidade mínima de tempo e esforço.
*
TÉCNICAS DE TESTE DE SOFTWARE
*
Teste de caixa branca é uma abordagem de projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos de teste.
Baseia-se num minucioso exame dos detalhes procedimentais.
*
TESTE CAIXA BRANCA
*
Com este método nós podemos projetar casos de teste que:
Garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez;
Exercitem todas as decisões lógicas para valores falsos ou verdadeiros;
Executem todos os laços em suas fronteiras e dentro de seus limites operacionais;
Exercitem as estruturas de dados internas para garantir a sua validade.
*
TESTE CAIXA BRANCA
*
Tipos de Teste Caixa Branca:
Teste de Caminho Básico
Teste de Condição
Teste de Fluxo de Dados
Teste de Ciclo
*
TESTE CAIXA BRANCA
*
*
TESTE DO CAMINHO BÁSICO
Técnica de teste de caixa branca inicialmente proposta por Tom McCabe.
Permite ao projetista derivar uma medida da complexidade lógica de um projeto procedimental e usá-la para definir um conjunto básico de caminhos de execução;
Os casos de teste projetados para exercitarem este conjunto básico têm garantia de executar cada instrução do programa pelo menos uma vez durante a atividade de teste.
*
*
TESTE DO CAMINHO BÁSICO
Usando o projeto ou o código como base, desenhar o grafo de fluxo correspondente;
Determinar a complexidade ciclomática do diagrama de fluxo resultante.
Determinar um conjunto base de caminhos linearmente independentes. 
Preparar casos de teste que vão forçar a execução de cada caminho do conjunto base.
*
*
TESTE DE CICLO (LAÇOS)
Técnica que concentra na validade das construções de laços.
Laços Simples: deve ser aplicado o seguinte conjunto de teste:
 	
Pule o laço inteiramente;
Somente uma passagem através do laço;
Duas passagens através do laço;
m passagens através do laço, onde m < n;
n-1, n, n+1 passagens através do laço.
*
*
TESTE DE CICLO (LAÇOS)
Laços Aninhados:
Inicie pelo laço mais interno. Fixe os outros laços para valores mínimos.
Realize testes de laços simples para o laço mais interno.
Trabalhe para fora, realizando testes para o laço seguinte, mas mantendo todos os ciclos externos nos valores mínimos
Continue até que todos os laços tenham sido testados. 
*
*
Laços Concatenados: 
1. Se laços independentes dos demais:
  usar abordagem de laços simples.
2. Se contador de laços para o laço 1 for usado como valor inicial para o laço 2:
  usar abordagem de laços aninhados. 
TESTE DE CICLO (LAÇOS)
*
*
Laços não estruturados:
Sempre que possível, esta classe deve ser reprojetada para refletir o uso das construções de programação estruturada. 
TESTE DE CICLO (LAÇOS)
*
*
TESTE CAIXA PRETA
 Foco: requisitos funcionais do software
Possibilita a derivação de conjuntos de condições de entrada que exercitem todos os requisitos funcionais para um programa.
O Teste de Caixa Preta desconsidera a estrutura de controle.
A atenção é voltada ao domínio da informação.
*
*
O Teste de Caixa Preta não é uma alternativa às técnicas Caixa Branca, mas ao contrário, é uma abordagem complementar, que mais provavelmente descobrirá uma classe diferente de erros.
TESTE CAIXA PRETA
*
São realizados para responder as seguintes perguntas:
Como a validade funcional é testada?
Como o comportamento e o desempenho é testado?
Que classes de entrada farão bons casos de teste?
O sistema é particularmente sensível a certos valores?
Como as fronteiras de uma classe de dados é isolada?
Que taxas e volumes de dados o sistema pode tolerar?
Que efeito combinações específicas de dados terão sobre a operação do sistema?
*
TESTE CAIXA PRETA
*
Desta forma o teste de caixa preta tenta encontrar erros nas seguintes categorias:
 
Funções incorretas ou faltando;
Erros de interface;
Erros em estruturas de dados ou acesso a bases de dados externas;
Erros de comportamento ou de desempenho;
Erros de inicialização e término.
*
TESTE CAIXA PRETA
*
Existem diferentes métodos de testes de caixa preta que podem ser subdivididos em:
 
Particionamento em Equivalência
Análise do Valor Limite
Teste de Matriz Ortogonal
Baseado em Grafo
*
TESTE CAIXA PRETA
*
*
TESTE CAIXA PRETA
Particionamento de Equivalência
Método de teste de caixa preta que divide o domínio de entrada de um programa em classes de dados a partir das quais os casos de testes podem ser derivados.
Um caso de teste ideal descobre sozinho uma classe de erros que, de outro modo, poderia exigir que muitos casos fossem executados antes que o erro geral fosse observado.
*
*
TESTE CAIXA PRETA
Análise do Valor Limite
 Percebe-se que um número maior de erros tende a ocorrer mais nas fronteiras do domínio de entrada do que no “centro”. A análise de valor de limite leva à escolha de casos de teste que põem à prova os valores fronteiriços.
É uma técnica que complementa o particionamento de equivalência: em vez de selecionar qualquer elemento de uma classe de equivalência, a BVA leva à seleção de casos de teste nas “extremidades”da classe.
*
*
A análise do valor limite leva a novos casos de teste referentes a valores
adjacentes aos limites. A seleção de tais casos adicionais, aumentam a probabilidade de se detectar uma falha.
Qualquer número
(neste intervalo)
TESTE CAIXA PRETA
Análise do Valor Limite
*
É um conjunto de atividades com um único objetivo:
Descobrir erros
 Mas como?
*
O TESTE DE UMA APLICAÇÃO WEB
*
 O processo de teste começa focando os aspectos visíveis da Aplicação ao usuário e abrange os aspectos de tecnologia e infraestrutura.
*
O TESTE DE UMA APLICAÇÃO WEB
*
*
Qualidade
Conteúdo
Função
Segurança
Usabilidade
Navegabi-lidade
Desempenho
Compatibilidade
Interope-rabilidade
Estrutura
DIMENSÕES DE QUALIDADE
*
Conteúdo: é avaliado no nível semântico e sintático. No nível sintático examina-se a ortografia, pontuação e gramática. No nível semântico são verificadas a exatidão, consistência e ausência de ambiguidade das informações.
Função: é testada para descobrir erros que indicam falta de conformidade com os requisitos do cliente.
*
DIMENSÕES DE QUALIDADE
*
Estrutura: É avaliada para assegurar o fornecimento apropriado do conteúdo e função da aplicação. Que seja extensível e possa ser mantida à medida que novo conteúdo ou funcionalidade é adicionado
Usabilidade: é testada para garantir que cada categoria de usuário seja suportada pela interface.
*
DIMENSÕES DE QUALIDADE
*
Navegabilidade: é testada para assegurar que toda a sintaxe e semântica de navegação sejam experimentadas para descobrir quaisquer erros de navegação.
 
Desempenho: é testado sob uma variedade de condições de operação, configuração e carga para assegurar que o sistema responda à interação com o usuário e suporte cargas extremas sem degradação inaceitável de operação.
*
DIMENSÕES DE QUALIDADE
*
Compatibilidade: é testada executando-se a aplicação em uma variedade de diferentes configurações hospedeiras tanto no lado cliente quanto no lado servidor.
 
Interoperabilidade: é testada para garantir que a aplicação tenha uma interface adequada com outras aplicações e/ou bases de dados.
*
DIMENSÕES DE QUALIDADE
*
Segurança: é testada para investigar vulnerabilidades potenciais e tentar explorar cada uma delas. Qualquer tentativa bem-sucedida de invasão é considerada falha de segurança.
*
DIMENSÕES DE QUALIDADE
*
O processo de teste da aplicação Web começa com testes que verificam o conteúdo e a funcionalidade da interface, posteriormente são verificados aspectos da arquitetura do projeto e da navegação da aplicação e finalizando com os testes que examinam os recursos tecnológicos.
Diversos deste testes não são aparentes para o usuário final.
*
O PROCESSO DE TESTE NA WEB
*
Tarefas importantes:
Revise os requisitos dos interessados. Identifique metas e objetivos-chave do usuário. Revise os casos de uso para cada categoria de usuário.
Estabeleça prioridades para garantir que cada meta e objetivo do usuário seja testado.
Defina a estratégia de teste da aplicação descrevendo os tipos de teste que serão conduzidos.
Desenvolva um plano de testes.
*
O PROCESSO DE TESTE NA WEB
*
Tarefas importantes (cont.):
Execute testes de unidade. Revise o conteúdo quanto à erros sintáticos e semânticos.
Realize testes de integração. Conduza testes de navegação.
Realize testes de configuração. Avalie a configuração do lado do cliente e do lado do servidor.
Conduza testes de desempenho.
Conduza testes de segurança.
*
O PROCESSO DE TESTE NA WEB
*
Integra técnicas de projeto de casos de teste numa série bem definida de passos;
Proporciona um mapa que descreve os passos a serem dados como parte da atividade de teste;
Deve incorporar planejamento de teste, projeto de casos de teste, execução de testes e a resultante coleta e avaliação;
*
ESTRATÉGIA DE TESTE DE SOFTWARE
*
Deve ser flexível o bastante para promover a criatividade e a customização necessárias para testar adequadamente;
Deve ser rígida o bastante para promover um razoável planejamento e rastreamento. 
*
ESTRATÉGIA DE TESTE DE SOFTWARE
*
Aqui nós precisamos responder as seguintes perguntas:
Como conduzir os testes de software?
Devemos estabelecer um plano formal para os testes?
Devemos testar o programa como um todo ou executar testes somente em uma parte dele?
Devemos refazer os testes quando acrescentamos novos componentes ao sistema?
Quando devemos envolver o cliente?
*
ESTRATÉGIA DE TESTE DE SOFTWARE
*
Do ponto de vista psicológico, as atividades de análise e projeto, junto com a programação, são tarefas construtivas.
Por outro lado, a atividade de teste pode ser vista, psicologicamente, como uma tarefa destrutiva.
Por esse motivo, é comum o desenvolvedor “pisar leve”, projetando e executando testes que demonstrem que o sistema funciona, em vez de descobrir erros.
*
QUEM REALIZA O TESTE?
*
Normalmente para que o processo de teste transcorra de forma íntegra é comum a utilização de um grupo independente de teste, já que as pessoas que criaram o software não devem ser as que irão realizar os testes. Seria um conflito de interesses pois foram elas que o “criaram”.
Este grupo trabalha de forma conjunta e existem testes que somente serão conduzidos pelos desenvolvedores, como o teste de unidade que iremos estudar mais adiante. 
*
QUEM REALIZA O TESTE?
*
O papel do ITG é remover os problemas inerentes ao fato de deixar que o construtor teste o que foi construído, de forma a suprimir o conflito de interesses.
Em muitos casos o ITG pertence ao grupo de GQS, conseguindo assim um grau de independência maior.
*
QUEM REALIZA O TESTE?
*
Após a definição da estratégia de testes é necessário criar o ambiente de teste, que não é apenas uma configuração de hardware, mas toda uma estrutura a ser considerada onde o teste será executado.
*
PORQUE É IMPORTANTE?
*
Pessoal
Hardware
Software
Suprimentos
Rede
Documentação
Ambiente físico
*
AMBIENTE DE TESTE
*
Lembre-se:
Teste é um conjunto de atividades que pode ser planejado antecipadamente e realizado sistematicamente.
Por essa razão, um gabarito de testes de software deve ser definido para o processo de software.
Um gabarito de testes é um conjunto de passos no qual podemos incluir técnicas de projeto de casos de teste e métodos de teste específicos.
*
ABORDAGEM ESTRATÉGICA
*
Características genéricas de uma estratégia de Teste :
 Para realizar um teste efetivo, uma equipe de software deve conduzir as RTF, quando muitos erros serão eliminados antes do início do teste;
 O teste inicia-se no nível de componente e prossegue “para fora”, na direção da integração de todo o sistema;
 Diferentes técnicas de teste são apropriadas a diferentes situações ou momentos;
*
ABORDAGEM ESTRATÉGICA
*
Características genéricas de uma estratégia de Teste (cont.):
 A atividade de teste pode ser realizada pela própria equipe de desenvolvedores ou por um grupo de teste independente;
 As atividades de Teste e de Depuração são diferentes, mas a depuração deve ser acomodada em qualquer teste. 
*
ABORDAGEM ESTRATÉGICA
*
A atividade de teste de software é uma parte de um tema mais amplo que é chamado de Verificação e Validação.
Verificação  conjunto de atividades que garante que o software implemente corretamente uma função específica.
Validação  conjunto de atividades que garante que o software que foi construído é adequado às exigências do cliente.
*
VERIFICAÇÃO & VALIDAÇÃO
*
Segundo Boehm:
 
Verificação – “Estamos construindo certo o produto?”
Validação – “Estamos construindo o produto certo?”
*
VERIFICAÇÃO & VALIDAÇÃO
*
“O processo de desenvolvimento de sistemas pode ser visto como uma espiral com suas etapas movimentando-se para dentro enquanto que a estratégia de teste pode ser vista movimentando-se para fora.
*
UMA ESTRATÉGIA DE TESTE
*
Concentra-se no estágio mais baixo da escala de teste, isto é, no código do programa e é considerado um adjunto da etapa de codificação.
Normalmente é realizado pelo desenvolvedor e inicia-se depois que o código foi desenvolvido, revisado e verificado quanto à sua sintaxe.
O teste de unidade baseia-se, fortemente, no teste de caixa branca.
*
TESTE DE UNIDADE
*
Este tipo de teste é aplicado nos menores componentes de código criado, visando garantir que estes atendem as especi-ficações em termos de características e de funcionalidade. 
O teste de unidade foca na lógica interna de processamento e nas estruturas de dados dentro dos limites de um compo-nente.
*
TESTE DE UNIDADE
*
Uma vez que um componente pode não ser um programa individual, softwares driver e/ou stub podem ser necessários para a realização do teste.
Driver (pseudocontrolador) é um substituto temporário de um módulo superior que permite que um módulo subordinado a ele seja testado. 
Stub (pseudocontrolado) é um substituto temporário de um módulo subordinado que permite que o módulo ao qual está subordinado seja testado.
*
TESTE DE UNIDADE - PROCEDIMENTO
*
*
TESTE DE UNIDADE - PROCEDIMENTO
*
Um driver representa o “programa principal” que aceita dados do caso de teste e passa esses dados para o componente a ser testado.
Um stub utiliza a interface dos módulos subordinados, pode fazer uma manipulação de dados mínima através de verificação de entrada e retorno do controle para o módulo que está sendo testado. 
*
TESTE DE UNIDADE - PROCEDIMENTO
*

Teste o Premium para desbloquear

Aproveite todos os benefícios por 3 dias sem pagar! 😉
Já tem cadastro?

Outros materiais