You are on page 1of 12

Teste de software

Origem: Wikipdia, a enciclopdia livre.


O teste do software a investigao do software a fim de fornecer informaes sobre sua q
ualidade em relao ao contexto em que ele deve operar. Isso inclui o processo de ut
ilizar o produto para encontrar seus defeitos.
O teste um processo realizado pelo testador de software, que permeia outros proc
essos da engenharia de software, e que envolve aes que vo do levantamento de requis
itos at a execuo do teste propriamente dito.
ndice
1 Viso geral
2 Princpios
3 Tcnicas
3.1 Caixa-branca
3.2 Caixa-preta
3.3 Caixa-cinza
3.4 Regresso
3.5 Tcnicas no funcionais
4 Fases ou Nveis
4.1 Teste de unidade
4.2 Teste de integrao
4.3 Teste de sistema
4.4 Teste de aceitao
4.5 Teste de operao
4.5.1 Testes alfa e beta
4.5.2 Candidato a lanamento
5 O Ciclo de Vida dos Testes
5.1 Planejamento
5.2 Preparao
5.3 Especificao
5.4 Execuo
5.5 Entrega
6 Papis
7 Artefatos
8 Referncias
9 Bibliografia
10 Ver tambm
11 Ligaes externas
Viso geral
No se pode garantir que todo software funcione corretamente, sem a presena de erro
s,[1] visto que os mesmos muitas vezes possuem um grande nmero de estados com frmu
las, atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido
e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexid
ade. Idealmente, toda permutao possvel do software deveria ser testada. Entretanto,
isso se torna impossvel para a ampla maioria dos casos devido quantidade imprati
cvel de possibilidades. A qualidade do teste acaba se relacionando qualidade dos
profissionais envolvidos em filtrar as permutaes relevantes.[2]
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificao pode
estar errada ou incompleta, ou pode conter requisitos impossveis de serem impleme
ntados, devido a limitaes de hardware ou software. A implementao tambm pode estar err
ada ou incompleta, como um erro de um algoritmo. Portanto, uma falha o resultado
de um ou mais defeitos em algum aspecto do sistema.

O teste de software pode ser visto como uma parcela do processo de qualidade de
software. A qualidade da aplicao pode e, normalmente, varia significativamente de
sistema para sistema.
Os atributos qualitativos previstos na norma ISO 9126 so:
Funcionalidade
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
De forma geral, mensurar o bom funcionamento de um software envolve compar-lo com
elementos como especificaes, outros softwares da mesma linha, verses anteriores do
mesmo produto, inferncias pessoais, expectativas do cliente, normas relevantes,
leis aplicveis, entre outros. Enquanto a especificao do software diz respeito ao pr
ocesso de verificao do software, a expectativa do cliente diz respeito ao processo
de validao do software. Por meio da verificao ser analisado se o produto foi feito c
orretamente, se ele est de acordo com os requisitos especificados. Por meio da va
lidao ser analisado se foi feito o produto correto, se ele est de acordo com as nece
ssidades e expectativas do cliente.
Um desenvolvimento de software organizado tem como premissa uma metodologia de t
rabalho. Esta deve ter como base conceitos que visem a construo de um produto de s
oftware de forma eficaz. Dentro desta metodologia esto definidos os passos necessr
ios para chegar ao produto final esperado.
Assim, quando se segue uma metodologia para o desenvolvimento de um produto de s
oftware, espera-se um produto final que melhor agrade tanto aos clientes quanto
ao prprio fornecedor, ou seja, a empresa de desenvolvimento. Observando este aspe
cto, no faz sentido iniciar a construo de um produto de software sem ter uma metodo
logia de trabalho bem solidificada e que seja do conhecimento de todos os envolv
idos no processo. Porm, alm de uma crescente demanda por softwares de qualidade, a
s empresas de desenvolvimento de software sofrem cada vez mais presso por parte d
os clientes para que o produto seja entregue num curto perodo de tempo. Este fato
pode fazer com que uma slida metodologia de trabalho acabe por se desequilibrar.
Independentemente da metodologia de trabalho empregada no desenvolvimento de um
software, para que se obtenha um produto final com um certo nvel de qualidade imp
rescindvel a melhoria dos processos de engenharia de software.
Uma maneira vivel para se assegurar a melhoria de tais processos seria tomar como
base modelos sugeridos por entidades internacionais respeitadas no assunto. Den
tro de uma gama de modelos, sejam eles para situaes e ambientes especficos ou para
solues genricas, existem alguns que so mais utilizados e tidos como eficientes, como
por exemplo os SW-CMM, SE-CMM, ISO/IEC 15504 e o mais conhecido CMMI.
Outro fator com grande influncia sobre a qualidade do software a ser produzido o
que diz respeito aos testes que sero executados sobre tal produto. Todas as metod
ologias de desenvolvimento de software tm uma disciplina dedicada aos testes. Atu
almente esta uma tarefa indispensvel, porm muitas vezes efetuada de maneira inefic
iente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pe
la falta de recursos humanos e financeiros.
De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num cu
sto anual de 59,5 bilhes de dlares economia dos Estados Unidos. Mais de um tero do
custo poderia ser evitado com melhorias na infraestrutura do teste de software.[
3]
Princpios

