Aula01 Teste

Prévia do material em texto

www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
Introdução ao Teste de 
Software 
Prof. Dr. Sandro Bezerra - srbo@ufpa.br 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
AGENDA 
• Verificação e Validação 
• Motivação para teste 
• Finalidades dos Testes 
• Testes de Software: Definições e Conceitos 
• Formando a Equipe de Testes 
• Relacionando as atividades de Testes com as de Desenvolvimento 
• Processo de Teste 
• Gerenciamento de Bugs 
• Ferramentas de Teste 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
OBJETIVO 
• Apresentar uma abordagem geral sobre o 
processo de teste de software, abrangendo 
seus principais fundamentos técnicos e 
gerenciais. Além disso, serão apresentados os 
principais conceitos necessários para um bom 
entendimento sobre as atividades de teste. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
VERIFICAÇÃO E VALIDAÇÃO 
• O desenvolvimento de software está sujeito a diversos 
tipos de problemas, os quais acabam resultando na 
obtenção de um produto diferente daquele que se 
esperava. 
• Muitos fatores podem ser identificados como causas de 
tais problemas, mas a maioria deles tem uma única 
origem: erro humano (Delamaro et al., 2007). 
• As atividades de Verificação e Validação (V&V) visam 
garantir, respectivamente, que: 
– o software está sendo desenvolvido corretamente, 
– o software que está sendo desenvolvido é o software 
correto. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
V&V: ESTÁTICA X DINÂMICA 
• As atividades de V&V costumam ser divididas em 
estáticas e dinâmicas. 
• As estáticas não requerem a execução ou mesmo a 
existência de um programa ou modelo executável para 
serem realizadas. 
• As dinâmicas se baseiam na execução de um 
programa ou modelo (Delamaro et al., 2007). 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
MOTIVAÇÃO PARA TESTE 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
MOTIVAÇÃO PARA TESTE 
As falhas causam 
prejuízos 
financeiros 
 
 
 
 
As falhas causam a 
perda de confiança 
do cliente 
 
 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
POR QUE ALGUMAS EMPRESAS NÃO 
TESTAM? 
Teste é um 
processo caro 
 
 
 
Dificuldade em 
implantar um processo 
de teste 
 
 
 
Desconhecem 
a relação 
custo/benefício 
 
 
Só se preocupam 
com teste na 
fase final do 
projeto 
 
 
Desconhecem 
técnicas de teste 
adequadas 
 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
MOTIVAÇÃO PARA TESTE 
• Segundo pesquisas do SEI ( Software Engineering 
Institute): 
– 30% dos projetos são cancelados antes de serem 
finalizados 
– 70% dos projetos falham nas entregas das 
funcionalidades esperadas; 
– Os custos dos projetos extrapolam mais de 180% dos 
valores previstos; 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
MOTIVAÇÃO PARA TESTE 
– Prazos excedem mais de 220% 
– Empresas de nível 1 dedicam cerca de 55% dos 
esforços para corrigir defeitos 
– Esses índices vão sendo gradativamente reduzidos à 
medida que elas adotam um modelo de qualidade 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FINALIDADE DOS TESTES 
– Verificar se todos os requisitos do sistema foram 
corretamente implementados 
– Assegurar a satisfação do cliente com o produto 
desenvolvido 
– Assegurar, na medida do possível, a qualidade e a 
corretude do software produzido 
– Reduzir custos de manutenção corretiva e retrabalho 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FINALIDADE DOS TESTES 
“Teste é o processo de demonstrar que erros não estão 
presentes” 
“O objetivo do teste é demonstrar que um programa executa 
suas funções corretamente” 
“Teste é o processo de criação de confiança de que o programa 
faz o que ele tem que fazer” 
Teste é o processo de executar um programa com a 
intenção de encontrar defeitos 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TESTE DE SOFTWARE 
• É o processo de executar um programa com o objetivo 
de encontrar defeitos (Myers, 1979). 
• É, portanto, uma atividade de V&V dinâmica. 
• Do ponto de vista psicológico, o teste de software é 
uma atividade com um certo viés destrutivo, ao 
contrário de outras atividades do processo de software. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PERSPECTIVA DE TESTE 
• Bons testadores necessitam de um conjunto especial 
de habilidades. Um testador deve abordar um software 
com a atitude de questionar tudo sobre ele (McGregor e 
Sykes, 2001). 
• A perspectiva de teste é, um modo de olhar qualquer 
produto de desenvolvimento e questionar a sua 
validade. 
• Habilidades requeridas na perspectiva de teste: 
– Querer prova de qualidade, 
– Não fazer suposições, 
– Não deixar passar áreas importantes, 
– Procurar ser reproduzível. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PERSPECTIVA DE TESTE 
• A perspectiva de teste requer que um fragmento de 
software demonstre não apenas que ele executa de 
acordo com o especificado, mas que executa apenas o 
especificado (McGregor e Sykes, 2001). 
• O software faz o que deveria fazer e somente isso? 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TESTE DE SOFTWARE 
• Executa-se um programa ou modelo utilizando algumas 
entradas em particular e verificar-se se seu 
comportamento está de acordo com o esperado. 
• Caso a execução apresente algum resultado não 
especificado, um defeito foi identificado. 
• Os dados da execução podem servir como fonte para a 
localização e correção de defeitos, mas teste não é 
depuração (Delamaro et al., 2007). 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TERMINOLOGIA 
• Defeito 
– Instrução ou definião incorreta 
• Falha 
– Resultados Incorretos 
• Erro 
– Falha resultante de ação humana 
 
