初出：SRA Qt MailNews 2018年10月号
改訂：2026年10月21日
掲載当時の事例を読みやすく再編集しました。本文の製品・構成・数値は当時の情報です。今回の解説・訂正は「編集補足」に記載しています。
この事例の要点
PerforceはP4VのGUI性能を継続的に確認するため、Squishを夜間テストに組み込みました。複数OS・複数バージョンを実行し、結果を毎朝のレポートへまとめる具体的な運用事例です。
継続的に性能変化を捉える
2018年のMailNewsは、PerforceのPerformance Lab engineerであるTim Brazil氏へのインタビュー内容を紹介しています。P4VはQtで開発したGUIクライアントで、新機能や修正によって操作性能が損なわれないことが課題でした。
採用理由には、標準的なスクリプト言語、コマンドライン実行、オブジェクトマップが挙げられています。既存のスクリプトや開発環境と組み合わせやすい点が評価されました。
夜間実行からレポートまで
当時の運用では、Windows、Mac OS X、SLED上で、夜間ビルドと過去3つのリリースをテストしていました。独自のPerlスクリプトrunner.plが各環境のテストを実行し、XML結果を集め、翌朝確認するHTMLレポートへ変換していました。
各テストは独立して実行できるようにし、一件の失敗が後続のテストへ影響しにくい構成にしています。処理の流れは「対象ビルドの準備 → OS・版ごとの実行 → XML集計 → HTMLレポート → 傾向確認」です。
保守性と待機処理
オブジェクトマップに識別情報を集約することで、画面変更時の修正範囲を抑えていました。またOSごとに読み込み時間が異なるため、wait系の関数で操作可能な状態を待つことが重要だったと説明されています。
編集補足：翌朝に判断できる結果を残す
自社へ応用する場合、レポートの一行に「対象OS・ビルド・操作名・所要時間・成否・前回との差」を並べると、失敗と性能変化を分けて追えます。これは本稿の運用から導いたレポート案です。自動化の完了を実行成功だけで判断せず、人が異常の原因を追えるかまで確認します。
出典・参考資料
出典：SRA Qt MailNews 2018年10月号の採用事例欄をもとに編集。
コラム一覧へ