M6 #2 - Tipos de teste

Página 1

Apresentação

Os projetos de desenvolvimento de software são passíveis de erros, falhas e defeitos, mesmo que tenham sido elaborados de maneira cuidadosa. Em vista disso, as atividades de testes se tornam fundamentais durante todo o ciclo de vida do projeto, para indicar se os requisitos do software estão sendo respeitados e também se as expectativas e as necessidades dos clientes estão sendo levadas em conta. Para cada fase do projeto existem diferentes tipos de testes que podem ser realizados, mas o importante é testar, para garantir a entrega de um produto de qualidade aos clientes.

Nesta Unidade de Aprendizagem, você vai estudar os fundamentos dos testes de software, a verificação, a validação estática e a dinâmica, além das categorias e os tipos de teste de software e suas etapas.

Bons estudos.

Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:

Explicar os fundamentos dos testes de software.

Descrever a verificação, a validação estática, a validação dinâmica e as categorias de teste de software.

Diferenciar os tipos de teste de software e suas etapas (o que testar, como testar e quando testar).

Página 2

Fundamentos dos testes de software

As áreas de engenharia costumam combinar atividades de projeto e construção com atividades de verifi cação intermediária do que está sendo produzido e de verifi cação fi nal do produto pronto. Tudo isso seve para que as falhas, erros e defeitos sejam identifi cados, reduzidos e até mesmo eliminados por completo. Na ciência da computação, a disciplina de engenharia de software trata seus produtos informatizados da mesma forma. Durante o trabalho de desenvolvimento de um software de qualidade, tanto as atividades de projeto quanto as atividades de verificação têm papel fundamental para o sucesso final. As atividades de verificação podem ser entendidas como as atividades de testes.

As atividades de teste são fundamentais para os projetos de desenvolvimento de software, principalmente pelos seguintes motivos

 descobrir defeitos, falhas e erros no software antes que ele seja entregue ao cliente;

 demonstrar que o software atende aos requisitos e às necessidades dos usuários que vão realizar as suas tarefas por meio dele;

 garantir maior segurança aos usuários na utilização do software entregue;

 aumentar a possibilidade de continuidade do negócio dos clientes;

 melhorar a qualidade dos softwares produzidos, devido à experiência adquirida com os projetos desenvolvidos;

 melhorar a imagem do software e da própria fábrica de software perante os clientes e usuários, por fornecer produtos que atendem às suas expectativas;

 diminuir ao máximo o tempo e as despesas gastos na correção de problemas.

Apesar de parecer um paradoxo, a verdade é que a tentativa de destruir a confiabilidade de um software por meio da identificação de erros, defeitos e falhas resulta no aumento da sua confiabilidade. Isso acontece pois, uma vez corrigidos todos os problemas, o produto entregue ao cliente atende objetivamente às suas necessidades, tornando agradável a experiência de utilizá-lo. É importante você notar que, quanto mais cedo os testes forem iniciados, menores serão o custo e o prazo utilizados na correção dos problemas encontrados. Por isso, existem estágios pelos quais os testes de software normalmente passam

Página 3

Veja a descrição dos estágios a seguir:

 Planejamento: elaboração e revisão da estratégia e do plano de teste.

 Preparação: preparação do ambiente de testes, incluindo equipamentos, softwares, rede, pessoal e ferramentas.

 Procedimentos iniciais: elaboração de um documento que estabelece o acordo entre as partes envolvidas nos testes (objetivo, pessoal, responsabilidades, etc.).

 Especificação: elaboração e revisão dos casos de teste manuais (roteiros de testes) e automáticos (scripts).

 Execução: execução dos testes planejados conforme os casos de teste elaborados e geração dos registros de resultados (relatórios de testes).

 Entrega: conclusão do processo de testes com a entrega da parte ou do todo do sistema.

Página 4

Verificação, validação estática, validação

dinâmica e categorias de teste de software

Atualmente, as empresas fabricantes de softwares já conseguem compre-

ender melhor que a realização dos testes faz parte do processo de verificação

e validação. Tal processo, por sua vez, é fundamental para a avaliação e para

a manutenção da qualidade requerida de um produto de software.

A verificação e a validação têm como propósito principal garantir que o

software esteja adequado aos seus objetivos e que atenda às expectativas dos

clientes. Em outras palavras, essas etapas garantem que o software cumpra

as suas especificações, aquilo a que ele se propõe

Na verificação, existe uma análise para entender se o software atende aos

requisitos funcionais e não funcionais que foram definidos para ele. A atividade

de validação consiste em verificar se o software atende às expectativas e

necessidades do usuário final. Apesar de esses dois termos terem significados

diferentes, as duas atividades não acontecem de maneira independente ou

sequencial. As atividades de verificação e de validação têm início até mesmo antes

que um projeto de desenvolvimento de software seja idealizado. Isso porque

é preciso que os gestores de projeto e de tecnologia de informação tenham

em mente se a sua equipe possui as competências necessárias. Ou seja,

eles devem verificar se a sua equipe tem o conhecimento, a habilidade e a

