Introdução aos Testes de Software - INPE/LACvijay/download/ELAC2007/Vijay_Testes_De_Software... · Carga útil não se separa Prejuízo de US$300 milhões ... Concentração na

Introdução aos Testes de Software

N. L. VijaykumarLAC/INPE

[email protected]

Acidente: Therac 25*

Equipamento para tratamento de câncer utilizando RADIOTERAPIA e RAIO-X6 casos de overdose (1985 a 1987)

2 mortes imediatas2 mortes por câncer desenvolvido devido à overdose2 casos com ferimentos permanentes

*Slide das aulas do Edgar Yano do ITA no curso de Dependabilidade


Software assumiu um padrão de temporização da entrada de dados mesmo tendo sido agilizada esta entrada baseada na experiência dos operadoresSoftware foi considerado livre de defeitosSoftware não passou por uma análise de segurançaQualidade de software não era gerenciada



Alguns módulos de software eram reusados mas sem passar por uma análise de segurançaComplexidade desnecessária do softwareEquipe de desenvolvimento não conhecia técnicas de concorrência de processos -> Equipe sem qualificação



Análise de segurança aplicada em outros componentes também deve ser aplicada no projeto e na implementação do softwareTestar usos não previstosQualificar a equipe de desenvolvimentoAnálise permanente de incidentes


Acidente com Airbus*

Aterrisagem numa pista molhada e com fortes ventosReversão da turbina somente após o toque do trem esquerdo


Acidente com Ariane 5*

Mesmo em condições favoráveis, o foguete desvia da trajetória e explodePrejuízo de US$400 milhõesÂngulo de ataque maior de 20o

Comando recebido pelo Computador de Bordo e foi calculado pelo computador de referência que estava em paneErro de conversão de ponto flutuante de 64 bits para inteiro de 16 bits


Acidente com Ariane 5*


Testes simulando com dados reaisTratamento de exceçõesProteger contra exceções no código

Acidente com Titan IV*

Missões comerciais com possibilidade de lançar 2 missões independentesProjeto com 2 conjuntos de interfaces de comunicação: frontal e traseiraResponsável por uma missão usou porta traseiraOutro responsável por uma outra missão projetou utilizando porta frontal


Acidente com Titan IV*

A troca não foi comunicada a equipe do softwareTestes realizados com software genérico para comandos com as duas portasCarga útil não se separaPrejuízo de US$300 milhões


Acidente com Titan IVB*

Satélite que foi levado ficou na órbita elípticaPrejuízo de US$1.3 Bilhões-0.199765 ao invés de -1.99765Faltou verificar dados críticos


Acidente de Boeing 757 em Colombia*

Choque contra montanha perto de aeroporto de CaliAs séries 757 e 767 tem muita automatização e requer pouco esforço do pilotoA aterrisagem estava prevista numa pista mas o controle indica uma outra


Acidente de Boeing 757 em Colombia*

Para realizar esta mudança, a tripulação deve executar várias operaçõesPor falta de conhecimento do aeroporto por parte dos pilotos, houve uma entrada errônea dos dados“ Speedbrake” acionado para descida não pôde ser desligado ao tentar desviar da montanha


Verificação e Validação(IEEE Definition)

VERIFICAÇÃOConfirmar por testes e com provas objetivas que requisitos especificados foram cumpridos.Garante que os produtos de uma dada fase implementam em sua totalidade as entradas para aquela fase ou seja o produto foi o produto foi construído corretamente (the product construído corretamente (the product was built right)was built right)

Verificação e Validação (cont.)

VALIDAÇÃOConfirmar por testes e com provas objetivas que requisitos particulares para um determinado uso foram cumpridosProva que o software implementa cada um dos requisitos corretamente e completamente ou seja, o produto correto o produto correto foi construído (the right product was foi construído (the right product was built)built)

Produtividade e Qualidade em Software

Peça produzida em massa numa fábricaCusto do projeto (qualquer que seja) é pequeno quando amortizado sobre produção em grande escalaControle de qualidade e testes desde componentes até produto final antes de despachar

