Você está na página 1de 78

ENGENHARIA DE SOFTWARE

AULA 05

Prof. José Carlos Correia Lima da Silva Filho


E-mail: jose.lima@estacio.br
ENGENHARIA DE SOFTWARE
Atividade

Em grupos, criem cinco requisitos funcionais para um


aplicativo de delivery de comida e na sequência desenhem
um diagrama de casos de uso.

Os trabalhos deverão ser entregues ao professor por e-mail:


jose.lima@estacio.br

[1] Vídeo "Tutorial de Diagramas de Classes UML".


Disponível em:
https://www.youtube.com/watch?v=rDidOn6KN9k

[2] Vídeo "Tutorial de Caso de Uso UML".


Disponível em:
https://www.youtube.com/watch?v=ab6eDdwS3rA
ENGENHARIA DE SOFTWARE
Tema

FASES DO DESENVOLVIMENTO DE SOFTWARE


ENGENHARIA DE SOFTWARE
Tema

IMPLEMENTAÇÃO E TESTES
Testes
IMPLEMENTAÇÃO
• Linguagens de Programação
– https://pt-br.classpert.com/blog/linguagens-de-programacao-mais-usadas
– https://targettrust.com.br/blog/linguagens-de-programacao-garantia-
emprego/
• Banco de Dados (SGBDs)
– https://www.softwareone.com/pt-br/blog/artigos/2020/01/14/bancos-de-
dados
– http://www.bosontreinamentos.com.br/bancos-de-dados/10-sistemas-de-
bancos-de-dados-mais-usados-atualmente/

6
A IMPORTÂNCIA DO TESTE

O desenvolvimento de sistemas envolve uma série de


atividades em que as oportunidades de injeção de falhas
são muito grandes. Estes erros podem começar a aparecer
logo no início do processo, onde os objetivos podem estar
erroneamente especificados, além de erros que venham a
ocorrer em fases de projeto e desenvolvimento posteriores.

7
A IMPORTÂNCIA DO TESTE

Por causa da inabilidade humana de realizar e de se


comunicar com perfeição, o desenvolvimento é
acompanhado de garantia de qualidade.

A atividade de teste de software é um elemento crítico da


garantia de qualidade de software e representa a última
revisão de especificação, projeto e codificação.

8
CUSTO DO REPARO

Custo

Requisitos Codificação Entrega Estágio de


desenvolvimento

9
A IMPORTÂNCIA DO TESTE

Não é raro gastarmos entre 30 e 40% do esforço total do


projeto no Teste de Software.

O Teste de Software para ambientes críticos (ex.: controle


de voo, monitoramento de reatores nucleares e etc.) pode
custar de três a cinco vezes mais do que todos os outros
passos de engenharia de software combinados.

10
curva real
mudança
índice de
falhas

curva idealizada

tempo

11
DEFININDO O TESTE DE
SOFTWARE
• Avaliar se o software está fazendo o que deveria fazer,
de acordo com os seu requisitos, e não está fazendo o que
não deveria fazer;
• Qualquer atividade que, a partir da avaliação de um
atributo ou capacidade de um programa ou sistema, seja
possível determinar se ele alcança os resultados
desejados. (Bill Hetzel – 1988).
• Processo de executar um programa ou sistema com a
intenção de encontrar defeitos (Glen Myers – 1979);

12
DEFININDO O TESTE DE
SOFTWARE
Segundo Pressman, o teste de software é um conjunto de
atividades que podem ser planejadas com antecedência e
executadas sistematicamente.

Uma estratégia de teste de software deve acomodar testes


de baixo nível, necessários para verificar se um pequeno
segmento de código fonte foi implementado corretamente,
bem como testes de alto nível, que validam as funções
principais do sistema de acordo com os requisitos do
cliente.
13
DEFININDO O TESTE DE
SOFTWARE
A atividade de teste é um passo do processo de Engenharia
de Software que visa encontrar/corrigir erros ao longo do
software que foi construído.

