checkbox-cli - クラウドでオンライン

プログラム：

NAME

checkbox_ng - CheckboxNG ドキュメント

CheckboxNG は、ラップトップ、デスクトップ、サーバーの認証に役立つハードウェア テスト ツールです
Ubuntuで。 これは、PlainBox の上に直接構築された Checkbox の新しいバージョンです

チェックボックスNG 置き換え チェックボックス（該当する場合）。

警告：
ドキュメントは開発中です。 間違っている、不正確、または説明が間違っているものもあります
現状ではなく開発目標。

インストール

CheckboxNG は、Ubuntu Precise (12.04) 上の PPA (推奨) または pypi からインストールできます。
新しい。

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

ランニング 安定 RELEASE UPDATE TESTS

CheckboxNG は、自動化された安定版リリース更新テストを実行するための特別なサポートを備えています。
やり方。 これにより、すべてのジョブが実行されます。 sru.ホワイトリスト そして結果を
認証ウェブサイト。

SRU テストを実行するには、使用しているデバイスのいわゆるセキュア ID を知る必要があります。
テスト中。 わかったら、あとは実行するだけです。

$ チェックボックス sru $secure_id submit.xml

XNUMX 番目の引数 submit.xml は、作成されるだけのフォールバック ファイルの名前です。
何らかの理由で認証 Web サイトにデータを送信できなかった場合。

報告 バグ

Checkbox プロジェクトのバグを報告するには、Launchpad アカウントが必要です。 見つかるかもしれません
説明書 on の 〜へ 作ります XNUMXつ <https://help.launchpad.net/YourAccount/NewAccount>
使える。 アカウントを取得すると、次のことが可能になります レポート バグ <https://bugs.launchpad.net/checkbox-
プロジェクト/+ファイルバグ>.

そのページでは、バグを報告したいプロジェクトを選択できます (いくつかのプロジェクトを使用します)
プロジェクトはリリースを調整するため、バグを適切なプロジェクトに関連付けることを好みます。
チェックボックスの一部）。 使用する適切なプロジェクトがわかっている場合は、それを使用してバグを報告してください。 もしも
Checkbox の内部構造をあまり知らない、または疑問がある場合は、ベースにファイルしてください
「チェックボックス」プロジェクト (使用できます) この 直接
<https://bugs.launchpad.net/checkbox/+filebug>.) 開発チームのメンバーは、
バグを確認し、適切な場所に再割り当てします。 バグ番号は表示されません
それが起こったら変わります。

ザ チェックボックス スタック

チェックボックス スタックは、完全なテストを構成するプロジェクトのコレクションです。
そして認証ソリューション。 これは次の部分で構成されています (詳細については、以下の表を参照してください)。
追加の詳細）。 すべてのプロジェクトは、 ランチパッド プロジェクト グループヘッド
<https://launchpad.net/checkbox-project>.

アーキテクチャ ダイアグラム
[画像: アーキテクチャ図] [画像]

この図には、現在のチェックボックス アーキテクチャの概要が含まれています。
主要な「柱」は XNUMX つあります。 左側には、 end 商品。 それらは実際のツールです
認定資格とエンジニアが使用しているもの。 右側には、 test 市場。 これは
テストベンダーとサプライヤーの開かれた市場。 テストは、次のように呼ばれるコンテナーにラップされます。
プロバイダー。 中央には XNUMX つの共有コンポーネントがあります。 これらは大部分を実装します。
テスト実行用のフレームワークとユーザー インターフェイス。 最後に左下隅にあります
特定のタスクのために HEXR と共有されるチェックボックス (ライブラリ) の一部です。 HEXRは、
認定プロセスの一部で使用される範囲外の Web アプリケーション。 矢印は暗示します
矢印の形でのコミュニケーションは、誰が誰に電話をかけているかを示します。

前に述べたように、中央の列には共有コードの XNUMX つの主要なコンポーネントがあります。
(以下で説明する最終製品を使用する全員によって共有されます)。 共有コードは
plainbox、checkbox-ng、checkbox-gui で構成されます。 コンポーネントの責任は次のとおりです。
以下の表で詳しく説明します。 ここで、checkbox-gui が DBus を使用していることがわかります。
checkbox-ng によって公開される API は、checkbox-support (ヘルパー ライブラリ) を使用します。
分離されているため、一部のコードを HEXR) とプレーンボックスで共有します。

右側の列にはさまざまなテストプロバイダーがあります。 チェックボックスプロジェクトは
多数のプロバイダーを生成および維持します (以下の表を参照) が、これは予想されています。
ダウンストリーム ユーザーも独自のプロバイダー (顧客またはユーザーに固有) を作成することになります。
計画）。 最終的には、一部のプロバイダーがサードパーティから提供される可能性があります。
形式でダウンロードすることができます。

最後に左下隅の共有ライブラリです。このライブラリには多くのパーサーが含まれています
さまざまなファイル形式と出力形式に対応しています。 技術的には、このライブラリは次の依存関係にあります。
HEXR、チェックボックスNG & プロバイダーの。 さらに複雑になるため、ライブラリを呼び出す必要があります。
python3 コードと python2 コードから。

