Níveis de Teste

Durante o ciclo de vida do desenvolvimento de um software, as atividades de teste serão executadas em diferentes níveis, visando verificar o sistema como um todo ou apenas partes dele. Estes testes podem derivar dos requisitos e especificações, de artefatos de projeto ou ainda do código-fonte. Independente do processo adotado, podemos dividir os níveis de teste em: Unidade, Integração e Sistema. Pressman (2015) propõe uma visão procedural em 3 partes dos níveis de teste, demonstrado aqui na figura abaixo.

Teste de Unidade

Inicialmente, os testes são focados em componentes individualmente, para garantir que esses cumpram seus propósitos independente de outros componentes do mesmo software. Do fato de testar pequenas unidades do software, vem o termo Teste de Unidade. Em IEEE 1008-1987 (1986), Teste de Unidade é definido como "um processo que inclui o planejamento de testes, a aquisição de um conjunto de testes e a medição de uma unidade de teste em relação a seus requisitos".

Essa atividade faz uso de técnicas que executam caminhos específicos do código-fonte, com o intuito de garantir que os testes cubram completamente (ou boa parte) das possibilidades de execução, provendo assim uma taxa de detecção de erros maior (PRESSMAN, 2015).

Teste de Integração

Mesmo que os componentes funcionem independentemente, eles podem não funcionar ao serem colocados para execução em conjunto, sendo necessário testar a integração entre eles, para garantir que suas interfaces se comunicam corretamente (AMMANN; OFFUTT, 2008). Teste de Integração visa expôr os problemas que podem surgir nessa etapa do desenvolvimento de um software.

Teste de Alta Ordem

Por fim, os testes de alta ordem buscam validar o software em um contexto mais amplo. Ao invés de checar as funções do programa, esse passo tem como propósito verificar se o software, já completo, atende aos seus objetivos definidos (MYERS et al., 2011; AMMANN; OFFUTT, 2008). Pressman (2015) divide essa etapa em Teste de Aceitação e Teste de Sistema. O Teste de Sistema visa verificar se o sistema como um todo, após construído, atende as suas especificações, enquanto o Teste de Aceitação visa checar se o que o sistema entrega está de acordo com as expectativas do usuário final.

Considerações finais

Falhas em um produto de software – mesmo os mais simples – podem custar caro, muitas das vezes até mais do que o custo empregado nas atividades de teste durante o processo de desenvolvimento. Desse modo, as prioridades de uma equipe de desenvolvimento deve ser em entregar software confiável e com a menor quantidade de bugs possível (HAYES, 2004). Muitos dos esforços dedicados a testes de software visam automatizar o máximo possível desse processo para torná-lo mais barato, rápido e confiável (BARR et al., 2014).

Cada um dos níveis de teste serão detalhados nos módulos seguintes, quando passaremos a explorar o uso de ferramentas e bibliotecas para construção e execução de testes automatizados.

Referências

BERTOLINO, A.; MARCHETTI, E. A brief essay on software testing. Software Engineering, 3rd edn. Development process, v. 1, p. 393–411, 2005.

AMMANN, P.; OFFUTT, J. Introduction to Software Testing. 1. ed. New York, NY, USA: Cambridge University Press, 2008. ISBN 0521880386, 9780521880381.

PRESSMAN, R. S. Software engineering: A practitioner’s approach. [S.l.]: McGraw-Hill Education, 2015.

IEEE 1008-1987. IEEE Standard for Software Unit Testing. IEEE, 1986. Disponível em: <https://doi.org/10.1109/ieeestd.1986.81001>.

MYERS, G. J.; SANDLER, C.; BADGETT, T. The Art of Software Testing. 3rd. ed. [S.l.]: Wiley Publishing, 2011. ISBN 1118031962, 9781118031964.

HAYES, L. G. Automated Testing Handbook. [S.l.]: Software Testing Inst, 2004. ISBN 0970746504.

BARR, E. T.; HARMAN, M.; MCMINN, P.; SHAHBAZ, M.; YOO, S. The Oracle Problem in Software Testing : A Survey. p. 1–30, 2014.