01-Processo de Teste

Processo de Teste de Software Auri M. R.
Vincenzi Organiza c ao Teste Problemas e Desaos Casos de Teste Tipos de Teste Fases de Teste Resumo Leitura Recomendada Refer encias Refer encias
Processo de Teste de Software

Introdu c ao Auri M. R. Vincenzi
Instituto de Inform atica Universidade Federal de Goi as
2013/2
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos Casos de Teste Tipos de Teste Fases de Teste Resumo Leitura Recomendada Refer encias Refer encias
Teste Problemas e Desaos Desaos do Teste Limita co es do Teste Impossibilidade Casos de Teste Projeto de Casos de Teste Entradas Sa das Or aculo Ordem de Execu c ao Tipos de Teste T ecnicas de Teste Fases de Teste Teste de Unidade Teste de Integra c ao Teste de Sistema Teste de Aceita c ao Modelo V Resumo Leitura Recomendada Refer encias
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos Casos de Teste Tipos de Teste Fases de Teste Resumo Leitura Recomendada Refer encias
O que e teste? (1)
De acordo com a norma IEEE Standard 610.12-1990 (IEEE, 1990): The process of operating a system or component under specied conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. Craig e Jaskiel (2002) apresentam outra deni c ao: Testing is a concurrent lifecycle process of engineering, using and maintaining testware in order to measure and improve the quality of the software being tested.
Refer encias
Programa ArraySort
Conjunto de Teste Baseado em Experi encias Anteriores
Especica c ao:
O programa deve fazer a leitura de um arquivo texto codicado da seguinte forma:
Primeira linha do arquivo: quantidade de n umeros presentes no arquivo. A quantidade deve ser especicada como um n umero inteiro positivo n entre 0 n 65.535; Demais linhas: n umeros a serem ordenados (um n umero por linha). Caso mais de um n umero esteja presente na mesma linha ele ser a ignorado.
O conjunto de n umeros informado deve ser do tipo inteiro de dois bytes na base 10.
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos Casos de Teste Tipos de Teste Fases de Teste Resumo Leitura Recomendada Refer encias
Programa ArraySort
Feita a leitura do arquivo, a sequ encia de n umeros original deve ser apresentada na tela na horizontal com os n umeros separados por v rgula e, em seguida, tais n umeros devem ser ordenados e apresentados em ordem crescente com o mesmo estilo de formata c ao. Em caso de falha, as seguintes mensagens s ao exibidas:
Refer encias
Tamanho inv alido do vetor N umero de elementos divergente do informado Conte udo inv alido do arquivo
Programa ArraySort
Exemplo: Arquivo de entrada: 5 3 2 1 4 5 Sa da esperada: 3, 2, 1, 4, 5 1, 2, 3, 4, 5
O que e teste? (2)
Diferentes organiza c oes e indiv duos t em vis oes diferentes do prop osito dos testes. Processo de Software versus Processo de Teste N veis de maturidade de teste (Beizer, 1990):
N vel 0 - N ao h a diferen ca entre teste e depura c ao (debugging );
O que e teste? (2)
N vel 0 - N ao h a diferen ca entre teste e depura c ao (debugging ); N vel 1 - O prop osito do teste e mostrar que o software funciona.
O que e teste? (2)
N vel 0 - N ao h a diferen ca entre teste e depura c ao (debugging ); N vel 1 - O prop osito do teste e mostrar que o software funciona. N vel 2 - O prop osito do teste e mostrar que o software n ao funciona.
O que e teste? (2)
N vel 0 - N ao h a diferen ca entre teste e depura c ao (debugging ); N vel 1 - O prop osito do teste e mostrar que o software funciona. N vel 2 - O prop osito do teste e mostrar que o software n ao funciona. N vel 3 - O prop osito do teste n ao e provar nada, mas reduzir o risco de n ao funcionamento a um valor aceit avel.
O que e teste? (2)
N vel 0 - N ao h a diferen ca entre teste e depura c ao (debugging ); N vel 1 - O prop osito do teste e mostrar que o software funciona. N vel 2 - O prop osito do teste e mostrar que o software n ao funciona. N vel 3 - O prop osito do teste n ao e provar nada, mas reduzir o risco de n ao funcionamento a um valor aceit avel. N vel 4 - Teste n ao e uma a c ao, mas sim uma disciplina mental (institucionalizada na empresa) que resulta em software de baixo risco sem que seja empregado muito esfor co de teste.
Terminologia (1)
O IEEE Standard Glossary 610.12-1990 (R2002) (IEEE, 2002) diferencia os seguintes termos: 1. Engano (Mistake) a c ao humana que produz um resultado incorreto. Exemplo: uma a c ao incorreta tomada pelo programador. 2. Defeito (Fault) um passo, processo, ou deni c ao de dados incorreta em um produto de software. No uso comum, os termos erro , bug , e defeito s ao usados para expressar esse signicado. Exemplo: um comando ou instru c ao incorreta. 3. Erro (Error) diferen ca entre o valor computado, observado ou medido e o valor teoricamente correto de acordo com a especica c ao. 4. Falha (Failure) inabilidade do sistema ou componente realizar a fun c ao requerida, considerando as quest oes de desempenho exigidas.
Terminologia (2)
Rela c ao da terminologia padr ao.
Engano
introduz
Defeito
produz
Erro
propaga
Erro
Falha
Causa Consequ encia
Terminologia (3)
Considere o seguinte comando de atribui c ao: (z = y + x ) 1. Engano o comando e modicado por (z = y x ), caracterizando um defeito. 2. Defeito se ativado (executado) com x = 0, nenhum resultado incorreto e produzido. Para valores de x = 0, o defeito e ativado causando um erro na vari avel z . 3. Erro o estado err oneo do sistema, quando propagado at e a sa da, causar a uma Falha.
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Desaos do Teste Limita co es do Teste Impossibilidade
Casos de Teste Tipos de Teste Fases de Teste Resumo Leitura Recomendada Refer encias Refer encias