注意：
checkbox-ng と plainbox の間の通信は双方向です。 プレーンボックスのオファー
いくつかの基本インターフェイスと拡張ポイント。 これらはすべてプレーンボックスを通じて公開されます
(共通 API を使用) しかし、それらの一部は実際には checkbox-ng で実装されています。

警告：
すべての内部 API は半不安定です。 DBus API は実際にはより安定していますが、
頼りにならない。 プロジェクトは、API が含まれる lp:checkbox にマージすることをお勧めします。
遷移を適切に処理できます。 唯一安定した API はファイル形式です
仕様 (ジョブ定義とホワイトライト)。 ランチャーの仕様は
次のリリースで安定化されます。

成分 説明
┌─────────────┬───────────── ─────────┬───────────┐
│プロジェクト │ 担当 │ 種類 │
§───────────┼─────────── ─────────┼─────────────┤
│次世代チェックボックス │ │ アプリケーション │
│(GUI) │ · C++/QML │ │
│ │ ユーザーインターフェース │ │
│ │ │ │
│ │ ・グラフィカル │ │
│ │ 用ランチャー │ │
│ │ プロバイダー、例 │ │
│ │ チェックボックス認証クライアント │ │
§───────────┼─────────── ─────────┼─────────────┤
│次世代チェックボックス │ │ アプリケーション │
│(CLI) │ · Python コマンドライン │ │
│ │ インターフェイス │ │
│ │ │ │
│ │ · テキスト ユーザー インターフェイス │ │
│ │ │ │
│ │ ・ SRU テストコマンド │ │
│ │ │ │
│ │ ・追加の認証 API │ │
│ │ │ │
│ │ · Launchpad にデータを送信中 │ │
│ │ │ │
│ │ ・ HEXR にデータを送信中 │ │
│ │ │ │
│ │ · │ │ が必要とする DBus サービス
│ │ GUI │ │
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ─────────┴─────────────┘

│クライアント認証 │ │ プロバイダー │
│プロバイダー │ · canonical-certification-client │ │
│ │ 実行可能ファイル │ │
│ │ │ │
│ │ ・クライアント認証 │ │
│ │ ホワイトリスト │ │
§───────────┼─────────── ─────────┼─────────────┤
│サーバー認証 │ │ プロバイダー │
│プロバイダー │・サーバー認証 │ │
│ │ ホワイトリスト │ │
│ │ │ │
│ │ · 追加のサーバー ホワイトリスト │ │
§───────────┼─────────── ─────────┼─────────────┤
│システムオンチップサーバー │ │ プロバイダー │
│認証プロバイダー │ ・SoCサーバー認証 │ │
│ │ ホワイトリスト │ │
§───────────┼─────────── ─────────┼─────────────┤
│チェックボックスプロバイダー │ │ プロバイダー │
│ │ ・ほぼすべてのジョブ定義 │ │
│ │ │ │
│ │ ・カスタム「スクリプト」のほとんど │ │
│ │ │ │
│ │ · デフォルトおよび SRU ホワイトリスト │ │
§───────────┼─────────── ─────────┼─────────────┤
│リソースプロバイダー │ │ プロバイダー │
│ │ ・ほぼ全てのリソースジョブ │ │
│ │ │ │
│ │ ・ほぼすべてのリソース「スクリプト」 │ │
§───────────┼─────────── ─────────┼─────────────┤
│チェックボックスのサポート │ │ ライブラリ │
│ │ ・各種サポートコード │ │
│ │ プロバイダー │ │
│ │ │ │
│ │ · 多くのテキスト形式に対応したパーサー │ │
§───────────┼─────────── ─────────┼─────────────┤
│PlainBox │ │ ライブラリと開発 │
│ │ ・ほぼすべてのコアロジック │ ツールキット │
│ │ │ │
│ │ ・RFC822（ジョブ定義） │ │
│ │ パーサー │ │
│ │ │ │
│ │ ・設定の取り扱い │ │
│ │ │ │
│ │ ・テストセッション │ │
│ │ (一時停止/再開) │ │
│ │ │ │
│ │ ・ジョブランナー │ │
│ │ │ │
│ │ ・信頼できるランチャー │ │
│ │ │ │
│ │ ・依存性リゾルバ │ │
│ │ │ │
│ │ ・コマンドライン処理 │ │
│ │ │ │
│ │ · XML、HTML、XSLX │ │
│ │ 輸出業者 │ │
│ │ │ │
│ │ ・その他... │ │
│ │ │ │
│ │ ・プロバイダ開発ツールキット │ │
│ │ │ │
│ │ · 'プレーンボックス スタートプロバイダー' │ │
│ │ │ │
│ │ · 'manage.py' の実装 │ │
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ─────────┴─────────────┘

