Este artigo apresenta uma introdução aos conceitos de Testes Funcionais de Software durante o processo de validação e medição da qualidade do produto desenvolvido. Sendo assim, o artigo serve para apresentar o conceito de qualidade e demonstrar como métodos de Testes de software, utilizados no processo de desenvolvimento, podem auxiliar na validação e medição da qualidade do produto.

Na elaboração de um padrão de validação onde constantemente seja necessária a validação do desenvolvimento realizado, e testes complexos que exigem grande esforço da equipe de desenvolvimento.


Guia do artigo:

Os testes funcionais permitem que os testes ocorram de uma forma mais eficiente e rápida, possibilitando encontrar as não conformidades do software em relação aos requisitos do sistema. O presente artigo cita os principais conceitos dos Testes Funcionais de Software e apresenta alguns detalhes extraídos de sua forma de implementação.

Atualmente os softwares são empregados em todos os seguimentos da sociedade, tanto para sistemas cujos requisitos sejam simples quanto para aplicações sofisticadas e de grande complexidade. Um exemplo de sistema complexo são os softwares de uso exclusivo para a área de medicina.

Com a ampla utilização das tecnologias da informação, a qualidade do produto tem se tornado imprescindível nos processos de desenvolvimento de aplicações e no momento de avaliação do projeto. O teste de software, cujo objetivo é revelar a presença de defeitos e aumentar a confiança sobre o software, é considerado um elemento crítico para a garantia da qualidade do produto.

As atividades de testes podem muitas vezes se tornar exaustivas e trabalhosas, dificultando assim a execução dos testes de forma adequada para a análise de qualidade. Com o objetivo de melhorar a qualidade da análise e o tempo de execução dos testes, foram criados os testes automatizados, que proporcionam a execução dos testes mais rapidamente, e com maior cobertura do software.

De acordo com Pressman, autor do livro Engenharia de Software, o principal objetivo dos testes de software é a localização de erros, falhas, defeitos (ler Nota 1) e a verificação das funcionalidades do software em desenvolvimento ou finalizado.

Através do processo de testes, busca-se avaliar se estas funcionalidades estão aparentemente trabalhando de acordo com as especificações e requisitos do projeto, garantindo que o software atinja o nível de qualidade esperada pelos interessados no produto.

Nota 1. Defeito, Erro e Falha

Defeito é uma deficiência mecânica ou algorítmica (deficiência no código) que se ativada pode levar a uma falha.

Erro é um estado de execução que impede o software de continuar, pode ser causado por algo externo ao software ou falhas na grafia do código fontes, tais como ausência de ponto-e-virgula e parâmetros.

Uma Falha é um evento notável onde o sistema viola suas especificações, é a existência aparente de um defeito.

Princípios dos Testes

Segundo Brunelli, os componentes essenciais para o teste de software de um programa podem ser divididos em:

  • Executável do programa (código do programa compilado);
  • Relação dos comportamentos esperados;
  • Apresentação do mecanismo de avaliação dos comportamentos esperados;
  • Descrição das funções;
  • Descrição de como observar se uma ação resultou na execução esperada.

O levantamento dos comportamentos esperados é considerado uma das maiores dificuldades na elaboração dos testes, portando sua elaboração deve ser feito de forma cautelosa e de acordo com os requisitos do sistema. Isso se deve ao fato de que os comportamentos do software nem sempre são previstos na etapa de levantamento de requisitos, sendo necessária a posterior elaboração da lista de comportamentos esperados versus funções requeridas.

Segundo Sommerville, um caso de teste bem elaborado possibilita a identificação e solução de erros inéditos, tornando seu processo muito mais eficiente.

Enfim, os testes de software visam mostrar aos clientes, através da exibição de erros detectados, que o software está funcional de acordo com as especificações propostas e requisitos desejados.

O processo de testes

O Processo de Teste, como qualquer outro processo, necessita ser refinado continuamente, permitindo seu amadurecimento, de maneira a ampliar sua atuação e permitir aos envolvidos no projeto uma maior visibilidade e organização dos seus trabalhos. O que se deseja nesta etapa é uma maior agilidade e controle operacional dos projetos de testes.

Realizar testes de software é uma tarefa bastante complexa quando se desconhece o que é qualidade. Nas indústrias automobilísticas, como é o caso da maioria das grandes indústrias, qualidade está intimamente associada a custo de retrabalho.

