Padrões de automação da interface do usuário e práticas recomendadas para aplicativos de desktop

fundo

Atualmente, estou automatizando alguns testes para um plug-in para o MS Office. Estamos criando testes de interface do usuário codificada no VS 2010. Suponho que eu poderia usar a ferramenta " Construtor de teste da interface do usuário codificada ", mas isso não se adequa realmente ao meu caso específico.

Por isso, criei minha própria classe UI Map e métodos de extensão para cada UI Control / Map, onde adiciono diferentes funcionalidades de ação. Por exemplo, pressione os botões ou afirme alguns valores da interface do usuário.

Os cenários dos casos de teste estão nas classes de teste.

Eu sou novo nesta área e também sou novo em trabalhar como testador de automação.

A questão

As pessoas teriam a gentileza de compartilhar suas experiências e conselhos sobre algumas boas práticas para automação de teste em aplicativos de desktop, do ponto de vista de programação / design?

A melhor prática para o teste de automação da interface do usuário é fazer o mínimo possível. As interfaces de usuário são alteradas com frequência, o que significa que você precisa constantemente atualizar sua automação. Geralmente, é preferível estruturar o código do produto de uma maneira que permita testes automatizados sem a UI Automation.

Dito isto, você nem sempre pode se livrar da automação da interface do usuário. Você mencionou o escritório, então eu presumo que você esteja codificando para Windows e usando .Net. Eu faço bastante no meu trabalho atual. Aqui estão algumas das coisas que aprendi.

1) Veja as bibliotecas UIAutomation que foram introduzidas no .Net 3.0. Eles fornecem uma biblioteca extensa e bastante simples de usar para automação. (http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2) Faça o download do UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3) Torne as UIs do seu produto automatizáveis.

3a) Se for WPF, coloque os AutomationIDs em tudo.

3b) Tente criar nomes distintos de classe de controle e janela (nomes de classe de interface do usuário, não nome de classe de código-fonte). Se você não sabe o que quero dizer, carregue o UI Spy e comece a olhar para o Windows. Observe quantas janelas em aplicativos diferentes têm um nome de classe # 32770. Este é o nome da classe para uma caixa de diálogo do Windows. Qualquer janela que estenda a caixa de diálogo e não defina seu próprio nome, o padrão é esse. Isso causa todo tipo de sofrimento do ponto de vista da automação da interface do usuário.

4) Evite instruções Thread.Sleep (). Tente usar garçons (consulte a documentação do UIAutomation).

5) NUNCA misture o código de teste com o código de automação da interface do usuário. Crie bibliotecas separadas para executar a automação da interface do usuário. Chame essas bibliotecas de seus testes. Quando a interface do usuário é alterada, isso facilita muito a atualização da automação.

6) Sempre registre um ouvinte para um evento de interface do usuário antes de executar a ação que causaria o disparo do evento. Na prática, isso significa que você estará trabalhando com threads.

6a) Exemplo: não comece a aguardar um evento Janela aberta depois de clicar em um botão para abrir a janela. A janela pode abrir antes do garçom ser registrado e nunca receber o evento.

7) Nunca assuma que a janela que acabou de abrir é a que você deseja. Todos os tipos de janela podem abrir inesperadamente no Windows.

Eu poderia continuar mais, mas isso está ficando um pouco longo.

Crie testes funcionais a partir de casos de uso reutilizáveis

Quando chega a hora de testar o aplicativo de ponta a ponta in situ, você está realizando testes funcionais. Normalmente, você terá um conjunto de requisitos com os quais está testando e poderá construir vários casos de uso que os representam.

Como exemplo, considere o caso de uso "Login como usuário padrão". Sua estrutura de teste aciona o aplicativo, aguarda a tela de login, insere algumas credenciais, clica no botão de login e verifica se a tela apropriada agora está mostrando que o login foi bem-sucedido.

Depois de concluir o caso de uso "Efetuar login como usuário padrão", você desejará desenvolver algo para fazer outra coisa, talvez o caso de uso "Editar meus detalhes do usuário". Você não deseja repetir todo o código do caso de uso "Login como usuário padrão", portanto, basta fazer uma referência ao código da estrutura de teste que faz isso.

Isso implica que você tem algum tipo de teste funcional abrangente que contém uma lista de casos de uso. Esses casos de uso contêm os métodos da estrutura de teste para causar o comportamento do aplicativo (clique no botão X) e verificar o comportamento (a tela ficou azul).

No geral, você pode criar um corpo de casos de uso reutilizáveis ​​que visam sequências específicas e testam respostas específicas e, em seguida, agrega-os em vários testes funcionais que se correlacionam estreitamente com os requisitos de negócios. Depois de implementá-lo, você estará em uma ótima posição para automatizar completamente todo o processo de criação .

Se você estiver interessado em ler mais, eu escrevi sobre essa abordagem em outro lugar, mas o artigo tem como alvo aplicativos da Web em Java (usando Maven e SeleniumRC), em vez de aplicativos de desktop que você solicitou.