Teste de software

Por que fazer testes? Segundo a lei de Murphy, se algo pode dar errado, vai dar. Se tudo parece estar indo bem é por que você não está prestando atenção... e a natureza sempre fica do lado do erro escondido. Ou seja, ninguém é infalível e um erro é sempre muito mais evidente que centenas de acertos.

[ Hits: 18.574 ]

Por: Aline em 08/05/2010


Introdução



Alguns programadores vêem como um martírio testar softwares, ou se sentem humilhados, por que se fossem bons o bastante não precisariam realizar testes.

Alguém já ouviu as frases?
  • "Aqui está funcionando..."
  • "Estranho, isso não era para acontecer..."
  • "Nossa, como você conseguiu fazer isso?"

São frases bem comuns e geralmente são respostas de desenvolvedores para usuários.

O que os desenvolvedores precisam ter em mente é que o usuário não sabe o que eles sabem e consequentemente usarão o aplicativo de maneira diferente do que eles usariam, encontrando assim falhas que passam desapercebidas aos desenvolvedores.

Quanto mais testes são efetuados, menos retrabalho é gerado.

Considerações

Primeiramente deve ser definida uma saída especifica esperada, e esta saída deve ser exaustivamente analisada. Os testes precisam verificar condições válidas e inválidas.

Quem testa destrói o software em busca de erros e falhas, quem desenvolve, como está em um processo de construção, fica cego para esses erros, por isso equipes diferentes precisam ser utilizadas para desenvolvimento e teste.

O ideal é usar testes de regressão, que verificam a evolução da qualidade do software conforme o desenvolvimento for fazendo alterações. Testes descartáveis podem empobrecer o resultado final.

Myers (escritor de um livro sobre testes em 2004) cita que a probabilidade da existência de erros em um trecho de código é maior quando erros já foram encontrados nesse mesmo trecho. Ou seja, erros aparecem em panelinhas, ficam juntos e alguns trechos de códigos são mais propensos a ter erros que outros.

Fases

O teste pode ser divido em 4 fases iniciais.

Teste de unidade:

São feitos testes isolados em pedaços do aplicativo, uma vez que a unidade é a menor parte testável de um software. Geralmente as unidades são independentes, facilitando assim o teste individual. Nesse momento são testadas entradas válidas e inválidas.

Entradas válidas são as previstas pelo sistema e as inválidas são aquelas onde, por exemplo, o código aceita 1 ou 2, ao colocar 3 deverá haver um tratamento para o retorno do erro.

Teste de integração Essa fase é onde os módulos passam a conversar entre si, neste ponto do teste são identificados erros de interface e de módulos soltos, sem integração.

Teste de sistema

Nessa fase os módulos estão integrados, e será testado o conjunto, a funcionalidade, as entradas e as saídas. Esse ponto também testa pontos ão técnicos, como a usabilidade do usuário leigo.

Teste de aceitação

O teste de aceitação é a fase final do teste, geralmente esse teste é feito por usuários finais em locais semelhantes ao que eles usariam o software.

Outras fases

Fora essas fases ainda podem ser incluídas as fases onde são testadas versões ALFA, BETA e as versões RC.

Versão ALFA:

É testada dentro do ambiente de desenvolvimento por usuários finais, onde o desenvolvedor pode verificar e anotar todos os erros que forem apresentados e assim corrigí-los, depois disso é disponibilizada a um grupo restrito e selecionado a versão beta.

Versão BETA:

A versão beta é testada em um ambiente não controlado, e o "testador" relata os problemas encontrados periodicamente ao desenvolvedor. Depois dessa fase, em alguns casos, como nas comunidades de software livre, são lançados os "RELEASE CANDIDATE".

Versão RC:

A versão RC é uma versão beta com uma quantidade pequena de erros, geralmente aberta para toda comunidade realizar testes. Essa versão é a candidata a virar versão final.

    Próxima página

Páginas do artigo
   1. Introdução
   2. Técnicas
Outros artigos deste autor

Impressoras/scanners e multifuncionais Insigne GNU/Linux

Mantendo-se atualizado nas notícias com RSS

Configurando leitores ópticos e HDs

O futuro - Linux, internet e TV

Leitura recomendada

Convocação da Seleção Brasileira do Software Livre

Monitoração de tráfego com MRTG

Calculadoras maravilhosas - HP 42S

Configurando o CACIC (parte 2) - Atualizado

Mostrar nome da música no aMSN

  
Comentários
[1] Comentário enviado por f_Candido em 08/05/2010 - 17:11h