│レガシーチェックボックス (いいえ │ │ モノリシックアプリケーション │
│より長く維持されます） │ · アプリケーション │ ライブラリとデータ │
│ │ │ │
│ │ · Qt4 GUI │ │
│ │ │ │
│ │ ・Gtk2 GUI │ │
│ │ │ │
│ │ ・ウルウィド（テキスト）GUI │ │
│ │ │ │
│ │ ・コア │ │
│ │ │ │
│ │ ・プラグインとイベント/メッセージ │ │
│ │ エンジン │ │
│ │ │ │
│ │ ・ほぼすべての機能 │ │
│ │ コアプラグインを実装しました │ │
│ │ │ │
│ │ ・データ │ │
│ │ │ │
│ │ ・ ジョブとホワイトリスト │ │
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ─────────┴─────────────┘

変更履歴

注意：
この変更ログには、変更の概要のみが含まれています。 より正確な会計のために
開発履歴はソース履歴を直接調べてください。

チェックボックスNG 0.23 (未発表)
・ バグの修正： https://launchpad.net/checkbox-ng/+milestone/0.23

チェックボックスNG 0.22
・ バグの修正： https://launchpad.net/checkbox-ng/+milestone/0.22

チェックボックスNG 0.3
・ バグの修正： https://launchpad.net/checkbox-ng/+milestone/0.3

チェックボックスNG 0.2
・ バグの修正： https://launchpad.net/checkbox-ng/+milestone/0.2

チェックボックスNG 0.1
・ 初回リリース

· 設定の表示のサポート

· SRU テスト (自動回帰テスト) の実行のサポート

テスト スクリプト

テスト「スクリプト」は、テストの実装を支援するために使用される小さなプログラムです。

明るさテスト
このスクリプトは、システムのバックライトの明るさをテストします。
/sys/class/backlight のカーネル インターフェイス。 選択できるインターフェースが複数ある場合があります
したがって、使用する正しいインターフェイスは、で規定されているヒューリスティックを使用して選択されます。
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight。 明るさ
インターフェースの明るさファイルとactual_brightnessを更新することで操作されます。
ファイルがチェックされ、値が選択した明るさに変更されたかどうかが確認されます。

プロフィール CONFIGURATION

実行プロファイルまたはランチャーを使用すると、事前定義された構成セットを指定できます。
ようこそ画面、表示されるホワイトリスト、およびカスタマイズを可能にするオプション
結果をローカルに保存するか、送信ファイルを Launchpad または認定に送信します。
データベース/HEXR、およびその他のパラメータ。

プロファイル設定はランチャー スクリプトの一部であり、checkbox-gui または
キー/値を解釈するためのシバンとしてのチェックボックスランチャー (テキストモード/CLI)。

このドキュメントでは、ランチャーの機能と構文に関するリファレンスを提供します。 を理解するには、
デザインとコンセプトを確認し、いくつかの例を参照してください。 チュートリアル どのように
ランチャーと従来のチェックボックスとの関係を作成します。

構文
checkbox-gui は Qt アプリケーションであるため、設定は INI スタイルのルールに従う必要があります。
Q設定 <http://qt-project.org/doc/qt-5/QSettings.html>クラス。

複数行の値はサポートされていますが、二重引用符と余分な行で囲む必要があります
スペース XNUMX つで始める必要があります。例:

[カテゴリー]
key = "こんにちは
世界"

· QML から:

settings.value("カテゴリー/キー", i18n.tr("default_value"))

· C++ から:

設定->値("カテゴリ/キー", app.tr("デフォルト値"))

逆に、チェックボックスランチャー固有のランチャーは以下に従う必要があります。 Python 構成パーサー
<https://docs.python.org/3/library/configparser.html#supported-ini-file-structure> 構文。

また、一部の設定は GUI または CLI でのみ意味をなすため、GUI または CLI では理解できません。
もう一方。 これらについては以下で説明します。

サポート 設定
ようこそ/タイトル
QML アプリケーションのタイトルとようこそ画面のヘッダー。 デフォルトは エントルピー テスト.

ようこそ/テキスト
最初の画面に表示されるウェルカム メッセージ (checkbox-gui はリッチ テキストをサポートします)
HTML スタイルのマークアップを許可します)。 デフォルトは いらっしゃいませ 〜へ エントルピー テスト中。 [...]

スイート/ホワイトリストフィルター
ホワイトリストのファイル名のサブセットと一致する正規表現。 チェックボックスGUIでそれを
デフォルトは .*。 チェックボックスランチャーの場合、デフォルトはありません。 しなければなりません 定義されます。

スイート/ホワイトリスト選択
ホワイトリストが事前に選択されるために一致する必要があるパターン。 Python の正規表現。
デフォルトはありませんし、 しなければなりません 定義される。 (CLIのみ)

スイート/skip_whitelist_selection
true に設定すると、ユーザーはホワイトリストの選択肢を受け取りません。 あらかじめ選択されたもののみ
そのうちの XNUMX つ (whitelist_selection を参照) が選択されます。 (CLI のみ)。

スイート/skip_test_selection
true に設定すると、ユーザーは実行前にテストの選択を解除できなくなります: すべてのテスト
選択したホワイトリスト内のものが実行されます。 (CLIのみ)

