6 IMPLEMENTAÇÃO E TESTES

Transcrição

1 Matéria: Implementação e Testes Página: IMPLEMENTAÇÃO E TESTES Origem: Engenharia de Software, Notas de Aula, prof. Ricardo Falbo, UFES, Departamento de Informática. Engenharia de Software, livro, Roger Pressman, Comentários adicionais. Uma vez que o software tenha seu design elaborado, é necessário construir os componentes que implementem esse projeto e testá-los. 6.1 IMPLEMENTAÇÃO Implementação é o processo de converter o projeto detalhado em código. Quando isso é feito por um único indivíduo, o processo é relativamente bem compreendido. Porém, hoje em dia, a maioria dos produtos são muito grandes para serem implementados por apenas um programador dentro das restrições de tempo. Em vez disso, o produto é implementado por uma equipe, com todos trabalhando ao mesmo tempo em diferentes componentes do produto. [Stephen R. Schach, 2007] Ainda que um projeto bem elaborado facilite sobremaneira a implementação, essa tarefa não é necessariamente fácil. Muitas vezes, os projetistas não conhecem em detalhes a plataforma de implementação e, portanto, não são capazes de (ou não desejam) chegar a um projeto algorítmico passível de implementação direta. Além disso, questões relacionadas à legibilidade, alterabilidade e reutilização têm de ser levadas em conta. Deve-se considerar, ainda, que programadores, geralmente, trabalham em equipe, necessitando integrar, testar e alterar código produzido por outros. Assim, é muito importante que haja padrões organizacionais para a fase de implementação. Esses padrões devem ser seguidos por todos os programadores e devem estabelecer, dentre outros, padrões de nomeclatura, formato de cabeçalhos de programas e formato de comentários, recuos e espaçamento, de modo que o código e a documentação a ele associada sejam claros para quaisquer membros da organização. Padrões para cabeçalho, por exemplo, podem informar o que o código (programa, módulo ou componente) faz, quem o escreveu, como ele se encaixa no projeto geral do sistema, quando foi escrito e revisado, apoios para teste, entrada e saída esperadas etc. Essas informações são de grande valia para a integração, testes, manutenção e reutilização [3]. Além dos comentários feitos no cabeçalho dos programas, comentários adicionais ao longo do código são também importantes, ajudando a compreender como o componente é implementado. Por fim, o uso de nomes significativos para variáveis, indicando sua utilização e significado, é imprescindível, bem como o uso adequado de recuo e espaçamento entre linhas de código, que ajudam a visualizar a estrutura de controle do programa [3]. Além da documentação interna, escrita no próprio código, é importante que o código de um sistema possua também uma documentação externa, incluindo uma visão geral dos componentes do sistema, grupos de componentes e da inter-relação entre eles [3]. Ainda que padrões sejam muito importantes, deve-se ressaltar que a correspondência entre os componentes do projeto e o código é fundamental, caracterizando-se como a mais importante questão a ser tratada. O projeto é o guia para a implementação, ainda que o programador deva ter certa flexibilidade para implementá-lo como código [3]. Como resultado de uma implementação bem-sucedida, as unidades de software devem ser codificadas e critérios de verificação das mesmas devem ser definidos.

