Exportación de un trabajo HLK con errores
Ahora puede exportar un trabajo con errores para que se pueda ejecutar en una máquina fuera del entorno HLK completo. Para los desarrolladores de controladores, esta característica permite la ejecución independiente de la prueba para simplificar el proceso de reproducción de errores.
Un entorno de prueba exportado simula estrechamente un entorno HLK dedicado. Sin embargo, esto no garantiza la ejecución de pruebas idéntica. Es posible que un usuario tenga que controlar cualquiera de las siguientes circunstancias:
- La infraestructura de prueba no controla los reinicios. El usuario tendrá que reiniciar manualmente el sistema en muchos casos.
- Puede haber casos en los que la prueba reinicia el sistema a través de la infraestructura del cliente HLK dentro de una tarea de prueba. Por ejemplo, es posible que estos reinicios no se capturen en el archivo por lotes como avisos o reinicios durante la ejecución independiente.
- Los archivos de registro con nombre no único escritos en la misma ubicación por diferentes tareas pueden dar lugar a que se sobrescriban algunos de estos archivos.
- Los parámetros escritos en el archivo por lotes pueden diferir al ejecutarse en sistemas diferentes. Por ejemplo, los identificadores de instancia de hardware pueden diferir para el mismo hardware y controlador cuando se mueven a un sistema diferente, y el usuario tendrá que buscar el valor de destino correspondiente (de Administrador de dispositivos, por ejemplo) y actualizar el archivo por lotes con el valor correcto.
- Es posible que las pruebas que dependen de un trabajo de configuración asociado para configurar el sistema no se preparen correctamente, ya que HLK solo exporta el propio trabajo de prueba.
No todos los resultados se pueden exportar. En la lista siguiente se describen los límites de las pruebas y los resultados de las pruebas que se pueden exportar:
- Las pruebas deben haberse ejecutado y completado con un estado superado, erróneo o cancelado.
- La ejecución de pruebas debe devolver correctamente los registros de infraestructura del sistema cliente. Estos archivos son necesarios para exportar la prueba.
- Solo se pueden exportar pruebas de una sola máquina. Las pruebas que requieren que se ejecuten varias máquinas no se pueden exportar.
- Las pruebas deben ejecutarse mediante el cliente de escritorio de HLK. Las ejecuciones de prueba en los sistemas cliente windows Core o Proxy Mobile no se pueden exportar.
- Las pruebas etiquetadas como no exportables debido a problemas conocidos de infraestructura u otros motivos no se pueden exportar.
- En la pestaña Resultados de HLK Studio, haga clic con el botón derecho en el resultado con errores y seleccione Exportar ejecución de pruebas.
- Aparece un cuadro de diálogo para guardar. Guarde el trabajo exportado en una unidad flash u otra ubicación externa para que pueda realizar la prueba exportada a otra máquina. La misma prueba no se puede exportar a la misma ubicación más de una vez. Un cuadro de diálogo confirmará que se completó la exportación.
- Los archivos binarios de prueba y un archivo por lotes necesarios para ejecutar la prueba en un sistema independiente se exportan al directorio especificado. La prueba exportada se guarda en un subdirectorio con el nombre y la arquitectura del trabajo con errores. Los componentes de infraestructura que se deben instalar para ejecutar la prueba se guardan en un subdirectorio denominado Infraestructura junto con el nombre de la arquitectura a la que se destina la infraestructura.
Nota
Los componentes de infraestructura deben instalarse solo una vez en el sistema de destino. No es necesario reinstalar estos componentes para cada trabajo con errores.
Por ejemplo, al guardar un trabajo x64 con errores titulado Establecer destino de representación en la raíz de la unidad E:\ exporta la carpeta de trabajo y el instalador de infraestructura mediante la siguiente estructura de carpetas:
E:.
├───Infrastructure(X64)
└───Set_Render_Target(X64)
├───CoreClr
├───MinTe
│ └───CoreClr
├───NetFx2.0
├───NetFx4.5
├───verifysupportfiles
│ ├───CoreClr
│ ├───MinTe
│ │ └───CoreClr
│ ├───NetFx2.0
│ └───NetFx4.5
└───[windir]
└───system32
El paquete de prueba exportado contiene varios archivos y subcarpetas, incluidos los siguientes:
- readme1st.txt: contiene información sobre cómo ejecutar la prueba exportada
- run.cmd: archivo por lotes que se usa para ejecutar la prueba
- archivos binarios y otros archivos necesarios para ejecutar la prueba
- setup(architecture).exe: instale el ejecutable que se usa para instalar la infraestructura.
Lleve la carpeta de prueba exportada a la nueva máquina para realizar pruebas. La ruta de acceso no debe contener espacios, ya que esto provocará un error en algunas pruebas.
Ejecute (guardar carpeta)\Infrastructure(architecture)\setup(architecture).exe para instalar los componentes de infraestructura antes de ejecutar la prueba. El instalador de infraestructura mostrará un cuadro de diálogo que indica si la instalación de los componentes se realizó correctamente.
Nota
Los componentes de infraestructura deben instalarse solo una vez en el sistema de destino. No es necesario reinstalar estos componentes para cada trabajo con errores.
Nota
La arquitectura del instalador y el trabajo deben coincidir con la arquitectura del sistema de destino en el que está instalado.
- Dentro del archivo por lotes de la carpeta (guardar carpeta)(nombre del trabajo)(arquitectura), puede realizar los cambios necesarios en el archivo por lotes para ejecutarse en el equipo de prueba. Como ejemplos, puede realizar los siguientes cambios:
- Comentar líneas que no contribuyen al error del trabajo
- Cambiar los valores de parámetro para que coincidan con la máquina en la que se ejecuta la prueba exportada. Por ejemplo, el identificador de instancia del mismo hardware a menudo difiere en dos sistemas independientes, por lo que tendría que actualizarse antes de ejecutar la prueba exportada.
- Adición de comandos para conectar un depurador
Nota
Si una tarea muestra el mensaje de error "Esta prueba no se puede ejecutar porque podría reiniciar la máquina", debe editar run.cmd y anexar /rebootstatefile=(some_file_name) a la línea de comandos de la tarea con errores, como se muestra en el ejemplo siguiente:
cmd /c TE.exe /inproc /enablewttlogging /appendwttlogging devfund_pcirootportsurpriseremovetest_wlk_certification.dll
/p:"MultiDeviceHardwareIdSdelQueryHardwareID=!MultiDeviceHardwareIdSdelQueryHardwareID!"
/p:"MultiDeviceInstanceIdSdelWDKDeviceID=!MultiDeviceInstanceIdSdelWDKDeviceID!" /p:"DQ=!DQ!"
/p:"TestCycles=!TestCycles!" /p:"IOPeriod=!IOPeriod!" /p:"WDTFREMOTESYSTEM=!WDTFREMOTESYSTEM!"
/p:"Wpa2PskAesSsid=!Wpa2PskAesSsid!"
/p:"DriverVerifierAdditionalDrivers=!DriverVerifierAdditionalDrivers!"
/p:"DriverVerifierExcludedFlags=!DriverVerifierExcludedFlags!"
/p:"DriverVerifierCustomizeConfiguration=!DriverVerifierCustomizeConfiguration!"
/rebootStateFile=rebootstatefile.xml
- Una vez que haya terminado con modificaciones, inicie un símbolo del sistema con privilegios administrativos, cambie al directorio de prueba y ejecute run.cmd. Cada tarea del archivo por lotes está asociada a un número de tarea que se puede usar como punto de partida al ejecutar el archivo por lotes. De forma predeterminada, la ejecución se detiene entre las tareas. Se admiten los siguientes modos de ejecución:
- "Ejecutar" sin parámetros inicia la ejecución al principio del archivo por lotes, con una pausa entre cada tarea.
- "Ejecutar 5" iniciará el archivo por lotes y pasará a la tarea 5.
- "Ejecutar FAST" inicia el archivo por lotes en modo rápido (sin pausa entre tareas) al principio.
- "Ejecutar 5 FAST" iniciará el archivo por lotes en modo rápido (sin pausa entre tareas) en la tarea 5.
- "RebootResume" iniciará el archivo por lotes desde el último reinicio desde la última ejecución del script. También se admite la marca FAST.
- "RerunLast" iniciará el archivo por lotes desde el comando que se estaba ejecutando cuando el archivo por lotes salió por última vez. Este comando se puede usar para volver a ejecutar una tarea varias veces presionando Control+C para salir del script durante la tarea y ejecutando rerunlast.cmd para volver a ejecutar el comando anterior. También se admite la marca FAST.
- Una vez que identifique y corrija el problema que provoca un error en la prueba, puede implementar la corrección y comprobar que el trabajo se realiza correctamente en el entorno de HLK.
Nota
No se pueden volver a importar los resultados correctos en el entorno de HLK. Debe volver a ejecutar el trabajo desde dentro del entorno.