sexta-feira, 31 de dezembro de 2010

Automação Web

Existem vários aplicativos para efectuar scipting de modo a automatizar as acções sobre um página web. Cada um deles com vários pontes fortes e com as suas falhas. Neste post vou abordar um “utilitário” que tenho usado nos últimos tempos com bastante frequência.

O watin pode ser obtido gratuitamente por enquanto a partir daqui Watin Homepage.

Efectuando o download da aplicação criamos um projecto no Visual C# Express Edition.

1. Criar projecto no Visual C# Express Edition

Para isto basta aceder ao C# Express Edition e criar um novo projecto. Um projecto do tipo “Console Application” serve perfeitamente o propósito aqui pretendido.

2. Efectuar o import da(s) bibliotecas existentes.

Extrair as dlls obtidas a partir do download do watin efectuado e adicionar as mesmas a uma sub pasta do projecto. Após esta operação importar como referência para o projecto. Esta operação pode ser efectuada acedendo ao menu de contexto das referências do projecto e adicionar uma nova referência. Para este exemplo em concreto basta adicionar a dll watin.core.dll.

3. Criar o script de automação

A partir deste momento temos o projecto pronto para arrancarmos com a codificação.

Adicionando um

   1:  using Watin.Core;

ao parte das referências da aplicação.


De seguida, e como este post funcionará apenas como um “Hello World” do watin apenas se irá aceder á página da google e pesquisar pelo blogue.



   1:  FireFox ff = new FireFox(http://www.google.com);
   2:  ff.TextField(Find.ByName(“f”)).TypeText(“http://softwareattest.blogspot.com/”)
   3:  ff.Button(Find.ByName(“q”)).Click();

A api desta aplicação pode ser consultada a partir da página da aplicação que pode ser consultada aqui.


A medida que for experimentando mais detalhes sobre esta api, vou publicando os aspectos importantes dessa experiência(s).


Bom, até à próxima.

quarta-feira, 8 de dezembro de 2010

State Transition Testing

Os testes de caixa preta são casos de testes construídos tendo como base as especificações e funcionalidades do software. Estes testes usam as descrições externas do software, incluindo especificações, requisitos e design para elaborar casos de teste. O tester selecciona entradas válidos e inválidos e determina a saída correcta. Neste tipo de testes não existe qualquer conhecimento da estrutura interna do objecto de teste.

Se é necessário executar um número infinito de testes então é necessário transformar esta infinidade numa quantidade adequada de trabalho. As técnicas de teste de software existem para reduzir o número de testes a ser executados, enquanto fornecem uma cobertura suficiente do sistema em análise.

State Transition Testing

A maioria dos sistemas nos quais é necessário efectuar testes, possuem um número demasiado grande, ou mesmo infinito de possíveis situações de teste. Por exemplo, apesar do facto de que um telemóvel possuir um número finito de funções, a utilização destas funções podem ser combinadas num número infinito de possibilidades. Este testes são usados quando o sistema, ou uma parte do sistema pode ser descrito como um diagrama de estados. Estes testes podem ser construídos para cobrir uma sequência típica de estados, cobrir todos os estados, verificar todas as transições, uma sequência especifica de transições ou testar transições inválidas.

Sendo assim temos de pegar num sistema e transforma-lo num diagrama de estados.

Desenhar o diagrama de estados associado ao objecto em testes

Um diagrama de estados é composto por estados e transições. Cada estado é geralmente representado por um circulo, e a transição por uma seta.

Mais informação sobre a construção de diagramas de transição de estados ver: (http://en.wikipedia.org/wiki/State_transition_table)

Determinar os estados iniciais, as entradas permitidas e os resultados esperados assim como os resultados finais

Depois de desenhado o diagrama há que determinar os estados iniciais (tipicamente pontos de entrada do caso em teste) e os estados finais (tipicamente os pontos de saída).

Determinar o nível de cobertura que se pretende alcançar

Existe uma série de modos diferentes de medir a cobertura quando usando testes por transição de estados. Num desses modos, a cobertura pode ser medida pelo número de sequências de transições. Esta medição é conhecida como “(n-1) switch”. N-Switch coverage representa a percentagem de sequencias de N-transições que são avaliadas por uma suite de testes. Os níveis de cobertura mais usado é o “0-Switch coverage” que define que é testado uma transição.

Desenhar a árvore de testes

A partir de uma tabela de transição de estados podemos definir um conjunto de casos de testes mínimos. Para tal devemos começar por colocar os estados iniciais como raiz da árvore e colocar todas as transições válidas para cada um destes estados. Repetir o passo anterior e colocar as transições válidas para cada um destes novos estdos. Repetiro processo até que não existam mais transições válidas. Não devem ser repetidas transições.

Definir os testes

Para determinar qual o conjunto de testes a executar deve-se pegar em todos os caminhos possíveis na árvore. Cada um destes caminhos dá origem a um caso de teste.

Exemplo

Um exemplo prático onde esta técnica pode ser aplicada é um típico workflow da gestão de defeitos. Pegando então nesse workflow temos o seguinte: (Obs: Por motivos de simplificação dos diagramas estão omitidas na análise as transições para o próprio estado)

out_thumb1

Tabela de Transições de estado

De seguida apresenta-se a tabela com as transições válidas no workflow definido pela imagem acima.

  Open Fixed ReOpen Answer Only Rejected Closed
Open   X     X  
Fixed     X     X
ReOpen   X     X  
AnswerOnly            
Rejected     X X  
Closed            

A partir de uma tabela de transições de estados ou de um diagrama desenhamos então uma árvore, que nos ajudará a identificar os casos de teste necessários.

tree_thumb

A partir desta árvore identificam-se claramente cinco casos de teste para testar o workflow de gestão de defeitos que correspondem às seguintes sequências:

  • Open –> Fixed –> Closed;
  • Open –> Fixed –> Reopen-> Fixed;
  • Open –> Fixed –> Reopen->Rejected;
  • Open –> Rejected –> Answer Only;
  • Open –> Rejected –> Reopen;

Obviamente estas não correspondem a todas as possíveis combinações para a edição de um defeito. Mas é garantido que neste conjunto de casos de testes todas as transições são executadas e todos os estados estão cobertos. Muito mais poderia ser escrito sobre o tema mas penso que fica cá resumido o essencial.

 

Bom, até à próxima.