Teste de Software
Princípios do teste de software Conforme a Lei de Pareto, 80% dos erros podem ser localizados em 20% do projeto, geralmente nos módulos principais do sistema; A atividade de teste não prova a ausência de erros, apenas a existência dos mesmos; Bons casos de teste são aqueles que encontram falhas no sistema até então não descobertas; Bons casos de teste são projetados levando em conta os requisitos do projeto;
Princípios do teste de software Um critério que pode ser utilizado para determinação do esforço a ser gasto na atividade de teste de software é verificar qual o grau de severidade das conseqüências advindas do seu mau funcionamento; A probabilidade de encontrar um erro numa determinada parte do sistema é proporcional ao número de erros já encontrados nesta parte;
Princípios do teste de software A maior parte dos autores concorda que os programas devem, preferencialmente, ser testados por pessoas não envolvidas no processo de desenvolvimento, por uma equipe independente. Pode haver também a interação dos desenvolvedores com a equipe independente, justificando as decisões tomadas durante o projeto. Esta abordagem ajuda na revisão do projeto.
Objetivos do teste no início de cada fase verificar se esta etapa do projeto reflete exatamente os requisitos e definições da fase imediatamente anterior, para com isso garantir que o produto encomendado e o gerado pela atividade de desenvolvimento do software sejam os mesmos, através dos diferentes níveis de refinamento do projeto; verificar se não existem erros de lógica no projeto e código, no fluxo de dados, no entendimento de requisitos, de codificação, tipográficos ou de interface em todas as fases do projeto;
Objetivos do teste identificar e interferir na presença do erro, iniciandose a depuração, sendo que quanto antes for descoberta a falha, menos custoso será para adequála; ter em mente que, uma vez que errar é humano e atividade de desenvolvimento de software é um exercício bastante complexo, os erros existem e devem ser descobertos. Portanto, o sucesso em um teste consiste em descobrir os erros e corrigí-los.
TESTE CAIXA PRETA Este tipo de teste examina alguns aspectos de um sistema sem se preocupar muito com a estrutura lógica interna do software. Estes testes são realizados nas interfaces do software, são utilizados para demonstrar que as funções do software são operacionais; que a entrada é adequadamente aceita e a saída é corretamente produzida; que a integridade das informações externas é mantida. O teste caixa preta tende a ser aplicado durante a últimas etapas da atividades de teste, uma vez que este tipo de teste desconsidera a estrutura de controle, a atenção se concentra do domínio da informação.
TESTE CAIXA BRANCA Utiliza a estrutura de controle do projeto procedimental para derivar casos de teste, assim usando métodos de teste de caixa branca, pode-se derivar os seguintes casos de teste: Garantia de que todos os caminhos independentes dentro de um módulo tenham sido exercitadas pelo menos uma vez; Exercício todas as decisões lógicas para valores falsos ou verdadeiros; Execução tem todos os laços em suas fronteiras e dentro de seus limites operacionais; e Exercício as estruturas de dados internas para garantir a sua validade
Testes estáticos ou testes humanos: não são feitos através da execução real do programa, mas sim através da execução conceitual do mesmo. Métodos classificados como estáticos são os de walkthrough, inspeções e peer rating. São utilizados principalmente para validar as primeiras etapas do projeto como: de elicitação de requisitos, projeto preliminar e projeto detalhado, podendo ser usados para validar o código também.
Testes dinâmicos: Requerem que o programa seja executado, e por isso seguem o modelo tradicional de teste de programa, no qual o programa é executado com alguns casos de teste e os resultados da execução são examinados para verificar se o programa operou de acordo com o esperado. São usados principalmente na validação do código em módulos e na integração geral do sistema.
Testes funcionais:uma vez que testes exaustivos não são viáveis, características do domínio de entrada são examinadas para que se tente descobrir formas de derivar um conjunto de dados de teste representativo que consiga exercitar completamente a estrutura do sistema. Os dados de teste precisam ser derivados de uma análise dos requisitos funcionais e incluir elementos representativos de todas as variáveis do domínio. Este conjunto deve incluir tanto dados de entrada válidos quanto inválidos. Geralmente, os dados no conjunto de dados de teste podem ser classificados em três classes: de fronteira, não de fronteira e especiais.
Testes estruturais: Diferentemente dos testes funcionais, que se preocupam com a função que o programa desempenha sem se preocupar com a maneira como a função foi implementada, o teste estrutural enfoca a implementação e a estrutura da função. Embora geralmente usado durante a fase de codificação, testes estruturais podem ser usados em todas as fase do ciclo de vida do software nas quais o software é representado formalmente. A intenção do teste estrutural é encontrar dados de teste que terão cobertura suficiente de todas as estruturas presentes na representação formal.
Testes de unidade: Concentra-se no esforço de verificação da menor unidade de projeto de software: o módulo. Através do uso da descrição do projeto detalhado como guia, caminhos de controle importantes são testados para descobrir erros dentro das fronteiras do módulo. Este teste baseia-se sempre na caixa branca, e esse passo pode ser realizado em paralelo para múltiplos módulos. Nos testes de unidade são verificados: a interface com o módulo, a estrutura de dados local, as condições de limite, todos os caminhos independentes através da estrutura de controle e todos os caminhos de tratamento de erros. Um caminho independente é qualquer caminho através do programa que introduza um novo conjunto de instruções de processamento ou uma condição nova
Testes de integração: O objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura do programa que foi determinada pelo projeto de forma sistemática, testando também a interface dos módulos. A integração pode ser incremental ou não-incremental. A integração não-incremental, executada através da abordagem do big-bang combinando-se antecipadamente todos os módulos, não costuma ser eficaz, dada a amplitude de um teste do programa como um todo. Torna-se difícil isolar um erro e, quando esses são corrigidos, novos erros são gerados na estrutura do programa. Já a integração incremental é mais eficiente, podendo seguir a abordagem top-down ou a bottom-up. Discussões sobre as vantagens e desvantagens relativas do teste de integração top-down versus bottom-up podemservistasem[2].
Testes de validação: O teste de validação pode ser considerado bem sucedido quando o software funciona da maneira esperada pelo cliente. Ou seja, verifica-se se o produto certo foi construído, seguindo a especificação de requisitos do software. A validação do software, na fase de testes, é realizada por meio de uma série de testes de caixa preta que demonstram a conformidade com os requisitos. Testes alfa e beta: São os testes de aceitação, feitos pelo usuário, que Testes alfa e beta: São os testes de aceitação, feitos pelo usuário, que dificilmente opera o sistema da forma prevista, e visam descobrir erros cumulativos que poderiam deteriorar o sistema no decorrer do tempo. O teste alfa é executado por um cliente nas instalações do desenvolvedor, sendo acompanhado pelo desenvolvedor, que registra os problemas encontrados no uso. O ambiente é controlado. Já o teste beta é realizado em uma ou mais instalações do cliente pelo usuário final do software. Geralmente o desenvolvedor não está presente. Assim, o teste beta é uma aplicação real do software, sem que haja controle por parte do desenvolvedor. Os problemas são registrados pelo usuário e repassados regularmente ao desenvolvedor, que corrige o software antes de lançar o produto para venda.
Teste de segurança: O teste de segurança tenta verificar se todos os mecanismos de proteção embutidos em um sistema o protegerão de acessos indevidos. Todas as formas de ataque devem ser simuladas. A finalidade é dificultar o acesso indevido de forma que seja mais interessante e barato obter a informação de forma correta e legal. Testes de estresse: O teste de estresse é feito para confrontar o sistema com situações anormais. O teste de estresse executa o sistema de forma que exige recursos em quantidade, freqüência ou volume anormais. Teste de desempenho: O teste de desempenho é idealizado para testar o desempenho do software quando executado dentro do contexto de um sistema integrado. Algumas vezes os testes de desempenho são combinados com os de estresse e podem ser executados durante todo o processo de desenvolvimento.
Teste de caminho básico: possibilita que o projetista do caso de teste derive uma medida da complexidade lógica de uma projeto procedimental e use essa medida como guia para definir uma conjunto básicos de caminhos de execução, ou seja estabelecer um limite máximo do número de testes que deve ser projetado e executado. Há a garantia de executar pelo menos uma vez cada instrução do programa durante o teste.
Teste de comparação: quando é dada mais de uma solução de software para um problema, então é comparada as duas soluções; pode ser testado a consistência dos produtos. Teste de caminho básico: possibilita que o projetista do caso de teste derive uma medida da complexidade lógica de uma projeto procedimental e use essa medida como guia para definir uma conjunto básicos de caminhos de execução, ou seja estabelecer um limite máximo do número de testes que deve ser projetado e executado. Há a garantia de executar pelo menos uma vez cada instrução do programa durante o teste.