投稿/メッセージ
送信ポップアップのヘッダー テキスト。送信後にユーザーに表示されます。
完成しました。 (GUIのみ)

送信/入力タイプ
セキュア ID または LP アドレス (デフォルト) を入力するためのテキスト入力フィールドを表示します。 に
結果をディスクに保存するだけです。 なし 価値。 正規表現を使用して検証するには、
は 正規表現。 (GUIのみ)

提出/正規表現
送信フィールドの入力を検証するための正規表現 (電子メール、secure_id など)
input_type が正規表現の場合。 (GUIのみ)。 RegExpValidator、デフォルト .*

submit/input_placeholder
入力フィールドに入力する一時的なテキスト。ユーザーをガイドするために使用されます。 ランチパッド Eメール
住所 （デフォルト）または セキュアー ID （15 or 18 キャラクター）。 (GUIのみ)

送信/secure_id
テキストフィールドに入力するための事前構成済みの secure_id。

提出/ok_btn_text
「送信」ボタンのラベル。 送信 結果 （デフォルト）または Save 結果。 (GUI
のみ）

送信/キャンセル_警告
レポートを保存せずに終了したいかどうかをユーザーに示します。 あなたは約
結果レポートを保存せずにこのテスト実行を終了します。 を保存しますか?
報告？ (GUIのみ)

提出/submit_to_hexr
ブール値。結果を HEXR に送信するための追加ヘッダーを追加します (
証明書の輸送）

エクスポーター/xml_export_path
XML 送信ファイルを保存する場所。空の文字列に設定すると、
ファイル保存ダイアログ。 デフォルト： /tmp/submission.xml (GUIのみ)

輸送/提出先
トランスポートエンドポイント。 デフォルトは 。 LP への送信をサポート (デフォルト、
値 発射台), プロフェッショナル認定または ローカル (ディスクに保存)

トランスポート/submit_url
結果を送信する先の URL。 これにより、たとえば、さまざまな Web サイトにアップロードできるようになります。
hexr またはステージング サイトに直接アップロードできます。 のみで使用されます
プロフェッショナル認定 submit_to の値。

トランスポート/config_filename
ロードするカスタム構成ファイルの名前。 設定ファイルは主に定義するために使用されます。
環境変数。 (CLIのみ)

トランスポート/dont_suppress_output
設定すると、リソース、ローカル ジョブ、添付ファイルが画面に出力されます。
大量のテキストを生成し、主にデバッグに使用されます。 (CLIのみ)

チェックボックス/プレーンボックス ランチャー チュートリアル

このドキュメントでは、ランチャーが必要な理由、ランチャーで何が実現できるのかについて説明します。
いくつかの例を取り上げて、その機能をより詳しく説明します。 のために
ランチャーでサポートされている設定に関する詳細なリファレンス、およびランチャーの特定の構文
ランチャーファイル、見てください /プロファイル.

Legacy チェックボックス 行動 コントロール
以前は、Checkbox の動作は XNUMX つのメカニズムによって制御されていました。

まず、プラグインを追加することでチェックボックスの機能を拡張できます。 たとえば、
認証 Web サイトに送信する機能が checkbox-certification パッケージによって追加されました
プラグインを使用して。 checkbox-certification に含まれ、新しい動作を追加するプラグイン
to Base チェックボックスは次のとおりです。

/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

これらにより、ユーザーに送信固有のデータの入力を求め、XML を生成する方法が追加されました。
レポートやその他の機能。

次に、構成を使用してプラグインの動作を構成または制御できます。
ファイルは「カスケード」されます。 構成ファイルには他の構成ファイルを含めることができ、それらも順番に含めることができます
他も含めて。

これは、プロジェクト固有の project-qt.ini メイン構成ファイルの例です。 それは最初です
プロジェクト固有のクライアントの起動時に読み取られるファイル。 一部の設定は省略されています。

[デフォルト]
含まれるもの = %(checkbox_oem_share)s/configs/checkbox-project-base-qt.ini %(checkbox_project_share)s/configs/checkbox-project-base.ini

[チェックボックス/プラグイン/環境情報]
リポジトリ = deb http://.*\(archive\|security\).ubuntu.com/ubuntu precision-security
ルーター = 複数
サーバー_iperf = 10.20.30.40
ソースリスト = /etc/apt/sources.list
wpa_n_psk = パスワード
wpa_n_ssid = アクセスポイント

[チェックボックス/プラグイン/ユーザーインターフェース]
title = 私のプロジェクト システムテスト

include 行に注目してください。これは、構成ファイルをロードするように指示しています。
checkbox-project-base-qt と checkbox-project-base 。 Checkbox-project-base-qt は、
checkbox-certification と checkbox-project の構成。 設定はカスケードされるため、
上部近くの設定オプションは下部近くの設定オプションをオーバーライドします。

最後に、チェックボックスを呼び出すために使用される「バイナリ」は、検索する場所を定義するシェル スクリプトです。
チェックボックスを実行する必要があるもの: 共有ディレクトリ、特定のデータを定義できます。
ディレクトリに移動し、構成ファイルを指定し、必要な環境変数をいくつか定義します。
テスト中に必要になる場合があります。 checkbox-project-qt の例を次に示します。

#!/bin/bash
エクスポート CHECKBOX_DATA=${CHECKBOX_DATA:-~/.チェックボックス}
エクスポート CHECKBOX_SHARE=${CHECKBOX_SHARE:-/usr/share/checkbox}
エクスポート CHECKBOX_OPTIONS=${CHECKBOX_OPTIONS:---log-level=debug --log=$CHECKBOX_DATA/checkbox-project.log}
エクスポート CHECKBOX_CERTIFICATION_SHARE=${CHECKBOX_CERTIFICATION_SHARE:-/usr/share/checkbox-certification}
エクスポート CHECKBOX_OEM_SHARE=${CHECKBOX_PROJECT_BASE_SHARE:-/usr/share/checkbox-project-base}
エクスポート CHECKBOX_PROJECT_SHARE=${CHECKBOX_PROJECT_SHARE:-/usr/share/checkbox-project}

# PYTHONPATH ディレクトリを定義するのに便利です。
if [ "$CHECKBOX_SHARE" != "/usr/share/checkbox" ]; それから
エクスポート PYTHONPATH="$CHECKBOX_SHARE:$PYTHONPATH"
fi

python3 $CHECKBOX_SHARE/run "$@" $CHECKBOX_PROJECT_SHARE/configs/$(ベース名 $0).ini

ここでは、いくつかの場所が定義されており、重要な部分が最後の python3 であることがわかります。
この行で、前に見た必要な .ini 構成ファイルを見つけて使用します。

この階層組織は非常に強力でしたが、扱いが難しいものでもありました。
にもいくつかの制限がありました。 チェックボックスで行った作業の一部は、すべての機能を統合することでした。
プロジェクト固有のプラグインをチェックボックス トランクに追加すると、すべてのコア コードが XNUMX か所に集まります。
プロジェクト固有のバリアントは、ジョブ、ホワイトリスト、データ、構成のみを提供します。
新しい動作を追加することなく。

新作 プレーンボックス 行動 コントロール
checkbox とは異なり、plainbox のコアはモノリシックであり、プラグインの概念がありません。 これ
理解と作業が容易になります。 プレーンボックス コアにはすべての実装が含まれています
古いチェックボックス パッケージの関数なので、機能を使用するために追加する必要はありません
認証への提出やレポートの作成など。

プレーンボックスと呼ばれるものは、ご覧のとおり、すべての機能を実装するライブラリです。
こちら.

Plainbox は、テスト開発者がテストを作成してパッケージ化するのに役立つツールを提供します。 これらは
テスト記述をカプセル化するように設計されたエンティティである「プロバイダ」で配信されます。
テスト用のカスタム スクリプト、ホワイトリスト、各種データ。 それらは、次のことを可能にするように設計されています。
チームはあまり心配することなくカスタム テストを作成して提供できます。
基礎となるプレーンボックス コード。

テストとプロバイダーの作成方法については、「プロバイダーのチュートリアル」を参照してください。

ただし、実際にこれらのテストを使用して実際のシステムを検証する場合、次のことを提供したいと考えました。
より簡単でチェックボックスのユーザーエクスペリエンスに近いもの。 XNUMX つのクライアントを作成しました。
checkbox-gui と checkbox-cli にはいくつかのハードコードされた動作があり、また、
これらに基づいて目的に特化した他のクライアントを作成しました。 例えば、
SRU テスト用のチェックボックスのバージョン、サーバー認証用のチェックボックスなどがありました。

しかしその後、多くのコードが重複しており、動作が共通していることに気付きました。
いくつかの変更を除いて。 そこで私たちは「ランチャー」という概念を思いつきました。
チェックボックスの設定ファイルやシェル スクリプト ランチャーに似ています。

checkbox-gui と checkbox-cli には非常に基本的な動作があるという考えです。
は、ubuntu にデフォルトで同梱されるクライアントです。 利用可能なものをすべて表示できます
ホワイトリストを作成し、事前定義されたウェルカム メッセージを表示し、最後にユーザーに
HTML レポートを作成し、バージョンと同様の電子メール アドレスを使用して Launchpad に送信します。
Ubuntu に同梱されているチェックボックスの。

複雑なコマンド ライン スイッチを使用する代わりに、ランチャーを使用していくつかの設定を行うことができます。
テスト エクスペリエンスをカスタマイズするためのオプションの動作。 ランチャーには設定が含まれており、
シェル スクリプトに似ていますが、インタプリタは checkbox-gui または
チェックボックスランチャー。

ここでは、ランチャーで実行できることの例をいくつか示します。

驚いたことに、checkbox-cli 自体がランチャーです。

#!/ usr / bin / env チェックボックスランチャー
[いらっしゃいませ]
text = システム テストへようこそ!
チェックボックスは、システムが適切に動作していることを確認するためのテストを提供します。
テストの実行が終了したら、テストの概要レポートを表示できます。
あなたのシステム。
警告: 一部のテストでは、システムがフリーズしたり、
無反応。 すべての作業内容を保存し、実行中の他のすべてを閉じてください
テストプロセスを開始する前にアプリケーションをインストールしてください。

[スイート]
ホワイトリストフィルター = ^デフォルト$
ホワイトリスト選択 = ^デフォルト$
Skip_whitelist_selection = True

[輸送]
submit_to = ラウンチパッド

ここでいくつかのオプションをカスタマイズしていることがわかります。ウェルカム メッセージが自動的に表示されます。
デフォルトのホワイトリストを選択し、完了すると Launchpad に送信されます。

グラフィカル ランチャーの例は canonical-certification-client です。

#!/usr/bin/checkbox-gui

[いらっしゃいませ]
title = "システム認証"
テキスト = " システム認定へようこそ! このアプリケーションは、
システムから情報を収集します。 次に、手動テストを行うように求められます。
システムが正常に動作していることを確認します。 最後に求められるのは、
認証に情報を送信するためのコンピューターのセキュア ID
データベース。 セキュア ID を作成または検索する方法については、
こちらをご覧ください: certification.canonical.com 」

[スイート]
Whitelist_filter = "^client-(cert|selftest).*"

[提出]
input_type = "正規表現"
input_placeholder = "セキュア ID (15 文字または 18 文字)"
ok_btn_text = "結果を送信"
submit_to_hexr = "true"

【輸出業者】
xml_export_path = "/tmp/submission.xml"

[輸送]
submit_to = "証明書"

グラフィカルランチャーはもう少し複雑ですが、本質的には似ています。
テストエクスペリエンスをカスタマイズするためにいくつかのパラメータを定義できます。

非常に単純なテキスト モード ランチャーは canonical-hw-collection で、基本的なものだけを実行します。
ハードウェア情報をテストし、ハードウェア データベースにアップロードします。

[いらっしゃいませ]
title = ハードウェア情報の収集
text = ハードウェア情報を収集しています。 パスワードの入力を求められる場合があります。
このプロセスには約 30 秒かかります。
ハードウェアを確認して登録できる URL が含まれています
提出。

[スイート]
ホワイトリストフィルター = ^hwsubmit$
ホワイトリスト選択 = ^hwsubmit$
Skip_whitelist_selection = True
Skip_test_selection = True

[提出]
# 偽の secure_id により、私たちがそれを尋ねないようにする
# .conf ファイルでいつでもオーバーライドできます。
セキュア ID = 000

[輸送]
submit_to = 証明書
submit_url = https://hardware-server.example.com/

最後に、canonical-driver-test-suite はグラフィカル モードとテキスト モードの両方のランチャーを提供します。
これらは機能的に同等です。

#!/usr/bin/checkbox-gui

[いらっしゃいませ]
title = "正規ドライバー テスト スイート"
テキスト = " Canonical ドライバー テスト スイートへようこそ。

このプログラムには、発見に役立つ自動テストと手動テストが含まれています。
Ubuntu でデバイス ドライバーを実行するときに発生する問題。

このアプリケーションは、ユーザーにこれらのテストを段階的に実行させます。
あらかじめ決められた順序で両方のシステム情報を自動的に収集します。
テスト結果も。 手動の場合もユーザーに入力を求めるプロンプトが表示されます
テストが必要です。

テストの実行時間は、どのテストを実行するかによって決まります。
実行する。 ユーザーはテスト実行をカスタマイズすることができます。
ドライバーとテストに使用できる時間を考慮します。

まず、下の [続行] ボタンをクリックし、画面上の指示に従ってください。
手順。 」

[スイート]
Whitelist_filter = "^ihv-.*"

[提出]
ok_btn_text = "結果を保存"
input_type = "なし"

【輸出業者】
xml_export_path = ""

[輸送]
submit_to = "ローカル"

テキストモード：

#!/ usr / bin / env チェックボックスランチャー
[いらっしゃいませ]
text = Canonical Driver Test Suite へようこそ
このプログラムには、発見に役立つ自動テストと手動テストが含まれています。
Ubuntu でデバイス ドライバーを実行するときに発生する問題。
このアプリケーションは、ユーザーにこれらのテストを段階的に実行させます。
あらかじめ決められた順序で両方のシステム情報を自動的に収集します。
テスト結果も。 手動の場合もユーザーに入力を求めるプロンプトが表示されます
テストが必要です。
テストの実行時間は、どのテストを実行するかによって決まります。
実行する。 ユーザーはテスト実行をカスタマイズすることができます。
ドライバーとテストに使用できる時間を考慮します。
まず、下の [続行] ボタンをクリックし、画面上の指示に従ってください。
指示に従ってください。

[スイート]
# スイート選択画面に表示されるホワイトリスト
ホワイトリストフィルター = ^ihv-.*
# Whitelist_selection は必須なので、偽の値に設定します。
# 事前に選択されているホワイトリストはありません。
ホワイトリスト選択 = 偽物

チェックボックス RELEASE プロセス

このページでは、Checkbox と Checkbox のバージョンをリリースするために必要な手順について説明します。
ハードウェア認定チームに属する安定した PPA に対する定期的な認定
基礎。 このドキュメント全体を通じて、「チェックボックス」という用語は、すべてをカバーする包括的な用語として使用されています。
ハードウェア認定チームが所有する Checkbox のすべてのバージョン (現在は Checkbox)
それ自体と Checkbox Certification 拡張機能。

概要
現在、このプロセスは隔週のペースで実行され、Checkbox の新しいリリースは毎週行われます。
二週間。 これは XNUMX 日間の営業日と、毎日またはグループごとに実行されるタスクをカバーします。
日数については以下で説明します。

· 1 ～ 4 日目: 新しい変更をトランクに導入するために許可される時間。

· 5 日目: 変更はトランクからマージされます。 lp:チェックボックス & lp:チェックボックス認証 〜へ
それぞれのリリース ブランチ。 両方の変更ログは次のとおりです ぶつかった この時点で、そして
リビジョンにはタグが付けられています。 この段階では、パッケージ「fwts」をコピーする必要がある場合もあります。
FWTS 安定した PPA <https://launchpad.net/~firmware-testing-team/+archive/ppa-
fwts-安定>へ チェックボックス リリース テスト PPA <https://launchpad.net/~checkbox-
開発/+アーカイブ/テスト>.

· 6 ～ 9 日目: ハードウェア認定のリリース マネージャーによってテストが実行されます。
チーム、および CE QA チームの代表者 (社内の Checkbox の主要顧客)
正規)

· 9 日目: ハードウェアのリリース マネージャーとの間でリリース ミーティングが開催されます。
認証チームおよびCE QAチームの代表。 の潜在的な問題
リリースが特定され、それに対処するための計画が立てられます。

· 10 日目: Checkbox のテストされたバージョンが安定した PPA にコピーされます。

ランチパッド 取引所の支社長制度
リリース プロセスには、半凍結されたファイルを含む Launchpad の別のブランチが必要です。
プロセスの 5 日目にトランクにあったコードのバージョン。 これはその開発のためです
リリース予定のバージョンの安定性を損なうことなく、トランク上で続行できます。
チェックボックス。 プロセスに含まれるすべてのブランチ間の関係は次のとおりです。

· lp:チェックボックス/リリース <- lp:チェックボックス

· lp:チェックボックス-認証/リリース <- lp:チェックボックス認証

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

会計監査 マイルストーンを迎えた バグ
リリース候補を作成する前に、リリース マネージャーはバグのリストを確認する必要があります。
Checkbox の次のリリースに向けたマイルストーン。 彼らは訪れるべきです チェックボックス マイルストーン
<https://launchpad.net/checkbox/+milestonesmilestones> という日付のマイルストーンを見つけます。
リリース日。

· 関連付けられたブランチで [進行中] に設定されているバグの場合 - ブランチと連携します。
所有者に連絡して、期限までにマージを完了できるかどうかを確認してください。

· その他の非クローズ状態にあるバグ (例外を除く) 修正する コミットした) - 再マイルストーン
次のマイルストーンまで進みます。

