checkbox-cli - Online na nuvem

PROGRAMA:

NOME

checkbox_ng - Documentação CheckboxNG

CheckboxNG é uma ferramenta de teste de hardware útil para certificar laptops, desktops e servidores
com o Ubuntu. É uma nova versão do Checkbox construída diretamente sobre o PlainBox

Caixa de seleçãoNG substitui Caixa de seleção, quando aplicável.

AVISO:
A documentação está em desenvolvimento. Algumas coisas estão erradas, imprecisas ou descritas
objetivos de desenvolvimento em vez do estado atual.

INSTALAÇÃO

CheckboxNG pode ser instalado a partir de um PPA (recomendado) ou pypi no Ubuntu Precise (12.04) ou
mais recente.

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

CORRENDO ESTÁBULO DIVULGAÇÃO ATUALIZAÇÃO TESTES

CheckboxNG tem suporte especial para a execução de testes de atualizações de versão estável em um sistema automatizado
maneiras. Isso executa todos os trabalhos do sru.lista branca e envia os resultados para o
site de certificação.

Para executar testes de SRU, você precisará saber o chamado Secure ID do dispositivo que você está
testando. Depois de saber que tudo o que você precisa fazer é executar:

$ checkbox sru $ secure_id submit.xml

O segundo argumento, submit.xml, é um nome do arquivo substituto que só é criado
quando o envio de dados para o site de certificação deixa de funcionar por qualquer motivo.

RELATÓRIOS INSETOS

Para relatar bugs no projeto Checkbox, você precisará de uma conta na barra de ativação. Você pode encontrar
instruções on como para crio um <https://help.launchpad.net/YourAccount/NewAccount>
útil. Depois de ter uma conta, você pode Denunciar erros <https://bugs.launchpad.net/checkbox-
project / + filebug>.

