Capítulo 8 - Teste de Software - di.ubi.ptsebastiao/Ensino/UBI/2017-2018/ES/Teoricas/Ch8... · 2017/2018 Capítulo 8 Teste de Software 3. Objetivos do teste Para demonstrar que o

Capítulo 8 - Teste de Software

Capítulo 8 Teste de Software 12017/2018

Assuntos abordados

Testes de desenvolvimento

Desenvolvimento orientado a testes

Testes de liberação

Testes com utilizadores


Teste

O teste tem a intenção de mostrar que um programa faz o

que se pretende fazer e de descobrir defeitos do programa

antes de ser colocado em uso.

Quando se testa um software, executa-se um programa

usando dados artificiais.

Verifica-se os resultados do teste para erros, anomalias ou

informações sobre os atributos não-funcionais do programa.

Pode revelar a presença de erros não a sua

ausência.

O teste é parte de um processo de verificação e validação

mais geral, que também inclui técnicas de validação

estáticos.


Objetivos do teste

Para demonstrar que o software atende os seus requisitos.

Para software personalizado, isto significa que deve haver pelo

menos um teste para cada requisito no documento de requisitos.

Para produtos de software genéricos, isso significa que não

deve haver testes para todos os recursos do sistema, além de

combinações desses recursos, que serão incorporadas no

lançamento do produto.

Para descobrir situações em que o comportamento do software

seja incorreto, indesejável ou não esteja em conformidade com a

sua especificação.

testes de defeito está preocupado com extrair o comportamento

do sistema indesejável, tais como falhas no sistema, as

interacções indesejadas com outros sistemas, cálculos

incorrectos e corrupção de dados.


O teste de validação e defeito

A primeira meta leva a testes de validação

Espera-se que o sistema execute corretamente, usando um

determinado conjunto de casos de teste que refletem o uso

esperado do sistema.

O segundo objetivo leva ao teste de defeito

Os casos de teste são projetados para expor defeitos. Os casos

de teste em teste de defeito não precisam refletir como o

sistema é usado normalmente.


Objetivo do processo de teste

Testes de validação

Para demonstrar que o software atende aos seus requisitos

Um teste bem sucedido mostra que o sistema funciona como

pretendido.

Teste de defeito

Para descobrir falhas ou defeitos no software, onde o seu

comportamento está incorreto ou não está em conformidade

com a sua especificação

Um teste bem sucedido é um teste que faz com que o sistema

funcione de forma incorreta e assim expõe um defeito no

sistema.


A modelo de teste de programa de entrada-saída


Verificação vs validação

Verificação:

“Está-se a desenvolver o produto correto”.

O software deve estar de acordo com sua especificação.

Validação:

"Está-se a desenvolver corretamente o produto”.

O software deve fazer o que o utilizador realmente

precisa.


V & V

Objetivo da V & V é estabelecer a confiança de que osistema está 'apto para o efeito'.

Depende do propósito, as expectativas do utilizador e omercado ambiente do sistema

Propósito do programa

• O nível de confiança depende do grau de importância do softwarepara a organização.

Expectativas do utilizador

• Os utilizadores podem ter baixas expectativas de certos tipos desoftware.

Ambiente do mercado

• Conseguir um produto para o mercado, no início, pode ser maisimportante do que encontrar defeitos no software.


Inspecções e testes

A inspeção preocupa-se com a análise estática do

sistema, para descobrir problemas (verificação

estática).

O teste preocupa-se com o comportamento do

programa quando está em execução (verificação

dinâmica).

O sistema é executado com dados de teste e é observado o

seu comportamento operacional.


Inspeções e testes


Inspeções de software

Envolvem as pessoas que examinaram a representação

de origem, com o objetivo de descobrir anomalias e

defeitos.

Inspeções não exigem a execução de um sistema antes

da implementação.

Podem ser aplicados a qualquer representação do

sistema (requisitos, dados de configuração, os dados de

ensaio, etc.).

São uma técnica eficaz para descobrir erros de

programa.


