Testes a sistemas de informação: diferenças entre revisões

Fonte: aprendis
Saltar para a navegaçãoSaltar para a pesquisa
Linha 85: Linha 85:
Quantas mais entradas foram fornecidas, melhor será o teste. Idealmente, todas as entradas possíveis deviam ser testadas, de forma garantir os melhores resultados. No entanto, isso implicaria muito tempo e muitos recursos.
Quantas mais entradas foram fornecidas, melhor será o teste. Idealmente, todas as entradas possíveis deviam ser testadas, de forma garantir os melhores resultados. No entanto, isso implicaria muito tempo e muitos recursos.
Para garantir a qualidade do teste de forma realista, normalmente são utilizados subconjuntos de entradas (alguns subconjuntos podem até ser processados similarmente) que se acredita maximizarem a riqueza do teste.
Para garantir a qualidade do teste de forma realista, normalmente são utilizados subconjuntos de entradas (alguns subconjuntos podem até ser processados similarmente) que se acredita maximizarem a riqueza do teste.


===Caixa Cinzenta===
===Caixa Cinzenta===

Revisão das 05h28min de 12 de fevereiro de 2016

Os testes são uma fase de um sistema de informação e são fundamentais para garantir a qualidade do sistema. É nesta fase que os erros são detetados, criando a oportunidade para aperfeiçoar o software. O problema é que esta fase implica tempo e recursos. Grande parte dos custos de desenvolvimento de sistemas advém, precisamente, da realização de testes.

Sub-fases

Tal como as anteriores, esta fase é composta por sub-fases:

  • Planeamento da estratégia e do plano de teste;
  • Preparação do ambiente de teste (recursos materiais, tecnológicos e humanos);
  • Especificação de casos e de roteiros de teste;
  • Execução dos testes e registo dos resultados;
  • Entrega da documentação final.

Fontes de Erros

  • Especificação errada e/ou incompleta dos requisitos;
  • Requisitos impossíveis;
  • Implementação errada/incompleta;
  • Mau desenho do sistema;
  • Técnica de desenvolvimento inadequada;
  • Erros de programação:
  • Interface pouco clara/inadequada, etc.

Atributos a avaliar

De acordo com a norma ISO 9126 (norma internacional para a qualidade de software), os atributos qualitativos a avaliar num sistema de informação são:

  • Funcionalidade:
    • Capacidade de um sistema de fornecer as funcionalidades que satisfazem as necessidades do utilizador;
    • Inclui:
      • Adequação (quanto as funcionalidades estão adequadas às necessidades dos utilizadores);
      • Precisão (capacidade de fornecer resultados precisos - de acordo com o estipulado);
      • Interoperabilidade (capacidade de interação com outros sistemas);
      • Segurança (capacidade de proteger, processar, gerar e armazenar informação);
      • Conformidade (com padrões, políticas e normas);
  • Confiabilidade:
    • Capacidade do sistema de manter o grau de desempenho esperado;
    • Inclui:
      • Maturidade (capacidade de evitar falhas relacionadas com defeitos do software);
      • Tolerância a falhas (capacidade de manter o desempenho, mesmo quando ocorrem erros);
      • Recuperabilidade (capacidade de repor níveis de desempenho depois de uma falha);
  • Usabilidade:
    • Capacidade do sistema de ser compreendido e usado pelos utilizadores;
    • Inclui:
      • Inteligibilidade (capacidade do sistema de fazer o utilizador entender as suas funcionalidades);
      • Apreensibilidade (capacidade do sistema de aprender com os utilizadores);
      • Operacionalidade;
      • Atratividade;
  • Eficiência:
    • Capacidade do sistema de utilizar os recursos de forma adequada ao desempenho - não há sobreutilização nem desperdício de recursos;
    • Inclui:
      • Comportamento em relação ao tempo (tempos de resposta e processamento);
      • Utilização de recursos (recursos consumidos e capacidade de utilização dos recursos);
  • Manutenibilidade:
    • Capacidade do sistema de ser modificado por melhorias, extensões, correções de erros, etc.;
    • Inclui:
      • Analisabilidade (capacidade para identificar falhas e as suas causas);
      • Modificabilidade (capacidade de modificação do comportamento);
      • Estabilidade (capacidade de evitar efeitos colaterais decorrentes de modificações);
      • Testabilidade;
  • Portabilidade:
    • Capacidade do sistema de ser transportado para outro ambiente;
    • Inclui:
      • Adaptabilidade (capacidade de se adaptar a novos ambientes);
      • Capacidade de instalação (capacidade de ser instalado noutro ambiente);
      • Coexistência (capacidade de coexistir com outros sistemas no mesmo ambiente);
      • Capacidade de substituição (capacidade de substituir outro sistema num contexto e ambiente específicos).

