Qualidade de Software: Teste de software

Teste deTeste de softwaresoftware
Prof. Alex Dias Camargo
alexcamargo@ifsul.edu.br
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
SUL-RIO-GRANDENSE
CÂMPUS BAGÉ
QUALIDADE DE SOFTWARE

2
I. Plano de aula
Na aula anterior foi visto:
 Normas de qualidade de software
 Modelos de qualidade de software
 Análise comparativa
QDS - Teste de software

3
I. Plano de aula
Nesta aula será apresentado:
 Conceitos básicos, verificação e tipos de teste
 Ferramentas de apoio ao teste de software

4
1. Introdução
A atividade de teste é o processo de executar um software com
a intenção de descobrir um erro.
 Erro: é uma ação humana que produz um resultado incorreto.
 Defeito (bug): a manifestação de um erro no software.
 Falha: quando o sistema se comporta de forma inesperada
devido ao defeito.
 Custo da correção de um defeito: tende a ser cada vez
maior quanto mais tarde ele for descoberto.
 Testes de software: são responsáveis por executar o
software utilizando valores reais (ou próximos).

5
1. Introdução
Figura. Processo de Testes x Processo de Desenvolvimento

6
1. Introdução
Figura. Processo de Teste iterativo

7
1. Introdução
Figura. Mitos sobre testes

8
1. Introdução
Porque testar é necessário?
 É provável que o software possua defeitos.

 Desenvolvedor já alocado para outro projeto teria que resolver
muitos bugs de projetos anteriores em produção.
 Para avaliar a qualidade do software.
 Porque falhas podem custar muito caro.

9
1. Introdução
Figura. Confiabilidade do software

10
1. Introdução
Figura. Custos de correção

11
1. Introdução
A atividade de teste é o processo de executar um software com
a intenção de descobrir um erro. Existem normas que tratam
especificamente sobre teste em software:

 IEEE 829 (Standard for Software and System Test
Documentation)
 ISO/IEC 29119 (Software Testing Standart)
 ISTQB (International Software Testing Qualifications Board)
 BSTQB (Brazilian Software Testing Qualifications Board)

12
1. Introdução
Figura. BSTQB (Brazilian Software Testing Qualifications Board)

13
1. Introdução
O desenvolvimento de software é uma área que exige cuidado e
precisão. Em muitos casos, as falhas podem custar caro.
 Em 1996: uma exceção de software não tratada foi
responsável pela explosão do foguete Ariane-5.
Prejuízo: 500 milhões de dólares.

 Em 2000: erro de cálculo num sistema de radioterapia que era
utilizado para controlar a emissão de radiação.
Danos: morte de 8 pessoas e queimaduras em outras 20.
 Em 2012: uma falha em um novo software que a empresa KCG
(Knight Capital Group) comprou gerou milhares de negociações
que não poderiam ser feitas.
Prejuízo: 440 milhões em meia hora.

14
1. Introdução
A equipe de testes é formada, basicamente, por 3 atores:
 Gerente de teste: comunicação entre a equipe de teste e de
desenvolvimento.
Atribuições: lidera, planeja e define estratégias de teste.

15
1. Introdução
Figura. Papel de um gerente de testes

16
1. Introdução
desenvolvimento.
 Arquiteto de teste: conhecedor dos requisitos do sistema.
Atribuições: elaborar os roteiros de teste.

17
1. Introdução
Figura. Papel de um arquiteto de testes

18
1. Introdução
desenvolvimento.
 Arquiteto de teste: conhecedor dos requisitos do sistema.
Atribuições: elaborar os roteiros de teste.
 Testador: possui noções de programação, preferencialmente.
Atribuições: executar os testes planejados e reportar os erros
encontrados.

19
1. Introdução
Figura. Papel de um testador

20
1. Introdução
Há diversos tipos de teste que podem ser aplicados em
diferentes momentos do desenvolvimento de um software. Nesse
contexto, se destacam:
 Testes de Caixa Branca (Estrutural):
Testes de Unidade, Teste de Integração.
 Testes de Caixa Preta (Funcional):
Testes Funcionais, Testes de Aceitação, Testes Exploratórios.
 Testes de Caixa Cinza (Estrutural-funcional):
Testes de Regressão, Testes de Cobertura.

21
1. Introdução
Figura. Níveis de teste de software

