Teste de Software

A última etapa do desenvolvimento de um software é a fase de testes. A fase de testes é de fundamental importância, pois através dela é possível detectar e solucionar erros no software. No decorrer de todo o desenvolvimento, atividades de garantia de qualidade do software são executadas, porém, a possibilidade de continuar encontrando erros é enorme, mesmo depois de concluído o desenvolvimento do software.

Segundo Pressman (1995), na fase de testes, os engenheiros executam uma série de atividades que consistem em varrer o software criado a procura de qualquer tipo de erro ou falha na codificação, que possam vir a interferir no correto funcionamento do aplicativo. O teste é responsável por detectar o maior número possível de erros, pois encontrar todos é praticamente impossível. Os testes de software são responsáveis por executar o software utilizando valores reais, com a finalidade de encontrar erros. Caso os testes sejam realizados e nenhuma falha seja descoberta, provavelmente, os casos de testes não foram bem elaborados. Seguindo o raciocínio de Pressman (1995), os casos de testes devem elevar a probabilidade de detecção de erros, caso contrário, os testes não serão bem sucedidos. Pressman (1995) defende ainda que o teste bem sucedido, além de apontar falhas ainda não constatadas, deve fazer isso com o mínimo tempo e esforço.

Os testes são realizados com a inserção de dados atuais para que se possam obter os resultados esperados de acordo com os requisitos e especificações previamente estabelecidos. Se os dados de saída são os esperados, significa que as informações geradas pelo software são legítimas e totalmente confiáveis.

Apesar de todos os esforços exigidos na fase de teste, é comum que o software não funcione completamente sem a ausência de erros. Falhas fazem parte do código de programação, isso muitas vezes acontece devido à complexidade do desenvolvimento de software e da negligência dos desenvolvedores nas fases iniciais da elaboração de um sistema.

Mesmo que os testes, por mais eficazes que sejam, não consigam detectar e remover todos os erros contidos no software, estes são indispensáveis pois aumentam o grau de segurança, e consequentemente, a confiança no produto pelo desenvolvedor e pelo cliente.

Inthurn (2001) afirma que há um gasto frequente muito grande de tempo e dinheiro em correções de software, em que o desenvolvimento não foi adequado e a fase de testes não foi satisfatória. Assim, entende-se que os testes são importantes, também, para evitar surpresas desagradáveis no futuro. Além disso, os testes são responsáveis por mostrar que o software possui erros e que os mesmos devem ser corrigidos, mas isso não significa que a partir das correções, o software estará imune a possíveis falhas posteriores. Novos erros podem ser inseridos ao software no momento em que outros erros são corrigidos, através de alterações realizadas no código a fim de corrigir os erros descobertos até o momento.

De acordo com Inthurn (2001), os testes bem sucedidos conseguem, em média, corrigir aproximadamente 60% das falhas contidas no software. O custo dos testes realizados dentro do processo de desenvolvimento é relativamente pequeno se comparado ao gasto com manutenção corretiva do software pronto, sem mencionar que para, um software ter qualidade, é necessário que haja uma rotina exaustiva de testes, que se estende por todo o desenvolvimento do projeto.

Jamais a atividade de teste deve trabalhar de maneira isolada, mas sim de maneira conjunta com as demais atividades e de forma iterativa. Os casos de teste devem testar as partes produzidas em cada etapa do projeto e o produto completo ao final do projeto. Só assim a qualidade do produto final é garantida. A atividade de testes é dividida de diferentes

maneiras por diversos autores. Por exemplo, segundo Peters (2001), a atividade de testes é constituída das atividades chaves, planos de teste, projetos de teste, casos de teste, procedimentos de teste, execução de teste e relatório de teste.

Já Pressman (1995) divide como técnicas de teste de software e estratégias de teste de software. Segue os estudos das atividades de teste de software focando as definições deste último autor.

Técnicas de teste de software

Segundo Pressman (1995), técnicas de teste de software consistem em elaborar casos de teste capazes de varrer o software a procura de erros ainda não constatados. As atividades de testes não visam culpar alguém por falhas ou, ainda, testar o software com finalidade destrutiva. Os testes são realizados com o objetivo de encontrar as falhas e, posteriormente, corrigi-las, garantindo assim a qualidade do mesmo.

Dentro das atividades de testes todos os resultados obtidos são avaliados, essa avaliação é realizada comparando-se os resultados obtidos com os esperados. Caso sejam encontrados erros, é feita a depuração.

