Fases de Teste - Início | Faculdade de Computaçãobacala/ES/18-fases-teste.pdf · Ordem de...

Fases de Teste

Testes no Processo de Desenvolvimento

Testes de Unidades e de Integração

Testes de

unidade

Código do

componente

Espec. do

componente

Testes de

unidade

Código do

componente

Espec. do

componente

Testes de

integração

Especificação da

arquitetura

componente

testado

componente

testado

subsistemas

integrados . . .

Testes de Unidades

• Visam exercitar detalhadamente uma unidade do sistema.

• Uma unidade é uma entidade executável independente.

• Pode representar:

• Uma função.

• Uma classe ou um tipo abstrato de dados.

• Um grupo pequeno de classes.

• Um componente.

• Um framework.

• Um serviço

Modelos de falhas

• Os Testes de Unidade visam revelar a presença de falhas em:

• interfaces: parâmetros de entrada e saída

• estruturas de dados: integridade dos dados armazenados

• condições de limite: a unidade opera adequadamente nos limites estabelecidos?

• tratamento de erros: a descrição do erro é inteligível? A descrição corresponde ao erro encontrado? O tratamento de exceção é adequado?

Componentes de teste • Driver

• Programa ou classe que aplica os casos de teste ao componente em teste Faz o papel de cliente do componente em teste (CeT).

• Stub

• Implementação temporária, mínima, de um componente usado pelo CeT, com o objetivo de melhorar a controlabilidade e observabilidade do CeT durante os testes. Faz o papel de servidor do CeT.

• Ambiente de teste (Test Harness)

• Sistema que compreende os drivers, stubs, CeT e outras ferramentas de apoio aos testes.

A unidade e suas colaborações

Cliente

Unidade

em

Teste

Servidor 1 Servidor 2 Servidor 3

A unidade e os componentes de teste

Casos

de teste

Driver

Unidade

em

Teste

Stub 1 Stub 2

resultados

Stub 3

Exemplo – componente em teste

Tabela

CriarTabela( )

LerItem( )

InserirItem( )

RemoverItem( )

MostrarTabela( )

Driver

• Operação que exercita o módulo sob teste

• Envia valores, coleta e compara resultados

• Exemplo:

• JUnit test cases

Exemplo - Driver

type TabInt = array [ 1 .. N, 1 ..

M ] of integer;

...

var Tabela: TabInt,

x: integer;

...

criaTab ;

leItem ( x );

insereItem (x );

mostraTab ;

....

Tabela

CriarTabela( )

LerItem( )

InserirItem( )

RemoverItem( )

MostrarTabela( )

Driver

Exemplo: JUnit

public class TestDriver extends TestCase {

…

public static void testDeposito(){

BankAccount sut = new BankAccount(100);

sut.remove(60);

Assert.assertEquals(sut.saldo(), 40);

}

}

Exemplo Driver OO

CasoTeste001

CasoTeste002

CasoTeste003

...

CeT

• Contém instâncias dos casos de teste;

• Contém instância da classe em teste

(CeT);

• Pode herdar de uma classe abstrata

CasoTeste

Driver

Stub

•Cenário:

•A e B são unidades

•A depende de B

•B não pode ser usado

•Stub: Substituto de B para testar A

Exemplo: stub

type VetorInt = array [1 .. N] of integer;

...

procedure Ordena_Vetor (a : VetorInt);

...

begin

write (“Valores fornecidos”);

for i := 1 to N do write (a [ i ] );

write (“Forneça os valores ordenados”);

for i := 1 to N do read (a [ i ] );

end;

Tabela

Stub

Por que usar stubs?

• O componente real (B) não está pronto

• Usar componente real não é prático para o teste. Exemplos:

• Requer conexão de rede

• É ineficiente

16

Custo de Stubs

• Pode ser trabalhoso implementar manualmente

• Stub e Stubbed devem respeitar mesma interface

• Pode deixar o código menos legível

17

Exemplo: Stub

18

public static int testPath(int x){

y = foo(x);

if (x > y) return x – y

else if (x < y) return x + y;

else x/y;

}

public static int foo(int x) {

// assuma que implementacão real

// nao está pronta ou é inviável

// de usar para o teste

}

19

Observe que o sistema não está

preparado para receber um stub!

Passo 1: preparação da interface

20

public static int testPath(int x, CmdFoo cf){

y = cf.foo(x);



else return x/y;

}

