checkbox-cli - Online en la nube

PROGRAMA:

NOMBRE

checkbox_ng - Documentación de CheckboxNG

CheckboxNG es una herramienta de prueba de hardware útil para certificar computadoras portátiles, computadoras de escritorio y servidores
con Ubuntu. Es una nueva versión de Checkbox que se construye directamente sobre PlainBox

Casilla de verificación NG reemplaza Casilla de verificación, donde corresponda.

ADVERTENCIA:
La documentación está en desarrollo. Algunas cosas están mal, son inexactas o se describen
objetivos de desarrollo en lugar del estado actual.

INSTALACIÓN

CheckboxNG se puede instalar desde un PPA (recomendado) o pypi en Ubuntu Precise (12.04) o
más nuevo.

$ sudo add-apt-repository ppa: checkbox-dev / ppa && sudo apt-get update && sudo apt-get install checkbox-ng

RUNNING ESTABLE LIBERAR ACTUALIZAR TESTS

CheckboxNG tiene soporte especial para ejecutar pruebas de actualizaciones de versiones estables de forma automatizada.
conducta. Esto ejecuta todos los trabajos del lista blanca sru. y envía los resultados al
sitio web de certificación.

Para ejecutar pruebas de SRU, necesitará conocer el llamado ID seguro del dispositivo que está
pruebas. Una vez que sepa que todo lo que necesita hacer es ejecutar:

$ casilla de verificación sru $ id_seguro envío.xml

El segundo argumento, submit.xml, es un nombre del archivo de respaldo que solo se crea
cuando el envío de datos al sitio web de certificación no funciona por cualquier motivo.

PRESENTACIÓN DE INFORMES LOCO

Para informar errores en el proyecto Checkbox, necesitará una cuenta de Launchpad. Puedes encontrar
Instrucciones on cómo a Para crear una <https://help.launchpad.net/YourAccount/NewAccount>
útil. Una vez que tenga una cuenta, puede reporte loco <https://bugs.launchpad.net/checkbox-
proyecto / + filebug>.