Técnicas de Teste

Caixa Branca

Esta técnica assenta diretamente sobre o código fonte do software, por forma a avaliar aspetos tais como:

  • teste de condição,
  • teste de fluxo de dados,
  • teste de ciclos,
  • teste de caminhos lógicos,
  • códigos nunca executados.

No entanto, os aspetos avaliados através deste método dependem da complexidade do sistema e da tecnologia utilizada na sua construção. Isto pode implicar que mais elementos tenham que ser testados, do aqueles referidos anteriormente.

Este teste é realizado, então, através da análise do código fonte do sistema em causa, elaborando casos de teste para avaliar todas as possibilidades. Só assim é possível testar todas as variações relevantes resultantes do código.


Caixa Preta

Ao contrário do que acontece com o teste caixa branca, o teste caixa preta ignora o comportamento interno do sistema e foca-se, antes, na avaliação do comportamento externo. Neste caso, dados de entrada são fornecidos ao sistema para processamento e o resultado obtido é comparado com o resultado esperado. Assim sendo, os casos de teste derivam todos da especificação inicial, isto é, dos requisitos.

Quantas mais entradas foram fornecidas, melhor será o teste. Idealmente, todas as entradas possíveis deviam ser testadas, de forma garantir os melhores resultados. No entanto, isso implicaria muito tempo e muitos recursos. Para garantir a qualidade do teste de forma realista, normalmente são utilizados subconjuntos de entradas (alguns subconjuntos podem até ser processados similarmente) que se acredita maximizarem a riqueza do teste.

Caixa Cinzenta

O teste caixa cinzenta combina os métodos dos dois testes apresentados anteriormente. Assim sendo, através do uso desta técnica é possível aceder ao código fonte e aos algoritmos do software de forma a definir os casos de teste a ser aplicados, posteriormente, ao teste do comportamento externo do sistema.

Regressão

Esta técnica é aplicada a novas versões de software. A regressão consiste na aplicação de todos os testes já aplicados a versões ou ciclos de teste anteriores de um sistema, a uma nova versão ou a um novo ciclo. Para garantir a produtividade e a viabilidade dos testes, é recomendado que se faça a automação dos mesmos. Assim, sobre a nova versão ou o novo ciclo do sistema, os testes podem ser replicados com maior agilidade.

Técnicas não funcionais

Ao contrário do que acontece com todas as técnicas anteriores, as técnicas não funcionais permitem avaliar aspetos não funcionais, isto é, atributos de um sistema que não se relacionam com a funcionalidade, como a eficiência, adequação do sistema às restrições (organizacionais, tecnológicas, de tempo, ...), a adequação a normas, a confiabilidade, a usabilidade, etc. Exemplos de testes não funcionais:

  • Teste de desempenho - procura encontrar o limite de processamento de dados no melhor desempenho do sistema;
  • Teste de carga (ou de volume) - procura encontrar o limite de processamento de dados até que o sistema não consiga mais;
  • Teste de usabilidade - testa a capacidade do sistema de ser compreendido e utilizado;
  • Teste de confiabilidade - testa se o sistema é capaz de recolher, processar e apresentar os dados de forma correta (de acordo com as especificações iniciais);
  • Teste de recuperação - testa a capacidade de recuperação de um sistema após uma falha.