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

Fonte: aprendis
Saltar para a navegaçãoSaltar para a pesquisa
m (uma edição)
 
Sem resumo de edição
 
(Há 6 revisões intermédias de 2 utilizadores que não estão a ser apresentadas)
Linha 1: Linha 1:
[[Category:Aprendis]]
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.
A fase de testes, num processo de desenvolvimento de sistemas de informação, é fundamental 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 12: 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 24: 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 71: 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 86: 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 94: 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 114: Linha 101:
* '''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" >
<small>[http://mediawiki.gim.med.up.pt/index.php/Sistemas_de_Informa%C3%A7%C3%A3o_em_Sa%C3%BAde Voltar]</small>
;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>