atitude necessárias para desenvolver produtos de software que satisfaçam

às necessidades e expectativas dos usuários. Essa verificação se chama

estudo de viabilidade.

Página 5

Na área da administração, a competência de um funcionário é definida pelo conjunto

de três elementos. Veja a seguir.

 Conhecimento: é o saber. É tudo o que se adquire por meio de cursos, treinamentos,

livros, experiência de vida.

 Habilidade: é o saber fazer. É aquilo que depende de prática, de treino, de saber

lidar com os acertos e com os erros cometidos.

 Atitude: é o querer fazer. É a ação necessária para colocar em prática os conheci-

mentos e a habilidade. Normalmente, é o elemento essencial para mudanças de

procedimentos.

Se o estudo de viabilidade for positivo e indicar que a equipe é capacitada

para participar do projeto, então as atividades de verificação e validação

começam. Elas ocorrem juntamente às atividades de desenvolvimento, tendo

fim depois que o produto final for liberado para o cliente.

Atualmente, é natural que os produtos de software sejam entregues em

etapas, passando por reavaliações e ajustes dos requisitos, caso sejam neces-

sários. Por esse motivo, é muito importante que as atividades de verificação e

validação sejam pensadas de antemão, para que se consiga cumprir a previsão

de custos e prazos.

O estudo de viabilidade é a primeira atividade que deve ser realizada

em um projeto de software rumo à entrega de um produto satisfatório. Esse

estudo está aliado às atividades de verificação, validação e desenvolvimento.

São as atividades de verificação que avaliam se o produto que está sendo

construído tem coerência com os requisitos e com a qualidade esperada,

tanto nas entregas em etapas como no produto final. No caso das atividades

de validação, é avaliado se existe coerência entre os produtos intermediários

e o final apresentados ao usuário. Além disso, são avaliadas as expectativas

do usuário para o software

Página 6

 Eficácia para diferentes classes de erros: por exemplo, condições de

corrida são muito difíceis de se encontrar com teste convencional, mas

podem ser detectadas com análise estática.

 Aplicabilidade em diferentes etapas do projeto: por exemplo, você

pode aplicar técnicas de inspeção inicialmente aos requisitos e re-

presentações de projeto que não são apropriados para análises mais

automáticas.

 Diferenças de objetivos: por exemplo, o teste sistemático (não randô-

mico) busca maximizar a detecção de falhas, mas não pode ser usado

para medir confiabilidade; para isso, o teste estatístico é necessário.

 Compromissos entre custo e garantias: por exemplo, você pode utilizar

uma técnica relativamente custosa para garantir algumas propriedades

essenciais de componentes centrais (como um kernel de segurança),

enquanto as mesmas técnicas seriam caras demais se aplicadas a todo

o projeto.

É importante você entender que, quando a validação é feita utilizando

padrões e ferramentas automatizadas de testes, esse tipo de validação é cha-

mado de estático. Já quando a validação é feita de maneira diferente para cada

funcionalidade ou para cada sistema, levando-se em conta que cada produto

de software tem suas características próprias, esse tipo de validação se chama

dinâmico e normalmente é feito de maneira manual.

Por fim, os testes de integração, que são elaborados pela equipe de qualidade

ou por aqueles analistas que tiverem esse papel, testam as funcionalidades de

maneira integrada. A ideia é indicar se elas funcionam quando precisam se

comportar como um sistema. São testados os diferentes caminhos possíveis

dentro dos programas, identificando se o sistema funciona de maneira global.

Página 7

Testes de software e suas etapas

Ainda que o planejamento do desenvolvimento de um produto de software tenha

sido elaborado de maneira detalhada e cuidadosa, é praticamente impossível

que as partes do software ou o produto final sejam entregues sem algum tipo

de problema, como defeitos, erros e falha

SAIBA MAIS

Quando o projeto já está mais adiantado, os casos de teste se apresentam

como uma técnica para, principalmente, verificar as interfaces com os usuários

e identificar o quanto os testes unitários utilizam cada interface. Isso serve

para indicar se as especificações de interface estão completas ou não.

Por fim, os testes de integração, que são elaborados pela equipe de qualidade

ou por aqueles analistas que tiverem esse papel, testam as funcionalidades de

maneira integrada. A ideia é indicar se elas funcionam quando precisam se

comportar como um sistema. São testados os diferentes caminhos possíveis

dentro dos programas, identificando se o sistema funciona de maneira global.

Testes de software e suas etapas

Ainda que o planejamento do desenvolvimento de um produto de software tenha

sido elaborado de maneira detalhada e cuidadosa, é praticamente impossível

que as partes do software ou o produto final sejam entregues sem algum tipo

de problema, como defeitos, erros e falhas (PEZZÈ; YOUNG, 2008).

Um produto de software pode apresentar problemas. A seguir, veja como esses

problemas podem ser classificados.

 Erro: é qualquer erro humano que resulta em algo incorreto. Um erro acontece

quando existe uma diferença entre o valor obtido em uma operação matemática

