Testes a sistemas de informação: diferenças entre revisões
Sem resumo de edição |
Sem resumo de edição |
||
(Há 3 edições intermédias do mesmo utilizador que não estão a ser apresentadas) | |||
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 86: | 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 103: | 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>