Figures Chapter 8

Captulo 8

Testes de Software 2011 Pearson Prentice Hall. Todos os direitos reservados.slide 1

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Tpicos abordadosTestes de desenvolvimento

Desenvolvimento dirigido a testes

Testes de release

Testes de usurio

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de programaOs testes so destinados a mostrar o que um programa faz, o que pretende fazer e para descobrir os defeitos do programa antes desse ser colocado em uso.

Ao testar o software, voc executa um programa usando dados artificiais.

Voc verifica os resultados do teste para erros, anomalias ou informaes sobre os atributos no funcionais do programa.

Podem revelar a presena de erros, NO a sua ausncia.

O teste parte de um processo de verificao e validao mais geral, que tambm inclui tcnicas de validao esttica.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Objetivos do processo de testesDemonstrar para o desenvolvedor e o cliente que o software atende aos seus requisitos.

Para softwares customizados, isso significa que deve haver pelo menos um teste para cada requisito no documento de requisitos. Para produtos de software genricos, isso significa que deve haver testes para todos as caractersticas do sistema, alm de suas combinaes, as quais sero incorporadas no release do produto.

Para descobrir situaes em que o comportamento do software est incorreto, indesejvel ou em desacordo com sua especificao.

Testes de defeitos esto interessados em eliminar comportamentos indesejveis do sistema, tais como falhas no sistema, interaes indesejveis com outros sistemas, clculos incorretos e corrupo de dados.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Validao e testes de defeitoO primeiro objetivo leva a testes de validao.

Voc espera que o sistema execute corretamente usando um determinado conjunto de casos de teste que refletem o uso esperado do sistema.

O segundo objetivo leva a testes de defeito.

Os casos de teste so projetados para exporem defeitos. Os casos de teste em testes de defeito podem ser deliberadamente obscuros e no precisam refletir como o sistema normalmente usado.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Objetivos do processo de testesTestes de validao

Para demonstrar para o desenvolvedor e o cliente que o sistema de software corresponde s suas exigncias.

Um teste bem sucedido mostra que o sistema opera como planejado.

Testes de defeitos

Para descobrir falhas ou defeitos no software, em que seu comportamento incorreto ou no est em conformidade com a especificao.

Um teste bem sucedido um teste que faz o sistema funcionar incorretamente e, dessa maneira expe um defeito no sistema.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Um modelo entrada-sada de teste de programa

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Verificao vs. validaoVerificao:"Estamos construindo o produto da maneira correta?".

O software deve estar em acordo com sua especificao.

Validao:"Estamos construindo o produto certo?".

O software deve fazer o que o usurio realmente necessita.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Confiana e V & V O objetivo de V &V estabelecer a confiana na adequao do sistema ao seu intuito".

Depende da finalidade do software, das expectativas do usurio e do ambiente de marketing

Finalidade do softwareO nvel de confiana depende do quanto o software crtico para uma organizao.

Expectativas do usurioUsurios podem ter expectativas baixas em certos tipos de software.

Ambiente de marketingColocar um produto em um mercado rapidamente pode ser mais importante do que encontrar defeitos no programa.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Inspees e testesInspees de software Interessadas na anlise da representao esttica do sistema para descobrir problemas (verificao esttica)

Pode ser suplementado por ferramentas baseadas em documentos e anlise de cdigos.

Teste de software Interessados no exerccio e observando o comportamento do produto (verificao dinmica)

O sistema executado com dados de teste e seu comportamento operacional observado.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Inspees e testes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Inspees de softwareEssas envolvem pessoas examinando principalmente a representao do cdigo-fonte com o objetivo de descobrir anomalias e defeitos.

As inspees no exigem a execuo de um sistema, assim, podem ser usadas antes da implementao.

Elas podem ser aplicadas a qualquer representao do sistema (requisitos, os dados de projeto, configurao, dados de teste, etc.)

Tm se mostrado uma tcnica eficaz para descobrir defeitos de programa.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Vantagens das inspeesDurante os testes, os erros podem mascarar (esconder) outros erros. Pois a inspeo um processo esttico, no qual no necessrio se preocupar com as interaes entre os erros.