2 Matéria: Implementação e Testes Página: TESTES Otimismo é o risco ocupacional da programação; teste é o tratamento. [Kent Beck] Não seja relaxado a ponto de pensar que o teste é uma rede de segurança que pegará todos os erros que ocorrem por causa de práticas inconsistentes de engenharia de software. Não pegará. Enfatize qualidade e detecção de erros ao longo de todo o processo de software. [Roger Pressman, 2006] Uma vez implementado o código de um software, o mesmo deve ser testado para descobrir tantos erros quanto possível, antes da entrega do produto ao seu cliente. Considerando os conceitos definidos pela Engenharia de Software é importante destacar dois termos que habitualmente são tratados como sinônimos: ERROS e DEFEITOS. Um erro é alguma falha encontrada em um artefato da engenharia de software, ou em algum resultado a ser produzido, que é encontrado ANTES do software ser entregue ao cliente. Um defeito se refere a falhas encontradas DEPOIS do software ser entregue ao cliente. O teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Por essa razão, um gabarito para teste de software um conjunto de passos no qual podemos incluir técnicas de projeto de casos de teste e métodos de teste específicos deve ser definido para o processo de software O teste é uma atividade de verificação e validação do software e consiste na análise dinâmica do mesmo, isto é, na execução do produto de software com o objetivo de verificar a presença de erros no produto e aumentar a confiança de que o mesmo está correto [4]. Além da identificação e consequente correção de erros, os testes tem outros benefícios: o teste demonstra que o software funciona de acordo com a especificação (requisitos e projeto), bem como trata os requisitos nãofuncionais que são necessários/desejados no produto de software. Vale ressaltar que, mesmo se um teste não detectar defeitos, isso não quer dizer necessariamente que o produto é um produto de boa qualidade. Muitas vezes, a atividade de teste empregada pode ter sido conduzida sem planejamento, sem critérios e sem uma sistemática bem definida, sendo, portanto, os testes de baixa qualidade [4]. Assim, o objetivo é projetar testes que potencialmente descubram diferentes classes de erros e fazêlo com uma quantidade mínima de esforço [1]. Ainda que os testes não possam demonstrar a ausência de defeitos, como benefício secundário, podem indicar que as funções do software parecem estar funcionando de acordo com o especificado. A idéia básica dos testes é que os defeitos podem se manifestar por meio de falhas observadas durante a execução do software. Essas falhas podem ser resultado de uma especificação errada ou falta de requisito, de um requisito impossível de implementar considerando o hardware e o software estabelecidos, o projeto pode conter defeitos ou o código pode estar errado. Assim, uma falha é o resultado de um ou mais defeitos [3]. São importantes princípios de testes a serem observados [1, 3]: Teste completo não é possível, ou seja, mesmo para sistemas de tamanho moderado, pode ser impossível executar todas as combinações de caminhos durante o teste. Teste envolve vários estágios. Geralmente, primeiro, cada módulo é testado isoladamente dos demais módulos do sistema (teste de unidade). À medida que os testes progridem, o foco se desloca para a integração dos módulos (teste de integração), até se chegar ao sistema como um todo (teste de sistema). Teste deve ser conduzido, preferencialmente, por terceiros. Os testes conduzidos por outras pessoas que não aquelas que produziram o código têm maior probabilidade de encontrar defeitos. O desenvolvedor que produziu o código pode estar muito envolvido com ele para poder detectar defeitos mais sutis.