No início da década de 60, por volta do ano de 1962, foi criado no Brasil um comitê específico para trabalhar a normalização destas regras visando sua implantação nas empresas. A qualidade, muitas vezes associada a certificações como ISO 9001, CMMI e tantas outras que existem por aí, não passam de formalizações de boas práticas que com o passar do tempo foram aperfeiçoadas e implementadas de forma comum.

O processo de Testes de Software deve contemplar, além de um roteiro com objetivos bastante claros, a declaração dos itens a serem avaliados e quais são os índices esperados, como por exemplo, defeitos por número de funções.

Na área de Engenharia de Software, desde Roger Pressman e seu livro Engenharia de Software, que inclusive é uma das referências deste artigo, muitas companhias passaram a compreender que qualidade apenas pode ser obtida com auditoria do processo e certificação dos itens que possuem maior impacto no resultado do produto.

Falando especificamente de Testes, podemos citar como principais técnicas:

  • Teste Funcional;
  • Teste Estrutural;
  • Teste Baseado em Falha ou Erro;
  • Teste de Caixa Branca;
  • Teste de Regressão.

Veremos agora cada uma destas técnicas e quais as suas particularidades.

Teste funcional

O teste funcional, que também é conhecido como teste “caixa - preta”, são os testes definidos de acordo com os requisitos funcionais do software. Como não há conhecimento sobre a operação interna do programa, o analista concentra-se nas funções que o software contemplará. Baseado na especificação determina-se as saídas que são esperadas para um determinado conjunto de dados.

Esse tipo de teste reflete a ótica do usuário, o stakeholder (ler Nota 2) interessado em utilizar o programa, sem levar em conta os detalhes de sua construção. Comparado a outros modelos, sua concepção é relativamente simples.

Nota 2. Stakeholder

Os interessados em um projeto (stakeholders) são todas as pessoas da organização que têm algum tipo de envolvimento direto ou indireto com o sistema, como usuários, gerentes, clientes, patronos e financiadores.

Segundo Koscianski, o teste é particularmente útil para revelar problemas como:

  • Funções incorretas ou omitidas;
  • Erros de interface;
  • Erros de comportamento ou desempenho;
  • Erros de iniciação e término.

A principal técnica utilizada nos testes funcionais é a de particionamento de equivalência, que visa uma divisão em subconjuntos das entradas de valores de acordo com as funcionalidades do software, por exemplo, a inserção de uma massa dados para validar o processo de inserção. Seu principio é a escolha da melhor abordagem a ser utilizada e a melhor maneira de se obter a validação dos erros e aumento da confiabilidade (BRUNELI, 2006). Uma maneira muito eficaz é analisar os dados resultantes e melhorar validações e verificações de entrada.

Além da técnica de particionamento de equivalência, existem diversas outras técnicas que podem ser adotadas como a de Análise do valor limite, Grafo Causa-Efeito e Error-Guessing.

Teste estrutural

O Teste estrutural, também conhecido como teste “caixa – branca” ou teste “caixa–de–vidro” ou ainda teste “caixa–clara”, são os projetos de casos de testes onde seus testes são desenvolvidos a partir dos conceitos de implementação do software e da estrutura desenvolvida.

Os testes caixa–branca possibilitam avaliar a estrutura interna do programa, sua codificação, módulos, implementação e execução particionada do software, sendo que as informações obtidas deste processo de validação também são utilizadas para a criação dos casos de testes.

