ENGENHARIA DE SOFTWARE

TESTE DE SOFTWARE

André NeriJander Cerqueira

Agenda

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

2

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

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

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

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

Fases Fundamentais e Metas dos Testes de Software.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Teste Baseado em Requisitos.

Iremos ver um exemplo prático onde é listado um requisito de um sistema e seus possíveis testes

24

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

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

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

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

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

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

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