En esa página puede seleccionar el proyecto en el que desea presentar el error (usamos varios
proyectos para coordinar lanzamientos y preferimos tener errores asociados con los
parte de Checkbox). Si conoce el proyecto correcto para usar, simplemente utilícelo y presente el error. Si
no conoce tanto los aspectos internos de Checkbox o tiene dudas, simplemente archívelo en la base
Proyecto 'Checkbox' (puede usar así de reservas liga
<https://bugs.launchpad.net/checkbox/+filebug>.) Un miembro del equipo de desarrollo
revise su error y vuelva a asignarlo a la ubicación adecuada. El número de error no
cambiar cuando eso suceda.

EL REINO UNIDO CAJA APILAR

Checkbox Stack es una colección de proyectos que juntos constituyen una prueba completa
y solución de certificación. Se compone de las siguientes partes (consulte la tabla siguiente para
detalles adicionales). Todos los proyectos están vinculados desde el Launchpad proyecto grupo de XNUMX
<https://launchpad.net/checkbox-project>.

Arquitectura Diagrama
[imagen: diagrama de arquitectura] [imagen]

Este diagrama contiene una aproximación de alto nivel de la arquitectura actual de Checkbox.
Hay tres "pilares" principales. A la izquierda tenemos final productos. Esas son herramientas reales
que están utilizando la certificación y los ingenieros. A la derecha tenemos el test mercado. Es
un mercado abierto de proveedores y proveedores de pruebas. Las pruebas se envuelven en contenedores conocidos como
proveedores. En el centro tenemos tres componentes compartidos. Aquellos implementan la mayor parte de la
framework e interfaces de usuario para la ejecución de pruebas. Finalmente en la esquina inferior izquierda hay
es una parte de la casilla de verificación (una biblioteca) que se comparte con HEXR para ciertas tareas. HEXR es un
aplicación web fuera del alcance utilizada por parte del proceso de certificación. Las flechas implican
la comunicación con la forma de la flecha muestra quién llama a quién.

Como se mencionó anteriormente, en la columna central hay tres componentes principales del código compartido
(compartido por todos los que utilizan los productos finales que se analizan a continuación). El código compartido es
compuesto por plainbox, checkbox-ng y checkbox-gui. Las responsabilidades de los componentes son
discutido con más detalle en la tabla siguiente. Aquí podemos ver que checkbox-gui usó DBus
API expuesta por checkbox-ng, que a su vez usa checkbox-support (una biblioteca auxiliar
separados, así que comparta algo de código con HEXR) y plainbox.

En la columna del lado derecho hay varios proveedores de pruebas. El proyecto de casilla de verificación es
producir y mantener una serie de proveedores (consulte la tabla a continuación), pero se espera
que nuestros usuarios intermedios también producirán sus propios proveedores (específicos para un cliente o
proyecto). Eventualmente, algunos proveedores pueden provenir de terceros que adoptarán el
formato.

Por último, en la esquina inferior izquierda, la biblioteca compartida, esta biblioteca contiene muchos analizadores
de varios formatos de archivo y formatos de salida. Técnicamente, esta biblioteca es una dependencia de
HEXR, casilla de verificación-ng y de proveedores. Como complejidad adicional, la biblioteca debe llamarse
desde el código python3 y el código python2.

NOTA:
La comunicación entre checkbox-ng y plainbox es bidireccional. Ofertas de Plainbox
algunas interfaces base y puntos de extensión. Esos están todos expuestos a través de plainbox.
(usando API comunes) pero algunas de ellas están realmente implementadas en checkbox-ng.

ADVERTENCIA:
Todas las API internas son semiinestables. La API de DBus es más estable en la práctica, pero debería
no se puede confiar en él. Se recomienda que los proyectos se fusionen en lp: casilla de verificación donde API
las transiciones se pueden manejar con gracia. La única API estable es el formato de archivo.
especificación (definiciones de puestos y listas blancas). La especificación del lanzador será
estabilizado en la próxima versión.

Componente Descripción
┌────────────────────────┬─────────────────────── ──────────────────┬──────────────────────────┐
│Proyecto │ Responsable de │ Tipo │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│ Casilla de verificación de próxima generación │ │ Aplicación │
│ (GUI) │ · El C ++ / QML │ │
│ │ interfaz de usuario │ │
│ │ │ │
│ │ · El │ │ gráfico
│ │ lanzador para │ │
│ │ proveedores, p. Ej. │ │
│ │ casilla de verificación-certificación-cliente │ │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│ Casilla de verificación de próxima generación │ │ Aplicación │
│ (CLI) │ · La línea de comandos de Python │ │
│ │ interfaz │ │
│ │ │ │
│ │ · la interfaz de usuario de texto │ │
│ │ │ │
│ │ · el comando de prueba SRU │ │
│ │ │ │
│ │ · API de certificación adicionales │ │
│ │ │ │
│ │ · enviando datos a Launchpad │ │
│ │ │ │
│ │ · enviando datos a HEXR │ │
│ │ │ │
│ │ · el servicio DBus que necesita │ │
│ │ Interfaz gráfica de usuario │ │
└────────────────────────┴──────────────────────── ──────────────────┴──────────────────────────┘

│ Certificación de cliente │ │ Proveedor │
│Proveedor │ · cliente-certificado-canónico │ │
│ │ ejecutable │ │
│ │ │ │
│ │ · certificación del cliente │ │
│ │ listas blancas │ │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│ Certificación de servidor │ │ Proveedor │
│Proveedor │ · certificación de servidor │ │
│ │ listas blancas │ │
│ │ │ │
│ │ · listas blancas de servidores adicionales │ │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Servidor de sistema en chip │ │ Proveedor │
│Proveedor de certificación │ · Certificación de servidor SoC │ │
│ │ listas blancas │ │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Proveedor de casilla de verificación │ │ Proveedor │
│ │ · Casi todas las definiciones de trabajo │ │
│ │ │ │
│ │ · La mayoría de los "scripts" personalizados │ │
│ │ │ │
│ │ · Lista blanca predeterminada y SRU │ │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│ Proveedor de recursos │ │ Proveedor │
│ │ · Casi todos los trabajos de recursos │ │
│ │ │ │
│ │ · Casi todos los "scripts" de recursos │ │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│ Compatibilidad con casillas de verificación │ │ Biblioteca │
│ │ · Código de soporte para varios │ │
│ │ proveedores │ │
│ │ │ │
│ │ · Analizadores para muchos formatos de texto │ │
├────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│PlainBox │ │ Biblioteca y desarrollo │
│ │ · Casi toda la lógica central │ Kit de herramientas │
│ │ │ │
│ │ · RFC822 (definición de trabajo) │ │
│ │ analizador │ │
│ │ │ │
│ │ · Manejo de la configuración │ │
│ │ │ │
│ │ · Sesión de prueba │ │
│ │ (suspender / reanudar) │ │
│ │ │ │
│ │ · Corredor de empleo │ │
│ │ │ │
│ │ · Lanzador de confianza │ │
│ │ │ │
│ │ · Solucionador de dependencias │ │
│ │ │ │
│ │ · Manejo de línea de comandos │ │
│ │ │ │
│ │ · XML, HTML y XSLX │ │
│ │ exportadores │ │
│ │ │ │
│ │ · y más ... │ │
│ │ │ │
│ │ · Kit de herramientas de desarrollo de proveedores │ │
│ │ │ │
│ │ · 'proveedor de inicio de plainbox' │ │
│ │ │ │
│ │ · Implementación de 'manage.py' │ │
└────────────────────────┴──────────────────────── ──────────────────┴──────────────────────────┘

│ Casilla de verificación heredada (sin │ │ Aplicación monolítica │
│ ya se mantiene) │ · Aplicaciones │ Biblioteca y datos │
│ │ │ │
│ │ · GUI Qt4 │ │
│ │ │ │
│ │ · GUI Gtk2 │ │
│ │ │ │
│ │ · Urwid (texto) GUI │ │
│ │ │ │
│ │ · Núcleo │ │
│ │ │ │
│ │ · Complemento y evento / mensaje │ │
│ │ Motor │ │
│ │ │ │
│ │ · Casi todas las funciones │ │
│ │ implementó un complemento principal │ │
│ │ │ │
│ │ · Datos │ │
│ │ │ │
│ │ · Trabajos y listas blancas │ │
└────────────────────────┴──────────────────────── ──────────────────┴──────────────────────────┘

CAMBIO

NOTA:
Este registro de cambios contiene solo un resumen de los cambios. Para una contabilidad más precisa de
historial de desarrollo, inspeccione el historial de la fuente directamente.

Casilla de verificación NG 0.23 (inédito)
· Corrección de errores: https://launchpad.net/checkbox-ng/+milestone/0.23

Casilla de verificación NG 0.22
· Corrección de errores: https://launchpad.net/checkbox-ng/+milestone/0.22

Casilla de verificación NG 0.3
· Corrección de errores: https://launchpad.net/checkbox-ng/+milestone/0.3

Casilla de verificación NG 0.2
· Corrección de errores: https://launchpad.net/checkbox-ng/+milestone/0.2

Casilla de verificación NG 0.1
· Versión inicial

· Soporte para mostrar la configuración

· Soporte para ejecutar pruebas SRU (prueba de regresión automática)

PROBAR GUIONES

Los 'scripts' de prueba son pequeños programas que se utilizan para ayudar en la implementación de las pruebas.

prueba_brillo
Este script prueba el brillo de la luz de fondo del sistema y se puede cambiar usando el
interfaces del kernel en / sys / class / backlight. Puede haber más de una interfaz para elegir
desde, por lo que la interfaz correcta a utilizar se selecciona mediante el uso de la heurística prescrita en
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight. El brillo
se manipula actualizando el archivo de brillo de la interfaz y el brillo actual
se comprueba el archivo para ver si el valor se modificó al brillo seleccionado.

PERFILES CONFIGURACIÓN

Los perfiles de ejecución, o lanzadores, permiten especificar un conjunto de configuración predefinido
opciones que permiten la personalización de la pantalla de bienvenida, listas blancas mostradas así como
guardar los resultados localmente o enviar el archivo de envío a Launchpad oa la Certificación
database / HEXR, así como algunos otros parámetros.

La configuración del perfil es parte de un script de inicio y usa checkbox-gui o
checkbox-launcher (en modo texto / CLI) como un shebang para interpretar la clave / valores.

Este documento proporciona una referencia sobre la funcionalidad y la sintaxis del lanzador. Para entender el
diseño y conceptos y ver varios ejemplos, es posible que desee leer el tutoriales sobre cómo
crear lanzadores y su relación con Checkbox heredado.

Sintaxis
Como checkbox-gui es una aplicación Qt, la configuración debe seguir las reglas de estilo INI del
QConfiguración <http://qt-project.org/doc/qt-5/QSettings.html> clase.

Se admiten valores de varias líneas, pero deben incluirse entre comillas dobles y líneas adicionales
debe comenzar con un espacio, por ejemplo:

[categoría]
key = "Hola
Mundo"

· De QML:

settings.value ("categoría / clave", i18n.tr ("valor_predeterminado"))

· Desde C ++:

settings-> value ("categoría / clave", app.tr ("valor_predeterminado"))

Por el contrario, los lanzadores específicos del lanzador de casillas de verificación deben seguir Python Analizador de configuración
<https://docs.python.org/3/library/configparser.html#supported-ini-file-structure> sintaxis.

Además, algunas configuraciones solo tienen sentido para GUI o CLI y, por lo tanto, no son entendidas por
el otro. Estos se indican a continuación.

Soportado Ajustes
bienvenido / título
Título de la aplicación QML y encabezado de la pantalla de bienvenida. Predeterminado a System Pruebas .

bienvenido / texto
Mensaje de bienvenida para mostrar en la primera pantalla (checkbox-gui admite texto enriquecido
permitiendo el marcado de estilo HTML). Predeterminado a Bienvenido a System Pruebas. [...]

suite / whitelist_filter
Expresión regular para que coincida con un subconjunto de nombres de archivos de la lista blanca. En checkbox-gui it
por defecto es .*. Para checkbox-launcher no tiene valor predeterminado y debe estar definido.

suite / whitelist_selection
Patrón que las listas blancas deben coincidir para ser preseleccionado. Expresión regular de Python.
No tiene defecto y debe estar definido. (Solo CLI)

suite / skip_whitelist_selection
Si se establece en verdadero, el usuario no recibirá una opción de lista blanca. Solo los preseleccionados
se seleccionarán unos (ver whitelist_selection). (Solo CLI).

suite / skip_test_selection
Si se establece en verdadero, el usuario no podrá anular la selección de las pruebas antes de ejecutarlas: todas las pruebas
en la lista blanca seleccionada se ejecutará. (Solo CLI)

envío / mensaje
Texto del encabezado de la ventana emergente de envío, que se muestra al usuario después de que se haya enviado el envío.
terminado. (Solo GUI)

submit / input_type
Muestre un campo de entrada de texto para ingresar el ID seguro o la dirección LP (predeterminado). Para
simplemente guarde los resultados en el disco, debe usar el ninguna valor. Para validar usando una expresión regular,
debe ser expresiones regulares. (Solo GUI)

sumisión / expresión regular
Expresión regular para validar la entrada en el campo de envío (por ejemplo, correo electrónico, secure_id)
si input_type es regex. (Solo GUI). RegExpValidator, predeterminado .*

submit / input_placeholder
Texto temporal para poner en el campo de entrada, utilizado para guiar al usuario. Launchpad E-Mail
Dirección (predeterminado) o Seguro ID (15 or 18 caracteres). (Solo GUI)

sumisión / secure_id
Secure_id preconfigurado para completar el campo de texto.

presentación / ok_btn_text
La etiqueta del botón "Enviar". Enviar Resultados (predeterminado) o Guardar Resultados. (GUI
solamente)

sumisión / cancel_warning
Mostrar al usuario si quiere salir sin haber guardado el informe. Estás a punto de
para salir de esta ejecución de prueba sin guardar su informe de resultados. ¿Quieres guardar el
¿reporte? (Solo GUI)

sumisión / submit_to_hexr
Booleano, agregue un encabezado adicional para enviar también los resultados a HEXR (funciona con el
transporte de certificación)

exporter / xml_export_path
Ubicación para guardar el archivo de envío XML, si se establece en una cadena vacía, se abrirá un
cuadro de diálogo para guardar archivo. Defecto: /tmp/envío.xml (Solo GUI)

transporte / submit_to
Punto final de transporte. Predeterminado a . Admite el envío a LP (por defecto,
propuesta de plataforma de lanzamiento), título o certificacióno local (guardar en el disco)

transporte / submit_url
URL a la que enviar los resultados. Esto permite subir a diferentes sitios web, por ejemplo
se puede cargar directamente en hexr o en los sitios de preparación. Usado solo con el
título o certificación enviar_al valor.

transporte / config_filename
Nombre de un archivo de configuración personalizado para cargar. Los archivos de configuración se utilizan principalmente para definir
Variables de entorno. (Solo CLI)

transporte / dont_suppress_output
Si se configura, los recursos, trabajos locales y archivos adjuntos se mostrarán en la pantalla, esto
genera mucho texto y es principalmente para depurar. (Solo CLI)

CHECKBOX / PLAINBOX LANZADORES TUTORIAL

Este documento proporciona una explicación de por qué son necesarios los lanzadores, qué puede lograr
con ellos, y repasa varios ejemplos para describir mejor sus capacidades. Para
referencia detallada sobre qué configuraciones son compatibles con los lanzadores y sintaxis específica para
archivos del lanzador, mira / perfiles.

Legado casilla de verificación comportamiento control
En el pasado, el comportamiento de Checkbox estaba controlado por tres mecanismos.

Primero, las funciones de la casilla de verificación podrían aumentarse agregando complementos. Por ejemplo, el
la capacidad de enviar al sitio web de certificación fue agregada por el paquete de certificación de casilla de verificación
usando un complemento. Los complementos incluidos por la certificación de casilla de verificación y que agregan un nuevo comportamiento
a la casilla de verificación base eran:

/usr/share/checkbox-certification/plugins/certify_message.py
/usr/share/checkbox-certification/plugins/submission_info.py
/usr/share/checkbox-certification/plugins/backup.py
/usr/share/checkbox-certification/plugins/certify_prompt.py
/usr/share/checkbox-certification/plugins/certify_report.py
/usr/share/checkbox-certification/plugins/certify_schemas.py

Estos agregaron la forma de solicitar al usuario datos específicos del envío, generar el xml
informe y otras funciones.

A continuación, los comportamientos de los complementos se pueden configurar o controlar mediante la configuración
archivos, que están "en cascada". Un archivo de configuración puede incluir otros y estos a su vez
incluir a otros.

Este es un ejemplo de un archivo de configuración principal project-qt.ini específico del proyecto. Es el primero
archivo leído cuando se inicia el cliente específico del proyecto. Algunas configuraciones están abreviadas:

[DEFECTO]
incluye =% (checkbox_oem_share) s / configs / checkbox-project-base-qt.ini% (checkbox_project_share) s / configs / checkbox-project-base.ini

[casilla de verificación / plugins / environment_info]
repositorios = deb http: //.* \ (archivo \ | seguridad \). ubuntu.com/ubuntu precisa-seguridad
enrutadores = múltiples
servidor_iperf = 10.20.30.40
lista_fuentes = /etc/apt/sources.list
wpa_n_psk = contraseña
wpa_n_ssid = punto de acceso

[casilla de verificación / plugins / user_interface]
title = Mi proyecto Prueba del sistema

Observe la línea incluye, esto le indica que cargue el archivo de configuración para
checkbox-project-base-qt y checkbox-project-base. Checkbox-project-base-qt carga el
configs para checkbox-certificate y checkbox-project. Los ajustes están en cascada, por lo que
Las opciones de configuración cerca de la parte superior anulan las que están cerca de la parte inferior.

Finalmente, el "binario" utilizado para invocar la casilla de verificación es un script de shell que define dónde encontrar
la casilla de verificación de cosas debe ejecutarse: puede definir un directorio compartido, un dato específico
directorio, apunte a un archivo de configuración y defina algunas variables de entorno que
puede necesitar durante la prueba. A continuación, se muestra un ejemplo de checkbox-project-qt:

#!/ bin / bash
exportar CHECKBOX_DATA = $ {CHECKBOX_DATA: -~ /. casilla de verificación}
exportar CHECKBOX_SHARE = ​​$ {CHECKBOX_SHARE: - / usr / share / checkbox}
export CHECKBOX_OPTIONS = $ {CHECKBOX_OPTIONS: --- log-level = debug --log = $ CHECKBOX_DATA / checkbox-project.log}
exportar CHECKBOX_CERTIFICATION_SHARE = ​​$ {CHECKBOX_CERTIFICATION_SHARE: - / usr / share / checkbox-certificate}
exportar CHECKBOX_OEM_SHARE = ​​$ {CHECKBOX_PROJECT_BASE_SHARE: - / usr / share / checkbox-project-base}
exportar CHECKBOX_PROJECT_SHARE = ​​$ {CHECKBOX_PROJECT_SHARE: - / usr / share / checkbox-project}

# Conveniencia para definir el directorio PYTHONPATH.
if ["$ CHECKBOX_SHARE"! = "/ usr / share / checkbox"]; luego
export PYTHONPATH = "$ CHECKBOX_SHARE: $ PYTHONPATH"
fi

python3 $ CHECKBOX_SHARE / ejecutar "$ @" $ CHECKBOX_PROJECT_SHARE / configs / $ (nombre base $ 0) .ini

Aquí puedes ver que define algunas ubicaciones y una parte importante es el python3 final
línea, donde ubicará y usará el archivo de configuración .ini requerido que vimos anteriormente.

Esta organización jerárquica era muy poderosa pero también difícil de manejar, y
también tenía algunas limitaciones. Parte del trabajo que hicimos con la casilla de verificación fue integrar todos los
complementos específicos del proyecto en el tronco de la casilla de verificación, de esta manera todo el código central está en un solo lugar,
y las variantes específicas del proyecto solo proporcionan trabajos, listas blancas, datos y configuración,
sin agregar nuevos comportamientos.

Nuevo caja llana comportamiento control
A diferencia de la casilla de verificación, el núcleo de plainbox es monolítico y no tiene ningún concepto de complementos. Esta
facilita la comprensión y el trabajo. El núcleo de plainbox tiene implementaciones para todos
las funciones en los paquetes de casillas de verificación anteriores, por lo que no es necesario agregar funciones para usar las funciones
como sumisión a certificación o generación de informes.

Lo que llamamos plainbox es la librería que implementa toda la funcionalidad, como se puede ver
esta página.

Plainbox proporciona herramientas para ayudar a los desarrolladores de pruebas a escribir y empaquetar pruebas. Estos son
entregado en "proveedores", que son entidades diseñadas para encapsular descripciones de prueba,
scripts personalizados para pruebas, listas blancas y datos variados. Fueron diseñados para permitir
equipos para escribir y entregar sus pruebas personalizadas sin preocuparse demasiado por el
código plainbox subyacente.

Para obtener información sobre cómo escribir pruebas y proveedores, consulte el Tutorial para proveedores

Sin embargo, cuando realmente usamos estas pruebas para verificar un sistema real, queríamos proporcionar
algo más fácil y más cercano a la experiencia del usuario de la casilla de verificación. Creamos dos clientes,
checkbox-gui y checkbox-cli, que tenían algunos comportamientos codificados, y también comenzamos
creando otros clientes que se basaron en estos pero que tenían un propósito específico. Por ejemplo,
teníamos una versión de checkbox para pruebas de SRU, otra para certificación de servidor, etc.

Pero luego nos dimos cuenta de que gran parte del código estaba duplicado y los comportamientos eran comunes
excepto por algunos cambios. Así que se nos ocurrió el concepto de "lanzadores", que son
algo similar a los archivos de configuración de checkbox y a los lanzadores de scripts de shell.

La idea es que checkbox-gui y checkbox-cli tengan algunos comportamientos muy básicos, ya que
son los clientes que se envían por defecto con ubuntu. Pueden mostrar todos los disponibles
listas blancas, mostrar un mensaje de bienvenida predefinido, y al final le permitirá al usuario ver el
html y envíelo a Launchpad utilizando su dirección de correo electrónico, similar a la versión
de la casilla de verificación que se envió con Ubuntu.

En lugar de utilizar complicados conmutadores de línea de comandos, los lanzadores le permiten configurar algunos
comportamientos opcionales para personalizar su experiencia de prueba. Un lanzador contiene configuraciones y
es similar a un script de shell, pero el intérprete será checkbox-gui o
lanzador de casillas de verificación.

A continuación, se muestran algunos ejemplos de lo que se puede hacer con los lanzadores.

Como sorpresa, checkbox-cli es en sí mismo un lanzador:

#!/ usr / bin / env casilla de verificación-lanzador
[Bienvenido]
text = ¡Bienvenido a las pruebas del sistema!
La casilla de verificación proporciona pruebas para confirmar que su sistema está funcionando correctamente.
Una vez que haya terminado de ejecutar las pruebas, puede ver un informe resumido para
tu sistema.
Advertencia: algunas pruebas pueden hacer que su sistema se congele o se vuelva
insensible. Guarde todo su trabajo y cierre todos los demás en ejecución.
aplicaciones antes de comenzar el proceso de prueba.

[después]
whitelist_filter = ^ predeterminado $
whitelist_selection = ^ predeterminado $
skip_whitelist_selection = Verdadero

[transporte]
enviar_a = plataforma de lanzamiento

Puedes ver aquí personalizamos algunas opciones: muestra un mensaje de bienvenida, automáticamente
selecciona la lista blanca predeterminada y la enviará a Launchpad cuando esté terminada.

Un ejemplo de lanzador gráfico es cliente-certificado-canónico.

#! / usr / bin / checkbox-gui

[Bienvenido]
title = "Certificación del sistema"
texto = " ¡Bienvenido a la certificación del sistema! Esta aplicación
recopilar información de su sistema. Luego se le pedirán pruebas manuales para
confirme que el sistema funciona correctamente. Finalmente, se le pedirá
la ID segura de la computadora para enviar la información a la certificación
base de datos. Para aprender a crear o localizar la ID segura,
por favor vea aquí: certificate.canonical.com "

[después]
whitelist_filter = "^ cliente- (cert | autoprueba). *"

[sumisión]
input_type = "regex"
input_placeholder = "ID segura (15 o 18 caracteres)"
ok_btn_text = "Enviar resultados"
submit_to_hexr = "verdadero"

[exportador]
xml_export_path = "/tmp/submission.xml"

[transporte]
submit_to = "certificación"

Los lanzadores gráficos son un poco más complicados, pero en esencia es similar, lo que
permite es que usted defina algunos parámetros para personalizar su experiencia de prueba.

Un lanzador de modo de texto muy simple es canonical-hw-collection, que solo ejecuta el básico
pruebas de información de hardware y las carga en una base de datos de hardware:

[Bienvenido]
title = Recopilación de información de hardware
text = Recopilación de información de hardware. Es posible que se le solicite su contraseña.
Este proceso tomará aproximadamente 30 segundos y se le proporcionará
con una URL a través de la cual puede confirmar y registrar su hardware
sumisión.

[después]
whitelist_filter = ^ hwsubmit $
whitelist_selection = ^ hwsubmit $
skip_whitelist_selection = Verdadero
skip_test_selection = Verdadero

[sumisión]
# Un secure_id falso asegura que no lo preguntamos
# Siempre se puede anular en el archivo .conf.
id_seguro = 000

[transporte]
submit_to = certificación
enviar_url = https://hardware-server.example.com/

Finalmente, canonical-driver-test-suite proporciona un lanzador de modo gráfico y de texto,
que son funcionalmente equivalentes:

#! / usr / bin / checkbox-gui

[Bienvenido]
title = "Canonical Driver Test Suite"
texto = " Bienvenido a Canonical Driver Test Suite.

Este programa contiene pruebas automáticas y manuales para ayudarlo a descubrir
problemas que surgirán al ejecutar los controladores de su dispositivo en Ubuntu.

Esta aplicación guiará al usuario a través de estas pruebas en un
orden predeterminada y recopilar automáticamente tanto la información del sistema como
así como los resultados de las pruebas. También le pedirá al usuario que ingrese cuando sea manual.
se requiere prueba.

El tiempo de ejecución de las pruebas está determinado por las pruebas que decida realizar.
ejecutar. El usuario tendrá la oportunidad de personalizar la ejecución de la prueba para
acomodar al conductor y la cantidad de tiempo disponible para la prueba.

Para comenzar, simplemente haga clic en el botón Continuar a continuación y siga las instrucciones en pantalla.
instrucciones. "

[después]
whitelist_filter = "^ ihv -. *"

[sumisión]
ok_btn_text = "Guardar resultados"
input_type = "ninguno"

[exportador]
xml_export_path = ""

[transporte]
submit_to = "local"

Modo de texto:

#!/ usr / bin / env casilla de verificación-lanzador
[Bienvenido]
text = Bienvenido a Canonical Driver Test Suite
Este programa contiene pruebas automáticas y manuales para ayudarlo a descubrir
problemas que surgirán al ejecutar los controladores de su dispositivo en Ubuntu.
Esta aplicación guiará al usuario a través de estas pruebas en un
orden predeterminada y recopilar automáticamente tanto la información del sistema como
así como los resultados de las pruebas. También le pedirá al usuario que ingrese cuando sea manual.
se requiere prueba.
El tiempo de ejecución de las pruebas está determinado por las pruebas que decida realizar.
ejecutar. El usuario tendrá la oportunidad de personalizar la ejecución de la prueba para
acomodar al conductor y la cantidad de tiempo disponible para la prueba.
Para comenzar, simplemente haga clic en el botón Continuar a continuación y siga las instrucciones en pantalla.
instrucciones.

[después]
# Lista (s) blanca (s) mostradas en la pantalla de selección de suite
whitelist_filter = ^ ihv -. *
# Whitelist_selection es obligatorio, por lo que lo configuramos con un valor falso para
# no hay listas blancas preseleccionadas.
whitelist_selection = falso

CAJA LIBERAR NUESTRO PROCESO

Esta página describe los pasos necesarios para lanzar versiones de Checkbox y Checkbox
Certificación al PPA estable perteneciente al equipo de Certificación de Hardware, de forma periódica
base. A lo largo de este documento, el término 'Casilla de verificación' se utiliza como un término general para cubrir
todas las versiones de Checkbox propiedad del equipo de certificación de hardware, actualmente Checkbox
sí mismo y las extensiones de certificación Checkbox.

General
Actualmente, el proceso se ejecuta en una cadencia quincenal, con una nueva versión de Checkbox cada
dos semanas. Cubre diez días laborables, y las tareas realizadas en cada día o grupo de
días se describe a continuación:

· Días 1-4: tiempo permitido para que se introduzcan nuevos cambios en el tronco.

· Día 5: Los cambios se fusionan desde el tronco de lp: casilla de verificación y lp: casilla de verificación-certificación a
sus respectivas ramas de lanzamiento. Los registros de cambios para ambos son golpeado en este punto y
las revisiones están etiquetadas. En esta etapa también puede ser necesario copiar el paquete 'fwts'
del desplegable FWTS Estable PPA <https://launchpad.net/~firmware-testing-team/+archive/ppa-
fwts-estable> al Caja tortugitas Pruebas PPA <https://launchpad.net/~checkbox-
dev / + archivo / prueba>.

· Días 6 a 9: el administrador de versiones realiza las pruebas para la certificación de hardware.
equipo, y un representante del equipo CE QA (el cliente principal de Checkbox dentro
Canónico)

· Día 9: se lleva a cabo una reunión de lanzamiento entre el administrador de lanzamiento del hardware
Equipo de certificación y representante del equipo CE QA. Posibles problemas con el
se identifican las liberaciones y se hacen planes para abordarlas.

· Día 10: La versión probada de Checkbox se copia al PPA estable.

Launchpad Bibliotecas
El proceso de lanzamiento requiere ramas separadas en Launchpad que contienen un semicongelado
versión del código que estaba en el tronco el día 5 del proceso. Esto es para que el desarrollo
puede continuar en el maletero sin poner en peligro la estabilidad de la versión de lanzamiento de
Caja. La relación entre todas las ramas involucradas en el proceso es como se muestra a continuación:

· lp: casilla de verificación / liberación <- lp: casilla de verificación

· lp: casilla de verificación-certificación / liberación <- lp: casilla de verificación-certificación

· lp: ~ checkbox-dev / checkbox / checkbox-packaging-release <-
lp: ~ checkbox-dev / checkbox / checkbox-packaging

Revisión de cuentas marcado loco
Antes de crear la versión candidata, el administrador de la versión debe revisar la lista de errores.
Milestoned para la próxima versión de Checkbox. Deberían visitar casilla de verificación evaluaciones del desarrollo
<https://launchpad.net/checkbox/+milestonesmilestones> y localice el hito fechado con
la fecha de lanzamiento.

· Para errores que están configurados en En curso con una rama asociada: enlace con la rama
propietario para ver si la fusión se puede completar antes de la fecha límite.

· Para errores que se encuentran en cualquier otro estado no cerrado (excepto Fijar Comprometido) - re-hito
ellos al siguiente hito.

Corte las ,
Para cortar la versión, tenemos que fusionar los cambios del tronco en la versión.
rama, consúltelos con un mensaje adecuado y actualice el registro de cambios en el tronco para que
los cambios futuros van bajo la versión correcta. Para cada combinación de ramas que se muestra arriba,
haz lo siguiente (el ejemplo usa lp: casilla de verificación y lp: casilla de verificación / liberación):

bzr branch lp: casilla de verificación / liberación casilla de verificación-liberación
bzr branch lp: casilla de verificación checkbox-trunk
liberación de casilla de verificación de cd
current_stable = `head -n1 $ (buscar. -nombre 'registro de cambios') | grep -oP '(? <= \ (). * (? = \))' `
bzr merge lp: casilla de verificación

en este punto si no hay cambios (excepto uno para debian / changelog) se fusionan y luego lo hacemos
no realizar una liberación del paquete en cuestión. En la práctica, esto sucede a menudo con
casilla de verificación-certificación pero nunca con casilla de verificación:

bzr commit -m "Combinado en cambios de rev $ (bzr revno -r etiqueta: $ current_stable lp: checkbox) a rev $ (bzr revno lp: checkbox) de lp: checkbox"
bzr push lp: casilla de verificación / liberación
cd `encontrar. -nombre 'debian'`; CD ..
etiqueta bzr `head -n1 debian / changelog | grep -oP '(? <= \ (). * (? = \))' `
dch -r (guardar registro de cambios modificado)
dch -i -U 'Registro de cambios aumentado'
compromiso de deuda
bzr push lp: casilla de verificación

El último paso del proceso es realizar una compilación de los paquetes en el
ppa: checkbox-dev / testing PPA. Para hacer esto, necesitamos ir a las páginas de recetas para el
casilla de verificación y/o casilla de verificación-certificación suelte ramas.

· prueba de casilla de verificación recetas <https://code.launchpad.net/~checkbox-dev/+recipe/checkbox-
las pruebas >

· casilla-de-certificación-prueba recetas <https://code.launchpad.net/~checkbox-
dev / + receta / casilla de verificación-certificación-prueba>

El Construcción Ahora La opción debería estar disponible en la página. Haga clic en él para comenzar una compilación.

Copiado firmware Probar Suite a las Pruebas PPA
La herramienta Firmware Test Suite es una herramienta de prueba para el firmware del sistema que, naturalmente, es muy
utilizado por Checkbox. Para asegurarse de que la última versión que contiene correcciones y nuevas
Las pruebas / características necesarias para Checkbox están disponibles y tampoco rompen nada
Checkbox, necesitamos liberarlo junto con Checkbox. Después de cortar el lanzamiento si el
El equipo de pruebas de firmware ha notificado que hay una nueva versión disponible y que esta versión
debe usarse para la certificación, debemos copiarlo en el PPA de prueba. Para hacer esto nosotros
Necesito ir a la Copiar paquetes view of las firmware Probar Suite (Estable) PPA
<https://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable/+copy-packages> y
seleccione los paquetes 'fwts' para todas las versiones de nuevo a Precise. Necesitamos configurar el
'Destino PPA' como 'Prueba de lanzamiento de casilla de verificación [~ checkbox-dev / testing]' y 'Copiar
opciones 'en el campo' Copiar binarios existentes ', luego haga clic en' Copiar paquetes '. Este paso entonces
debe repetirse, pero establezca el campo 'PPA de destino' en 'PPA para desarrolladores de casillas de verificación
[~ checkbox-dev / ppa] '.

Siguiente tortugitas of Caja correo electrónico
Para que todos tengan la oportunidad de realizar las pruebas necesarias en el momento oportuno.
manera, después de que se hayan completado las compilaciones de PPA, se debe enviar un correo electrónico a la siguiente
listas de correo:

· [email protected] <certificación de hardware
[email protected]>

· [email protected] <[email protected]>

El contenido suele ser algo como esto:

Asunto: Próxima publicación de la casilla de verificación (18/11/2013)

Hola,

La próxima versión de Checkbox está disponible en la
https://code.launchpad.net/~checkbox-dev/+archive/testing PPA.
Pruébelo a su conveniencia. La casilla de verificación se basa en la revisión 2484 de
lp: la certificación de casilla de verificación y casilla de verificación se basa en la revisión 586 de
lp: casilla de verificación-certificación.

Gracias,

Si uno u otro de la casilla de verificación y la certificación de casilla de verificación no se han actualizado,
no es necesario mencionar ese paquete

Pruebas las ,
Ahora que se ha eliminado la versión, las pruebas deben realizarse antes de la reunión de publicación.
Desde el punto de vista del equipo de certificación, lo que debe probarse es
checkbox-certificación-cliente y casilla de verificación servidor de certificación que forman la base para
CE QA Versiones específicas de OEM de Checkbox. El servidor de certificación de casilla de verificación se prueba en el
El cliente de certificación de casilla de verificación de bucle de CI debe probarse manualmente.

tortugitas Reunión
El jueves anterior a la liberación, se lleva a cabo una reunión entre un representante de
el equipo de Certificación y un representante del Comercial Ingeniería QA equipo. los
La reunión se lleva a cabo a las 7:30 UTC como se muestra en este calendario invitar
<https://www.google.com/calendar/hosted/canonical.com/event?action=TEMPLATE&tmeid=Y3QxcWVla3ViMTRvMXByOHZlOTFvc283Y2NfMjAxMzA4MjlUMDczMDAwWiBicmVuZGFuLmRvbmVnYW5AY2Fub25pY2FsLmNvbQ&tmsrc=brendan.donegan%40canonical.com>.
La agenda de la reunión se incluye en la invitación.

DTP las ,
Para publicar el lanzamiento, simplemente necesitamos copiar varios paquetes del Caja
tortugitas Pruebas PPA <https://launchpad.net/~checkbox-dev/+archive/testing> al Materiales
de Padi Público PPA <https://launchpad.net/~hardware-certification/+archive/public>.
Para hacer esto vamos a la Copiar paquetes view of las Caja tortugitas Pruebas PPA
<https://launchpad.net/~checkbox-dev/+archive/testing/+copy-packages> y seleccionar todo
versiones de la siguiente lista de paquetes: caja, casilla de verificación-certificación, fwts. Hacer
asegúrese de que el campo 'Destino PPA' esté configurado como 'PPA público para certificación de hardware
[~ certificación de hardware / público] 'y que el campo' Opciones de copia 'está configurado en' Copiar
binarios existentes ', luego haga clic en' Copiar paquetes '.

Una vez hecho esto, se debe enviar un correo electrónico de anuncio a
[email protected] <[email protected]>.
Una plantilla para el anuncio se incluye a continuación:

Hola,

Se ha cargado una nueva versión de la casilla de verificación en el hardware.
Certificación PPA pública
(https://launchpad.net/~hardware-certification/+archive/public). los
la versión se basa en la revisión 2294 de lp: casilla de verificación

Gracias,

Adjunte la parte más reciente del registro de cambios como notas de la versión.

· Genindex

· Modindex

· buscar

Use checkbox-cli en línea usando los servicios de onworks.net