Em geral, existem diversos critérios para a elaboração dos testes estruturais, representados com o apoio dos Grafos de Fluxo de Controle ou Grafos de Programa (ver Figura 1), demonstrando de maneira clara o fluxo lógico da execução do programa. Os critérios dos testes estruturais podem ser destacados como: Critérios Baseados em Fluxo de Controle, Critérios Baseados na Complexidade e Critérios Baseados no Fluxo de Controle.

  • Critérios Baseados em Fluxo de Controle: Segue de acordo com as características de execução do programa (comandos e desvios). Para elaboração da lista de verificação são utilizados critérios como:
    • Todos – Nós, método que exige que cada comando da aplicação seja executado pelo menos uma vez, passando por cada vértice do grafo (ler Nota 3);
    • Todos – Arcos (ler Nota 4), método que requer que cada aresta do grafo seja executada pelo menos uma vez; e
    • Todos – Caminhos, que requer que todos os caminhos possíveis do programa sejam executados, criando assim um teste completo, dado o grande numero de possibilidades existentes.
  • Nota 3. Nós

    É construído através do código-fonte, onde os seus comandos são os nós do Grafo, ou seja, são os pontos do grafo, seguindo a sequência dos comandos (VILELA c, 2005).

    Nota 4. Arcos

    São os desvios que ocorrem no código-fonte do programa, as linhas que ligam os nós, ou seja, a transferência de controle entre os blocos (VILELA c, 2005).

  • Critérios Baseados na Complexidade: São criados a partir dos requisitos de testes e classificados de acordo com o seu grau de complexidade. Um dos critérios que são utilizados é o Critério de McCabe, que visa a execução do programa através de conjuntos lineares independentes, estabelecendo um número de caminhos linearmente independentes do programa. Ou seja, caminhos que introduzam pelo menos um novo conjunto de instruções de processamento ou uma nova condição, utilizando o conceito da complexidade ciclomática (ler Nota 5) para os requisitos de teste;
  • Critérios Baseados no Fluxo de dados: Utiliza informações do fluxo de dados do programa para a criação dos requisitos dos testes. Incluem critérios de adequação de controle de fluxo, que analisam o grafo de execução de um programa; critérios de adequação baseados no fluxo de dados, que analisam os caminhos que o código percorre entre a inicialização dos dados e os pontos onde são alterados e lidos; e critérios de adequação baseados em uma combinação dos dois tipos, que usam relações de dependência entre os comandos e os seus dados operandos.

Como foi dito, na identificação dos caminhos que devem ser testados pode-se utilizar a técnica Complexidade Ciclomática. Através dela é possível fazer a identificação da quantidade de testes necessários (ver Figura 1) garantindo que todas as instruções sejam executadas ao menos uma vez.

Nota 5. Complexidade Ciclomática

Técnica utilizada para avaliação da complexidade de altorítmos. A fórmula utilizada no cálculo da Complexidade Ciclomática é CC = Número de arcos – Número de nós + 2, e Server para determinar a quantidade de casos de teste mínima para testar os caminhos independentes do programa.

Exemplo de Grafo de Fluxo (VILELA C,2005)
Figura 1. Exemplo de Grafo de Fluxo (VILELA C,2005).

A Figura 1 apresenta um exemplo de Grafo de Fluxo demonstrando, com a ajuda da complexidade ciclomática, o código implementado, onde são separados os estados de acordo com as decisões do programa e obedecendo a sua ordem no decorrer da execução do software. A utilização destes Grafos auxilia na criação dos casos de testes.

Testes baseados em falha ou erro

Os Testes Baseados em Erros e Falhas são criados a partir das informações dos erros mais comuns que os desenvolvedores cometem no processo de desenvolvimento, formando uma base de conhecimento que auxilia na criação dos novos casos de testes.

Para o desenvolvimento dos casos de testes, existem algumas técnicas que podem ser empregadas, como: Semeadura de Erros e Análise de Mutantes.

No critério de Semeadura de Erros são inseridos artificialmente no programa alguns erros. Após estas inserções são analisados os erros encontrados e verificados quais são erros prováveis e improváveis, descartando apenas aqueles que foram propositalmente inseridos para avaliarmos o comportamento da execução. Através do conceito de probabilidade pode se chegar à quantidade provável de erros naturais que podem conter no software.

No critério de Análise de Mutantes são criados programas com pequenas alterações em cima daquele software que será testado. O objetivo é avaliar a quantidade de testes necessários para o software em questão

Na Análise de Mutantes o foco é encontrar casos de testes capazes de revelar diferenças de comportamentos entre o software original e os softwares cujos trechos foram modificados, ou seja, nos softwares mutantes. Ao final, os resultados obtidos da versão original são comparados com a versão modificada.

Os tipos de critérios existentes na Análise de Mutantes são a Mutação Fraca e a Mutação Firme. Na Mutação Fraca cria-se o mutante inicialmente, antes do início da execução e após seu término quando os dados são comparados. Na Mutação Firme são realizadas alterações no programa para a criação do programa mutante, sendo que as comparações acontecem desde o início até o término da execução.

