9 Tipos de Testes de Software em Engenharia de Software

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Os testes de software são um ofício. Um testador de software, tal como um artesão, deve ter um conhecimento sólido das ferramentas de teste de software que tem à sua disposição. Compilámos uma lista de 9 tipos diferentes de testes de software, bem como das ferramentas utilizadas por cada tipo, para ajudar os analistas de […]

Os testes de software são um ofício. Um testador de software, tal como um artesão, deve ter um conhecimento sólido das ferramentas de teste de software que tem à sua disposição. Compilámos uma lista de 9 tipos diferentes de testes de software, bem como das ferramentas utilizadas por cada tipo, para ajudar os analistas de QA e qualquer outra pessoa que trabalhe na área de testes de software a compreender melhor o seu ofício.

Por que razão precisamos de testes de software?

Por vezes, é importante recordar por que razão aquilo que fazemos é importante. O simples facto é que todos os programas de software desenvolvidos até hoje que alcançaram o sucesso o fizeram com a ajuda de testadores de software que trabalharam incansavelmente para garantir que o produto apresentava o mais elevado padrão possível. Eis três razões pelas quais os testes de software são importantes. 

  1. Satisfação do cliente: Durante o desenvolvimento de um projeto, pode ser fácil perdermo-nos no emaranhado do código e esquecermo-nos de que o utilizador também precisa de ficar satisfeito com o funcionamento do software. Os analistas de QA e os restantes membros da equipa de QA ocupam esse papel. 
  2. Qualidade do produto: Todas as profissões em que uma equipa ou indivíduo cria algo de raiz exigem outra equipa para detetar os seus erros. Os escritores precisam de editores. Os realizadores de cinema também precisam de editores. Os programadores de software não precisam de editores, mas precisam de uma equipa de QA que forneça um ponto de vista objetivo e detete eventuais erros. 
  3. Segurança: A cada dia que passa, este aspeto parece tornar-se cada vez mais importante. Os clientes querem ter a tranquilidade de saber que as informações que introduzem no software e o trabalho que realizam nele permanecem privados. Parte do trabalho de QA consiste em garantir que os clientes têm essa confiança. 

Metodologias de testes de software

Cada tipo de técnica de teste de software mencionada neste artigo pertence a uma de duas categorias principais: testes estáticos e testes dinâmicos. Antes de explorarmos os detalhes específicos das nove técnicas diferentes de teste de software, explicarei a diferença entre estas duas metodologias e em que momento do ciclo de desenvolvimento de software são aplicadas. 

Testes estáticos

Os testes estáticos são um tipo de teste de software realizado numa fase inicial do ciclo de desenvolvimento. Constituem uma forma económica de encontrar erros antes de estes se transformarem em grandes problemas para a equipa de desenvolvimento. Os testes estáticos são executados no início do ciclo de desenvolvimento porque podem ser realizados sem que o software esteja totalmente funcional. É verdade: o software pode ser depurado antes de estar sequer perto da conclusão. Vê como isso pode ser útil? 

Os testes estáticos são realizados de duas formas:

  • Análises manuais: O código é analisado por um analista de QA ou por um testador. 
  • Análise automática: Uma ferramenta de teste verifica automaticamente o documento do programa e regista eventuais erros.

Os testes estáticos são:

A maioria dos testes estáticos é realizada sob a forma de revisões de documentos. Neste cenário, um documento é uma descrição escrita de um produto (conhecida como documento de conceção de software) ou o código-fonte do programa. Eis algumas técnicas de teste estático que todos os analistas de QA devem conhecer:

  • Revisão informal:  Não existem orientações rigorosas para a revisão informal. A equipa analisa os documentos de teste e comenta o que observa. Não existe documentação.
  • Revisão guiada: O autor do código percorre o seu documento, e a equipa de QA coloca questões e manifesta preocupações. As revisões guiadas são normalmente muito informais e constituem uma boa forma de discutir temas com pessoas de fora da área de software. 
  • Revisão técnica: Especialistas técnicos reúnem-se e analisam as especificações técnicas do código. Realizar este procedimento numa fase inicial do processo de desenvolvimento garante que o produto final cumprirá as especificações exigidas.
  • Inspeções: A mais formal de todas as revisões. Uma equipa de moderadores formados inspecionará cuidadosamente os documentos durante a reunião. Quaisquer erros encontrados serão documentados formalmente e registados para análise. Será realizada uma revisão de acompanhamento para verificar se os erros documentados foram corrigidos. 

