qualidade de software - di.ubi.ptsebastiao/ensino/qualidadedesoftware-20162017/te... · os testes...

Qualidade deSoftware

Sebastiao Pais

Testes deSoftware

Visao Geral

Principaisobjetivos eprincıpios deteste

Criterio decobertura deteste

Abordagemestrategica aoteste de software

Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema

Testes deambiente,arquiteturas eaplicacoesespecializadas

Testes Alfa eBeta

Depuracao desoftware

Defeitos e falhasno software

Planeamento detestes

Ferramentasautomaticas detestes

Conclusao

Qualidade de Software2o Ciclo de Engenharia Informatica, 1o Ano, 1o Semestre

Apontamentos Teoricas - Testes de Software

Sebastiao Pais1

1Departamento de InformaticaUniversidade da Beira Interior

[email protected]://www.di.ubi.pt/~sebastiao

2016/2017

http://www.di.ubi.pt/~sebastiao


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I

1 Testes de SoftwareVisao GeralPrincipais objetivos e princıpios de testeCriterio de cobertura de testeAbordagem estrategica ao teste de softwareTeste caixa-brancaTeste caixa-pretaTeste caixa-cinzentaTeste de unidadeTeste de integracaoTeste de validacaoTeste de sistemaTestes de ambiente, arquiteturas e aplicacoesespecializadasTestes Alfa e BetaDepuracao de software


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario IIDefeitos e falhas no softwarePlaneamento de testesFerramentas automaticas de testesConclusao


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Visao Geral I

Os testes de qualidade sao de grande importancia para aqualidade de software, pois tem como proposito a garantia daqualidade de software e a validacao de que as funcionalidadesestao de acordo com os requisitos.Tem como principal objetivo:

• o de identificar problemas no funcionamento do software;

• fornecer diagnosticos para que os erros sejam corrigidos;

• manter o foco na prevencao do erro durante o ciclo devida do software.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Visao Geral II

Depois de codificar o programa, o passo seguinte e testa-lo,existindo para tal varios tipos de abordagens. Quando seprocede a acao do teste, devem–se ter projetado casos detestes, com o intuito de aplicar na fase de testes de software efazer a respetiva correcao dos defeitos existentes. Nesta fase,os testes do software tambem devem ter em conta os requisitosfuncionais e tecnicos, pois sao estes que especificam ecaracterizam o produto que esta a ser construıdo.

Como esta atividade consome bastante tempo e recursos, estafase e muitas vezes negligenciada em funcao de limitacoes deprazo e orcamento e por isso o software e entregue ao clientecom defeitos nao revelados que provocarao falhas noquotidiano. Por esta razao, a eficacia dos testes e um dosfactos importante para garantir a qualidade e para a reducao decustos.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Principais objetivos de teste I

• tem como finalidade encontrar erros;

• os bons casos de teste sao aqueles que tem altaprobabilidade de encontrar erros ainda nao encontrados;

• testes bem sucedidos sao aqueles que encontrarao errosainda nao descobertos.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Principais princıpios de teste I

• devem estar relacionados com o cliente e com as suasexpectativas quanto ao produto;

• os testes devem ser planeados com a devida antecedencia,devendo faze-los assim que o modelo de requisitos estejacompleto;

• os testes devem considerar a aplicacao do princıpio dePareto, que sugere que 80% dos erros estarao relacionadoscom 20% dos componentes;

• os primeiros testes concentram-se nos componentes edepois deslocam-se para os testes de sistema; o testecompleto e impossıvel.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Criterio de cobertura de teste I

O criterio de cobertura de teste e uma regra pela qual como sedeve selecionar os testes e quando se deve parar os mesmostestes. Trata-se de condicoes que devem ser preenchidas peloteste, a qual selecionam determinados caminhos que visamcobrir o codigo implementado.Os principais pontos de coberturas sao os seguintes: testefuncional, teste estrutural e matrizes de testes.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste funcional I