切断 　 リリース
リリースをカットするには、トランクからの変更をリリースにマージする必要があります
ブランチに移動し、適切なメッセージを使用してコミットし、トランク内の変更ログを更新します。
将来の変更は正しいバージョンに基づいて行われます。 上記の分岐の組み合わせごとに、
次の操作を実行します (例では lp:チェックボックス & lp:チェックボックス/リリース):

bzr ブランチ lp:チェックボックス/リリース チェックボックス-リリース
bzr ブランチ lp:チェックボックス チェックボックス-トランク
cd チェックボックス-リリース
current_stable=`head -n1 $(find . -name 'changelog') | grep -oP '(?<=\().*(?=\))'`
bzr マージ lp:チェックボックス

この時点で何も変更がなければ (変更するもの以外は) debian / changelog) マージしてから実行します
問題のパッケージのリリースを実行しないでください。 実際には、これはよく起こります
チェックボックス認証 でも決して一緒ではない チェックボックス:

bzr commit -m "lp:checkbox の rev$(bzr revno -r tag:$current_stable lp:checkbox) から rev$(bzr revno lp:checkbox) への変更をマージしました"
bzr プッシュ LP:チェックボックス/リリース
cd ` を見つけます。 -name 'debian' `; CD ..
bzr タグ `head -n1 debian/changelog | grep -oP '(?<=\().*(?=\))'`
dch -r (変更された変更ログを保存)
dch -i -U '増分された変更ログ'
デコミット
bzr プッシュ LP:チェックボックス