Opa, olá. Primeiro gostaria de parabenizar pelo Artigo. Ficou muito bom!!! Um ponto citado e muito importante, é essa briga(também pode ser levada no sentido literal), entre equipes de desenvolvedores e teste. Geralmente os desenvolvedores não concordam com os erros encontrados.... Enfim. Um detalhe que poderia ser adicionada é a remuneração. Infelizmente no Brasil, até mesmo o profissional certificado não ganha tão bem. Fora, ele ganha bem, muito bem.
Ah, ia me esquecendo, discordo num ponto : "Os testes não devem ser feitos pelo desenvolvedor". Acredito que estes devem fazer testes sim, de suas unidades criadas. E além disso, passar por uma bateria de testes por uma equipe especializada nesta tarefa.

Abraços

[2] Comentário enviado por vinyanalista em 08/05/2010 - 18:29h

Realmente... o que tiver de dar errado, na hora em que tiver que dar errado, vai dar errado... a Lei de Murphy está aí para aterrorizar a vida de nós desenvolvedores.

Assim como o amigo acima, também discordo com o "Os testes não devem ser feitos pelo desenvolvedor". Aqueles erros que provavelmente seriam os mais comuns podem ser evitados pelo programador se ele testar seu programa à medida em que o desenvolve.

Bem verdade, porém, que há erros que são percebidos somente por quem usa o programa. Então a fase de testes com certeza não deve ser dispensada e deve ser realizada por uma equipe diferente da de desenvolvimento. Até porque como os programadores já sabem como fazer as coisas no software não tentam caminhos diferentes para se chegar ao mesmo objetivo e muitas vezes aí está o erro. Nesse ponto, eu concordo com você (na verdade, então, quanto àquela frase, eu discordei apenas em parte).

Só acrescentando algo: os testes podem ser usados não somente para verificar se o programa está funcionando bem, como também se melhorias podem ser feitas neles para torná-los mais fáceis de usar. São os testes de usabilidade. Já tive oportunidade de fazer um teste desses no curso técnico e é bastante interessante.

Mas parabéns pelo artigo, está excelente, realmente muito interessante.

Um abraço.

[3] Comentário enviado por vinipsmaker em 08/05/2010 - 20:25h

Muito bom o artigo, parabéns.

[4] Comentário enviado por madcow em 08/05/2010 - 23:25h

Obrigado Pelo auxilio!

Espero seus próximos Artigos. Este ficou muito bom.

[5] Comentário enviado por artur_olsen em 08/05/2010 - 23:47h

Excelente artigo!

Meus parabéns!

[6] Comentário enviado por edisonsousa em 09/05/2010 - 14:48h

Realmente é impossível fugir da lei de Murphy, o que podemos fazer com esses testes exaustivos é diminuir as suas conseqüências, ok, muito bom artigo, parabéns !!!

[7] Comentário enviado por Teixeira em 09/05/2010 - 16:06h

No tocante a testes feitos pelo próprio desenvolvedor, não há como evitar isso de uma forma absoluta.
Quem programa tem sempre que dar uma peneirada primeiro.

Quando eu fazinha joguinhos, pedia pera meu sobriho (na época com 8 anos de idade) para testar.
Qualquer sombra de erro era assim facilmente (?) detectável, pois criança consegue dar pau em qualquer coisa (afinal, o próprio Murphy já foi criança)...
Mas com programas comerciais, sérios, não há essa chance toda.
Principalmente desenvolvedores free lancers raramente conseguem a ajuda de alguém que tenha paciência de testar exaustivamente algum aplicativo. E alguns erros serão descobertos até alguns meses depois, o que é bastante ruim para a imagem do desenvolvedor.

Existem erros inexplicáveis que até mesmo não valem a pena serem procurados, pois será uma enorme perda de tempo.
Já vi um programa de Caixa em PAL (do Paradox) que funcionava muito bem, mas com um pequeno senão: No mês de novembro (?) ele simplesmente duplicava TODOS os lançamentos.
A solução mais rápida (e também a mais picareta) foi fazer um "bacalhau" que varria os bancos de dados em busca de duplicidades.
Funcionou assim por 4 anos (!!!!), e foi feito outro programa "à prova de novembros".
Certo é que até hoje ninguém descobriu o fenômeno espiritista que dobrava sistematicamente os lançamentos.

Certos erros são devidos ao excesso de certeza de que temos de que o código está "certinho": Já vi editores de texto apresentarem anomalias tais que um código copiado e colado sofre alguma corrupção, fazendo com que uma rotina que deveria funcionar "igualzinho" a outra possa simplesmente tirar o programa do ar...

Em desenvolvimento web, então, é um tanto comum acontecer por exemplo uma linha com
<div id=nome_da_divisao
e aí não funciona de jeito nehum pois esta fatando o ">" que fecharia a tag.
Ou então, um teclado de qualidade inferior pode fazer com que fique <div i=nome_a_ivisao> ou qualquer coisa assim.