Neste tipo de teste e utilizada a especificacao do software paraidentificar subdomınios que devem ser testados. Um dosprimeiros passos e criar casos de testes para cada tipo de saıdada aplicacao (como exemplo, cada mensagem de erro deveriaser gerada), seguindo todos os casos especiais que devem tercasos de teste. Todas as situacoes de excecao, erros e enganosdevem ser testados. No final temos como resultado umconjunto de casos de teste que ira testar totalmente aaplicacao quando implementado. Esse conjunto de casos deteste tambem tem como objetivo ajudar a identificar algunscomportamentos esperados do software.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste estrutural I

Este tipo de teste e baseado no fluxo de dados do programa,onde podemos encontrar os seguintes criterios de teste:

• c0 - cobertura de todos os comandos - todos oscomandos do codigo-fonte devem ser executados poralgum caso de teste;

• c1 - teste de todos os ramos - este tipo de teste temcomo objetivo passar por todos os caminhos e em todas asdecisoes;

• teste de todo o caminho - este tipo de teste tem comofinalidade verificar se uma determinada sequencia de nosde programas e executado por um caso de teste, podendoter um numero infinito de caminhos e por isso nao eatingido o final do caminho;


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste estrutural II

• cobertura de condicao multipla - para este tipo decriterio e requerido que cada condicao de primitiva sejaavaliada como verdadeira e falsa;

• teste de subdomınio - a ideia principal para este tipo deteste e o de dividir o domınio de entrada em subdomınios,nao restringido como estes subdomınios sao selecionados.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Matrizes de teste I

Uma maneira de formalizar a identificacao de subdomınios eatraves de matrizes de teste, identificando assim todas ascombinacoes possıveis como sendo verdadeiras ou falsas.Um exemplo da matriz de teste e a tabela seguinte com ascondicoes do problema de um triangulo: sao colocadas 4condicoes nas linhas da matriz. As colunas da matrizrepresentam um subdomınio, sendo colocado um V quando acondicao e verdadeira e um F quando a condicao e falsa.Podem ser usadas linhas adicionais para as condicoes e asrespetivas saıdas esperadas para cada subdomınio.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Matrizes de teste II


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Abordagem estrategica ao teste desoftware I

Existem varias estrategias de teste de software. O principalobjetivo da estrategia de testes de software e o de fornecer asdiretrizes para a verificacao, validacao, organizacao e estrategiados testes de software.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Verificacao e validacao I

Os testes tem como objectivo garantir a qualidade de software,permitindo a verificacao e validacao:

• verificacao tem como objetivo garantir que o programaesta a ser implementado corretamente (”Estamos aconstruir bem o produto?”);

• validacao tem como objetivo garantir que o programacorresponde aos requisitos (”Estamos a construir oproduto correto?”).


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Verificacao e validacao II

Os erros mais comuns, que dificultam o processo dedesenvolvimento:

• incapacidade de compreensao das necessidades doutilizador;

• engano na gestao do tamanho do projeto;

• falta de planeamento de projeto;

• falta de testes do produto final;

• execucao errada do produto;

• forma inadequada de lidar com as coisas;

• nao permitir que um profissional possa planear o projetode desenvolvimento de software;

• nao incentivar a equipa a dar o melhor;

• atraso do plano do projeto;


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Verificacao e validacao III

• instalacao de um pacote de software insuficiente;

• mudanca de ferramentas de software no inıcio do projeto;

• permitir adicionar coisas desnecessarias; por vezes osprogramadores tentam eliminar tarefas necessarias a fimde encurtar o plano do projeto;

• incapacidade de gestao do projeto;

• falta de patrocınio do mais alto nıvel empresarial;

• nao aumento da equipa de projeto para acelerar o projeto;

• falta de teste de unidade;

• esgotamento dos programadores de software;


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Verificacao e validacao IV

• falta de tratamento de erros; um erro leva a outro e porisso deve-se verificar cuidadosamente os erros;

• erros por parte de um processo de desenvolvimento desoftware;

• implementacao incorreta de hardware;

• inexistencia de convencoes de codigos;

• aplicar sempre variaveis globais;

• falta de coordenacao do processo de desenvolvimento desoftware;

• incapacidade de comentar o codigo;


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Verificacao e validacao V

• manter as informacoes para si proprio;

• executar operacoes de base de dados na camada deaplicacao, em vez na camada de base de dados; invalidaros dados;