Testes podem ser usados para descobrir a presença de


erros, mas não para mostrar a sua ausência.

Testes de software é o processo de executar o software de


uma maneira controlada com o objetivo de descobrir dife-
renças entre o comportamento previsto e o comportamento
observado.
14
ESTRATÉGIAS DE TESTE

Todas estratégias fornecem um modelo para o teste e têm


basicamente as seguintes características:

➢ Para executar um teste eficaz, proceder a revisões


técnicas eficazes. Fazendo isso, muitos erros serão
eliminados antes do começo do teste.

➢ O teste começa no nível do componente e progride em


direção à integração do sistema computacional como um
todo.

15
ESTRATÉGIAS DE TESTE

Todas estratégias fornecem um modelo para o teste e têm


basicamente as seguintes características:

➢ Diferentes técnicas de teste são apropriadas para


diferentes abordagens de engenharia de software e em
diferentes momentos

➢ O teste é feito pelo desenvolvedor do software e (para


grandes projetos) por um grupo independente de teste.

➢ O teste e a depuração são atividades diferentes, mas


a depuração ocorre em consequência de um teste.
16
ESTRATÉGIAS DE TESTE

A atividade de teste é o processo de executar um programa


com a intenção de descobrir um erro.

Um bom caso de teste é aquele que possui uma elevada


probabilidade de revelar um erro ainda não descoberto.

Um teste bem-sucedido é aquele que revela um erro ainda


não descoberto.

17
O PROCESSO DE TESTE

O processo de teste de software deve basear-se em uma


metodologia aderente ao processo de desenvolvimento, com
pessoal técnico qualificado, ambiente e ferramentas adequadas.
Esta metodologia de teste deve ser o documento básico para
organizar a atividade de testar aplicações no contexto da
empresa. Assim como o processo de desenvolvimento de
software, teste de software também possui um ciclo de vida:

18
O PROCESSO DE TESTE

Planejamento

Procedimentos
Especificação Execução Entrega
Iniciais

Preparação

19
O PROCESSO DE TESTE

Planejamento: Elaboração e revisão da Estratégia de teste


e do plano de teste;

Preparação: Preparação do ambiente de teste, incluindo


equipamentos, rede, pessoal, software e ferramentas.

20
O PROCESSO DE TESTE

Procedimentos iniciais: Consiste na elaboração de


documento com o estabelecimento de um acordo entre as
partes envolvidas no projeto de teste (usuários e técnicos):
➢ Objetivo do projeto de teste,
➢ Pessoal a ser envolvido,
➢ As responsabilidades de cada um;
➢ O plano preliminar de trabalho;
➢ Avaliação dos riscos;
➢ Os níveis de serviços acordados e etc.

21
O PROCESSO DE TESTE

Especificação: Elaboração e revisão dos casos de teste ,


“scripts” ( no caso de ferramentas de automação de testes)
e dos roteiros de Teste e execução dos testes de verificação
da documentação do sistema (testes estáticos).
Execução: Execução dos testes planejados conforme os
Casos de Teste, “scripts” e dos roteiros de Teste com os
correspondentes registros dos resultados obtidos.
Entrega: conclusão do processo de testes com a entrega
do sistema para o ambiente de produção.

22
INTERAÇÃO ENTRE OS CICLOS DE VIDA

23
O PROCESSO DE TESTE

Há muitas estratégias que podem ser utilizadas para testar


um software. Uma das estratégias de teste que é preferida
pela maioria das equipes é a visão incremental do teste,
começando com o teste das unidades individuais de
programa, passando para os testes destinados a facilitar a
integração de unidades e culminando com testes que usam
o sistema concluído.

Verificação: Nesta etapa são realizadas inspeções/revisões


sobre os produtos gerados.
24
O PROCESSO DE TESTE

Testes Unitários: São realizados no estágio mais baixo da


escala de testes e são aplicados nas menores componentes
de códigos criados, visando garantir que estes atendem as
especificações, em termos de garantia e de funcionalidade.
Verificam o funcionamento de um pedaço do sistema ou
software isoladamente ou que possam ser testado
separadamente.