Na maioria dos casos, as revisões de testes estáticos são úteis porque toda a equipa de QA analisará o produto e proporá alterações com base nos problemas que identifica e nos problemas previsíveis. Para além da vantagem de envolver uma grande variedade de opiniões na conversa, isto também permite que todos os membros da equipa se familiarizem com o progresso e o design do projeto. 

Utilize testes estáticos se a sua equipa:

  • Estiver numa fase inicial do processo de desenvolvimento.
  • Estiver à procura de uma forma económica de encontrar erros.
  • Tiver software que ainda não esteja pronto para ser executado.
  • Quiser detetar erros numa fase inicial do desenvolvimento.
Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

Testes dinâmicos

Ao contrário dos testes estáticos, os testes dinâmicos são um tipo de teste de software que requer a execução de código. Naturalmente, isto significa que o desenvolvimento terá de estar mais avançado no ciclo de produção. A vantagem de testar código executável é que os analistas de QA podem observar o desempenho do software enquanto este é executado numa situação do mundo real. É uma excelente forma de verificar o comportamento funcional do software e outros aspetos, como a utilização da CPU. Os testes dinâmicos verificam se o resultado esperado corresponde ao resultado real. O principal objetivo dos testes dinâmicos é verificar se o produto cumpre os requisitos de design e funcionais definidos antes do início do projeto.

Normalmente, existem quatro etapas envolvidas quando o software de um sistema é testado dinamicamente, que os analistas de QA devem conhecer:

  • Testes unitários: Quando o software é submetido a testes unitários, é dividido nos componentes mais pequenos possíveis e testado individualmente. Ao testar desta forma, os analistas de QA podem ter a certeza de que cada parte individual do software está a funcionar conforme previsto. E, se for encontrado um erro, será mais fácil corrigi-lo nesta fase do desenvolvimento, uma vez que o código problemático pode ser rapidamente isolado. Normalmente, quando a equipa de QA inicia os testes dinâmicos (embora, por vezes, esta fase seja realizada pela equipa de desenvolvimento), começa pelos testes unitários.
  • Testes de integração: Depois de o software ter sido cuidadosamente dividido nos seus componentes e testado através de testes unitários, os componentes são agrupados e testados novamente. Se os testes unitários servem para garantir que cada parte individual funciona corretamente, os testes de integração garantem que essas partes comunicam entre si como devem. Pense nisto como a montagem de um automóvel. Em cada fase da montagem, as peças do automóvel (o motor, os pedais e o volante) são testadas individualmente. Depois, o automóvel é montado e testado como um todo, para garantir que o pedal do acelerador comunica corretamente com o motor (e que os travões também!). Quer garantir uma integração perfeita entre módulos? As nossas ferramentas de teste de software recomendadas podem ajudá-lo a consegui-lo.
  • Testes de sistema: Os testes de sistema são o terceiro nível dos testes de software. Nesta fase, é testado um software completo e totalmente integrado. O objetivo do teste de sistema é garantir que o software cumpre os requisitos, ou seja, que faz aquilo para que foi concebido. 
  • Testes de aceitação: A fase final dos testes dinâmicos. O teste de aceitação consiste em testar novamente o software face aos requisitos e garantir que está aperfeiçoado de acordo com um padrão aceitável. É realizado para garantir que não passaram erros despercebidos nas outras fases de teste. Essencialmente, trata-se de uma verificação adicional por motivos de segurança. 

Etapas dos testes dinâmicos

  1. Testes unitários
  2. Testes de integração
  3. Testes de sistema
  4. Testes de aceitação

Dica rápida: testes de verificação vs. validação 

Os testes de verificação partilham todas as características principais dos testes estáticos. O objetivo de um teste de verificação é verificar todos os documentos e o código, sendo alcançado através dos mesmos métodos utilizados nos testes estáticos