• falta de teste de carga.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Verificacao e validacao VI


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Organizacao do teste de software I

Devera haver um trabalho contınuo no projeto em conjuntoentre os varios grupos de trabalho (programadores, grupo deteste, etc.), com o objetivo de garantir a qualidade de software.O programador devera ser responsavel por efetuar os testes deunidade dos modulos do programa, garantido que cada um dosmodulos esta a funcionar de acordo para o fim qual foiconcebido. O grupo independente de teste devera remover osproblemas associados a aplicacao. O engenheiro de softwaredevera trabalhar com os programadores e o grupo de teste,para garantir que estam a ser efetuados testes rigorosos.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Estrategia de teste de software I

Devem testar-se individualmente os programas que integram aaplicacao, com o objetivo de verificar que cada um esta afuncionar adequadamente. Em seguida deve-se reunir osdiversos componentes para formar o pacote de software,permitindo fazer os respetivos testes de integracao e validar seos requisitos estao a funcionar adequadamente. Por fim deveser testado com outros elementos do sistema e verificar se odesempenho global e conseguido.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Criterios para completar o teste I

Nao existe limite para o termino dos testes. Ao longo dotempo, existe a probabilidade de decrescimo de erros a medidaque o teste progride, nao havendo nunca a certeza deinexistencia de mais erros. Um exemplo desta situacao e oMicrosoft Windows 7, onde participaram no desenvolvimentotres mil engenheiros, cinquenta mil parceiros e oito milhoes detestadores.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste caixa-branca I

O teste de caixa-branca e um metodo que utiliza a estrutura decontrolo do projeto procedimental para derivar casos de testes.Esta tecnica utiliza diretamente o codigo-fonte do componentepara avaliar diversos aspetos, tendo como principais objetivosos seguintes pontos:

• garantir que todos os fluxos de execucao corram pelomenos uma vez;

• garantir que todas as decisoes logicas corram os ladosverdadeiros e falsos;

• garantir que os ciclos corram nos seus limites e intervalosoperacionais;

• garantir que as corram as estruturas de dados internascom objetivo de garantir sua validade.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste caixa-branca II

Tambem se deve ter em conta o tempo e a energia gastos comeste tipo de teste, devido as seguintes razoes:

• erros logicos e pressupostos incorretos encontrados nofluxo do programa;

• o fluxo de controlo de um programa pode levar a cometererros de projeto;

• erros de digitacao ao traduzir um programa numcodigo-fonte.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste caixa-preta I

O teste de caixa-preta tem como objetivo focar-se nosrequisitos de software, funcionando como complemento aoteste de caixa-branca. A principal consideracao que se deve terneste tipo de teste e a do domınio da informacao. As principaiscategorias em que este tipo de teste se foca sao as seguintes:

• funcoes incorretas;

• erros de interface;

• erros de estrutura de dados e acesso a base de dados;

• erros de comportamento ou desempenho;

• erros de inicializacao e finalizacao.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste caixa-preta II

Tecnicas:

• metodos baseados em grafos - entender os objetos dedados modelados e suas relacoes, definindo–se uma seriede testes que verifiquem relacoes esperadas entre eles epor final cria-se uma colecao de nos que representam osobjetos;

• metodo da particao equivalente - o domınio de entradade um programa e dividido em classes de dados, em queos casos de teste podem ser derivados, descobrindo classesde erro e reduzindo o numero total de casos de teste;

• metodo da analise de valores limites - alguns errosocorrem na fronteira do domınio de entrada e este tipo detecnica e usada para a analise de valores de limite;


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste caixa-preta III

• testes de comparacao - e utilizada para minimizar apossibilidade de erro usadas em sistemas redundantes;

• testes de matriz ortogonal - e normalmente utilizadaquando o domınio de entrada e pequeno, mas que exigemmuitas provas exaustivas e onde e bastante util paraencontrar erros de logica associados a erros de logica numcomponente de software. Tambem possibilita obter boacobertura de teste com menos casos de testes que aestrategia exaustiva.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste caixa-cinzenta I