Produtividade e Qualidade em Software (cont.)

Falhas? descarta ou retrabalho

Produtividade numa linha de montagem:Custo dos materiaisRetrabalhoComponentes descartadosCusto de garantia de qualidadeTestes


MENOR esforço em garantia de qualidade implica em ALTA taxa de rejeição e conseqüentemente MAIOR o custo líquidoBOA inspeção implica em descobrir falhas e domínio de custos de inspeção e conseqüentemente MAIOR o custo líquidoCompromisso entre Custos de Garantia de Qualidade x Custos de Fabricação


Estabelecem-se níveis de Testes e Garantia de Qualidade que MINIMIZEM o custo líquido mantendo um certo padrão de qualidadeCustos de Testes e Garantia de Qualidade variam desde 2% (produtos de consumo) a 80% (foguetes, reatores nucleares, aviões...)


Relação entre PRODUTIVIDADE e QUALIDADE para Software é bem diferenteCusto de “ Manufatura” de Software: fita ou disco, tempo do uso do computadorGarantia de Qualidade da “ Manufatura” do Software: check sums ou outros métodos de detecção


Custos do Software são dominados por seu DESENVOLVIMENTOManutenção do Software é diferente da manutenção do HardwareNão é propriamente uma manutençãoExtensão do desenvolvimento: melhorias são projetadas, implementadas e são corrigidas as deficiências


A fatia maior do custo do Software está nos custos dos ERROS (bugs)

Custo de DETECTÁ-LOSCusto de CORRIGÍ-LOSCusto de PROJETAR TESTESTESTES para ACHÁ-LOSCusto de EXECUTAR estes TESTESTESTES


Diferença principal entre produtividade de uma peça e produtividade de um Software

Para Hardware, qualidade é APENAS uma das várias determinantes de produtividadeNo caso de Software QUALIDADE e PRODUTIVIDADE são INDISTINTAS


Concentração na prevenção de errosAchar sintomas causados pelos errosDiagnóstico claro para facilitar a correção dos errosPrevenir erro é melhor que detectar o erro e corrigí-lo

Não há código para corrigirNão há código para corrigir


“ Teste e depois codifique” (D. Gelperin & W. Hetzel)O ideal é suceder na prevenção para que a atividade de testes não seja necessáriaIMPOSSÍVEL. Então, concentrar em descobrir os errosERRO é um desvio do comportamento esperado


Saber que o programa está errado não implica em conhecer o erroDiferentes erros podem se manifestar de uma maneira semelhanteUm erro pode ter vários sintomasSintomas e causas podem ser conhecidos somente com testes detalhados

Teste e Depuração

Objetivo de Teste é mostrar que um programa tem errosObjetivo de Depuração é descobrir o tal erro e projetar e implementar as mudanças no programa para corrigir aquele erroTeste: prova uma falha do programadorDepuração: “ vingança” d o programador

Função x Estrutura

Teste FuncionalPrograma é visto como CAIXA PRETAEntradas são submetidas e as Saídas são verificadas se estão de acordo com a especificação – CONFORMANCE TESTINGPreocupação é com a funcionalidade e não com os detalhes da programaçãoPonto de vista de um USUÁRIO

Função x Estrutura (cont.)

Teste EstruturalDetalhes da implementação (estilo, controle, linguagem, banco de dados, código). Programa é visto como CAIXA BRANCA

Bons sistemas são construídos em camadasUsuário vê apenas a última camada

Função x Estrutura (cont.)

Camadas mais internas são menos relacionadas com as funcionalidades do sistema e mais com a estruturaESTRUTURA para uma camada significa que é FUNÇÃO para outraExemplo: num sistema online, o usuário não tem menor idéia que no sistema há uma rotina de alocação de memória

Teste de Unidade

UnidadeO menor pedaço testável de um software, e que pode ser compilado e ligadoEm geral é um trabalho de um programador

Teste de UnidadeMostrar que a unidade NÃO SATISFAZ a sua especificação funcional e/ou que a sua estrutura implementada não corresponde à estrutura do projeto

