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

Testes no RUP (Parte 2)

Em muitas organizações, os testes começam muito tarde no processo de desenvolvimento de um software. Muitas vezes, começam tão tarde que o produto é lançado com uma quantidade irrisória de testes executados. Para solucionar esse problema, muitas empresas estão começando a adotar testes como um 'mal necessário'. Como contraste a esse panorama, o RUP modifica a abordagem de testes, distribuindo a mesma no decorrer do ciclo de desenvolvimento do software, agregando valor ao invés de arcar com custos excessivos decorrentes da ausência de testes. No post anterior , justificamos a pergunta 'por que testar cedo e com frequência?' com o gráfico de custos. A seguir vocês podem ver um gráfico similar, retirado do site da IBM (detentora da metodologia RUP): Muitas pessoas ainda veem a disciplina de Testes como algo secundário, por que isso acontece? Talvez porque não esteja diretamente ligado ao desenvolvimento do software e por isso é muitas vezes deixado para o final, depois do

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

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