Para Myers (2004), h princpios vitais para o teste de software. O caso de teste de
ve definir a sada esperada, de forma a reduzir a interpretao do critrio de sucesso.
A sada da execuo do teste deve ser exaustivamente analisada. Os casos de teste deve
m verificar no somente as condies invlidas de execuo, como tambm as condies vlidas.
conceito apresentado utilizar pessoas e organizaes diferentes para a implementao e p
ara a verificao. A entidade de teste possui uma viso destrutiva do sistema, em busc
a de erros, enquanto a entidade de programao possui uma viso construtiva, em busca
da implementao de uma especificao.
Myers tambm aborda o esforo para se construir casos de teste. Deve-se evitar teste
s descartveis, pois a qualidade do teste piora gradualmente com as iteraes de desen
volvimento. Em contrapartida, h o teste de regresso, que permite quantificar a evo
luo da qualidade de software, mantendo e executando novamente testes realizados an
teriormente.
O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a
probabilidade de existncia de erros num certo trecho de cdigo proporcional quantid
ade de erros j encontrada anteriormente. Basicamente, erros aparecem em grupos. T
rechos especficos de cdigo de um software qualquer esto mais propensos a ter erros
que outros.
Tcnicas
Existem muitas maneiras de se testar um software. Mesmo assim, existem as tcnicas
que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens es
truturadas que ainda hoje tm grande valia para os sistemas orientados a objeto. A
pesar de os paradigmas de desenvolvimento serem completamente diferentes, o obje
tivo principal destas tcnicas continua a ser o mesmo, encontrar falhas no softwar
e. Abaixo esto descritas algumas das tcnicas mais conhecidas.
Caixa-branca
Ver artigo principal: teste de caixa-branca
Tambm chamada de teste estrutural ou orientado lgica, a tcnica de caixa-branca aval
ia o comportamento interno do componente de software. Essa tcnica trabalha direta
mente sobre o cdigo fonte do componente de software para avaliar aspectos tais co
mo: teste de condio, teste de fluxo de dados, teste de ciclos, teste de caminhos lg
icos, cdigos nunca executados.
Os aspectos avaliados nesta tcnica de teste dependero da complexidade e da tecnolo
gia que determinarem a construo do componente de software, cabendo portanto avaliao
de mais aspectos que os citados anteriormente. O testador tem acesso ao cdigo fon
te da aplicao e pode construir cdigos para efetuar a ligao de bibliotecas e component
es. Este tipo de teste desenvolvido analisando o cdigo fonte e elaborando casos d
e teste que cubram todas as possibilidades do componente de software. Dessa mane
ira, todas as variaes relevantes originadas por estruturas de condies so testadas.
Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre JUnit para d
esenvolvimento de classes de teste para testar classes ou mtodos desenvolvidos em
Java. Tambm se enquadram nessa tcnica testes manuais ou testes efetuados com apoi
o de ferramentas para verificao de aderncia a boas prticas de codificao reconhecidas p
elo mercado de software. A aderncia a padres e boas prticas visa principalmente a d
iminuio da possibilidade de erros de codificao e a busca de utilizao de comandos que g
erem o melhor desempenho de execuo possvel. Apesar de muitos desenvolvedores alegar
em que no h ganhos perceptveis com essa tcnica de teste aplicada sobre unidades de s
oftware, devemos lembrar que, no ambiente produtivo, cada programa pode vir a se
r executado milhares ou milhes de vezes em intervalos de tempo pequenos. na reali
dade de produo que a soma dos aparentes pequenos tempos de execuo e consumo de memria
de cada programa poder levar o software a deixar de atender aos objetivos espera
dos. A tcnica de teste de caixa-branca recomendada para as fases de teste de unid
ade e teste de integrao, cuja responsabilidade principal fica a cargo dos desenvol