3 Matéria: Implementação e Testes Página: 153 Testes devem ser planejados antes de serem realizados. Um plano de testes deve ser utilizado para guiar todas as atividades de teste e deve incluir objetivos do teste, abordando cada tipo (unidade, integração e sistema), como serão executados e quais critérios a serem utilizados para determinar quando o teste está completo. Uma vez que os testes estão relacionados aos requisitos dos clientes e usuários, o planejamento dos testes pode começar tão logo a especificação de requisitos tenha sido elaborada. À medida que o processo de desenvolvimento avança (análise, design e implementação), novos testes vão sendo planejados e incorporados ao plano de testes. O processo de teste envolve quatro atividades principais [3, 4]: Planejamento de Testes: trata da definição das atividades de teste, das estimativas dos recursos necessários para realizá-las, dos objetivos, estratégias e técnicas de teste a serem adotadas e dos critérios para determinar quando uma atividade de teste está completa. Projeto de Casos de Testes: é a atividade chave para um teste bem-sucedido, ou seja, para se descobrir a maior quantidade de defeitos com o menor esforço possível. Os casos de teste devem ser cuidadosamente projetados e avaliados para tentar se obter um conjunto de casos de teste que seja representativo e envolva as várias possibilidades de exercício das funções do software (cobertura dos testes). Existe uma grande quantidade de técnicas de teste para apoiar os testadores a projetar casos de teste, oferecendo uma abordagem sistemática para o teste de software. Execução dos testes: consiste na execução dos casos de teste e registro de seus resultados. Avaliação dos resultados: detectadas falhas, os defeitos deverão ser procurados. Não detectadas falhas, deve-se fazer uma avaliação final da qualidade dos casos de teste e definir pelo encerramento ou não de uma atividade de teste. As atividades de teste normalmente requerem os seguintes artefatos de entrada: Definição de Requisitos; Especificação de Requisitos; Especificação de Análise de Requisitos; Especificação de Design; Código-fonte dos programas / componentes. E as mesmas atividades costumam gerar os seguintes artefatos de saída: Uma Especificação/Plano de Teste, que especifica os procedimentos de teste que a equipe de testes deverá adotar, contendo a estratégia de teste a ser seguida, bem como as técnicas de teste que deverão ser aplicadas. Os testes a serem conduzidos deverão ser detalhados através de um conjunto de casos de teste, que contém os pré-requisitos, os procedimentos a serem seguidos, e os resultados esperados de cada teste realizado; Os resultados obtidos ao longo da execução dos testes. Testabilidade Testabilidade de software é simplesmente quão fácil [um software] pode ser testado. As seguintes características levam a um software testável: Operabilidade. Quanto melhor funciona, mais eficientemente pode ser testado ; Observabilidade. O que você vê é o que você testa ; Controlabilidade. Quanto melhor você pode controlar o software, mais o teste pode ser automatizado e otimizado ;

4 Matéria: Implementação e Testes Página: 154 Decomponibilidade. Controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar retestagem mais racionalmente ; Simplicidade. Quanto menos houver a testar, mais rapidamente podemos testá-lo ; Estabilidade. Quanto menos modificações, menos interrupções no teste ; Compreensibilidade. Quanto mais informações temos, mais racionalmente vamos testar. Característica do teste. Atributos para um bom teste: Tem alta probabilidade de encontrar um erro; Não é redundante; Deve ser de boa cepa ; Não deve ser muito simples nem muito complexo ESTRATÉGIAS DE TESTE Estratégias de teste são relacionadas à condução dos testes. Uma estratégia de teste de software integra métodos de projeto de casos de teste em uma série bem planejada de passos, que resultam na construção bem-sucedida de software. A estratégia fornece um roteiro que descreve os passos a serem conduzidos como parte do teste, quando esses passos são planejados e depois executados, e quanto de esforço, tempo e recursos serão necessários. Assim, qualquer estratégia de teste deve incorporar planejamento de teste, projeto de casos de teste, execução de teste e a resultante coleta e avaliação de dados. Algumas características genéricas podem ser identificadas, e são independentes de qualquer estratégia adotada: Para realizar teste efetivo, uma equipe de software deve conduzir revisões técnicas formais. Ao fazer isso, muitos erros serão eliminados antes do início do teste; O teste começa no nível de componente e prossegue para fora, em direção à integração de todo o sistema baseado em computador; Diferentes técnicas de testes são adequadas em diferentes momentos; O teste é conduzido pelo desenvolvedor do software e (para projetos grandes) um grupo de teste independente. Uma estratégia de teste deve acomodar testes de baixo nível, para verificar se um pequeno segmento de código-fonte foi corretamente implementado, bem como testes de alto nível, que validam as principais funções do sistema com base nos requisitos do cliente. Uma estratégia deve fornecer diretrizes para o profissional e um conjunto de referenciais para o gerente. Como os passos da estratégia de teste ocorrem quando a pressão do prazo de entrega começa a crescer, o progresso deve ser mensurável e os problemas devem aparecer tão cedo quanto possível Verificação x Validação O teste de software é um elemento de um aspecto mais amplo, que é frequentemente referido como verificação e validação. Verificação se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica. (Estamos construindo o produto corretamente?). Já Validação se refere a um

