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
Capítulo 8 Teste de Software 22017/2018
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.
Capítulo 8 Teste de Software 32017/2018
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.
Capítulo 8 Teste de Software 42017/2018
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.
Capítulo 8 Teste de Software 52017/2018
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.
Capítulo 8 Teste de Software 62017/2018
A modelo de teste de programa de entrada-saída
Capítulo 8 Teste de Software 72017/2018
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.
Capítulo 8 Teste de Software 82017/2018
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.
Capítulo 8 Teste de Software 92017/2018
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.
Capítulo 8 Teste de Software 102017/2018
Inspeções e testes
Capítulo 8 Teste de Software 112017/2018
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.
Capítulo 8 Teste de Software 122017/2018
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.
Capítulo 8 Teste de Software 132017/2018
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.
Capítulo 8 Teste de Software 142017/2018
Modelo do processo de teste de software
Capítulo 8 Teste de Software 152017/2018
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.
Capítulo 8 Teste de Software 162017/2018
Testes de desenvolvimento
Capítulo 8 Teste de Software 172017/2018
Testes de desenvolvimento
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.
Capítulo 8 Teste de Software 192017/2018
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.
Capítulo 8 Teste de Software 202017/2018
Interface da estação de metereologia objecto
Capítulo 8 Teste de Software 212017/2018
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
Capítulo 8 Teste de Software 222017/2018
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.
Capítulo 8 Teste de Software 232017/2018
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.
Capítulo 8 Teste de Software 242017/2018
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.
Capítulo 8 Teste de Software 252017/2018
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.
Capítulo 8 Teste de Software 262017/2018
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.
Capítulo 8 Teste de Software 272017/2018
Equivalência particionamento
Capítulo 8 Teste de Software 282017/2018
Equivalência partições
Capítulo 8 Teste de Software 292017/2018
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
Capítulo 8 Teste de Software 312017/2018
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.
Capítulo 8 Teste de Software 322017/2018
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
Capítulo 8 Teste de Software 332017/2018
Erros de interface
Uso indevido de interface
Incompreensão da interface
Erros de temporização
Capítulo 8 Teste de Software 352017/2018
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.
Capítulo 8 Teste de Software 362017/2018
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.
Capítulo 8 Teste de Software 372017/2018
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.
Capítulo 8 Teste de Software 382017/2018
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.
Capítulo 8 Teste de Software 392017/2018
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.
Capítulo 8 Teste de Software 422017/2018
Desenvolvimento orientado a testes
Capítulo 8 Teste de Software 432017/2018
Desenvolvimento orientado a testes
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.
Capítulo 8 Teste de Software 442017/2018
TDD
Capítulo 8 Teste de Software 452017/2018
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.
Capítulo 8 Teste de Software 462017/2018
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.
Capítulo 8 Teste de Software 472017/2018
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.
Capítulo 8 Teste de Software 482017/2018
“Release testing”
Capítulo 8 Teste de Software 492017/2018
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.
Capítulo 8 Teste de Software 502017/2018
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).
Capítulo 8 Teste de Software 512017/2018
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.
Capítulo 8 Teste de Software 522017/2018
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
Testes com utilizadores
Capítulo 8 Teste de Software 572017/2018
Testes com utilizadores
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.
Capítulo 8 Teste de Software 582017/2018
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
Capítulo 8 Teste de Software 602017/2018
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
Capítulo 8 Teste de Software 612017/2018
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.
Capítulo 8 Teste de Software 622017/2018
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.
Capítulo 8 Teste de Software 632017/2018
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.
Capítulo 8 Teste de Software 642017/2018
Top Related