Documentation technique
Comment installer Q-Bot sur votre réseau, y relier un smartphone, construire un scénario et le déclencher depuis votre chaîne de tests. Cette page s'adresse à qui intègre réellement Q-Bot ; pour savoir ce qu'il fait et s'il convient à votre environnement, voyez les caractéristiques.
Comment Q-Bot est fait
Un ordinateur complet posé sur votre réseau local, un smartphone Android relié en USB, et une interface web servie par le boîtier lui-même.
Le boîtier est un nano-ordinateur qui fonctionne de façon autonome sur le réseau où vous l'installez. Il n'appelle aucun service extérieur pendant l'exécution des tests, et n'a besoin d'aucune connexion internet pour les mener.
Le téléphone sous test lui est relié par un câble USB. Q-Bot le pilote par ADB, l'outil standard d'Android : chaque appui arrive sur l'écran physique, dans la véritable application d'authentification.
- Votre chaîne de tests appelle Q-Bot en HTTP
- Q-Bot rejoue le scénario sur le téléphone, par ADB
- Le second facteur est validé dans la vraie application
- Votre test reprend son cours
Installation et réseau
Le boîtier arrive prêt. Ce qu'il faut savoir, c'est où le brancher et ce qu'il attend de votre réseau.
Le boîtier se place sur le même réseau que la machine qui exécute vos tests : c'est ce réseau, et lui seul, qui donne accès à l'interface et à l'API.
Connexion du smartphone
Un téléphone Android physique, relié en USB, piloté par ADB. Ni émulateur, ni simulateur, ni application bouchon.
Un boîtier pilote un appareil à la fois, et les demandes sont traitées l'une après l'autre, dans leur ordre d'arrivée.
Création des scénarios
Un scénario se construit à l'écran, sur une capture de l'application testée. Il n'y a pas de langage de script à apprendre.
- Une capture de l'écran de l'application sert de fond d'étape
- Les points d'appui se posent au clic, et sont numérotés
- Les temps d'attente se règlent à la milliseconde
- Les étapes se réordonnent
- Les scénarios sont versionnés dans le boîtier
- Les captures restent stockées localement
Chaque scénario porte un identifiant numérique : c'est lui que votre chaîne de tests appellera.
L'API REST
Trois points d'entrée, en HTTP, sur le réseau local. Aucun SDK, aucun greffon propriétaire, aucun agent à installer dans votre intégration continue.
- Auto-hébergé : tout reste sur votre réseau local
- Compatible avec toute chaîne capable d'un appel HTTP
- L'API n'attend aucune clé : le contrôle d'accès est celui de votre réseau
Déclencher depuis votre chaîne de tests
Le même appel HTTP, dans cinq outils. Dépliez celui qui vous concerne.
# On déclenche le scénario 2FA
import requests
requests.get(
"http://q-bot.local:8000"
"/scenarios/42/execute"
)
# Le test reprend son cours
driver.find_element(
By.ID, "dashboard"
).is_displayed()// On déclenche le scénario 2FA
cy.request(
'GET',
'http://q-bot.local:8000'
+ '/scenarios/42/execute'
)
.its('status')
.should('eq', 200)
cy.get('#dashboard')
.should('be.visible')# On déclenche le scénario 2FA
curl -s \
http://q-bot.local:8000 \
/scenarios/42/execute
# Le code LuxTrust
OTP=$(curl -s \
http://q-bot.local:8000 \
/get-luxtrust-otp \
| jq -r '.otp')*** Settings ***
Library RequestsLibrary
*** Test Cases ***
Connexion 2FA
# on déclenche le scénario
${r}= GET
... ${QBOT}/scenarios/42/execute
Status Should Be 200 ${r}// on déclenche le scénario 2FA
given()
.baseUri("http://q-bot.local:8000")
.when()
.get("/scenarios/42/execute")
.then()
.statusCode(200);
// le test reprend son cours
assertTrue(
dashboard.isDisplayed()
);L'app compagnon
Le second chemin de déclenchement : l'application s'installe sur le téléphone sous test et part seule dès qu'une notification 2FA arrive.
Installée sur le téléphone sous test, elle surveille les notifications des applications d'authentification et déclenche le scénario correspondant dès qu'une arrive. Aucun appel depuis votre chaîne de tests n'est nécessaire.
Les deux chemins de déclenchement coexistent dans le même environnement : l'appel HTTP quand c'est votre test qui décide, l'app compagnon quand c'est l'application testée qui réclame le second facteur.
Le QR code sur l'écran du boîtier
Le boîtier porte un petit écran intégré. POST /display-image y affiche un QR code que le téléphone vient scanner.
Certains parcours d'authentification demandent de scanner une image plutôt que de saisir un code. L'écran du boîtier sert alors de support : votre test y envoie l'image, le téléphone la scanne, le parcours continue.
Stockage des données
Les scénarios et leurs captures restent sur le boîtier. Rien n'est envoyé vers un service extérieur.
Q-Bot est conçu pour des données de test. Les comptes utilisés dans vos scénarios doivent être des comptes de test.
Sécurité
Ce que le produit garantit aujourd'hui, et ce qu'il laisse à votre infrastructure. Énoncé tel quel, sans promesse au-delà.
- Auto-hébergé : le boîtier vit sur votre réseau, pas dans un cloud
- Aucun appel vers un service extérieur pendant l'exécution des tests
- Aucune connexion internet n'est nécessaire pour exécuter un scénario
- Les scénarios et les captures ne quittent pas le boîtier
L'API n'attend aucune clé d'authentification. Le contrôle d'accès est donc celui de votre réseau : placez le boîtier sur un segment dont l'accès est déjà maîtrisé, comme vous le feriez pour tout équipement de test. Pour toute question de conformité propre à votre environnement, écrivez-nous.
Support et remplacement
Ce qui est inclus dans la location, et ce qui se passe en cas de panne.
Prêt à automatiser la dernière étape manuelle ?
Échangez avec notre équipe et découvrez Q-Bot en action.
Demander une démo