O documento explora a importância do teste de software nos projetos de desenvolvimento, detalhando suas fases, tipos e metas. Os testes são cruciais para garantir a qualidade e descobrir defeitos, com custos que podem ser significativos, especialmente em sistemas críticos. Diferentes abordagens e métodos são discutidos, enfatizando a necessidade de planejamento apropriado para a realização de testes eficazes.

1. ENGENHARIA DE
SOFTWARE
TESTE DE SOFTWARE
André Neri
Jander Cerqueira

2. Agenda
• Introdução
• Fases Fundamentais e Metas dos Testes de Software
• Tipos de Testes
• Projeto de Casos de Testes
2

3. Através deste vídeo iremos mostrar 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.
3

4. No decorrer do desenvolvimento de um sistema existe uma grande
possibilidade de erros principalmente de falha humana, a fim de detectar e
corrigir esses erros utilizamos os testes, que segundo Pfleeger.. “Teste têm
como foco a detecção de defeitos, e existem muitos meios de tornar mais
eficientes e efetivos os esforços a eles relacionados”.
4

5. Nos projetos de desenvolvimento de software os testes estão diretamente
relacionados com a qualidade como é citado por Pressman. “A atividade de
teste de software é um elemento crítico da garantia de qualidade de software
e representa a ultima revisão de especificação, projeto e codificação.”
5

6. Na maioria dos casos os testes de software custa cerca de 40% dos
recursos total do projeto, mas quando se trata de sistemas críticos (por
exemplo, controle de voo, monitoração de reatores nucleares) o custo pode
chegar a cinco vezes mais do que as outras etapas do projeto. Porem nem
todas as empresas dedicam-se a essa etapa adequadamente alegando prazo
curto, custo elevado, falta de profissionais adequados, complexidade do software
e até mesmo a falta de conhecimento dos benefícios dos testes de software.
6

7. 7
Fases Fundamentais e Metas
dos Testes de Software.

8. Os sistemas são divididos em duas fases de testes, os testes de
componentes, onde são testados em partes e teste de sistema quando o
sistema é completamente testado. O alvo dos testes de componentes é através
dos componentes individuais (funções, objetos ou componentes reusáveis) do
programa localizar defeitos. Já o objetivo do teste de sistema é integrar os
componentes, formando o sistema completo assim verifica se o sistema atende
os requisitos funcionais e não funcionais e se comporta de maneira esperada,
e se alguma imperfeição passar pelo teste de componente poderá ser corrigido
pelo teste de sistema.
8

9. Os testes de software visam duas metas, a primeira meta é demonstrar ao
desenvolvedor e ao cliente que o software atende aos requisitos demostrando
pelo menos um teste por requisito que esteja na documentação, através de um
conjunto de teste é esperado que o programa seja executado como o
esperado sem nenhum tipo de erro.
9

10. A outra meta é descobrir falhas ou defeitos no software que apresenta
comportamento incorreto, não desejável ou em não conformidade com sua
especificação onde são removidos os travamentos, interações indesejáveis e
dados corrompidos, essa meta usa o teste de defeitos utilizando casos de
testes para mostrar defeitos. Desta forma a principal meta dos testes de
software é provar para os desenvolvedores e clientes que o programa está
apto para ser utilizado.
10

11. Tipos de Testes
Como observamos anteriormente os testes são divididos em testes de
componentes e teste de sistemas esses testes contem subdivisões que facilita o
teste em cada etapa do projeto. Vamos iniciar falando sobre as fases do teste
de sistema que possui teste de integração, teste de releases e teste de
desempenho. Depois vamos para as fases dos testes de componentes que
abrange teste de interface.
11

12. Teste de Integração
Esse teste está ligado à descoberta de defeitos do sistema onde é acessado o
código fonte do sistema e todo problema. encontrado tenta-se localizar a
origem, e identificar os componentes afetados. O teste de integração, verifica se
efetivamente os componentes funcionam, em conjunto, se são chamados
corretamente. e se trocam dados no tempo certo.
12

13. Teste de Integração
A estratégia de integração top-down, é a criação do esqueleto do sistema, e
depois a adição dos componentes a ele, já a integração bottom-up é a
integraçã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 componentes
funcionais. A estratégia mais utilizada é a combinação dessas duas estratégias
anteriores com os componentes de infra-estrutura e funcionais adicionados em
incrementos.
13

14. Teste de Integração
O principal problema no teste de integração é localização dos erros para facilitar a
descoberta de erros é usada a abordagem incremental para integração e teste do
sistema. Primeiramente tem que integrar uma configuração mínima do sistema e
testar, 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 T5
são os testes.
14

15. Teste de Releases
Com o propósito de mostrar que o programa atende aos requisitos, o teste de
releases também conhecido como teste de caixa-preta e teste funcional tem o foco na
funcionalidade e não na implementação. Procura encontrar erros nas funções
incorretas ou ausentes, erros de interface, erros nas estruturas de dados, erros de
desempenho e erros de inicialização e finalização.
15

16. Teste de Releases
O método particionamento de equivalência é utilizado para definir um caso de teste
que encontre classes de erros, para reduzir o numero de casos de teste. Avaliando as
condições de entrada através de um conjunto de estados válido ou inválido conhecido
como classe de equivalência.
16

