Mostrando postagens com marcador Técnicas de Testes de software. Mostrar todas as postagens

Templates de Testes de Software




Encontrei neste site um conjunto bem completo de templates de testes de software. São mais de 70 Templates para serem usados durante todas as fases de testes de software. Entre eles, podem ser encontrados modelos de testes como:
  • Termo de aceite;
  • Plano de Testes;
  • Planejamento de Testes;
  • Testes unitários;
  • Especificação de testes;
  • Relatório de testes;
  • Checklists diversos;
  • Entre outros.

Material Validação e Testes de Software disponível para download




Este material pertence ao Professor Manuel Mendonça e está disponível para Download no site do DCC da UFBA


São 02 módulos ministrados para uma disciplina de Graduação na Universidade


  • Primeiro: Validação de Software
  • Segundo: Técnicas de Testes de Software

Tecnicas de Testes de Software - 2

Técnicas de testes para tela de inserção/alteração (Primeira parte)


.Fazer a inserção permutando os campos preenchidos/não preenchidos da mesma forma que foi apresentado na tela de busca (olhar tabela). No caso de telas com um número grande de campos, é impossível testar todas as combinações, então se define uma margem (25% por ex) de combinações que serão testadas.


.Inserir um registro com os tamanhos máximos de todos os campos.



Técnicas de Testes de Software - 1



Esta seqüência de artigos tem o objetivo de demonstrar algumas técnicas de testes simples, contribuindo para homologadores/analistas de testes em início de experiência. Espero que contribua.
____________________________________
Por Fernando Palma, Setembro de 2009



Técnica de teste para telas de pesquisa

Ao validar uma tela de pesquisa, o homologador deve fazer os seguintes testes:
☺ Testar todas as combinações existentes dos campos para garantir que a tela funciona. Para uma busca com “a” campos, existirão 2ª combinações.


Ex: 3 filtros são dispostos em uma pesquisa. Portanto, então seriam 8 combinações.


A melhor técnica para alcançar este fim, é utilização de números binários, como demonstrado a seguir: 
Ex: Imaginemos uma tela com os campos: Nome, Cidade e Estado.
Nome
Cidade
Estado
0
0
0
0
0
1
0
1
0
0
1
1
1
0
0
1
0
1
1
1
0
1
1
1
*Considerando “0” o campo não preenchido e “1” o campo preenchido.


Como a tabela demonstra, 8 combinações de busca são realizadas.
Mas estes não são todos os testes, pois para cada campo preenchido, o desenvolvedor deve testá-lo preenchendo uma vez com parâmetros que retorne(m) registros(s) e outra vez com parâmetros que não retorne registro. Então, seriam na verdade 2 (ª + 1) à 2 elevado a “a” mais 1 combinações diferentes.  No exemplo acima, seriam 16 combinações, na verdade.


Obs: Considerando que “R” represente um parâmetro que retorne registro(s) e “N” um parâmetro que não retorne nenhum registro.


Nome
Cidade
Estado
0
0
0
0
0
         1 (R/N)
0
        1 (R/N)
0
0
        1 (R/N)
        1 (R/N)
        1 (R/N)
0
0
        1 (R/N)
0
        1 (R/N)
        1 (R/N)
        1 (R/N)
0
        1 (R/N)
        1 (R/N)
        1 (R/N)




O interessante desta técnica é imaginar uma tela com diversos filtros. 6, 8, 15 filtros de pesquisa. Representariam estes valores elevado ao cubo, quando traduzido em testes. Três conclusões podem ser tiradas, portanto:

1- O gerente responsável pelo projeto de software deve definir o nível de qualidade que é requerido para o sistema. Baseado nesta especificação, ou melhor: neste requisito de qualidade, o analista de testes/homologador executa a metade, um terço, ou até 1% das combinações existentes.


2- Quando parte das combinações são executadas, cabe ao Analista de Testes definir quais delas serão escolhidas, por representarem maior risco de falhas.


3- Ao receber os requisitos do sistema, no inicio do projeto, o Analista de Testes deve prevenir com estimativas de quantidade de testes que serão gerados. Esta colaboração é importante para que haja um balanceamento  eficaz diante de escolhas, como esta: "quantos filtros existirão na tela?". Nem sempre o que é fácil de implementar é fácil de testar. Por isso, muitos analistas de testes já utilizam o conceito denominado "pontos de testes" para os requisitos de teste, que equivale aos "pontos de função" dos requisitos de sistema. 


Aguardem outras técnicas, em breve.