Projeto de casos de teste

Um projeto de teste requer uma atenção especial dos engenheiros, pois os testes a serem realizados devem possuir uma alta probabilidade de descobrir os erros ainda não detectados, em um prazo relativamente curto e com esforços irrelevantes. Outro fato que exige que o projeto seja bem elaborado é a questão dos valores, pois o custo de manutenção para correção de erros após o término do desenvolvimento pode ser de 60 a 100 vezes mais do o custo da manutenção realizada durante o desenvolvimento (PRESSMAN, 1995).

Um software pode ser testado de duas formas. A primeira, quando se conhecem as suas funções e quais as saídas esperadas quando se recebem tais entradas, é popularmente conhecida como teste de caixa preta. E a segunda, quando se conhece a estrutura e o funcionamento interno, a maneira que os métodos estão interligados, quais as responsabilidades de cada um deles, dentre outros detalhes, é chamada de teste de caixa branca.

Segundo Inthurn (2001), um projeto de teste é responsável por gerenciar a fase de teste identificando e descrevendo qual tipo de teste será aplicado em determinado momento. O projeto de teste é dependente de um plano de teste, esse plano mostra as estratégias para a execução do teste com base numa lista de casos de teste.

Plano de teste

Dentre outros objetivos, o plano de teste deve identificar os componentes do software que serão testados e os recursos necessários para a correta execução dos mesmos, recomendando e descrevendo as estratégias de teste a serem aplicadas. O plano de teste deve conter e disponibilizar a documentação referente ao projeto em desenvolvimento, seus requisitos funcionais e não funcionais, a fim de entender o que será testado no software. O plano de teste deve conter as estratégias de teste, pois nela encontra-se a maneira como o teste será realizado e quais técnicas e critérios serão utilizados. Listas contendo os tipos de testes a serem aplicados, ferramentas, recursos de hardware e de pessoas disponíveis também são parte do plano de teste. A cada teste realizado, informações sobre o que foi realizado, data e hora de inicio e fim da atividade, nome do responsável pela mesma e resultados obtidos são registrados (INTHURN, 2001).

Caso de teste

Um caso de teste pode ser definido como um documento que descreve as etapas a serem seguidas para realização de um teste. Desde os dados de entrada, a atividade em execução e o resultado de saída. É utilizado para observar se o resultado de saída é realmente o esperado. Em caso positivo o teste foi realizado com êxito (INTHURN, 2001).

O caso de teste serve para verificar se o sistema segue as definições impostas no projeto e se o mesmo foi devidamente construído. Segundo Bartié (2002), o caso de teste é o documento que registra todo o planejamento dos testes, nele devem ser abordados os seguintes itens:

ƒ identificação das condições de testes;

ƒ identificação do que será testado;

ƒ definição de cada caso de teste identificado;

ƒ detalhamento das classes de dados de entrada;

ƒ detalhamento da saída gerada;

ƒ responsáveis pela atividade de teste;

ƒ definição de como será realizada a bateria de testes;

ƒ cronograma das atividades.

Suíte de teste

É o documento que faz o detalhamento final dos testes, nele é identificado o comportamento de cada caso de teste durante a execução. A suíte de teste estabelece a ordem de execução e a maneira que cada caso de teste irá proceder (BARTIÉ, 2002).

O objetivo do conjunto de teste é auxiliar no exercício de verificar as especificações dos requisitos funcionais e não funcionais do sistema, ou seja, constatar se o sistema procede normalmente durante a execução das funções.

Teste estrutural ou teste de caixa branca

Pressman (1995) define o teste de caixa branca como um método de projeto de casos de testes voltado a testar a estrutura interna do software. O teste de caixa branca, ao contrário de teste de caixa preta, se preocupa em como o código fonte foi construído e a lógica de programação utilizada no desenvolvimento dos métodos. O teste é totalmente realizado na estrutura interna do software (INTHURN, 2001).

O teste estrutural visa confirmar ou se certificar de que a estrutura interna do software esteja correta. Para isso, é preciso que o caso de teste percorra todos os caminhos internos possíveis. A atividade de teste estrutural pode ser considerada complexa porque deve abranger todos os níveis de hierarquia, no caso de classes com herança. O fato de um método funcionar corretamente em uma classe não garante que o mesmo não apresente erros na classe que a herde (INTHURN, 2001).