e o valor que era esperado.

 Defeito: é qualquer inconsistência do software, evidenciando algo que foi imple-

mentado ou programado de maneira incorreta. Um exemplo acontece quando

existem incorreções nas linhas de código-fonte. Todo defeito é causa de erros,

mas, por outro lado, se a linha que estiver incorreta jamais for executada, o erro

não vai acontecer.

 Falha: é qualquer comportamento inesperado realizado pelo software. Uma falha

pode ter sido gerada por vários erros, mas alguns erros podem nunca gerar uma

falha. É o caso de uma operação aritmética que é programada e não é usada

Página 8

TIPOS DE TESTES

 Teste unitário: normalmente é realizado pelos próprios desenvolvedo-

res, nas porções menores do software que estão sendo desenvolvidas

no momento, de maneira individualizada. Ele serve para verificar se

as partes do software funcionam de maneira isolada das demais partes

do sistema.

 Teste de caixa branca: avalia a parte interna do software, seu código-

-fonte. Ele serve para identificar problemas na lógica de programação

e também na estrutura do programa, observando elementos como as

condições usadas, os laços de repetição e o fluxo tomado pelos dados. O

testador deve lembrar-se de verificar se o nível de segurança e confiança

exigido está sendo implementado.

 Teste de caixa preta: avalia a parte externa do software, o seu modo de

funcionamento. Esse tipo de teste serve para identificar se o software

está funcionando como deveria, se os dados informados resultam nas

informações pretendidas e se, de maneira geral, o sistema faz o que

ele deveria fazer.

 Teste de caixa cinza: é uma combinação dos testes de caixa branca e de

caixa preta, pois ele avalia os aspectos internos e também os aspectos

externos do software, as suas entradas, o fluxo dos dados e as saídas.

 Teste de regressão: tem a função de testar cada nova versão do software

toda vez que uma funcionalidade for modificada. Ou seja, toda a parte

pronta do software será testada novamente para verificar se alguma

novidade resultou em problema. Esse tipo de teste é muito importante

para indicar se erros que já haviam sido corrigidos não voltaram a se

manifestar.

 Teste de integração: tem como propósito verificar se as porções me-

nores, testadas anteriormente pelos testes unitários, têm condições

de funcionar em conjunto, formando um sistema. Esse teste é muito

importante, pois funcionalidades que operam perfeitamente de maneira isolada podem apresentar problemas quando tentam, por exemplo,

realizar o fluxo de dados de uma parte do sistema para outra.

 Teste de volume: esse teste tem como objetivo avaliar até que limites

um software pode ser utilizado, ou seja, qual é o seu limite de suporte

a informações ou tráfego sem que apresente nenhum problema.

 Teste de performance: divide-se em outros três tipos, listados a seguir.

■ Teste de carga: verifica o software como um todo, em condições

normais de uso, avaliando o tempo de resposta das operações, quantas

operações podem ser executadas em determinado período de tempo,

quantos usuários simultâneos gravando dados podem existir, entre

outros aspectos.

■ Teste de estresse: identificados os limites do software por meio dos

testes de volume, esse teste serve para levar o software aos seus limites.

A ideia é verificar em que ponto ele para de funcionar corretamente.

■ Teste de estabilidade: verifica se o software se mantém funcionando

de maneira adequada depois de ser utilizado por um longo período

de tempo.

 Teste funcional ou de funcionalidade: verifica se o software como um

todo, bem como cada parte dele, faz exatamente o que deveria fazer, ou

seja, se os casos de uso foram corretamente descritos e desenvolvidos.

 Teste de segurança: verifica se o software permite que os dados sejam

acessados somente pelos perfis determinados para cada parte específica

do sistema ou para cada funcionalidade.

 Teste de usabilidade: é realizado por usuários e não por analistas. O seu

propósito é verificar se o software satisfaz as necessidades do usuário.

Esse teste serve para identificar a forma como o usuário utiliza as

funcionalidades do software, na tentativa de apontar partes do sistema

em que ele apresenta maior dificuldade de interação. Como esse teste é

feito pelos clientes, é importante o acompanhamento de analistas para

documentar comentários, sugestões e reclamações.

 Teste de aceitação: serve para verificar se o produto de software está

pronto para ser entregue ao cliente, ou seja, se ele está pronto para entrar

em produção. Geralmente, esse teste é realizado por alguém indicado

pelo cliente, ou ainda por um testador especializado que não tenha

participado do projeto, mas que tenha grande conhecimento acerca

dos requisitos do software.

 Teste de instalação: tem como propósito verificar se o software é pas-

sível de ser instalado de maneira correta, em diferentes hardwares, com

diferentes sistemas operacionais e diferentes disposições de memória,

rede, entre outros aspectos.

 Teste de configuração: serve para identificar se o software funciona

de maneira adequada no hardware para o qual foi planejado e no qual

será instalado.

 Teste de manutenção: avalia se determinada mudança em algum as-

pecto do software resultou em falhas no seu funcionamento como um

todo