Teste de Componente

ComponenteIntegração de uma ou mais unidadesPode ser uma unidade ou um sistema

Teste de ComponenteMostrar que o componente NÃO SATISFAZ a sua especificação funcional e/ou que a sua estrutura implementada não corresponde à estrutura do projeto

Teste de Integração

IntegraçãoProcesso onde os componentes são agregados em componentes maiores

Teste de IntegraçãoTeste de Componente pode ter sido satisfatório. Mesmo assim, a combinação destes componentes não está correta

Teste de Integração (cont.)

ExemplosChamadas ou retornos incorretosCritérios de validação de dadosManipulação errônea de objetos

Teste de Integração (cont.)

Exemplos (cont.)Considere rotina A que chama a si próprio

Teste inicial de componente NÃO INCLUI a chamada a sub-componentes a chamada recursiva a A não é testadaTeste de Integração é testar a chamada a A e o retornoTem-se agora um “ novo componente” integrado pois trabalha com o mecanismo de pilha; então teria que passar por um teste adicional

Teste completo é possível?

Qual é o objetivo de teste?Se fosse para PROVAR PROVAR que um programa não tem erros

Em Teoria, isto é impossívelNa Prática, isto também é impossível

Teste completo é possível? (cont.)

Abordagens demonstrando que o programa está correto

Teste FuncionalTeste EstruturalProvas de Correção (Correctness Proofs)

Teste Funcional

Qualquer programa trabalha com um número FINITO de entradasIndependente do significado destas entradas, será que não dá para considerá-las como um stream de bits?Então, um teste completo seria colocar o programa rodando para todas as possíveis combinações destas streams

Teste Funcional (cont.)

Para cada entradaAceita e produz uma saída corretaAceita e produz uma saída erradaNão aceita e informa deste fato

Considere um string de entrada de 10 caracteres 228080 combinações possíveis de entradas e suas saídas correspondentes


É impraticávelSupondo que cada teste demore 1 micro-segundoDUAS VEZES A IDADE ESTIMADA DO UNIVERSO


Quem garante que o hardware e o software usados para:

Gerar as entradasComparar a saída resultante com a saída esperadaDocumentar estes fatos

São livres de erros?????????????????????


O problema é que Testes Funcionais são condicionados na SUPOSIÇÃO que as ferramentas de testes e ferramentas que preparam os testes são corretasSomente a rotina em teste está ERRADANo mundo real, isto seria um ABSURDO

Teste Estrutural

Testes tem que ser projetados de tal forma que eles seriam suficientes para garantir que TODO O CAMINHO dentro da rotina seja executadaO que fazer quando se encontra loops infinitos?E se dentro de cada destes loops houverem vários caminhos?

Teste Estrutural (cont.)

Mesmo uma rotina pequena poderá ter milhões (ou bilhões) de caminhosIsto faz com que teste completo seja impraticávelAqui também devem haver garantias que entradas preparadas são livres de erros, etc.

Prova de Correção

Provas formais dependem de uma combinaçao de conceitos funcionais e estruturaisA especificação tem que ser descrita formalmente (linguagem matemática)Prova indutiva é usada nos comandos para verificar se há saída correta para a combinação de todas as entradas

Prova de Correção (cont.)

Na prática, isto é muito caroTem sido usado muito em rotinas numéricas ou em software crucial como kernel de segurança ou pedaços de um compiladorHá outros problemas também

Prova de Correção (cont.)

Quem garante que a especificação é possível de se obter?Quem garante que dá para provar a consistência e completude desta especificação?É provado que isto é um problema não solúvel

Barreiras para Teste Completo

Manna, Z. & Waldinger, R. The logic of computer programming. IEEE Transactions on Software Engineering 4:199-229, 1978

Não se pode ter certeza que as especifcações estão corretasNenhum sistema de verificação pode verificar se todos os programas estão corretosNão se pode ter certeza que um sistema de verificação está correto.

Qual a solução?