Verses incompletas de um sistema podem ser inspecionadas sem custos adicionais.

Se um programa est incompleto, ento necessrio desenvolver equipamentos de teste especializados para testar as partes que esto disponveis.

Bem como procurar por defeitos no programa, uma inspeo tambm pode considerar atributos mais amplos de qualidade de um programa, como o cumprimento de normas, portabilidade e manutenibilidade.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Inspees e testesInspees e testes so complementares e no tcnicas opostas de verificao.

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

As inspees podem verificar a conformidade com uma especificao, mas no a conformidade com os requisitos reais do cliente.

As inspees no podem verificar caractersticas no-funcionais, como desempenho, usabilidade, etc.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Um modelo do processo de teste de software

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Estgios de testeTestes de desenvolvimento, no qual o sistema testado durante seu desenvolvimento para descobrir bugs e defeitos.

Testes de release, em que uma equipe de testes separada testa uma verso completa do sistema antes que ele seja liberado para os usurios.

Testes de usurio, em que os usurios ou potenciais usurios de um sistema testam o sistema em seu prprio ambiente.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de desenvolvimentoTestes de desenvolvimento incluem todas as atividades de testes que so realizas pela equipe de desenvolvimento do sistema.

Teste de unidade, em que so testadas as unidades de programa individual ou classes de objetos. Os teste de unidade devem se concentrar em testar a funcionalidade dos objetos ou mtodos.

Testes de componentes, em que vrias unidades individuais so integradas para criar componentes compostos. Testes de componentes devem se concentrar em testar as interfaces dos componentes.

Teste de sistema, em que alguns ou todos os componentes de um sistema so integrados e o sistema testado como um todo. Esses devem se concentrar em testar interaes entre os componentes.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de unidadeTeste de unidade o processo de teste de componentes individuais isoladamente.

um processo de teste de defeitos.

As unidades podem ser:

Funes individuais ou mtodos dentro de um objeto

Classes de objetos com vrios atributos e mtodos

Componentes compostos com interfaces definidas usados para acessar suas funes.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de classe de objetoA cobertura completa dos testes de uma classe envolve

Testes de todas as operaes associadas com um objeto

Definio e verificao de todos os atributos do objeto

Exercitar o objeto em todos os estados possveis.

A herana torna mais difcil projetar testes de classe de objeto pois a informao a ser testada no localizada.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.A interface do objeto Estao Meteorolgica

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes na estao meteorolgicaNecessidade de definir casos de testes para relatar o clima, calibrar, reiniciar e desligar.

Usando um modelo de estado, identificar as sequncias de transies de estado a serem testadas e as sequncias de eventos para causar essas transies.

Por exemplo:

Desligar-> Executar-> Desligar

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

Executar->Coletar->Executar->Resumir->Transmitir->Executar

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes automatizadosSempre que possvel, os testes de unidade deve ser automatizados para que essas sejam executados e verificados sem interveno manual.

Em testes de unidade automatizados, voc faz uso de um framework de automao de teste (como JUnit) para escrever e executar os testes do seu programa.

Frameworks de testes de unidade fornecem classes de testes genricos que voc estende para criar casos de teste especficos.

Eles podem executar todos os testes implementados e informar, muitas vezes por meio de alguma interface grfica, sobre o sucesso ou fracasso dos testes.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Componentes de testes automatizados Uma parte da configurao, em que voc inicia o sistema como caso de teste, ou seja, as entradas e sadas esperadas.

Uma parte de chamada, em que voc chama o objeto ou o mtodo a ser testado.

Uma parte afirmao, em que voc compara os resultados da chamada com o resultado esperado.

Se a afirmao avaliada como verdadeira, o teste foi bem sucedido, se for falsa, ento ele falhou.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Eficcia dos testes de unidadeOs casos de teste devem mostrar que, quando usado como esperado, o componente sendo testado faz o que supostamente ele deve fazer.

