ReportPortalをちょっとだけ試してみた
ReportPortalをちょっとだけ試した感想
という記事を見て、そういえば昔にReportPortalという名前だけは見たことがあるけど結局試していなかったなと思い出したので自分で少しだけ試してみました。
インストール（docker-compose）
dockerが提供されているので、とりあえず自分のマシンで雑に立ち上げてみます
ドキュメントの手順の通りにやっていきます。ElasticSearch関係のカーネルの設定を変更するのはちょっと怖かったのでスキップ。それ以外は普通に手順通りにdocker-compose upして起動できました。
立ち上げたらlocalhost:8080でReportPortalのログイン画面にアクセスできます。ドキュメントを見ると一般ユーザーとadminの2つのデフォルトアカウントが用意されていると書かれており、id/passが書いてあるのでadminであるsuperadminのアカウントでログインします。
デモデータを見る
SettingsにDEMO DATAという項目があったのでとりえあえずデモを見せてもらいましょう。
デモデータの作成が完了するとダッシュボードも自動的に作られるので早速見ていきます。
テストケースの成功数、失敗数などの推移らしい。investigatedが何を意味しているのかはまだ分からない。
左上と左下は全体の統計情報、右上はテスト時間、右下は失敗したテストケースの推移かな。
上は実行した回の全体的な情報？PRODUCT BUG, AUTO BUGと別れているということは、自動テストの失敗と人間が報告した問題を両方とも管理できるのか？
左下はテストが何回中何回失敗したか。右下は何かのフィルターをかけたあとにどれだけの成功率か？これは何を意味しているのか推測できなかった。
このあたりで「LAUNCH=1回の自動テストを実行した情報」ではなくて、QAにおける検証案件みたいに複数回の自動テストを内包するような単位なのかな？と推測。
Flakyテストなので成功/失敗が安定しないやつ
ダッシュボードページのグラフを一通り見たので、ここからは一番分からなかったLAUNCH TABLEを詳しく見てみます。
これはテストスイートの単位かな？
試しに左上のLaunch Testsをクリックし、次の一覧画面もまだよくわからないのでFinishLaunchTestをクリックしてみる。
テストケースとbefore、afterに対してStatusのプルダウンから自分でPassedやFailedのステータスを変えることもできるようです。
試しにTo Investigateが付いていたbeforeMethodを見てみるとこういう画面。
過去のステータス変更や、タグの情報や説明を付けられるらしい。自動テストの結果に対して、1つ1つ説明を追加したり修正すべき問題であるなどの情報を付けられるということかな
ちなみにこのbeforeMethodだとログが全く無かったので、他にログがちゃんと存在するテストケースを見てみるとこんな感じ。
エラーのスタックトレースが目立つように表示されているが、それ以外の通常のテスト実行中のログも時系列順に下の方に表示されている。フィルタリングもできるっぽい
さらにログ中にアタッチメントとしてファイルをつけることもできるようです。このサンプルではpdf, txt, htmlぐらいしか見つけられませんでしたがE2Eテストであれば画像や動画などを付けると重宝しそう。
自分でデータを送る
https://reportportal.io/installation で紹介されているようにテストフレームワーク毎に対応するパッケージを導入する方式のようです。昔にAllureを調査したときもこういう方式だった記憶がありますが、リッチなレポートツールは代償として密結合になりやすいですね。
今回はjsで有名なテストフレームワークであるjestで試してみました。まずはjest用のパッケージをインストールします。
次にデータを送信する先のReportPortalに接続するための設定を書く必要があります。今回はこんな感じの設定をjestの設定ファイルであるjest.config.jsに書きました。
READMEを見る限り、このあたりの設定は環境変数からも与えることができるようです。
[
"@reportportal/agent-js-jest",
{
"token": "xxxx-xxxx-xxxx-xxxx-xxxx",
"endpoint": " http://localhost:8080/api/v1",
"project": "superadmin_personal",
"launch": "Unittest",
"description": "CIAnalyzer ReportPortal",
"attributes": [
{
"key": "type",
"value": "unittest"
},
{
"value": "sandbox"
},
]
}
]
各項目の自分の理解
- token: ReportPortalのAPIを叩くためのユーザーのトークン
- endpoint: ReportPortalのURL
- project, launch: 後述
- attributes: launchに付与するメタデータ。key:valueの形式でも、単にvalueだけでもOK
token, endpoint, projectについてはユーザーのプロフィールページに表示されている情報を入れる必要があります。
projectとlaunchの関係
projectの中に複数のlaunchが含まれる関係です。というより、projectが一番上位の概念でありGithubにおけるOrganizationみたいな概念が近そう。
1つのProjectの中に複数のlaunchが同居可能で、ユーザーもProject毎に管理されるようです。
launchはGithubに例えるとリポジトリでしょうか。
実行してみる
tokenやprojectなどの設定にミスがなければjestでテストを実行したときに裏で自動的にReportPortalにデータが送信されます。
テストを実行するたびにReportPortalに情報が送られ、同じlaunch名の場合は実行するたびに#1, #2などが増えていくようです。
いくつかのテストをわざと失敗させていました。テスト一覧の画面ではFailしたテストに自動的に「To Investigate」のラベルが付くようです。
テストケースの名前をクリックすると詳細画面になります。jestのプラグインの場合はfailしたテストのエラーログを自動的に送ってくれるようです。デモのように通常のログも送信できるのかどうかは分かりませんでした。READMEにそれっぽい内容は無さそうでしたが調べれば方法があるのかもしれない？
このページ上部には同じテストケースでの過去の実行の結果が並んでおり、passなのかfailなのかがひと目で分かるように表示されています。このテストケースの場合は前回の#2からfailしているということが分かります。
どのあたりがAIなのか
ReportPortalのトップページには「AI-powered Test Automation Dashboard」と大層な宣伝文句が書いてあるのですが、実際はどうでしょうか？
このAIなどの説明はドキュメントのこのあたりのようです。ざっと読んでいきましょう。
新しいテストデータが入力されたとき、過去の同じfailしたテストケースに対して付与したdefect type、バグトラッキングシステムへのリンク、コメントなどを自動的に付けてくれるようです。
この自動分析にはElasticSearchが使われていて、テストデータに対してインデックスが付けられるのでそれを使っているようです。ElasticSearchは一般的には全文検索システムとして有名ですが、それを応用してるみたいです。
defect typeに"To investigate"が付いているか、エラーより高いログレベルのテストケースについて自動的に解析が行われます。
ElasticSearchは過去のエラーログに対してTF-IDF[1]で同一のfailなのかを判定しているようです。つまり、テストに失敗したときのエラーログがほぼ一致すればそれは過去にfailしたときの問題と一緒であると判定してくれるのだと思います。
このAuto-Analysisと呼ばれる設定をONにするにはprojectのsettingsでこのあたりの設定をすればよいようです。
Auto-Analysisを実際に試してみる
適当にわざとユニットテストでexpectの値を書き換えてfailにしたテストケースのDEFECT TYPEを"To Investigate"から"Automation Bug"に変更し、コメントも残してみました。
1つだけ情報を付与して再度テストを実行してみると、おおたしかに自動でさっき変更したDEFECT TYPEとコメントが自動的に反映されている！
自動で付けられたものはAuto-Analysisを意味するAAというラベルも付くようです。
が、異なるテストケースなのに全部が同じ判定をされるのは正しいのか・・・？expectの値を全部同じ値に変更して意図的にfailさせたのがよくなかったのかもしれない。TF-IDFで判定しているということはエラーログの中身がほぼ同一であれば一緒のものみなされそうですね。
今度は別のテストケースに対して意図的にテストコード内で例外を発生させてみて、DEFECT TYPEをこのように修正してみました
再びテストを実行すると、同じテストケースでDEFECT TYPEとコメントが自動的に入力されていました。最初に実験したときの「Expect variable is incorrect.」とコメントが異なるのでしっかりと別物として区別されているみたいですね。
これがランディングページに書いてあるようなAIとか機械学習か？🤔 と言われるとだいぶ疑問なのですが、実際に使う側としては似たようなものですかね。
今回はユニットテストで試したのでありがたみがないのですが、E2Eテストなどでたまに失敗したテストが前と同じ原因だったのか、違う原因だったのかをログから特定する職人芸をしなくてもレポートツール側で自動的にやってくれるのはかなり便利なのではないでしょうか。
まとめ
数時間試しただけなので自分も表面的なところしか分かっていないですが、なんとなく雰囲気は伝わったでしょうか？自分の印象のまとめはこんな感じです
向いてそうなユースケース
- 統合テストやE2Eテストなど複雑な自動テストを継続的に解析する必要がある
- 時間とか成功率などの時系列や統計情報を見たい
- Flakyなテストを特定したい
- 自動テストも含めて管理しているQAチーム
- 失敗した自動テストの原因をチームで共有したい
向いてなさそうなユースケース
- 短時間で終わるユニットテスト
- 基本的に100% Passするのが前提なため
- Failしたテストは実装者本人が直すべきなので、わざわざReportPortalのようなツールで管理するほどの必要性はなさそう
環境を用意する手間について
- デプロイ
- docker-composeかk8sのテンプレが用意されている
- AWSやGCPに社内サービスを構築した経験があればそんなに難しくはなさそう
- DBもElasticSearchもdockerで用意されているが、大規模に使われるようになったらそれぞれチューニングが必要になるかもしれない予感
- docker以外の方法も色々解説されている
- docker-composeかk8sのテンプレが用意されている
- アカウント管理
- 有名な認証基盤には対応してそう
- とはいえアカウント周りは雑に考えると後で大変なので、新しい社内用サービスを新たに立ち上げるぐらいの心づもりが必要そう
デプロイやアカウント管理の仕組みは結構しっかりしてそうだけど、サーバーの安定稼働とかバージョン上がったときのマイグレーションなどが発生するかと思うと有償サービスを使いたくなりそう。この手のツールはOSS版とは別に商用版が存在することが多いのですが、ReportPortalのトップページにもPrice情報が無いのでコミュニティのOSS版しか存在しないのかも？
会社内で誰かが既に構築していて管理もしてくれれば便利に使えそうですが、自分で構築・運用するところから始めて使いたいかと言われると・・・ちょっと面倒くさそう。
とはいえ大規模なE2Eテストを相手にする場合にはやはり便利そうです。そのようなテストを相手にしていてテストデータの管理に苦労しているような方は試してみる価値があるかなと思います。
-
TF-IDFは古典的な文書検索のための尺度のことです。簡単に説明すると、ドキュメントを単語などの単位に分解しどのドキュメントにも含まれているような一般的な単語は小さな重み、珍しい単語には大きな重みを付けて類似度を計算します。 ↩︎
Discussion