Résolution des problèmes de test lan
Pour résoudre les problèmes qui se produisent avec les tests Device.Network, procédez comme suit :
Consultez Résolution des problèmes d’échecs de test Windows HLK.
Consultez les notes de publication de Windows HLK pour connaître les problèmes de test actuels.
En cas d’échec de test, recherchez des informations utilisables dans le journal des tests Windows HLK Studio. Si vous trouvez des informations utilisables, résolvez le problème et réexécutez le test.
Si les travaux de test LAN de deux machines échouent, il est probable que les tests ne soient pas en mesure de détecter le message et/ou de prendre en charge les appareils sur l’une des deux machines.
Pour diagnostiquer rapidement ce type de problème, exécutez le travail « NDISTest 6.5 - [2 Machine] - CheckConnectivity ». L’exécution de ce travail ne prend que quelques minutes, mais vous indique si les machines peuvent communiquer et sont prêtes à exécuter le reste des travaux de l’ordinateur.
En cas de problème de connectivité, le travail échoue dans la tâche « Exécuter le client NDISTest ». Les fichiers journaux du travail répertorient les échecs lorsque les cartes réseau de test et de prise en charge ne peuvent pas communiquer de manière bidirectionnelle. Passez en revue les résultats dans les fichiers journaux du travail, case activée les connexions des machines, puis réessayez d’exécuter le travail.
Vous devez également case activée que vous sélectionnez l’ordinateur approprié comme machine de support. Avec les cartes réseau multiports et plusieurs configurations de machine, il est très facile de sélectionner la mauvaise carte réseau ou la mauvaise machine. Nous vous suggérons de conserver les deux machines exécutant des tests LAN dans leur propre pool d’ordinateurs afin d’éviter de sélectionner accidentellement la mauvaise machine.
Le travail NDISTest 6.5 - [2 Machine] - CheckConnectivity
Le travail NDISTest 6.5 - [2 Machine] - CheckConnectivity garantit que les appareils de test et de support peuvent communiquer correctement en effectuant un envoi et une réception de base.
Si la tâche « Exécuter le script pour détecter les appareils et remplir les paramètres » est marquée comme ayant échoué, la suppression automatique de l’appareil a échoué. Double-cliquez sur detect.wtl pour ouvrir le journal de détection automatique et déterminer l’appareil qui n’a pas été détecté.
La détection automatique des appareils ne fonctionnera que si les machines sont configurées dans la topologie recommandée. La machine de test doit contenir la carte réseau cible et la carte réseau du message. La machine de support doit contenir une carte réseau de support et une carte réseau de message. Tout autre appareil Ethernet connecté rendra la détection automatique impossible et exigera que les appareils soient renommés pour désigner leurs rôles.
La carte réseau de prise en charge doit être connectée à la carte réseau de test à l’aide d’une connexion directe (pas de commutateur ou de hub) afin d’éviter les interférences. Les cartes réseau de message sont les mêmes que celles utilisées pour la connectivité à l’ordinateur contrôleur et au reste du labo ou du réseau d’entreprise.
Logique de script CheckConnectivity
La logique de script de création automatique est la suivante :
Recherchez la carte réseau du message.
Recherchez des appareils nommés « MessageDevice ».
S’il est introuvable, recherchez la carte réseau Ethernet avec une adresse IP affectée DHCP.
Si elle est toujours introuvable, recherchez la carte réseau Ethernet avec une adresse IP affectée statiquement.
Si rien n’est trouvé, échouez et quittez.
Si vous exécutez sur l’ordinateur de support, recherchez la carte réseau de prise en charge.
Recherchez des appareils nommés « SupportDevice0 ».
S’il est introuvable, recherchez une carte réseau Ethernet physique activée qui n’est pas la carte réseau du message.
Si rien n’est trouvé, échouez et quittez.
Vous trouverez tous les détails de la logique de script de détection automatique en examinant le script qui se trouve à l’emplacement suivant : \\[CONTROLLER]\Tests\[ARCH]\NDIS\Scripts\detect.wsf
Où :
[CONTRÔLEUR]. Nom de l’ordinateur contrôleur.
[ARCH]. X86 (pour les processeurs x86) ou amd64 (pour les processeurs x64).
Lecture des journaux NDISTest
Une façon de lire les journaux NDISTest consiste à double-cliquer sur « ndistest.wtl » ou à cliquer avec le bouton droit sur le résultat de la tâche et à accéder à « Fichiers supplémentaires » pour le résultat du travail que vous souhaitez afficher. Cela ouvre la visionneuse du journal du Gestionnaire DTM.
NDISTest produit également des journaux HTML qui sont souvent beaucoup plus lisibles. Pour afficher le journal HTML d’un résultat, cliquez avec le bouton droit sur le résultat de la tâche et accédez à « Fichiers supplémentaires ». Plusieurs fichiers seront répertoriés ; ouvrez le fichier checkconnectivity.htm sous le dossier « Client ».
Ouvrez également « ndistest.htm » à partir du dossier « Client » pour afficher les échecs des tâches de préconfiguration et de postconfig qui s’exécutent avant et après chaque test NDISTest 6.5.