Testes Orientação Visão Conceitual em Testes Versão 0.3

Transcrição

1 Testes Versão 0.3 ori_visao_conceitual_testes.odt 1 de 10

2 Histórico de Revisões Data Versão Descrição Autor 23/04/ Versão inicial Fernanda Monteiro 07/10/ Verificação ortográfica Ana Eckel 22/10/ Verificação ortográfica Samuel Portela e Anália Lima Sumário 1 Finalidade Técnicas para Projeto de Casos de Teste (ou Abordagens de Teste) Testes de Caixa Preta (Black Box) Testes de Caixa Branca (White Box) Níveis de Testes de Software (ou Estágios de Teste) Teste de Unidade Teste de Integração Teste de Sistema Teste de Aceitação (ou Homologação) Testes Alfa e Beta 6 4 Tipos de Testes Teste de Sanidade Teste Funcional Teste de Recuperação de Falhas Teste de Segurança e Controle de Acesso Teste de Performance Teste de Volume (carga) Teste de Estresse Teste de Configuração ou Portabilidade Teste de Interface com o Usuário Teste de Regressão Reteste Mitos sobre Teste... 8 ori_visao_conceitual_testes.odt 2 de 10

3 6 Princípios de Teste Referências ori_visao_conceitual_testes.odt 3 de 10

4 1 Finalidade Definir Abordagens, Níveis e Tipos de Testes. Também tem por finalidade apresentar os principais mitos e princípios existentes sobre testes. 2 Técnicas para Projeto de Casos de Teste (ou Abordagens de Teste) As técnicas de projeto de casos de teste são classificadas em Caixa Branca ou Caixa Preta [3] e serão apresentadas a seguir. 2.1 Testes de Caixa Preta (Black Box) Também conhecido como um teste funcional, pois é desempenhado apenas através das funcionalidades do sistema: o testador não está preocupado com o código. O testador fornece as entradas ao componente ou ao sistema e examina uma saída (que falharão se não estiverem de acordo com os requisitos do sistema). Acontece quando a codificação termina em alguma fase, e esse código vai para o grupo de testes. Os defeitos investigados pelos testes Caixa Preta estão em uma classe de defeitos que os testes Caixa Branca não estão aptos a encontrar. Esses defeitos, de acordo com [3] são: Funções incorretas ou ausentes; Defeitos de interface; Defeitos de desempenho; Defeitos de inicialização e término. 2.2 Testes de Caixa Branca (White Box) Também conhecidos como testes estruturais, testes caixa de vidro ou testes caixa clara, são testes que conhecem a estrutura de implementação do software e são geralmente aplicados a unidades pequenas de programas (unidades não integradas) [3]. Geralmente é desempenhado pelo próprio programador durante a programação. Esse tipo de teste tem alguns benefícios como: o programador pode testar pequenas partes do programa (isso faz com que a depuração seja mais fácil); o programador conhece o comportamento esperado do sistema (dessa forma pode identificar melhor as falhas); enfim, conhecendo melhor o código, ele pode identificar falhas que seriam mais difíceis aos olhos de outros. Essa prática é considerada complementar ao processo de programação, pois muitos programadores já têm o hábito de executarem testes de caixa branca em seus códigos. Esse tipo de teste precisa garantir [4]: Que todos os caminhos independentes dentro de um módulo de software tenham sido exercitados pelo menos uma vez; O exercício de todas as decisões lógicas para valores verdadeiros e falsos; ori_visao_conceitual_testes.odt 4 de 10