Se houver defeitos no componente, esses devem ser revelados por casos de testes.

O que nos leva a dois tipos de casos de teste de unidade:

O primeiro deve refletir a operao normal de um programa e deve mostrar que o componente funciona como esperado.

O outro tipo de casos de teste deve ser baseado em testes de experincias, de onde surgem os problemas comuns. Ele deve usar entradas anormais para verificar se esses so devidamente processados e que o componente no falhe.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Estratgias de testeTestes de partio, nos quais se identificam grupos de entradas que tm caractersticas comuns e devem ser processados da mesma maneira.

Voc deve escolher os testes de dentro de cada um desses grupos.

Testes baseados em diretrizes, em que voc usa diretrizes de testes para escolher casos de teste.

Essas diretrizes refletem a experincia anterior dos tipos de erros que os programadores cometem frequentemente no desenvolvimento de componentes.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de partioMuitas vezes, os dados de entrada e resultados de sada, caem em diferentes classes, em que todos os membros de uma classe esto relacionados.

Cada uma dessas classes uma partio de equivalncia ou domnio, em que o programa se comporta de uma forma equivalente para cada membro da classe.

Casos de testes devem ser escolhidos a partir de cada partio.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Particionamento de equivalncia

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Parties de equivalncia

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Diretrizes de teste (sequncias)Testar o software com as sequncias que possuem apenas um nico valor.

Usar sequncias de tamanhos diferentes em diferentes testes.

Derivar testes para que o primeiro elemento da sequencia, os do meio e o ltimo sejam acessados.

Testar com sequncias de comprimento zero.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Diretrizes gerais de testesEscolher entradas que forcem o sistema a gerar todas as mensagens de erro.

Projetar entradas que causem o transbordamento dos buffers de inputs.

Repetir a mesma entrada ou uma srie de entradas inmeras vezes.

Forar a gerao de sadas invlidas.

Forar os resultados de clculos serem muito grandes ou muito pequenos.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Pontos ImportantesOs testes podem apenas mostrar a presena de erros em um programa. Eles no podem demonstrar que no existem defeitos remanescentes.

Testes de desenvolvimento so de responsabilidade da equipe de desenvolvimento de software.

Uma equipe separada deve ser responsvel por testar um sistema antes que ele seja liberado para os clientes.

Testes de desenvolvimento incluem testes de unidade, em que voc testa objetos individuais e mtodos de componentes, em que voc testa grupos de objetos relacionados e testes do sistema, em que voc testa sistemas parciais ou completos.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Teste de componenteGeralmente, os componentes de software so componentes compostos de vrios objetos que interagem.

Por exemplo, no sistema da estao meteorolgica, o componente reconfigurao inclui objetos que lidam com cada aspecto da reconfigurao.

Voc acessa a funcionalidade desses objetos atravs da interface do componente definido.

Portanto, os testes de componentes compostos devem focar em mostrar que a interface do componente se comporta de acordo com sua especificao.

Voc pode supor que j foram concludos os testes de unidade sobre os objetos individuais dentro do componente.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Teste de interface

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Teste de interfaceOs objetivos so detectar defeitos devidos a erros de interface ou suposies invlidas sobre as interfaces.

Tipos de interfaces

Interfaces de parmetro - Dados passados de um mtodo ou procedimento para o outro.Interfaces de memria compartilhada - Blocos de memria so compartilhados entre os procedimentos ou funes.Interfaces de procedimento - Subsistemas sintetizam um conjunto de procedimentos para serem chamados por outros subsistemas.Interfaces de passagem de mensagem - Subsistemas solicitam servios de outros subsistemas.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Erros de interfaceMau uso de interface

Um componente chamado chama outro componente e comete um erro no uso da sua interface, por exemplo, de parmetros na ordem errada.

Mau entendimento de interface

Um componente chamador, incorpora suposies incorretas sobre o comportamento dos componentes chamados.

Erros de timing