Teoricamente, um teste de caixa branca seria capaz de avaliar e classificar um software como 100% correto, isso porque o teste de caixa branca percorre todos os caminhos lógicos possíveis, o que resulta num teste exaustivo e complexo, pois mesmo em um programa pequeno, os caminhos lógicos são muitos (PRESSMAN, 1995). O teste de caixa branca, também, pode ser conhecido como testes de caixa de vidro, ou ainda, testes de caixa clara (SOMMERVILLE, 2003).

Bartié (2002) aponta dificuldades em aplicar o teste de caixa branca em alguns casos. O teste de caixa branca deve ser realizado por um profissional competente e extremamente experiente, pois o responsável por aplicar o teste deve conhecer minuciosamente a estrutura do software. O teste será executado pelos próprios desenvolvedores, e como os

desenvolvedores normalmente trabalham sob pressão, o software tem que ficar pronto rapidamente. Este fato faz com que a preocupação do desenvolvedor seja maior com a implementação, de forma que os testes acabam ficam em segundo plano.

Teste funcional ou teste de caixa preta

Segundo Inthurn (2001), o teste de caixa preta consiste em verificar na interface do software se todas as funcionalidades estão operando corretamente. Este teste é aplicado com a finalidade de encontrar: funções incorretas ou ausentes, erros de interface, erros nas estruturas de dados ou no acesso ao banco de dados, erros de desempenho e, ainda, erros de inicialização e término.

O teste funcional, como o próprio nome já diz, é realizado com base nos requisitos funcionais do software, assim, é possível analisar as entradas e saídas de todas as unidades. Para isso os dados de entrada devem ser normalmente aceitos pelo sistema e a saída deve ser a esperada. Caso a saída não seja a esperada, o erro é constatado. Esse tipo de teste não se preocupa em saber como o código fonte foi produzido e sim se o mesmo faz o que lhe foi

especificado.

As técnicas de caixa preta são responsáveis por garantir que todos os requisitos do sistema funcionem de acordo com o especificado durante a elaboração do projeto. Cabe aos testes de caixa preta averiguar que o sistema forneça todos os resultados esperados.

Uma vantagem do teste de caixa preta em relação ao teste de caixa branca é que nesse não é necessário que a equipe de testes conheça ou entenda a estrutura interna, a tecnologia utilizada e a maneira como foi implementado, e sim, que verifique se faz o que foi proposto e se atenderá as necessidades do futuro usuário. No teste de caixa preta o profissional responsável pela execução do teste necessita apenas entender os requisitos e analisar os resultados produzidos (BARTIÉ, 2002).

O teste de caixa preta consiste em validar os requisitos funcionais do sistema, o objetivo é encontrar erros de interface, erros relacionados ao desempenho, ao acesso ao banco de dados, erros de inicialização e término, falha ou ausência de funções (PRESSMAN, 1995).

Este último autor define alguns tipos de teste de caixa preta, entre eles o particionamento da equivalência e análise do valor limite. No primeiro, os dados de entrada são divididos em classes de forma que os casos de teste possam ser derivados. O particionamento de equivalência permite que seja definido um caso de teste capaz de encontrar uma ou mais classes de erros. Um exemplo poderia ser um caso de teste que identifique problemas sempre que um tipo específico de dado é utilizado. O particionamento

de equivalência é normalmente representado por um conjunto de dados de entrada, válidos ou inválidos para o sistema.

Na segunda, análise do valor limite, a intenção do teste é colocar em prova os valores fronteiriços, ou seja, analisar as extremidades do sistema. Difere-se um pouco do particionamento de equivalência porque além de testar os dados de entrada, analisa também os dados de saída. O teste pode ser feito da seguinte forma: se os parâmetros de entrada devem respeitar o intervalo entre 0 e 4, inserir números normais, ou seja, entre 0 e 4, depois um número abaixo do especificado e em seguida um número acima do especificado. Assim, é possível testar se as condições de entrada estão sendo validadas. O mesmo critério deve ser utilizado para analisar dos dados obtidos na saída.

Teste de caminho básico

O teste de caminho básico é conhecido como uma técnica de teste de caixa branca. Através do teste de caminho básico é possível definir os diversos caminhos de execução do software e garantir que cada um deles seja executado ao menos uma vez (PRESSMAN, 1995). O número de caminhos é proporcional ao tamanho e complexidade do software. Devido aos módulos não trabalharem sozinhos, ou seja, são apenas partes de um sistema, fica inviável a utilização dos testes de estrutura. Dessa forma, testes de caminho básico são mais utilizados nos testes de unidade (SOMMERVILLE, 2003).