プロセスの最後のステップは、パッケージのビルドを実行することです。
ppa:checkbox-dev/testing PPA。 これを行うには、
チェックボックス および チェックボックス認証 枝を解放します。

· チェックボックスのテスト レシピ <https://code.launchpad.net/~checkbox-dev/+recipe/checkbox-
テスト>

· チェックボックス-認証-テスト レシピ <https://code.launchpad.net/~checkbox-
dev/+recipe/checkbox-certification-testing>

　 完成に向けてあなたの背中を押してくれる、執筆のための持続可能で本物のモーメンタムを作り出す。 Now このオプションはページ上で利用できるはずです。 それをクリックしてビルドを開始します。

複写 ファームウェア ホイール試乗 スイート 〜へ 　 テスト PPA
Firmware Test Suite ツールは、システム ファームウェアのテスト ツールです。
チェックボックスで利用されます。 修正と新規を含む最新バージョンを確認するには
Checkbox に必要なテスト/機能が利用可能であり、何も中断しません。
Checkbox は、Checkbox と一緒にリリースする必要があります。 リリースをカットした後、
ファームウェア テスト チームは、新しいバージョンが利用可能であることと、このバージョンが利用可能であることを通知しました。
認証に使用する必要がある場合は、それをテスト PPA にコピーする必要があります。 これを行うために私たちは
に行く必要があります コピー パッケージ ビュー of 　 ファームウェア ホイール試乗 スイート （安定的） PPA
<https://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable/+copy-packages>および
Precise に戻るすべてのリリースの「fwts」パッケージを選択します。 を設定する必要があります。
「Destination PPA」を「Checkbox Release Testing [~checkbox-dev/testing]」および「コピー」として
[オプション] フィールドを [既存のバイナリをコピー] に変更し、[パッケージをコピー] をクリックします。 このステップでは
繰り返す必要がありますが、「Destination PPA」フィールドを「PPA for Checkbox Developers」に設定します。
[~checkbox-dev/ppa]'。