Normalmente é feito pelos desenvolvedores.

25
O PROCESSO DE TESTE

Testes de integração: São executados em uma


combinação de componentes para verificar se ele
funcionam corretamente juntos, conforme as
especificações. Componentes podem ser pedaços de
código, módulos, aplicações distintas, clientes servidores.
Normalmente é feito pelos desenvolvedores.

26
O PROCESSO DE TESTE

Teste de sistema: São realizados pela equipe de testes,


visando a execução do sistema como um todo ou um
subsistema (parte de um sistema), dentro de um ambiente
operacional controlado, para validar a exatidão e perfeição
na execução de suas funções. Neste estágio de teste deve
ser simulada a operação normal do sistema, sendo testadas
todas as suas funções de forma mais próxima possível do
que irá ocorrer no ambiente de produção. Esses testes são
feitos pela equipe de teste de software.

27
O PROCESSO DE TESTE

Teste de aceitação: São os testes finais de execução do


sistema, realizados pelos usuários, visando verificar se a
solução atende aos objetivos do negócio e aos seus
requisitos, no que diz respeito À funcionalidade e
usabilidade, antes da sua utilização no ambinete de
produção.

28
O PROCESSO DE TESTE

Ao tratar os testes como um processo organizado e muitas


vezes paralelo e integrado ao processo de
desenvolvimento, os custos de manutenção serão
reduzidos. Segundo Myers, o custo de correção de defeitos
tende a aumentar quanto mais tarde o defeito é detectado.
Defeitos encontrados durante a produção tendem a custar
muito mais que defeitos encontrados em modelos de dados
e em outros documentos do projeto do software.

29
O PROCESSO DE TESTE

➢ Os testes unitários podem remover entre 30% e 50 %


dos defeitos dos programas;

➢ Os testes de sistemas podem remover entre 30% e


50% dos defeitos remanescentes.

➢ Desse modo, os sistemas podem ir para produção


ainda com aproximadamente 49% de defeitos.

➢ Por últimos, as revisões de códigos podem reduzir


entre 20% e 30% desses defeitos.

30
TESTE NO PROGRAMA
TESTE CAIXA BRANCA E
TESTE CAIXA PRETA
os casos de uso. “A aplicação faz o que
• 1. Teste de Configuração deveria fazer?”
– Testa se o software funciona no hardware a
ser instalado. • 6. Teste de Unidade
Testa um componente isolado ou classe do
• 2. Teste de Instalação –
sistema.
– Testa se o software instala como planejado,
em diferentes hardwares e sob diferentes • 7. Teste de Integração
condições, como pouco espaço de – Testa se um ou mais componentes
memória, interrupções de rede, combinados funcionam de maneira
interrupções na instalação etc. satisfatória. Há quem diga que o teste de
integração é composto por vários testes de
• 3. Teste de Integridade unidade.
– Testa a resistência do software à falhas
(robustez). • 8. Teste de Volume
Testa o comportamento do sistema
• 4. Teste de Segurança –
operando com o volume “normal” de
– Testa se o sistema e os dados são dados e transações envolvendo o banco
acessados de maneira segura, apenas pelo de dados durante um longo período de
autor das ações. tempo.

• 5. Teste Funcional
– Testa os requisitos funcionais, as funções e
indesejado, além de,
• 9. Teste de • 10. Teste de certificar se o sistema ainda
Performance Usabilidade atende os requisitos.
– O teste de performance se – Teste focado na experiência • 13. Teste de
divide em 3 tipos: do usuário, consistência da
• Teste de carga: interface, layout, acesso às Manutenção
– Testa o software sob as funcionalidades etc. – Testa se a mudança de
condições normais de
uso. Ex.: tempo de ambiente não interferiu no
resposta, número de
transações por minuto,
• 11. Testes de Caixa funcionamento do sistema.
usuários simultâneos
etc. Branca e Caixa Preta
• Teste de stress – Basicamente, teste de caixa
– Testa o software sob
condições extremas de branca envolve o código e o
uso. Grande volume de de caixa-preta, não.
transações e usuários
simultâneos. Picos
excessivos de carga em • 12. Teste de
curtos períodos de