Desaos
Algu em j a testou algum produto de software?

Desaos

Algu em j a testou algum produto de software? Quais foram os maiores desaos?

Desaos

Algu em j a testou algum produto de software? Quais foram os maiores desaos? Alguns problemas comuns s ao:

Desaos

N ao h a tempo para o teste exaustivo.

Desaos


N ao h a tempo para o teste exaustivo. Muitas combina co es de entrada para serem exercitadas.

Desaos


Casos de Teste Tipos de Teste Fases de Teste
Resumo Leitura Recomendada Refer encias Refer encias
N ao h a tempo para o teste exaustivo. Muitas combina co es de entrada para serem exercitadas. Diculdade em determinar os resultados esperados para cada caso de teste.

Desaos


N ao h a tempo para o teste exaustivo. Muitas combina co es de entrada para serem exercitadas. Diculdade em determinar os resultados esperados para cada caso de teste. Requisitos do software inexistentes ou que mudam rapidamente.

Desaos


N ao h a tempo para o teste exaustivo. Muitas combina co es de entrada para serem exercitadas. Diculdade em determinar os resultados esperados para cada caso de teste. Requisitos do software inexistentes ou que mudam rapidamente. N ao h a tempo suciente para o teste.

Desaos


N ao h a tempo para o teste exaustivo. Muitas combina co es de entrada para serem exercitadas. Diculdade em determinar os resultados esperados para cada caso de teste. Requisitos do software inexistentes ou que mudam rapidamente. N ao h a tempo suciente para o teste. N ao h a treinamento no processo de teste.

Desaos


N ao h a tempo para o teste exaustivo. Muitas combina co es de entrada para serem exercitadas. Diculdade em determinar os resultados esperados para cada caso de teste. Requisitos do software inexistentes ou que mudam rapidamente. N ao h a tempo suciente para o teste. N ao h a treinamento no processo de teste. N ao h a ferramenta de apoio.

Desaos


