IMEI en lot : Luhn, données de test et automatisation QA

Un IMEI de test peut suffire à valider un champ de formulaire, tandis que les tests de charge ou de migration peuvent exiger des jeux de données bien plus grands. RandomIMEI.com crée de 1 à 50 valeurs par lot web ; pour des centaines ou des milliers de valeurs, utilisez un générateur local avec déduplication explicite et conservez les résultats dans un environnement de test isolé.

Ce guide définit un contrat de données de test reproductible : 15 chiffres, un chiffre de contrôle Luhn valide, des entrées TAC documentées, une gestion explicite des collisions et des réponses de statut simulées.

Pourquoi des nombres aléatoires à 15 chiffres ne suffisent pas

Les chaînes aléatoires à 15 chiffres enfreignent souvent un ou plusieurs contrats de test :

1. Échec de Luhn : un IMEI standard à 15 chiffres contient un chiffre de contrôle Luhn. Un dernier chiffre tiré uniformément a une chance sur dix de correspondre à la somme ; environ 90 % des chaînes arbitraires échouent donc devant un validateur limité à Luhn.

2. Branches liées au préfixe non couvertes : certains systèmes associent les huit premiers chiffres à un jeu de données TAC. Un préfixe arbitraire ne teste aucun mappage connu et peut être traité comme inconnu par un logiciel qui consulte une source autorisée.

3. Doublons non contrôlés : lorsqu'un schéma ou un scénario exige des identifiants uniques, des séries aléatoires peuvent entrer en collision et déclencher une contrainte pour la mauvaise raison.

4. Distribution non déclarée : un mélange arbitraire de préfixes n'indique pas quelles branches du produit les données de test doivent couvrir. Déduisez les catégories et les poids de vos propres exigences, pas d'une part de marché non sourcée.

Un générateur de données de test en lot utile doit calculer des sommes Luhn valides, utiliser des TAC choisis pour le test, rejeter les doublons du jeu courant et documenter la source des libellés de familles d'appareils.

Cas d'usage de la génération d'IMEI en lot

1. Initialisation de base de données et test du schéma

Pour construire ou migrer une base qui stocke des identifiants d'appareils, choisissez un nombre de données de test qui exerce le plan de requête et les contraintes à mesurer. Une base vide ou un test sur un seul enregistrement ne révèle pas :

• Les performances des index à la cardinalité prévue
• Le comportement du plan de requête lors d'un filtre sur le préfixe TAC du fabricant
• L'élagage des partitions lorsque le schéma partitionne par TAC
• Le temps de validation des contraintes sous une charge d'insertion

Consignez avec la mesure de performance la version de la base, le nombre de lignes, les catégories TAC et le jeu de requêtes. Les résultats synthétiques ne prédisent la production que si ces entrées correspondent à sa charge.

2. Tests de charge et mesures de performance

Répéter un seul identifiant peut mesurer le cache plutôt que le chemin de recherche. Dimensionnez l'ensemble selon le comportement du cache, la répartition des requêtes et la concurrence de votre plan de performance.

Transmettez cet ensemble contrôlé à k6, JMeter, Locust ou Gatling, et placez les réponses de statut derrière un service local simulé. Une autre chaîne IMEI ne crée pas un appareil réel.

3. Développement de plateformes MDM

Un plan de test MDM peut couvrir l'inscription, l'affectation de politiques, les requêtes d'inventaire et les rapports de conformité avec plusieurs tailles d'inventaire. Utilisez les volumes de votre objectif de capacité, pas une plage générique du secteur.

Les valeurs générées en lot peuvent remplir un inventaire simulé ou de préproduction sans copier les identifiants des clients. Les réponses d'inscription et d'éligibilité du fournisseur doivent rester simulées ou passer par un environnement de test approuvé.

4. Chaînes d'automatisation QA

Les suites automatisées qui valident des fonctions liées aux IMEI ont besoin de données propres à chaque exécution. Quelques IMEI codés en dur créent une pollution entre tests, car plusieurs cas partagent l'état des mêmes identifiants.