22
1. Introdução
O Teste de Caixa Branca é um método de projeto de casos de
testes voltado a testar a estrutura interna do software (código-
fonte).
 Teste de unidade: realizado em um componente para
verificar sua corretude.
Exemplo: Teste para uma classe ou métodos do sistema.
 Geralmente executado pelo desenvolvedor que codificou o
componente.

 Realizado de forma automática. Ex.: JUnit.

23
1. Introdução
Figura. Testes de unidade: JUnit.

24
1. Introdução
Figura. Testes de unidade: JUnit.

25
1. Introdução
O Teste de Caixa Branca é um método de projeto de casos de
testes voltado a testar a estrutura interna do software (código-
fonte).
 Teste de integração: verifica se ao juntar vários
componentes do sistema, eles se comunicam corretamente.
Ex.: Testar um módulo do sistema.
 Executado pelos desenvolvedores ou analistas de sistema.
 Realizado de forma automática. Ex.: API Java RMI (Remote
Method Invocation).

26
1. Introdução
Figura. Testes de integração: Java RMI (package java.rmi).

27
1. Introdução
O Teste de Caixa Preta consiste em verificar na interface do
software se todas as funcionalidades (entradas e saídas) estão
operando corretamente.
 Teste funcional: verifica se o sistema está em conformidade
com a especificação de requisitos.
Ex.: Testes baseados em roteiros criados a partir da
especificação.

 Executado pelo testador, o qual tem acesso apenas a
interface do sistema.

 Pode ser realizado de forma manual ou automática.
Ex.: Selenium + Selenium-IDE (Firefox) + pyTest

28
1. Introdução
Figura. Testes funcionais: Selenium (automação de um navegador)

29
1. Introdução
Figura. Testes funcionais: Selenium

30
1. Introdução
 Teste de aceitação: verifica se o sistema está em
conformidade com os requisitos esperados pelo cliente.
Ex.: Testes em novas versões de um software.

 Executado pelo cliente em ambiente de homologação ou
produção.

 Realizado de forma manual ou automática. Ex.: EasyAccept

31
1. Introdução
Figura. Testes de aceitação: EasyAccept

32
1. Introdução
Figura. Testes de aceitação: EasyAccept

33
1. Introdução
 Testes exploratórios: implementados quando não há muita
documentação sobre o sistema.
Ex.: Adoção de um sistema open-source pouco documentado.

 Executado por testadores com experiência.

 Realizado de forma manual.

34
1. Introdução
Figura. Testes exploratórios: objetivos

35
1. Introdução
O Teste de Caixa Cinza analisa a parte lógica mais a
funcionalidade do sistema, fazendo uma comparação do que foi
especificado com o que esta sendo realizado.
 Testes de regressão: realizar novos testes em um sistema já
testado.
Ex.: Conjunto de testes a serem realizados em uma nova
versão de software implementada.

 Executado por testadores.

 Pode ser realizado de forma manual ou automática.
Ex.: TestLink

36
1. Introdução
Figura. Testes de regressão: Testlink

37
1. Introdução
Figura. Testes de regressão: Testlink

38
1. Introdução
O Teste de Caixa Cinza analisa a parte lógica mais a
funcionalidade do sistema, fazendo uma comparação do que foi
especificado com o que esta sendo realizado.
 Teste de cobertura (Estrutural):
Tem por finalidade identificar se os testes realizados no
sistema abrangem pelo menos 95% do código produzido.
 Teste de cobertura (Funcional):
Verificam se os roteiros de teste abrangem 100% das
funcionalidades do sistema, ou seja, possui pelo menos 1 caso
de teste para cada regra de negócio.

39
2. Exercícios
1. Responda os quizes sobre Teste de Software:
Software Testing Practice Test-1
https://www.proprofs.com/quiz-school/story.php?title=software-test
ing-practice-test1
Software Testing Quiz: Part 1 and 2
https://www.softwaretestinggenius.com/software-testing-quiz-part-
1-and-2/
ISTQB Sample Exam Questions – Testing Fundamentals
https://www.testingexcellence.com/istqb-quiz/istqb-sample-exam-q
uestions-testing-fundamentals/
ISTQB Foundation Practice Exam 1
https://www.testingexcellence.com/istqb-quiz/istqb-foundation-prac
tice-exam-1/