Vantagens de inspeções

Durante os testes, os erros podem mascarar (ocultar)

outros erros. Como a inspeção é um processo estático,

não existe a preocupação com as interações entre erros.

Versões incompletas de um sistema podem ser

inspecionadas, sem custos adicionais.

Bem como a procura de defeitos do programa, uma

inspeção pode também considerar atributos de

qualidade mais amplas de um programa, como a

conformidade com os padrões, portabilidade e facilidade

de manutenção.


Inspecções e testes

Inspeções e testes são técnicas de verificação

complementares e não opostas.

Ambos devem ser usadas durante o processo de V & V.

As inspeções podem verificar a conformidade com uma

especificação, mas não verificam a conformidade com

os requisitos reais do cliente.

Inspeções não podem verificar características não-

funcionais, como desempenho, usabilidade, etc.


Modelo do processo de teste de software


Fases de testes

Testes de desenvolvimento, onde o sistema é testado

durante o desenvolvimento para descobrir erros e

defeitos.

Testes de release, onde uma equipa de teste, testa uma

versão completa do sistema antes de ser implantado no

cliente.

Testes de utilizador, onde os utilizadores ou potenciais

utilizadores de um sistema testam o sistema no seu

próprio ambiente.





Testes de desenvolvimento, incluem todas as atividades

de testes que são realizados pela equipa de

desenvolvimento do sistema.

Teste de unidade, onde são testados unidades individuais do

programa ou classes de objectos. O teste de unidade deve-se

concentrar em testar a funcionalidade de objetos ou métodos.

Teste de componentes, em que várias unidades individuais são

integradas para criar componentes compostos. o teste de

componentes deve-se concentrar em testar interfaces de

componentes.

Teste do sistema, onde alguns ou todos os componentes de um

sistema estão integrados e o sistema é testado como um todo.

O teste do sistema deve se concentrar em testar interações de

componentes.Capítulo 8 Teste de Software 182017/2018

O teste de unidade

O teste de unidade é o processo de testar componentes

individuais isoladamente.

É um processo de teste de defeito.

As unidades podem ser:

As funções individuais ou métodos dentro de um objeto

Classes de objetos com vários atributos e métodos

Componentes compostos com interfaces definidas, utilizadas

para aceder à funcionalidade.


Testes de classe de objeto

Cobertura de teste completo de uma classe envolve

Testar todas as operações associadas a um objeto

Definir e interrogar todos os objetos atributos

Exercitando o objeto em todos os estados possíveis.


Interface da estação de metereologia objecto


Testes da estação meteorológica

Necessidade de definir casos de teste para

reportWeather, Calibre, teste, inicialização e

encerramento.

Usa-se um modelo de estado, para identificar

sequências de transições de estado a ser testados e as

sequências de eventos para causar estas transições

Por exemplo:

Desligar -> Executar-> Desligar

Configurar-> Executar-> Testar -> Transmitir -> Executar

Executar-> Recolher Dados-> Executar -> Resumir -> Transmitir

-> Executar


Testes automatizados

Sempre que possível, o teste de unidade deve ser

automatizado para que os testes sejam executados e

verificados sem intervenção manual.

Em testes de unidade automatizado, faz-se uso de um

quadro de automação de teste (tal como JUnit) para

escrever e executar os testes do programa.

Frameworks de Testes Unidade, fornecem classes de

teste genéricos que se estendem para criar casos de

teste específicos. Eles podem, em seguida, executar

todos os testes que são implementados e criar os

respetivos relatório.


Componentes de testes automatizados

Uma parte da configuração, onde se inicializa o sistema

com o caso de teste, ou seja, as entradas e saídas

esperadas.

A parte da chamada, onde se chama o objeto ou método

a ser testado.

Uma parte da afirmação, onde se compara o resultado

da chamada com o resultado esperado. Se a afirmação

for avaliada como verdadeira, o teste foi bem sucedido

se for falso, então ele falhou.


Escolher casos de teste de unidade

Os casos de teste deve mostrar que, quando usado como

