Como as equipes de aplicativos móveis QA testam conexões de celular ruins?

Como o Dima mencionou, o modo avião é um ótimo lugar para começar. Você pode colocar seu dispositivo no modo avião antes de tomar uma ação que acione as atualizações da rede, e então tomar a ação, ver como ele responde enquanto espera, e então tirá-lo do modo avião, e ver como ele responde após reconectar. Espero que sua aplicação tenha a lógica para tentar novamente e sincronizar corretamente.

Para ir mais fundo para testar no dispositivo, eu recomendo configurar uma rede wifi condicionada. Você pode fazer isso com seu Mac em cinco passos (mas você precisa de um cabo de rede):

1. Conecte um cabo Ethernet ao seu Mac (talvez você precise usar um adaptador Thunderbolt)
2. Instale o Condicionador de Rede XCode [1]
3. Compartilhe sua rede wifi do seu Mac [2]
4. Conecte seu dispositivo à rede wifi do seu Mac
5. À medida que você usa seu aplicativo, altere as configurações do Network Conditioner (offline, mau, bom, etc)
>br>Linux tem mais ferramentas de condicionamento e captura/inspecção de pacotes do que o Mac. Você pode configurar uma caixa wifi Linux dedicada com tc (netem) e tcpdump para levar essa idéia para o próximo nível.

[wifi machine]

Um resultado desses testes pode ser repensar partes da sua aplicação como mais assíncronas, tarefas em segundo plano. Outro pode ser a construção de alguns caches locais.

No passado eu me perguntei algumas questões relacionadas:
>>br>- Existe alguma maneira de facilmente condicionar a rede da sua aplicação para corresponder às experiências reais dos usuários? Definir alguns argumentos de condicionador de balde é bom, mas seria ótimo saber que estou tentando os casos certos.
- Então provavelmente a maioria dos desenvolvedores vão lidar com cenários de rede ruins de forma similar. Haverá uma maneira comum de fazer isso que as pessoas possam se locomover e contribuir para?
>br> Isso me fez pensar em construir uma biblioteca de rede melhor. Então eu comecei a construí-la. Pode verificar o que estou a construir em https://github.com/nextopio/nextop-client.
>br> As ideias centrais com este projecto de código aberto são:
- Altere os padrões de entrega de mensagens para que os seus pedidos não se percam, nunca. Até que uma mensagem seja entregue, ela é novamente testada. Ele usa algumas técnicas inteligentes para evitar o bloqueio de cabeça de linha sem que você faça nada. E você pode sempre cancelar uma mensagem.
- Abra a porta para novos protocolos em uma estrutura que pode cair perfeitamente de volta ao HTTP/HTTPS. Então tenha um cliente que pode tentar algo novo, se isso estiver falhando, volte para algo confiável, sem bagunçar o seu backend. Se você já viu os primeiros resultados do HTTP/2, então você sabe que as coisas são excitantes. Um melhor formato de wire pode fazer muito para tornar os aplicativos mais utilizáveis em redes ruins.
- Construa um protocolo melhor para todas as redes.
>br> Então aqui estou eu perfilando meu aplicativo, usando uma visão de depuração Nextop, porque todos os meus protocolos são baseados em um Wire.Factory [4] que me permite entrar e moldar o tráfego com dados reais.

>br> Em resumo, acho que precisamos de ferramentas melhores.

esperança que ajuda!
>br> 1. Network Link Conditioner
2. Preferências -> Partilha -> Partilha de Internet -> Partilha a sua Ligação a partir de Ethernet -> Para Computadores usando WiFi
3. https://github.com/nextopio/nextop-client