5 O exercício de todos os laços em suas fronteiras e dentro de seus limites operacionais; O exercício de estruturas de dados internas para garantir a sua qualidade. 3 Níveis de Testes de Software (ou Estágios de Teste) Um plano de teste, bem como a escolha do grupo de testes, deve ser desenvolvido de acordo, entre outras coisas, com os níveis de teste escolhido para o projeto. Os testes de software podem ser aplicados no ciclo de desenvolvimento de software através de vários níveis. Esses níveis vão desde o mais elementar, o de unidade, até o mais geral, o nível de aceitação. Os níveis serão apresentados em detalhes a seguir. Como os nomes são diferentes dependendo do autor, vamos utilizar os nomes encontrados no padrão IEEE. 3.1 Teste de Unidade Testes de pequenos elementos ou unidades do sistema [1]. Geralmente desempenhado pelo próprio programador como sendo uma atividade complementar à implementação. Nesse tipo de teste são geralmente aplicados testes Caixa Branca, mas podem também ser aplicados Testes Caixa Preta (caso se deseje testar funcionalmente a unidade ou componente). 3.2 Teste de Integração Tem a finalidade de encontrar falhas quando pedaços de código são integrados, principalmente falhas de interface [2]. Podem ser aplicados de acordo com duas estratégias [1]: Bottom up: integração de módulos de baixo nível para a formação de módulos maiores; Top down: integração de módulos de alto nível substituindo módulos de baixo nível com stubs de teste para simular interfaces; Mista: mesclagem das duas estratégias. Essas estratégias são necessárias para que testes possam ser desempenhados sem a necessidade de todos os componentes estarem terminados. Os testes de integração devem ser desempenhados o mais cedo possível, logo após terem sido aplicados testes de unidade. Testes de integração geralmente aplicam testes de Caixa Preta [1]. 3.3 Teste de Sistema Tipo de teste de software que tem a finalidade de testar hardware e software integrados [2]. Geralmente durante esse teste são verificados alguns requisitos não funcionais como performance, carga, confiabilidade, etc. São aplicados após os testes de unidade e integração terem sido executados e o sistema já tenha em um estado estável. Aqui são aplicados testes Caixa Preta. 3.4 Teste de Aceitação (ou Homologação) ori_visao_conceitual_testes.odt 5 de 10

6 Teste baseado em requisitos de alto nível. Os testes de aceitação servem para identificar discordâncias do software de acordo com esses requisitos. Esse tipo de teste é mais efetivo quando desempenhado por usuários ou seus representantes em um ambiente mais realístico possível. Aqui são aplicados testes Caixa Preta Testes Alfa e Beta São processos de teste de validação bastante usados pelos desenvolvedores de software para descobrir erros que só o usuário final parece ser capaz de descobrir (instruções de uso podem ser mal interpretadas, combinações estranhas de dados podem ser usadas, saídas que pareciam claras ao analista podem ser não tão claras ao usuário em campo). Têm como objetivo testar a aplicação em um produto. O teste Alfa é realizado nas instalações do desenvolvedor. O produto é usado pelo cliente com o desenvolvedor observando e registrando erros e problemas de uso. Esse tipo de teste é conduzido em um ambiente controlado. Já no teste Beta, o desenvolvedor não está presente. O cliente registra todos os problemas encontrados e os relata ao desenvolvedor que fará as modificações necessárias e entrega o produto final ao cliente. 4 Tipos de Testes 4.1 Teste de Sanidade Com esse tipo de teste é possível avaliar se o build está estável o suficiente para ser submetido a testes mais detalhados, projetados e implementados para a demanda de testes da iteração (Teste Funcional). Este tipo de teste também é conhecido como Smoke test e tem o propósito de evitar que se desperdicem recursos de testes com um build não suficientemente estável para testes. 4.2 Teste Funcional Com esse tipo de teste a funcionalidade geral do sistema em termos de regras de negócio é testada. Devem ser testadas condições válidas e inválidas. Como exemplo, pode-se citar testar o Cadastro de um usuário no sistema. 4.3 Teste de Recuperação de Falhas Com esse tipo de teste o software é forçado a falhar de diversas maneiras para que seja verificado o seu comportamento, bem como a adequação dos procedimentos de recuperação. A recuperação pode ser automática ou exigir iteração humana. Como exemplo podemos citar a interrupção de uma impressão por falta de energia. O sistema deve ser capaz de retornar e informar ao usuário da impressão pendente. 4.4 Teste de Segurança e Controle de Acesso ori_visao_conceitual_testes.odt 6 de 10