Enquanto o teste de caixa-preta se concentra na funcionalidadedo programa e sua especificacao e o teste de caixa-branca seconcentra na estrutura da logica, o teste de caixa-cinzento e acombinacao dos dois testes.O responsavel pelos testes de software estuda as especificacoesdos requisitos e comunica com o programador para entender aestrutura do sistema. O principal objetivo e acabar comespecificacoes ambıguas e construir testes apropriados. Umexemplo deste tipo de teste e quando a pessoa que esta atestar uma certa funcionalidade se apercebe que uma partedessa funcionalidade esta a ser reutilizada em toda a aplicacao,entrando em contacto com o programador com o objetivo decompreender a arquitetura interna e assim eliminar muitostestes, pois podera testar a funcionalidade apenas uma unicavez.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de unidade I

Tambem conhecido por teste unitario ou teste de modulo, oprincipal objetivo e o de testar em pequenas partes ou unidadesdo software desenvolvido (componentes / modulos) e assimencontrar falhas de funcionamento isoladas do todo o sistema.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de integracao I

Nesta fase o principal objetivo e a integracao dos variosmodulos / componentes do sistema, que sao combinados etestados em grupo. Por vezes, quando combinados, podem naoefetuar a funcao principal para a qual se desejaria, sendo porisso necessario fazer a construcao dos varios programasindependentes.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de integracao II

Abordagens dos testes de integracao:

• teste bottom-up - comeca a construcao de testes com oscomponentes individualmente, ou seja, nos nıveis maisbaixos da estrutura do programa, e sao integrados debaixo para cima;

• teste top-down - e uma abordagem incremental para aconstrucao da estrutura do programa. Os varios modulossao integrados, comecando com o modulo principal,movendo-se descendentemente pela hierarquia de controlo.Podera haver problemas de processamento nos nıveis maisbaixos da hierarquia quando e necessario testaradequadamente os nıveis superiores.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de integracao III

• teste de regressao - cada vez que um modulo eadicionado ao programa, o software modifica-se. Estasmodificacoes podem trazer problemas a funcoes queanteriormente funcionavam perfeitamente. Nestecontexto, o teste de regressao e a reexecucao de parte detestes, para garantir que essas modificacoes nao sepropagam com efeitos indesejaveis;

• teste cortina de fumo - este tipo de teste e usadofrequentemente quando os produtos de software estao aser desenvolvidos. Sao testes que procuram erros aosistema todo, de ponta a ponta. Embora nao exaustivo,devera ser suficientemente rigoroso para garantir aestabilidade do sistema.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de integracao IV

• documentacao do teste de integracao - o documentode testes de integracao devera conter um plano de testes eprocedimentos de teste. O plano de testes deveradescrever a estrategia global de integracao, devendo ostestes serem divididos por fases e construcoes que tratamas caracterısticas funcionais e comportamentais especıficosdo software. Deverao seguir os seguintes criteriosaplicados a fase de teste:

• integridade de interface - sao testados os interfacesinternos e externos a medida que cada modulo e integradona estrutura;

• validade funcional - o objetivo e descobrir errosfuncionais, isto e, verificar se o produto corresponde aosrequisitos dos utilizadores;

• conteudo informacional - serve para descobrir errosrelacionados com estruturas de dados locais ou globais;

• desempenho - testes associados a verificacao dodesempenho estabelecidos pelo software.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de validacao I

No final dos testes de integracao e depois de completar opacote final de software e corrigidos os erros que foramdescobertos, podem comecar os testes de validacao.A validacao do software torna-se bem sucedida quando oproprio software funciona segundo as expectativas do cliente.Esta e conseguida atraves de um conjunto de testes quedemonstram conformidade com os requisitos, atraves de umplano de testes que confirma que todos os requisitos estaocompletos. O plano e os procedimentos dos testes saoprojetados com o objetivo de garantir que os requisitosfuncionais sao satisfeitos. Caso sejam descobertos desvios aoplaneado, sera necessario estabelecer metodos de resolucao dasdeficiencias existentes, sendo preciso negociar com o cliente ummetodo para corrigir as deficiencias encontradas.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de validacao II