5 Matéria: Implementação e Testes Página: 155 conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente. (Estamos construindo o produto certo?). Ambas abrangem um amplo conjunto de atividades de qualidade, que inclui revisões técnicas formais, auditoria de qualidade e configuração, monitoramento de desempenho, simulação, estudo de viabilidade, revisão de documentação, revisão da base de dados, análise de algoritmos, teste de desenvolvimento, teste de usabilidade, teste de qualificação e teste de instalação Organização de Teste de Software Em cada projeto de software há um conflito de interesses inerente que ocorre quando o teste inicia. Conflito de interesses: quem construiu o software tentará mostrar que o programa funciona. O teste procura identificar justamente o que não funciona! Algumas concepções equivocadas, e o que deve efetivamente ocorrer: O desenvolvedor não deve realizar nenhum teste. Desenvolvedores devem realizar testes unitários e podem conduzir testes de integração. Apenas depois de a arquitetura do software ser completada, um grupo independente de teste começa a ser envolvido; O software deve ser jogado por cima do muro, para estranhos que vão testá-lo impiedosamente. O papel do grupo independente é remover os problemas inerentes associados com deixar o construtor testar a coisa que ele construiu. O engenheiro e o grupo independente trabalham juntos para garantir testes rigorosos; Os testadores se envolvem com o projeto apenas quando os passos de teste estão para começar. O grupo independente é parte da equipe do projeto, estando envolvido desde a análise e o projeto. Alguns tópicos estratégicos importantes na consideração da estratégia de teste a ser definida: Especifique os requisitos do produto de um modo quantificável muito antes de o teste começar; Enuncie explicitamente os objetivos do teste; Entenda os usuários do software e desenvolva um perfil para cada categoria de usuário; Desenvolva um plano de teste que enfatize teste de ciclo rápido ; Construa software robusto que é projetado para testar a si próprio; Use revisões técnicas formais efetivas como filtro antes do teste; Conduza revisões técnicas formais para avaliar a estratégia de teste e os casos de teste propriamente ditos; Desenvolva uma abordagem de aperfeiçoamento contínuo para o processo de teste Fases de Teste O projeto efetivo de casos de teste é importante, mas não suficiente para o sucesso da atividade de testes. A estratégia, isto é, a série planejada de realização dos testes, é também crucial [1]. Basicamente, podem ser consideradas as seguintes fases de teste:

6 Matéria: Implementação e Testes Página: 156 Teste de Unidade: tem por objetivo testar a menor unidade do projeto (um componente de software que não pode ser subdividido), procurando identificar erros de lógica e de implementação em cada módulo separadamente. No paradigma estruturado, a menor unidade refere-se a um procedimento ou função. No paradigma orientado a objetos pode-se considerar uma classe ou um método; Teste de Integração: visa descobrir erros associados às interfaces entre os módulos quando esses são integrados para formar a estrutura do produto de software, focando assim na arquitetura do software; Teste de Validação: tem por objetivo identificar erros de funções (requisitos funcionais) e características de desempenho, entre outros, (requisitos não-funcionais) que não estejam de acordo com as especificações; Teste de Sistema: testa o software e os outros elementos do sistema do qual o software faz parte. Tomando por base essas fases, a atividade de teste pode ser estruturada de modo que, em cada fase, diferentes tipos de erros e aspectos do software sejam considerados [4]. Tipicamente, os primeiros testes focalizam componentes individuais e aplicam testes caixa-branca e caixa-preta para descobrir erros. Após os componentes individuais terem sido testados, eles precisam ser integrados, até se obter o sistema por inteiro. Na integração, o foco é o projeto e a arquitetura do sistema. Finalmente, uma série de testes de alto nível é executada quando o sistema estiver operacional, visando a descobrir erros nos requisitos [1,3] Teste de Unidade O teste de unidade focaliza o esforço de verificação na menor unidade de projeto do software o componente ou módulo de software. Enfoca a lógica interna de processamento e as estruturas de dados dentro dos limites de um componente. Tipos de testes: Testes de interface; Estrutura lógica de dados; Condições-limites; Caminhos independentes; Caminhos de manipulação de erros.