Da mesma forma, os testes de validação partilham todas as características principais dos testes dinâmicos. Um teste de verificação visa confirmar que o software é de elevada qualidade, que é precisamente o objetivo dos testes de sistema e de aceitação.

Agora que abordámos alguns conceitos fundamentais relacionados com os testes de software, vamos explorar os 9 tipos de testes de software que todos os analistas de QA devem conhecer.

9 tipos de testes de software que todos os analistas de QA devem conhecer:

  1. Caixa preta
  2. Caixa branca
  3. Caixa cinzenta 
  4. Automatizados 
  5. Unitários
  6. De regressão
  7. Exploratórios
  8. Testes funcionais
  9. Testes de usabilidade

1. Testes de caixa preta

Os testes de caixa preta são uma estratégia de teste de software em que o desenho do sistema de software a testar é desconhecido pelo testador.

Lembra-se daquela cena no final de Pulp Fiction, em que Samuel Jackson abre a mala e o seu rosto se ilumina? Enquanto espectadores, sabemos o que a mala significa e representa no contexto do filme, mas nunca descobrimos o que está lá dentro. Um testador de caixa preta é o espectador, que sabe o que aquilo (seja uma mala ou um sistema de software) deve fazer, mas não sabe como é constituído.

Fotografia de testes de caixa preta, tipos de testes de software

Um testador responsável por testar uma aplicação de controlo de tempos através de testes de caixa preta abrirá o programa sem conhecer o desenho interno do software e experimentará as diferentes funcionalidades e menus para garantir que funcionam conforme esperado. A razão para realizar testes de caixa preta é que, sem um conhecimento aprofundado do desenho do software, o testador abordará o software com expectativas semelhantes às do utilizador final. 

Alguns benefícios dos testes de caixa preta são:

  • Os testadores não precisam de muitos conhecimentos de linguagens de programação, porque utilizam o software da perspetiva de um utilizador.
  • Permitem uma análise imparcial do software, porque o teste de software é realizado pela equipa de QA e não pelos programadores do software.
  • Os testadores não precisam de acompanhar o desenvolvimento dos sistemas de software, o que significa que é necessário muito pouco tempo de preparação antes de os testes poderem ser realizados.

Leitura relacionada: As 10 melhores ferramentas de testes de caixa preta

2. Testes de caixa branca

Nos testes de caixa branca, o membro da equipa de QA compreende totalmente a estrutura interna e o desenho do software que está a ser testado. Abordará o teste como um inspetor, garantindo que todas as partes do programa estão a funcionar corretamente. Os testes de caixa branca são por vezes designados por testes de caixa transparente, porque o testador observa as interações entre as unidades enquanto testa o software. Ao contrário dos testes de caixa preta, um testador de caixa branca não está tão preocupado com a experiência do utilizador. 

Alguns benefícios dos testes de caixa branca são:

  • Os testes podem ser realizados nas primeiras fases do desenvolvimento. A interface gráfica do utilizador (GUI) não tem de estar totalmente funcional. 
  • Os testes são mais completos e deliberados do que os testes de caixa preta.

No exemplo de Pulp Fiction, o testador de caixa branca é a personagem interpretada por Tim Roth, a olhar diretamente para o que está dentro da mala. 

3. Testes de caixa cinzenta

Nos testes de caixa cinzenta, o testador tem alguns conhecimentos sobre a estrutura interna e o desenho do software (caixa branca), mas continua a testar da perspetiva de um utilizador final (caixa preta). Foi assim que nasceram os testes de caixa cinzenta. Nos testes de caixa cinzenta, o desenho do teste é desenvolvido através da análise da estrutura interna do software, enquanto o teste propriamente dito é realizado utilizando a interface do utilizador.

Mais uma vez, se esta fosse aquela famosa cena de Pulp Fiction, o testador de caixa cinzenta não seria nem o público nem Tim Roth. Desta vez, o testador seria o próprio Quentin Tarintino.  

4. Testes automatizados

Os testes automatizados utilizam software para realizar tarefas sem instruções manuais de um testador.