• Durante o teste observamos as falhas. Na 
depuração do código encontramos os defeitos 
(causas) para corrigi-los. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FORMANDO A EQUIPE DE TESTES 
Usando a Equipe de Desenvolvimento: 
 
- O Líder do Projeto de Desenvolvimento será 
também o Líder do Projeto de Testes; 
 
- A Equipe de Teste é a mesma Equipe de 
Desenvolvimento; 
 
- Os Testes serão executados através de rodízios, 
onde nunca a pessoa que desenvolveu o módulo 
executará testes no próprio modulo. 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FORMANDO A EQUIPE DE TESTES 
Desvantagens: 
- Diminuição da qualidade do produto final; 
- Tendência a não visualizar certos defeitos do 
projeto (testes de sucesso); 
- Tendência a informalidade na execução dos 
testes; 
- Dificuldade de conciliar os cronogramas das 
equipes de desenvolvimento; 
- Falta de conhecimento do negócio da equipe que 
for executar os testes. 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FORMANDO A EQUIPE DE TESTES 
Usando Equipe Independente: 
 
- Esta é uma prática que está sendo cada vez mais 
usada no mercado; 
 
- Equipes especializadas em teste produzem 
resultados, em termos de qualidade do software, 
muito melhores; 
 
- Essas equipes possuem um treinamento 
adequado para executar com qualidade os 
testes e estão bastante familiarizadas com as 
suas ferramentas e metodologias. 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FORMANDO A EQUIPE DE TESTES 
Desvantagens: 
 
- Custos maiores; 
- Aumento no tempo de liberação do software; 
- Tendência da equipe de desenvolvimento em relaxar 
na parte que lhe cabe (teste unitário e de 
integração); 
- Divergências entre as duas equipes. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FORMANDO A EQUIPE DE TESTES 
Usando Equipesde não-especialistas em TI 
 
- Muitas empresas usam grupos de usuários para fazer 
o chamado trabalho de homologação do software ou 
o seu teste de aceitação; 
 
- A perspectiva é sempre a do negócio, ou seja, garantir 
que o software foi desenvolvido de acordo com os 
requisitos que foram estabelecidos pelo negócio. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FORMANDO A EQUIPE DE TESTES 
Desvantagens: 
 