Antes de executar o teste de caminho básico é importante criar o modelo de representação do trecho de código a ser testado, para facilitar o entendimento do fluxo de controle. Nessa representação são utilizados fluxogramas e grafos. A figura 01 mostra um fluxograma simplificado de um teste de caminho básico.

Fluxograma de um teste do caminho básico

O fluxograma acima pode ser facilmente representado em forma de grafos de fluxo, como mostrado a seguir.

Grafo de fluxo do fluxograma da figura 1.

As linhas do grafo traçam os possíveis caminhos. É importante que a cada laço o teste utilize um caminho independente até que todos os caminhos sejam percorridos. Caminhos independentes são aqueles que executam instruções que ainda não foram executadas (PRESSMAN, 1995).

Para encontrar o número de caminhos independentes é necessário realizar o cálculo da complexidade ciclomática do grafo de fluxo do programa, esse cálculo é feito através da fórmula (SOMMERVILLE, 2003):

CC(G) = Número (ramos) – Número (nós) + 2

sendo as setas correspondentes aos ramos e os círculos correspondentes aos nós, para o grafo de fluxo na figura 02, CC(G) = 11 – 9 + 2 = 4. Quatro é o número de caminhos independentes.

Caminhos independentes:

Caminho 1: 1-11

Caminho 2: 1-2-3-4-5-10-1-11

Caminho 3: 1-2-4-6-8-9-10-1-11

Caminho 4: 1-2-3-6-7-9-10-1-11

Caminho não independente:

Caminho 5: 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

O caminho 5 não é independente porque todas as suas instruções já foram executadas anteriormente, ou seja, não encontrou instruções ainda não executadas.

Pressman (1995) mostra duas outras maneiras de encontrar o número de caminhos independentes, além da fórmula apresentada por Sommerville (2003). Uma é encontrando o número de regiões (fechamento dos nós), que corresponde ao número de caminhos. A outra, o número de nós predicativos (nó que apresenta condicional) mais um corresponde ao número de caminhos independentes. De acordo com o grafo de fluxo:

CC(G) = Ramos – Nós + 2 = 11 – 9 + 2 = 4

CC(G) = Nós predicativos + 1 = 3 + 1 = 4

CC(G) = Regiões = 4

Genericamente, o teste de caminho básico não testa todas as combinações possíveis de todos os caminhos do software, pois, devido ao grande número de laços de repetições existentes, a quantidade de combinações de caminhos é infinita (SOMMERVILLE, 2003).

O teste de caminho básico é simples e eficaz, e ainda pode ser complementado por outros tipos de testes, para, assim, encontrar e corrigir o maior número possível de falhas, são eles o teste de condição, teste de fluxo de dados e o teste de laços (PRESSMAN, 1995).

Teste de condição

O teste de condição é um método de projeto de casos de testes responsável por certificar que todas as condições lógicas de um módulo do programa funcionem corretamente. Uma condição simples pode ser definida como duas expressões aritméticas separadas por um operador relacional (PRESSMAN, 1995):

E1 <operador relacional> E2,

em que E1 e E2 são as expressões aritméticas e o operador relacional sendo qualquer um desses (<, ≤, =, ≠, >, ≥) ou ainda operadores booleanos (OR, AND e NOT). Uma condição composta é definida com a união de duas ou mais condições simples.

O teste de condição consiste em testar cada condição existente no programa à procura de erros. Uma condição é considerada incorreta quando pelo menos um componente da condição está incorreto, ou seja, operadores lógicos ou booleanos ausentes ou a mais. O mesmo acontece com os parênteses, além de erros na própria expressão aritmética ou operador relacional.

Para encontrar erros nos operadores relacionais, três testes são realizados, considerando que as expressões aritméticas estejam corretas, a E1 deve receber valores, maior, menor e igual a E2.

Teste de laços

Normalmente o número de estruturas de repetição, laços ou loops, como são conhecidos, utilizados na implementação de sistemas é muito grande, mesmo em pequenos softwares, isso porque essas estruturas são extremamente necessárias, ou melhor, é inviável a construção de um sistema sem a utilização de estruturas de repetição.

O teste de laços consiste em validar a estrutura dos laços. Existem quatro classes de laços: laços simples, laços concatenados, laços aninhados e laços não-estruturados (PRESSMAN, 1995):

