c. Técnica de Estrutura de Controle Teste do Caminho Básico

Transcrição

1 1) Defina: a. Fluxo de controle A análise de fluxo de controle é a técnica estática em que o fluxo de controle através de um programa é analisado, quer com um gráfico, quer com uma ferramenta de fluxo de controle. Muitas anomalias podem ser detectadas em um sistema com esta técnica, inclusive loops mal concebidos (por exemplo, com vários pontos de entrada), alvos ambíguos de chamadas de função em certas linguagens (por exemplo, Scheme), o sequenciamento incorreto de operações etc. Um dos usos mais comuns da análise de fluxo de controle é a determinação da complexidade ciclomática. O valor da complexidade ciclomática é um número inteiro positivo que representa o número de caminhos independentes em um gráfico com muitas conexões, com loops e iterações ignorados assim que tiverem sido percorridos uma vez. Cada caminho independente, da entrada à saída, representa um caminho único através do módulo. Cada caminho único deve ser testado. Geralmente, o valor da complexidade ciclomática consiste em entender a complexidade geral de um módulo. A teoria de Thomas McCabe era a de que quanto mais complexo for o sistema, mais difícil seria mantê-lo e mais defeitos ele conteria. Ao longo dos anos, muitos estudos observaram esta correlação entre complexidade e o número de defeitos contidos. O Instituto Nacional de Metrologia, Normalização e Qualidade Industrial dos EUA (NIST, na sigla em inglês) recomenda um valor máximo de complexidade de 10. Qualquer módulo que tiver uma complexidade maior do que essa poderá ser dividido em vários módulos. b. Fluxo de Dados A análise de fluxo de dados cobre várias técnicas que coletam informações sobre o uso de variáveis em um sistema. O ciclo de vida das variáveis (isto é, onde são declaradas, definidas, lidas, avaliadas e destruídas) é examinado, já que as anomalias podem ocorrer durante qualquer uma destas operações. c. Técnica de Estrutura de Controle Teste do Caminho Básico d. Partição de Equivalência Teoria de partição de equivalência proposta por Glenford Myers [MYE79]. Tenta reduzir o número total de casos de teste necessários, particionando as condições de entrada em um número finito de classes de equivalência. As classes de equivalência são classificadas em dois tipos: o conjunto de entradas válidas para o programa é considerado como a classe de equivalência válida e todas as outras entradas são incluídas na classe de equivalência inválida. e. Complexidade Ciclomática É uma métrica de software usada para indicar a complexidade de um programa de computador. Desenvolvida por Thomas J. McCabe em 1976, ela

2 mede a quantidade de caminhos de execução independentes a partir de um código fonte. Essa complexidade é computada através do grafo de fluxo de controle do programa: os nós do grafo correspondem a grupos indivisíveis de comandos, e uma aresta direcionada conecta dois nós se o segundo comando pode ser executado imediatamente após o primeiro. A complexidade ciclomática também pode ser aplicada a funções, módulos, métodos ou classes individuais de um programa. f. Teste de Software É a investigação do software com o objetivo de fornecer informações sobre o nível de qualidade em relação ao contexto em que o mesmo deve operar. Isso inclui o processo de encontrar seus defeitos. g. Casos de Teste É um conjunto de condições usadas para teste de software. Ele pode ser elaborado para identificar defeitos na estrutura interna do software por meio de situações que exercitem adequadamente todas as estruturas utilizadas na codificação; ou ainda, garantir que os requisitos do software que foi construído sejam plenamente atendidos. Podemos utilizar a ferramenta de casos de uso para criar e rastrear um caso de teste, facilitando assim identificação de possíveis falhas. O caso de teste deve especificar a saída esperada e os resultados esperados do processamento. Numa situação ideal, no desenvolvimento de casos de teste, se espera encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de encontrar a maioria dos erros. h. Falta Falta é um problema bem determinado no artefato. Falta é a identificação interna enquanto que falha é a percepção externa. i. Erro É uma diferença detectada entre o resultado de uma computação e o resultado correto ou esperado. Problema introduzido no software pelo programador j. Falha Falha é a consequência de uma ou mais faltas. É a percepção de que o artefato não se comportou como o esperado. É um não funcionamento do software, possivelmente provocada por um defeito, mas também com outras causas possíveis. Problema ocorrido no software por um erro não detectado pelos testes.

3 De acordo com o padrão IEEE (1983) uma falha ocorre quando um programa não se comporta conforme o esperado ou apresenta resultados diferentes do planejado. Deste modo uma falha é considerada uma propriedade do sistema em execução. k. Defeito É uma linha de código, bloco ou conjunto de dados incorretos, que provocam um erro observado. Problema encontrado no software pelos testadores. É decorrente de um erro. Um defeito ocorre no nível mais baixo do hardware ou em uma linha de código. O defeito é a causa de um erro, mas não necessariamente sempre acarreta em um erro, pois a linha que contém um defeito pode nunca ser executada. l. Testes estáticos São aqueles realizados sobre o código-fonte do software, utilizando como técnica básica a inspeção visual. Este tipo de teste é de simples implementação, uma vez que não há necessidade de execução do programa para obter-se resultados. Eles podem ser utilizados utilizando a técnica de leitura cruzada, onde um leitor é atribuído para avaliar o trabalho de cada programador do software. Uma outra forma de realizar o teste é por inspeção, onde uma equipe designada analisa o código à luz de um questionário especialmente concebido (check-list). m. Testes dinâmicos Os testes dinâmicos são os procedimentos baseados na execução do código binário do programa, sendo esta execução realizada com base em subconjuntos de dados (o jogo de teste). n. Testes funcionais São testes que avaliam o comportamento da aplicação. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado. O teste funcional é aplicável a todas as fases do teste (unitário, integração, sistema e aceitação). Testa as funcionalidades, requerimentos, regras de negócio presentes na documentação. Conhecidos como Teste de Caixa Preta. o. Testes não-funcionais São testes que verificam atributos de um componente de sistema que não se relacionam com a funcionalidade (confiabilidade, eficiência, usabilidade, manutenabilidade e portabilidade) p. Testes estruturais Garantem que os softwares e os programas sejam estruturalmente sólidos e que funcionem no contexto técnico onde serão instalados. Conhecidos como testes de Caixa Branca.