7 Matéria: Implementação e Testes Página: / Nos testes de unidade e de integração, faz-se necessário construir pequenos componentes para permitir testar os módulos individualmente e a integração incremental, os ditos drivers e stubs. Um driver é um programa responsável pela ativação e coordenação do teste de uma unidade. Ele é responsável por receber os dados de teste fornecidos pelo testador, passar esses dados para a unidade/integração sendo testada, obter os resultados produzidos por essa unidade/integração e apresentá-los ao testador. Um stub é uma unidade que substitui, na hora do teste, uma outra unidade chamada pela unidade/integração que está sendo testada. Em geral, um stub simula o comportamento da unidade/integração chamada com o mínimo de computação ou manipulação de dados [4].

8 Matéria: Implementação e Testes Página: Teste de Integração O Teste de integração é uma técnica sistemática para construir a arquitetura do software enquanto, ao mesmo tempo, conduz testes para descobrir erros associados às interfaces. É interessante a ideia de utilizar integração incremental ao invés de integrar todos os componentes de uma só vez. A abordagem de integração de módulos pode ter impacto na quantidade de drivers e stubs a ser construída. Sejam as seguintes abordagens: Integração ascendente ou bottom-up: Nessa abordagem, primeiramente, cada módulo no nível inferior da hierarquia do sistema é testado individualmente. A seguir, são testados os módulos que chamam esses módulos previamente testados. Esse procedimento é repetido até que todos os módulos tenham sido testados [3]. Neste caso, apenas drivers são necessários. Seja o exemplo da figura 7.1. Usando a abordagem de integração ascendente, os módulos seriam testados da seguinte forma. Inicialmente, seriam testados os módulos do nível inferior (E, F e G). Para cada um desses testes, um driver teria de ser construído. Concluídos esses testes, passaríamos ao nível imediatamente acima, testando seus módulos (B, C e D) combinados com os módulos por eles chamados. Neste caso, testamos juntos B, E e F bem como C e G. Novamente, três drivers seriam necessários. Por fim, testaríamos todos os módulos juntos. Integração descendente ou top-down: A abordagem, neste caso, é precisamente o contrário da anterior. Inicialmente, o nível superior (geralmente um módulo de controle) é testado sozinho. Em seguida, todos os módulos chamados por este módulo testado são combinados e testados como uma grande unidade. Essa abordagem é repetida até que todos os módulos tenham sido incorporados [3]. Neste caso, apenas stubs são necessários. Tomando o exemplo da figura 7.1, o teste iniciaria pelo módulo A e três stubs (para B, C e D) seriam necessários. Na sequência seriam testados juntos A, B, C e D, sendo necessários stubs para E, F e G. Por fim, o sistema inteiro seria testado. Teste de regressão é a reexecução de algum subconjunto de testes que já foi conduzido para garantir que as modificações não propaguem efeitos colaterais indesejáveis. Esse subconjunto contém 3 diferentes classes de casos de teste: Uma amostra representativa de testes que vão exercitar todas as funções do software; Testes adicionais que focalizam funções do software, que serão provavelmente afetadas pela modificação; Testes que focalizam os componentes de software que foram modificados. Teste fumaça é projetado como mecanismo de marca-passo para projetos de prazo crítico, permitindo à equipe avaliar seu projeto em bases frequentes. Abrange as seguintes atividades: Componentes que foram traduzidos para código são integrados em uma construção, que inclui todos os arquivos de dados, bibliotecas, módulos reusáveis e componentes submetidos a engenharia, que são necessários para implementar uma ou mais funções do produto.