O componente chamador e o componente chamado operam em velocidades diferentes e so acessadas informaes desatualizadas.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Diretrizes de testes de interfaceProjete os testes de modo que os valores dos parmetros para um procedimento chamado estejam nos extremos de suas escalas.

Sempre teste parmetros de ponteiros com ponteiros nulos.

Projete os testes que causam a falha do componente.

Use testes de estresse em sistemas de passagem de mensagens.

Em sistemas de memria compartilhada, varie a ordem em que os componentes so ativados.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de sistemaTestes de sistema durante o desenvolvimento envolvem a integrao dos componentes para criar uma verso do sistema e, em seguida, testar o sistema integrado.

O foco dos testes de sistema testar as interaes entre os componentes.

Os testes de sistema verificam se os componentes so compatveis ,se interagem corretamente e transferem os dados certos no momento certo por suas interfaces.

Os testes de sistema testam o comportamento emergente de um sistema.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de sistema e de componentesDurante os testes de sistema, os componentes reusveis que tenham sido desenvolvidos separadamente e os sistemas de prateleira podem ser integrados com os componentes recm-desenvolvidos. Em seguida, o sistema completo testado.

Nesse estgio podem ser integrados os componentes desenvolvidos por diferentes membros da equipe ou subequipes. Os testes de sistema so um processo coletivo, e no um processo individual.

Em algumas empresas, o teste de sistema pode envolver uma equipe de testes separada do envolvimento de projetistas e programadores.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de casos de uso Os casos de uso desenvolvidos para identificar as interaes do sistema podem ser usados como uma base para testes de sistema.

Geralmente, cada caso de uso envolve vrios componentes do sistema, assim que, os testes de caso de uso foram a ocorrncia dessas interaes.

Os diagramas de sequncia associados com os documentos de casos de uso, os componentes e as interaes que esto sendo testadas.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Diagrama de sequncia de coletar dados meteorolgicos

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Polticas de testesTestes de sistema exaustivos so impossveis, assim polticas de teste que definem a cobertura necessria dos testes do sistema devem ser desenvolvidas.

Exemplos de polticas de testes:

Todas as funes do sistema que so acessados atravs de menus devem ser testadas.

Devem ser testadas todas as combinaes de funes (por exemplo, formatao de texto) acessadas por meio do mesmo menu.

Onde a entrada do usurio fornecida, todas as funes devem ser testadas com entradas corretas e incorretas.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Desenvolvimento dirigido a testesO desenvolvimento dirigido a testes (TDD Test Driven Development) uma abordagem para o desenvolvimento de programas em que se intercalam testes e o desenvolvimento de cdigo.

Testes so escritos antes do cdigo e "passar" nos testes o fator crtico de desenvolvimento.

Voc desenvolve o cdigo de forma incremental, juntamente com um teste para esse incremento. Voc no passa para o prximo incremento at que o cdigo que voc desenvolveu passe no seu teste.

TDD foi introduzido como parte dos mtodos geis como o Extreme Programming. No entanto, ele tambm pode ser usado em processos de desenvolvimento dirigido a planos.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Desenvolvimento dirigido a testes

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Processo de atividades de TDDIniciar identificando o incremento de funcionalidade que necessria. Isto deve ser normalmente pequeno e implementvel em poucas linhas de cdigo.

Escrever um teste para esta funcionalidade e implementar isso como um teste automatizado.

Executar o teste, junto com todos os outros testes que foram implementadas. Inicialmente, voc no implementou a funcionalidade de modo que o novo teste ir falhar.

Implementar a funcionalidade e reexecutar o teste.

Uma vez que todos os testes forem executados com sucesso, voc se move sobre a implementao da prxima parte de funcionalidade.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Benefcios do TDDCobertura de cdigoCada segmento de cdigo que voc escreve deve ter pelo menos um teste associado, para todo o cdigo escrito tem pelo menos um teste.

Testes de regressoUm conjunto de testes de regresso desenvolvido de forma incremental enquanto um programa desenvolvido.