- Custos maiores; 
- Falta de familiarização com ferramentas; 
- Abordagens exclusivas do negócio, esquecendo 
aspectos técnicos do teste. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
ESTÁGIOS DE TESTE 
Testes de 
unidade 
Testes de 
Integração 
Testes de 
Sistema 
Testes de 
Aceitação 
Entrega 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
CICLO DE VIDA 
Testes de 
unidade 
Testes de 
Integração 
Testes de 
Sistema 
Testes de 
Aceitação 
Design 
detalhado 
Design da 
arquitetura 
Requisitos 
do sw/hw 
Requisitos de 
usuário 
Implementação 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TESTE DE UNIDADE 
• Tem como foco as menores unidades de um programa. 
• Uma unidade é um componente de software que não 
pode ser subdividido. 
• Nesta fase esperam-se encontrar defeitos relacionados 
a algoritmos incorretos ou mal implementados, 
estruturas de dados incorretas ou simples erros de 
programação. 
• Pode ser aplicado à medida que ocorre a 
implementação das unidades e pode ser realizado pelo 
próprio desenvolvedor (Delamaro et al., 2007). 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TESTE DE UNIDADE 
• Durante os testes de unidade, é necessária a 
implementação de drivers e stubs. 
• Um driver é um programa que coordena o teste de uma 
unidade, sendo responsável por ler os dados fornecidos 
pelo testador, repassar esses dados na forma de 
parâmetros para a unidade, coletar os resultados 
produzidos pela unidade e apresentá-los para o 
testador. 
• Um stub é um programa que substitui, na hora do teste, 
uma unidade, simulando o comportamento dessa 
unidade com o mínimo de computação ou manipulação 
de dados (Delamaro et al., 2007). 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TESTE DE INTEGRAÇÃO 
• Deve ser realizado após serem testadas as unidades 
individualmente. 
• A ênfase é colocada na construção da estrutura do 
sistema. 
• Deve-se verificar se as partes, quando colocadas para 
trabalhar juntas, não conduzem a erros. 
• Requer grande conhecimento das estruturas internas 
do sistema e, por isso, geralmente é executado pela 
própria equipe de desenvolvimento (Delamaro et al., 
2007). 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TESTE DE SISTEMA/ACEITAÇÃO 
• Uma vez integradas todas as partes, inicia-se o teste 
de sistema. 
• Quando realizado por uma equipe de teste, o objetivo é 
verificar se as funcionalidades especificadas na 
especificação de requisitos foram corretamente 
implementadas. 
• Quando realizado por usuários, o objetivo é validar o 
sistema (Teste de Aceitação). 
• É uma boa prática que essa fase seja realizada por 
testadores independentes. 
• Tipicamente, aplica-se teste funcional. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TESTE DE SISTEMA/ACEITAÇÃO 
• Teste de Aceitação 
– Teste para verificar se o produto de software atende os 
Requisitos (Conformidade com os Requisitos) 
• Testes de Sistema 
– Combinação de diferentes testes para por a prova todos os 
diferentes elementos do sistema (foram adequadamente 
integrados? realizam corretamente as funções?) 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TIPOS DE TESTE 
Estáticos ou revisões: 
– Revisão técnica: Consiste na apresentação do material 
para uma equipe de revisão onde será feita a análise do 
produto de trabalho; 
– Inspeção: Consiste na verificação dos produtos do 
software e processo estão de acordo com os padrões, 
guidelines, especificações e procedimentos; 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
TIPOS DE TESTE 
– Teste Funcional 
– Teste de Recuperação de Falhas 
– Teste de segurança e controle de acesso 
– Teste de performance 
– Teste de estresse 
– Teste de configuração ou portabilidade 
– Teste de interface com o usuário 
– Teste de regressão 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
ABORDAGENS DE TESTE 
• Abordagem funcional(“caixa-preta”) 
Os testes são gerados a partir de uma análise dos 
relacionamentos entre os dados de entrada e de saída 
• Abordagem estrutural(“caixa-branca”) 
Os testes são executados a partir de uma análise dos 
caminhos lógicos possíveis de serem executados. 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
RELACIONANDO AS ATIVIDADES DE TESTES 
COM AS DE DESENVOLVIMENTO 
Quando começar a testar? 
Planejamento 
de Projeto 
Captura de 
Requisitos 
Análise e 
Projeto 
Implementação 
Planejar 
Testes 
Projetar 
Testes 
Implementar 
Testes 
Build Build 
Executar 
Testes 
Avaliar Testes 
Gerenciar Defeitos 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PROCESSO DE TESTE 
• O processo de teste pode ser definido como um 
processo separado, mas intimamente ligado, ao 
processo de desenvolvimento. Isso porque eles têm 
metas e medidas de sucesso diferentes. 
• Por exemplo, quanto menor a taxa de defeitos (razão 
entre o no de casos de teste que falham pelo total de 
casos de teste), mais bem sucedido é considerado o 
processo de desenvolvimento. Por outro lado, quanto 
maior a taxa de defeitos, considera-se mais bem 
sucedido o processo de teste (McGregor e Sykes, 
2001). 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PROCESSO DE TESTE 
- Planejar Testes 
- Especificar Testes 
- Executar Testes 
- Reportar Testes 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PLANEJAR TESTES 
 Entradas 
–Documento de Requisitos 
–Plano de Projeto 
–Modelos de Caso de Uso 
Saídas 
–Plano de Testes 
 
 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PLANO DE TESTES 