ƒ Laços simples: cinco testes são realizados, 1) não entrando no laço; 2) somente uma passagem pelo laço; 3) duas passagens pelo laço; 4) enquanto m<n passagens pelo laço; e 5) n-1, n, n+1 passagens pelo laço.

Laços aninhados: deve-se testar primeiro o laço interno e iniciar com valores mínimos todos os laços; execute os testes de laços simples no laço interno sem alterar os valores do laço externo; continue realizando testes com valores inaceitáveis. Repita até que todos os laços sejam testados.

Laços concatenados: se os laços foram implementados de maneira individual, um independe do outro, o teste realizado é o mesmo do mostrado anteriormente no laço simples. Se os laços foram implementados de forma que um interaja com outro, ou seja, se o contador do primeiro laço for utilizado como valor inicial para o segundo laço, o teste a ser realizado é o mesmo mostrado anteriormente no laço concatenado.

Laços não-estruturados: para facilitar o teste é necessário reprojetar os grupos de laços de forma que os mesmos se assemelhem à programação estruturada.

Tipos de laços – retirada de (MARIATH, 2004).

Teste unitário

O teste unitário consiste em validar a menor unidade do projeto, uma classe de métodos, funções isoladas e unidades lógicas. A partir disso, testam-se módulos integrados a outros e outros, até que se tenha o sistema completo. O mesmo deve ser realizado diversas

vezes, dia a dia, isso porque as falhas sempre aparecem e fica mais fácil corrigir pequenas falhas do que corrigir o sistema inteiro depois de construído (MEDEIROS, 2005).

Medeiros (2005) afirma que a importância do teste unitário se dá na prevenção de futuros erros no sistema. A única maneira de saber se o código é realmente bom é testando sua reação diante de uma bateria de testes exaustivos, esses testes validam situações normais, que deveriam ser bem sucedidas e situações de erro.

O mesmo autor ainda cita um exemplo do mundo real: pensando na fundamental importância do teste unitário, imagine o resultado dos testes em um avião ou mesmo em um navio apenas após o término de sua construção. Se algo sair errado, os danos podem ser irreparáveis. Nada mais apropriado para descrever o resultado, do que uma tragédia.

Testes de verificação e validação de software

Toda a fase de teste de um software refere-se ao (V&V) ou verificação e validação. A verificação consiste em atividades que garantem que as funções do sistema tenham sido implementadas corretamente, e a validação em verificar que o software corresponde às expectativas do cliente (PRESSMAN, 1995). Segundo Sommerville (2003), os testes de validação ou verificação são responsáveis por constatar se o sistema desenvolvido está realmente de acordo com as especificações fornecidas pelo cliente e se satisfaz as suas necessidades.

Os testes de validação devem evoluir de acordo com o desenvolvimento do software, não sendo executados de maneira isolada, ou seja, sempre que um módulo ou uma classe é desenvolvido, testes são realizados. Os testes são incrementados a cada etapa de desenvolvimento, mais classes e funções implementadas, mais testes realizados.

Para que os erros sejam encontrados no início do processo, resumidamente Sommerville (2003) divide os testes de validação em 5 (cinco) estágios, sendo eles teste de unidade, teste de módulo, teste de subsistema, teste de sistema e teste de aceitação.

Teste de unidade: tem como objetivo averiguar que um componente do sistema está funcionando corretamente, para isso o teste é realizado em cada componente separadamente.

Teste de módulo: num sistema, um módulo corresponde a uma classe, um conjunto de métodos ou funções interligadas, ou seja, dependentes uma da outra. O teste é realizado visando verificar que o módulo todo está funcionando corretamente, se as conexões entre os métodos estão corretas e produzindo o esperado. O teste de módulo, assim como o teste de unidade, é normalmente executado por seus próprios desenvolvedores.

Teste de subsistemas: responsabiliza-se basicamente por testar pequenos conjuntos de módulos integrados, o objetivo é encontrar erros de interface de módulos e suas ligações.

Teste de sistema: o sistema consiste na união coerente dos subsistemas, o teste de sistema, por sua vez, consiste em descobrir possíveis falhas nas interações desses módulos e, ainda, em verificar que todos os requisitos funcionais ou não, estejam presentes.