Depurao simplificadaQuando um teste falhar, deve ser bvio onde est o problema. O cdigo recm-escrito tem de ser verificado e modificado.

Documentao de sistemaOs prprios testes so uma forma de documentao que descreve o que o cdigo deve estar fazendo.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de regressoTestes de regresso testam o sistema para verificar se as mudanas no "quebram" os cdigo previamente trabalhado.

Em um processo de teste manual, os teste de regresso so caros, mas, com testes automatizados, so simples e diretos.

Todos os testes so reexecutados toda vez que feita uma alterao no programa.

Os testes devem ser executados com 'sucesso' antes da mudana ser executada.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de releaseTeste de release o processo de testes de uma verso particular de um sistema que se destina para uso fora da equipe de desenvolvimento.

O principal objetivo do processo de teste de release convencer o fornecedor de que o sistema bom o suficiente para o uso.

Portanto, os testes de release precisam mostrar que o sistema oferece a funcionalidade, o desempenho e confiabilidade especificados, e que no falha durante o uso normal.

Geralmente, os testes de release so um processo de teste caixa-preta, em que os testes so derivados somente a partir da especificao do sistema.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de release e testes de sistemaTestes de release so uma forma de teste do sistema.

Diferenas importantes:

Uma equipe separada, sem envolvimento com o desenvolvimento do sistema, deve ser responsvel pelo testes de release.

Os testes de sistema realizados pela equipe de desenvolvimento devem se centrar na descoberta de bugs do sistema (teste de defeitos). O objetivo do teste de release verificar se o sistema atende aos seus requisitos e bom o suficiente para uso externo. (teste de validao).

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes baseados em requisitosTestes baseados em requisitos envolvem o exame de cada requisito e o desenvolvimento de um teste ou testes para esses.

Requisitos do MHC-PMS:

Se sabido que um paciente alrgico a algum medicamento em particular, a prescrio dessa medicao deve resultar na emisso de uma mensagem de aviso para o usurio do sistema.

Se um mdico opta por ignorar um aviso de alergia, ele deve fornecer o motivo pelo qual o aviso foi ignorado.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de requisitosDefinir um registro do paciente alrgico. Prescrever medicamentos para as alergias que j conhecidas. Verificar se o sistema emite uma mensagem de aviso.

Criar o registro de um paciente com alergia. Prescrever a medicao para a alergia do paciente, e verificar se o aviso emitido pelo sistema.

Estabelecer um registro do paciente em que so registradas alergias a duas ou mais medicaes. Prescrever ambas as medicaes separadamente e verificar se emitido o aviso correto para cada droga.

Receitar dois medicamentos s quais o paciente alrgico. Verificar se so emitidos corretamente dois avisos.

Prescrever um medicamento que emite um aviso e ignorar esse aviso. Verificar se o sistema exige informaes explicando por que o aviso foi ignorado.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Caractersticas testadas pelo cenrioAutenticao por logon no sistema.Download e upload dos registros de um paciente especfico para um computador porttil.Programao de visitas domiciliares.Criptografia e descriptografia do registros de um paciente em um dispositivo mvel.Recuperao e modificao de registros. Links com o banco de dados dos medicamentos, o qual mantm informaes sobre os efeitos colaterais.O sistema de aviso de chamada.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Um cenrio de uso para o MHC-PMSKate uma enfermeira especialista em sade mental. Uma de suas responsabilidades visitar os pacientes em casa para verificar a eficcia do tratamento e se os pacientes esto sofrendo com os efeitos colaterais da medicao.

Em um dia de visitas, Kate faz o login no MHC-PMS e usa-o para imprimir sua agenda de visitas domiciliares para aquele dia, juntamente com o resumo das informaes sobre os pacientes a serem visitados. Ela pede que os registros desses pacientes sejam transferidos para seu notebook. solicitada a palavra-chave para criptografar os registros no notebook.