vedores do software, que por sua vez conhecem bem o cdigo fonte produzido.
Caixa-preta
Ver artigo principal: Teste de caixa-preta
Tambm chamada de teste funcional, teste comportamental, orientado a dado ou orien
tado a entrada e sada, a tcnica de caixa-preta avalia o comportamento externo do c
omponente de software, sem se considerar o comportamento interno do mesmo.[4] Da
dos de entrada so fornecidos, o teste executado e o resultado obtido comparado a
um resultado esperado previamente conhecido. Como detalhes de implementao no so cons
iderados, os casos de teste so todos derivados da especificao.
Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao ideal todas a
s entradas possveis seriam testadas, mas na ampla maioria dos casos isso impossvel
.[5] Outro problema que a especificao pode estar ambgua em relao ao sistema produzido
, e como resultado as entradas especificadas podem no ser as mesmas aceitas para
o teste.[6] Uma abordagem mais realista para o teste de caixa-preta escolher um
subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconj
untos de entradas possveis que so processadas similarmente, de forma que testar so
mente um elemento desse subconjunto serve para averiguar a qualidade de todo o s
ubconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testa
r todos os casos possveis pode gerar pelo menos dezenas de milhares de casos de t
estes distintos. Entretanto, a partir da especificao do sistema, pode-se encontrar
um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propsi
to do sistema, mas casos possveis incluem inteiros pares, inteiros mpares, zero, i
nteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro.

Essa tcnica aplicvel a todas as fases de teste


teste unitrio, teste de integrao, tes
e de sistema e teste de aceitao. A aplicao de critrios de teste leva o testador a pro
duzir um conjunto de casos de teste (ou situaes de teste). A aplicao do critrio de Pa
rticionamento de Equivalncia (ou uso de classes de equivalncia) permite avaliar se
a quantidade de casos de teste produzida coerente. O Particionamento de Equivaln
cia se baseia em testar subconjuntos dos dados e no todos os dados possveis - o qu
e seria exaustivo e s vezes impossvel -, pode-se assumir que as classes de equivaln
cia sero tratadas da mesma maneira, pois um nico elemento da classe se comporta co
mo um representante dessa classe. A partir das classes de equivalncia identificad
as pode-se usar a Anlise de Valor Limite, o testador construir casos de teste que
atuem nos limites superiores e inferiores destas classes, de forma que um nmero mn
imo de casos de teste permita a maior cobertura de teste possvel. Outro critrio o
Grafo Causa-Efeito, que consiste em utilizar a ideia de grafos para transformar
entradas de dados em causas e sadas de dados em efeitos. Esse grafo posteriorment
e convertido para tabela de deciso e este para casos de teste. Por fim, tem-se o
critrio de Error-Guessing, que uma tcnica em que os analistas de teste, por meio d
a experincia e intuio, supem tipos provveis de erro.
Uma abordagem no desenvolvimento do teste de caixa-preta o teste baseado na espe
cificao, de forma que as funcionalidades so testadas de acordo com os requisitos. A
pesar de necessrio, esse tipo de teste insuficiente para identificar certos risco
s num projeto de software.[7]
Caixa-cinza
A tcnica de teste de caixa-cinza uma mescla do uso das tcnicas de caixa-preta e de
caixa-branca. Isso envolve ter acesso a estruturas de dados e algoritmos do com
ponente a fim de desenvolver os casos de teste, que so executados como na tcnica d
a caixa-preta. Manipular entradas de dados e formatar a sada no considerado caixacinza pois a entrada e a sada esto claramente fora da caixa-preta. A caixa-cinza p
ode incluir tambm o uso de engenharia reversa para determinar por exemplo os limi
tes superiores e inferiores das classes, alm de mensagens de erro.
Regresso
Ver artigo principal: teste de regresso

