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

Fonte: aprendis
Saltar para a navegaçãoSaltar para a pesquisa
Sem resumo de edição
 
Linha 3: Linha 3:
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==
==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 21: Linha 21:
* Interface pouco clara/inadequada, etc.
* Interface pouco clara/inadequada, etc.


==Atributos a avaliar==
==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:
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:
Linha 65: 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==
==Técnicas de Teste ==


===Caixa Branca===
===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 78: 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 85: 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 100: 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 11h58min 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

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

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

</slideshow>