Teste de aceitação: o teste de aceitação é o último realizado antes da entregado do software ao cliente. O teste é realizado utilizando valores reais vindos dos próprios clientes. O teste de aceitação pode trazer à tona diversos tipos de erros anteriormente não constatados, pois os dados reais criam situações não pensadas pelos desenvolvedores. Através do teste de validação é possível perceber se o sistema é estável e se possui um desempenho que corresponda às expectativas do cliente.

Segundo Inthurn (2001), o teste de sistema se subdivide em quatro outros tipos envolvendo todas as partes do software: Teste de recuperação; teste de segurança; teste de stress; e, por último, teste de desempenho.

Teste de recuperação: consiste em provocar diversos tipos de falhas, o sistema, porém, deve ser capaz de tolerar as mesmas, ou seja, um sistema tolerante a falhas é aquele consegue se recuperar de falhas sem que essas atrapalhem o seu funcionamento. O sistema deve se recuperar das falhas completamente num tempo relativamente pequeno e com o mínimo de intervenção humana. A geração de um log detalhando as atividades realizadas antes das falhas é interessante. Um dos objetivos do teste de recuperação é averiguar a maneira como o sistema se recupera dos erros, os mais comuns são, problemas no disco rígido, erros de interface e falhas referentes à falta de memória.

Teste de segurança: é responsável por verificar se todos os recursos de defesa do sistema realmente impedem os possíveis acessos indevidos. Esse tipo de teste deve ser realizado por uma equipe que não tenha participado do desenvolvimento. O seu objetivo é garantir que o sistema continue funcionando normalmente sob tentativas de acessos não permitidos. O correto é que as políticas de segurança do próprio sistema se encarreguem de protegê-lo desses acessos. Durante a execução dos testes, os responsáveis por ele devem utilizar todos os métodos disponíveis para tentar, de alguma forma, acessar o sistema indevidamente, neste caso, vale conseguir senhas ilegalmente, tentativas de acesso durante o processo de recuperação do sistema, entre outras ocasiões de falhas provocadas pelos próprios testadores.

Teste de stress: é realizado com o objetivo de forçar o sistema, por exemplo, executar várias buscas de dados no disco, abrir o maior número de janelas possível a fim de causar falta de memória. Enquanto isso, deve-se analisar a queda de desempenho do sistema e a maneira como ele se recupera, em caso de parada do sistema durante o processo, mais testes de recuperação devem ser executados.

Teste de desempenho: como o próprio nome já diz, é responsável por testar o desempenho do sistema, pode ser realizado em conjunto com o teste de stress. O objetivo desse tipo de teste é garantir que os requisitos de desempenho relatados durante o planejamento sejam alcançados. O teste de desempenho analisa o tempo de resposta das atividades, a capacidade do banco de dados, os momentos em que o sistema perde mais desempenho em função de um grande número de processos executando, dentre outros. Esse teste pode ser realizado executando alguma instrução inúmeras vezes, assim, é possível observar se o desempenho cai ou não.

Teste de integração

Durante o desenvolvimento do sistema os gerentes decidem quem ficará responsável por cada fase de teste, normalmente cada programador se encarrega de testar seu próprio código, ao final, as partes desenvolvidas por cada programador são passadas a outra equipe que irá unificar os códigos. Essa equipe realiza a integração do software e mais testes são feitos. Os testes são realizados em partes separadas ou subsistemas e no sistema como um todo, por fim o teste é detalhadamente documentado e arquivado (SOMMERVILLE, 2003).

Um dos objetivos do teste de integração é detectar problemas junto às interfaces, ou seja, erros que aparecem com a junção das partes do sistema. Antes da junção são realizados testes nos pedaços individuais do sistema, os erros encontrados são corrigidos, outros erros aparentemente “menores”, nem são notados. Mais tarde, com as partes do sistema integradas, aqueles erros “menores” podem se apresentar não tão pequenos assim, e causar falhas inaceitáveis no sistema (PRESSMAN, 1995).

Basicamente, o teste de integração consiste em verificar se as partes testadas individualmente funcionam também unidas umas as outras, (INTHURN, 2001).

Pressman (1995) define dois tipos de integração de sistemas: a não incremental e a incremental. A primeira consiste em desenvolver todos os módulos do sistema, realizar a junção dos mesmos, e só depois iniciar a fase de testes. Normalmente os erros são tantos e a dificuldade de correção é tamanha que o resultado é um sistema completamente inaceitável. O teste de integração incremental tende a assegurar que o sistema possua uma quantidade menor de erros, isso se faz possível pelo fato de que cada módulo do sistema é testado individualmente antes da junção com os demais módulos, com isso fica mais fácil detectar e corrigir os erros existentes. Após a junção novos testes são realizados para detectar outros erros que possam aparecer. Um módulo pode funcionar corretamente quando testado sozinho, e não funcionar normalmente quando integrado a outros módulos, por isso a importância dos testes antes e depois da integração.