static interface CmdFoo {public int foo(int x);}

Passo 2: instanciação da interface

21


y = cf.foo(x);



else return x/y;

}


…

public static void test1() {

int x = 1;

CmdFoo foo1 = new CmdFoo() {

public int foo(int x) {

return x + 1;

}

};

testPath(x, foo1);

}


22


y = cf.foo(x);



else return x/y;

}


…


int x = 1;



return x - 1;

}

};

testPath(x, foo1);

}


23


y = cf.foo(x);



else return x/y;

}


…


int x = 0;



return 0;

}

};

testPath(x, foo1);

} BANG!!!

Fases da execução de um caso de teste

• Preparação (set up): • Cria o que for necessário, configurando os stubs de acordo

para que o caso de teste execute conforme o esperado.

• Execução: • Interage com o CeT, aplicando os testes gerados e

observando os resultados obtidos.

• Verificação: • Compara os resultados obtidos com os esperados.

• Término (clean up ou tear down): • Termina a execução do CeT e deixa o ambiente de execução

de testes no mesmo estado em que estava antes da realização do caso de teste.

Estrutura de testes (xUnit)

Prepara

(set up)

Executa

Verifica

Termina

(clean up)

CeT

Servi-

dores

Stubs

(ou mocks)

cria

configura

instala

caso de teste

Mock Objects

• Criados pela comunidade XP (em 2000) • Tim Mackinnon, Steve Freeman, Philip Craig.

“Endo-Testing: Unit Testing with Mock Objects” (www.cs.ualberta.ca/~hoover/cmput401/XP-Notes/xp-conf/Papers/4_4_MacKinnon.pdf), apresentada no evento XP2000.(disponível emt www.mockobjects.com).

• Objetivo: • Sistematizar a geração de stubs • Desenvolver uma infra-estrutura para criação de

mocks e incorporação dos mesmos aos Testes de Unidade.

Bibliotecas

• Mock Objects (ou mocks) servem para emular ou instrumentar o contexto (serviços requeridos) de objetos da CeT.

• Devem ser simples de implementar e não duplicar a implementação do código real.