Histórico de Revisões 
1.Objetivo 
2.Requisitos a serem testados 
3.Estágios de Teste 
4.Tipos de Teste 
5.Abordagens de Teste 
6.Critérios de parada/aceitação 
7.Recursos 
8.Matriz de Responsabilidade 
9.Cronograma 
 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PROJETAR TESTES 
 Entradas 
– Documento de Requisitos 
– Plano de Testes 
– Modelo de Caso de Uso 
 
Saídas 
– Projeto de Testes(casos e procedimentos) 
– Planilha de Teste 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PROJETO DE TESTES 
Histórico de Revisões 
1. Requisitos a serem testados(prioridade) 
2. Identificador do caso de Teste 
3.Requisitos Associados 
3.Casos de Teste 
3.Tipo de Teste 
4. Pré-condição 
4.Dados de entrada 
5.Procedimento 
6.Resultado esperado 
7.Status do teste 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
EXECUÇÃO DE TESTES 
 Entradas 
– Projeto de Testes 
– Código executável do sistema 
 
Saídas 
– Planilha de Teste 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
RELATÓRIO DE TESTES 
- Registrar resultados 
- Avaliar resultados 
- Encaminhar ao desenvolvedor responsável 
 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
GERENCIAMENTO DE BUGS 
Classificação de defeitos: 
 
1.Faltante: O defeito ocorre em virtude da falta parcial ou 
total de um requisito; 
2.Errado: O defeito ocorre porque o requisito foi 
implementado corretamente; 
3.Acréscimo: O defeito ocorre em virtude de um 
comportamento ou elemento que foi implementado mas 
não foi especificado no requisito.www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
GERENCIAMENTO DE BUGS 
Ciclo de vida de um defeito 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FERRAMENTAS DE TESTE 
- Automatizam atividades do processo de teste 
- Podem nos auxiliar em todas as atividades do processo de teste 
 
Ferramentas de planejamento e projeto de testes: 
• Elaborar plano de testes. Ex: Project 
• Projetar testes:Excel, TestManager 
• Executar testes:Excel, TestManager 
• Avaliar testes:Excel, TestManager 
• Implementação: Junit(unidade), Jtest e C++Test (Análise 
estática de código) 
• Gerência de defeitos: Bugzilla, Mantis, Redmine 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FERRAMENTAS DE TESTE 
• O Mantis é uma ferramenta Open Source automatizada 
escrita em PHP cujo principal objetivo é dar suporte ao 
processo de gestão de defeitos. 
• Website do Mantis 
 http://www.mantisbt.org 
 
 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
PÁGINA INICIAL 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
RELATAR CASO 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
RECONHECIMENTO DE UM DEFEITO 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
E-MAIL ENVIADO AO DESENVOLVEDOR 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
VISÃO POR DESENVOLVEDOR 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
REPORT DA CORREÇÃO 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
FECHAMENTO DE UM DEFEITO 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
REFERÊNCIAS 
• ACKERMAN, A., BUCHWALD, L., LEWSKI, F., 1989, “Software 
Inspections: An Effective Verification Process”, IEEE Software, vol. 
6, no. 3, pp.31-37. 
• KALINOWSKI, M., SPÍNOLA, R.O., TRAVASSOS, G.H., Infra-
Estrutura Computacional para Apoio ao Processo de Inspeção de 
Software. No: Simpósio Brasileiro de Qualidade de Software, 2004, 
Brasília. 
• BOEHM, B. W., BASILI, V.R., 2001, “Software Defect Reduction 
Top 10 List.”, IEEE Computer 34 (1): 135-137. 
• BOEHM, B.W., ABTS, C., BROWN, A.W., CHULANI, S., CLARK, 
B.K., HOROWITZ, E., MADACHY, R., REIFER, D., STEECE, B., 
2000, Software Cost 
• Estimation with COCOMO II, Prentice Hall. BOEHM, B.W., 1981, 
Software Engineering Economics, Prentice Hall. 
• CIOLKOWSKI, M., LAITENBERGER, O., BIFFL, S., 2003, 
“Software Reviews: The State of the Practice”, IEEE Software 20 
(6): 46-51. 
 
www.spider.ufpa.br UNIVERSIDADE FEDERAL DO PARÁ 
OBRIGADO! 
Dúvidas? 
Prof. Dr. Sandro Bezerra – srbo@ufpa.br