9 Matéria: Implementação e Testes Página: 159 Uma série de testes é projetada para expor erros que impeçam a construção de desempenhar adequadamente a sua função. O propósito deve ser descobrir erros bloqueadores que têm a maior probabilidade de colocar o projeto fora do cronograma. A construção é integrada com outras construções e o produto inteiro passa pelo teste fumaça diariamente. A abordagem de integração pode ser descendente ou ascendente. Alguns benefícios esperados do teste fumaça: 276 / O risco de integração é minimizado; A qualidade do produto final é aperfeiçoada; Diagnóstico e correção de erros são simplificados; Progresso é fácil de avaliar. Muitas outras abordagens, algumas usando as apresentadas anteriormente, podem ser adotadas, tal como a integração sanduíche [3], que considera uma camada alvo no meio da hierarquia e utiliza as abordagens ascendente e descendente, respectivamente para as camadas localizadas abaixo e acima da camada alvo. Outra possibilidade é testar individualmente cada módulo e só depois de testados individualmente integrá-los (teste big-band). Neste caso, tanto drivers quanto stubs têm de ser construídos para cada módulo, o que leva a muito mais codificação e problemas em potencial [3]. Módulo Crítico A medida que o teste de integração é conduzido, o testador deve identificar os módulos críticos. Um módulo crítico tem uma ou mais das seguintes características: Aborda vários requisitos do software; Tem um alto nível de controle (situa-se em um ponto relativamente alto na estrutura do programa); É complexo ou propenso a erro; ou Tem requisitos de desempenho bem definidos Teste de Validação Uma vez integrados todos os módulos do software, parte-se para os testes de validação, quando se busca observar se o software funciona conforme esperado pelo cliente. A validação do software é conseguida por intermédio de uma série de testes que demonstram conformidade com os requisitos. Tanto o plano quanto o procedimento são projetados para garantir que todos os requisitos funcionais sejam satisfeitos, todas as características comportamentais sejam seguidas, todos os requisitos de desempenho sejam alcançados, a documentação esteja correta, usabilidade e outros requisitos não-funcionais sejam satisfeitos (como compatibilidade, recuperação de erro e manutenibilidade). Se o software é desenvolvido como um produto a ser usado por vários clientes, não é prática realizar testes formais de aceitação com cada um. A maioria dos construtores de produtos de software usa os processos denominados Teste Alfa e Teste Beta para descobrir erros que apenas o usuário final parece ser capaz de descobrir. Teste Alfa é conduzido na instalação do desenvolvedor com os usuários finais. O software é usado em um ambiente natural com o desenvolvedor olhando sobre os ombros dos usuários típicos e registrando erros e problemas de uso. Testes alfa são conduzidos em um ambiente controlado. Teste Beta é conduzido nas instalações dos usuários finais. Diferente do teste alfa, o desenvolvedor geralmente não está presente. Consequentemente, o teste beta é uma aplicação ao vivo do software em um ambiente que não pode ser controlado pelo usuário final. O cliente registra todos os

