Viso geral[editar | editar cdigo-fonte]

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 frmula
s, atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e
a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidad
e. Idealmente, toda permutao possvel do software deveria ser testada. Entretanto, i
sso se torna impossvel para a ampla maioria dos casos devido quantidade impraticve
l de possibilidades. A qualidade do teste acaba se relacionando qualidade dos pr
ofissionais 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[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
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 Dado
s de entrada so fornecidos, o teste executado e o resultado obtido comparado a um
resultado esperado previamente conhecido. Como detalhes de implementao no so consid
erados, 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 subc
onjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjunto
s de entradas possveis que so processadas similarmente, de forma que testar soment
e um elemento desse subconjunto serve para averiguar a qualidade de todo o subco
njunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar to
dos os casos possveis pode gerar pelo menos dezenas de milhares de casos de teste
s distintos. Entretanto, a partir da especificao do sistema, pode-se encontrar um
subconjunto de inteiros que maximizem a qualidade do teste. Depende do propsito d
o sistema, mas casos possveis incluem inteiros pares, inteiros mpares, zero, intei
ros positivos, inteiros negativos, o maior inteiro, o menor inteiro.
Essa tcnica aplicvel a todas as fases de teste teste unitrio, teste de integrao, test
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[editar | editar cdigo-fonte]
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 caixa-
cinza 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[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
Outras tcnicas de teste existem para testar aspectos no-funcionais do software, co
mo por exemplo, a adequao a restries de negcio, adequao a normas, ou restries tecnol
Em contraste s tcnicas funcionais mencionadas acima, que verificam a produo pelo si
stema de respostas adequadas de suas operaes, de acordo com uma especificao, as tcnic
as no funcionais verificam atributos de um componente ou sistema que no se relacio
nam com a funcionalidade (por exemplo, confiabilidade, eficincia, usabilidade, ma
nutenibilidade 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 verificar
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 um
estado estvel de execuo aps estar em um estado de falha.
Fases ou Nveis[editar | editar cdigo-fonte]
Abstrao do teste
Descendente
Crystal Clear action 1downarrow.png Sistema Crystal Clear action 1uparrow.pn
g
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[editar | editar cdigo-fonte]
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 mesm
o pequenos trechos de cdigo. Assim, o objetivo o de encontrar falhas de funcionam
ento dentro de uma pequena parte do sistema funcionando independentemente do tod
o.
Teste de integrao[editar | editar cdigo-fonte]
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. No faz parte do escopo dessa fase de teste o tratame
nto de interfaces com outros sistemas (integrao entre sistemas). Essas interfaces
so testadas na fase de teste de sistema, apesar de, a critrio do gerente de projet
o, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente
construdo.
Teste de sistema[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
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. PRESSMAN11 afirma que o test
e alfa conduzido pelo cliente no ambiente do desenvolvedor, com este "olhando so
bre 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[editar | editar cdigo-fonte]
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 encontradas. Tais verses so um
passo alm do teste beta, sendo divulgadas para toda a comunidade.
O Ciclo de Vida dos Testes[editar | editar cdigo-fonte]
O Ciclo de Vida dos Testes composto de 5 fases: Planejamento, Preparao, Especificao,
Execuo e Entrega.
Planejamento[editar | editar cdigo-fonte]
Nesta fase elaborada a Estratgia de Teste e o Plano de Teste.
Preparao[editar | editar cdigo-fonte]
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[editar | editar cdigo-fonte]
Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e El
aborar/ Revisar roteiros de testes.
Execuo[editar | editar cdigo-fonte]
Os testes so executados e registrado os resultados obtidos.
Entrega[editar | editar cdigo-fonte]
Esta a ltima fase do ciclo de vida de testes, onde o projeto finalizado e toda do
cumentao finalizada e arquivada.
Papis[editar | editar cdigo-fonte]
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 t
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 teste
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[editar | editar cdigo-fonte]
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, alm
de uma seo para descrio da configurao do sistema usado.
A especificao de teste chamada plano de teste.
Referncias
Ir para cima ? MYERS, 2004, p. 8
Ir para cima ? MYERS, 2004, p. 5
Ir para cima ? Michael Newman (28 de junho de 2002). Software Errors Cost U.S. E
conomy $59.5 Billion Annually: NIST Assesses Technical Needs of Industry to Impr
ove Software-Testing (em ingls). NIST. Pgina visitada em 17 de novembro de 2008.
Ir para cima ? MYERS, 2004, p. 9
Ir para cima ? MYERS, 2004, p. 10
Ir para cima ? Jiantao Pan (1999). Software Testing (em ingls). Universidade Carn
egie Mellon. Pgina visitada em 1 de dezembro de 2008.
Ir para cima ? James Bach (Junho de 1999). Risk and Requirements-Based Testing (
em ingls). IEEE. Pgina visitada em 17 de novembro de 2008.
Ir para cima ? [1]
Ir para cima ? MYERS, 2004, p. 136
Ir para cima ? MYERS, 2004, p. 91
Ir para cima ? PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002
Bibliografia[editar | editar cdigo-fonte]
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 & S
ons, 2004. ISBN 0-471-46912-2
Ver tambm[editar | editar cdigo-fonte]
Anexo:Lista de instituies pela qualidade
Qualidade de software
Gesto da qualidade
Verificao formal
Otimizao em engenharia de software.
Ligaes externas[editar | editar cdigo-fonte]
Guia de gerenciamento de teste
Comunidade Testes de Software
Empresas testes de software
[Expandir]
v e