Testes de Software

1,988 views
1,903 views

Published on

Esse slide mostra a necessidade do processo de teste de software nos projetos de desenvolvimento de softwares, vamos demostrar as técnicas, tipos, fases, ferramentas, modelos e normas envolvidas na execução dos testes de software com o intuito de obter um ótimo nível de qualidade dos softwares gerados.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,988
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
117
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Testes de Software

  1. 1. ENGENHARIA DESOFTWARETESTE DE SOFTWAREAndré NeriJander Cerqueira
  2. 2. Agenda• Introdução• Fases Fundamentais e Metas dos Testes de Software• Tipos de Testes• Projeto de Casos de Testes2
  3. 3. Através deste vídeo iremos mostrar a necessidade do processo de teste de softwarenos projetos de desenvolvimento de softwares, vamos demostrar as técnicas, tipos,fases, ferramentas, modelos e normas envolvidas na execução dos testes de softwarecom o intuito de obter um ótimo nível de qualidade dos softwares gerados.3
  4. 4. No decorrer do desenvolvimento de um sistema existe uma grandepossibilidade de erros principalmente de falha humana, a fim de detectar ecorrigir esses erros utilizamos os testes, que segundo Pfleeger.. “Teste têmcomo foco a detecção de defeitos, e existem muitos meios de tornar maiseficientes e efetivos os esforços a eles relacionados”.4
  5. 5. Nos projetos de desenvolvimento de software os testes estão diretamenterelacionados com a qualidade como é citado por Pressman. “A atividade deteste de software é um elemento crítico da garantia de qualidade de softwaree representa a ultima revisão de especificação, projeto e codificação.”5
  6. 6. Na maioria dos casos os testes de software custa cerca de 40% dosrecursos total do projeto, mas quando se trata de sistemas críticos (porexemplo, controle de voo, monitoração de reatores nucleares) o custo podechegar a cinco vezes mais do que as outras etapas do projeto. Porem nemtodas as empresas dedicam-se a essa etapa adequadamente alegando prazocurto, custo elevado, falta de profissionais adequados, complexidade do softwaree até mesmo a falta de conhecimento dos benefícios dos testes de software.6
  7. 7. 7Fases Fundamentais e Metasdos Testes de Software.
  8. 8. Os sistemas são divididos em duas fases de testes, os testes decomponentes, onde são testados em partes e teste de sistema quando osistema é completamente testado. O alvo dos testes de componentes é atravésdos componentes individuais (funções, objetos ou componentes reusáveis) doprograma localizar defeitos. Já o objetivo do teste de sistema é integrar oscomponentes, formando o sistema completo assim verifica se o sistema atendeos requisitos funcionais e não funcionais e se comporta de maneira esperada,e se alguma imperfeição passar pelo teste de componente poderá ser corrigidopelo teste de sistema.8
  9. 9. Os testes de software visam duas metas, a primeira meta é demonstrar aodesenvolvedor e ao cliente que o software atende aos requisitos demostrandopelo menos um teste por requisito que esteja na documentação, através de umconjunto de teste é esperado que o programa seja executado como oesperado sem nenhum tipo de erro.9
  10. 10. A outra meta é descobrir falhas ou defeitos no software que apresentacomportamento incorreto, não desejável ou em não conformidade com suaespecificação onde são removidos os travamentos, interações indesejáveis edados corrompidos, essa meta usa o teste de defeitos utilizando casos detestes para mostrar defeitos. Desta forma a principal meta dos testes desoftware é provar para os desenvolvedores e clientes que o programa estáapto para ser utilizado.10
  11. 11. Tipos de TestesComo observamos anteriormente os testes são divididos em testes decomponentes e teste de sistemas esses testes contem subdivisões que facilita oteste em cada etapa do projeto. Vamos iniciar falando sobre as fases do testede sistema que possui teste de integração, teste de releases e teste dedesempenho. Depois vamos para as fases dos testes de componentes queabrange teste de interface.11
  12. 12. Teste de IntegraçãoEsse teste está ligado à descoberta de defeitos do sistema onde é acessado ocódigo fonte do sistema e todo problema. encontrado tenta-se localizar aorigem, e identificar os componentes afetados. O teste de integração, verifica seefetivamente os componentes funcionam, em conjunto, se são chamadoscorretamente. e se trocam dados no tempo certo.12
  13. 13. Teste de IntegraçãoA estratégia de integração top-down, é a criação do esqueleto do sistema, edepois a adição dos componentes a ele, já a integração bottom-up é aintegração de componentes de infra-estrutura que forneça serviços comuns (ex.:acesso a rede e ao banco de dados) e depois adicionar os componentesfuncionais. A estratégia mais utilizada é a combinação dessas duas estratégiasanteriores com os componentes de infra-estrutura e funcionais adicionados emincrementos.13
  14. 14. Teste de IntegraçãoO principal problema no teste de integração é localização dos erros para facilitar adescoberta de erros é usada a abordagem incremental para integração e teste dosistema. Primeiramente tem que integrar uma configuração mínima do sistema etestar, depois vai adicionando componentes e executando novos testes como émostrado na figura acima onde A, B, C e D são componentes e T1, T2, T3, T4 e T5são os testes.14
  15. 15. Teste de ReleasesCom o propósito de mostrar que o programa atende aos requisitos, o teste dereleases também conhecido como teste de caixa-preta e teste funcional tem o foco nafuncionalidade e não na implementação. Procura encontrar erros nas funçõesincorretas ou ausentes, erros de interface, erros nas estruturas de dados, erros dedesempenho e erros de inicialização e finalização.15
  16. 16. Teste de ReleasesO método particionamento de equivalência é utilizado para definir um caso de testeque encontre classes de erros, para reduzir o numero de casos de teste. Avaliando ascondições de entrada através de um conjunto de estados válido ou inválido conhecidocomo classe de equivalência.16
  17. 17. Teste de ReleasesNa imagem a acima ilustra o modelo de teste caixa-preta onde são fornecidas asentradas para o componente ou sistema e são examinadas as saídas; caso a saídanão for a prevista (Oe) o teste detectou um erro. O intuito é fornecer entradas com altoíndice de falha (Ie) como forçar resultados de cálculos muito grandes ou muitopequenos, forçar geração de saídas invalidas, repetir a mesma entrada e forçarentradas que causam overflow dos buffers.17
  18. 18. Teste de DesempenhoDepois que todos os requisitos funcionais foram testados e todas as funções exigidasestão funcionando é chegado à hora de começar a fazer os testes não funcionais eum dos pontos que são bastante exigidos é o desempenho. O teste de desempenhotem um conjunto de outros testes envolvidos como: testes de estresse, testes devolume, testes de tempo, testes de ambiente, testes de qualidade, testes derecuperação e testes de manutenção. 18
  19. 19. Teste de EstressePorem o teste de estresse é o mais utilizado, na maioria dos casos os sistemas sãoprojetados para atender um numero especifico de usuários ou transações o teste deestresse testa o programa além da carga máxima até que ele falhe, o objetivo desseteste é verificar qual será o impacto do sistema caso aconteça de ultrapassar o limiteprojetado e verificar se vai haver surgimento de novos defeitos depois do limiteatingido. 19
  20. 20. Teste de InterfaceOs erros de interfaces dos componentes compostos não podem ser identificadosatravés de testes de objetos ou componentes individuais sendo encontrado apenas nainteração entre as suas partes.A figura mostra o processo de teste de interface dando uma visão que o testenão é realizado nos componentes individuais e sim na interface do componentecomposto.20
  21. 21. Projeto de Casos de Testes.Projeto de casos de teste é o conjunto de entradas e saídas esperadas, que sejamutilizados tanto nos testes de sistemas como de componentes. Para realizar o projetode casos de teste é escolhida uma característica do sistema que será testado, entãoocorre uma seleção das entradas que vai ser executada no teste, depois verifica se assaídas correspondem com o esperado. Podemos utilizar basicamente três tipos deabordagens na elaboração do projeto de casos de testes que são: teste baseado emrequisitos, teste de partições, teste estrutural e o teste de caminho que é umaestratégia de teste estrutural. 21
  22. 22. Teste Baseado em Requisitos.Na etapa de requisitos do sistema tem que ser definido que os requisitos devem sertestáveis, ou seja, os requisitos devem ser escritos com o intuito de ser testadosfuturamente para verificar se os requisitos foram atendidos como o solicitado. Portantoteste baseado em requisitos é o conjunto de teste elaborado para cada requisitoregistrado na fase de levantamento, essa técnica é essencial para verificar requisitosvagos ou ausentes.22
  23. 23. Teste Baseado em Requisitos.O teste baseado em requisitos é um teste de validação isto é ele demonstra que osistema tem seus requisitos adequadamente implementados.23
  24. 24. Teste Baseado em Requisitos.Iremos ver um exemplo prático onde é listado um requisito de um sistema e seuspossíveis testes24
  25. 25. Teste Baseado em Requisitos.R1 - O usuário será capaz de procurar todo o conjunto inicial do banco dedados ou selecionar um subconjunto dele.Os possíveis testes para esse requisito são:•Iniciar as buscas de usuário pelos itens cuja presença ou ausência são conhecidas,quando o conjunto de bancos de dados incluírem um ou mais banco de dados.•Selecionar mais de um banco de dados de um conjunto de banco de dados e iniciaras buscas pelos itens cuja presença ou ausência são conhecidas. 25
  26. 26. Teste Baseado em Requisitos.Concluímos que para cada requisito podem ser feitos vários testes para assegurar queo requisito foi devidamente concluído.26
  27. 27. Teste de Partições.O teste de partições visa identificar todas as partições do sistema ou componentes, eque as entradas e saídas de casos de testes sejam alocadas dentro dessas partições.As identificações de partições são feitas por meio de especificações na documentaçãoou através da experiência dos projetistas que prevê classes que podem conter valoresde entradas com grande probabilidade de erros.27
  28. 28. Teste Estrutural.Também conhecido como teste de caixa-branca, o teste estrutural é uma abordagemonde os testes são derivados do conhecimento da estrutura e da implementação dosoftware. Avalia o comportamento interno do componente de software, essa técnicatrabalha diretamente sobre o código fonte do componente de software para avaliaraspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, testede caminhos lógicos e códigos nunca executados. O testador tem acesso ao códigofonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas ecomponentes, esta é uma técnica de teste geralmente realizada pelosdesenvolvedores que trabalha diretamente com o código-fonte do sistema.28
  29. 29. Teste de Caminho.O teste de caminho tem o objetivo de percorrer cada componente ou o sistema porcompleto testando as condições tanto verdadeiras como falsas. O numero decaminhos é relativamente proporcional ao tamanho do sistema, logo é mais viável autilização do teste de caminho na etapa de teste de componentes. O teste faz comque pelo menos uma vez cada caminho seja executado.29
  30. 30. Considerações Finais.Concluímos que o processo de teste desoftware faz com que a qualidade, acredibilidade, a confiança e a competitividadedo software cresçam. Aprendemos também queos testes estão subdivididos e que a dependerda necessidade podemos utilizar, a combinaçãode dois ou mais testes. E que devemos planejare deixar uma boa quantidade recursos paraessa etapa do projeto, que em alguns casoschega ser a etapa mais importante do projeto dedesenvolvimento de um sistema.30
  31. 31. ReferênciasSOMMERVILLE, I.; Engenharia de Software. 8ª ed. São Paulo:Pearson Addison-Wesley, 2007.PFLEEGER, S. L.; Engenharia de Software: Teoria e Prática. 2ªed. São Paulo: Prentice Hall, 2004.PRESSMAN, R. I.; Engenharia de Software. São Paulo: PearsonMakron Books, 1995.31

×