N ao h a tempo para o teste exaustivo. Muitas combina co es de entrada para serem exercitadas. Diculdade em determinar os resultados esperados para cada caso de teste. Requisitos do software inexistentes ou que mudam rapidamente. N ao h a tempo suciente para o teste. N ao h a treinamento no processo de teste. N ao h a ferramenta de apoio. Gerentes que desconhecem teste ou que n ao se preocupam com qualidade.

Problemas Indecid veis (1)

ao existe um algoritmo de prop osito geral para Corre c ao: N provar a corre c ao de um produto de software; Equival encia: Dados dois programas, decidir se eles s ao equivalentes; ou dados dois caminhos (sequ encia de comandos) decidir se eles computam a mesma fun c ao; Executabilidade: Dado um caminho (sequ encia de comandos) decidir se existe um dado de entrada que levem ` a execu c ao de tal caminho. Corre c ao Coincidente: Um produto pode apresentar, coincidentemente, um resultado correto para um dado valor de entrada d D porque um defeito mascara o erro de outro defeito.


ao existe um algoritmo de prop osito geral para Corre c ao: N provar a corre c ao de um produto de software; Equival encia: Dados dois programas, decidir se eles s ao equivalentes; ou dados dois caminhos (sequ encia de comandos) decidir se eles computam a mesma fun c ao; Executabilidade: Dado um caminho (sequ encia de comandos) decidir se existe um dado de entrada que levem ` a execu c ao de tal caminho. Corre c ao Coincidente: Um produto pode apresentar, coincidentemente, um resultado correto para um dado valor de entrada d D porque um defeito mascara o erro de outro defeito.
Essas limita c oes trazem considera c oes importantes no contexto de teste de software, principalmente a impossibilidade de oferecer um suporte totalmente automatizado para todas as atividades de teste.