tempo.
Teste de estabilidade
Regressão
– Testa se o sistema se – Reteste de um sistema ou
mantém funcionando de
maneira satisfatória após componente para verificar se
um período de uso. alguma modificação recente
causou algum efeito
PROJETOS DE CASOS TESTE

Qualquer produto trabalhado por engenharia pode ser


testado de duas maneiras:

1 - Conhecendo-se a função específica que um produto


projetado deve executar, testes podem ser realizados
para demonstrar que cada função é totalmente
operacional;

Abordagem: Teste de Caixa Preta

34
PROJETOS DE CASOS TESTE

2 - Conhecendo-se o funcionamento interno de um


produto, testes podem ser realizados para garantir que
a operação interna do mesmo tenha desempenho de
acordo com as especificações e que os componentes
internos foram postos à prova.

Abordagem: Teste de Caixa Branca

35
TESTE CAIXA BRANCA

Teste de caixa branca é uma abordagem de projeto de


casos de teste que usa a estrutura de controle do projeto
procedimental para derivar casos de teste.

Baseia-se num minucioso exame dos detalhes


procedimentais.

36
TESTE CAIXA BRANCA

Os caminhos lógicos através do software são testados,


fornecendo-se casos de teste que põem à prova conjuntos
específicos de condições e/ou laços.

O status do programa pode ser examinado em vários


pontos para determinar se o esperado corresponde ao real.

37
TESTE CAIXA BRANCA

Com este método nós podemos projetar casos de teste que:

Garantam que todos os caminhos independentes dentro de


um módulo tenham sido exercitados pelo menos uma vez;

Exercitem todas as decisões lógicas para valores falsos ou


verdadeiros;

Executem todos os laços em suas fronteiras e dentro de


seus limites operacionais;

Exercitem as estruturas de dados internas para garantir a


sua validade.
38
TESTE CAIXA PRETA

Foco: requisitos funcionais do software


Possibilita a derivação de conjuntos de condições de
entrada que exercitem todos os requisitos funcionais
para um programa.

O Teste de Caixa Preta desconsidera a estrutura de


controle.
A atenção é voltada ao domínio da informação.

39
TESTE CAIXA PRETA

O Teste de Caixa Preta não é uma alternativa às técnicas


Caixa Branca, mas ao contrário, é uma abordagem
complementar, que mais provavelmente descobrirá uma
classe diferente de erros.

40
TESTE CAIXA PRETA

São realizados para responder as seguintes perguntas:


Como a validade funcional é testada?
Como o comportamento e o desempenho é testado?
Que classes de entrada farão bons casos de teste?
O sistema é particularmente sensível a certos valores?
Como as fronteiras de uma classe de dados é isolada?
Que taxas e volumes de dados o sistema pode tolerar?
Que efeito combinações específicas de dados terão sobre a
operação do sistema?

41
TESTE CAIXA PRETA

Desta forma o teste de caixa preta tenta encontrar erros


nas seguintes categorias:

Funções incorretas ou faltando;


Erros de interface;
Erros em estruturas de dados ou acesso a bases de dados
externas;
Erros de comportamento ou de desempenho;
Erros de inicialização e término.

42
ESTRATÉGIA DE TESTE DE SOFTWARE
INTRODUÇÃO

Compreenderemos as principais estratégias de teste de


software de forma a promover uma abordagem de teste
personalizada e de diferentes níveis de forma a atingir
todas as fases do ciclo de desenvolvimento do software.

Discutiremos a relevância da utilização de uma equipe


independente de teste no processo de teste de software, a
importância da criação do ambiente de teste e a aplicação
de teste unitário pelo desenvolvedor.

