Teste de desempenho com Digital.ai Continuous Testing

BACKGROUND

No mundo do teste de software, o Teste de Desempenho pode significar coisas diferentes para várias equipes e indivíduos, dependendo do que eles estão testando. Por exemplo, o teste de carga e o teste de estresse usando ferramentas como JMeter ou SoapUI são mais comumente associados ao teste de desempenho para validar o servidor de back-end de um aplicativo quando vários usuários interagem com o aplicativo simultaneamente.

No entanto, o Teste de desempenho para iOS ou Android Mobile Web e aplicativos nativos é uma área que poucas organizações exploraram, em parte porque poucas ferramentas de mercado fornecem uma solução decente de Teste de desempenho para dispositivos móveis.

As organizações com aplicativos voltados para o cliente priorizaram o teste de automação para dispositivos móveis nos últimos anos. No entanto, à medida que os aplicativos crescem, também aumenta a demanda dos clientes por aplicativos que funcionem de maneira otimizada e sem interrupções. Por exemplo, suponha que um usuário baixe um aplicativo da AppStore e tenha problemas como carregamento lento ou travamentos. Nesse caso, eles provavelmente mudarão para outro aplicativo que atenda às suas necessidades.

Embora os scripts de automação tradicionais se concentrem fortemente no aspecto funcional do aplicativo, eles não validam outros elementos críticos do desempenho do aplicativo. Por exemplo, eles não validam o tempo necessário para navegar e chegar a uma nova página, picos de CPU, memória e uso de bateria ou quaisquer chamadas de rede desnecessárias feitas durante os fluxos do usuário. Esses são desafios diários que os usuários enfrentam, mas as organizações falham em enfatizar o teste dessas áreas de aplicativos móveis.

como funciona Digital.ai Desafio de Abordagem?

O verdadeiro valor do teste de desempenho em dispositivos móveis é mensurável quando você pode executar um grande número de testes de desempenho em vários modelos de dispositivos e versões de sistema operacional.

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 uma variedade de modelos de dispositivos e versões de sistema operacional fornecerá uma imagem melhor.

Mas como você dimensiona o Teste de desempenho em dispositivos móveis para medir esses dados?

Digital.ai apresenta comandos que podem ser implementados dentro de um Appium Script Funcional; isso significa que podemos combinar um Script de Automação Funcional com Teste de Desempenho.

Se observarmos um Appium Script Funcional simplificado para um cenário em que estamos testando a funcionalidade de Login de um aplicativo, podemos ver que o teste é direto. Primeiro, preenchemos o campo de nome de usuário e senha, clicando no botão Login até finalmente chegarmos à próxima página:

Se fôssemos implementar o Teste de Desempenho neste Appium Script Funcional, seria mais ou menos assim:

Antes de o Script clicar no botão Login, iniciamos uma Transação de Desempenho e, assim que chegamos à próxima página, encerramos a Transação de Desempenho.

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

Podemos medir quanto tempo demorou 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 quando clicamos no botão Login.

Também podemos simular uma condição de rede diferente para ver como o usuário final experimenta o aplicativo quando está em diferentes condições de rede, e o perfil de rede é passado como o primeiro parâmetro:

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

Vejamos o tipo de métricas que capturamos e como elas podem nos ajudar a entender como foi a Transação de Desempenho.

Quais tipos de métricas estão sendo capturados como parte de uma transação de desempenho?

Para cada Transação de Desempenho, capturamos 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 da rapidez com que o conteúdo final foi pintado
• CPU: Gráfico com a CPU consumida, 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 a bateria consumida, valores médios e máximos da transação
• Rede: Total de KBs carregados/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 vendo é uma única transação de desempenho executada em um iPhone 13 Pro. Podemos reproduzir o Vídeo que foi capturado como parte da Transação de Desempenho e em relação ao vídeo, podemos acompanhar o consumo de CPU, Memória e Bateria.

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

O relatório que acabamos de ver se concentra em uma transação de desempenho individual. Mas imagine se agora tivermos executado a mesma transação de desempenho em escala em muitos modelos de dispositivos e versões de SO, podemos aproveitar nossos recursos de relatórios integrados para começar a observar as tendências.