Um dos pacientes que Kate visita Jim, que est sendo tratado com medicao para depresso. Jim acha que a medicao est ajudando, mas acredita que tem o efeito colateral de mant-lo acordado durante a noite. slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Um cenrio de uso para o MHC-PMSKate vai consultar o registro de Jim; sua frase-chave solicitada para decifrar o registro. Ela verifica o medicamento prescrito e consulta seus efeitos colaterais. Insnia um efeito colateral conhecido.

Ela faz uma observao sobre o problema no registro de Jim e sugere que ele visite a clnica para ter sua medicao alterada. Ele concorda. Assim, Kate faz um prompt de entrar em contato com ele quando ela voltar clnica, para que faa uma consulta com um mdico. Ela termina a consulta e o sistema criptografa novamente o registro de Jim.

Depois, terminadas suas consultas, Kate retorna clnica e transfere os registros dos pacientes visitados para o banco de dados. O sistema gera para Kate uma lista de pacientes que ela precisa contatar para obter informaes de acompanhamento e fazer agendamentos de consultas.slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de desempenhoParte dos testes de release podem envolver ensaios sobre as propriedades emergentes de um sistema, tais como desempenho e confiabilidade.

Os testes devem refletir o perfil de uso do sistema.

Geralmente, os testes de desempenho envolvem o planejamento de uma srie de testes, nos quais a carga aumentada continuamente at que o desempenho do sistema se torne inaceitvel.

Testes de estresse so uma forma de testes de desempenho em que o sistema deliberadamente sobrecarregado para testar seu comportamento at falhar.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Testes de usurioTestes de usurio ou cliente, uma etapa no processo de teste em que os usurios ou clientes fornecem informaes e conselhos sobre os testes de sistema.

Testes com usurios so essenciais, mesmo quando j foram realizados os testes de sistema abrangentes e testes de release.

A razo para tanto, que as influncias do ambiente de trabalho do usurio tem um efeito importante sobre a confiabilidade, desempenho, usabilidade e robustez de um sistema. Esses no podem ser replicados em um ambiente de teste.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Tipos de testes de usurioTestes alfaUsurios do software trabalham com a equipe de desenvolvimento para testar o software no local do desenvolvedor.

Testes betaUm release do software disponibilizado para os usurios para que possam experimentar e levantar os problemas descobertos com os desenvolvedores do sistema.

Testes de aceitaoClientes testam um sistema para decidir se se esse est pronto para ser aceito dos desenvolvedores do sistema, e implantado no ambiente do cliente. Principalmente para sistemas sob encomenda.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.O processo de testes de aceitao

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Estgios do processo de testes de aceitaoDefinir critrios de aceitao

Planejar testes de aceitao

Derivar testes de aceitao

Executar testes de aceitao

Negociar resultados de teste

Rejeitar/aceitar sistema

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Mtodos geis e testes de aceitaoEm mtodos geis, o cliente/usurio faz parte da equipe de desenvolvimento e responsvel pela tomada de decises sobre a aceitabilidade do sistema.

Os testes so definidos pelo usurio/cliente e so integrados com outros testes executados automaticamente quando mudanas so feitas.

No existem processo de testes de aceitao separados.

O principal problema aqui se o usurio incorporado ou no um usurio "tpico" e se pode representar os interesses de todos os stakeholders do sistema.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Pontos ImportantesAo testar o software, voc deve tentar "quebrar o software usando a experincia e as diretrizes para escolher tipos de casos de teste que tm sido eficazes na descoberta de defeitos em outros sistemas.

Sempre que possvel, voc deve escrever testes automatizados.

Cada vez que uma mudana feita em um sistema, os testes so incorporados em um programa que possa ser executado.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.Pontos ImportantesO desenvolvimento test-first uma abordagem para o desenvolvimento em que os testes so escritos antes do cdigo ser testado.

Os testes de cenrio envolvem a inveno de um cenrio tpico de uso e p uso desse para derivar casos de testes.

Os testes de aceitao so um processo de teste de usurio, em que o objetivo decidir se o software bom o suficiente para ser implantado e usado em seu ambiente operacional.

slide n

2011 Pearson Prentice Hall. Todos os direitos reservados.