44
ESTRATÉGIA DE TESTE DE SOFTWARE

➢ Integra técnicas de projeto de casos de teste numa


série bem definida de passos;

➢ Proporciona um mapa que descreve os passos a


serem dados como parte da atividade de teste;

➢ Deve incorporar planejamento de teste, projeto de


casos de teste, execução de testes e a resultante
coleta e avaliação;

45
ESTRATÉGIA DE TESTE DE SOFTWARE

➢ Deve ser flexível o bastante para promover a


criatividade e a customização necessárias para
testar adequadamente;

➢ Deve ser rígida o bastante para promover um


razoável planejamento e rastreamento.

46
ESTRATÉGIA DE TESTE DE SOFTWARE

Aqui nós precisamos responder as seguintes perguntas:

➢ Como conduzir os testes de software?

➢ Devemos estabelecer um plano formal para os testes?

➢ Devemos testar o programa como um todo ou


executar testes somente em uma parte dele?

➢ Devemos refazer os testes quando acrescentamos


novos componentes ao sistema?

➢ Quando devemos envolver o cliente?


47
QUEM REALIZA O TESTE?

Do ponto de vista psicológico, as atividades de análise e projeto, junto com a


programação, são tarefas construtivas.

Por outro lado, a atividade de teste pode ser vista, psicologicamente, como uma
tarefa destrutiva.

Por esse motivo, é comum o desenvolvedor “pisar leve”, projetando e


executando testes que demonstrem que o sistema funciona, em vez de descobrir
erros.

Se o Engenheiro de Software não o encontrar, o cliente o fará!

48
QUEM REALIZA O TESTE?

Normalmente para que o processo de teste transcorra de forma íntegra


é comum a utilização de um grupo independente de teste, já que as
pessoas que criaram o software não devem ser as que irão realizar os
testes. Seria um conflito de interesses pois foram elas que o “criaram”.

Este grupo trabalha de forma conjunta e existem testes que somente


serão conduzidos pelos desenvolvedores, como o teste de unidade que
iremos estudar mais adiante.

49
QUEM REALIZA O TESTE?

Existem várias responsabilidades e papéis dentro da equipe:

Líder do projeto Responsável pela liderança de um projeto de teste,


de testes geralmente relacionado a um sistema em desenvolvi-
mento, seja um projeto novo ou manutenção.
Arquiteto Responsável pela montagem da infraestrutura de teste,
monta o ambiente de teste, escolhe as ferramentas de
teste e capacita a equipe para executar seu trabalho
neste ambiente.
Analista Responsável pela modelagem e elaboração dos casos
do teste de teste e pelos scripts de teste. Em alguns casos, os
scripts podem ser elaborados pelos testadores.
Testador Responsável pela execução dos casos de teste e
scripts.
Fonte: Rios.E & Moreira,T. Testes de Software. Rio de Janeiro. Alta Books, 2003
50
AMBIENTE DE TESTE

Pessoal:

✓ Usuários;

✓ Desenvolvedores;

✓ Testadores.

Hardware:

✓ Plataforma;

✓ Impressoras;

✓ Scanners;
51
AMBIENTE DE TESTE

Software:

✓ Software a ser testado;

✓ Sistema operacional;

✓ Software de teste, procedimentos.

Suprimentos:

✓ Papel;

✓ Formulários;

✓ Cartuchos de Tinta.
52
AMBIENTE DE TESTE

Rede:

✓ Protocolos;

✓ Autorizações;

✓ Usuários.

Documentação:

✓ Requisitos;

✓ Design;

✓ Cartuchos de Tinta.
53
AMBIENTE DE TESTE

Ambiente físico:

✓ Local;

✓ Segurança;

✓ Estrutura.

54
ABORDAGEM ESTRATÉGICA

Lembre-se:

Teste é um conjunto de atividades que pode ser planejado


antecipadamente e realizado sistematicamente.

Por essa razão, um gabarito de testes de software deve ser


definido para o processo de software.

Um gabarito de testes é um conjunto de passos no qual