• Bibliotecas de mocks podem ser usadas para criar stubs: existem várias APIs para esse fim: • MockObjects (www.mockobjects.com) • EasyMock (www.easymock.com) • MockMaker (www.mockmaker.org ) • djUnit (http://works.dgic.co.jp/djunit/) • ...

Mocks x stubs • Mocks : voltados para testes classes (OO) • Stubs: usados em linguagem OO ou não. • Segundo Fowler, mocks e stubs não são sinônimos:

• Mocks • podem servir para colocar o objeto da CeT no estado

desejado para os testes.

• Um stub • implementação alternativa da interface do objeto

substituído. • mais passivo, geralmente retornando dados pré-

estabelecidos pelos casos de teste para a CeT.

• Mocks podem verificar se o servidor foi chamado adequadamente contêm verificação embutida (assertivas)

Exemplo: classe em teste e uma servidora

classe ClasseEmTeste

Servidora serv;

metodo( )

// chama servidora

serv.executa( )

end

end

classe Servidora

executa( )

# código complexo

end http://www.floehopper.org/articles/2006/09/11/the-difference-between-mocks-and-stubs

Exemplo de stub: pseudo-código

classe ClasseDeTeste implementa Test::Unit::TestCase

classe ServidoraStub

executa( )

retorna X

end

end

// exemplo_uso_Stub

ServidoraStub servidora

classeTeste = ClasseEmTeste.new(servidora)

assert_equal X, classeTeste.metodo

end

end http://www.floehopper.org/articles/2006/09/11/the-difference-between-mocks-and-stubs

Exemplo de mock: pseudo-código

http://www.floehopper.org/articles/2006/09/11/the-difference-between-mocks-and-stubs

classe ClasseDeTeste implementa Test::Unit::TestCase

classe ServidoraMock

atributo: call_count

...

call_count = 0

// métodos

execute( )

call_count +=1 // conta nº de chamadas ao método

end

get_call_count ( )

...

end

// exemplo_uso_Mock

servidora = ServidoraMock.new

classeTeste = ClasseEmTeste.new(servidora)

// verifica nº de chamadas ao método servidor

assert_equal 1, servidora.get_call_count

end

end

Outro exemplo : o mock

// Usado no teste do método: canUserLogin( User, String ) , para substituir // o método validatePassword, chamado pelo método em teste. public class MockUser implements User { ... // Prepara o que retornar quando validatePassword for chamado public void setValidatePasswordResult( boolean result ) { expectedCalls++; this.returnResult = result; } // Implementação do mock de validatePassword public boolean validatePassword( String password ) { actualCalls++; return returnResult; } public boolean verify() { return expectedCalls == actualCalls; } ... }

Interface da classe

substituída

Determina nº esperado de chamadas ao

método substituído

Conta chamadas ao método substituído

Verifica se chamadas de acordo com o esperado

Uso do mock: o caso de teste

// Caso de teste usando o MockUser criado anteriormente

public void testCanUserLogin() {

MockUser user = new MockUser();

user.setValidatePasswordResult( true );

// usa objeto em teste já criado: ot

boolean result = ot.canUserLogin( user, "foobar" );

assertTrue("Expected to validate user " + "password \"foobar\"", result );

assertTrue("MockUser not used as expected", user.verify());

}

preparação

execução

verificação

Testes de unidade e de integração

Testes de

unidade

Código do

componente

Espec. do

componente

Testes de

unidade

Código do

componente

Espec. do

componente

Testes de

integração

Especificação da

arquitetura

componente

testado

componente

testado

subsistemas

integrados . . .

Testes de integração

• Integram unidades já testadas •Objetivo: exercitar interações entre unidades

Modelo de falhas de integração • Falhas de interpretação: a funcionalidade implementada por uma

unidade difere do que é esperado. • B implementa incorretamente um serviço requerido por A. • B não implementa um serviço requerido por A. • B implementa um serviço não requerido por A e que interfere com seu

funcionamento.

• Falhas devido a chamadas incorretas: • B é chamado por A quando não deveria (chamada extra). • B é chamado em momento da execução indevido (chamada incorreta). • B não é chamado por A quando deveria (chamada ausente).

• Falhas de interface: o padrão de interação (protocolo) entre duas unidades é violado. • violação da integridade de arquivos e estruturas de dados globais • tratamento de erros (exceções) incorreto • problema de configuração / versões • falta de recursos para atender a demanda das unidades • objeto incorreto é associado a mensagem (polimorfismo)

[Leung e White; Binder99]

Abordagens de integração

• Não incremental (“big-bang”): • todas as unidades são integradas de uma só vez

esforço de preparação menor

esforço para diagnóstico e correção de falhas é maior

• Incremental • As unidades são integradas gradualmente

• Existem inúmeras estratégias • Descendente (“top-down”)

• Ascendente (“bottom-up”)

• Por colaboração

• Mista

• Por camadas

• ...

Abordagem incremental

A

B

T1

T2

T3

A

B

T1

T2

T3

T4

C

A

B

T1

T2

T3

T4

T5 C

D

Integração descendente (“top-down”) • Começa com a unidade principal e

vai aos poucos integrando as unidades subordinadas

• Em OO: classes de controle primeiro • Utiliza stubs em lugar das unidades

subordinadas

Integração ascendente (“bottom-up”) • Começa a integração pelas unidades

subordinadas • Em OO: começar pelas classes independentes

ou que usam poucas servidoras • Utiliza drivers em lugar das unidades de

controle • As unidades de mais baixo nível são testadas

primeiro e mais vezes

Integração sanduíche

• Combina estratégia ascendente e descendente •O sistema pode ser visto como uma

arquitetura com 3 camadas: • Camada-alvo, no meio • Camada superior, acima da camada alvo • Camada inferior, abaixo da camada alvo

•Os testes convergem para a camada-alvo • Como escolher a camada-alvo? • Objetivo: reduzir nº de stubs e drivers

Ordem de integração

• Ao integrar vários componentes, é importante determinar a ordem para integrá-los

• Componentes podem depender de outros por várias razões: • Classes dependem de outras de diferentes formas:

Composição e agregação, herança, uso de métodos ou atributos definidos em outras classes

• Chamadas a interfaces (API)

• Dependência necessidade de stubs Análise de dependências: • Objetivo: determinar uma ordem de integração que

reduza o número de stubs

Exemplo: Diagrama de Classes

Cliente

Serviço

Financeiro Transação

Taxas

Dinheiro

Conta

Possui

Possui 1 ..*

0 ..*

Realizado através de 0 ..*

Aplicada a

2 ..*

Usa

Contém

Usa

1 ..1

[inspirado em Binder00, 13.1.3]

Exemplo de dependência: X usa Y

Cliente

ServiçoFinanceiro

Transação

Taxas

Dinheiro

Conta

[inspirado em Binder00, 13.1.3]

Array [Int]

usa

Classe de implementação

Não é usada por nenhuma outra classe

Não usa nenhuma outra classe

Por onde começar a

integração para reduzir o

número de stubs?

Por onde começar a

integração para reduzir o

número de drivers?

Determinação da ordem de testes (1)

•Existem várias propostas com base no grafo de dependências: • Caso não existam ciclos: • Integração ascendente: para reduzir nº de stubs,

começar pelos componentes que não dependem de outros

• Integração descendente: para reduzir o nº de drivers, começar pelo componente do qual nenhum outro depende

Exemplo – Integração Ascendente

Cliente

ServiçoFinanceiro

Transação

Taxas

Dinheiro

Conta

Array [Int]

Testa

Dinheiro

Testa

Taxas

Testa

Conta +

Dinheiro

Testa

Transação+Conta+

Dinheiro+Taxas

Testa

Cliente+ Conta+

Dinheiro

Testa

ServiçoFinanc. +

Transação +

Conta +

Dinheiro +

Taxas

Exemplo – Integração Sanduíche

Cliente

ServiçoFinanceiro

Transação

Taxas

Dinheiro

Conta

Array [Int]

Testa

Dinheiro

Testa

Taxas

Testa

Conta +

Dinheiro

Testa

Transação+Conta+

Dinheiro+Taxas

Testa

Cliente+ Conta+

Dinheiro

Testa

ServiçoFinanc. +

Transação +

Conta +

Dinheiro +

Taxas

Camada alvo

Testa

ServiçoFinac.

Determinação da ordem de testes (2)

• Existem várias propostas com base no grafo de dependências: • Caso existam ciclos componentes fortemente

acoplados • Uma opção: refatore sua arquitetura, para evitar os ciclos,

ou • “Quebre” os ciclos: • As propostas variam de acordo com a forma de quebrar os

ciclos • Ex.: em OO remover uma associação (herança e agregação

não são “quebráveis”) Quebra da dependência construção de stubs

Exemplo – quebra de ciclos

A

B C

D Testa

D

Testa

B+D

Testa

C+D

Testa

A+B+C+D

Stub

C

Integração ascendente:

Análise de dependências

•Existem ferramentas, como por exemplo: • Class Dependency Analyzer (CDA) • http://www.dependency-analyzer.org/

• Jdepend • http://clarkware.com/software/JDepend.htm

l

•Metrics • http://metrics.sourceforge.net/

• ...

http://www.dependency-analyzer.org/



http://clarkware.com/software/JDepend.html

http://clarkware.com/software/JDepend.html

http://metrics.sourceforge.net/

Testes de Sistemas

Testes de

Sistemas

(funcionais)

Especificação de

Requisitos Funcionais

funcionalidades

testadas

subsistemas

integrados

Manual do

Usuário

Testes de

Sistemas

(qualidade)

Especificação de

Requisitos de Qualid.

Testes de

Aceitação Requisitos

do usuário

sistema

testado

sistema

aceito

Fontes de informação para os testes

• Especificação de requisitos.

• Protótipo, layouts ou modelos da IU.

• Políticas da organização implementadas como objetos de negócio, “stored procedures” ou “triggers”.

• Características do produto descritas na literatura.

• Características e procedimentos descritos na documentação, telas de ajuda ou assistentes de operação (“wizards”).

• Manual do usuário.

• Padrões.

Especificação

deve ser:

• completa

• consistente

• precisa

testável

Testes dos requisitos funcionais

• Visam verificar se as funcionalidades especificadas foram devidamente implementadas

• Uso de métodos de testes caixa-preta : • partição de equivalência

• valores-limite

• tabela de decisão / grafo causa-efeito

• modelos de estado

• diagramas de casos de uso

• cenários

• ...

Testes dos requisitos de qualidade • Visam determinar se a implementação do sistema satisfaz aos

requisitos de qualidade (não funcionais)

• Tipos de testes: • configuração e compatibilidade

• desempenho

• estresse

• tolerância a falhas

• segurança

• ...

Testes de desempenho

• Visam determinar se implementação satisfaz aos requisitos de desempenho especificados: • configuração de rede

• tempo de CPU

• limitação de memória

• carga do sistema

• taxa de chegada de entradas

esses requisitos devem ser descritos de forma testável

ex.: nº de transações/seg ou tempo de resposta em seg, mseg

O sistema é testado em condições reais de operação.

Variações dos testes de desempenho

• Testes de carga • geralmente associados com sistemas transacionais

• usam simuladores de carga para geração de múltiplas transações/usuários simultaneamente

• Testes de volume • geralmente usados para sistemas “batch”

• consistem na transmissão de um grande volume de informações quando o sistema está com a carga normal ou

• uso de arquivos grandes (maior tamanho possível) ou de grande número de arquivos

Teste de estresse • Visa ir além dos limites do sistema: nº máximo de usuários

simultâneos, nº máximo de processos ou de transações, …:

• verificar se o sistema não apresenta um comportamento de risco quando submetido a carga elevada e com um ou mais recursos saturados.

• Importância: • muitos sistemas apresentam comportamento de risco nessa situação

• falhas detectadas são sutis

• correções desse tipo de falha podem requerer retrabalho considerável (e.g., rever arquitetura)

Robustez

• O que é [IEEE Std Glossary]: • O grau em que um sistema ou componente pode funcionar

corretamente em presença de entradas inválidas ou sob condições ambientais estressantes.

• Em suma, pode ser interpretado como a capacidade do sistema em: • Tratar exceções

• Tolerar falhas

• Como medir robustez? • proposta de Robustness Benchmark

• Como determinar se um sistema é robusto? • Realização de testes de robustez

Testes de robustez

•Objetivo: • Verificar se o comportamento do sistema é

adequado em presença de: • Entradas inválidas • Entradas inoportunas • Condições ambientais anormais

• Abordagens: • Formais • Baseadas em injeção de falhas

Injeção de falhas

•O que é • Técnica de validação de software que

consiste em observar o funcionamento de um sistema em presença de falhas ou erros.

•Objetivos: • Verificação – remoção de falhas de

software no sistema em teste. • Avaliação – obtenção de medidas de

atributos de qualidade: confiabilidade, disponibilidade, entre outras.

Esquema típico dos testes de robustez

Comportamento

especificado

Espaço de

entrada

Software em

Teste

Espaço de

saída

Entradas

válidas

Entradas

inválidas ou

inoportunas

Normal

Não especificado

Deve retornar

erro

Operação

robusta

Falhas de interface

Defeito

[base: Koopman99]

Falhas de interface: o modelo Ballista

Tipo do

dado

Valores

Inteiro 0, 1, -1, MaxInt, MinInt

Real 0., 1., -1., DblMin, DblMax

Boolean Inversão de estado (V F, F V)

String Null, string do tamanho da memória virtual, string

com caracteres especiais (fim de arquivo,

formatação, etc)

Descritor de

arquivo (tipo

inteiro)

0, 1, -1, MaxInt, MinInt

descritor de: arquivo aberto para leitura, arquivo

aberto para escrita, arquivo vazio, arquivo apagado

após o descritor ter sido atribuído Fonte: Projeto Ballista - http://www.ece.cmu.edu/~koopman/ballista/

Exemplo de falhas de interface – modelo Ballista

API: write(int filedesc, const void *buffer, size_t nbytes)

Tipos de descritor buffer de tamanho

dados de arquivos memória

Valores

de teste

FD_CLOSED

FD_OPEN_READ

FD_OPEN_WRITE

FD_DELETED

FD_EMPTYFILE

...

BUF_SMALL_1

BUF_LARGE_512M

BUF_HUGE_2G

BUF_NULL

BUF_16

...

SIZE_1

SIZE_ZERO

SIZE_NEG

SIZE_MININT

SIZE_MAXINT

...

Caso de

teste write(FD_CLOSED, BUF_NULL, SIZE-NEG) (inspirado em Koopman2008)

Exemplos de resultados da aplicação de Ballista com Sistemas Operacionais

Fonte: Philip Koopman, Kobey DeVale, and John DeVale. INTERFACE ROBUSTNESS TESTING: EXPERIENCES AND

LESSONS LEARNED FROM THE BALLISTA PROJECT. Relatório, 2008.

Sistema operacional Nº

funções

testadas

Nº de

funções

“system

killers”

Exemplo de

funções “system

killer”

% de defeitos

de robustez

(normalizada)

Linux 2.0.18 190 0 N/a 12,5

Red Hat Linux 2.2.5 183 0 N/a 21,9

Windows 98 SE SP 1 237 7 CreateThread,

DuplicateHandle,

strncpy, ...

17,8

Windos CE 2.11 179 28 13,7

Sun JVM 1.3.1-04

(Red Hat Linux

2.4.18-3)

226 0 N/a 4,7

Nº de funções chamadas que foram a

causa do defeito catastrófico

Funções chamadas que foram a

causa do defeito catastrófico

Testes de segurança

• Visam verificar a capacidade do sistema de impedir acesso não autorizado, sabotagem ou outros ataques intencionais

• Características básicas de segurança são testadas como as outras funcionalidades (logon/logoff, permissões)

• Testes são geralmente feitos por especialistas ou “hackers” contratados

• Testam a capacidade do sistema de resistir a ataques • Quem realiza os testes deve “pensar” como um atacante

Recomendações para Testes de Segurança • Critérios e metodologias para testes de segurança foram

propostos por diferentes grupos: • NIST (National Institute of Standards and Technology)

• Manual descrevendo técnicas a serem usadas nos testes de segurança

• OSSTMM (Open Source Security Testing Methodology Manual) • desenvolvido pela ISECOM (Institute for Security and Open Methodologies)

• Manual descreve a metodologia proposta para testes e análise de segurança

• OWASP (Open Web Application Security Project) • Guia descrevendo melhores práticas para a realização de testes de

penetração para aplicações e serviços Web

Testes de Aceitação

Testes de

Sistemas

(funcionais)

Especificação de

Requisitos Funcionais

funcionalidades

testadas

subsistemas

integrados

Manual do

Usuário

Testes de

Sistemas

(qualidade)

Especificação de

Requisitos de Qualid.

Testes de

Aceitação Requisitos

do usuário

sistema

testado

sistema

aceito

Testes de Aceitação

• Têm os mesmos objetivos que os testes de sistemas, só que envolvem a participação do cliente ou usuário

• Escolha dos testes feita pelo cliente

• Referências: • Manual do Usuário

• Testes alfa: • realizados por um grupo de usuários no ambiente de desenvolvimento

• seu objetivo é determinar se o sistema pode ser liberado

• Testes beta • realizados por um grupo de usuários em ambiente de operação

Ferramentas

• Testes manuais:

• não recomendável pois número de testes e nº de falhas

• Ferramentas que podem auxiliar: • capture/playback: permitem armazenar e re-aplicar conjuntos de testes

• controle de versões: controlar o sistema e seu histórico de testes

• comparação entre resultados do delta e da linha básica

• embaralhador de casos de teste: permitem revelar falhas de seqüência de entradas

• testes embutidos: assertivas permitem revelar falhas de contrato. Drivers embutidos permitem reduzir custos com manutenção dos testes.

Referências

R.Binder. Testing OO Systems. Addison Wesley, 1999, c.16-19.

M.Fowler. Mocks aren’t stubs. Postado na Internet em julho/2004. http://www.theserverside.com/news/thread.tss?thread_id=27209

G.Rothermel, M.J.Harrold. “A Framework for Evaluating Regression Test Selection Techniques”, Proc. 16th. Int’l Conf on Sw Eng., Sorrento, Itália, maio/1994, pg. 201-210.

M.J.Harrold. “Testing Evolving Software”. The Journal of Systems and Sw, nº 47, 1999, pp173-181.

L.A Fondazzi Martimiano. “Estudo de Técnicas de Teste de Regressão Baseado em Mutação Seletiva”. Dissertação de mestrado. Instituto de Ciências Matemáticas e de Computação - USP/S.Carlos, 1999.

G. Meszaros. : A Pattern Language for Automated Testing of Indirect Inputs and Outputs using XUnit. PLOP 2004. Obtained in jan/2006 at: http://testautomationpatterns.com/TestingIndirectIO.html

Fases de Teste - Início | Faculdade de Computaçãobacala/ES/18-fases-teste.pdf · Ordem de...

Documents

Transcript of Fases de Teste - Início | Faculdade de Computaçãobacala/ES/18-fases-teste.pdf · Ordem de...