Essa uma tcnica de teste aplicvel a uma nova verso de software ou necessidade de se
executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste
em se aplicar, a cada nova verso do software ou a cada ciclo, todos os testes qu
e j foram aplicados nas verses ou ciclos de teste anteriores do sistema. Inclui-se
nesse contexto a observao de fases e tcnicas de teste de acordo com o impacto de a
lteraes provocado pela nova verso ou ciclo de teste. Para efeito de aumento de prod
utividade e de viabilidade dos testes, recomendada a utilizao de ferramentas de au
tomao de teste, de forma que, sobre a nova verso ou ciclo de teste, todos os testes
anteriores possam ser executados novamente com maior agilidade.
Tcnicas no funcionais

So tcnicas utilizadas para verificar a operao correta do sistema em relao a casos invl
dos ou inesperados de entrada. Outras tcnicas de teste existem para testar aspect
os no-funcionais do software, como por exemplo, a adequao a restries de negcio, adequa
a normas, ou restries tecnolgicas. Em contraste s tcnicas funcionais mencionadas acim
a, que verificam a produo pelo sistema de respostas adequadas de suas operaes, de ac
ordo com uma especificao, as tcnicas no funcionais verificam atributos de um compone
nte ou sistema que no se relacionam com a funcionalidade (por exemplo, confiabili
dade, eficincia, usabilidade, manutenibilidade e portabilidade)[8] .
Uma delas o uso conjunto de teste de desempenho e teste de carga, que verifica s
e o software consegue processar grandes quantidades de dados, e nas especificaes d
e tempo de processamento exigidas, o que determina a escalabilidade do software.
O teste de usabilidade necessrio para verificar se a interface de usurio fcil de s
e aprender e utilizar. Entre verificaes cabveis esto a relao da interface com conhecim
ento do usurio, a compreensibilidade das mensagens de erro e a integridade visual
entre diferentes componentes.[9] J o teste de confiabilidade usado para verifica
r se o software seguro em assegurar o sigilo dos dados armazenados e processados
. O teste de recuperao usado para verificar a robustez do software em retornar a u
m estado estvel de execuo aps estar em um estado de falha.
Fases ou Nveis
Abstrao do teste Descendente
Crystal Clear action 1downarrow.png
Sistema
Crystal Clear action 1up
arrow.png
Ascendente
Integrao
Unidade
Uma prtica comum testar o software aps uma funcionalidade ser desenvolvida, e ante
s dela ser implantada no cliente, por um grupo de profissionais diferente da imp
lementao. Essa prtica pode resultar na fase de teste ser usada para compensar atras
os do projeto, comprometendo o tempo devotado ao teste. Outra prtica comear o test
e no mesmo momento que o projeto, num processo contnuo at o fim do projeto.
Em contrapartida, algumas prticas emergentes como a programao extrema e o desenvolv
imento gil focam o modelo de desenvolvimento orientado ao teste. Nesse processo,
os testes de unidade so escritos primeiro (TDD), por engenheiros de software. Ant
es da implementao da unidade em questo, o teste falha. Ento o cdigo escrito, passando
incrementalmente em pores maiores dos casos de teste. Os testes so mantidos junto
com o resto do cdigo fonte do software, e geralmente tambm integra o processo de c
onstruo do software.
Teste de unidade
Ver artigo principal: teste de unidade
Tambm conhecida como teste unitrio ou teste de mdulo, a fase em que se testam as me
nores unidades de software desenvolvidas (pequenas partes ou unidades do sistema
).[10] O universo alvo desse tipo de teste so as subrotinas, mtodos, classes ou me
smo pequenos trechos de cdigo. Assim, o objetivo o de encontrar falhas de funcion
amento dentro de uma pequena parte do sistema funcionando independentemente do t
odo.