4 q. Testes de unidade O teste de unidade objetiva a verificação de erros existentes nas unidades de projeto do mesmo, à qual daremos o nome de módulo. Nesta modalidade de teste, é importante utilizar as informações contidas no documento de projeto detalhado do software, as quais servirão de guia para sua aplicação. O teste de unidade é, de certa forma, uma técnica de teste de caixa branca, podendo ser realizado em paralelo sobre diferentes módulos. r. Testes de integração O Teste de Integração, como o nome indica, objetiva a busca de erros surgidos quando da integração das diferentes unidades componentes do software. É importante lembrar que, o fato de se ter analisado os módulos do software de forma exaustiva (através de procedimentos de teste de unidade), não há nenhuma garantia de que estes, uma vez colocados em conjunto para funcionar, não apresentarão anomalias de comportamento. s. Testes de validação Ao final do teste de integração, o software é finalmente estruturado na forma de um pacote ou sistema. A forma mais simples de definição do teste de validação é a verificação de que o software como um todo cumpre corretamente a função para a qual ele foi especificado. É importante lembrar que, no documento de especificação do software, quando no início da sua concepção, são definidos os chamados critérios de validação, que servirão de guia para o julgamento de aprovação ou não do software nesta etapa de testes. t. Testes alfa e beta Teste Alfa é normalmente definida quando este produto ainda está em fase de construção e testes. Mas só os programadores envolvidos têm acesso, e não ao público em geral. Porém, os usuários que serão beneficiados com o software poderão testar o sistema em um ambiente controlado nas instalações do desenvolvedor, caracterizando o processo denominado teste alpha. A versão beta é a versão de um produto (geralmente software) que ainda se encontra em fase de desenvolvimento e testes e são disponibilizados para que os usuários possam testar e eventualmente, reportar bugs para os desenvolvedores. No entanto, esses produtos muitas vezes são popularizados bem antes de sair a versão final. Na prática, sempre que um programa é lançado em versão Beta, significa que o próprio desenvolvedor admite que o programa ainda não está pronto e pode ter problemas, porém já está em um nível decente para a utilização, mesmo que sem nenhuma garantia. u. Teste de segurança

5 O Teste de Segurança tem como meta garantir que o funcionamento da aplicação esteja exatamente como especificado. Verifica também se o software se comporta adequadamente mediante as mais diversas tentativas ilegais de acesso, visando possíveis vulnerabilidades. Para isso, testa se todos os mecanismos de proteção embutidos na aplicação de fato a protegerão de acessos indevidos. v. Testes de estresse É realizado para submeter o software a situações extremas. Basicamente, o teste de estresse baseia-se em testar os limites do software e avaliar seu comportamento. Assim, avalia-se até quando o software pode ser exigido e quais as falhas (se existirem) decorrentes do teste. w. Teste de desempenho Teste de Desempenho (ou Performance) é normalmente executado para ajudar a identificar gargalos sistema, estabelecer uma baseline para futuras análises/testes, apoio no esforço de performance tuning, determinar a conformidade com requisitos e metas de performance, e/ou coleta de outros dados relacionados ao desempenho para assim ajudar os stakeholders a tomar decisões relacionados com a qualidade total da aplicação que está sendo testada. Além disso, os resultados do Teste de Performance e análises podem ajudar você a estimar a configuração do hardware necessária para suportar a aplicação quando você liberar para o uso em produção x. Teste Caixa Branca Um teste de caixa branca num produto de software está relacionado a um exame minucioso de sua estrutura interna e detalhes procedimentais. Os caminhos lógicos definidos no software são exaustivamente testados, pondo à prova conjuntos bem definidos de condições ou laços. Durante o teste, o status do programa pode ser examinado diversas vezes para eventual comparação com condições de estado esperadas para aquela situação. Apesar da importância do teste de caixa branca, não se deve guardar a falsa ideia de que a realização de testes de caixa branca num produto de software vai oferecer a garantia de 100% de correção deste ao seu final. Isto porque, mesmo no caso de programas de pequeno e médio porte, a diversidade de caminhos lógicos pode atingir um número bastante elevado, representando um grande obstáculo para o sucesso completo desta atividade. y. Teste Caixa Preta Quando o procedimento de teste está relacionado ao produto de software, o teste de caixa preta refere-se a todo teste que implica na verificação do funcionamento do software através de suas interfaces, o que, geralmente, permite verificar a operacionalidade de todas as suas funções. É importante observar que, no teste de caixa preta, a forma como o software está

6 organizado internamente não tem real importância, mesmo que isto possa ter algum impacto na operação de alguma função observada em sua interface.