Outro elemento importante do processo de validacao e arevisao da configuracao, que tem como objetivo garantir quetodos os elementos da configuracao foram adequadamentedesenvolvidos, catalogados e com os detalhes necessarios paraapoiar a fase de suporte do ciclo de vida do software.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de sistema I

O teste de sistema e uma fase do processo que integra testescuja finalidade principal e a preocupacao com os aspetos geraisdo sistema. Nao se limita a testar os requisitos funcionais, mastambem os nao funcionais.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de recuperacao I

Muitos sistemas devem recuperar de falhas e retomar oprocessamento em tempo util, sendo em alguns casos tolerantea falhas e em outros casos deverao ser corrigidos em tempoespecıfico. Este tipo de teste tem como objetivo forcar osoftware a falhar em diversos modos, com o objetivo deverificar se a recuperacao e adequadamente realizada.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de seguranca I

O teste de seguranca tem como objetivo verificar se osmecanismos de protecao incorporados no sistema estao defacto a proteger de invasao impropria, quanto asvulnerabilidades do sistema.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de carga I

No teste de carga, procura–se testar o sistema quando sujeitoem quantidade, frequencia ou volume de dados anormais.Como o principal objetivo e verificar o limite de dadosprocessados pela aplicacao ate nao conseguir processar,permite a melhoria do software ao reduzir custos, otimizacaode carga e eventuais estrangulamentos.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Teste de desempenho I

Tem como objetivo testar o desempenho de software durante aexecucao, ocorrendo ao longo do contexto do sistemaintegrado. Por vezes sao utilizados instrumentos paramonitorizar intervalos de execucao, para descobrir situacoesque possam levar a degradacao do desempenho do software efalha do sistema.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Testes de ambiente, arquiteturas eaplicacoes especializadas I

A medida que os programas se tornam mais complexos, saousadas abordagens de testes mais especializadas.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Testes de interfaces graficas I

E atraves da interface grafica que a maioria dos programascomunica com os utilizadores, cujo GUI (Graphical UserInterface) representa uma grande parcela de codigo econsequentemente maior probabilidade de defeitos deaplicacao. Ao longo do tempo a criacao de interfaces para outilizador tornou–se mais precisa e menos demorada, devido aouso de componentes reutilizaveis, mas ao mesmo tempoaumentou a complexidade dos casos de teste.Devido a permutacao de operacoes GUI, existem variasferramentas automaticas de testes que ajudam a realizar essesmesmos testes, em oposicao a abordagem manual, que estasujeita a falhas humanas, dura bastante mais tempo e e maisdispendiosa.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Testes de arquiteturas cliente /servidor I

Devido a natureza distribuıda desta arquitetura, torna–se maisdifıcil fazer testes do que em relacao aos aplicacoes isoladas.Existe um aumento de custo e de tempo para odesenvolvimento deste tipo de arquitetura, devido a naturezadistribuıda do ambiente cliente / servidor, aspetos dedesempenho associado ao processamento de transacoes, adiferentes tipos de plataformas de hardware, complexidades deredes de comunicacao, etc.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Testes de documentacao I

O teste de documentacao deve ser abordado de duas maneiras:

• verificacao da clareza do documento;

• utilizacao da documentacao em conjunto com o programade software com o objectivo de fazer testes de coerencia.

Sugere-se haver um utilizador que devera validar adocumentacao. Todas as discrepancias devem ser anotadas equando existe ambiguidade ou deficiencia no documento, esteerro deve ser corrigido.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Testes de sistemas em tempo real I

Este tipo de testes tem o objetivo avaliar o correto desempenhoa um estımulo e sua resposta em tempo util, podendo ter osseguintes casos de teste:

• teste de tarefa - neste tipo de teste verifica-se cadatarefa individualmente, onde o objetivo e descobrir errosde logica e de funcao;

• teste comportamental - o principal objetivo e examinar ocomportamento do sistema e verificar a sua conformidadecom o esperado;


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Testes de sistemas em tempo realII

• teste intertarefas - depois das tarefas serem testadasindividualmente e examinado o comportamento dosistema, as tarefas sao avaliadas em conjunto com afinalidade de descobrir erros;