Teste de integrao
Ver artigo principal: teste de integrao
Na fase de teste de integrao, o objetivo encontrar falhas provenientes da integrao i
nterna dos componentes de um sistema. Geralmente os tipos de falhas encontradas
so de transmisso de dados. Por exemplo, um componente A pode estar aguardando o re
torno de um valor X ao executar um mtodo do componente B; porm, B pode retornar um
valor Y, gerando uma falha. O teste de integrao conduz ao descobrimento de possvei
s falhas associadas interface do sistema.No faz parte do escopo dessa fase de tes
te o tratamento de interfaces com outros sistemas (integrao entre sistemas). Essas
interfaces so testadas na fase de teste de sistema, apesar de, a critrio do geren
te de projeto, estas interfaces podem ser testadas mesmo antes de o sistema esta
r plenamente construdo.
Teste de sistema
Ver artigo principal: teste de sistema
Na fase de teste de sistema, o objetivo executar o sistema sob ponto de vista de
seu usurio final, varrendo as funcionalidades em busca de falhas em relao aos obje
tivos originais. Os testes so executados em condies similares
de ambiente, interfac
es sistmicas e massas de dados
quelas que um usurio utilizar no seu dia-a-dia de man
ipulao do sistema. De acordo com a poltica de uma organizao, podem ser utilizadas con
dies reais de ambiente, interfaces sistmicas e massas de dados.
Teste de aceitao
Ver artigo principal: teste de aceitao
Geralmente, os testes de aceitao so realizados por um grupo restrito de usurios fina
is do sistema, que simulam operaes de rotina do sistema de modo a verificar se seu
comportamento est de acordo com o solicitado. Teste formal conduzido para determ
inar se um sistema satisfaz ou no seus critrios de aceitao e para permitir ao client
e determinar se aceita ou no o sistema. Validao de um software pelo comprador, pelo
usurio ou por terceira parte, com o uso de dados ou cenrios especificados ou reai
s. Pode incluir testes funcionais, de configurao, de recuperao de falhas, de segurana
e de desempenho.
Teste de operao
Ver artigo principal: teste de operao
Nessa fase o teste conduzido pelos administradores do ambiente final em que o si
stema ou software entrar em ambiente produtivo. Vale ressaltar que essa fase apli
cvel somente a sistemas de informao prprios de uma organizao, cujo acesso pode ser fei
to interna ou externamente a essa organizao. Nessa fase de teste devem ser feitas
simulaes para garantir que a entrada em produo do sistema ser bem sucedida. Envolve t
estes de instalao, simulaes com cpia de segurana dos bancos de dados, etc.. Em alguns
casos um sistema entrar em produo para substituir outro e necessrio garantir que o n
ovo sistema continuar garantindo o suporte ao negcio.
Testes alfa e beta
Ver artigo principal: verso alfa
Ver artigo principal: verso beta
Em casos especiais de processos de desenvolvimento de software sistemas operacio
nais, sistemas gerenciadores de bancos de dados e outros softwares distribudos em
escala nacional e internacional os testes requerem fases tambm especiais antes d
o produto ser disponibilizado a todos os usurios.
O perodo entre o trmino do desenvolvimento e a entrega conhecido como fase alfa e
os testes executados nesse perodo, como testes alfa. PRESSMAN[11] afirma que o te
ste alfa conduzido pelo cliente no ambiente do desenvolvedor, com este "olhando
sobre o ombro" do usurio e registrando erros e problemas de uso.
Completada a fase alfa de testes, so lanadas a grupos restritos de usurios, verses d
e teste do sistema denominadas verses beta. Ele tambm um teste de aceitao voltado pa