esperado, o componente que se está a testar faz o que é suposto

fazer.

Se houver defeitos no componente, estes devem ser revelados

pelos casos de teste.

Isto leva a 2 tipos de casos de teste de unidade:

A primeira delas deve refletir o funcionamento normal de um programa

e deve mostrar que o componente funciona como esperado.

O outro tipo de caso de teste deve ser baseado na experiência em

testes de onde surgem os problemas comuns. Deve usar entradas

anormais para verificar que estas sejam devidamente processados e

não falha do componente.


Estratégias de teste

Testes de partição, onde se identifica grupos de

entradas que têm características comuns e devem ser

processados da mesma maneira.

Deve-se escolher os testes dentro de cada um desses grupos.

Base dos teste, onde se usam diretrizes de teste para

escolher casos de teste, baseados nessas diretrizes.

Essas diretrizes refletem a experiência prévia dos tipos de erros

que os programadores muitas vezes fazem ao desenvolver

componentes.


Testes de partição

Os dados de entrada e resultados de saída, muitas

vezes caem em classes diferentes, onde todos os

membros de uma classe estão relacionados.

Cada uma dessas classes é uma partição de

equivalência ou domínio em que o programa se

comporta de uma forma equivalente para cada membro

da classe.

Os casos de teste devem ser escolhidos de cada

partição.


Equivalência particionamento


Equivalência partições


Diretrizes gerais de testes

Escolher entradas que forçam o sistema a gerar todas

as mensagens de erro

Repetir a mesma entrada várias vezes

Forçar saídas inválidas


Testes de componentes

Componentes de software são muitas vezes

componentes compostos por vários objetos que

interagem entre si.

Por exemplo, no sistema de estação de meteorologia, o

componente de reconfiguração inclui objetos que lidam com

cada aspeto da reconfiguração.

Acessa-se a funcionalidade desses objetos através da

interface do componente definido.

Componentes compostos de teste devem, portanto,

concentrar-se em mostrar que a interface componente

se comporta de acordo com a sua especificação.


Teste de interface

Objetivos são detetar falhas devido a erros de interface

ou suposições inválidas sobre interfaces.

Tipos de interface

Parâmetro - Os dados transmitido de um método ou processo

para outro.

Memória partilhada - Bloco de memória é partilhado entre os

procedimentos ou funções.

Procedimentos - Subsistema encapsula um conjunto de

procedimentos para ser chamado por outros subsistemas.

Passagem de mensagens - Solicitar serviços de outros

subsistemas


Erros de interface

Uso indevido de interface

Incompreensão da interface

Erros de temporização


Diretrizes de teste de interface

Testes de design, para que os parâmetros para a chamada

de um procedimento estão nos extremos das suas escalas.

Testar sempre ps parâmetros de ponteiro com ponteiros

nulos.

Testes de design que fazem com que o componente falhe.

Use testes de stresse em sistemas de passagem de

mensagens.

Em sistemas de memória partilhada, variar a ordem em

que os componentes são ativados.


Teste do sistema

Teste do sistema durante o desenvolvimento envolve a

integração de componentes para criar uma versão do

sistema e, em seguida, testar o sistema integrado.

O foco do teste do sistema é testar as interações entre

os componentes.

Verificações de teste do sistema que os componentes

são compatíveis, interagir corretamente e transferir os

dados certos no momento certo através das interfaces.

Teste do sistema testa o comportamento emergente do

sistema.


Teste do sistema e componente

Durante os testes do sistema, componentes

reutilizáveis que foram desenvolvidos separadamente

podem ser integrados com componentes recém-

desenvolvidos. O sistema completo é então testado.

Componentes desenvolvidos por diferentes membros da

equipa ou sub-equipas podem ser integrados nesta fase.

Teste de sistema é colectivo em vez de um processo

individual.

Em algumas empresas, o teste do sistema pode envolver uma

equipa de teste sem envolvimento de designers e

programadores.


Teste de caso de uso

Os casos de uso desenvolvidos para identificar

interações do sistema pode ser usado como uma base