7 Com esse tipo de teste o software é forçado a quebrar um mecanismo de proteção de acesso. Como exemplo temos: tentar logar no sistema através de um teclado virtual com usuário não autorizado. O sistema não deve permitir que usuários não autorizados acessem dados sigilosos. 4.5 Teste de Performance Verifica o tempo de resposta e o processamento (para diferentes configurações, cargas de trabalho, número de usuários, tamanho do BD, etc.). Exemplo, recuperar uma conta de usuário em x segundos ou processar a transação y em x segundos. 4.6 Teste de Volume (carga) Verifica o comportamento do sistema sob condições de carga de trabalho diferente do normal. O teste de volume submete grandes quantidades de dados ao sistema para determinar se limites que causam a falha do software são alcançados. 4.7 Teste de Estresse Verifica a funcionalidade do sistema em situações limite de transações ou fora da tolerância esperada. Exemplos são: alta competição por recursos compartilhados como vários acessos/ transações no BD ou rede. 4.8 Teste de Configuração ou Portabilidade Verifica o funcionamento do sistema em diferentes configurações de hardware e software. Devem ser testadas: Compatibilidade do software hardware Configuração do servidor Tipos de conexão com a internet Compatibilidade com o browser 4.9 Teste de Interface com o Usuário Devem ser testadas: Aparência e comportamento da interface o Como a informação é apresentada ao usuário o Quais controles da interface serão testados (caixa de diálogo, botões, menu) o Se os nomes das caixas e diálogos são intuitivos e consistentes Navegação Adequação a padrões Tempo para aprender como usar o programa 4.10 Teste de Regressão Reexecução dos testes feita após uma manutenção corretiva ou evolutiva. Existem duas abordagens de testes de regressão: a total, que executa todos os testes desenvolvidos ori_visao_conceitual_testes.odt 7 de 10

8 anteriormente sempre que existir uma alteração; a parcial, que executa apenas um subconjunto de testes somente para as dependências das áreas modificadas Reteste Execução de testes falhos (somente os falhos) novamente após seu conserto. 5 Mitos sobre Teste Em [1] são encontrados alguns mitos sobre testes de software. Esses mitos são: Mito 1: É preciso testar todas as possibilidades de entradas em um software. Essa afirmação é falsa pelo seguinte motivo: a combinação de todas as possíveis entradas de um software pode resultar em milhares ou milhões de possibilidades. Com isso, a aplicação dessas combinações para o exercício de um software torna o teste inviável. O que se busca com a atividade de teste de software é encontrar a maior quantidade de falhas utilizando um mínimo de esforço e tempo. Para isso são usadas algumas técnicas de projeto de casos de testes de softwares. Mito 2: Um sistema testado é perfeito. Partindo da inverdade do mito 1, podemos perceber que o mito 2 também é falso. O motivo é que, visto que não são testadas todas as possibilidades de entradas em um software, o que se pode afirmar é que para aquele determinado conjunto de entradas não existem falhas, mas, para aquelas entradas que não foram testadas, nada se pode afirmar. Mito 3: Testes são usados para mostrar que o software não tem falhas. A atividade de teste de software tem a finalidade de encontrar falhas e não a sua ausência. Esse mito cai no mito 2, já que se encontram falhas com um conjunto de dados de teste. A ausência de falhas só poderia ser afirmada utilizando-se todas as combinações possíveis de entrada. Mito 4: Testes precisam ser executados apenas uma ou duas vezes. Os testes precisam ser repetidos sempre que forem encontradas falhas e algum tipo de correção for aplicada. Isso acontece porque, além de precisar testar se aquela correção contém falha, também é necessário testar se aquela correção afetou outra parte do software. 6 Princípios de Teste Em [5][6] encontram-se alguns princípios que devem ser levados em consideração na hora de se projetar e desenvolver uma tarefa de teste. Esses princípios podem ser vistos a seguir: Princípio 1: Uma parte essencial do caso de teste é a definição da saída ou resultado esperado. O princípio 1 pode induzir a erros quando não acontece. Pode ser óbvio que os resultados ori_visao_conceitual_testes.odt 8 de 10