Next リリース of チェックボックス メール
誰もが必要なテストをタイムリーに実行できるようにするため
PPA のビルドが完了したら、次の宛先に電子メールを送信する必要があります。
メーリングリスト：

· [メール保護] <ハードウェア認証-
[メール保護]>

· [メール保護] <[メール保護]>

内容は通常次のようなものです。

件名: Checkbox の次のリリース (18/11/2013)

こんにちは、

Checkbox の次のリリースは、
https://code.launchpad.net/~checkbox-dev/+archive/testing PPA.
ご都合に合わせてテストしてください。 チェックボックスは、リビジョン 2484 に基づいています。
lp:checkbox およびチェックボックス認定は、リビジョン 586 に基づいています。
lp:チェックボックス認証。

おかげで、

チェックボックスとチェックボックス認定のいずれかが更新されていない場合は、
そのパッケージについて言及する必要はありません

テスト 　 リリース
リリースはカットされたため、リリース ミーティングの前にテストを行う必要があります。
認証チームの観点から見ると、テストする必要があるのは次のとおりです。
チェックボックス認証クライアント & チェックボックス認証サーバー の基礎となるもの
CE QA OEM 固有のバージョンの Checkbox。 チェックボックス認証サーバーは次の環境でテストされています。
CI ループ チェックボックス認証クライアントは手動でテストする必要があります。