• teste de sistema - o software e o hardware sao integradoscom o objetivo de verificar a eficiencia do sistema.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Testes Alfa e Beta I

Por norma as aplicacoes passam por duas fases de testes, antesde serem consideradas como produto final:

• teste Alfa - testes efetuados pelos utilizadores da propriaempresa;

• testes Beta - testes efetuados que envolve o uso limitadode utilizadores externos a empresa que desenvolve aaplicacao, com o objetivo de encontrar erros e seremcorrigidos antes na versao final.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Depuracao de software I

A depuracao de software, normalmente conhecido pordebugging, nao e propriamente um teste e ocorre comoconsequencia dos testes efetuados. Quando o resultado daavaliacao de um teste nao tem correspondencia entre oesperado e aquilo que efetivamente e obtida, e efetuado odebug ao programa com o objetivo de encontrar a causa e levara correcao do erro de software.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Depuracao de software II

Em geral temos tres categorias de abordagens de debug:

• forca bruta - e o metodo mais comum e o menoseficiente; normalmente utilizado quando as outrasabordagens falham; o programa e carregado commensagens tendo como objetivo encontrar uma pista, quenos leve a encontrar o erro;

• comportamento - metodo utilizado quando se temprogramas pequenos; o codigo-fonte e verificado ateencontrar a causa do erro;

• eliminacao da causa - os dados relacionados com aocorrencia do erro e organizada para isolar as causas,refinadas numa tentativa de isolar o erro.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Defeitos e falhas no software I

Devido a um grande numero de situacoes, a presenca dedefeitos e funcao nao so do software, mas tambem dasexpectativas dos utilizadores e clientes. O software falhaquando a expectativa que esperamos do programa nao esta deacordo com os requisitos, resultado de varios fatores.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Defeitos e falhas no software II

• falta ou falha de requisito na especificacao, onde aespecificacao pode nao ter sido manifestada de modo claropelo cliente;

• requisito da especificacao difıcil ou impossıvel deimplementar, considerando o software e o hardware(violacao da regra de ouro);

• defeitos no projeto do sistema, onde o algoritmoimplementado pode nao corresponder ao esperado ou estaincompleto, quer em termos de funcionalidade, quer emtermos de desempenho.

Quando e concluıda a fase de codificacao e se entra na fase deteste, espera-se que as especificacoes refletidas no programatenham uma implementacao correta. Atraves da fase de testesconsegue-se identificar o defeito e efetuar posteriormente acorrecao do defeito.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Planeamento de testes I

O planeamento caracteriza-se pela definicao de proposta detestes baseadas nas especificacoes do cliente, considerandoprazos, custos e qualidade esperados, ajudado a projetar e aorganizar os testes. Cada etapa do processo deve ser planeada,devendo seguir os seguintes pontos:

• estabelecer os objetivos do teste;

• definir os casos de teste;

• escrever casos de teste;

• testar os casos de testes;

• executar os casos de testes;

• avaliar os resultados dos testes.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas automaticas de testesI

A execucao manual dos testes de software pode ser rapida eefetiva, embora seja uma tarefa dispendiosa e cansativa. Porisso e normal que ao longo do tempo as condicoes dos testesnao se verifiquem novamente e que os erros de softwareacontecam, trazendo prejuızo para as equipas dedesenvolvimento que perdem tempo a identificar e a corrigir oserros e tambem para os clientes que sofrem com os atrasos nosprazos e tempo com a entrega de software de qualidadeduvidosa.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas automaticas de testesII

Os testes automaticos sao programas ou scripts simples, cujoprincipal objetivo e avaliar as funcionalidades do sistema,fazendo essas verificacoes de uma forma automatica. Aprincipal vantagem deste tipo de abordagem e que todos oscasos de teste podem ser rapida e facilmente repetidos aqualquer momento e com pouco esforco.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas de analise de codigo I

Existem duas categorias de ferramentas de analise de codigo: aanalise estatica (que e utilizada quando o programa nao estaa ser executado) e a analise dinamica (possibilita relatar ocomportamento do programa em tempo real).


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas de analise de codigo II

analise estatica - existem diversas ferramentas que analisam ocodigo-fonte do programa antes que seja executado, onde seinvestiga a correcao da aplicacao e que inclui as seguintestarefas:

