Testes a sistemas de informação

Fonte: aprendis
Revisão em 11h58min de 9 de fevereiro de 2017 por Rcorreia (discussão | contribs)
(dif) ← Revisão anterior | Revisão atual (dif) | Revisão seguinte → (dif)
Saltar para a navegaçãoSaltar para a pesquisa

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.

Informação para slides

<slideshow style="flower" headingmark="⌘" incmark="…" scaled="true" >

author
Vários autores
subfooter
Predefinição:Date
footer

</slideshow>