You are on page 1of 10

PD-DATAPREV

Processo de Desenvolvimento de Software da Dataprev

Orientação – Visão Conceitual em Testes

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

ori_Visao_Conceitual_Testes.odt 1 de 10

Modelo 2.0

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

.............................................. 10 ori_Visao_Conceitual_Testes................. PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Visão Conceitual em Testes 6 Princípios de Teste........................0 ......................................................................................................................................... 8 7 Referências.............................................odt 3 de 10 Modelo 2............

testes caixa de vidro ou testes caixa clara.0 . conhecendo melhor o código. pois muitos programado- res já têm o hábito de executarem testes de caixa branca em seus códigos. • Defeitos de desempenho. Níveis e Tipos de Testes. • Defeitos de interface. o programador conhece o comporta- mento esperado do sistema (dessa forma pode identificar melhor as falhas). • Defeitos de inicialização e término. • O exercício de todas as decisões lógicas para valores verdadeiros e falsos.2 Testes de Caixa Branca (White Box) Também conhecidos como testes estruturais. 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. pois é desempenhado apenas através das funciona- lidades do sistema: o testador não está preocupado com o código. Acontece quando a codificação termina em alguma fase. PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Visão Conceitual em Testes 1 Finalidade Definir Abordagens. 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). Esses defeitos. ori_Visao_Conceitual_Testes. Geralmente é desempenhado pelo próprio programador durante a programação. e esse código vai para o grupo de testes. 2. ele pode identificar falhas que seriam mais difíceis aos olhos de outros. são tes- tes que conhecem a estrutura de implementação do software e são geralmente aplicados a unida- des pequenas de programas (unidades não integradas) [3].odt 4 de 10 Modelo 2. Também tem por finalidade apresentar os principais mitos e princípios existentes sobre testes.1 Testes de Caixa Preta (Black Box) Também conhecido como um teste funcional. de acordo com [3] são: • Funções incorretas ou ausentes. enfim. 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. 2. Essa prática é considerada complementar ao processo de programação. 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). 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.

confiabilidade. etc. en- tre outras coisas. • 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. 3 Níveis de Testes de Software (ou Estágios de Teste) Um plano de teste. • O exercício de estruturas de dados internas para garantir a sua qualidade. 3. Os testes de software podem ser aplicados no ciclo de desenvolvimento de software através de vários níveis. 3. Como os nomes são diferentes dependendo do autor. 3. Esses níveis vão desde o mais elementar. mas podem também ser aplicados Testes Caixa Preta (caso se deseje testar funcionalmente a unidade ou componente). PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Visão Conceitual em Testes • O exercício de todos os laços em suas fronteiras e dentro de seus limites operacionais. deve ser desenvolvido de acordo. São aplicados após os testes de unidade e integração terem sido executa- dos e o sistema já tenha em um estado estável. Nesse tipo de teste são geralmente aplicados testes Caixa Branca. 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. até o mais geral.1 Teste de Unidade Testes de pequenos elementos ou unidades do sistema [1]. Essas estratégias são necessárias para que testes possam ser desempenhados sem a necessida- de de todos os componentes estarem terminados. Geralmente desempenhado pelo pró- prio programador como sendo uma atividade complementar à implementação. Os níveis serão apresentados em detalhes a seguir.3 Teste de Sistema Tipo de teste de software que tem a finalidade de testar hardware e software integrados [2].0 .odt 5 de 10 Modelo 2. • Mista: mesclagem das duas estratégias. bem como a escolha do grupo de testes. 3. Geral- mente durante esse teste são verificados alguns requisitos não funcionais como performance. com os níveis de teste escolhido para o projeto.4 Teste de Aceitação (ou Homologação) ori_Visao_Conceitual_Testes.2 Teste de Integração Tem a finalidade de encontrar falhas quando pedaços de código são integrados. logo após terem sido aplicados testes de unidade. principalmente falhas de interface [2]. car- ga. o de unidade. Aqui são aplicados testes Caixa Preta. Os testes de integração devem ser desempe- nhados o mais cedo possível. o nível de aceitação. Testes de inte- gração geralmente aplicam testes de Caixa Preta [1]. vamos utilizar os nomes encontrados no padrão IEEE.