Nos testes manuais, o testador escreve o código que pretende executar ou planeia o percurso no software que quer verificar se está a funcionar corretamente. Os testes automatizados tratam dessas tarefas em nome dos testadores. Eis uma lista breve de ferramentas de software automatizado e de QA que os analistas de QA devem conhecer:

Para uma análise mais aprofundada das ferramentas de testes automatizados, consulte a lista das melhores ferramentas de testes automatizados que deve utilizar.

5. Testes unitários

Ferramentas de testes unitários garantem que cada parte individual do software funciona corretamente. É extremamente importante garantir que os testes unitários são realizados corretamente; caso contrário, a equipa de desenvolvimento sofrerá um grande revés quando descobrir mais tarde que uma parte essencial do software não funciona. 

6. Testes de regressão

As ferramentas de testes de regressão executam testes antigos em novas versões para garantir que o software continua a funcionar conforme previsto. A execução de testes de regressão protege os programadores contra efeitos latentes, garantindo que uma alteração no software no ponto A não danificou acidentalmente algo muito mais adiante, no ponto D. 

Para um analista de QA, dois passos em frente e um passo atrás não devem ser vistos como algo negativo. Ao dar um passo atrás de vez em quando, garante que não está prestes a dar cinquenta passos atrás mais tarde.

7. Testes exploratórios

Os testes exploratórios destinam-se a pessoas que não gostam de planear. Na maioria das outras situações, o caso de teste é cuidadosamente planeado antes de ser executado. Aqui não. Quando um testador realiza um teste exploratório, explora o software sem qualquer plano predefinido, utilizando ferramentas especializadas de testes exploratórios.

A vantagem dos testes exploratórios é permitirem que o testador se adapte imediatamente às suas descobertas, sem ter de escrever outro caso de teste. Os testes exploratórios também permitem a colaboração, a criação de teorias e a experimentação, tudo no momento.

À medida que a teoria ágil de desenvolvimento se tornou mais proeminente, o mesmo aconteceu com os testes exploratórios. Ao permitir que os testadores de QA utilizem a sua intuição, são detetados muitos erros interessantes que uma execução de testes tradicional talvez não procurasse. 

Atenção: os testes exploratórios podem exigir uma grande dose de criatividade. 

More Articles

8. Testes funcionais

Os testes funcionais são realizados para garantir que o software do sistema corresponde aos requisitos do projeto definidos antes do início do desenvolvimento.

O testador de software verificará se as suas entradas correspondem ao resultado esperado. São realizados durante uma das últimas fases dos testes, quer nos testes do sistema quer nos testes de aceitação, e constituem exclusivamente uma forma de testes de caixa negra, uma vez que não se preocupam com o funcionamento do software, desde que este funcione. 

9. Testes de usabilidade

Os testadores de usabilidade garantem que as escolhas de conceção são funcionais e, ao mesmo tempo, intuitivas.

Se prevê que muitos utilizadores do seu software quererão fazer uma cópia de segurança dos seus documentos a cada meia hora, é melhor ter a função de cópia de segurança num local facilmente acessível, em vez de a ter escondida atrás de quatro submenus. 

Em muitas ocasiões, foi desenvolvido software que funciona na perfeição e satisfaz uma necessidade importante do mercado, mas que é completamente impossível de navegar do ponto de vista do utilizador. Isto pode ser explicado pela falta de testes de usabilidade durante a fase de testes do software.

No fim de contas, por muito bom que um software seja do ponto de vista técnico, será difícil encontrar um mercado se os utilizadores não gostarem de o utilizar.

Quer mais?

A indústria dos testes de software está sempre a mudar, e os analistas de QA precisam de se manter atualizados sobre as tendências atuais. Existem inúmeros recursos sobre testes de software, incluindo podcasts, livros, boletins informativos e muito mais.

Subscreva o boletim informativo do The CTO Club para receber atualizações sobre produtos, análises de ferramentas e mais compilações de recursos.

Jason Boog
Over his 15-year career, Jason Boog has worked as a QA tester, QA analyst, and Senior QA Analyst on video games, commercial sites, and interactive web applications. He spent more than a decade building out the QA team and process as Director of Quality & Client Support at a full-service digital agency.
Follow the author:

You may also like