podemos incluir técnicas de projeto de casos de teste e
métodos de teste específicos.
55
ABORDAGEM ESTRATÉGICA

Características genéricas de uma estratégia de Teste :

➢ Para realizar um teste efetivo, uma equipe de software


deve conduzir as RTF, quando muitos erros serão
eliminados antes do início do teste;

➢ O teste inicia-se no nível de componente e prossegue


“para fora”, na direção da integração de todo o sistema;

➢ Diferentes técnicas de teste são apropriadas a


diferentes situações ou momentos;
56
ABORDAGEM ESTRATÉGICA

Características genéricas de uma estratégia de Teste :

➢ A atividade de teste pode ser realizada pela própria


equipe de desenvolvedores ou por um grupo de teste
independente;

➢ As atividades de Teste e de Depuração são diferentes,


mas a depuração deve ser acomodada em qualquer teste.

57
VERIFICAÇÃO & VALIDAÇÃO

A atividade de teste de software é uma parte de um tema


mais amplo que é chamado de Verificação e Validação.

Verificação ➔ conjunto de atividades que garante que o


software implemente corretamente uma função específica.

Validação ➔ conjunto de atividades que garante que o


software que foi construído é adequado às exigências do
cliente.
58
VERIFICAÇÃO & VALIDAÇÃO

Segundo Boehm:

✓ Verificação – “Estamos construindo certo o produto?”

✓ Validação – “Estamos construindo o produto certo?”

59
VERIFICAÇÃO & VALIDAÇÃO

A definição de V&V abrange muitas das atividades


discutidas na Garantia da Qualidade de Software.

Os métodos de Engenharia de Software proporcionam a


base a partir da qual a qualidade é conseguida.

A atividade de teste constitui o último reduto, no qual a


qualidade do software pode ser avaliada e erros podem e
devem ser descobertos.

60
VERIFICAÇÃO & VALIDAÇÃO

“Não se pode testar a qualidade. Se ela não estiver lá


antes de você começar a testar, não estará lá quando
você tiver terminado de testar.” (Pressman).

A qualidade é incorporada ao software em todo o processo


de engenharia de software.

A aplicação adequada de métodos e ferramentas, RTFs e


um gerenciamento e medição sólidos, todos levam à
qualidade que é confirmada durante o teste.

61
UMA ESTRATÉGIA DE TESTE

“O processo de desenvolvimento de sistemas pode ser


visto como uma espiral com suas etapas movimentando-se
para dentro enquanto que a estratégia de teste pode ser
vista movimentando-se para fora.

62
UMA ESTRATÉGIA DE TESTE

Considerando de um ponto de vista procedimental, o teste


no contexto da Engenharia de Software é uma série de
quatro passos, que são implementados sequencialmente.

63
UMA ESTRATÉGIA DE TESTE

Os testes iniciais também conhecidos como teste de


unidade focalizam um único componente e aplicam-se para
descobrir erros nos dados e na lógica de processamento
destes componentes. Posteriormente cada componente
testado deve ser integrado.

Neste momento ocorre o teste de integração, cuja


preocupação é verificar problemas associados à construção
do programa.

64
UMA ESTRATÉGIA DE TESTE

Após esta fase ocorrem testes de ordem superior, como por


exemplo, o teste de validação com o objetivo de garantir
que o software satisfaz a todos os requisitos informativos,
funcionais, comportamentais e de desempenho.

A última etapa de teste de ordem superior é o teste de


sistema que verifica se todos os elementos se combinam
corretamente e se a função/desempenho global do sistema
é conseguida.

65
TESTE DE UNIDADE

Concentra-se no estágio mais baixo da escala de teste, isto


é, no código do programa e é considerado um adjunto da
etapa de codificação.

Normalmente é realizado pelo desenvolvedor e inicia-se


depois que o código foi desenvolvido, revisado e verificado
quanto à sua sintaxe.

O teste de unidade baseia-se, fortemente, no teste de caixa


branca.

