TESTE DE SOFTWARE np2

Prévia do material em texto

TESTE DE SOFTWARE 
Motivação do Teste de SW 
• Mercado de soluções cada vez mais competitivo; melhores 
práticas e soluções tecnológicas que atendam aos requisitos 
estabelecidos. 
• A adoção de processos no desenvolvimento de produtos de 
software. 
• Nesse contexto, procura-se: 
• Funcionalidades: alinhamento com os requisitos. • Prazo: rápido e 
suficiente. • Custo: adequado. • Qualidade: relevante para os clientes. 
O Teste de SW provê a informação para direcionar o projeto, reduzir e 
gerenciar riscos e garantir o reparo dos erros importantes. 
• Frequentemente, o Teste de SW é responsável pela conformidade 
contratual ou regulatória de um projeto. 
• Originalmente, o Teste de SW é parte da estratégia de garantia da 
qualidade onde a análise da causa raiz permite reduzir a incidência 
de falhas. 
Veremos que as revisões técnicas são mais eficazes na detecção e 
remoção de defeitos, porém, os testes são importantes para 
complementar às revisões e aferir o nível de qualidade proposto. 
• Apesar da sua relevância, a realização de testes é, quase sempre, 
limitada por restrições de cronograma e orçamento. 
Os Testes de SW são indicadores da qualidade do produto, mais 
do que meios de detecção e correção de erros. • Quanto maior o número 
de defeitos detectados em um software, provavelmente maior também o 
número de defeitos não detectados. 
• A ocorrência de um número anormal de defeitos em uma bateria de 
testes indica uma provável necessidade de redesenho dos itens testados. 
O conceito de Erro, Defeito e Falha 
Definições da norma IEEE 610 
• Um defeito ocorre quando uma pessoa comete um engano, chamado de 
erro, na realização de alguma 
atividade relacionada ao desenvolvimento de SW. 
• O especificador do projeto pode não compreender 
corretamente um requisito e criar um projeto que não condiz com a 
verdadeira intenção do cliente. Esse defeito do projeto é uma codificação 
do erro e pode levar a outros defeitos. 
A falha pode ser descoberta antes ou depois de o sistema ser entregue ao 
cliente, durante os testes ou durante a operação e a manutenção. 
• Como a documentação dos requisitos pode conter defeitos, uma falha 
indica que o sistema não está atuando como requerido, embora ele possa 
estar atuando conforme o especificado. 
Portanto, um defeito é uma visão interna do sistema, observada pelo 
ponto de vista dos desenvolvedores, enquanto uma falha é vista à partir 
de um referencial externo ao sistema: um problema que o usuário vê. 
• Nem todo defeito corresponde a uma falha. Se um código com defeitos 
nunca for executado ou se um estado específico nunca ocorrer, então o 
defeito nunca fará o código falhar. 
O que é um BUG? 
Quando ocorre? 
• Na interpretação errônea de um requisito e/ou na especificação do 
sistema. 
• Na codificação/sintaxe do código fonte. 
• Quando existe falta de familiaridade com a tecnologia utilizada. 
• Na integração de múltiplos sistemas. 
 
 
 
Quem deve testar? 
• Os desenvolvedores não são as pessoas mais adequadas para testar seus 
próprios produtos. 
• Assim como nas revisões aos pares, os autores têm maior dificuldade em 
enxergar problemas, comparados com pessoas que não participam do 
desenho e da implementação. 
• Logo, o desenvolvedor tem uma “visão menos crítica” de seu próprio 
trabalho. 
O planejamento e o desenho dos testes devem ser feitos por pessoas 
experientes, que conheçam adequadamente a metodologia de testes 
utilizada, bem como a tecnologia e o produto que se pretende validar. 
• Por outro lado, a execução de testes baseados em planos e 
especificações de testes bem detalhados pode ser feita por pessoas 
menos experientes, ou até parcialmente automatizada. 
Postura pragmática: O testador pragmático é realista e objetivo; suas 
decisões são baseadas no seu conhecimento teórico e prático das técnicas 
de teste e nas ferramentas disponíveis no mercado. 
• Flexível: flexibilidade é um pré-requisito para qualquer profissional de TI 
e na atividade de testes é exigido mais ainda, pois os requisitos mudam, os 
prazos afunilam e o especialista em teste não pode ser a verso as 
mudanças e deve-se adaptar com facilidade as novas realidades. 
• Criativo: deve pensar em todas as situações possíveis de teste e até as 
que aparentam ser impossíveis. 
• Crítico: colocar sempre em dúvida aquilo que está em teste, não se 
contentar com resultados aparentes, ter um olhar crítico. 
• Incansável: sempre interrogar e investigar a causa raiz dos problemas; 
testar a exaustão o software, nunca acreditar que não há mais defeitos. 
 
 
• Assertivo: nunca pressupõe ou se baseia em informações subjetivas; 
suas suposições são aferidas a fim de garantir a sua veracidade. 
• Diplomata: foca os seus esforços nos problemas ao invés de focar nas 
pessoas que os causaram; deve saber se comunicar com o desenvolvedor, 
nunca desprezar ou criticar negativamente o seu trabalho. 
• E por fim, o especialista em teste deve ser um generalista, alcançando 
conhecimentos gerais que muitas vezes não são o alvo do teste. 
Objetivos do Teste de SW 
• Localizar os erros na build, provendo informações consistentes aos 
desenvolvedores de maneira que seja possível identificar as causas do 
defeito e corrigi-lo. 
• Adquirir confiabilidade sobre o nível de qualidade da aplicação. 
• Prevenir defeitos através do envolvimento da equipe de testes desde o 
início do projeto, passando pelas revisões, até o planejamento avançado 
da fase de validação. 
Um objetivo fundamental de toda a metodologia dos testes é maximizar a 
sua cobertura, ou seja, a quantidade potencial de defeitos que podem ser 
detectados por meio da fase de validação. 
• Deseja-se conseguir detectar a maior quantidade possível de defeitos 
que não foram apanhados pelas revisões, dentro dos limites de custo e 
prazo estipulados para o projeto. 
• Prover informações sobre os aspectos fundamentais que envolvem a 
qualidade da aplicação. 
• Para serem eficazes, os testes devem ser cuidadosamente desenhados e 
planejados. 
• Testes irreproduzíveis são inúteis e devem ser evitados. 
• Durante e após a realização dos testes, os resultados de cada teste 
devem ser minuciosamente inspecionados, comparando se resultados 
previstos e obtidos, pois nem sempre é óbvio quando um teste detectou 
um defeito. 
 
 
 