para testes do sistema.

Cada caso de uso geralmente envolve vários

componentes do sistema, assim o teste do caso de uso,

força as interações entre componentes.

Os diagramas de sequência associados com os casos

de uso, documenta os componentes e interações que

estão a ser testados.


Políticas de teste

É impossivel existir todas as politicas de testes, de modo

que os teste que definem a cobertura de teste de

sistema exigido podem ser desenvolvidos.

Exemplos de políticas de teste:

Todas as funções do sistema que são acedidas através de

menus devem ser testadas.

Combinações de funções (por exemplo, formatação de texto)

que são acedidas através do mesmo menu devem ser testadas.

Se for fornecido login ao utilizador, todas as funções devem ser

testadas com a entradas corretas e incorretas.





Test-driven development (TDD) é uma abordagem ao

desenvolvimento em que são efetuados teste na fase de

desenvolvimento.

Testes são escritos antes do código e 'passar' os testes é o

driver crítico do desenvolvimento.

Desenvolve-se código de forma incremental, juntamente com

um teste para esse incremento. Não passar para o próximo

incremento até que o código que se desenvolveu passe no

respetivo teste.

TDD foi introduzido como parte de métodos ágeis como

Extreme Programming. No entanto, também pode ser usado

em processos de desenvolvimento orientada para o plano.


TDD


Atividades do processo de TDD

Identificar o incremento da funcionalidade que é necessário. Isto

deve normalmente ser pequeno e implementável em algumas

linhas de código.

Escrever um teste para esta funcionalidade e implementar estes

como um teste automatizado.

Executar o teste, juntamente com todos os outros testes que têm

sido implementados. Inicialmente, não se implementa a

funcionalidade de modo que o novo teste falhe.

Implementar a funcionalidade e voltar a executar o teste.

Uma vez que todos os testes são executados com êxito,

implementa-se o próximo incremento da funcionalidade.


Benefícios do desenvolvimento orientado a

testes

Cobertura do código

Cada segmento de código que se escreve tem pelo menos um teste

associado de modo que todo o código escrito tem pelo menos um teste.

Testes de regressão

Um conjunto de testes de regressão é desenvolvido de forma

incremental como um programa é desenvolvido.

Depuração simplificada

Quando um teste falha, ele deve ser óbvio onde reside o problema. O

código recém-escrito precisa ser verificado e modificado.

Documentação do sistema

Os próprios testes são uma forma de documentação que descreve o

que o código deve fazer.


Testes de regressão

Testes de regressão testa o sistema para verificar que

as mudanças não têm 'quebrado' código previamente

feito.

Num processo de testes manuais, testes de regressão

são caros, mas, com testes automatizados, é simples e

direto. Todos os testes são executados novamente toda

vez que uma alteração no programa é feita.

Os testes devem correr 'com sucesso' antes da

mudança estar comprometida.


“Release testing”


Release testing

Testes de “release” é o processo de testar uma versão

particular de um sistema que se destina para uso fora da

equipe de desenvolvimento.

O objetivo principal do processo de teste de “release” é

convencer o fornecedor do sistema que é bom o suficiente

para uso.

testes de “release” têm que mostrar que o sistema oferece a sua

funcionalidade, tem bom desempenho e confiabilidade, e que não

falha durante o uso normal.

Testes de “release” são geralmente um processo de teste

da caixa preta, onde apenas os testes são derivados a

partir da especificação do sistema.


Testes de “release” e testes de sistema

Testes de “release” são uma forma de teste de sistema.

Diferenças importantes:

Uma equipa separada que não foi envolvida no desenvolvimento

do sistema, deve ser responsável por testes de “release”.

Teste do sistema pela equipa de desenvolvimento, deve se

concentrar em descobrir erros no sistema (testes de defeito). O

objetivo do teste de “release” é para verificar se o sistema

atende os seus requisitos e é bom o suficiente para uso externo

(teste de validação).


Testes baseados em requisitos

Testes baseados em requisitos, examina cada requisito