17. Teste de Releases
Na imagem a acima ilustra o modelo de teste caixa-preta onde são fornecidas as
entradas para o componente ou sistema e são examinadas as saídas; caso a saída
nã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 muito
pequenos, forçar geração de saídas invalidas, repetir a mesma entrada e forçar
entradas que causam overflow dos buffers.
17

18. Teste de Desempenho
Depois que todos os requisitos funcionais foram testados e todas as funções exigidas
estão funcionando é chegado à hora de começar a fazer os testes não funcionais e
um dos pontos que são bastante exigidos é o desempenho. O teste de desempenho
tem um conjunto de outros testes envolvidos como: testes de estresse, testes de
volume, testes de tempo, testes de ambiente, testes de qualidade, testes de
recuperação e testes de manutenção. 18

19. Teste de Estresse
Porem o teste de estresse é o mais utilizado, na maioria dos casos os sistemas são
projetados para atender um numero especifico de usuários ou transações o teste de
estresse testa o programa além da carga máxima até que ele falhe, o objetivo desse
teste é verificar qual será o impacto do sistema caso aconteça de ultrapassar o limite
projetado e verificar se vai haver surgimento de novos defeitos depois do limite
atingido. 19

20. Teste de Interface
Os erros de interfaces dos componentes compostos não podem ser identificados
através de testes de objetos ou componentes individuais sendo encontrado apenas na
interação entre as suas partes.
A figura mostra o processo de teste de interface dando uma visão que o teste
não é realizado nos componentes individuais e sim na interface do componente
composto.
20

21. Projeto de Casos de Testes.
Projeto de casos de teste é o conjunto de entradas e saídas esperadas, que sejam
utilizados tanto nos testes de sistemas como de componentes. Para realizar o projeto
de casos de teste é escolhida uma característica do sistema que será testado, então
ocorre uma seleção das entradas que vai ser executada no teste, depois verifica se as
saídas correspondem com o esperado. Podemos utilizar basicamente três tipos de
abordagens na elaboração do projeto de casos de testes que são: teste baseado em
requisitos, teste de partições, teste estrutural e o teste de caminho que é uma
estratégia de teste estrutural. 21

22. Teste Baseado em Requisitos.
Na etapa de requisitos do sistema tem que ser definido que os requisitos devem ser
testáveis, ou seja, os requisitos devem ser escritos com o intuito de ser testados
futuramente para verificar se os requisitos foram atendidos como o solicitado. Portanto
teste baseado em requisitos é o conjunto de teste elaborado para cada requisito
registrado na fase de levantamento, essa técnica é essencial para verificar requisitos
vagos ou ausentes.
22

23. Teste Baseado em Requisitos.
O teste baseado em requisitos é um teste de validação isto é ele demonstra que o
sistema tem seus requisitos adequadamente implementados.
23

24. Teste Baseado em Requisitos.
Iremos ver um exemplo prático onde é listado um requisito de um sistema e seus
possíveis testes
24

25. Teste Baseado em Requisitos.
R1 - O usuário será capaz de procurar todo o conjunto inicial do banco de
dados 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 iniciar
as buscas pelos itens cuja presença ou ausência são conhecidas. 25

26. Teste Baseado em Requisitos.
Concluímos que para cada requisito podem ser feitos vários testes para assegurar que
o requisito foi devidamente concluído.
26

27. Teste de Partições.
O teste de partições visa identificar todas as partições do sistema ou componentes, e
que 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ção
ou através da experiência dos projetistas que prevê classes que podem conter valores
de entradas com grande probabilidade de erros.
27

28. Teste Estrutural.
Também conhecido como teste de caixa-branca, o teste estrutural é uma abordagem
onde os testes são derivados do conhecimento da estrutura e da implementação do
software. Avalia o comportamento interno do componente de software, essa técnica
trabalha diretamente sobre o código fonte do componente de software para avaliar
aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste
de caminhos lógicos e códigos nunca executados. O testador tem acesso ao código
fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e
componentes, esta é uma técnica de teste geralmente realizada pelos
desenvolvedores que trabalha diretamente com o código-fonte do sistema.
28

29. Teste de Caminho.
O teste de caminho tem o objetivo de percorrer cada componente ou o sistema por
completo testando as condições tanto verdadeiras como falsas. O numero de
caminhos é relativamente proporcional ao tamanho do sistema, logo é mais viável a
utilização do teste de caminho na etapa de teste de componentes. O teste faz com
que pelo menos uma vez cada caminho seja executado.
29

30. Considerações Finais.
Concluímos que o processo de teste de
software faz com que a qualidade, a
credibilidade, a confiança e a competitividade
do software cresçam. Aprendemos também que
os testes estão subdivididos e que a depender
da necessidade podemos utilizar, a combinação
de dois ou mais testes. E que devemos planejar
e deixar uma boa quantidade recursos para
essa etapa do projeto, que em alguns casos
chega ser a etapa mais importante do projeto de
desenvolvimento de um sistema.
30

31. Referências
SOMMERVILLE, 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: Pearson
Makron Books, 1995.
31