66
TESTE DE UNIDADE

Este tipo de teste é aplicado nos menores componentes de


código criado, visando garantir que estes atendem as
especi-ficações em termos de características e de
funcionalidade.

O teste de unidade foca na lógica interna de processamento


e nas estruturas de dados dentro dos limites de um compo-
nente, conforme a figura adiante:

67
TESTE DE UNIDADE

68
TESTE DE UNIDADE

A interface de módulo é testada para assegurar que as


informações fluam corretamente para dentro e para fora da
unidade do programa que está sendo testada.

A estrutura de dados local é examinada para garantir que os


dados armazenados temporariamente mantenham sua
integridade durante todos os passos na execução de um
algoritmo.

69
TESTE DE UNIDADE

Todos os caminhos independentes da estrutura de controle


são usados para assegurar que todas as instruções em um
módulo tenham sido executadas pelo menos uma vez.

As condições limite são testadas para garantir que o módulo


opere adequadamente nas fronteiras estabelecidas para
restringir ou limitar o processamento.

70
TESTE DE UNIDADE

Todos os caminhos de manipulação de erro são testados.

Casos de testes deverão ser projetados para descobrir erros


devido a computações errôneas, comparações incorretas ou
fluxo de controle inadequado.

71
TESTE DE UNIDADE - PROCEDIMENTO

Uma vez que um componente pode não ser um programa


individual, softwares driver e/ou stub podem ser
necessários para a realização do teste.

Driver (pseudocontrolador) é um substituto temporário de


um módulo superior que permite que um módulo
subordinado a ele seja testado.

Stub (pseudocontrolado) é um substituto temporário de um


módulo subordinado que permite que o módulo ao qual está
subordinado seja testado.
72
TESTE DE UNIDADE - PROCEDIMENTO

73
TESTE DE UNIDADE - PROCEDIMENTO

Um driver representa o “programa principal” que aceita


dados do caso de teste e passa esses dados para o
componente a ser testado.

Um stub utiliza a interface dos módulos subordinados, pode


fazer uma manipulação de dados mínima através de
verificação de entrada e retorno do controle para o módulo
que está sendo testado.

74
TESTE DE UNIDADE - PROCEDIMENTO

Driver e stub representam despesas indiretas no projeto de


desenvolvimento de software, pois são softwares que devem
ser escritos e que não serão fornecidos com o produto final.

75
TESTE DE UNIDADE - OO

Quando consideramos o software orientado a objeto, o


conceito de unidade se modifica.

Não podemos mais testar uma única operação isoladamente


como no desenvolvimento convencional, mas como parte de
uma classe.

Neste caso uma classe encapsulada é usualmente o foco do


teste de unidade e as operações (métodos) dentro da classe
são as menores unidades testáveis.

76
TESTE DE UNIDADE - OO

Uma classe pode conter um conjunto de diferentes


operações, e uma operação em particular pode existir como
parte de um conjunto de diferentes classes.

Assim o teste de classe para software OO é o equivalente


ao teste de unidade para software convencional e foca nas
operações encapsuladas na classe e pelo estado de
comportamento da classe.

77
ENGENHARIA DE SOFTWARE
Atividade Avaliativa
Em grupos, os alunos deverão escolher um sistema que seja do
conhecimento de todos (rede social, aplicativo de mensagens,
delivery, internet banking, etc.) e listar 10 casos de teste, que
podem abordar diversos cenários. Após o trabalho, os grupos
deverão apresentar os seus casos de teste, para os demais alunos.

Este trabalho vale 1,0 ponto, para compor a nota da AV1.

Pode-se usar a bibliografia da aula ou outra na internet(neste caso


TEM que se referenciar a origem: http://xxx.xxx.xx ) OBS: Trabalho
de 2 a 4 páginas (formato PDF), Não esqueça de colocar matrícula e
nome COMPLETO no trabalho

Os trabalhos deverão ser entregues ao professor por e-mail:


jose.lima@estacio.br

Você também pode gostar