はじめに
JaSST'22 Kyushuは、オンサイトとオンラインでのハイブリッド開催となった。JaSST Kyushuは「関東圏まで出なくてもソフトウェアテストのシンポジウムに参加できる」をコンセプトに、毎年九州の各県で開催されてきた。今年の開催地は佐賀県(佐賀大学 本庄キャンパス)であり、晴れて九州の全ての県で開催されたことになる。
基調講演
「皆さんの自動テストは改善されていますか？」
山口 鉄平 氏（freee）
freeeの自動テストの目的と使い方
freee社では、10以上のサービスを並行して開発しており、1日に2回程度の頻度でリリースを行っている。高い頻度でリリースを続けるには、自動化されたリグレッションテストが欠かせない。本講演では、自動実行されるリグレッションテストを「自動テスト」と呼ぶ。自動テストは、E2Eテスト、APIテスト、ユニットテストの3種類に分類される。
freeeの自動テストの「今」の構成
- ユニットテスト
比較的一般的な構成。CircleCIやGitHub Actionsの上にDockerが乗り、その上に各言語と、各言語に対応したテストフレームワークが乗っている。
- WEBのE2Eテスト
RSpec、Capybara、SitePrismの3つのテストフレームワークをベースに、それらをJenkinsで管理して動かす構成となっている。実行されるシナリオ数は、月間で約30000。実行維持コストは全サービスを合わせても、1日あたり1人いれば十分な程度である。
自動テストの運用としておこなうこと
自動テストの提供チームは、運用として5つの活動を行っている。
- 自動テストの実行失敗時の要因分析
特にE2Eテストにおいて、不安定性による失敗の判断が難しく、自動テストの提供チームがサポートを行っている。
具体的には、失敗箇所の特定、原因の推測、自動テストの再実行、失敗箇所に関する変更の確認を実施する。
- 自動テストの実行環境のアップデート
テストフレームワークにおける利用ライブラリ、実行環境のOS、利用ブラウザのアップデートなどを行い、影響の有無を検証し、影響があった場合は対応を実施する。
- 自動テスト実行時間の適正化に向けたテストスクリプトや構成の変更
テストが増加すれば実行時間も増加する。組織としての現実的な落とし所を探りつつ、全体の実行時間を一定の枠におさめる。具体的には、時間のかかるテストを特定し、並列実行の構成を変更し、不要な処理の削除や統合を実施する。
- 自動テスト利用者の拡大のサポート
自動テストの知見が自動テストの提供チームに閉じてしまうと、情報伝達だけで多くの時間を要してしまい、頻繁なリリースのボトルネックになってしまう。開発チームなど、テストの関係者自身が自動テストを作成・編集できるようになった方が望ましい。
そこで主に、テストスクリプト作成時のサポート(ペア作業やコードレビュー)、ドキュメントやコードスタイルガイドの整備、新入社員向けの社内ピーアールなどを実施する。
利用者が自動テストの利用を始めるまでは、自動テストの価値をアピールし、自動テストにかかるコストを価値よりも低くするような活動を行う。利用開始後は、自動テストの必要性を見極めつつ、継続のサポートを行う。利用者にとって自動テストの価値がないと判断された場合は、自動テストを削除する。
- 運用の改善
第一に、テスト実行を安定化させる改善に取り組んでいる。活動の中では最も大きなウェイトを占める。例えばE2Eテストでは、全体のテスト成功率や個々のテスト成功率を計測し、成功率が下がったテストに対して対策を行う。
また、プログラミングに詳しくない利用者であってもテストスクリプトを利用しやすくする改善や、運用の各作業を容易化・自動化する改善を行っている。
freeeの自動テストの改善の歴史
- 改善で意識していること
まず第一に、自動テストの利用者が増えることを目標としている。次に、良い改善を行うために、自動テストの提供チーム自身が当事者であり続けることも意識している。また、自動テストはある程度長期間利用するため、極力シンプルになるよう意識している。
- 改善の優先順位:基本的な考え方
まず第一に、自動テストの利用者が自動テストを信頼して(安定して高速に)利用できることを優先する。次に、持続的に運用できる状態を維持するよう利用コストを下げることと、自動テストの利用・作成・修正にかかる障壁を取り除くことを優先する。
- 改善の優先順位:短期・長期での考え方
短期では基本的な考え方を踏襲した優先順位、長期(5年程度)では、テストシステムの刷新や追加を視野に入れる。
- ユニットテストの運用と改善の歴史
開発初期(2012年)はRSpecを用いて、開発環境(1環境)で確認していた。テスト数の増加に伴い、専用の実行環境が必要となり、Jenkinsを導入した。2017年には、CircleCIに移行した(並列数を簡単に増やせることが大きなメリットだった)。
主な改善活動としては、前処理の削除や並列実行による実行時間の適正化を行ってきた。
- APIテストの運用と改善の歴史
APIテストは、まだfreee社として本格的に取り組めていない分野であるが、ユニットテストフレームワークを用いた部分については、ユニットテストと同様の歴史を辿ってきた。
その他、個別具体的なニーズに応じて、手動ではテスト困難な状況に対してAPIテストを整備した。
- WEBのE2Eテストの運用と改善の歴史
WEBのE2Eテストについては、大きな変更を何度も行ってきた。
最初(2014年)は、Selenium IDEを導入した。Selenium IDEはHTMLコードを生成するためレビューが困難であり、RubyのWebDriverによるテストシステムを導入した。2016年には、ユニットテストと同様に実行環境の分離が必要となりJenkinsを導入、また、実行を容易にするためchatbotを導入した。2017年には、開発者が慣れていることを理由に、Capybara+SitePrismによるテストシステムを導入した。テストシナリオとページファイルの分離により、テストの作成・修正が容易になった。
2019年後半ごろから、テスト実行回数の増加に伴い運用負荷が上がった。失敗時の結果確認の容易化、ダッシュボードの作成、E2Eテストを全社的にCapybara+SitePrismに統合する、などの取り組みを実施した。結果として、どのサービスに対してもテストシナリオの作成や理解が容易になった。
また、サービスのプロトタイプなどに対して部分的に、レコード&リプレイ型のSaaSを導入した。その他、E2Eテストをプルリクエスト上で実行できるよう改善に取り組んでいる。
おわりに
自動テストもひとつのサービスである。これを構築すれば終わりという性質のものではなく、常に多くの要望や課題があり、改善が必要である。ひとつの正解は無いが、考えて改善を続けることが重要である。
筆者感想
自動テストの歴史や運用の具体例もさることながら、山口氏をはじめとする自動テスト提供チームの想いや信念が強く印象に残った。利用者に自動テストはどのような価値を提供できるのか、長期的な視野では自動テストをどう考えるべきかなど、筆者自身のチームでもあらためて考えてみたくなる講演であった。
招待講演
「自動運転ソフトウェアの大規模シミュレーションサービスの立ち上げとこれから」
髙野 大輔 氏、関谷 英爾氏（ティアフォー）
第一部 TIER IVにおけるCIの取り組み
Introduction
TIER IV社では、自動運転システムの開発のほか、自動運転技術を開発・運用するための周辺基盤の構築も行っている。また、オープンソースの活用により、自動運転システムの構築を誰もが自由に実施できる世界を目指している。テスト対象となるソフトウェア(Autoware)はOSSであり、破壊的な変更が行われるリスクがある。そのため、CIによるチェックが必要となる。
評価基盤
テスト対象となるソフトウェアは多くのモジュールに分割されるが、全てを実車で行うことは現実的ではない。そこで、用途に応じて4つの評価基盤を使い分けている。
- Driving Log Replayer(ログデータを活用した、認識系の評価)
- Scenario Simulator(シミュレータを用いた、経路生成や制御系の評価)
- End2End Simulator(現実を再現するシミュレータを用いた、全モジュールを結合した評価)
- Real Test(実車を用いた評価)
TIER IVのCIの現状
開発フローにおいて、2種類のCIがある。1種類目はシナリオ評価を行うCIであり、開発用ブランチをmainブランチにマージする際に行われる。2種類目は、コーディング規約のチェックや単体テストの実行などを行うCIであり、プルリクエストの単位で行われる。
シナリオ評価を行うCIは、リリースごとの評価用ブランチに対しても行われる。
シナリオ評価を行うCIでは、Driving Log ReplayerとScenario Simulatorが実施される。
不具合検出事例
Scenario Simulatorでは、現実の交通状況をシミュレータ上に再現し、様々なシナリオを用いて、経路生成や制御系の評価を行う。例えば、車両が右折する際に対向車の通過を待つシナリオでは、1台目の対向車が通過したのち、自動運転ソフトウェアが2台目以降の対向車を考慮できずに右折を開始し、対向車に衝突してしまう不具合を検出した。
CIの課題
現状、CIにはいくつか課題がある。
- シナリオ評価を行うCIの実施後、結果の最終的な評価は人間が行う必要がある
- シナリオ評価で用いるシナリオを、リファレンスデザインを跨いで再利用できない
v
(リファレンスデザインとは、ODD(Operational Design Domain/運行設計領域)ごとにユースケースを類型化したもの。
例:自家用車、ロボタクシー)
- シナリオ評価を行うCIを、プルリクエストの単位で実施できる状況にない
(開発による影響範囲の判断や、結果の最終的な評価などを人間が実施する必要があるため、プルリクエストごとの実施は現実的でない)
第二部 技術開発編
CI/CDの立ち上げ
開発サイクルを支えるシステムであるWeb.Autoでは、テスト対象となるソフトウェア(Autoware)のソースコードをGitHubから取得し、ビルド、シミュレータによるテスト、リリース、運行管理システムとの連携によるデータ収集を行う。
Web.Autoの開発は、2018年に、実証実験に用いる運行管理システムを構築するところからスタートした。利用拠点の増加や開発陣の増加に伴い、シミュレータの開発やCI/CD基盤の構築が必要となった。様々なチームと協力し、運行管理システムとCI/CDの連携を実現させたのち、より多くのシミュレータを実行できる基盤を構築した。
CI/CDサービスの現状
Driving Log Replayerでは、センサーからの入力に基づくテストを扱う(センサーからの入力をログとして保存し、テスト時に再生する)。これは、シミュレータでは実現困難である。
Scenario Simulatorでは、シナリオベースでのテストを行う。シンプルなセンサーを用いてコンピューティング負荷を低くするなど、シミュレーションを膨大に回せるよう工夫している。
End2End Simulator(Scene Simulator for Autoware / AWSIM)では、センサーも実車同様の精度でシミュレーションを行う。AWSIMは、自動運転シミュレーションのほか、機械学習データ生成などの用途でも用いられる。
CI/CDのこれから
- DigitalTwinのチャレンジ
シミュレーションのカバレッジ拡充や、より複雑なシーンへの対応、自動運転の周辺エコシステムのE2Eへの組み込みなどの実現に取り組んでいる。
- Performance&Flakinessのチャレンジ
テスト実行時間の短縮や、不安定なテストの克服に取り組んでいる。
- 効率化のチャレンジ
データ解析の効率を上げるためにログデータの検索性を高める、ログデータから自動的にデータ抽出を行いシナリオ作成をする、などの実現に取り組んでいる。
筆者感想
自動運転システムのみならず、周囲を取り巻くソフトウェアも含めて非常に大規模な開発が必要であることを知ることができた。また、そのような大規模な開発を効率的に進めるため、組織やモジュールを分割するなどの工夫も知ることができた。筆者自身が携わるシステムは、本講演と比較すれば非常に小さいものではあるが、効率化を図るためのヒントを得ることができた。
筆者感想（全体）
基調講演と招待講演のいずれも、自動テストの運用事例を詳しく知ることができた。効果の高い自動テストを少ないコストで運用するための技術や、関係者を巻き込むための考え方など、様々な気づきを得られた一日であった。
