Testes de QA em dispositivos reais: frotas para compatibilidade
Como os testes de QA em dispositivos reais numa frota de telemóveis detetam erros de fragmentação, sensores e rede que os emuladores deixam passar, além de como construir uma matriz de testes de dispositivo/SO.
Os testes de QA em dispositivos reais executam a sua app em telemóveis e tablets físicos para que valide face ao hardware, às builds de SO e às condições de rede que os seus utilizadores realmente têm. É a forma mais fiável de detetar erros de fragmentação, sensores e renderização que os emuladores encobrem silenciosamente.
- Emulators are fast for early smoke tests, but only real devices reproduce hardware-specific behavior: cameras, GPS, biometrics, thermal throttling, and vendor OS skins.
- Android and iOS fragmentation both demand a deliberate device/OS test matrix rather than "whatever is on the desk."
- A physical fleet runs manual exploratory testing and automated regression suites against the same coverage set.
- The highest-value edge cases live at the hardware and network boundary: sensors, cameras, notifications, low battery, and degraded connectivity.
- Prioritize matrix coverage by real user analytics, not by what is newest or cheapest.
Porque os dispositivos reais superam os emuladores em QA
Os emuladores e simuladores modelam um dispositivo idealizado. São excelentes para um desenvolvimento em ciclo interno rápido e para paralelizar testes de fumo económicos. Mas abstraem exatamente as camadas onde se concentram os erros móveis.
Um dispositivo real corre a build de SO modificada pelo OEM, as políticas de gestão de energia e de eliminação de memória do fabricante, drivers de GPU reais, rádios reais e o software pré-instalado do fabricante. Um layout que se apresenta perfeitamente num simulador pode cortar-se numa build Samsung One UI com um tipo de letra do sistema maior, ou bloquear quando um eliminador de processos em segundo plano da Xiaomi termina o seu serviço. Nada disso é visível num emulador.
Os dispositivos reais também expõem a verdade do desempenho. Um telemóvel de gama média com dois anos que uma grande parte dos seus utilizadores ainda usa vai revelar lentidão, arranques a frio lentos e falhas por falta de memória que o topo de gama de um programador ou um emulador de datacenter nunca mostrarão. Para uma comparação mais aprofundada dos compromissos, consulte emuladores versus dispositivos reais.
Uma divisão pragmática: emuladores para o ciclo interno do programador e verificações de fumo em PR, uma frota de dispositivos reais para regressão de release candidates, desempenho e qualquer teste que envolva hardware.
Compreender a fragmentação
Fragmentação no Android
O Android corre num vasto catálogo de modelos de dispositivos de muitos OEM, cada um com a sua própria camada (One UI, MIUI/HyperOS, ColorOS, Pixel stock, entre outras) sobre um leque de versões de Android ainda em uso ativo. A fragmentação manifesta-se em tipos de letra e densidades de ecrã por defeito diferentes, gestão de processos em segundo plano agressiva e inconsistente, comportamento de notificações variado e diálogos de permissões específicos do OEM. As proporções de ecrã, os notches e os recortes acrescentam ainda mais combinações de layout.
Fragmentação no iOS
O iOS tem muito menos modelos, mas a fragmentação de versões e as diferenças entre gerações de hardware continuam a importar: notch versus Dynamic Island, dispositivos mais antigos sem os sensores mais recentes, e alterações de comportamento entre lançamentos do iOS. Como a Apple distribui as atualizações de forma alargada, normalmente testa-se a versão atual e uma ou duas versões principais anteriores, num leque de tamanhos de ecrã.
Construir uma matriz de testes de dispositivo/SO
A cobertura é um problema de orçamento: não é possível testar tudo, por isso testam-se as combinações que representam mais utilizadores e mais risco.
Passo 1 — Recolher dados de utilização reais
Comece pela sua própria análise (ou dados da consola da loja): modelos de dispositivos, versões de SO, tamanhos de ecrã e idiomas principais por utilizadores ativos. Este é o input mais importante de todos — transforma uma matriz infinita numa lista ordenada.
Passo 2 — Segmentar em níveis de cobertura
| Nível | Objetivo | Exemplo de seleção |
|---|---|---|
| Core | Dispositivos com mais tráfego; todos os lançamentos são testados aqui | Os 5–8 modelos principais que cobrem a maior quota de utilizadores |
| Alargado | Cobertura mais ampla realizada antes de lançamentos importantes | Dispositivos de gama média e mais antigos, camadas de OEM adicionais |
| Edge | Configurações de risco conhecido ou de nicho | Ecrãs mais pequenos/maiores, SO suportado mais antigo, dobráveis |
Passo 3 — Equilibrar os eixos
Varie deliberadamente os eixos que produzem erros: versão de SO, camada do OEM, tamanho/densidade de ecrã, nível de RAM e idioma. Uma matriz de "cinco topos de gama" é uma cobertura fraca; uma matriz que abrange um telemóvel económico com pouca RAM, um SO mais antigo, uma definição de acessibilidade de letra grande e um idioma RTL é sólida. Para orientação sobre a seleção, consulte escolher dispositivos para uma frota.
Passo 4 — Versionar e atualizar
Trate a matriz como algo vivo. Retire dispositivos à medida que a sua quota de utilizadores desce, adicione novos topos de gama e novas betas de SO assim que são lançados, e mantenha pelo menos um dispositivo em cada versão de SO ainda suportada.
Testes manuais e automatizados na frota
Uma frota física suporta ambos os modos de teste sobre o mesmo conjunto de cobertura.
| Manual exploratory | Automated regression | |
|---|---|---|
| Best for | Visual polish, gesture feel, accessibility | Repetitive breadth across the core tier |
| Cadence | New features, edge tier | Every build / release candidate |
| Tooling | scrcpy, remote access | Appium, Espresso/UIAutomator, XCUITest |
| Scale | Bounded by tester time | Parallelized across the fleet |
Os testes manuais e exploratórios continuam a ser essenciais para o polimento visual, a sensação dos gestos, a acessibilidade e as interações de hardware que são difíceis de scriptar. Ferramentas como o scrcpy permitem a um tester controlar um dispositivo Android a partir de uma estação de trabalho, e o espelhamento de ecrã em conjunto com o acesso remoto permitem que equipas de QA distribuídas partilhem um rack.
A regressão automatizada trata da amplitude repetitiva: executa a mesma suite no nível core em cada build. As frameworks de automação em dispositivos reais (Appium, Espresso/UIAutomator, XCUITest) controlam as apps, e uma frota permite paralelizar entre muitos dispositivos para manter as suites rápidas. Consulte automação e scripting de apps para mais detalhes sobre a stack.
Um padrão comum: as suites automatizadas condicionam o nível core em cada release candidate, enquanto as passagens exploratórias manuais se concentram nas novas funcionalidades e no nível edge.
Casos limite que só o hardware real revela
Estas categorias são onde uma frota justifica o seu custo:
- Sensores — a precisão de GPS/localização, a UI orientada por acelerómetro/giroscópio, o barómetro e os fluxos biométricos (impressão digital, rosto) comportam-se de forma diferente consoante o dispositivo e não podem ser emulados com fidelidade.
- Câmaras — a resolução, o autofoco, os metadados de orientação (EXIF) e o comportamento com pouca luz variam amplamente; a leitura de QR/códigos de barras e as funcionalidades de AR devem ser testadas com ótica real.
- Condições de rede — a transferência celular real, o Wi-Fi com portal cativo, as transições para modo avião, o roaming e as ligações degradadas ou de alta latência expõem erros de nova tentativa e de gestão offline. Use ferramentas de shaping de rede e SIM reais para reproduzir condições de campo.
- Notificações — a entrega push, os canais, o agrupamento e o comportamento sob Doze/restrições em segundo plano diferem entre camadas de OEM.
- Energia e térmica — o comportamento com bateria fraca, a eliminação de tarefas em segundo plano e o throttling térmico alteram o desempenho da app de formas que só os dispositivos físicos mostram.
- Interrupções — chamadas recebidas, alarmes e diálogos do sistema que interrompem um fluxo.