ra softwares cuja distribuio atingir grande nmero de usurios de uma ou vrias empresas
compradoras. PRESSMAN afirma que o teste beta conduzido em uma ou mais instalaes d
o cliente, pelo usurio final do software. Diferente do teste alfa, o desenvolvedo
r geralmente no est presente. Consequentemente, o teste beta uma aplicao do software
num ambiente que no pode ser controlado pelo desenvolvedor. O cliente registra t
odos os problemas (reais ou imaginrios) que so encontrados durante o teste beta e
os relata ao desenvolvedor em intervalos regulares. Com o resultado dos problema
s relatados durante os testes beta, os engenheiros de software fazem modificaes e
depois se preparam para liberar o produto de software para toda a base de client
es.
A comunidade do teste de software usa o termo teste gama de forma sarcstica refer
indo-se aos produtos que so mal testados e so entregues aos usurios finais para que
estes encontrem os defeitos j em fase de produo.
Candidato a lanamento
Ultimamente, e principalmente na comunidade de software livre, comum utilizar o
termo candidato a lanamento (release candidate) para indicar uma verso que candida
ta a ser a verso final, em funo da quantidade de erros encontrados. Tais verses so um
passo alm do teste beta, sendo divulgadas para toda a comunidade.
O Ciclo de Vida dos Testes
O Ciclo de Vida dos Testes composto de 5 fases: Planejamento, Preparao, Especificao,
Execuo e Entrega.
Planejamento
Nesta fase elaborada a Estratgia de Teste e o Plano de Teste.
Preparao
O objetivo desta fase preparar o Ambiente de Teste (equipamentos, pessoal, ferra
mentas de automao, massa de testes) para que os testes sejam executados conforme p
lanejados.
Especificao
Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e El
aborar/ Revisar roteiros de testes.
Execuo
Os testes so executados e os resultados obtidos so registrados.
Entrega
Esta a ltima fase do ciclo de vida de testes, onde o projeto finalizado e toda do
cumentao finalizada e arquivada.
Papis
Segue abaixo alguns dos papis que uma pessoa pode desenvolver num projeto de test
e de software. Uma pessoa pode acumular mais de um dos papis citados, de acordo c
om caractersticas e restries de projetos de desenvolvimento de software nas quais e
stejam inseridas. Nas fases de teste de unidade e de integrao, por exemplo, os papi
s de arquiteto de teste e analista de teste podem ser assumidos pelo analista de
sistemas do projeto; o papel de testador pode ser assumido pelo programador ou
por um segundo programador que atue num processo de programao em pares. Na fase de
teste de sistema, num contexto em que haja uma equipe de teste independente, po
de haver profissionais acumulando os papis de arquiteto de teste, analista de tes
te e testador.
O lder (ou gerente) do projeto de testes a pessoa responsvel pela liderana de um pr
ojeto de teste especfico, normalmente relacionado a um sistema de desenvolvimento
, seja um projeto novo ou uma manuteno. J o engenheiro (ou arquiteto) de teste o tcn
ico responsvel pelo levantamento de necessidades relacionadas montagem da infraes

trutura de teste, incluindo-se o ambiente de teste, a arquitetura de soluo, as res