Nessa página, você pode selecionar o projeto no qual deseja registrar o bug (usamos vários
projetos para coordenar lançamentos e preferimos ter bugs associados a
parte da caixa de seleção). Se você souber o projeto certo a usar, basta usá-lo e arquivar o bug. Se
você não conhece muito o interno da Checkbox ou está em dúvida basta arquivar na base
Projeto 'Checkbox' (você pode usar isto diretamente link
<https://bugs.launchpad.net/checkbox/+filebug>.) Um membro da equipe de desenvolvimento irá
reveja seu bug e reatribua-o ao local apropriado. O número do bug não
mudar quando isso acontecer.

A CAIXA DE VERIFICAÇÃO PILHA

O Checkbox Stack é uma coleção de projetos que, juntos, constituem um teste completo
e solução de certificação. É composto pelas seguintes partes (ver tabela abaixo para
detalhes extras). Todos os projetos estão ligados a partir do Launchpad projeto grupo
<https://launchpad.net/checkbox-project>.

Arquitetura Diagrama
[imagem: Diagrama de arquitetura] [imagem]

Este diagrama contém uma aproximação de alto nível da arquitetura atual do Checkbox.
Existem três "pilares" principais. Na esquerda temos final Produtos. Essas são ferramentas reais
que a certificação e os engenheiros estão usando. À direita temos o teste mercado. Isto é
um mercado aberto de vendedores e fornecedores de testes. Os testes são embalados em recipientes conhecidos como
provedores. No centro, temos três componentes compartilhados. Esses implementam a maior parte do
framework e interfaces de usuário para execução de teste. Finalmente no canto esquerdo inferior
é uma parte da caixa de seleção (uma biblioteca) que é compartilhada com HEXR para certas tarefas. HEXR é um
aplicativo da web fora do escopo usado por parte do processo de certificação. Setas implicam
a comunicação com a forma da seta mostra quem liga para quem.

Como mencionado antes, na coluna central existem três componentes principais de código compartilhado
(compartilhado por todos que usam os produtos finais discutidos abaixo). O código compartilhado é
composto de plainbox, checkbox-ng e checkbox-gui. As responsabilidades dos componentes são
discutido em mais detalhes na tabela abaixo. Aqui podemos ver que checkbox-gui usou DBus
API exposta por checkbox-ng, que por sua vez usa checkbox-support (uma biblioteca auxiliar
separados para compartilhar algum código com HEXR) e plainbox.

Na coluna do lado direito, existem vários fornecedores de teste. O projeto da caixa de seleção é
produzindo e mantendo uma série de fornecedores (veja a tabela abaixo), mas é esperado
que nossos usuários downstream também produzirão seus próprios fornecedores (específicos para um cliente ou
projeto). Eventualmente, alguns provedores podem vir de terceiros que adotarão o
formato.

Por último, no canto inferior esquerdo, a biblioteca compartilhada, esta biblioteca contém muitos analisadores
de vários formatos de arquivo e formatos de saída. Tecnicamente, esta biblioteca é uma dependência de
HEXR, caixa de seleção-ng e de provedores. Como uma complexidade adicional, a biblioteca precisa ser chamada
do código python3 e código python2.

NOTA:
A comunicação entre checkbox-ng e plainbox é bidirecional. Ofertas Plainbox
algumas interfaces básicas e pontos de extensão. Todos esses são expostos por meio do plainbox
(usando APIs comuns), mas algumas delas são realmente implementadas em checkbox-ng.

AVISO:
Todas as APIs internas são semi-instáveis. A API DBus é mais estável na prática, mas deve
não ser invocado. Os projetos são incentivados a serem mesclados em lp: caixa de seleção em que API
as transições podem ser tratadas com elegância. A única API estável é o formato de arquivo
especificação (definições de trabalho e whitelits). A especificação do lançador será
estabilizado na próxima versão.

Componente Descrição
┌────────────────────────────┬────────────────────────────────────────────────────────────────────────────────── ────────────────────┬────────────────────────────────────────────────────────┐
│ Projeto │ Responsável por │ Tipo │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│ Caixa de seleção da próxima geração │ │ Aplicativo │
│ (GUI) │ · O C ++ / QML │ │
│ │ interface do usuário │ │
│ │ │ │
│ │ · O gráfico │ │
│ │ launcher para │ │
│ │ provedores, por exemplo, │ │
│ │ caixa de seleção-certificação-cliente │ │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│ Caixa de seleção da próxima geração │ │ Aplicativo │
│ (CLI) │ · A linha de comando python │ │
│ │ interface │ │
│ │ │ │
│ │ · a interface de usuário de texto │ │
│ │ │ │
│ │ · o comando de teste SRU │ │
│ │ │ │
│ │ · APIs de certificação adicionais │ │
│ │ │ │
│ │ · enviando dados para o Launchpad │ │
│ │ │ │
│ │ · enviando dados para HEXR │ │
│ │ │ │
│ │ · o serviço DBus necessário para │ │
│ │ GUI │ │
└────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────── ────────────────────┴────────────────────────────────────────────────────────┘

│ Certificação de Cliente │ │ Provedor │
│Provedor │ · cliente de certificação canônica │ │
│ │ executável │ │
│ │ │ │
│ │ · certificação do cliente │ │
│ │ listas de permissões │ │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│ Certificação de servidor │ │ Provedor │
│Provider │ · certificação do servidor │ │
│ │ listas de permissões │ │
│ │ │ │
│ │ · listas de permissões de servidores adicionais │ │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│Servidor System-on-Chip │ │ Provedor │
│ Provedor de certificação │ · Certificação de servidor SoC │ │
│ │ listas de permissões │ │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│ Provedor de caixa de seleção │ │ Provedor │
│ │ · Quase todas as definições de trabalho │ │
│ │ │ │
│ │ · A maioria dos "scripts" personalizados │ │
│ │ │ │
│ │ · Lista de permissões padrão e SRU │ │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│ Provedor de recursos │ │ Provedor │
│ │ · Quase todos os empregos de recursos │ │
│ │ │ │
│ │ · Quase todos os "scripts" de recursos │ │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│Suporte de caixa de seleção │ │ Biblioteca │
│ │ · Código de suporte para vários │ │
│ │ provedores │ │
│ │ │ │
│ │ · Analisadores para muitos formatos de texto │ │
├────────────────────────────┼────────────────────────────────────────────────────────────────────────────────── ────────────────────┼────────────────────────────────────────────────────────┤
│PlainBox │ │ Biblioteca e Desenvolvimento │
│ │ · Quase todas as lógicas básicas │ Kit de ferramentas │
│ │ │ │
│ │ · RFC822 (definição de trabalho) │ │
│ │ analisador │ │
│ │ │ │
│ │ · Tratamento da configuração │ │
│ │ │ │
│ │ · Sessão de teste │ │
│ │ (suspender / retomar) │ │
│ │ │ │
│ │ · Corredor de trabalho │ │
│ │ │ │
│ │ · Iniciador confiável │ │
│ │ │ │
│ │ · Resolvedor de dependência │ │
│ │ │ │
│ │ · Manipulação de linha de comando │ │
│ │ │ │
│ │ · O XML, HTML e XSLX │ │
│ │ exportadores │ │
│ │ │ │
│ │ · e mais ... │ │
│ │ │ │
│ │ · Kit de ferramentas de desenvolvimento de provedor │ │
│ │ │ │
│ │ · 'plainbox startprovider' │ │
│ │ │ │
│ │ · implementação de 'manage.py' │ │
└────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────── ────────────────────┴────────────────────────────────────────────────────────┘

│Legacy Checkbox (sem │ │ Monolithic Application │
│ mantido por mais tempo) │ · Aplicativos │ Biblioteca e dados │
│ │ │ │
│ │ · GUI Qt4 │ │
│ │ │ │
│ │ · GUI Gtk2 │ │
│ │ │ │
│ │ · Urwid (texto) GUI │ │
│ │ │ │
│ │ · Núcleo │ │
│ │ │ │
│ │ · Plugin e Evento / Mensagem │ │
│ │ Motor │ │
│ │ │ │
│ │ · Quase todos os recursos │ │
│ │ implementou um plugin principal │ │
│ │ │ │
│ │ · Dados │ │
│ │ │ │
│ │ · Empregos e listas de permissões │ │
└────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────── ────────────────────┴────────────────────────────────────────────────────────┘

CHANGELOG

NOTA:
Este changelog contém apenas um resumo das mudanças. Para uma contabilidade mais precisa de
histórico de desenvolvimento, inspecione o histórico de origem diretamente.

Caixa de seleçãoNG 0.23 (não lançado)
· Correções de bugs: https://launchpad.net/checkbox-ng/+milestone/0.23

Caixa de seleçãoNG 0.22
· Correções de bugs: https://launchpad.net/checkbox-ng/+milestone/0.22

Caixa de seleçãoNG 0.3
· Correções de bugs: https://launchpad.net/checkbox-ng/+milestone/0.3

Caixa de seleçãoNG 0.2
· Correções de bugs: https://launchpad.net/checkbox-ng/+milestone/0.2

Caixa de seleçãoNG 0.1
· Lançamento inicial

· Suporte para configuração de exibição

· Suporte para execução de testes SRU (teste de regressão automática)

TESTE CRITÉRIOS

Os 'scripts' de teste são pequenos programas usados ​​para auxiliar na implementação de testes.

brilho_teste
Este script testa o brilho da luz de fundo do sistema pode ser alterado usando o
interfaces do kernel em / sys / class / backlight. Pode haver mais de uma interface para escolher
de, de modo que a interface correta a ser usada é selecionada usando a heurística prescrita em
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight. A claridade
é manipulado atualizando o arquivo de brilho da interface e o real_brightness
arquivo é verificado para ver se o valor foi modificado para o brilho selecionado.

PERFIS CONFIGURAÇÃO

Perfis de execução, ou iniciadores, permitem especificar um conjunto predefinido de configuração
opções que permitem a personalização da tela de boas-vindas, listas de permissões exibidas, bem como
salvando os resultados localmente ou enviando o arquivo de envio para o Launchpad ou para a Certificação
banco de dados / HEXR, bem como alguns outros parâmetros.

As configurações de perfil são parte de um script de iniciador e usam checkbox-gui ou
checkbox-launcher (em modo de texto / CLI) como um shebang para interpretar a chave / valores.

Este documento fornece uma referência sobre a funcionalidade e sintaxe do iniciador. Para entender o
design e conceitos e ver vários exemplos, você pode querer ler o tutorial sobre a forma de
criar lançadores e sua relação com o legado Checkbox.

Sintaxe
Como checkbox-gui é um aplicativo Qt, as configurações devem seguir as regras de estilo INI do
QConfigurações <http://qt-project.org/doc/qt-5/QSettings.html> classe.

Valores de várias linhas são suportados, mas devem ser colocados entre aspas duplas e linhas extras
deve começar com um espaço, por exemplo:

[categoria]
key = "Olá
Mundo"

· De QML:

settings.value ("categoria / chave", i18n.tr ("default_value"))

· De C ++:

configurações-> valor ("categoria / chave", app.tr ("valor_padrão"))

Por outro lado, os iniciadores específicos do inicializador de caixa de seleção devem seguir Python ConfigParser
<https://docs.python.org/3/library/configparser.html#supported-ini-file-structure> sintaxe.

Além disso, algumas configurações só fazem sentido para GUI ou CLI e, portanto, não são compreendidas por
o outro. Estes são indicados a seguir.

Suportado Configurações
bem-vindo / título
Título do aplicativo QML e cabeçalho da tela de boas-vindas. Padrões para System ensaio.

bem-vindo / texto
Mensagem de boas-vindas a ser exibida na primeira tela (checkbox-gui suporta Rich text
permitindo a marcação de estilo HTML). Padrões para Receber para System Testando. [...]

suite / whitelist_filter
Expressão regular para corresponder a um subconjunto de nomes de arquivos da lista de permissões. No checkbox-gui-lo
o padrão é .*. Para checkbox-launcher não tem padrão e devo ser definida.

suite / whitelist_selection
O padrão que as listas de permissão precisam corresponder para ser pré-selecionado. Expressão regular Python.
Não tem padrão e devo ser definida. (Apenas CLI)

suite / skip_whitelist_selection
Se definido como verdadeiro, o usuário não receberá a opção de lista de permissões. Apenas o pré-selecionado
uns (veja whitelist_selection) serão selecionados. (CLI apenas).

suite / skip_test_selection
Se definido como verdadeiro, o usuário não terá permissão para desmarcar os testes antes de executar: todos os testes
na lista de permissões selecionada será executado. (Apenas CLI)

submissão / mensagem
Texto do cabeçalho do pop-up de envio, mostrado ao usuário após o envio
concluído. (Apenas GUI)

submissão / tipo_de_entrada
Mostre um campo de entrada de texto para inserir a ID segura ou o endereço LP (padrão). Para
apenas salve os resultados no disco, deve usar o Nenhum valor. Para validar usando um regex,
devemos ser regex. (Apenas GUI)

submissão / regex
Expressão regular para validar a entrada no campo de envio (por exemplo, email, secure_id)
se input_type for regex. (Apenas GUI). RegExpValidator, padrão .*

submissão / input_placeholder
Texto temporário para inserir no campo de entrada, utilizado para orientar o usuário. Launchpad E-Mail
Endereço (padrão) ou Confie ID (15 or 18 personagens). (Apenas GUI)

submissão / secure_id
Secure_id pré-configurado para preencher o campo de texto.

submissão / ok_btn_text
O rótulo do botão "Enviar". Submeter Resultados (padrão) ou Salvar Resultados . (GUI
apenas)

submissão / cancel_warning
Mostra ao usuário se ele deseja sair sem ter salvo o relatório. Você está prestes
para sair deste teste sem salvar seu relatório de resultados. Você quer salvar o
relatório? (Apenas GUI)

submissão / enviar_para_hexr
Booleano, adicione um cabeçalho extra para também enviar os resultados para HEXR (funciona com o
transporte de certificação)

exportador / xml_export_path
Local para salvar o arquivo de envio XML, se definido como uma string vazia abrirá um
caixa de diálogo para salvar o arquivo. Predefinição: /tmp/submission.xml (Apenas GUI)

transport / submit_to
Ponto final de transporte. Padrões para . Suporta envio para LP (o padrão,
valor plataforma de lançamento), certificaçãoou local (salvar no disco)

transport / submit_url
URL para enviar os resultados. Isso permite fazer upload para diferentes sites, por exemplo
ele pode ser carregado diretamente para o hexr ou para os sites de teste. Usado apenas com o
certificação valor submit_to.

transport / config_filename
Nome de um arquivo de configuração personalizado a ser carregado. Arquivos de configuração são usados ​​principalmente para definir
variáveis ​​ambientais. (Apenas CLI)

transport / dont_suppress_output
Se definido, recursos, trabalhos locais e anexos serão enviados para a tela, este
gera muito texto e é principalmente para depuração. (Apenas CLI)

CHECKBOX / PLAINBOX LANÇADORES TUTORIAL

Este documento fornece uma explicação de por que os iniciadores são necessários, o que você pode conseguir
com eles e aborda vários exemplos para descrever melhor suas capacidades. Para
referência detalhada sobre quais configurações são suportadas por iniciadores e sintaxe específica para
arquivos de inicialização, olhe para / profiles.

Legado checkbox comportamento ao controle
No passado, o comportamento da Checkbox era controlado por três mecanismos.

Primeiro, as funções da caixa de seleção podem ser aumentadas com a adição de plug-ins. Por exemplo, o
capacidade de enviar ao site de certificação foi adicionada pelo pacote de certificação de caixa de seleção
usando um plugin. Os plug-ins incluídos pela caixa de seleção de certificação e que adicionam um novo comportamento
para a caixa de seleção de base foram:

/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

Eles adicionaram a forma de solicitar ao usuário dados específicos de envio, gerar o xml
relatório e outras funções.

Em seguida, os comportamentos dos plug-ins podem ser configurados ou controlados usando a configuração
arquivos, que são "em cascata". Um arquivo de configuração pode incluir outros e estes, por sua vez,
incluir outros.

Este é um exemplo de arquivo de configuração principal project-qt.ini específico do projeto. É o primeiro
arquivo lido quando o cliente específico do projeto é iniciado. Algumas configurações são abreviadas:

[PADRÃO]
inclui =% (checkbox_oem_share) s / configs / checkbox-project-base-qt.ini% (checkbox_project_share) s / configs / checkbox-project-base.ini

[checkbox / plugins / environment_info]
repositórios = deb http: //.* \ (arquivo \ | segurança \). ubuntu.com/ubuntu segurança precisa
roteadores = múltiplos
servidor_iperf = 10.20.30.40
lista_fontes = /etc/apt/sources.list
wpa_n_psk = senha
wpa_n_ssid = ponto de acesso

[checkbox / plugins / user_interface]
title = Meu projeto Teste de sistema

Observe a linha de inclusão, que o instrui a carregar o arquivo de configuração para
checkbox-project-base-qt e checkbox-project-base. Checkbox-project-base-qt carrega o
configs para certificação de caixa de seleção e projeto de caixa de seleção. As configurações são colocadas em cascata para que o
as opções de configuração perto da parte superior substituem as próximas à parte inferior.

Finalmente, o "binário" usado para invocar a caixa de seleção é um script de shell que define onde encontrar
a caixa de seleção de coisas precisa ser executada: você pode definir um diretório de compartilhamento, um dado específico
diretório, aponte para um arquivo de configuração e defina algumas variáveis ​​de ambiente que você
pode precisar durante o teste. Aqui está um exemplo para checkbox-project-qt:

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

# Conveniência para definir o diretório PYTHONPATH.
if ["$ CHECKBOX_SHARE"! = "/ usr / share / checkbox"]; então
export PYTHONPATH = "$ CHECKBOX_SHARE: $ PYTHONPATH"
fi

python3 $ CHECKBOX_SHARE / run "$ @" $ CHECKBOX_PROJECT_SHARE / configs / $ (basename $ 0) .ini

Aqui você pode ver que ele define alguns locais e uma parte importante é o python3 final
, onde localizará e usará o arquivo de configuração .ini necessário que vimos anteriormente.

Esta organização hierárquica era muito poderosa, mas também difícil de administrar, e
também tinha algumas limitações. Parte do trabalho que fizemos com a checkbox foi integrar todos os
plug-ins específicos do projeto no tronco da caixa de seleção, desta forma, todo o código principal está em um só lugar,
e as variantes específicas do projeto fornecem apenas empregos, listas de permissões, dados e configuração,
sem adicionar um novo comportamento.

Novo caixa simples comportamento ao controle
Ao contrário do checkbox, o núcleo do plainbox é monolítico e não tem conceito de plug-ins. Esse
torna mais fácil de entender e trabalhar. O núcleo do plainbox tem implementações para todos
as funções nos pacotes de caixa de seleção antigos, portanto, nenhuma adição é necessária para usar os recursos
como submissão à certificação ou geração de relatório.

O que chamamos de plainbox é a biblioteca que implementa todas as funcionalidades, como pode ser visto
SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

Plainbox fornece ferramentas para ajudar os desenvolvedores de teste a escrever e empacotar testes. Estes são
entregues em "provedores", que são entidades projetadas para encapsular as descrições de teste,
scripts personalizados para testes, listas de permissões e dados diversos. Eles foram projetados para permitir
equipes para escrever e entregar seus testes personalizados sem se preocupar muito com o
código plainbox subjacente.

Para obter informações sobre como escrever testes e provedores, consulte o Tutorial do Provedor

No entanto, quando realmente usamos esses testes para verificar um sistema real, queríamos fornecer
algo mais fácil e mais próximo da experiência do usuário do checkbox. Criamos dois clientes,
checkbox-gui e checkbox-cli, que tinham alguns comportamentos codificados, e também começamos
criar outros clientes baseados neles, mas com objetivos específicos. Por exemplo,
tínhamos uma versão da caixa de seleção para teste de SRU, outra para certificação de servidor e assim por diante.

Mas então percebemos que muito do código estava duplicado e os comportamentos eram comuns
exceto por algumas mudanças. Então, criamos o conceito de "lançadores", que são
um pouco semelhante aos arquivos de configuração da caixa de seleção e lançadores de script de shell.

A ideia é que checkbox-gui e checkbox-cli tenham alguns comportamentos muito básicos, uma vez que
são os clientes que são enviados por padrão com o Ubuntu. Eles podem mostrar todos os disponíveis
listas de permissões, mostram uma mensagem de boas-vindas predefinida e, no final, permitem que o usuário veja o
relatório html e envie-o para o launchpad usando seu endereço de e-mail, semelhante à versão
da caixa de seleção que acompanha o Ubuntu.

Em vez de usar opções de linha de comando complicadas, os iniciadores permitem que você configure alguns
comportamentos opcionais para personalizar sua experiência de teste. Um iniciador contém configurações e
é semelhante a um script de shell, mas o interpretador será checkbox-gui ou
lançador de caixa de seleção.

Aqui estão alguns exemplos do que pode ser feito com lançadores.

Como uma surpresa, o checkbox-cli é um iniciador:

#!/ usr / bin / env lançador de caixa de seleção
[receber]
text = Bem-vindo ao teste do sistema!
A caixa de seleção fornece testes para confirmar se o sistema está funcionando corretamente.
Assim que terminar de executar os testes, você pode ver um relatório resumido para
Seu sistema.
Aviso: Alguns testes podem fazer com que seu sistema congele ou se torne
sem resposta. Salve todo o seu trabalho e feche todos os outros em execução
aplicativos antes de iniciar o processo de teste.

[depois de]
whitelist_filter = ^ default $
whitelist_selection = ^ default $
skip_whitelist_selection = Verdadeiro

[transporte]
submit_to = barra de lançamento

Você pode ver aqui que personalizamos algumas opções: mostra uma mensagem de boas-vindas, automaticamente
seleciona a lista de permissões padrão e enviará para a barra de ativação quando terminar.

Um exemplo de iniciador gráfico é cliente de certificação canônica.

#! / usr / bin / checkbox-gui

[receber]
title = "Certificação do Sistema"
text = " Bem-vindo à Certificação do Sistema! Este aplicativo irá
reúna informações de seu sistema. Em seguida, serão solicitados testes manuais para
confirme se o sistema está funcionando corretamente. Finalmente, você será solicitado por
o ID seguro do computador para enviar as informações para a certificação
base de dados. Para saber como criar ou localizar o Secure ID,
por favor, veja aqui: Certification.canonical.com "

[depois de]
whitelist_filter = "^ client- (cert | selftest). *"

[submissão]
input_type = "regex"
input_placeholder = "Secure ID (15 ou 18 caracteres)"
ok_btn_text = "Enviar resultados"
submit_to_hexr = "true"

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

[transporte]
submit_to = "certificação"

Os lançadores gráficos são um pouco mais complicados, mas essencialmente são semelhantes, o que
permite que você defina alguns parâmetros para personalizar sua experiência de teste.

Um iniciador de modo de texto muito simples é canonical-hw-collection que apenas executa o básico
as informações de hardware testam e os carregam para um banco de dados de hardware:

[receber]
title = Coletando informações de hardware
text = Coletando informações de hardware. Sua senha pode ser solicitada.
Este processo levará aproximadamente 30 segundos e você receberá
com um URL através do qual você pode confirmar e registrar seu hardware
submissão.

[depois de]
whitelist_filter = ^ hwsubmit $
whitelist_selection = ^ hwsubmit $
skip_whitelist_selection = Verdadeiro
skip_test_selection = Verdadeiro

[submissão]
# Um falso secure_id garante que não o perguntaremos
# Ele sempre pode ser sobrescrito no arquivo .conf.
ID_seguro = 000

[transporte]
submit_to = certificação
enviar_url = https://hardware-server.example.com/

Por fim, o canonical-driver-test-suite fornece um iniciador gráfico e de texto,
que são funcionalmente equivalentes:

#! / usr / bin / checkbox-gui

[receber]
title = "Canonical Driver Test Suite"
text = " Bem-vindo ao Canonical Driver Test Suite.

Este programa contém testes automatizados e manuais para ajudá-lo a descobrir
problemas que irão surgir ao executar seus drivers de dispositivo no Ubuntu.

Este aplicativo guiará o usuário por esses testes em um
pedido predeterminado e coletar automaticamente as informações do sistema como
bem como os resultados dos testes. Ele também solicitará ao usuário uma entrada quando for manual
o teste é necessário.

O tempo de execução dos testes é determinado por quais testes você decide
executar. O usuário terá a oportunidade de personalizar a execução do teste para
acomodar o driver e a quantidade de tempo disponível para teste.

Para começar, basta clicar no botão Continuar abaixo e seguir as instruções na tela
instruções. "

[depois de]
whitelist_filter = "^ ihv -. *"

[submissão]
ok_btn_text = "Salvar resultados"
input_type = "nenhum"

[exportador]
xml_export_path = ""

[transporte]
submit_to = "local"

Modo de texto:

#!/ usr / bin / env lançador de caixa de seleção
[receber]
text = Bem-vindo ao Canonical Driver Test Suite
Este programa contém testes automatizados e manuais para ajudá-lo a descobrir
problemas que irão surgir ao executar seus drivers de dispositivo no Ubuntu.
Este aplicativo guiará o usuário por esses testes em um
pedido predeterminado e coletar automaticamente as informações do sistema como
bem como os resultados dos testes. Ele também solicitará ao usuário uma entrada quando for manual
o teste é necessário.
O tempo de execução dos testes é determinado por quais testes você decide
executar. O usuário terá a oportunidade de personalizar a execução do teste para
acomodar o driver e a quantidade de tempo disponível para o teste.
Para começar, basta clicar no botão Continuar abaixo e seguir as instruções na tela
instruções.

[depois de]
# Whitelist (s) exibida (s) na tela de seleção da suíte
whitelist_filter = ^ ihv -. *
# Whitelist_selection é obrigatório, portanto, definimos com um valor falso para
# nenhuma lista de permissões foi pré-selecionada.
whitelist_selection = falso

CAIXA DE VERIFICAÇÃO DIVULGAÇÃO PROCEDIMENTO:

Esta página descreve as etapas necessárias para o lançamento de versões de Checkbox e Checkbox
Certificação para o PPA estável pertencente à equipe de Certificação de Hardware, em um regular
base. Ao longo deste documento, o termo 'Caixa de seleção' é usado como um termo abrangente para abranger
todas as versões do Checkbox pertencentes à equipe de Certificação de Hardware, atualmente Checkbox
próprio e as extensões de certificação da caixa de seleção.

Visão geral
Atualmente, o processo é executado em uma cadência quinzenal, com uma nova versão do Checkbox a cada
duas semanas. Isso cobre dez dias úteis, e as tarefas realizadas em cada dia ou grupo de
dias é descrito abaixo:

· Dias 1-4: Tempo permitido para que novas alterações sejam introduzidas no tronco.

· Dia 5: As mudanças são mescladas do tronco de lp: caixa de seleção e lp: checkbox-Certification para
seus respectivos ramos de lançamento. Os changelogs para ambos são colidido neste ponto e
revisões são marcadas. Nesta fase, também pode ser necessário copiar o pacote 'fwts'
do FWTS Estável PPA <https://launchpad.net/~firmware-testing-team/+archive/ppa-
fwts-estável> para o Caixa de seleção Solte ensaio PPA <https://launchpad.net/~checkbox-
dev / + arquivo / teste>.

· Dias 6 a 9: O teste é realizado pelo gerente de lançamento para a Certificação de Hardware
equipe, e um representante da equipe de QA CE (o principal cliente da Checkbox em
Canônico)

· Dia 9: Uma reunião de lançamento é realizada entre o gerente de lançamento do Hardware
Equipe de certificação e o representante da equipe de QA da CE. Possíveis problemas com o
liberação são identificados e planos feitos para resolvê-los.

· Dia 10: A versão testada do Checkbox é copiada para o PPA estável.

Launchpad ramos
O processo de liberação requer ramos separados no Launchpad contendo um semi-congelado
versão do código que estava no tronco no dia 5 do processo. Isso é para que o desenvolvimento
pode continuar no tronco sem comprometer a estabilidade da versão a ser lançada
Caixa de seleção. A relação entre todas as filiais envolvidas no processo é mostrada a seguir:

· lp: caixa de seleção / liberação <- lp: caixa de seleção

· lp: checkbox-certificate / release <- lp: checkbox-Certification

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

Auditoria marco erros
Antes de criar o candidato a lançamento, o gerente de lançamento deve revisar a lista de bugs
milestoned para o próximo lançamento do Checkbox. Eles deveriam visitar checkbox marcos
<https://launchpad.net/checkbox/+milestonesmilestones> e localize o marco datado com
a data de lançamento.

· Para bugs definidos como Em andamento com uma ramificação associada - liase com a ramificação
proprietário para ver se a fusão pode ser concluída antes do prazo.

· Para bugs que estão em qualquer outro status não fechado (exceto Fixar Comprometido) - re-marco
para o seguinte marco.

Corte que o liberar
A fim de cortar a liberação, temos que mesclar as alterações do tronco na liberação
branch, envie-os com uma mensagem adequada e atualize o changelog no tronco para que
as alterações futuras vão para a versão correta. Para cada combinação de ramos mostrada acima,
faça o seguinte (o exemplo usa lp: caixa de seleção e lp: caixa de seleção / liberação):

bzr branch lp: checkbox / release checkbox-release
bzr branch lp: checkbox checkbox-trunk
lançamento de caixa de seleção de cd
current_stable = `head -n1 $ (find. -name 'changelog') | grep -oP '(? <= \ (). * (? = \))' `
bzr merge lp: caixa de seleção

neste ponto, se nenhuma mudança (diferente de um para debian / changelog) se fundir, então nós fazemos
não realizar um lançamento do pacote em questão. Na prática, isso geralmente acontece com
certificação de caixa de seleção mas nunca com checkbox:

bzr commit -m "Fusão nas alterações de rev $ (bzr revno -r tag: $ current_stable lp: checkbox) para rev $ (bzr revno lp: checkbox) de lp: checkbox"
bzr push lp: caixa de seleção / liberação
cd `find. -name 'debian'`; CD ..
tag bzr `head -n1 debian / changelog | grep -oP '(? <= \ (). * (? = \))' `
dch -r (salvar o changelog modificado)
dch -i -U 'changelog incrementado'
debcommit
bzr push lp: caixa de seleção

A última etapa do processo é realizar uma compilação dos pacotes no
ppa: checkbox-dev / testing PPA. Para fazer isso, precisamos ir para as páginas de receita para o
checkbox e / ou certificação de caixa de seleção liberar ramos.

· teste de caixa de seleção receita <https://code.launchpad.net/~checkbox-dev/+recipe/checkbox-
ensaio>

· teste de certificação de caixa de seleção receita <https://code.launchpad.net/~checkbox-
dev / + receita / caixa de seleção-teste de certificação>

A Construa Atual opção deve estar disponível na página. Clique nele para iniciar uma construção.

Copiar firmware Test suíte para que o ensaio PPA
A ferramenta Firmware Test Suite é uma ferramenta de teste para firmware de sistema que é naturalmente pesada
utilizado pela Checkbox. Para certificar-se de que a versão mais recente que contém correções e novos
testes / recursos necessários para Checkbox estão disponíveis e também não quebram nada em
Caixa de seleção, precisamos liberá-la junto com a caixa de seleção. Depois de cortar o lançamento, se o
A equipe de teste de firmware notificou que uma nova versão está disponível e que esta versão
deve ser usado para certificação, precisamos copiá-lo para o PPA de teste. Para fazer isso nós
precisa ir para o Copiar pacotes view of que o firmware Test suíte (Estável) PPA
<https://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable/+copy-packages> e
selecione os pacotes 'fwts' para todas as versões de volta ao Precise. Precisamos definir o
'Destination PPA' como 'Checkbox Release Testing [~ checkbox-dev / testing]' e 'Copiar
opções 'para' Copiar binários existentes 'e clique em' Copiar pacotes '. Esta etapa então
precisa ser repetido, mas defina o campo 'PPA de destino' como 'PPA para desenvolvedores de caixa de seleção
[~ checkbox-dev / ppa] '.

Próximo Solte of Caixa de seleção o email
Para que todos tenham a oportunidade de realizar qualquer teste necessário em tempo hábil
forma, após as compilações do PPA terem sido concluídas, um e-mail deve ser enviado para o seguinte
listas de mala direta:

· [email protegido] <certificação de hardware-
[email protegido]>

· [email protegido] <[email protegido]>

O conteúdo é normalmente algo assim:

Assunto: Próximo lançamento da caixa de seleção (18/11/2013)

Oi,

A próxima versão do Checkbox está disponível no
https://code.launchpad.net/~checkbox-dev/+archive/testing PPA.
Teste-o conforme sua conveniência. A caixa de seleção é baseada na revisão 2484 de
lp: checkbox e Checkbox Certification é baseado na revisão 586 de
lp: certificação de caixa de seleção.

Obrigado,

Se um ou outro dos Checkbox e Checkbox Certification não tiver sido atualizado, então
não há necessidade de mencionar esse pacote

ensaio que o liberar
Agora que a versão foi cortada, o teste deve ocorrer antes da reunião de versão.
Do ponto de vista da equipe de certificação, o que precisa ser testado é
caixa de seleção-certificação-cliente e caixa de seleção-certificação-servidor que formam a base para
CE QAs versões específicas do OEM do Checkbox. O servidor de certificação de caixa de seleção é testado no
O cliente de certificação de caixa de seleção de loop de CI precisa ser testado manualmente.

Solte Reunião
Na quinta-feira anterior à liberação, é realizada reunião entre um representante do
a equipe de certificação e um representante do Comercial Engenharia QA equipe. o
reunião é realizada às 7:30 UTC, conforme mostrado neste calendário convidar
<https://www.google.com/calendar/hosted/canonical.com/event?action=TEMPLATE&tmeid=Y3QxcWVla3ViMTRvMXByOHZlOTFvc283Y2NfMjAxMzA4MjlUMDczMDAwWiBicmVuZGFuLmRvbmVnYW5AY2Fub25pY2FsLmNvbQ&tmsrc=brendan.donegan%40canonical.com>.
Uma agenda para a reunião está incluída no convite.

Publishing que o liberar
Para publicar o lançamento, simplesmente precisamos copiar alguns pacotes do Caixa de seleção
Solte ensaio PPA <https://launchpad.net/~checkbox-dev/+archive/testing> para o Hardware
FDA Público PPA <https://launchpad.net/~hardware-certification/+archive/public>.
Para fazer isso, vamos ao Copiar pacotes view of que o Caixa de seleção Solte ensaio PPA
<https://launchpad.net/~checkbox-dev/+archive/testing/+copy-packages> e selecione tudo
versões da seguinte lista de pacotes: caixa de seleção, certificação de caixa de seleção, fwts. Faço
certifique-se de que o campo 'PPA de destino' esteja definido como 'PPA público para certificação de hardware
[~ hardware-verification / public] 'e que o campo' Copiar opções 'está definido como' Copiar
binários existentes 'e clique em' Copiar pacotes '.

Depois disso, um e-mail de anúncio deve ser enviado para
[email protegido] <[email protegido]>.
Um modelo para o anúncio está incluído abaixo:

Oi,

Uma nova versão da caixa de seleção foi carregada para o Hardware
PPA Público de Certificação
(https://launchpad.net/~hardware-certification/+archive/public). o
versão é baseada na revisão 2294 de lp: checkbox

Obrigado,

Anexe a parte mais recente do changelog como notas de lançamento

· Genindex

· Modindex

· procurar

Use checkbox-cli online usando serviços onworks.net