Nas linguagens onde se pode fechar os loops mas provê-los de uma saída alternativa ("o pulo do gato") é bom testá-los à medida em que se vai escrevendo o código.
Isso é chato, mas a quantidade de erros a depurar no final será algo próximo de zero.

Agora, cometer erros em programas grandes escritos em Pascal é dose pra leão.

No Cobol, para melhor depurar, temos de impimir o código, e para isso precisamos de uma impressora onde o ponto seja um caracter cuja impressão seja muito bem legível.
Todos sabemos da importância do ponto em Cobol.
E já tivemos uma impressora Centronics (que deu nome ao padrão adotado nas impressoras matriciais) cujo ponto era deteminado por apenas uma das agulhas.
Essa "economia" fazia com que a turma ficasse procurando até chifre em cabeça de cavalo.
Tinha hora em que o ponto não aparecia, tinha hora em que o ponto no papel era uma "cortesia" de algum mosquitinho que aparecesse eventualmente na sala.

Agora imaginem dar manutenção em programas escritos por terceiros em linguagem Assembly e depurados em linguagem de máquina... É dose para dragão de Comodo!...

Tem hora que dá a impressão de que foi o Murphy que inventou a informática e o processamento de dados...

[8] Comentário enviado por pardalz em 10/05/2010 - 12:23h

Bom, ainda bem que eu não sou programador, pq eu odeio programar e admiro muito quem programa.
as vezes o murphy aparece nos servidores que eu configuro também.. mas eh assim mesmo.. vou começar a testar desta forma para ver se ele desaparece..
Belo artigo...

[9] Comentário enviado por removido em 10/05/2010 - 18:25h

Ótimo artigo

[10] Comentário enviado por cainf em 10/05/2010 - 21:26h

Oi Aline ótimo artigo convido-lhe a escrever esse assunto no linuxfast.com.br lá a presença feminina é grande e você com certeza será bem vinda
Abraços

[11] Comentário enviado por elismar em 11/06/2010 - 14:53h

=)

[12] Comentário enviado por wguedes em 11/07/2011 - 18:44h

Acabo de avaliar o artigo com 8 pontos. Achei interessante, bem desenvolvido, mas faltou algo que pra mim é vital: definição ou referência a fontes onde pesquisar.
É que sou iniciante e tão leigo que chego a ter uma sensação de cegueira sobre Linux de um modo amplo e geral.

Adotei o Ubuntu há menos de um mês e ainda não posso dizer que estou engatinhando porque mesmo nessa tentativa os tropeços são sucessivos e de alta frequência, ou seja, ainda não consigo engatinhar. Estou gostando da experiência, especialmente no que diz respeito a aprendizado. É muito boa a sensação de que percebe que está manjando horrores sobre seja lá o que for. Sentir-se ignorante é horrível, mas isto pode ser abrandado por uma outra sensação: a de estar aprendendo. É assim que estou: aprendendo. O que há de mais fascinante em matéria de Linux é o fato de nós, usuários, podermos contar com uma comunidade tão grande e participativa como a que o sistema tem no mundo todo. Isto não tem preço e não tem par.

Instalei recentemente - há uma semana - o Rosegarden. Parece ótimo, mas não pude comprovar suas qualidades, já que está sem som, tanto in quanto out, abre no quadrante superior direito da tela, e tunca de um modo tal que acabo tendo que reiniciar.

Postei ontem, no VOL, um pedido de ajuda que logo foi respondido e me parece que a solução esta ali, mas num informatiquês que, provavelmente, nem o Sr. Bill entenderia. O primeiro tropeço foi com a seguinte sentença:

"12 Deverá ser fornecida uma unidade de teste com pressão compatível com a pressão máxima do BOP, com carta registradora de pressão, com os sistemas de baixa e alta pressão, para a realização rápida dos testes. Além disso, as válvulas e acessórios de linha deverão ser do tipo autoclave."

Pra mim isto é Grego dos mais puros. É claro que como foi o meu primeiro acesso para questionamentos, achei que seria mais simples a resposta e não me ocorreu alertar a comunidade para a minha estupidez no assunto, mas gostaria de deixar uma sugestão: Levem em consideração que o Linux é um sistema em franca expansão e que por isso mesmo a comunidade dos novatos talvez seja maior do que a dos veteranos e que "o usuário não sabe o que eles sabem e consequentemente" precisam de uma linguagem mais simples, que o tecniquês seja definido ou que seja fornecida uma referência referência sobre o problema para o qual pede ajuda. Não sei se o que estou propondo é possível, mas se for vai revolucionar mais ainda esta revolução que o Linux já é.

Grato,
WGuedes


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts