Diferenças entre edições de "Testes a sistemas de informação"

Da aprendis
Ir para: navegação, pesquisa
 
(Há 5 edições intermédias do mesmo utilizador que não estão a ser apresentadas)
Linha 1: Linha 1:
A fase de testes, num processo de desenvolvimento de sistemas de informação, é fundamental para garantir a qualidade do sistema.
+
Os testes são uma [[Fases_de_um_sistema_de_informação| 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.
 
É 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.
 
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:
 
Tal como as anteriores, esta fase é composta por sub-fases:
 
* '''Planeamento''' da estratégia e do plano de teste;
 
* '''Planeamento''' da estratégia e do plano de teste;
Linha 11: Linha 11:
 
* '''Entrega''' da documentação final.
 
* '''Entrega''' da documentação final.
  
 
+
==Fontes de Erros ==
----
+
===Fontes de Erros===
+
  
 
* Especificação errada e/ou incompleta dos requisitos;
 
* Especificação errada e/ou incompleta dos requisitos;
Linha 23: Linha 21:
 
* Interface pouco clara/inadequada, etc.
 
* 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:
 
+
===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:
 
* Funcionalidade:
 
** Capacidade de um sistema de fornecer as funcionalidades que satisfazem as necessidades do utilizador;
 
** Capacidade de um sistema de fornecer as funcionalidades que satisfazem as necessidades do utilizador;
Linha 70: Linha 65:
 
*** Capacidade de substituição (capacidade de substituir outro sistema num contexto e ambiente específicos).
 
*** Capacidade de substituição (capacidade de substituir outro sistema num contexto e ambiente específicos).
  
 +
==Técnicas de Teste ⌘==
  
----
+
===Caixa Branca ⌘===
===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:
 
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 condição,
Linha 85: Linha 78:
 
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.
 
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 ⌘===
'''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.
 
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.
 
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.
Linha 93: Linha 85:
 
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'''
+
 
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.
 
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 ⌘===
'''Regressão'''
+
 
Esta técnica é aplicada a novas versões de software.
 
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.
 
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 ⌘===
 
+
'''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.
 
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:
 
Exemplos de testes não funcionais:
Linha 112: Linha 100:
 
* '''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 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.
 
* '''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: {{date}}
 +
;footer:
 +
</slideshow>

Edição atual desde as 13h58min de 9 de fevereiro de 2017

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

Title
Testes a sistemas de informação
Author
Vários autores
Subfooter
13h58min de 9 de fevereiro de 2017