Générez de nouvelles valeurs au début de l'exécution, ou conservez un grand ensemble prégénéré et sélectionnez-les avec un compteur ou un décalage aléatoire. La génération en lot convient aux deux méthodes.

5. Simulation de réseau télécom

Les ingénieurs qui testent des intégrations HLR, VLR ou EIR peuvent modéliser des champs de type IMSI et IMEI dans des enregistrements synthétiques. Définissez la relation et l'état de registre attendu dans les données de test ; la génération seule ne fournit ni identité d'abonné ni statut d'équipement.

6. Test des places de marché d'appareils d'occasion

Les plateformes qui vérifient le statut d'un IMEI, comme une liste noire, un verrouillage opérateur ou une garantie, doivent tester leur chaîne avec plusieurs entrées. Couvrez notamment :

• Réponse contrôlée : le service simulé renvoie un statut libre ou bloqué
• Délai dépassé ou erreur : le service simulé renvoie la forme d'échec du contrat
• Format incorrect : l'entrée est mal formée
• Cas limite du mappage : Luhn est valide, mais le catalogue de test ne connaît pas le TAC

Les valeurs générées n'ont aucun statut connu de liste noire, de verrouillage opérateur ou de garantie. Testez ces branches avec des données dont votre simulation contrôle les réponses ; ne déduisez pas un statut « libre » de la seule génération.

Exigences techniques de la génération d'IMEI valides en lot

Une génération fiable à grande échelle doit respecter plusieurs conditions.

Algorithme de Luhn à grande échelle

Chaque IMEI généré a besoin d'un chiffre de contrôle Luhn valide. Cette implémentation Python convient à la génération en lot :

import random

def luhn_checksum(digits_14: str) -> int:
    """Calcule le chiffre de contrôle Luhn d'une chaîne de 14 chiffres."""
    digits = [int(d) for d in digits_14]
    # Pour une base de 14 chiffres, doubler les positions 2, 4, ... 14.
    for i in range(13, -1, -2):
        digits[i] *= 2
        if digits[i] > 9:
            digits[i] -= 9
    total = sum(digits)
    return (10 - (total % 10)) % 10

def generate_imei(tac: str) -> str:
    """Génère un IMEI valide avec le TAC à 8 chiffres fourni."""
    if len(tac) != 8 or any(ch not in "0123456789" for ch in tac):
        raise ValueError("le TAC doit contenir exactement 8 chiffres")
    serial = str(random.randint(0, 999999)).zfill(6)
    base = tac + serial
    check = luhn_checksum(base)
    return base + str(check)

def generate_bulk(tac: str, count: int) -> list[str]:
    """Génère des IMEI valides et uniques pour un TAC donné."""
    if not 1 <= count <= 1_000_000:
        raise ValueError("le nombre doit être compris entre 1 et 1 000 000")
    seen = set()
    results = []
    while len(results) < count:
        imei = generate_imei(tac)
        if imei not in seen:
            seen.add(imei)
            results.append(imei)
    return results

# Exemple : générer 1 000 données de test depuis un préfixe explicitement
# non officiel choisi pour ce test isolé. Fournissez votre propre entrée documentée.
imeis = generate_bulk("12345678", 1000)
print(f"{len(imeis)} IMEI uniques générés")
print(f"Exemple : {imeis[:5]}")

Choisir une distribution depuis le plan de test

Ne copiez pas dans vos données de test une table de parts de marché sans source. Définissez les catégories et les poids pris en charge par votre produit, documentez leur origine et conservez une solution de repli explicite pour un TAC inconnu.

Garantir l'unicité

Si le schéma ou le scénario exige des valeurs uniques, choisissez l'une de ces méthodes :

1. Déduplication par ensemble, comme dans le code Python : conservez les IMEI générés dans un ensemble et recommencez en cas de collision.
2. Numéros de série séquentiels : incrémentez le champ de série, aux positions 9 à 14. Cette méthode garantit des valeurs distinctes dans le jeu de test pour un TAC. Les six chiffres offrent 1 000 000 de combinaisons, mais Random IMEI ne peut pas savoir lesquelles sont déjà attribuées dans le monde réel.