tries tecnolgicas, as ferramentas de teste. tambm responsvel pela liderana tcnica do
abalho de teste e pela comunicao entre a equipe de teste e a equipe de projeto (ou
equipe de desenvolvimento).
O analista de teste o tcnico responsvel pela operacionalizao do processo de teste. D
eve seguir as orientaes do gerente de teste ou do arquiteto de teste para detalhar
a forma de execuo dos testes e as condies de teste necessrias. Tambm deve focar seu t
rabalho nas tcnicas de teste adequadas fase de teste trabalhada. Tambm no campo de
anlise, o analista de ambiente o tcnico responsvel pela configurao do ambiente de te
ste e pela aplicao das ferramentas necessrias para tal. Esse profissional deve ser
especializado em arquiteturas de soluo e nos sistemas operacionais e softwares de
infraestrutura que regem o ambiente. Ele ser responsvel por tornar disponvel o ambi
ente de teste.
O testador o tcnico responsvel pela execuo de teste. Ele deve observar as condies de
este e respectivos passos de teste documentados pelo analista de teste e evidenc
iar os resultados de execuo. Em casos de execues de teste mal-sucedidas, esse profis
sional pode tambm registrar ocorrncias de teste (na maioria das vezes, defeitos) e
m canais atravs dos quais os desenvolvedores tomaro conhecimento das mesmas e toma
ro as providncias de correo ou de esclarecimentos.

Por fim, o automatizador de teste o tcnico responsvel pela automao de situaes de test
em ferramentas. Ele deve observar as condies de teste e respectivos passos de tes
te documentados pelo analista de teste e automatizar a execuo desses testes na fer
ramenta utilizada. Normalmente so gerados scripts de teste que permitam a execuo de
ciclos de teste sempre que se julgar necessrio, desde claro, que sejam garantida
s as mesmas condies iniciais do ciclo de teste (valores de dados, estados dos dado
s, estados do ambiente, etc..)
Artefatos
O processo de teste de software pode produzir diversos artefatos. O caso de test
e geralmente consiste de uma referncia a um identificador ou requisito de uma esp
ecificao, pr-condies, eventos, uma srie de passos a se seguir, uma entrada de dados, u
ma sada de dados, resultado esperado e resultado obtido. A srie de passos (ou part
e dela) pode estar contida num procedimento separado, para que possa ser compart
ilhada por mais de um caso de teste.

Um script de teste a combinao de um caso de teste, um procedimento de teste e os d


ados do teste. Uma coleo de casos de teste chamada de suite de teste. Geralmente,
ela tambm contm instrues detalhadas ou objetivos para cada coleo de casos de teste, al
de uma seo para descrio da configurao do sistema usado.
A especificao de teste chamada plano de teste.
Referncias
MYERS, 2004, p. 8
MYERS, 2004, p. 5
Michael Newman (28 de junho de 2002). Software Errors Cost U.S. Economy $59.5 Bi
llion Annually: NIST Assesses Technical Needs of Industry to Improve Software-Te
sting (em ingls) NIST. Visitado em 17 de novembro de 2008.
MYERS, 2004, p. 9
MYERS, 2004, p. 10
Jiantao Pan (1999). Software Testing (em ingls) Universidade Carnegie Mellon. Vis
itado em 1 de dezembro de 2008.
James Bach (Junho de 1999). Risk and Requirements-Based Testing (em ingls) IEEE.
Visitado em 17 de novembro de 2008.
[1]
MYERS, 2004, p. 136
MYERS, 2004, p. 91

PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002


Bibliografia
KOSCIANSKI, A., Soares. M. S. Qualidade de Software. [S.l.]: Novatec, 2006.
PRESSMAN, R. S.. Engenharia de Software. [S.l.]: McGraw Hill, 2002.
MYERS, Glenford J.. The Art of Software Testing. 2 ed. Nova Jrsei: John Wiley
& Sons, 2004. ISBN 0-471-46912-2
Ver tambm
Anexo:Lista de instituies pela qualidade
Qualidade de software
Gesto da qualidade
Verificao formal
Otimizao em engenharia de software
Ligaes externas
Guia de gerenciamento de teste
Comunidade Testes de Software
Empresas testes de software

