Testes de desempenho com Digital.ai Continuous Testing

Contexto

No mundo dos testes de software, o Teste de Desempenho pode ter significados diferentes para diversas equipes e indivíduos, dependendo do que estão testando. Por exemplo, Testes de Carga e Testes de Estresse, utilizando ferramentas como JMeter ou SoapUI, são mais comumente associados ao Teste de Desempenho para validar o servidor backend de uma aplicação quando múltiplos usuários interagem com ela simultaneamente.

No entanto, os testes de desempenho para aplicativos nativos e web móveis iOS ou Android são uma área pouco explorada pelas organizações, em parte porque poucas ferramentas no mercado oferecem uma solução adequada para testes de desempenho em dispositivos móveis.

Nos últimos anos, as organizações com aplicativos voltados para o cliente priorizaram os testes automatizados para dispositivos móveis. No entanto, à medida que os aplicativos crescem, aumenta também a demanda dos clientes por aplicativos que funcionem de forma otimizada e sem interrupções. Por exemplo, imagine que um usuário baixe um aplicativo da App Store e encontre problemas como carregamento lento ou travamentos. Nesse caso, ele provavelmente optará por outro aplicativo que atenda às suas necessidades.

Embora os scripts de automação tradicionais se concentrem principalmente no aspecto funcional do aplicativo, eles falham ao não validar outros elementos críticos do desempenho. Por exemplo, não validam o tempo de navegação e carregamento de uma nova página, picos de uso de CPU, memória e bateria, ou chamadas de rede desnecessárias durante o fluxo do usuário. Esses são desafios diários enfrentados pelos usuários, mas as organizações não priorizam o teste dessas áreas em aplicativos móveis.

Como a Digital.ai Desafio de abordagem?

O verdadeiro valor dos testes de desempenho em dispositivos móveis torna-se mensurável quando é possível executar um grande número de testes de desempenho em diversos modelos de dispositivos e versões de sistemas operacionais.

Testar o desempenho de um único dispositivo pode não refletir com precisão o que os usuários realmente enfrentam, mas usar tendências e entender como uma única transação se comportou em diversos modelos de dispositivos e versões de sistemas operacionais fornecerá uma visão mais precisa.

Mas como dimensionar os testes de desempenho em dispositivos móveis para mensurar esses dados?

Digital.ai Introduz comandos que podem ser implementados em um Script Funcional do Appium; isso significa que podemos combinar um Script de Automação Funcional com Testes de Desempenho.

Se analisarmos um script Appium funcional simplificado para um cenário em que estamos testando a funcionalidade de login de um aplicativo, podemos ver que o teste é simples. Primeiro, preenchemos os campos de nome de usuário e senha, clicando no botão "Entrar" até finalmente chegarmos à próxima página:

Se implementássemos testes de desempenho neste script funcional do Appium, ele ficaria mais ou menos assim:

Antes que o script clique no botão de login, iniciamos uma transação de desempenho e, assim que acessamos a próxima página, finalizamos a transação de desempenho.

Capturar a transação de desempenho para preencher os campos de nome de usuário e senha é menos importante, visto que inserir o texto a partir de um script de automação pode não representar com precisão quanto tempo o usuário realmente leva para inserir suas credenciais.

Podemos medir quanto tempo levou para navegar da página de login para a próxima página ou se houve picos no consumo de CPU, memória ou bateria ao clicar no botão de login.

Também podemos simular diferentes condições de rede para ver como o usuário final interage com o aplicativo em diferentes condições de rede, sendo o Perfil de Rede passado como primeiro parâmetro:

driver.executeScript(“seetest:client.startPerformanceTransaction(\”4G-average\”)”);

Vamos analisar os tipos de métricas que coletamos e como elas podem nos ajudar a entender como ocorreu a Transação de Desempenho.

Que tipos de métricas são coletadas como parte de uma transação de desempenho?

Para cada Transação de Desempenho, coletamos as seguintes métricas:

• Duração: Duração de toda a transação, do início ao fim.
• Índice de velocidade: Pontuação geral calculada com base na rapidez com que o conteúdo final foi pintado.
• CPU: Gráfico com o consumo de CPU, valores médios e máximos da transação.
• Memória: Gráfico com a memória consumida, valores médios e máximos da transação.
• Bateria: Gráfico com o consumo de bateria, valores médios e máximos da transação.
• Rede: Total de KBs enviados/baixados durante a transação, com base no perfil de rede aplicado.
• Chamadas de rede: Todas as chamadas de rede feitas durante a transação

O que estamos analisando é uma única transação de desempenho executada em um iPhone 13 Pro. Podemos reproduzir o vídeo capturado como parte da transação e, em relação ao vídeo, acompanhar o consumo de CPU, memória e bateria.

Como este relatório me ajuda a entender as tendências e os possíveis gargalos?

O relatório que acabamos de analisar se concentra em uma transação de desempenho individual. Mas imagine se agora executássemos a mesma transação de desempenho em larga escala, em diversos modelos de dispositivos e versões de sistemas operacionais. Poderíamos aproveitar nossos recursos de geração de relatórios integrados para começar a analisar tendências.

Segue um exemplo de relatório filtrado para mostrar todas as transações que executei em uma versão específica e para uma transação em particular (por exemplo, pesquisar um item no campo de busca de um aplicativo nativo e entender quanto tempo levou para carregar a próxima página no contexto de um aplicativo de varejo):

Este relatório indica que o Índice de Velocidade foi significativamente maior na versão 13.2 do iOS em comparação com outras versões do iOS.

Da mesma forma, podemos analisar as tendências de outras métricas também, como CPU, memória e bateria:

Esse nível de informação permite que os testadores de controle de qualidade e os desenvolvedores investiguem modelos de dispositivos e versões de sistemas operacionais específicos em busca de possíveis gargalos e identifiquem áreas de melhoria no aplicativo móvel que está sendo testado.

É importante observar que pode haver diferenças de desempenho entre diferentes dispositivos ou redes. É comum ver uma variação de até 30% entre dispositivos, o que não indica necessariamente um problema grave de desempenho. No entanto, problemas de desempenho podem causar diferenças de 10 a 100 vezes maiores em relação às medições de referência.

Preciso implementar testes de desempenho em scripts de automação funcional existentes?

A decisão de implementar testes de desempenho em scripts funcionais existentes ou criar novos scripts independentes para testes de desempenho dependerá da flexibilidade e complexidade da estrutura de automação atual.

No exemplo que dei anteriormente, o código está bastante simplificado. Mesmo assim, vamos pensar na mesma abordagem no contexto de um framework de automação existente. Muitas outras dependências e camadas podem estar envolvidas ao chamar um método para executar operações como clicar ou enviar teclas.

Vejamos um exemplo:

Adicionar mais lógica à estrutura de automação existente pode aumentar o tempo total necessário para executar o script automatizado, o que pode afetar negativamente os testes de desempenho e não fornecer métricas valiosas.

Caso a complexidade da estrutura de automação existente dificulte os testes de desempenho, recomenda-se a criação de scripts de automação separados, exclusivamente para a captura de métricas de desempenho.

Isso nos permite simplificar a lógica do código até certo ponto, possibilitando a captura precisa das métricas apropriadas para os testes de desempenho.

Que tipo de números de referência devo definir para garantir que os dados coletados sejam mensuráveis?

Não existem métricas universais ou padronizadas para medir o desempenho, pois cada organização e suas equipes definem a experiência do usuário para seu próprio aplicativo. Além disso, dependendo da complexidade do aplicativo, os valores de referência podem variar de página para página ou de aplicativo para aplicativo.

Um exemplo de métrica que pode ser usada é o TTI (tempo de interação), que mede quanto tempo leva para um aplicativo se tornar utilizável após o usuário tê-lo iniciado.

Já foram realizadas pesquisas sobre isso, e algumas regras práticas úteis baseadas em pesquisas de IHC (Interação Humano-Computador) nos dizem o seguinte:

• Qualquer atraso superior a 500 ms torna-se um evento "cognitivo", o que significa que o usuário sabe que o tempo passou.
• Qualquer atraso superior a 3 segundos torna-se um evento "reflexivo", o que significa que o usuário tem tempo para refletir sobre o fato de que o tempo passou. Ele pode se distrair ou optar por fazer outra coisa.

Mas existem também outras métricas consideradas métricas-chave de desempenho, tais como:

• Tempo de resposta mais alto
• Tempo Médio de Resposta
• Número máximo de solicitações

Se o tempo de resposta do seu servidor for lento, isso pode prejudicar a experiência do usuário. O Google PageSpeed ​​Insights recomenda um tempo de resposta do servidor inferior a 200 ms. Um intervalo de 300 a 500 ms é considerado padrão, enquanto qualquer valor acima de 500 ms está abaixo do padrão aceitável.

É importante ressaltar que não existe uma resposta única para todas as métricas e que a definição da linha de base pode variar de caso para caso. Portanto, é crucial entender o que é aceitável dentro do contexto da aplicação que está sendo testada. Isso pode envolver a colaboração com os desenvolvedores da aplicação para obter informações sobre o backend da aplicação, como o número de chamadas de rede realizadas durante um fluxo de usuário específico, operações complexas que ocorrem no backend ao interagir com determinados componentes da aplicação e outros fatores relacionados.

Também pode ser útil executar alguns testes de desempenho para usá-los como base de comparação.

Devo executar meus testes de desempenho em todas as combinações de dispositivos disponíveis?

Ao decidir quais dispositivos testar para os testes de desempenho, é importante considerar aqueles que geram mais receita. Determinar isso requer uma compreensão clara da base de usuários e dos tipos de dispositivos mais frequentemente usados ​​para o aplicativo que está sendo testado.

A partir daí, recomenda-se selecionar os 5 a 10 principais dispositivos para testes consistentes (o número exato pode variar dependendo da escala do projeto e da base de usuários). Essa abordagem ajuda a estabelecer uma base de referência para os dispositivos testados, permitindo medições de desempenho mais precisas.

Resumo

Os testes de desempenho são essenciais para garantir que softwares, aplicativos e sistemas suportem as cargas e o tráfego esperados. Eles ajudam a identificar e solucionar gargalos de desempenho e possíveis falhas antes da implementação, assegurando uma experiência perfeita para os usuários finais.

Em contraste com os scripts de automação tradicionais, os testes de desempenho visam medir o tempo que um usuário leva para navegar entre as páginas, identificar picos no consumo de CPU, memória e bateria e detectar chamadas de rede desnecessárias.

O valor dos testes de desempenho reside na capacidade de identificar problemas no início do processo de desenvolvimento, reduzindo os custos associados à sua correção posterior. Além disso, eles ajudam a estabelecer uma linha de base para métricas de desempenho que podem ser monitoradas e comparadas ao longo do tempo, fornecendo informações sobre como as mudanças no sistema impactam o desempenho. Os testes de desempenho são essenciais em qualquer ciclo de desenvolvimento de software, desde o desenvolvimento até a implantação e além.

 

Pronto para começar os testes de desempenho para dispositivos móveis? Entre em contato conosco hoje mesmo! https://digital.ai/why-digital-ai/contact/