Calcul des collisions et solutions déterministes

Un TAC offre 1 000 000 d'entrées de série à six chiffres. Avec un tirage aléatoire, le nombre attendu de paires en doublon vaut environ n(n-1) / (2 x 1 000 000). Pour 1 000 tirages dans un TAC, la valeur atteint environ 0,5, soit une probabilité proche de 39 % d'obtenir au moins une collision avec un générateur uniforme idéal.

Le rejet par ensemble supprime les doublons de la sortie, mais perd en efficacité à mesure que l'espace se remplit. Les séries séquentielles rendent le jeu de test reproductible et évitent les collisions internes. Utilisez plusieurs TAC uniquement si le plan exige plusieurs catégories de mappage ou plus d'un million d'entrées distinctes.

Matrice de vecteurs QA

Intégrer les IMEI en lot aux outils QA

Avec k6 (test de charge JavaScript)

import http from 'k6/http';
import { check } from 'k6';
import { SharedArray } from 'k6/data';

// Précharger 50 000 IMEI générés depuis un fichier
const imeis = new SharedArray('imeis', function () {
  return open('./test_imeis.txt').split('\n').filter(l => l.length === 15);
});

export default function () {
  // Choisir un IMEI au hasard dans l'ensemble
  const imei = imeis[Math.floor(Math.random() * imeis.length)];

  // Utiliser un service local simulé dont le test contrôle la réponse.
  const res = http.post('http://localhost:8080/mock/devices/lookup', {
    imei: imei,
  });

  check(res, {
    'statut égal à 200': (r) => r.status === 200,
    'informations appareil présentes': (r) => r.json('manufacturer') !== undefined,
  });
}

Avec pytest (suite de tests Python)

import pytest
import random

# Donnée de test fournissant un IMEI unique à chaque test
@pytest.fixture
def unique_imei(imei_pool):
    """Fournit un IMEI unique depuis un ensemble prégénéré."""
    return imei_pool.pop()

@pytest.fixture(scope="session")
def imei_pool():
    """Charge l'ensemble d'IMEI prégénérés au début de la session."""
    with open("test_data/bulk_imeis.txt") as f:
        imeis = [line.strip() for line in f if len(line.strip()) == 15]
    random.shuffle(imeis)
    return imeis

def test_device_lookup(unique_imei, api_client):
    response = api_client.lookup_device(unique_imei)
    assert response.status_code == 200
    assert response.json()["format_valid"] is True

Avec SQL (initialisation de base de données)

-- PostgreSQL : insertion en lot depuis un CSV
CREATE TEMP TABLE temp_imeis (imei CHAR(15));

COPY temp_imeis FROM '/path/to/bulk_imeis.csv' CSV;

-- Insérer dans la table devices avec des métadonnées supplémentaires
INSERT INTO test_devices (imei, created_at, status)
SELECT
    imei,
    NOW() - (random() * INTERVAL '365 days'),  -- Date de création aléatoire
    CASE WHEN random() < 0.95 THEN 'active' ELSE 'inactive' END
FROM temp_imeis
ON CONFLICT (imei) DO NOTHING;

SELECT COUNT(*) FROM test_devices;  -- Vérifier le nombre de lignes

Utiliser RandomIMEI.com pour la génération en lot

RandomIMEI.com accepte de petits lots web. Vous pouvez :

• Générer de 1 à 50 valeurs par requête
• Choisir un fabricant et un profil d'appareil dans la copie locale datée
• Copier les résultats ou télécharger un fichier CSV

Le site n'offre pas d'API publique de génération. Pour l'automatisation ou les jeux plus grands, adaptez l'exemple Luhn local de ce guide et ajoutez vos propres entrées déterministes, une déduplication et des protections réservées aux tests.

Chaque IMEI généré :

• Possède un chiffre de contrôle Luhn valide
• Utilise un préfixe de la copie locale versionnée et non officielle de Random IMEI
• Est dédupliqué dans le lot web courant