v e
Engenharia de software
reas
Anlise de Requisitos Anlise de sistemas Projeto de software Programao
computadores Mtodos formais Teste de software Implantao de software Manuten
software
Conceitos
Modelagem de dados Enterprise architecture Especificao de progr
ama Linguagem de Modelagem Paradigma de programao Software Arquitetura de soft
ware Metodologia de desenvolvimento de software Processo de desenvolvimento de
software Qualidade de software Garantia de qualidade de software Arqueologia
de software Anlise estruturada
Orientaes
Agile Programao orientada a aspecto Programao Orientada a Objeto
Ontologia Arquitetura orientada a servios Ciclo de vida de desenvolvimento de
sistema
Modelos
Modelos de Desenvolvimento
Agile Desenvolvimento iterativo e incremental
RUP Scrum Modelo em espiral Modelo em cascata XP Modelo V Modelo de cons
ruo incremental Prototipao
Outros Modelos SPICE CMMI Data model Function model Information model Met
amodelagem Object model Modelagem de sistemas View model
Linguagens de modelagem
IDEF UML
reas relacionadas

Cincia da computao Engenharia da computao Engenharia empresarial histria


rao Gerncia de projetos Gerenciamento da qualidade Usabilidade Engenharia de s
stemas
Symbol question.svg Categoria Commons
v e
Teste de software
Tcnicas funcionais
caixa-branca
caixa-preta
regresso
Tcnicas no funcionais
desempenho carga
usabilidade
confiabilidade
recupera
rana
Fases unidade integrao sistema
aceitao
operao
Artefatos
caso de teste
plano de teste
Assuntos relacionados qualidade de software
automao de teste IEEE 829
v e
Processo de desenvolvimento de software

Atividade e passos
Requisito Projeto de Software Construo de Software Arquite
tura Especificao Implementao Teste Depurao Implantao Manuteno
Modelos/Metodologias
Cascata Prototipao gil Cleanroom Iterativo Modelo V RA
M PU Lean Dual Vee Model RUP Espiral XP Scrum TDD BDD FDD DDD MDE
Disciplinas de apoio
Gerncia de configurao Documentao Gerncia de projetos Gara
de qualidade de software Experincia do usurio
Ferramentas
Compilador Depurador Gprof Construtor de GUI Ferramentas UML IDE
Automao de compilao
Categoria:
Teste de software
Menu de navegao
Criar uma conta
Entrar
Artigo
Discusso
Ler
Editar
Editar cdigo-fonte
Ver histrico
Pgina principal
Contedo destacado
Eventos atuais
Esplanada
Pgina aleatria
Portais
Informar um erro
Colaborao
Boas-vindas
Ajuda
Pgina de testes
Portal comunitrio
Mudanas recentes
Manuteno
Criar pgina
Pginas novas
Contato
Donativos
Imprimir/exportar
Criar um livro
Descarregar como PDF
Verso para impresso
Noutros projectos
Wikimedia Commons
Ferramentas
Pginas afluentes
Alteraes relacionadas

Carregar ficheiro
Pginas especiais
Ligao permanente
Informaes da pgina
Item no Wikidata
Citar esta pgina
Noutros idiomas
???????
?????????? (???????????)?
?????????
Catal
Ce tina
Deutsch
English
Espaol
Eesti
?????
Suomi
Franais
?????
??????
Magyar
Bahasa Indonesia
Italiano
???
???????
???????
?????
???
??????????
Bahasa Melayu
Nederlands
Norsk bokml
Polski
Romna
???????
Simple English
Slovencina
Shqip
Svenska
?????
???
Trke
??????????
Ti?ng Vi?t
??
Editar ligaes
Esta pgina foi modificada pela ltima vez (s) 19h32min de 17 de julho de 2015.
Este texto disponibilizado nos termos da licena Creative Commons - Atribuio - C
ompartilha Igual 3.0 No Adaptada (CC BY-SA 3.0); pode estar sujeito a condies adici
onais. Para mais detalhes, consulte as Condies de Uso.
Poltica de privacidade
Sobre a Wikipdia
Avisos gerais
Programadores

Verso mvel
Wikimedia Foundation
Powered by MediaWiki

You might also like