Mudar a abordagem de PROVA ABSOLUTA para DEMONSTRAÇÃO CONVINCENTERealizar testes suficientessuficientes para garantir que a probabilidade de falha devido aos erros que hibernam é baixa o suficiente para aceitarO que é suficiente?

Qual a solução? (cont.)

SuficienteSuficiente depende da aplicaçãoO que é suficientesuficiente para um jogo não é suficientesuficiente para um reator nuclearTécnicas de testes e modelos de confiabilidade estão em constante evolução e será possível, baseado em resultados de testes, fazer uma medida quantitativa da confiabilidade do sistema

Teste de Conformidade

Foco maior será dado a testes funcionais ou seja teste tipo CAIXA PRETA (Black box testing)Este caso é considerado como Teste de Conformidade (Conformance Testing), i.e., a implementação está ou não está de acordo com a especificação

Teste de Conformidade (cont.)

Exemplos:Protocolos de comunicaçãoSistemas concorrentesFalhas e recuperação de sistemasConfiguração de sistemasBanco de dados distribuídos


Não se pode testar algo sem primeiro entendê-loOu seja, teria que entender o que a Implementação Sob Teste (IUT) deve fazerTeste pode ser considerado um problema de busca: combinações de entradas e estados


Se houver uma especificação e se for possível modelá-la por alguma técnica, pode-se então gerar os casos de testeExecutaria a implementação sob teste (IUT) baseado nos casos obtidos acimaPoderia confrontar com a especificação para dar um veredito se a IUT está ou não de acordo com a especificação


Força bruta – está fora de questão!!!Testes “ aleatórios” não leva ao objetivoEntão, esta busca deve ser

SistemáticaFocadaAutomatizada


SistemáticaPara garantir que toda a combinação seja testada

FocadaAproveitar as vantagens de se ter informações disponíveis sobre onde existiriam possíveis erros


AutomatizadaPara produzir e executar o maior número de testes consistentes e repetitivos

Para atingir estes três objetivos, o ideal é utilizar MODELOS

Testes baseados em Modelos (Model-Model-Based TestingBased Testing)

ModelagemModelagem é utilizada para representarum sistema real onde se pode captar relações essenciaisA vantagem é que modelos são mais fáceis de serem desenvolvidos e analisados do que sistemas físicose.g., modelos são usados para explorar vários tópicos através de simulação

Modelagem (cont.)

No caso de testes, modelagem deve facilitar a representação da especificação para gerar os casos de testesQual técnica a ser utilizada para modelar a especificação?

Grafo (Máquina de Estados)

a/1

S1

S2 S3

a/0

b/1 b/0

b/1

a/0

Modelagem (cont.)

Estado inicial S1Seqüência abbS1, S2 e S3Saída:

011

[Lee & Yannakakis, 1996]

Métodos para Geração de Seqüências de Testes

Método T (Transition Tour)Método U (UIO – Unique Input/Output)Método DMétodo W

Exemplo Método TB/0

[Sidhu & Leung, 1989]

B A B A B A A A A A A A B B0 0 3 3 4 0 3 4 2 1 4 2 1 2

A/0

B/0B/1

A/1

B/1

A/1

A/0

B/1

3

1

2

4

0

A/0

Switch Cover Method

Switch Cover Method (cont.)Step 1

Dual Graphcreation

Step 2

Arc creation,considering allnodes in the original graph

Step 3

Transformationinto a “ Eulerized”Graph by balancingthe polarity of thenodes

Step 4

Nodes aretraversed

Result:abf, abrbf,cf, crbf

Exemplo: Command Recog Component from OBDH

PerformCharts em TestesGeração de casos de testes

Vários métodos desde que o software esteja especificado em Diagramas de Estado

Usar PerformCharts para especificar um software complexo em Statecharts para gerar automaticamente o diagrama de estadosAssociar um método (geração de casos de teste – transition tour, switch cover, W) à especificação

PerformCharts em Testes (cont.)