• analisador de codigo: avalia a sintaxe dos componentes;

• verificadores de estrutura: avalia a fluxo logico,verificando problemas estruturais;

• analisador de dados: avalia a estrutura de dados;

• verificador de sequencia: avalia a sequencia de eventos.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas de analise de codigoIII

analise dinamica - muitas vezes os sistemas sao difıceis detestar, pois diversas operacoes sao executadas em paralelo,especialmente nos sistemas de tempo-real. E aqui que os testescom ferramentas automaticas possibilitam que a equipa dedesenvolvimento obtenha os estados dos eventos durante aexecucao da aplicacao, atraves de monitorizacao de programasque permitem avaliar o desempenho do sistema.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas de execucao de testesI

Este tipo de testes nao tem foco no codigo, mas sim naexecucao dos testes de software, devido ao tamanho e acomplexidade dos sistemas atuais. Nos ultimos anos, este tipode ferramentas tem ajudado os programadores a aumentar aprodutividade no desenvolvimento de software, aumentandotambem a execucao de testes na validacao do produto emmenor tempo.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas de execucao de testesII

Ferramentas

• captura e repeticao - quando os testes sao planeados, aequipa deve especificar nos casos de teste, as entradasfornecidas e qual o resultado esperado das acoes testadas ee aqui que as ferramentas de captura e repeticao sao uteis,pois assim sao capturadas as entradas e respostas dostestes que estao a ser executados e descobrir discrepanciase em seguida corrigir os defeitos que foram encontrados;


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas de execucao de testesIII

Ferramentas

• stubs e drivers - este tipo de testes tem como objetivotestar um componente especıfico com um caso de teste,existindo ferramentas comerciais com o objetivo de auxiliarna geracao de stubs e drivers, podendo o driver:

• definir todas as variaveis de estado a preparacao de casosde teste;

• simular a insercao de dados e outras condicoesrelacionadas com dados;

• comparar os resultados com a saıda esperada;• rastrear os caminhos durante a execucao;• redefinir as variaveis para novo caso de teste;• interagir com pacotes de depuracao, com o objetivo de

rastrear e corrigir os erros.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Ferramentas de execucao de testesIV

Ferramentas

• ambientes automaticos de teste - a automacao dostestes deve ser integrado com outras, afim de formar umamplo ambiente de testes e tem como objetivo o auxilionos testes do software (como por exemplo ferramentasconectadas a base de dados de teste, ferramentas demedicao, ferramentas de analise de codigo-fonte,ferramentas de simulacao e modelacao, etc.), pois ostestes sempre envolverao esforco manual para rastrear odefeito ate a causa original e por isso a automacao auxiliaos testes, nao substituindo a funcao humana.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Geradores de casos de teste I

Este tipo de ferramenta baseia–se na estrutura do codigo fonte,fluxo de dados, teste funcional ou estados de cada variavel como objetivo de criar casos de testes. Como os testes de softwareresultam da definicao cuidadosa e completa dos casos detestes, e bastante vantajoso automatizar parte dos casos deteste, com o objetivo de garantir que os testes cubram todos oscasos possıveis.


Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Sumario I



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao



Sebastiao Pais

Testes deSoftware

Visao Geral




Testecaixa-branca

Teste caixa-preta

Testecaixa-cinzenta

Teste de unidade

Teste deintegracao

Teste devalidacao

Teste de sistema


Testes Alfa eBeta





Conclusao

Conclusao I

Os testes de software sao um elemento util e que tem comoobjetivo o aumento da confiabilidade e garantia dos requisitosdo produto. Podem ajudar o processo de desenvolvimento econsequentemente a qualidade da aplicacao, dentro dos custose prazos.A implementacao de metodos de teste, ajuda a minimizardesperdıcios e estimular a equipa de desenvolvimento amelhorar o seu procedimento de trabalho, atraves daincorporacao de procedimentos, filosofias e documentacao queincorporam factores de qualidade do software.

qualidade de software - di.ubi.ptsebastiao/ensino/qualidadedesoftware-20162017/te... · os testes...

Documents