40
2. Exercícios
2. Indique se é verdadeiro ou falso:
( ) O testes devem ser realizados para mostrar a ausência de
defeitos.
( ) O processo de teste deve ser independente do processo de
desenvolvimento, porém integrado.
( ) A equipe de testes pode ser formada por desenvolvedores
menos qualificados.
3. Cite alguns motivos que levam as empresas a cada vez mais
testar os softwares em desenvolvimento, antes de entregá-los aos
clientes.

41
2. Exercícios
4. Assinale a alternativa que NÃO aborda um teste de desempenho:
( ) Teste de carga.
( ) Teste de estresse.
( ) Teste de estabilidade.
( ) Teste de balanceamento de carga.
( ) Teste de usabilidade.
5. Teste realizado na instalação do desenvolvedor com os usuários
finais, em um ambiente controlado, para identificar erros e
problemas de uso durante a operação do sistema pelos usuários é
denominado:
( ) Teste Alfa.
( ) Teste Beta.
( ) Teste de Regressão.

42
2. Exercícios
6. No contexto de teste de software, o termo “Beta teste”
caracteriza testes que:
( ) empregam primordialmente técnicas conhecidas como “White
box”;
( ) são equivalentes aos testes conhecidos pelo termo “Alfa teste”;
( ) focam em pontos críticos, cujas correções são providenciadas
de imediato pelo desenvolvedores;
( ) são realizados num ambiente de laboratório do desenvolvedor;
( ) são realizados por usuários externos, em condições de uso
semelhantes às de produção.

43
2. Exercícios
7. Com relação a desenvolvimento de software, julgue e justifique o
item a seguir. Na prática de integração contínua para
desenvolvimento de software, vários colaboradores criam e
mantêm o código de forma organizada e controlada, utilizando
ferramentas como Git (controle de versão), Junit (testes) e Jenkins
(deploys em ambientes de desenvolvimento e produção), o que
reduz a geração de erros de integração.
( ) Certo ( ) Errado

44
2. Exercícios
8. Marque a melhor definição do objetivo do teste de aceitação.
Justifique a sua resposta.
( ) Garantir que o software entre sem erros na produção
( ) Garantir que o grupo de testes fez um bom trabalho
( ) Garantir que o software esteja fazendo exatamente aquilo que
foi solicitado nos requisitos de negócio.
9. Explique qual a finalidade do Teste Exploratório, e de quem é a
responsabilidade por sua execução.
10. Enquanto os testes de unidade propiciam a qualidade externa,
os testes de aceitação ajudam o desenvolvedor a avaliar a
qualidade interna do código, dando feedback sobre o design dos
módulos e permitindo a manutenção com menor custo.

45
2. Exercícios
11. No teste funcional, que é uma das fases do processo de
validação, não é necessário o conhecimento das estruturas
internas do software. Justifique.
12. Trata-se de um teste que desconhece o conteúdo do código
fonte. Nesse teste o componente testado é tratado como uma
caixa preta: são fornecidos dados de entrada e o resultado
comparado com aquele esperado e previamente conhecido. Além
disso, esse teste pode ser aplicado em diversas fases de teste. A
questão retrata características do teste:
( ) funcional ( ) de integração ( ) de desempenho ( ) de carga
( ) unitário

46
Referências básicas
CHRISSIS, M.B., KONRAD, M., SHRUM, S., CMMI for development:
guidelines for process integration and product improvement, 3rd
edition, Addison Wesley Professional, 2011.
DELAMARO, M.E.; MALDONADO, J.C.; JINO, M. Introdução ao Teste de
Software. Elsevier Editora, ISBN 978-8535226348. 2007.
MYERS, G.; BADGETT, T.; THOMAS, T.; SANDLER, C.; The Art of Software
Testing. Wiley, 3rd Edition, ISBN 978-1118031964. 2011.
PRESSMAN, Roger, MAXIM, Bruce. Engenharia de Software, 8º edição.
AMGH, 01/2016.
PAULA FILHO, W. de P., Engenharia de Software: fundamentos,
métodos e padrões. 3.ed. Rio de Janeiro. LTC. 2008.
ROCHA, A.R.C., SOUZA, G.S., BARCELLOS, M.P., Medição e Controle
Estatístico de Processos. MCTi: Série de Livros PBQP. 2012.

Qualidade de Software: Teste de software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Qualidade de Software: Teste de software

Semelhante a Qualidade de Software: Teste de software (20)

Mais de Alex Camargo

Mais de Alex Camargo (20)

Qualidade de Software: Teste de software