Integração Top-down

É uma abordagem da integração incremental. Segue uma ordem hierárquica, de cima para baixo. Os módulos mais importantes do sistema são desenvolvidos primeiro, depois os menos importantes. Após desenvolvido, cada módulo é testado individualmente, integrado aos outros módulos e testado novamente, assim, é possível conferir se a interface com os demais módulos continua compatível.

Integração Bottom-up

A ordem de teste dos módulos é inversa à top-down, os módulos menos importantes, ou de níveis mais baixos da hierarquia são desenvolvidos e testados primeiro, depois os próximos níveis a cima na hierarquia até que o último módulo seja testado.

Depuração de software

A depuração ou debugging ocorre quando um caso de teste encontra e mostra erros do sistema, ou seja, para que se faça a depuração é necessário que os testes realizados tenham obtido êxito.

A depuração consiste em analisar os resultados obtidos com os esperados, e, no caso de diferença entre eles, encontrar a causa, ou seja, encontrar o motivo da não correspondência entre os dados reais e os esperados, e, por fim, corrigir o problema (PRESSMAN, 1995). Em resumo, a depuração objetiva encontrar e corrigir a causa, ou causas, dos erros no sistema.

Executando Testes de Software

A primeira classe possui três métodos a serem testados: fatorial(), maiorNumero() e par(). O processo de teste utilizando a técnica do teste do caminho básico no primeiro método é o seguinte: primeiro deve-se numerar o programa, como pode-se observar a seguir:

Código numerado:

O próximo passo consiste em desenhar o grafo para visualização dos

caminhos a serem executados:

Na sequência, deve-se calcular a complexidade ciclomática para se certificar que o número de caminhos está correto. Ele pode ser feito de três maneiras:

CC(G) = Ramos – Nós + 2 = 12 – 9 + 2 = 5

CC(G) = Nós predicativos + 1 = 4 + 1 = 5

CC(G) = Regiões = 5

O resultado comum aos três cálculos indica maior probabilidade do grafo

estar correto.

Por último, deve-se descrever os possíveis caminhos e valores de entrada, como é mostrado a seguir:

Caminhos Básicos

1. 1, 2, 9 2. 1, 3, 5, 9 3. 1, 3, 4, 5, 9 4. 1, 3, 4, 6, 9 5. 1, 3, 4, 6, 7, 8, ..., 6, 9

Entradas

1. valor = -2 -> -1 "Valor Negativo!!! Não é válido!!!" 2. valor = 0 -> 1 3. valor = 1 -> 1 4. Inválido. Deveria entrar no “while” 5. valor = 5 -> 120

Dessa forma, encontram-se e percorrem-se todos os possíveis caminhos do método. A próxima etapa consiste em automatizar os testes, por exemplo, utilizando o JUnit.

Os métodos de asserções consistem em afirmar que suas instruções são verdadeiras, como se observa nas linhas de 16 a 19, ou seja, se o valor inserido no método for negativo o retorno é “-1”, se for 0 ou 1, o retorno é “1”, e se for um número positivo maior que 1 o retorno é seu fatorial. Neste caso, o fatorial de 5 é 120, então o resultado do teste deve ser positivo, caso não seja, o método possui erros.

O próximo método maiorNumero() foi implementado e numerado:

O grafo referente código exibido anteriormente é:

CC(G) = Ramos – Nós + 2 = 11 – 9 + 2 = 4

CC(G) = Nós predicativos + 1 = 3 + 1 = 4

CC(G) = Regiões = 4

Caminhos Básicos

1. 1, 4, 7, 8, 9 2. 1, 2, 3, 8, 9 3. 1, 4, 5, 6, 8, 9 4. 1, 2, 4, 5, 6, 8, 9

Entradas

1. v1 = 33, v2 = 33, v3 = 99 -> 99 2. v1 = 99, v2 = 33, v3 = 51 -> 99 3. v1 = 33, v2 = 99, v3 = 51-> 99 4. v1 = 51, v2 = 99, v3 = 33 ->99