Exemplos de Equival encia:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
public class Factorial { p u b l i c s t a t i c l o n g compute ( i n t x ) th r ows N e g a t i v e N u m b e r E x c e p t i o n { i f ( x >= 0) { long r = 1; f o r ( int k = 2 ; k <= x ; k++) { r = k ; } return r ; } else { th r ow new N e g a t i v e N u m b e r E x c e p t i o n ( ) ; } } 1 public class Factorial { } 2 p u b l i c s t a t i c l o n g compute ( i n t x ) 3 th r ows N e g a t i v e N u m b e r E x c e p t i o n { 4 i f ( x >= 0) { 5 long r = 1; 6 f o r ( int k = 1 ; k <= x ; k++) { // i n t k = 2 ; 7 r = k ; 8 } 9 return r ; 10 } else { 11 th r ow new N e g a t i v e N u m b e r E x c e p t i o n ( ) ; 12 } 13 } 14 }


Exemplo de N ao-executabilidade:
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
p u b l i c boolean v a l i d a t e I d e n t i f i e r ( S t r i n g s ) { char ac har ; boolean v a l i d i d = f a l s e ; ac har = s . charAt ( 0 ) ; v a l i d i d = v a l i d s ( achar ) ; i f ( s . l e n g t h ( ) > 1) { ac har = s . charAt ( 1 ) ; int i = 1; w h i l e ( i < s . l e n g t h ( ) 1) { ac har = s . charAt ( i ) ; i f (! v a l i d f ( achar )) valid id = false; i ++; } } i f ( v a l i d i d && ( s . l e n g t h ( ) >= 1) && ( s . l e n g t h ( ) < 6 ) ) return true; else return f a l s e ;
N ao existe um caminho execut avel que inclua, simultaneamente, os comandos das linhas 15 e 21.

Impossibilidade do Teste Exaustivo (1)
Por que, simplesmente, n ao se testa todo o produto de forma exaustiva?

Por que, simplesmente, n ao se testa todo o produto de forma exaustiva?
Pode
Dom nio de Entrada
Dom nio de Sa da
Pro duto Produto

ser innito ()

Observe o exemplo abaixo, adaptado de Binder (1999):

1 2 3 4 5
in t blech ( int j ) { j = j 1; // s h o u l d be j = j + 1 j = j / 30000; return j ; }
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos Casos de Teste
Projeto de Casos de Teste Entradas Sa das Or aculo Ordem de Execu ca o
Tipos de Teste Fases de Teste Resumo Leitura Recomendada Refer encias Refer encias
Projeto de Casos de Teste
O segredo do sucesso do teste est a no projeto dos casos de teste. Segundo (Pressman, 2006): The design of tests for software and other engineering products can be as challenging as the initial design of the product itself. Yet ... software engineers often treat testing as an afterthought, developing test cases that feel right but have little assurance of being complete. Recalling the objectives of testing, we must design tests that have the highest likelihood of nding the most errors with a minimum amount of time and eort.
Partes de um Caso de Teste
Um caso de teste bem projetado e dividido em tr es partes:

Entradas (inputs ); Sa das Esperadas (outputs ); Ordem de execu c ao (order of execution).
Partes de um Caso de Teste entradas
Geralmente identicadas como dados fornecidos via teclado para o programa executar. Entretanto, os dados de entrada podem ser fornecidos por outros meios, tais como:
Dados oriundos de outro sistema que servem de entrada para o programa em teste; Dados fornecidos por outro dispositivo; Dados lidos de arquivos ou banco de dados; O estado do sistema quando os dados s ao recebidos; O ambiente no qual o programa est a executando.
Partes de um Caso de Teste sa das esperadas
As sa das tamb em podem ser produzidas de diferentes formas. A mais comum e aquele apresentada na tela do computador. Al em dessa, as sa das podem ser enviadas para:

Outro sistema interagindo com o programa em teste; Dados enviados para um dispositivo externo; Dados escritos em arquivos ou banco de dados; O estado do sistema ou o ambiente de execu c ao podem ser alterados durante a execu c ao do programa.
Partes de um Caso de Teste or aculo (1)
Todas as formas de entrada e sa da s ao relevantes.
Todas as formas de entrada e sa da s ao relevantes. Durante o projeto de um caso de teste, determinar corre c ao da sa da esperada e fun c ao do or aculo (oracle).
Todas as formas de entrada e sa da s ao relevantes. Durante o projeto de um caso de teste, determinar corre c ao da sa da esperada e fun c ao do or aculo (oracle). Or aculo corresponde a um mecanismo (programa, processo ou dados) que indica ao projetista de casos de testes a sa da obtida para um caso de teste e aceit avel ou n ao.
Beizer (1990) lista cinco tipos de or aculos:
Or aculo Kiddie - simplesmente execute o programa e observe sua sa da. Se ela parecer correta deve estar correta. Conjunto de Teste de Regress ao - execute o programa e compare a sa da obtida com a sa da produzida por uma vers ao mais antiga do programa. Valida c ao de Dados - execute o programa e compare a sa da obtida com uma sa da padr ao determinada por uma tabela, f ormula ou outra deni c ao aceit avel de sa da v alida. Conjunto de Teste Padr ao - execute o programa com um conjunto de teste padr ao que tenha sido previamente criado e validado. Utilizado na valida c ao de compiladores, navegadores Web e processadores de SQL. Programa existente - execute o programa em teste e o programa existente com o mesmo caso de teste e compare as sa das. Semelhante ao teste de regress ao.
Partes de um Caso de Teste ordem de execu c ao (1)
Existem dois estilos de projeto de casos de teste relacionados com a ordem de execu c ao:

Casos de teste em cascata. Casos de teste independentes.
Casos de teste em cascata - quando os casos de teste devem ser executados um ap os o outro, em uma ordem espec ca. O estado do sistema deixado pelo primeiro caso de teste e reaproveitado pelo segundo e assim sucessivamente. Por exemplo, considere o teste de uma base de dados:

criar um registro ler um registro atualizar um registro ler um registro apagar um registro ler o registro apagado
Casos de teste em cascata (cont.)
Vantagem - casos de testes tendem a ser pequenos e simples. F aceis de serem projetados, criados e mantidos. Desvantagem - se um caso de teste falhar os casos de teste subsequentes tamb em podem falhar.
Casos de teste independentes - Cada caso de teste e inteiramente autocontido.
Vantagem - casos de teste podem ser executados em qualquer ordem. Desvantagem - casos de teste tendem a ser grandes e complexos, mais dif ceis de serem projetados, criados e mantidos.
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos Casos de Teste Tipos de Teste
T ecnicas de Teste
Fases de Teste Resumo Leitura Recomendada Refer encias Refer encias
T ecnicas de Teste
Tipos de Teste (1)
Diferentes tipos de testes podem ser utilizados para vericar se um programa se comporta como o especicado. Basicamente, os testes podem ser classicados em teste caixa-preta (black-box testing ), teste caixa-branca (white-box testing ) ou teste baseado em defeito (fault-based testing ). Esses tipos de teste correspondem ` as chamadas t ecnicas de teste.
Fases de Teste
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste
Tipos de Teste (2)
Problemas e Desaos Casos de Teste Tipos de Teste

T ecnicas de Teste
A t ecnica de teste e denida pelo tipo de informa c ao utilizada para realizar o teste.
T ecnica caixa-preta - os testes s ao baseados exclusivamente na especica c ao de requisitos do programa. Nenhum conhecimento de como o programa est a implementado e requerido. T ecnica caixa-branca - os testes s ao baseados na estrutura interna do programa, ou seja, na implementa c ao do mesmo. T ecnica baseada em defeito - os testes s ao baseados em informa co es hist orica sobre defeitos cometidos frequentemente durante o processo de desenvolvimento de software.
T ecnicas de Teste
Tipos de Teste (3)
Cada t ecnica de teste possui um conjunto de crit erios de teste. Os crit erios sistematizam a forma como requisitos de teste devem ser produzidos a partir da fonte de informa c ao dispon vel (especica c ao de requisitos, c odigo fonte, hist orico de defeitos, dentre outras). Os requisitos de teste s ao utilizados para:

Fases de Teste Resumo Leitura Recomendada Refer encias
Refer encias
Gerar casos de teste. Avaliar a qualidade de um conjunto de teste existente.
T ecnicas de Teste
T ecnicas, Crit erios e Requisitos de Teste
T ecnica de Teste
tem
dene
Fonte de Informa c ao
usam
Crit erios de Teste

derivam
Requisitos de Teste
avalia c ao gera c ao
Casos de Teste
**Requisitos n ao-execut aveis.
Termos utilizados na area de teste e seus relacionamentos
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao
Papel dos Crit erios de Teste
Teste Problemas e Desaos Casos de Teste Tipos de Teste

T ecnicas de Teste
Subdividir o dom nio de entrada for cando o testador a escolher diferentes elementos para o teste.
Divis ao do dom nio em subdom nios

T ecnicas de Teste

T ecnicas de Teste

T ecnicas de Teste

T ecnicas de Teste
Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos Casos de Teste Tipos de Teste Fases de Teste
Teste de Unidade Teste de Integra ca o Teste de Sistema Teste de Aceita ca o Modelo V
Fases de Teste (1)
A Atividade de Teste tamb em e dividida em fases, conforme outras atividades de Engenharia de Software. Objetivo e reduzir a complexidade dos testes. Conceito de dividir e conquistar . Come car testar a menor unidade execut avel at e atingir o programa como um todo.
Processo de Teste de Software Auri M. R. Vincenzi
Fases de Teste (2)

Fases de Teste Teste Procedimental
Organiza c ao Teste Problemas e Desaos

Procedimento ou Subrotina

Dois ou mais procedimentos Subsistema

Todo Sistema
1111 11111 0000 00000 0000 1111 00000 11111 0000 1111 00000 11111 000 111 0000 1111 00000 11111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 000 111 000000 111111 0000 1111 000 111 0000 1111 000 111 000 111 000000 111111 0000 1111 000 111 0000 1111 000 111 000 111 000000 111111 0000 1111 000 111 0000 1111 000 111 000000 111111 000 111 0000 1111 000 111 0000 1111 000 111 000 111 0000 1111 0000 1111 000 111 000 111 000 111 000 111 0000 1111 0000 1111 000 111 000 000 111 000 111 0000 111 1111
Teste de Unidade 111 000 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 000 111 0000 1111 Teste de Integrao
Teste Orientado a Objeto
Mtodo
Classe Cluster Componentes Subsistema
1111 0000 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111 1111 0000 0000 1111 0000 1111 0000 1111 0000 1111
Teste de Sistema e Aceitao
111 000 000000 111111 000 111 000000 111111 000 111 000000 111111 0001111 111 000000 111111 0000 000 111 111 000 0000 1111 000 111 000 111 000 111 0000 1111 000 000 111 000 111 111
111 000 000 111 000 111 000 111 000 111 000 111
Todo Sistema
Principais Fases de Teste (adaptada de Binder (1999)).
Teste de Unidade
Objetivo e identicar erros de l ogica e de programa c ao na menor unidade de programa c ao. Diferentes linguagens possuem unidades diferentes.

Pascal e C possuem procedimentos ou fun co es. Java e C++ possuem m etodos (ou classes?). Basic e COBOL (o que seriam unidades?).
Resumo Leitura Recomendada Refer encias
Como testar uma unidade que depende de outra para ser executada? Como testar uma unidade que precisa receber dados de outra unidade para ser executada?
Refer encias
Processo de Teste de Software Auri M. R. Vincenzi
Driver e Stub
Organiza c ao Teste Problemas e Desaos Casos de Teste Tipos de Teste Fases de Teste
Para auxiliar no teste de unidade, em geral, s ao necess arios drivers e stubs. O driver e respons avel por fornecer para uma dada unidade os dados necess arios para ela ser executada e, posteriormente, apresentar os resultados ao testador. O stub serve para simular o comportamento de uma unidade que ainda n ao foi desenvolvida, mas da qual a unidade em teste depende.
entrada driver sa da
Unidade em Teste (F )
stub1
stub2
stubn
Drivers e Stubs.
Teste de Integra c ao (1)
Objetivo e vericar se as unidades testadas individualmente se comunicam como desejado.

1. Por que testar a integra c ao entre unidades se as mesmas, em isolado, funcionam corretamente?
Dados podem se perder na interface das unidades. Vari aveis globais podem sofrer altera c oes indesejadas.
Tipos de Teste Fases de Teste

Teste de Unidade X Teste de Integra c ao.
Tipos de Erros de Integra c ao.
Teste de Sistema
Objetivo e vericar se o programa em si interage corretamente com o sistema para o qual foi projetado. Isso inclui, por exemplo, o SO, banco de dados, hardware, manual do usu ario, treinamento, etc. Corresponde a um teste de integra c ao de mais alto n vel. Inclui teste de funcionalidade, usabilidade, seguran ca, conabilidade, disponibilidade, performance, backup/restaura c ao, portabilidade, entre outros (Norma ISO-IEC-9126 para mais informa c oes (ISO/IEC, 1991))
Teste de Aceita c ao
Objetivo e vericar se o programa desenvolvido atende as exig encias do usu ario.
Processo de Desenvolvimento versus Teste
Modelo V (V-Model)
Especica c ao de Requisitos Plano de Teste de Aceita c ao Especica c ao do Sistema Plano de Teste de Sistema Projeto do Sistema Plano de Teste de Integra c ao Projeto Detalhado Teste de Integra c ao Teste de Sistema Teste de Aceita c ao Sistema Operacional
Teste de Unidade
Resumo
A atividade de teste e um processo executado em paralelo com as demais atividades do ciclo de vida de desenvolvimento do software. A principal tarefa da atividade de teste e o projeto de casos de teste. Eles e que s ao respons aveis por revelar erros no programa.
O projeto de casos de teste deve levar em considera c ao o objetivo do teste que e demonstrar que o programa em teste possui erros. Segredo e selecionar aqueles casos de teste com maior probabilidade de revelar os erros existentes.
Diferentes t ecnicas de teste existem para auxiliar na atividade de teste. Al em disso, o teste deve ser conduzido em fases para reduzir a complexidade.
Leitura Recomendada
Mais informa c oes sobre esse tema podem ser encontrados em:
Cap tulo 1 do livro de Copeland (2004).
Refer encias Bibliogr acas
Beizer, B. Software testing techniques. 2nd ed. New York: Van Nostrand Reinhold Company, 1990. Binder, R. V. Testing object-oriented systems: Models, patterns, and tools, v. 1. Addison Wesley Longman, Inc., 1999. Copeland, L. A practitioners guide to software test design. Artech House Publishers, 2004. Craig, R. D.; Jaskiel, S. P. Systematic software testing. Artech House Publishers, 2002. IEEE IEEE standard glossary of software engineering terminology. Standard 610.12-1990, IEEE Computer Society Press, 1990. IEEE IEEE standard glossary of software engineering terminology. Standard 610.12-1990 (R2002), IEEE Computer Society Press, 2002. ISO/IEC Quality characteristics and guidelines for their use. Padr ao ISO/IEC 9126, ISO/IEC, 1991. Pressman, R. S. Engenharia de software. 6 ed. McGraw-Hill, 2006.

01-Processo de Teste

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01-Processo de Teste

Uploaded by

Copyright:

Available Formats

Processo de Teste de Software Auri M. R.

Processo de Teste de Software

O que e teste? (1)

O programa deve fazer a leitura de um arquivo texto codicado da seguinte forma:

O que e teste? (2)

N vel 0 - N ao h a diferen ca entre teste e depura c ao (debugging );

O que e teste? (2)

O que e teste? (2)

O que e teste? (2)

O que e teste? (2)

Rela c ao da terminologia padr ao.

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Algu em j a testou algum produto de software?

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Algu em j a testou algum produto de software? Quais foram os maiores desaos?

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

N ao h a tempo para o teste exaustivo.

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Casos de Teste Tipos de Teste Fases de Teste

Resumo Leitura Recomendada Refer encias Refer encias

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Casos de Teste Tipos de Teste Fases de Teste

Resumo Leitura Recomendada Refer encias Refer encias

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Casos de Teste Tipos de Teste Fases de Teste

Resumo Leitura Recomendada Refer encias Refer encias

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Casos de Teste Tipos de Teste Fases de Teste

Resumo Leitura Recomendada Refer encias Refer encias

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Casos de Teste Tipos de Teste Fases de Teste

Resumo Leitura Recomendada Refer encias Refer encias

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Casos de Teste Tipos de Teste Fases de Teste

Resumo Leitura Recomendada Refer encias Refer encias

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Problemas Indecid veis (1)

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Problemas Indecid veis (1)

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Problemas Indecid veis (2)

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Problemas Indecid veis (3)

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Impossibilidade do Teste Exaustivo (1)

Por que, simplesmente, n ao se testa todo o produto de forma exaustiva?

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Impossibilidade do Teste Exaustivo (1)

Por que, simplesmente, n ao se testa todo o produto de forma exaustiva?

Dom nio de Entrada

Pro duto Produto

Processo de Teste de Software Auri M. R. Vincenzi Organiza c ao Teste Problemas e Desaos

Impossibilidade do Teste Exaustivo (2)

Observe o exemplo abaixo, adaptado de Binder (1999):

in t blech ( int j ) { j = j 1; // s h o u l d be j = j + 1 j = j / 30000; return j ; }

Projeto de Casos de Teste

Partes de um Caso de Teste

Um caso de teste bem projetado e dividido em tr es partes:

Entradas (inputs ); Sa das Esperadas (outputs ); Ordem de execu c ao (order of execution).

Partes de um Caso de Teste entradas

Partes de um Caso de Teste sa das esperadas