Testes de regressão

Essa é uma técnica de teste aplicável a uma nova versão de software ou a uma versão em desenvolvimento. Ela consiste em aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.

Projeto de casos de testes

O projeto de casos de testes define as situações que serão utilizadas como base tanto para validar os requisitos funcionais quanto para avaliar a eficácia dos componentes.

No projeto de casos de testes são descritas suas entradas e saídas (ver Nota 6), de acordo com cada característica do software, visando os requisitos e especificações do projeto. Os casos de testes são elaborados para exercitar adequadamente as estruturas do programa.

Nota 6. Entradas e Saídas

Dado de Entrada – Conjunto de todos os valores que podem ser usados como entrada para um programa.

Dado de Saída – Conjunto de valores que podem ser obtidos como saídas do programa.

Os casos de teste podem ser utilizados em diversos seguimentos. Segundo Sommerville, os principais são:

  • Na criação e implementação de esquemas de scripts de testes, fornecendo os pontos–chaves de acordo com as implementações dos requisitos no momento da codificação do software;
  • Utilização de scripts para identificação dos melhores testes, tanto para testes manuais quanto para testes automáticos;
  • Um controle dos números de teste específicos para abranger todo o software.

Fases de teste

Os testes de software possuem estratégias que são utilizadas na execução dos testes, e podem ser divididos em etapas como: Teste de Unidade, Teste de Integração, Teste de Componentes, Teste de Validação e Teste de Sistema.

As estratégias de testes permitem a verificação dos erros nos diversos tipos de software, possibilitando uma maior cobertura do software de acordo com o nível do teste, podendo ocorrer em baixo nível ou em alto nível. Os testes de baixo nível focam uma funcionalidade específica que se deseja testar, enquanto os testes de alto nível têm o objetivo de verificar as funções do software de acordo com os requisitos do sistema.

Teste de unidade

O teste de unidade é a fase de teste que tem como finalidade testar individualmente as funcionalidades do software em questão, garantindo que todas as funcionalidades do software sejam testadas pelo menos uma vez.

Uma das desvantagens do teste de unidade é que sua implementação é exaustiva e necessita de prazos maiores para realização, sendo que para a realização dos testes deve-se conhecer os objetivos e especificações dos requisitos de cada uma das funcionalidades do software. Por outro lado, sua vantagem é a localização e prevenção de falhas por estar testando cada uma das funcionalidades individualmente.

Teste de integração

O teste de integração é a fase que testa a integração dos componentes do sistema, se estão de acordo com os requisitos do software, levando em consideração a sua funcionalidade em conjunto e não as suas regras de negócios, procurando assim erros associados a interfaces. O teste de integração pode ser dividido em dois tipos:

  • Não Incremental: Os módulos do sistema são interligados e combinados, e o software é testado como um todo, dificultando a localização dos erros e a correção dos erros encontrados;
  • Incremental: O software é testado em partes, possibilitando que as interfaces sejam testadas de forma incremental, facilitando encontrar erros e isolá-los para correção. O teste incremental possui duas estratégias:
    • Integração descendente (top-down), onde os módulos do sistema são integrados de cima para baixo de acordo com a hierarquia de controle do software; e
    • Integração ascendente (bottom-up), onde a construção e os testes dos módulos são iniciados da parte mais baixa da estrutura do software.

Teste de componentes

No teste de componentes os componentes do software são testados separadamente de acordo com a especificação e estrutura das funcionalidades. Estes componentes são as integrações de interface e unidades do software, com diversas classes no seu desenvolvimento.

Teste de validação

O teste de validação tem como objetivo avaliar se o sistema desenvolvido funciona de maneira que atenda a todas as especificações dos requisitos do software e o processo de regras de negócios estabelecidas na sua elaboração.

Teste de sistema

O teste de sistema é realizado após o sistema estar pronto, sendo avaliados todos os componentes e funcionalidades. O objetivo do teste de sistema é exercitar todo o software, assegurando que todos os elementos que compõem o sistema estão de acordo com as especificações dos requisitos, incluindo todos os itens de hardware e software que compõem a regra de negócio. Existem vários tipos de teste de sistema, tais como: Teste de Desempenho (agilidade), Teste de Segurança (confiabilidade), Teste de Recuperação (recuperação de dados) e Teste de Inicialização (inserção).