Aqui está um relatório de exemplo que é filtrado para mostrar todas as transações que executei em uma compilação específica e uma transação específica (por exemplo, pesquisar um item no campo de pesquisa em um aplicativo nativo e entender quanto tempo demorou para carregar o próximo página no contexto de um aplicativo de varejo):

Este relatório me diz que o índice de velocidade foi significativamente maior no iOS versão 13.2 em comparação com outras versões do iOS.

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

Esse nível de informação permite que testadores e desenvolvedores de controle de qualidade investiguem modelos de dispositivos e versões de SO específicos para possíveis gargalos e identifiquem áreas para 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 os 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 nas medições da linha de base.

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

Se faz sentido implementar o Teste de Desempenho em Scripts Funcionais existentes ou criar novos Scripts autônomos para Teste de Desempenho dependerá da flexibilidade e complexidade da Estrutura de Automação atual.

No exemplo que dei anteriormente, o código é muito simplificado. Ainda 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 chaves.

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.

Se a complexidade da estrutura de automação existente dificultar o Teste de desempenho, é recomendável escrever scripts de automação separados exclusivamente para capturar métricas de desempenho.

Isso nos permite simplificar a lógica do código até certo ponto, permitindo-nos capturar as métricas apropriadas para os testes de desempenho com precisão.

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

Não há métricas universais ou padronizadas a serem aplicadas ao 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 números de referência podem variar de página para página ou de aplicativo para aplicativo.

Um exemplo de métrica que pode ser utilizada é o TTI (time-to-interactivity), que mede quanto tempo leva para um aplicativo se tornar utilizável após o usuário iniciá-lo.

Tem havido pesquisas feitas sobre isso, e algumas regras práticas úteis com base na pesquisa de HCI (interação humano-computador) nos dizem:

• Qualquer atraso acima de 500ms torna-se um evento “cognitivo”, o que significa que o usuário sabe que o tempo passou.
• Qualquer atraso acima de 3s torna-se um evento “reflexivo”, o que significa que o usuário tem tempo para refletir sobre o fato de que o tempo passou. Eles podem se distrair ou optar por fazer outra coisa.

Mas também existem outras métricas que são consideradas métricas-chave de desempenho, como:

• Maior tempo de resposta
• 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-500 ms é considerado padrão, enquanto qualquer valor acima de 500 ms está abaixo de um padrão aceitável.

É importante observar que não há uma resposta única para essas métricas, e determinar a linha de base pode variar de caso para caso. Portanto, é crucial entender o que é aceitável dentro do contexto do aplicativo que está sendo testado. Isso pode envolver a colaboração com os desenvolvedores de aplicativos para obter informações sobre o back-end do aplicativo, como o número de chamadas de rede feitas durante um determinado fluxo de usuário, operações pesadas que ocorrem no back-end ao interagir com determinados componentes do aplicativo e outros fatores relacionados.

Também pode ser útil executar alguns testes de desempenho para usar como linha de base.

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

Ao decidir quais dispositivos testar para 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 usados ​​com mais frequência para o Aplicativo que está sendo testado.

A partir daí, é recomendável selecionar os 5 a 10 principais dispositivos para testar consistentemente (o número exato pode variar dependendo da escala do projeto e da base de usuários). Essa abordagem ajuda a estabelecer uma linha de base para os dispositivos testados, permitindo medições de desempenho mais precisas.

Resumo

O teste de desempenho é fundamental para garantir que o software, os aplicativos e os sistemas possam lidar com cargas e tráfego esperados. Ele ajuda a identificar e resolver gargalos de desempenho e possíveis falhas antes deploymento, garantindo que os usuários finais tenham uma experiência perfeita.

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

O valor do Teste de desempenho reside na capacidade de identificar problemas no início do processo de desenvolvimento, reduzindo os custos associados à correção deles posteriormente. Além disso, ajuda 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 afetam o desempenho. O Teste de Desempenho é essencial para qualquer ciclo de desenvolvimento de software, do desenvolvimento ao deploymento e além.

 

Pronto para iniciar o teste de desempenho para dispositivos móveis? Contate-nos hoje em https://digital.ai/why-digital-ai/contact/