リリース ミーティング
発売前の木曜日に、代表者間で会議が開催されます。
認証チームとその代表者 商用ダイビング機材 エンジニアリング QA チーム。 ザ
この図に示すように、会議は UTC 7:30 に開催されます カレンダー 招待
<https://www.google.com/calendar/hosted/canonical.com/event?action=TEMPLATE&tmeid=Y3QxcWVla3ViMTRvMXByOHZlOTFvc283Y2NfMjAxMzA4MjlUMDczMDAwWiBicmVuZGFuLmRvbmVnYW5AY2Fub25pY2FsLmNvbQ&tmsrc=brendan.donegan%40canonical.com>.
会議の議題は招待状に含まれています。

出版 　 リリース
リリースを公開するには、次の場所からいくつかのパッケージをコピーするだけです。 チェックボックス
リリース テスト PPA <https://launchpad.net/~checkbox-dev/+archive/testing>へ Hardware
認証 公共 PPA <https://launchpad.net/~hardware-certification/+archive/public>.
これを行うには、 コピー パッケージ ビュー of 　 チェックボックス リリース テスト PPA
<https://launchpad.net/~checkbox-dev/+archive/testing/+copy-packages> そしてすべてを選択します
次のパッケージのリストのバージョン: チェックボックス、 チェックボックス認証、 fwts。 作る
「宛先 PPA」フィールドが「ハードウェア認証用のパブリック PPA」に設定されていることを確認してください。
[~hardware-certification/public]」、および「コピー オプション」フィールドが「コピー」に設定されていること
既存のバイナリ」を選択し、「パッケージのコピー」をクリックします。

それが完了すると、通知メールが次の宛先に送信されます。
[メール保護] <[メール保護]>.
発表のテンプレートは以下に含まれています。

こんにちは、

チェックボックスの新しいリリースがハードウェアにアップロードされました
認定パブリック PPA
(https://launchpad.net/~hardware-certification/+archive/public)。 の
リリースは lp:checkbox のリビジョン 2294 に基づいています

おかげで、

変更ログの最新部分をリリースノートとして添付してください

· ジェネインデックス

· modindex

・ 検索

onworks.net サービスを使用して、checkbox-cli オンラインを使用する