Testes em Software
Teste de Sistemas
• É importante testes em cada fase do projeto.
• Com procedimentos eficazes de testes progressivos, dificilmente os testes de sistemas serão iniciados até que se tenha confiança razoável no desenho.
• Tentativa de se testar um sistema complexo com um desenho impreciso e partes defeituosas não é uma boa prática.
• Saltar teste de desenho e dos programas = voltar à depuração e à correção do desenho e o desenvolvimento é interrompido.
Testes em grande escala
• Testes em grande escala• Realização de testes de sistemas eficazes, entendendo-se por sistemas qualquer grupo interligado de programas.
• Conforme o projeto:
– Testes de componentes, testes funcionais, testes de sistemas, testes de produto, testes de stress, testes de aceitação, etc
– Testes de sistemas: preparação de plano. – 3 níveis distintos:
• Testes de integração: reunião de programas em componentes ou módulos funcionais
• Testes de sistemas: desempenho funcional do sistema como um todo • Testes de aceitação: disponibilidade do sistema para instalação e entrada
Testes em grande escala
Principais atividades dos Testes em Grande Escala • Testes de integração
– Interface de programas e módulos – Reunião de componentes do sistema – Interação de programas/módulos • Testes de sistemas – Desempenho funcional – Recursos do sistema • Testes de aceitação – Necessidades do sistema
Testes em grande escala
Plano Global de Testes
• Documento formal que : – define objetivos;
– estabelece uma estratégia coordenada para a conclusão de todos os testes;
– fornece a estrutura para o planejamento detalhado de todos passos e tarefas do processo.
• Documento ou conjunto de documentos delineado durante a fase inicial do projeto e ampliado e revisto durante sua execução.
Testes em grande escala
• Plano Global de Teste
– Estratégia/enfoque dos testes
• Definição do ciclo de vida dos testes • Enfoque global
• Ferramentas técnicas principais
• Definição dos componentes e seções dos testes • Procedimentos para estudo/ampliação das revisões
– Especificações dos casos de teste
• Organização geral dos casos de teste • Pastas de casos de teste
• Matriz de validação de necessidades • Matriz de casos de teste funcionais
– Responsabilidades
• Organização dos testes • Recursos e programação • Tarefas e alocação de recursos
– Procedimentos
• Procedimentos de teste
• Registro de acompanhamento de problemas • Repetição dos testes
– Controles
• Alterações
Testes de Integração
• Testes de Integração
– Iniciam-se quando os primeiros programas são interligados.
– Testar as interfaces dos programas e confirmar que os programas foram interligados corretamente.
– Na fase de teste de integração, o objetivo é encontrar falhas
provenientes da integração interna dos componentes de um sistema.
• Como é desenvolver um avião?
– Geralmente os tipos de falhas encontradas são de transmissão de dados. • Por exemplo, um componente A pode estar aguardando o retorno
de um valor X ao executar um método do componente B; porém, B pode retornar um valor Y, gerando uma falha.
– Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema e não teste de integração.
Testes de Integração
– Objetivos• Obter um sistema mínimo (em condições de operação)
• Adquirir confiança : os componentes do sistema mínimo interligam-se corretamente
• Casos de teste e transações simples estão sendo processados corretamente
– Aspectos importantes
• Quais módulos devem ser interligados primeiro
• Quantos módulos devem ser interligados para começar os testes de integração
• Ordem para integrar os módulos (módulos críticos, grupos funcionais, nível superior para baixo, etc
Testes de Integração
• Módulos de nível superior – começar pelo programa de iniciação dos testes ou pelo módulo principal, plugando os módulos associados a eles. • Módulos críticos – começar pelos módulos críticos, integrando-os
primeiro, e depois acrescentar o restante.
• Módulos de nível inferior – começar pelos programas isolados assim que eles passarem pelos testes unitários.
• Módulos funcionais – selecionar uma função específica e integrar os módulos necessários para que ela se realize.
• Módulos disponíveis – trabalhar com os módulos à medida que ficarem prontos.
• Sistema mínimo completo – integre todos os módulos do sistema mínimo de uma vez só, e adie os testes de integração até que todas as interfaces estejam concluídas.
Testes de Integração
• Metodologia sugerida
1. Selecionar um grupo mínimo de módulos que componham uma das funções básicas do sistema e que não sejam difíceis de testar conjuntamente.
2. Interligar esses módulos de modo a formar um sistema mínimo que permita o processamento dessa função básica.
3. Teste a integração do sistema mínimo
1. Por à prova todos os parâmetros de entrada e saída de cada módulo. 2. Testar todos os módulos e chamadas de sub-rotinas.
3. Por à prova todas as opções dos programas e rotinas especiais. 4. Submeter o sistema mínimo ao teste de stress
1. Testar a carga.
2. Testar o desempenho.
3. Fazer o possível para que o sistema mínimo falhe. 5. Integrar o próximo grupo de módulos.
Testes de Integração
• O teste de integração é uma extensão lógica dos testes de unidade.• Na sua forma mais simples, duas unidades que já foram testados são combinadas em um componente e a interface entre eles for testada .
• Um componente , neste sentido, refere-se a um agregado integrado de mais do que uma unidade .
• Num cenário realístico, muitas unidades são combinados em componentes, que são, por sua vez agregadas em partes cada vez maiores do programa.
• A idéia é testar combinações de peças e, eventualmente, expandir o processo para testar seus módulos com os de outros grupos.
• Eventualmente todos os módulos que compõem um processo são testados em conjunto . • O teste de integração identifica os problemas que ocorrem quando as unidades são
combinadas.
• Usando um plano de teste que requer que você teste cada unidade e garantir a viabilidade de cada um antes da combinação de unidades, você sabe que todos os erros descobertos quando se combinam as unidades estão provavelmente relacionados com a interface entre as unidades.
Testes de Integração
Testes de Integração
• Bottom-up
• Módulos de mais baixo nível de teste individual de unidade primeiro. Módulos de nivel menor são combinados para formar subsistemas, os subsistemas testados, e assim por diante.
• Um ambiente artificial é necessário para cada teste de integração; o ambiente é composto por programas drivers e dados de teste, e é chamado de equipamento de teste.
Testes de Integração
• A integração é feita a partir do nível mais básico da
hierarquia. Os stubs nem sempre são necessários
– Os módulos do nível inferior são combinados.
– Para cada combinação é criado um driver que
coordena a entrada e a saída dos casos de teste.
• O módulo é testado.
• O driver é substituído pela combinação de módulos
correspondentes, que passam a interagir com os
módulos do nível superior
Testes de Integração
A
B
E
F
J
K
L
C
G
D
H
I
Testes de Integração
F
J
Testes de Integração
J
driver
E
F
Testes de Integração
A
B
E
F
J
K
L
C
G
D
H
I
driver
Testes de Integração
• Top-down
• Módulos no topo da estrutura são testados primeiro, começando pelo módulos principais ou de controle.
• Usa componente stubs
• NOTE: Para módulos chamados ainda não escritos, é necessário usar stubs, ou seja, módulos fantasma (dummy) simples usados para evitar erros de ligação.
Testes de Integração
• Os módulos são integrados de cima para baixo.
• O teste usa driver e stubs.
• O driver é utilizado como módulo de controle
principal, e os módulos reais são substituídos por
stubs.
• À medida que os testes vão sendo realizados os stubs
são substituídos pelos módulos reais, um de cada
Testes de Integração
• Exemplo:
A
B
E
F
J
K
L
C
G
D
H
I
Testes de Integração
A
B
stu
b
stu
b
stu
b
stu
b
driver
Testes de Integração
A
B
stu
b
stu
b
C
stu
b
stu
b
E assim por diante. Até que...
Testes de Integração
A
B
E
F
J
K
L
C
G
D
H
I
driver
Testes de Integração
• Big bang
• Não aconselhável:
– Necessita muitos drivers – Necessita muitos stubs – Difícil isolar falhas
Testes de Integração
• O driver é um programa principal que aceita dados de caso de teste, passa tais dados para o módulo a ser testado e imprime os dados relevantes. • Os stubs servem para substituir módulos que estejam subordinados ao
módulo a ser testado.
• Um stub ou programa simulado usa a interface do módulo subordinado, pode fazer manipulação de dados mínima, imprime verificação de entrada e retorna.
Testes de Integração
• Os testes top-down e bottom-up são puramente funcionais
• Usando abordagem estrutural podemos identificar
dependências entre unidades
• Duas técnicas:
– Por pares
– Por vizinhança
Testes de Integração
Testes de Integração
Teste de Sistemas
• Teste de Sistemas
• Começam após a conclusão dos testes de integração.
• Encerram quando se adquire confiança razoável nos recursos do sistema e no fato que os problemas foram satisfatoriamente corrigidos de modo a permitir o início dos testes de aceitação.
• O planejamento dos testes do sistema parte dos casos de teste funcionais. • Testes funcionais e de caixa preta para grupos de programas.
• Testes dos recursos funcionais do sistema
– Fornecer evidências sistemáticas de que todas as funções estão disponíveis tal como foram especificadas.
• Testes do desempenho do sistema
– Testes complementares necessários para medir os limites de desempenho do sistema: tempo de resposta, requisitos de processamento e tamanho dos arquivos.
Teste de Sistemas
• Tipos de testes em teste de sistemas
– Teste de interface gráfica de usuário - Graphical user interface testing – Teste de Usabilidade - Usability testing
– Teste de Desempenho do software - Software performance testing – Teste de compatibilidade - Compatibility testing
– Teste de exceção - Exception handling – Teste de carga - Load testing
– Teste de volume - Volume testing – Teste de stress - Stress testing
– Teste de segurança - Security testing – Teste de escalabilidade - Scalability testing – Teste de sanidade - Sanity testing
– Teste fumaça - Smoke testing
– Teste exploratório - Exploratory testing – Teste ad hov - Ad hoc testing
– Teste de regressão - Regression testing – Teste de instalação - Installation testing
Teste de Sistemas
• Teste de usabilidade
• Envolve a observação sistemática sob condições controladas para determinar o quão bem as pessoas podem usar o produto.
• A criação de um teste de usabilidade envolve a criação cuidadosa de um cenário, ou de uma situação realista, onde a pessoa executa uma lista de tarefas usando o produto que está sendo testado enquanto observadores observam e tomam notas.
• Vários outros instrumentos de teste, tais como instruções de script, protótipos de papel e questionários de pré-e pós-teste também são usados para obter feedback sobre o produto que está sendo testado.
• Por exemplo, para testar a função de anexação de um programa de e-mail, um cenário descreveria uma situação em que uma pessoa precisa para enviar um anexo de e-mail, e peça-lhe para realizar esta tarefa.
• Teste de Corredor (Hallway testing) é um método geral de testes de usabilidade. Ao invés de usar um grupo de testadores treinado “em casa”, apenas 5-6 pessoas aleatórias são trazidas para testar o produto ou serviço. O nome da técnica refere-se ao fato de que os testadores devem ser pessoas aleatórias que passam no corredor.
Teste de Sistemas
• Teste de Desempenho
• Em geral realizado para determinar como um sistema executa em termos de capacidade de resposta e estabilidade, sob uma carga de trabalho específica.
• Também pode servir para investigar, avaliar, validar ou verificar outros atributos de qualidade do sistema, tais como escalabilidade, confiabilidade e recursos de uso.
• O teste de desempenho é um subconjunto da engenharia de performance, uma prática
emergente da ciência da computação, que se esforça para dar desempenho na implementação, design e arquitetura de um sistema.
• Tipos:
• Teste de carga (Load testing) • Teste de stress (Stress testing)
• Soak testing - type of Performance testing in which we can test the stability and response time of the application by applying the designed load for a longer time. in this case the time duration may be normally 72hrs to 120 hrs
• Spike testing - Spike testing is done by suddenly increasing the number of or load generated by users
• Configuration testing • Isolation testing
Teste de Sistemas
• O teste de carga é o processo de colocar demanda em um sistema ou dispositivo e medir a sua resposta.
• É realizado para determinar o comportamento de um sistema em ambas as condições normal e de pico de carga esperados.
• Ele ajuda a identificar a capacidade máxima de operação de uma aplicação, bem como os gargalos e determinar qual elemento está causando degradação.
• Quando a carga colocada sobre o sistema é aumentada para além de padrões normais de utilização, de modo a testar a resposta do sistema à cargas
invulgarmente altas ou de pico, ele é conhecido como o teste de stress. • A carga geralmente é tão grande que as condições de erro são o resultado
esperado, apesar de não existir uma fronteira clara quando uma atividade deixa de ser um teste de carga e torna-se um teste de estresse.
• Há pouco acordo sobre quais são os objetivos específicos de testes de carga. O termo é freqüentemente usado como sinônimo de testes de simultaneidade, testes de desempenho de software, testes de confiabilidade e testes de volume.
Teste de Sistemas
• Teste de carga e desempenho analisa software destinado a um público multi-usuário, submetendo o software para diferentes números de usuários virtuais e ao vivo, enquanto monitora-se medidas de desempenho sob essas diferentes cargas.
• Teste de carga e desempenho é geralmente realizado em um ambiente de teste idêntico ao
ambiente de produção antes que o sistema de software está autorizada a ir ao ar.
• Como exemplo, um site web com capacidade do carrinho de compras necessária para suportar 100 usuários simultâneos, divididos nas seguintes atividades:
– Log in de 25 Usuários Virtuais (Vusers), navegar através dos itens e, em seguida, fazer logof – Log in de 25 VUsers, adicionar itens ao seu carrinho de compras, fazer check-out e, em
seguida, fazer logof
– Log in de 25 Vusers, devolver os itens comprados anteriormente e, em seguida, fazer logof – Login de 25 VUsers apenas, sem qualquer atividade subseqüente
• Um analista de teste pode usar várias ferramentas de teste de carga para criar esses Vusers e suas atividades.
• Uma vez que o teste começou e chegou a um estado de equilíbrio, o aplicativo está sendo testado na carga de 100 Vusers como descrito acima.
Teste de Sistemas
• FerramentasNome Companhia Obs
Apache JMeter Projeto open source
da Apache Jakarta
Aplicação desktop Java para testes de carga e medição de desempenho.
Silk Performer Borland Ferramenta de desempenho de
aplicativos com a nuvem e agentes virtuais locais. Suporta a maioria dos protocolos e aplicações. Licenciado.
Edição Ultimate do Visual
Studio Microsoft
Inclui uma ferramenta de teste de carga, que permite que um desenvolvedor execute uma variedade de testes (web, unidade, etc ..) com uma combinação de configurações para simular carga de usuários reais.
Rational Performance Test IBM Ferramenta de teste de desempenho de grande escala baseada no Eclipse, usada para execução de testes de desempenho de grande volume para medir o tempo de resposta do sistema para aplicações baseadas em servidor. Licenciado.
Teste de Sistemas
• Teste de stress
• Os testes de estresse, em geral, devem colocar o hardware do computador em níveis exagerados de estresse, a fim de garantir a estabilidade quando usado em um ambiente normal.
• Estes podem incluir extremos de carga de trabalho, tipo de tarefa, uso de memória, carga térmica (calor), a velocidade do clock, ou tensões (voltagem).
• Memória e CPU são dois componentes que são comumente testados em stress desta maneira. • Ao modificar os parâmetros de funcionamento de uma CPU, tais como temperatura,
overclocking, underclocking, overvolting e undervolting, pode ser necessário verificar se os novos parâmetros (geralmente voltagem do núcleo da CPU e freqüência) são adequados para cargas pesadas de CPU.
• Isto é feito através da execução de um programa intensivo de CPU por longos períodos de tempo, para testar se o computador trava ou falha (crash).
• Teste de estresse da CPU também é referido como o teste de tortura. Software que é adequado para testes de tortura normalmente deve executar instruções que utilizam o chip inteiro em vez de apenas algumas de suas unidades.
• O teste de stress de uma CPU, ao longo de 24 horas a 100% de carga é, na maioria dos casos, suficiente para determinar que a CPU vai funcionar corretamente em situações de uso normal, como num computador desktop, onde o uso de CPU normalmente oscila em níveis baixos (50 % ou menos) .
Teste de Sistemas
• Teste fumaça – Smoke Test
• Na programação de computadores e teste de software, teste de fumaça é o teste
preliminar para revelar falhas simples graves o suficiente para rejeitar uma versão do software em potencial.
• Um subconjunto de casos de teste que cobrem as funcionalidades mais importantes de um componente ou sistema é selecionado e executado, para verificar se as funções mais importantes de um programa trabalham corretamente.
• Por exemplo, um teste de fumaça podem fazer perguntas básicas, como "Será que o
programa executa?","Será que ele abre uma janela?", ou" Será que ao clicar no botão principal ele faz alguma coisa?"
• O objetivo é determinar se o aplicativo está tão mal que mais testes são desnecessários.
• Como o livro "Lições Aprendidas em Teste de Software" coloca, "testes de fumaça cobrem amplamente as características do produto em um tempo limitado ... se os principais recursos não funcionam ou se erros fundamentais ainda não foram corrigidos, sua equipe não vai perder mais tempo a instalar ou testar".
Teste de Sistemas
• Teste de regressão
• É um tipo de teste de software que visa descobrir novos bugs de software, ou regressões, em áreas funcionais e não-funcionais de um sistema existente, após mudanças como aprimoramentos, correções ou alterações de configuração, serem feitas neles.
• A intenção dos testes de regressão é de garantir que uma mudança tal como as mencionadas acima não introduziu novos defeitos.
• Uma das razões principais para os testes de regressão é para determinar se uma alteração em uma parte do software afeta outras partes do software.
• Os métodos comuns de testes de regressão incluem executar novamente os testes previamente realizados e verificar se o comportamento do programa mudou e se falhas previamente fixados reapareceram.
• O teste de regressão pode ser realizado para testar um sistema eficientemente, selecionando sistematicamente o conjunto mínimo adequado de testes
Testes de Aceitação
• Teste de aceitação
• Confirmar se um sistema está pronto para ser colocado em operação. • Realizados por outra pessoa (normalmente o usuário final)
– Ênfase às necessidades do usuário
– Estágio final do processo de aquisição de confiança – O envolvimento dos usuários é fundamental
Testes de Aceitação
• Cada teste individual, conhecido como um caso, exerce uma condição particular de operação do ambiente do usuário ou recurso do sistema, e irá resultar em um resultado de aprovação ou reprovação. Geralmente não há grau de sucesso ou fracasso.
• O ambiente de teste é normalmente desenhado para ser idêntico, ou o mais próximo possível, para o ambiente previsto do usuário, incluindo extremos.
• Esses casos de teste devem ser acompanhados por dados de entrada de caso de teste e/ou uma descrição formal das atividades operacionais a serem realizadas. As intenções são para elucidar completamente o caso de teste específico e a descrição dos resultados esperados.
• Testes de aceitação do usuário (UAT) consistem de um processo para verificar se a solução funciona para o usuário.
• Não é o teste do sistema (garantindo que o software não trava e atende aos requisitos documentados), mas está lá para garantir que a solução vai funcionar para o usuário, ou seja, testar que o usuário aceita a solução ( fornecedores de software muitas vezes referem-se a eles como testes Beta).
Casos de Teste baseado em casos de uso
• Garantir a qualidade do software desenvolvido é primordial paraconseguir o sucesso de qualquer projeto.
• Testá-lo adequadamente virou uma obrigação.
• Questão: Forma sistemática de como montar um plano de testes eficiente e consistente baseado em casos de uso.
• Uma das primeiras perguntas que devem ser respondidas para iniciar a montagem de um plano de testes é o que testar?
• Parece óbvio e a resposta é realmente essa: devemos testar as
funcionalidades que compõem o escopo do software que está sendo desenvolvido.
• Agora você pode perguntar, onde está descrito esse escopo?
• Pode estar na proposta do projeto, na especificação funcional e, em muitos projetos, nos casos de uso.
Casos de Teste baseado em casos de uso
• Os casos de uso descrevem requisitos, identificam o valor que o clienteespera obter da funcionalidade, e representam a forma como o sistema será utilizado.
• Permite identificar todos os caminhos que o usuário pode percorrer para conseguir o que deseja e se podem ocorrer problemas.
• Mostram ao cliente o que esperar do software, ao desenvolvedor o que codificar, e ao testador ou certificador o que validar para garantir a qualidade dos entregáveis.
• Desse modo, podemos concluir que os casos de uso ajudam na certificação e validação dos requisitos implementados.
• Simplificando e sistematizando o processo de teste do software, permitindo um ganho de produtividade e ajudando na garantia de que todo o escopo vai ser abrangido pelo teste.