4 Teste de Segurança e Controle de Acesso ori_Visao_Conceitual_Testes. Têm como objetivo testar a apli- cação em um produto. 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. 4. PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Visão Conceitual em Testes Teste baseado em requisitos de alto nível.odt 6 de 10 Modelo 2. O cliente re- gistra todos os problemas encontrados e os relata ao desenvolvedor que fará as modificações ne- cessárias e entrega o produto final ao cliente. saídas que pareciam cla- ras ao analista podem ser não tão claras ao usuário em campo). 4 Tipos de Testes 4. Esse tipo de teste é conduzi- do em um ambiente controlado. O teste Alfa é realizado nas instalações do desenvolvedor. pode-se citar testar o Cadastro de um usuário no sistema.0 .2 Teste Funcional Com esse tipo de teste a funcionalidade geral do sistema em termos de regras de negócio é testada. bem como a adequação dos procedimentos de recuperação. Devem ser testadas condições válidas e inválidas. Como exemplo. O sistema deve ser capaz de retornar e informar ao usuário da impressão pendente. 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. Os testes de aceitação servem para identificar dis- cordâncias do software de acordo com esses requisitos. projetados e implementados para a demanda de testes da iteração (Teste Funcional).1 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. Esse tipo de teste é mais efetivo quando desempenhado por usuários ou seus representantes em um ambiente mais realístico possível. o desenvolvedor não está presente. 3. 4. Aqui são aplicados testes Caixa Preta.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.4. Já no teste Beta. O produto é usado pelo cliente com o desenvolvedor observando e registrando erros e problemas de uso. combinações estranhas de dados podem ser usadas. 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.

0 . recuperar uma conta de usuário em x segundos ou processar a transação y em x segundos. número de usuários.5 Teste de Performance Verifica o tempo de resposta e o processamento (para diferentes configurações. botões. O sistema não deve permitir que usuários não autorizados acessem dados sigilosos. Exemplo.8 Teste de Configuração ou Portabilidade Verifica o funcionamento do sistema em diferentes configurações de hardware e software. que executa todos os testes desenvolvidos ori_Visao_Conceitual_Testes. 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.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. 4.7 Teste de Estresse Verifica a funcionalidade do sistema em situações limite de transações ou fora da tolerância esperada. PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Visão Conceitual em Testes 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. 4.6 Teste de Volume (carga) Verifica o comportamento do sistema sob condições de carga de trabalho diferente do normal.odt 7 de 10 Modelo 2.10 Teste de Regressão Reexecução dos testes feita após uma manutenção corretiva ou evolutiva. 4. Devem ser testadas: • Compatibilidade do software hardware • Configuração do servidor • Tipos de conexão com a internet • Compatibilidade com o browser 4. Existem duas abordagens de testes de regressão: a total. 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.). tamanho do BD. 4. etc. Exemplos são: alta competição por recursos compartilhados como vários acessos/ transações no BD ou rede. cargas de trabalho.

a aplicação dessas combinações para o exercício de um software torna o teste inviável. 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. Mito 4: Testes precisam ser executados apenas uma ou duas vezes. 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 mitos são: Mito 1: É preciso testar todas as possibilidades de entradas em um software. além de precisar testar se aquela correção contém falha. visto que não são testadas todas as possibilidades de entradas em um software. Esse mito cai no mito 2. também é necessário testar se aquela correção afetou outra parte do software. O princípio 1 pode induzir a erros quando não acontece.odt 8 de 10 Modelo 2. 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. Isso acontece porque. o que se pode afirmar é que para aquele determinado conjunto de entradas não existem falhas. já que se encontram falhas com um conjunto de dados de teste. Os testes precisam ser repetidos sempre que forem encontradas falhas e algum tipo de correção for aplicada. Pode ser óbvio que os resultados ori_Visao_Conceitual_Testes. Mito 2: Um sistema testado é perfeito. Mito 3: Testes são usados para mostrar que o software não tem falhas. O motivo é que. 5 Mitos sobre Teste Em [1] são encontrados alguns mitos sobre testes de software. PD-DATAPREV Processo de Desenvolvimento de Software da Dataprev Orientação – Visão Conceitual em Testes anteriormente sempre que existir uma alteração.11 Reteste Execução de testes falhos (somente os falhos) novamente após seu conserto. Partindo da inverdade do mito 1. A ausência de falhas só poderia ser afirmada utilizando-se todas as combinações possíveis de entrada. A atividade de teste de software tem a finalidade de encontrar falhas e não a sua ausência. nada se pode afirmar. 4. Para isso são usadas algumas técnicas de projeto de casos de testes de softwares. podemos perceber que o mito 2 também é falso. 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. Com isso. para aquelas entradas que não foram testadas.0 . a parcial. mas. que executa apenas um subconjunto de testes somente para as dependências das áreas modificadas.

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

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