Pular para o conteúdo principal

Níveis de Testes - Parte 1: Testes Unitários

Durante o ciclo de vida de um software, podemos citar como os quatro principais níveis de testes:

1. Testes Unitários
2. Testes de Integração
3. Testes de Sistema
4. Testes de Aceitação

Nesse post vamos falar sobre o item 1 (Testes Unitários) e nos demais posts seguiremos com os demais itens.

1. Testes Unitários ou Testes de Unidade

Em programação de computadores, teste de unidade ou teste unitário é um método de teste que verifica se as unidades individuais do código-fonte de um software estão funcionando corretamente. Uma unidade é a menor parte de uma aplicação onde pode-se aplicar testes. Em programação orientada a objetos, podemos considerar um método como a menor unidade. Já em programação procedural, podemos considerar como uma unidade, um programa, uma função, um procedimento.

Testes unitários são tipicamente feito pelos próprios desenvolvedores para garantir que o código que outros desenvolvedores escreveram atende aos requerimentos do software e comporta-se da maneira que o desenvolvedor projetou.



O objetivo dos testes unitários é isolar cada parte do programa e mostrar que tais partes estão corretas. Testes unitários encontram problemas mais cedo no ciclo de desenvolvimento do software.

Uma vantagem dos testes unitários é a documentação que é gerada por esse tipo de teste. Tal documentação servirá para futuros testes assim como para novo desenvolvedores entenderem isoladamente o que cada unidade do software faz.

Porém, os testes unitários não são capazes de detectar todos os erros de um programa, pois só testam a funcionalidade de unidades específicas. Testes unitários não são capazes de detectar erro de integração entre as unidades.

O conceito de teste unitário é facilmente confundido com o conceito de debug. Porém, não são a mesma coisa. Debug é a tarefa utilizada em algumas poucas linhas de código para detectar porque tal código não está funcionando como o desenvolvedor planejou. Por exemplo: porque a variável X não está adquirindo determinado valor num loop For. Já o teste unitário busca erros em unidades de teste que a princípio estão funcionando corretamente. Testes unitários estão diretamente relacionados a requerimentos, boas práticas em programação, além de buscarem erros de escopo.

Existem ferramentas que auxiliam na construção, execução e documentação de testes unitários, dentre elas podemos citar como o mais 'famoso' o JUnit. A seguir um link com uma lista de ferramentas para testes unitários:

http://www.testingfaqs.org/t-unit.html

Nos próximos posts daremos continuidade aos níveis de teste no ciclo de vida de um software.

Até a próxima!

Comentários

Postagens mais visitadas deste blog

FURPS

Olá! Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software : Vamos começar pela sigla FURPS: o que significa cada uma dessas letras? Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema. Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário. Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema. Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema. Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema. As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não ante...

O + do FURPS+

Segue a continuação do assunto FURPS: Posteriormente à definição do modelo FURPS, notou-se a necessidade da inclusão de mais atributos para encorpar e aumentar a cobertura do modelo. A partir dessa extensão, o acrônimo passou a ser mais comumente chamado de FURPS+ . Quais são os atributos do “+”? O + do FURPS refere-se a especificação de restrições que definirão determinados limites que deverão ser atendidos quando construímos um sistema. O + é composto dos seguintes requisitos não-funcionais: Design constraints – restrições de design: design nesse caso refere-se ao projeto, diretrizes e não a layout. A definição da utilização um banco de dados relacional no projeto é uma restrição de design, por exemplo. Implementation constraints – restrições de implementação: relacionado a limites impostos a código e construções. Como exemplo podemos citar a linguagem de programação que será utilizada para a codificação de um sistema. Interface constraints – restrições de interface: diretamente l...

Testes no RUP (Parte 1)

Nesse post, falarei sobre a disciplina de Testes dentro do modelo RUP (Rational Unified Process). Antes de abordar a aplicação da disciplina de Testes no RUP, apresento aqui uma visão geral do processo. A seguinte ilustração sobre o RUP é, por si só, bastante elucidativa: (fonte: http://www.devmedia.com.br/) Na imagem acima, temos as fases e as disciplinas que compõem o RUP: Fases: Concepção Elaboração Construção Transição Disciplinas: Modelagem de Negócio Requisitos Análise e Projeto Implementação Testes Implantação Gerência de Configuração e Mudanças Gerência do Projeto Ambiente Como o foco é falar sobre Testes, não entrarei em questões relativas a outras disciplinas. Para outras informações sobre RUP, indico os seguintes links: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf http://www-01.ibm.com/software/rational/ Como nota-se na imagem anterior, a nuvem da disciplina de Testes está presente em cada uma das 4 fa...