Contexte et contraintes

Les applications Windows nécessitent un environnement complet : un VM avec interface graphique active, un compte utilisateur connecté et un accès à l’API UI Automation (UIA). Un VM « froid » met entre deux et trois minutes à démarrer, contre quelques secondes pour un conteneur Linux. De plus, chaque exécution conserve les fichiers, les clés de registre et les processus résiduels, ce qui empêche la parallélisation massive demandée par les équipes d’assurance qualité.

Architecture du dispositif

QA Wolf a réutilisé son modèle de test mobile. Un contrôleur Kubernetes orchestre un pool de machines virtuelles Windows sur Google Compute Engine (GCE). Le pool est décrit par trois ressources personnalisées : WindowsVMTemplate (image, taille, configuration), WindowsVMPool (nombre de VMs prêtes) et WindowsVM (instance individuelle). Le scheduler attribue à chaque test un DeviceClaim, récupère les adresses de connexion (CDP, Appium, WebRTC) et libère la VM à la fin du test.

Flux de test et communications

Le code de test s’exécute dans un pod Linux contenant le package @qawolf/flows/windows. Le processus se déroule en six étapes :

1. runner → scheduler : DeviceClaim
2. scheduler → VM pool : assignation VM
3. scheduler → runner : adresses CDP, Appium, WebRTC
4. runner → VM : startApp(); // téléchargement et lancement
5. runner ↔ VM : commandes CDP/Appium, flux vidéo WebRTC
6. runner → scheduler : release → destruction VM

Playwright utilise le Chrome DevTools Protocol (CDP) pour piloter les navigateurs, tandis qu’Appium (via WinAppDriver) contrôle les applications natives. Un agent Go installé sur la VM transmet le flux d’écran en temps réel via WebRTC, permettant la visualisation et l’enregistrement des tests.

Analyse des performances et limites

Le recours à un pool « warm » réduit le temps d’attente à quelques secondes, car les VMs sont déjà démarrées et connectées. La nature jetable garantit l’isolation : chaque test reçoit un environnement vierge, éliminant les effets de contamination entre les exécutions. Cependant, le modèle implique un coût proportionnel au nombre de VMs maintenues en veille sur GCE, et la latence réseau entre le pod Linux et la VM distante peut affecter les scénarios UI sensibles au timing. De plus, la dépendance à GCE limite la portabilité vers d’autres fournisseurs cloud sans adaptation du scheduler. Enfin, la visibilité reste limitée aux logs et captures d’écran fournis par le flux WebRTC ; aucune métrique native du système d’exploitation n’est exposée sans instrumentation supplémentaire.