Testes automatizados

Os testes automatizados são desenvolvidos como programas ou scripts que têm como principal objetivo exercitar o sistema, testando as funcionalidades e verificando se estão de acordo com as especificações dos requisitos do sistema e os objetivos esperados.

Existem diversas vantagens para a utilização dos testes automatizados, dentre elas destacam-se:

  • Menor tempo na execução dos testes;
  • Verificação do sistema durante o processo de desenvolvimento;
  • Alcançar melhor qualidade do software;
  • Casos de testes mais elaborados.

A grande vantagem dos testes automatizados é que podem ser repetidos a qualquer momento, seja em uma nova funcionalidade ou alguma modificação em uma funcionalidade específica. Sua implementação reduz os esforços e o tempo gasto, reduzindo as chances de que ocorram falhas humanas na execução dos testes.

Os testes automatizados reduzem o tempo no processo de testes, porém, precisa ser complementado por outros tipos de testes.

Conclusão

A utilização de testes ao longo do projeto de desenvolvimento e implementação do software permite que tenhamos uma ampla visão sobre o comportamento do mesmo, eliminando falhas e erros que poderiam causar divergência em seu funcionamento. Como foi apresentado, um plano de testes possibilita encontrarmos as não conformidades do software em relação aos requisitos do sistema e resolve-las de uma forma rápida e eficaz.

Vimos que existem várias maneiras de se aplicar Testes em um projeto de desenvolvimento, e que todas possuem o mesmo objetivo: reduzir a chance de entregarmos software contendo defeitos para o cliente.

Confira também

Referências Bibliográficas

1. BERNARDO, Paulo C.; KON, Fabio, A importância dos Testes Automatizados. Artigo Revista Engenharia de Software Magazine, página 54-57, 2008.

2. BRUNELI, Marcus V. Q., A utilização de uma metodologia de Teste no processo de melhoria da Qualidade de Software. Dissertação de Mestrado, Unicamp, Campinas, São Paulo, Fevereiro, 2006.

3. CARDOSO, Josiane Ap., Um método de Testes de Integração para Sistemas Baseados em Componentes. Dissertação de Mestrado, Unicamp, Campinas, São Paulo, Fevereiro, 2006.

4. CORTE, Camila K. D., Ensino integrado de fundamentos de Programação e Teste de Software. Dissertação de Mestrado, ICMC – USP, São Carlos – São Paulo, Maio, 2006.

5. JINO, Mário; MALDONADO, José C.; DELAMARO, Márcio E. , Introdução ao Teste de Software. São Paulo: Campus Elsevier, 2007.

6. KOSCIANSKI, André; SOARES, Michel dos Santos, Qualidade Software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de sofwares. 2ª ed. São Paulo: Novatec Editora, 2007.

7. PFLEEGER, Shari L. Engenharia de Software: Teoria e Prática. 2ª ed. São Paulo: Pearson Prentice Hall Brasil, 2004.

8. PRESSMAN, Roger S. Engenharia de Software. São Paulo: Pearson Makron Books, 1995.

9. RICARTE, Ivan L. M., Teste de Software Orientado a Objetos. Campinas, São Paulo, DCA – FEEC – Unicamp, 2006, Notas de Aula.

10. SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson Education Brasil, 2007.

11. VILELA, Plínio, Introdução ao teste de Software. Piracicaba, São Paulo, Unimep, 2005, Notas de Aula. (A)

12. VILELA, Plínio, Teste de Software: Técnicas Estruturais. Piracicaba, São Paulo, Unimep , 2005, Notas de Aula. (B)

13. VILELA, Plínio, Teste de Software: Técnicas Funcionais. Piracicaba, São Paulo, Unimep , 2005, Notas de Aula. (C)

14. VINCENZI, Auri M. R., Subsídios para Estabelecimento de Estratégias de Teste Baseado na Técnica de Mutação. Dissertação de Mestrado. USP, São Carlos – SP, 1998. (SCAMPI) A, Version 1.2: Method Definition Document, Carnegie Mellon University, (2006b)

15. ZHU, Hong; HALL ,Patrick A. V. ; MAY, John H. R. - Software Unit Test Coverage and Adequacy - ACM Computing Surveys, 29 (4). ISSN 0360-0300, pp. 366–427. New York, NY, USA - December 1997.