Mapping the Methodology Step a: PcML Specification <States> <Root Name="ReceivingCommand" Type="AND"> <State Name="A" Type="XOR" Default="Idle"> <State Name="Idle" Type="BASIC"/> <State Name="CountingTime" Type="BASIC"/> </State> <State Name="B" Type="XOR" Default="WaitingSync"> <State Name="WaitingSync" Type="BASIC"/> <State Name="CheckingField" Type="XOR" Default=“ WaitingExpId” > <State Name="WaitingExpId" Type="BASIC"/> <State Name="WaitingType" Type="BASIC"/> <State Name="WaitingSize" Type="BASIC"/> <State Name="Aborting" Type="BASIC"/> <State Name="WaitingChecksum" Type="BASIC"/> <State Name="WaitingData" Type="BASIC"/> </State> </State> </Root> </States>


M a p p i n g t h e M e t h o d o l o g y – S t e p b : C + + P r o g r a m ( o u t p u t ) S t a t e c h a r t R e c e i v i n g C o m m a n d ;

/ / S t a t e s R e c e i v i n g C o m m a n d . c r e a t e R o o t ( " R e c e i v i n g C o m m a n d " , A N D ) ; / / S t a t e A R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " A " , O R , " R e c e i v i n g C o m m a n d " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " I d l e " , B A S I C , " A " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " C o u n t i n g T i m e " , B A S I C , " A " ) ;

/ / S t a t e B R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " B " , O R , " R e c e i v i n g C o m m a n d " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " W a i t i n g S y n c " , B A S I C , " B " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " C h e c k i n g F i e l d " , O R , " B " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " W a i t i n g E x p I d " , B A S I C , " C h e c k i n g F i e l d " ) ; R e c e i v i n g C o m m a n d . c r e a t e S o n S t a t e ( " W a i t i n g T y p e " , B A S I C , " C h e c k i n g F i e l d " ) ;

… R e c e i v i n g C o m m a n d . s e t D e f a u l t E n t r y ( " A " , " I d l e " ) ; R e c e i v i n g C o m m a n d . s e t D e f a u l t E n t r y ( " B " , " W a i t i n g S y n c " ) ; R e c e i v i n g C o m m a n d . s e t D e f a u l t E n t r y ( " C h e c k i n g F i e l d " , " W a i t i n g E x p i d " ) ; / / E v e n t s R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( " E B 9 " , 1 . 0 ) ;

