Teste automatizado do aplicativo de desktop:visão geral de conveniência e frameworks

Introdução

ROI

ROI =Lucro / Despesas
ou
ROI =(Lucro – Despesas) / Despesas

Nesta fase, precisávamos de um pequeno protótipo que nos ajudasse a estimar todas as despesas necessárias. Ele mostrou resultados muito peculiares:realizar testes de aceitação leva aproximadamente o mesmo tempo que automatizar esse processo. A princípio, essa informação parecia questionável, mas quando investigamos mais a fundo, os motivos ficaram claros:

• Os novos especialistas em controle de qualidade podem ter uma compreensão limitada das etapas descritas nos casos de teste. Quando isso acontecer, algumas pessoas estarão envolvidas no teste de aceitação para ajudar a entender melhor a situação. Aqui, também devemos ter em mente a questão de quão relevantes são as informações que temos sobre as configurações e requisitos do ambiente.
• Às vezes, as pessoas envolvidas no teste de aceitação passam algum tempo aprendendo a documentação técnica.
• O próprio aplicativo interage com um conjunto específico de serviços. Se um deles não estiver disponível, os especialistas em QA menos experientes gastarão tempo descrevendo bugs que os desenvolvedores, por sua vez, investigarão. Como resultado, o tempo é desperdiçado porque o serviço necessário simplesmente não foi executado corretamente após um blecaute/atualização de hardware/reinicialização do computador.
• Os computadores dos testadores de controle de qualidade não são muito poderosos. Se não houver SSD, você já notará durante a instalação. Além disso, se o aplicativo estiver trabalhando com carga pesada, é possível que um arquivo de paginação lento seja usado.
• Para ser honesto, nos empolgamos e esquecemos que estamos trabalhando com automação. A propósito, você fechou a guia Youtube no seu navegador?

ROI =Lucro / Despesas =472 / 80 =5,9

Claro, alguns dos aspectos aqui são estimados. Para avaliar nossos próprios cálculos, passamos algum tempo investigando os recursos oferecidos por soluções pagas e várias calculadoras de ROI. Com isso, calculamos o valor médio de ROI de 2 ou 3, o que é um ótimo resultado.

Estruturas existentes

• Os testes serão desenvolvidos e executados em máquinas Windows
• A estrutura deve ser adaptada para testar aplicativos de desktop
• Os testes de interface do usuário podem ser integrados ao processo de CI. Já estávamos usando Jenkins, então era preferível aqui
• A capacidade de escrever testes em um IDE amigável – ele precisa ter realce de sintaxe, navegação de script de teste e conclusão de código no estilo IntelliSense
• Despesas mínimas com treinamento de controle de qualidade. Por alguns motivos, nossos especialistas em controle de qualidade não quiseram escrever testes no Brainfuck
• É preferível uma comunidade no Stack Overflow, MSDN etc.

Teste concluído

--no-sandbox
program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent

• IDE que você deseja fechar
• Compatibilidade com scripts de 1996
• Um gravador para não escrever tudo manualmente
• Outra inspeção, mas com sinos e assobios
• 2 tipos de respostas de suporte técnico
• Documentação que não representa a realidade

IU codificada

• Um poderoso IDE pago
• Toda infraestrutura já criada para testes:tanto do lado do IDE quanto do nosso CI
• A capacidade de pedir ajuda a qualquer desenvolvedor do nosso projeto porque estamos escrevendo testes em C# no mesmo IDE
• Uma grande quantidade de documentação de boa qualidade
• Alguns tristes especialistas em controle de qualidade que colocaram seu código na parte gerada automaticamente da classe e o perderam durante o processo de geração automática
• Muito código gerado que funciona e que você precisa submeter a uma revisão rigorosa
• Uma abordagem escandalosamente transparente para CI:você pode escrever código para iniciar testes por meio do mstest com os olhos fechados
• Uma gigante vermelha da automação que morre lentamente, que cresce constantemente a partir de novos testes e está perigosamente perto de se transformar em uma anã branca desbotada representada por uma máquina absolutamente isolada com software irreversivelmente obsoleto ou em uma explosão de supernova quando o projeto implode sob o pressão de novas atualizações.

TestStack.Branco

var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);

var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);

var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();

app.WaitWhileBusy();

public class InitializeOption {
//
// Summary:
//     This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }

//
// Summary:
//     Specify the unique identification for your window. White remembers the location
//     of UIItems inside a window as you find them. Next time when items inside the
//     same window is found they are located first based on position which is faster.
//
// Parameters:
//   identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}

• Documentação decente
• Acesso ao código-fonte
• Uma pequena comunidade
• A necessidade de explicar a todos os especialistas de controle de qualidade que o comportamento do controle é implementado por meio da classe Pattern
• Um repositório antigo do qual definitivamente precisaríamos fazer um fork

Ápio

• A capacidade de testar a funcionalidade do aplicativo que requer interação com um navegador (abertura da página de feedback, ativação on-line, verificação de entrega de e-mail) no escopo de uma infraestrutura e um teste
• A capacidade de trabalhar com qualquer edição do Visual Studio
• A capacidade de testar um aplicativo de desktop que usa um navegador para renderizar a interface do usuário. Um bom exemplo disso seria o Azure Data Studio
• Todas as vantagens que temos com a IU codificada
• Uma estrutura gratuita que a Microsoft recomenda usar
• Infraestrutura familiar aos especialistas de controle de qualidade que trabalharam com o Selenium
• Um repositório atualizado com novos commits
• Uma comunidade decentemente grande que, no entanto, não é tão grande quanto a comunidade da IU codificada
• Um gravador com funcionalidade limitada
• A necessidade de executar um aplicativo de driver para teste. Não é muito conveniente, mas tem sua própria funcionalidade de registro
• Muitas oportunidades para dar um tiro no pé devido à infeliz herança do WindowsElement do AppiumWebElement

Conclusão