e desenvolvimento de um teste ou testes para esse

requisito.

Requisitos do sistema Mentcare:

Se um paciente é conhecido por ser alérgico a qualquer

medicamento, então a prescrição da medicação deve resultar

numa mensagem de aviso a ser emitida para o utilizador do

sistema.

Se um médico opta por ignorar um aviso de alergia, eles devem

fornecer uma razão para que isso foi ignorado.


Teste de performance

Parte dos ensaios de “release” pode envolver testes às

propriedades emergentes de um sistema, tais como o

desempenho e fiabilidade.

Os testes devem refletir o perfil de uso do sistema.

Os testes de desempenho geralmente envolvem o

planeamento de uma série de testes onde a carga está

em constante aumento até que o desempenho do

sistema se torne inaceitável.

Os testes de stress é uma forma de testes de

desempenho em que o sistema é sobrecarregado

deliberadamente para testar a sua falha no

comportamento.Capítulo 8 Teste de Software 562017/2018




Utilizador ou testes de cliente é uma etapa no processo

de teste no qual os utilizadores ou clientes fornecem

informações e conselhos sobre o teste do sistema.

Testes com utilizadores é essencial, mesmo quando o

sistema é abrangente e os testes de “release” foram

realizados.

A razão para isto é que influências do ambiente de trabalho do

utilizador têm um efeito importante sobre a confiabilidade,

desempenho, usabilidade e robustez de um sistema. Estes não

podem ser replicados num ambiente de teste.


Tipos de testes com utilizadores

Teste Alpha

Os utilizadores do software trabalham com a equipe de

desenvolvimento para testar o software no site do

desenvolvedor.

Teste beta

A versão do software é disponibilizada para os utilizadorss, que

lhes permitam experimentar e levantar problemas que eles

descobrem com os programadores do sistema.

Teste de aceitação

Clientes testam o sistema para decidir se está ou não está

pronto para ser aceite pelos programadores do sistema e

implantado no ambiente do cliente. Principalmente para

sistemas personalizados.Capítulo 8 Teste de Software 592017/2018

O processo de teste de aceitação


Fases do processo de teste de aceitação

Definir critérios de aceitação

Plano do teste de aceitação

Derivar os testes de aceitação

Executar os testes de aceitação

Negociar os resultados dos testes

Aceitar ou Rejeitar o sistema


Métodos ágeis e testes de aceitação

Em métodos ágeis, o utilizador / cliente faz parte da equipa

de desenvolvimento e é responsável pela tomada de

decisões sobre a aceitabilidade do sistema.

Os testes são definidos pelo utilizador / cliente e estão

integrados com outros testes na medida em que são

executados automaticamente quando são feitas alterações.

Não há nenhum processo de teste de aceitação separado.


Pontos chave

Teste só pode mostrar a presença de erros num

programa. Ele não pode demonstrar que não existem

falhas remanescentes.

Testes de desenvolvimento são da responsabilidade da

equipa de desenvolvimento de software. Uma outra

equipa deve ser responsável por testar um sistema

antes de ser entregue aos clientes.

Ao testar o software, deve-se tentar 'quebrar' o software

usando experiência e diretrizes para escolher os tipos

de caso de teste que têm sido eficazes na descoberta

de defeitos noutros sistemas.


Pontos chave

Sempre que possível, deve-se escrever testes

automatizados. Os testes estão embutidos num

programa que pode ser executado a cada vez que uma

alteração é feita para um sistema.

Testar o desenvolvimento anterior é uma abordagem

para o desenvolvimento em que os testes são escritos

antes de o código ser testado.

O teste de aceitação é um processo de teste de

utilizador onde o objectivo é decidir se o software é bom

o suficiente para ser implantado e utilizado no seu

ambiente operacional.


Documents

Capítulo 8 - Teste de Software - di.ubi.ptsebastiao/Ensino/UBI/2017-2018/ES/Teoricas/Ch8... · 2017/2018 Capítulo 8 Teste de Software 3. Objetivos do teste Para demonstrar que o