Random IMEI ne consulte ni la GSMA, ni les opérateurs, ni les services d'activation, de garantie ou de liste noire. Il ne peut donc pas déterminer si un résultat est attribué, enregistré, bloqué ou accepté par un autre système. Traitez chaque sortie comme une donnée synthétique et ne l'envoyez pas à un système d'identité réel.

Formats de sortie des IMEI en lot

RandomIMEI.com propose le presse-papiers et le CSV. Un générateur local sous votre contrôle peut aussi produire les formats demandés par vos outils de test :

Usages exclus des IMEI générés en lot

Dans certaines juridictions et organisations, la génération en lot peut convenir à des données de test isolées si la politique interne et la loi applicable l'autorisent. Elle ne doit pas servir à :

• Usurper un IMEI : reprogrammer ou présenter faussement l'identifiant d'un appareil réel peut être illégal et sort du cadre de ce site. Gardez les valeurs générées comme données dans des tests contrôlés.
• Contourner des listes : une valeur générée n'a aucun statut de registre vérifié. Ne l'envoyez pas à un opérateur, une liste noire, un service d'activation ou un autre service d'identité en production.
• Commettre une fraude : les fraudes à l'assurance, au financement d'appareils ou tout autre usage qui présente une fausse identité d'appareil sont exclus. Ces données existent pour les environnements de développement, pas pour les systèmes réels.

Les lois varient selon la juridiction. L'emploi d'un faux identifiant pour accéder à un service, usurper un appareil ou commettre une fraude peut être illégal ; gardez les données de test dans des environnements contrôlés et demandez un avis juridique pour les flux réglementés.

Questions fréquentes

Combien d'IMEI distincts puis-je générer avec un seul code TAC ?

Le champ de série à six chiffres offre 1 000 000 d'entrées possibles pour un TAC. Une énumération séquentielle peut produire autant de valeurs de test distinctes, mais Random IMEI ne peut pas savoir si une valeur coïncide avec un appareil attribué. Utilisez plusieurs TAC si le contrat de test exige plus de valeurs ou plusieurs catégories de mappage.

Quelle est la méthode la plus rapide pour générer 1 million d'IMEI de test ?

Une méthode déterministe consiste à énumérer la plage de séries d'un préfixe de test documenté et à calculer Luhn pour chaque ligne. Elle évite les collisions aléatoires ; mesurez l'implémentation et la taille du jeu dans votre environnement au lieu de supposer un temps fixe.

Puis-je utiliser des IMEI générés en lot dans une chaîne CI/CD ?

Oui. Générez les valeurs dans un script local avant les tests ou conservez un ensemble de données de test clairement étiqueté. RandomIMEI.com n'offre pas d'API publique de génération ; les tâches CI doivent utiliser du code que vous possédez, examinez et pouvez initialiser de façon reproductible.

Les IMEI générés en lot fonctionnent-ils avec de vrais outils de vérification ?

Ils passent les contrôles limités au format à 15 chiffres et à la somme Luhn. D'autres outils peuvent consulter des données propriétaires de TAC, d'opérateur, de liste noire ou de garantie. Random IMEI ne connaît ni ne prédit ces résultats ; n'envoyez pas les valeurs générées à des services de recherche réels.

Comment éviter les doublons dans un jeu d'IMEI générés en lot ?

Rejetez les collisions avec un ensemble pour les séries aléatoires, ou énumérez le champ de série à six chiffres de façon déterministe. La seconde méthode évite les collisions internes et rend les exécutions reproductibles. N'imposez l'unicité que si elle fait partie du contrat du schéma ou du scénario.

Un IMEI généré peut-il coïncider avec celui d'un appareil réel ?

Oui. Une série aléatoire dans un TAC peut coïncider avec un identifiant attribué, et Random IMEI ne dispose d'aucune base d'attribution officielle pour l'exclure. Gardez les résultats à l'écart des systèmes réels d'opérateur, d'activation, de garantie, de financement, d'assurance et de liste noire.