Diário de testes embebidos #1. Frotas de dispositivos.
Problemas comuns nos testes de sistemas embebidos: como gerir frotas de dispositivos, setups de teste heterogéneos e a disputa de recursos entre vários hosts.
Nesta série de artigos, vamos descrever problemas comuns nos testes de sistemas embebidos. Também vamos partilhar o que descobrimos, a nossa experiência e as nossas soluções.
Este é o primeiro artigo. Comecemos por um problema simples.
Está a desenvolver um novo dispositivo. O firmware cresce e surgem muitas funcionalidades novas. Um dia, repara que os setups de teste ficaram difíceis. Precisa de 2–3 computadores para testar cada dispositivo, e geri-los torna-se um enorme problema.
Chamemos setup de teste ao conjunto mínimo de computadores, com a respetiva configuração, de que precisa para testar um dispositivo.
A magia dos testes multiagente
Os testes multiagente resolvem este problema com a gestão automática destes hosts. Quando inicia os testes, o sistema faz sozinho todas as alterações necessárias à configuração.
O nosso TS Factory altera a configuração e regista o histórico dessas alterações. Quando o teste termina, reverte-as de forma limpa.
Isto é feito através da entidade Configurator. O Configurator descobre todas as interfaces de rede, máquinas virtuais, agentes de software e configurações WiFi e série, e acompanha-as do início ao fim. Qualquer teste pode alterar a configuração em qualquer momento e com qualquer complexidade. No fim do teste, todas as alterações são desfeitas.
Setups de teste heterogéneos
Um dos desafios é suportar setups de teste heterogéneos. Os hosts da sua rede podem ter capacidades e recursos diferentes.
Um host permite configurar uma firewall, outro não.
Um dispositivo usa Windows, outro usa Linux.
Mesmo entre dispositivos Linux, pequenas incompatibilidades entre versões da glibc podem impedir que o mesmo agente corra em todos os hosts.
Há ideias óbvias, como compilar para musl. É um bom ponto de partida, mas não resolve por completo o problema das funcionalidades e bibliotecas diferentes.
Para resolver o problema por completo, criámos o Builder. O motor de testes conhece bem o sistema alvo e recompila o agente para cada host de forma transparente. Não precisa de se preocupar com isso. Simplesmente funciona.
Gestão de recursos
O outro problema é a gestão de recursos.
Imagine que o host tem um adaptador WiFi que só uma configuração de teste pode usar de cada vez. Outras configurações de teste podem usá-lo ao mesmo tempo? Muito provavelmente, não. É importante ter direitos exclusivos sobre este recurso. Por isso, bloqueie o recurso enquanto os testes correm e liberte-o assim que terminarem.
Parece fácil? Sim. É mesmo fácil? Não é.
Um setup de teste possível
Para nós, um conceito importante é o dos setups intercalados. Resolve vários problemas de gestão de recursos, sobretudo a gestão de rotas em dispositivos de rede.
Imagine que tem 3 configurações de teste: A, B e C. Cada configuração precisa de acesso exclusivo a um adaptador WiFi. E tem três hosts: H1, H2 e H3.
As sub-redes LAN/WAN/WiFi têm uma configuração diferente em cada configuração de teste, por isso as rotas de tráfego não se misturam. Ao mesmo tempo, é fácil entrar em qualquer dispositivo durante os testes e investigar o que se passa.
Isto só funciona com testes multiagente, com suporte para setups de teste heterogéneos e com uma boa gestão de recursos.
Conclusão
Vimos alguns problemas que surgem na gestão de uma frota de dispositivos de QA (garantia de qualidade): gestão de recursos, setups heterogéneos e funcionamento multiagente. O esquema de setups intercalados descrito acima é uma abordagem que funciona em instalações reais.
No próximo artigo, vamos analisar outro desafio comum da nossa prática de testes de sistemas embebidos.