10 Matéria: Implementação e Testes Página: 160 problemas que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares Teste de Sistema Teste de Sistema são uma série de testes cuja finalidade principal é exercitar por completo o Sistema de Informação Baseado em Computador. Os tipos de teste de sistema mais comumente realizados são os seguintes: Teste de Recuperação é um teste de sistema que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada. Se a recuperação é automática, a reinicialização, os mecanismos de verificação, a recuperação dos dados e o reinício são avaliados quanto à correção. Se a recuperação requer intervenção humana, o tempo médio para reparo é avaliado para determinar se está dentro de limites aceitáveis;279 / Teste de Segurança verifica se os mecanismos de proteção incorporados a um sistema vão de fato protegê-lo de invasão imprópria; Teste de Estresse executa um sistema de tal forma que demanda recursos em quantidade, frequência ou volume anormais; Teste de Desempenho é projetado para testar o desempenho do software durante a execução, para sistemas em tempo real e embutidos A ARTE DA DEPURAÇÃO A depuração ocorre como conseqüência de teste bem-sucedido. Isto é, quando um caso de teste descobre um erro, a depuração é a ação que resulta na reparação do erro. Apesar de a depuração poder e dever ser um processo ordenado, é ainda excessivamente uma arte. Um engenheiro de software, avaliando os resultados de um teste, é frequentemente confrontado com uma indicação sintomática de um problema do software. Isto é, a manifestação externa do erro e a causa interna do erro podem não ter relação óbvia uma com a outra. O processo mental mal compreendido que conecta um sintoma com uma causa é a depuração. A depuração não é teste, mas sempre ocorre como consequência do teste. O processo de depuração pode ser observado na figura abaixo.

11 Matéria: Implementação e Testes Página: 161 Por que a depuração é tão difícil? O sintoma e a causa podem ser geograficamente remotos. Estruturas de programas altamente acopladas agravam essa situação; O sintoma pode desaparecer (temporariamente) quando outro erro é corrigido; O sintoma pode, na verdade, ser causado por não-erros (por exemplo, imprecisões de arredondamento); O sintoma pode ser causado por erro humano (que não é facilmente rastreado); O sintoma pode ser resultado de problemas de tempo, em vez de problemas de processamento; Pode ser difícil reproduzir precisamente condições de entrada (por exemplo, uma aplicação em tempo real na qual a ordem das entradas é indeterminada); O sintoma pode ser intermitente. Isso é particularmente comum em sistemas embutidos, que acoplam hardware e software inextricavelmente; O sintoma pode ser devido a causas que estão distribuídas entre várias tarefas sendo executadas em diferentes processadores. Considerações psicológicas A depuração é uma das partes mais frustrantes da programação. Tem elementos de solução de problemas ou de quebra-cabeças, combinados com o reconhecimento desagradável de que você cometeu um erro. A elevada ansiedade e a má vontade em aceitar a possibilidade de erros aumentam a dificuldade da tarefa. Felizmente, há um suspiro de alívio e uma diminuição da tensão quando o defeito é finalmente... corrigido. [Shneiderman, 1980] Abordagens de Depuração Força bruta A mais comum. São feitas listagens de memória, são invocados rastreadores de execução e o programa é carregado com comandos de saída. Tudo em busca de uma pista do erro; Rastreamento Partindo do local em que o sintoma foi descoberto, o código-fonte é rastreado até que o lugar da causa seja encontrado; Eliminação de causa Os dados relacionados ao erro são organizados para isolar causas em potencial, que são depois testadas e sucessivamente eliminadas, até que a verdadeira causa seja encontrada e consiga-se isolar o erro. Correção do Erro Uma vez encontrado um erro, ele precisa ser corrigido. Mas deve-se estar atento ao fato de que a correção de um erro pode introduzir no sistema novos erros. Três perguntas simples que devem ser feitas antes da correção de um erro: A causa do erro está reproduzida em outra parte do programa? Qual o próximo erro que pode ser introduzido pelo conserto que estou prestes a fazer? O que poderíamos ter feito para prevenir a ocorrência deste erro?