R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( “ e i d r c " , 1 . 0 ) ; … R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( “ c o m m a n d r e c e i v e d " ) ; R e c e i v i n g C o m m a n d . c r e a t e P r i m E v e n t ( “ s t a r t i n g t i m i n g c o u n t i n g " ) ; …


M a p p i n g t h e M e t h o d o l o g y – S t e p c : F l a t F S M ( o u t p u t ) N O D E L A B E L = R e c e i v i n g C o m m a n d . . . . . L e v e l = 0 . . . . . T y p e = A N D . . . . . * * * R O O T N O D E * * * . . . . . S o n s = A - > B * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * * N O D E L A B E L = A . . . . . L e v e l = 1 . . . . . T y p e = O R . . . . . F a t h e r = R e c e i v i n g C o m m a n d . . . . . D e f a u l t = I d l e . . . . . S o n s = I d l e - > C o u n t i n g T i m e * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * * N O D E L A B E L = I d l e . . . . . L e v e l = 2 . . . . . T y p e = B A S I C . . . . . F a t h e r = A . . . . . S o n s = * * * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * * *



M a p p i n g t h e M e t h o d o l o g y – S t e p d : B a s e o f f a c t s ( o u t p u t )

i n i t i a l ( i d l e _ w a i t i n g s y n c ) .

t r a n s ( i d l e _ w a i t i n g s y n c , t r a n s i t i o n 0 , c o u n t i n g t i m e _ w a i t i n g e x p i d , L 0 , L n ) : - r e c e i v e l ( ' E B 9 ' , L 0 , L 1 ) , t r a n s m i t ( L 1 , L n ) . … t r a n s ( c o u n t i n g t i m e _ w a i t i n g e x p i d , t r a n s i t i o n 2 , e n d , L 0 , L n ) : - r e c e i v e l ( ' w a i t i n g t i m e e x p i r e d ' , L 0 , L 1 ) , t r a n s m i t ( L 1 , L n ) . … t r a n s ( c o u n t i n g t i m e _ w a i t i n g e x p i d , t r a n s i t i o n 3 , c o u n t i n g t i m e _ w a i t i n g t y p e , L 0 , L n ) : - r e c e i v e l ( ‘ e i d r c ' , L 0 , L 1 ) , t r a n s m i t ( L 1 , L n ) .


M a p p i n g t h e M e t h o d o l o g y – S t e p e : T e s t C a s e s ( o u t p u t ) s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( )

s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( )

s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , t y p e r c ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( )

s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , t y p e r c ) r e c d a t a ( ) s e n d d a t a ( L , s i z e r c ) r e c d a t a ( ) s e n d d a t a ( L , w a i t i n g t i m e e x p i r e d ) r e c d a t a ( ) … s e n d d a t a ( L , E B 9 ) r e c d a t a ( ) s e n d d a t a ( L , e i d r c ) r e c d a t a ( ) s e n d d a t a ( L , t y p e r c ) r e c d a t a ( ) s e n d d a t a ( L , s i z e r c ) r e c d a t a ( ) s e n d d a t a ( L , d a t a r c ) r e c d a t a ( ) s e n d d a t a ( L , c k s u m r c ) r e c d a t a ( )

P e r f o r mC h a r t sX

ML

S t a t e C h a r t s( H a r e l )

E n t r a d a d aP e r f o r m C h a r t s M E F R e s u l t a d o

I n s t â n c i a P c M L

A p l i c a ç ã o P e r l

A p l i c a ç ã o J a v a

S o u r c ec o d e

S c h e m aP c M L

M o d e l o d os i s t e m a e m

P c M L

p r o g r a m ae m C + +

A v a l i a ç ã od e

D e s e m p e n h o

C a s o sd e

T e s t e

C o n d a d o

M o d e s t o

P e r f o r mC h a r t sX

ML

XML

S t a t e C h a r t s( H a r e l )

E n t r a d a d aP e r f o r m C h a r t s M E F R e s u l t a d o

I n s t â n c i a P c M L

A p l i c a ç ã o P e r l

A p l i c a ç ã o J a v a

S o u r c ec o d e

S c h e m aP c M L

M o d e l o d os i s t e m a e m

P c M L

p r o g r a m ae m C + +

A v a l i a ç ã od e

D e s e m p e n h o

C a s o sd e

T e s t e

C o n d a d o

M o d e s t o


P c M L S p e c i f i c a t i o n

P e r l S c r i p t C + + P r o g r a m

P e r f o r m C h a r t s

X S L T P a r s e r

F S M ( X M L f o r m a t )

B a s e o f F a c t sC o n d a d oT e s t C a s e s

BibliografiaLee, D.; Yannakakis, M. Testing FiniteState Machines: State Identification and Verification, IEEE Transactions on Computers, 43(3), 1994

Lee, D.; Yannakakis, M. Principles and Methods of Testing Finite State Machines – A Survey. In: Proceedings of the IEEE, 84(8), 1996, pp. 10901123

Martins, E.; Sabião, S.B.; Ambrósio, A.M. ConData: a tool for automating Specificationbased Test Case Generation for Communicating Systems. Software Quality Journal, 8(4), 303319, 1999

Sidhu, D.P.; Leung, T. Formal Methods for Protocol Testing: A Detailed Study, IEEE Transactions on Software Engineering, 15(4), 1989, pp. 413426

Bibliografia (cont.)Beizer, B. Software Testing Techniques. International Thomson Computer Press, 1990.

Binder, R. V. Testing Object-Oriented Systems: Models, Patterns and Tools. Addison Wesley. 1999

Documents

Introdução aos Testes de Software - INPE/LACvijay/download/ELAC2007/Vijay_Testes_De_Software... · Carga útil não se separa Prejuízo de US$300 milhões ... Concentração na