Métodos e Técnicas de Teste 
• Basicamente, existem duas maneiras para construção dos casos de 
teste: 
• Método da caixa branca: tem por objetivo determinar defeitos na 
estrutura interna do produto, através do desenho de testes que exercitem 
suficientemente os possíveis caminhos de execução. 
• Também chamado de Teste Estrutural, pode detectar, entre outros, 
falhas de sintaxe ou ausência de comandos, por exemplo. 
Método da caixa preta: tem por objetivo determinar se os requisitos 
foram total ou parcialmente atendidos pelo produto. 
• Os testes de caixa preta não verificam como ocorre o processamento, 
mas apenas os resultados produzidos. 
• Também chamado de Teste Funcional, pode detectar, entre outras, 
funções não implementadas ou erros nas interfaces do sistema. 
Testes de Unidade têm por objetivo verificar um elemento que possa ser 
logicamente tratado como uma unidade de implementação. Identifica 
erros nos módulos de um sistema individualmente, antes que possam ser 
integrados. 
• Em produtos implementados com tecnologia orientada a objetos, uma 
unidade é tipicamente uma classe. 
Apenas unidades especialmente críticas possuem Testes de Unidade 
realizado em baterias devidamente formalizadas. 
• Seriam unidades cuja falha pudesse acarretar consequências graves, 
como risco de vida ou perdas materiais consideráveis. 
• Normalmente, os testes de unidades são feitos pelos próprios 
desenvolvedores, como parte do fluxo de implementação. 
 
 
 
 
Testes de Integração têm por objetivo verificar as interfaces de uma 
arquitetura de produtoa medida que são agrupadas. 
• Esses testes têm por objetivo verificar se as unidades implementadas em 
cada iteração funcionam corretamente, em conjunto com as unidades já 
implementadas em iterações anteriores, realizando corretamente os casos 
de uso que se quer nessa iteração. 
• Existe tipicamente uma bateria de testes de integração para cada 
iteração de desenho implementável. 
Testes de Sistema validam o produto como um todo, verificando se as 
funcionalidades atendem aos resultados esperados (Testes Funcionais). 
• Esta validação tem por objetivo verificar se a aplicação cumpre os 
requisitos inicialmente propostos. 
Uma categoria especial de baterias de teste é formada pelos Testes de 
Regressão, que executam novamente um subconjunto de testes 
previamente executados em uma das baterias anteriormente descritas. 
• Seu objetivo é assegurar que alterações em partes do produto não 
impactaram em partes anteriormente implementadas. 
Os testes de regressão, via de regra, devem ser automatizados, pois 
representam um aumento considerável ao escopo de testes, impactando 
diretamente em esforço e prazo. 
• É importante esclarecer que a automatização de testes não deve ser 
considerada como a única e melhor solução na performance e qualidade 
da fase de testes; tornar um escopo de testes automático tem custo e 
prazo relevante, sendo necessário determinar se o ganho a ser atingido 
justifica sua implementação. 
Testes de Aceitação têm por objetivo validar o produto, ou seja, verificar 
se ele atende aos requisitos especificados sob a óptica do cliente. 
• Neste contexto, os testes devem (preferencialmente) ser executados no 
ambiente do cliente e supervisão do fornecedor. 
• Essa bateria é parte do procedimento que atesta a aceitação do produto 
pelo cliente. 
 
O Teste Não-funcional deve ser executado para medir as características 
que podem ser quantificadas em uma escala variável, como o tempo de 
resposta em um teste de performance. 
• Exemplo de requisitos não-funcionais: 
• Segurança 
• Desempenho 
• Manutenibilidade 
• Portabilidade 
• Confiabilidade 
Os Testes Não-funcionais podem ser realizados em todas as fases de teste 
e são normalmente executados com ajuda de ferramentas especializadas, 
com grande planejamento, avaliação arquitetural e aplicando técnicas 
avançadas de validação. 
Considerações Finais 
• É importante que os todos os envolvidos na produção de software 
reconheçam que não é possível desenvolver sistemas com qualidade, 
cumprir prazos e custos e atender às expectativas dos usuários sem ter 
um processo de testes definido, compreendido e utilizado por toda a 
equipe. 
• O teste de software é hoje um dos fatores críticos para o sucesso no 
desenvolvimento de software e consequente manutenção das empresas 
neste ramo.