12 Matéria: Implementação e Testes Página: TÉCNICAS DE TESTE Técnicas de teste são relacionadas ao Projeto de Testes. Para testar um módulo, é necessário definir um caso de teste, executar o módulo com os dados de entrada definidos por esse caso de teste e analisar a saída. Um teste é um conjunto limitado de casos de teste, definido a partir do objetivo do teste [3]. Diversas técnicas de teste têm sido propostas visando apoiar o projeto de casos de teste. Essas técnicas podem ser classificadas, segundo a origem das informações utilizadas para estabelecer os objetivos de teste, em, dentre outras categorias, técnicas funcional, estrutural ou baseadas em máquinas de estado [4]. Os testes funcionais ou caixa-preta utilizam as especificações (de requisitos, análise e projeto) para definir os objetivos do teste e, portanto, para guiar o projeto de casos de teste. O conhecimento sobre uma determinada implementação não é usado [4]. Assim, os testes são conduzidos na interface do software. Os testes caixa-preta são empregados para demonstrar que as funções do software estão operacionais, que a entrada é adequadamente aceita e a saída é corretamente produzida e que a integridade da informação externa (uma base de dados, por exemplo) é mantida [1]. Os testes estruturais ou caixa-branca estabelecem os objetivos do teste com base em uma determinada implementação, verificando detalhes do código. Caminhos lógicos internos são testados, definindo casos de testes que exercitem conjuntos específicos de condições ou laços [1]. Os testes baseados em máquinas de estado são projetados utilizando o conhecimento subjacente à estrutura de uma máquina de estados para determinar os objetivos do teste [4]. É importante ressaltar que técnicas de teste devem ser utilizadas de forma complementar, já que elas têm propósitos distintos e detectam categorias de erros distintas [4]. À primeira vista, pode parecer que realizando testes caixa branca rigorosos poderíamos chegar a programas corretos. Contudo, conforme anteriormente mencionado, isso não é prático, uma vez que todas as combinações possíveis de caminhos e valores de variáveis teriam de ser exercitadas, o que é impossível. Isso não quer dizer, entretanto, que os testes caixa-branca não são úteis. Testes caixabranca podem ser usados, por exemplo, para garantir que todos os caminhos independentes (Um caminho independente é qualquer caminho ao longo de um módulo que introduz pelo menos um novo comando de processamento ou condição [1]) de um módulo tenham sido exercitados pelo menos uma vez [1]. Há diversas técnicas de testes caixa-branca, cada uma delas procurando apoiar o projeto de casos de teste focando em algum ou vários aspectos da implementação. Dentre elas, podem ser citadas [1]: Testes de estrutura de controle: como o próprio nome diz, enfocam as estruturas de controle de um módulo, tais como comandos, condições e laços. Teste de condição é um tipo de teste de estrutura de controle que exercita as condições lógicas contidas em um módulo. Um teste de fluxo de dados, por sua vez, seleciona caminhos de teste tomando por base a localização das definições e dos usos das variáveis nos módulos. Testes de ciclo ou laço focalizam exclusivamente os laços (loops). Teste de caminho básico: define uma medida de complexidade lógica de um módulo e usa essa medida como guia para definir um conjunto básico de caminhos de execução. Assim como há diversas técnicas de teste caixa-branca, o mesmo acontece em relação ao teste caixa-preta. Dentre as diversas técnicas de teste caixa-preta, podem ser citadas [1]: Particionamento de equivalência: divide o domínio de entrada de um módulo em classes de equivalência, a partir das quais casos de teste são derivados. A meta é minimizar o número de casos de teste, ficando apenas com um caso de teste para cada classe, uma vez que, a princípio, todos os elementos de uma mesma classe devem se comportar de maneira equivalente. Análise de valor limite: a prática mostra que um grande número de erros tende a ocorrer nas fronteiras do domínio de entrada de um módulo. Tendo isso em mente, a análise de valor limite leva à seleção de casos de teste que exercitem os valores limítrofes.

13 Matéria: Implementação e Testes Página: DICAS DE LEITURA PRESSMAN, Roger. Engenharia de software Makron Books. Capítulo 13 Estratégias de Teste de Software; Capítulo 14 Técnicas de Teste de Software; SOMMERVILLE, Ian. Engenharia de software Pearson Education. Capítulo 22 Verificação e Validação; Capítulo 23 Teste de Software; SCHACH, Stephen R.. Engenharia de software: os paradigmas clássicos e orientado a objeto McGrawHill. Capítulo 6 Testes; Capítulo 14 - Implementação.