9 esperados devem aparecer no caso de teste, mas muitas vezes não é isso que acontece. Pode acontecer um desconhecimento das saídas esperadas e o testador usar o bom senso na análise. Princípio 2: Um programador deveria evitar testar seu próprio código. O princípio 2 é importante no sentido de que o próprio desenvolvedor pode se viciar em seu código. Isso faz com que ele não mais perceba falhas que para outras pessoas parecem óbvias. Outro motivo para o cumprimento desse princípio é que o próprio desenvolvedor pode não querer encontrar falhas em seu código para que não precise fazer correções. Por esse mesmo motivo é sugerido o princípio 3, tomando agora a aplicação do princípio 2 para um grupo de pessoas. Vale ressaltar que o princípio 2 vale apenas para testes de alto nível, ou seja, um desenvolvedor pode e deve executar e implementar testes de baixo nível em seu próprio código. Princípio 3: Uma organização desenvolvedora de software deveria ter uma equipe própria para os testes de alto nível. Princípio 4: Os resultados dos testes deveriam ser meticulosamente analisados. O princípio 4 é importante para a detecção dos sintomas das falhas. É necessário para se conhecer de onde vieram essas falhas e o motivo de sua existência. Isso ajuda na prevenção de novos defeitos. Princípio 5: Casos de teste devem ser escritos para entradas esperadas bem como não esperadas. O princípio 5 diz respeito à robustez do caso de teste. Com as entradas esperadas, busca-se testar se o programa não faz o que é preciso fazer. Com as entradas não desejadas, busca-se testar se o programa resulta em uma falha absurda. Como exemplo podemos citar uma entrada incorreta em um programa que faz com que ele trave ou que o programa simplesmente feche. Desse exemplo caímos também no princípio 6, que verifica que mesmo que uma entrada seja absurda, o programa tem que ser robusto o suficiente para suportar. Princípio 6: É necessário verificar se um programa não faz o que ele não foi designado a fazer. Princípio 7: É necessária a documentação do processo de teste. O princípio 7 é necessário para que, caso haja uma falha do sistema na hora dos testes, aquele esforço de invenção dos testes seja guardado e executado outra vez. Esse princípio é importante também no que diz respeito a testes que precisam ser executados novamente, como testes de regressão, logo após terem sido consertados alguns defeitos. Princípio 8: Não se deve planejar um esforço de teste assumindo que erros não vão ser encontrados. Os testes devem ser planejados com um cronograma que leva em consideração que algumas falhas vão ser descobertas e que levam um tempo para serem corrigidas. Isso é a importância do princípio 8. Deve-se sempre considerar que falhas sempre vão existir. Princípio 9: A probabilidade da existência de mais falhas numa seção do programa é ori_visao_conceitual_testes.odt 9 de 10

10 proporcional ao número de falhas já encontradas naquela seção. O princípio 9 é um fenômeno citado nas referências e que não se sabe ao certo o porquê dele. A probabilidade de encontrar erros é mostrada no gráfico abaixo: Princípio 10: Os testes deveriam ser integrados num processo de desenvolvimento de software. Os testes deveriam ser executados ao longo de todo ciclo de vida de desenvolvimento do software, não precisando esperar até o final. Isso facilita a depuração dos erros encontrados e é o que fala o princípio Referências [1] Ross, Kelvin. Pratical Guide to Software System Testing. K.J. Ross & Associates Pty. Ltd:1998. [2] Craig, Rick D.; Jaskiel, Stefan P. Systematic Software Testing. Artech House Publishers Boston, London: [3] Pressman, Roger S. Engenharia de Software. Tradução de José Carlos Barbosa dos Santos. São Paulo: Pearson Education do Brasil, [4] Loveland, Scott et al. Software testing techniques: Finding the Defects that Matter. Massachusetts: Charles River media, Inc, [5] Myers, Glenford J. The Art of Software Testing. New Jersey: John Wiley & Sons, Inc, [6] Burnstein, Ilene. Practical Software Testing: A Process-oriented Approach. New York: Springer, ori_visao_conceitual_testes.odt 10 de 10