こちらの投稿にも書かれているように、弊社のQAチームはSeleniumを使った自動テストを作っています。QAチームの得意技であるSeleniumでテストできない機能というのは、なかなか自動テストとして組み込まれにくくなってしまいます。
今回は一例としてAPI機能を取り上げます。
SHANON MARKETING PLATFORM APIを使うことで、XMLメッセージの送受信によりSHANON MARKETING PLATFORM のセミナー申し込みやリード情報の登録・参照が可能になり、連携アプリケーションを開発することが可能になります。
弊社のAPI機能はRESTなので、基本的にはURIを指定すればいいのですが、認証情報などを付加する必要があります。そのため開発された当初は、開発者自身が使っていたPerlスクリプトを使用して、そのパラメータを書き換えて動かして…という形でテストされていました。
これでは自動テストに組み込めないので、Seleniumでテストを書けるようなツールを作ることになりました。これはもう3年近く前の話です。そんな前に作っていたツールではあるのですが、当初はなかなか自動テストとして反映されていませんでした。
徐々にQAチームの意見を反映させていったことで、この1年ほどでAPIの自動テストの量がものすごく増えました。とにかく使われるようになってくれてよかったです。
■ツールにバグが入り込まないように
当初のコンセプトとして、あまり作り込んでしまうとバグが出たときにAPIのバグなのかツールのバグなのかわからないため、なるべくシンプルなツールにしたい、ということがありました。そのため内部にデータを蓄積することもなく、入力フォームもシンプルなものになりました。
APIにはGET/PUT/POST/DELETEの4つのメソッドがありますが、このツールではGET(取得),DELETE(削除)メソッドにはパラメータの入力画面がありませんでした(DELETEは今もありませんが)。検索条件やIDの指定は、APIのインタフェースそのままに、URLパラメータとして search_key, search_operator, search_value といったパラメータを記述して使うのです。
画像1: GETパラメータの指定をURLで行う
ツール側では渡されたパラメータを元にシグニチャ等を生成してくっつけることしかせずに、APIサーバーに送信します。レスポンスもXMLのまま加工せずに画面上に表示します。
PUT(更新)/POST(作成)については、URIに対して更新/生成データを送信する必要があります。ツールを作り込まないというコンセプトからは外れてしまいますが、このデータ作成のために入力フォームを用意しました。ただ当時は項目名などの情報をツール側が持っていたため、API機能を拡張するたびにツールを拡張しなければならないというのが難点でした。
このようにできるだけシンプルなインタフェースを用意していたのですが、どうもQAチームにとってはテストが作りにくいようで、なかなか自動テストのカバー範囲が広がりません。
そこで要望として言われたのが、
- GETのパラメータを指定しにくいのを何とかしてほしい
- WSDLから項目を取得するようにしてほしい（API機能を拡張するたびツールを拡張しなきゃいけないのはイヤ）
- レスポンスのXMLデータをファイルとしてダウンロードしたい
- WSDLの定義と合っていないときは警告を出してほしい
WSDLはRESTに対応したWSDL2.0に準拠したものを使用しています。APIを利用したサービスを開発する際にはこれが仕様書として使用されるので、情報が正しいかどうかも重要なポイントなのです。
だんだんと作り込まないというコンセプトだけでは成り立たなくなってきました。シンプルに要望を満たすのは難しいものです。
結論を先に言ってしまうと、自動テストが目的だったらせいぜい上記のようなことが必要だということです。
その上で、正常系だけでなく異常系もテストできるように自由にパラメータを指定でき、もしバグがあったときにツールのバグかAPIのバグか見分けられることが必要なわけです。
■パラメータを指定しやすいように ＆ WSDLから項目を取得するように
URLパラメータを長々と自分で書かなくてはいけないのでは、Seleniumでやる意味が薄れるのです。SeleniumでURLを開くときに指定する値として、テストしたいパラメータをつけたURLを書かなければいけないわけです。このURLを書くのが疲れます。
そこで、WSDLから項目定義を取得し、その情報を元に入力フォームを作成するようにしました。使用可能なサービス名をプルダウンで選択し、サービスが選択されたら検索・順序として指定可能な項目をWSDLから取得してプルダウンとして表示します。WSDLに記述されていない項目もテストできるよう、フリー入力のパラメータも指定できるようにしました。
使う側から見れば、こちらのほうが使いやすいのは一目瞭然です。
画像3: GETリクエスト生成フォーム
私自身は開発チームの者ですが、実際にAPI機能の修正等を行うときにはこのツールを使っています。前までのURLパラメータとしてパラメータを書く機能も残してあるのですが、おそらく新しくQAチームに入る人は使い方を知らないでしょう。自分自身も今はほとんど使っていません。
PUT/POSTの入力フォームも、WSDLから取得した情報で作成するようにしました。また、項目自体を送るか送らないかで動作が変わるので、この違いもテストできるように、データとして送る項目を選べるようにしました。
これでテストしたいバージョンのWSDLを使えば、そのバージョンのテストができるようになりました。また、API機能を拡張/修正するたびにツールを修正する手間が省けました。
画像4: POSTデータ生成フォーム
これらの改修でツール側が複雑になってしまったのが残念なところですが、QAチームにとって非常に重要なことだったのだと思います。
■レスポンスをファイルとしてダウンロードしたい
QAチームとしてはAPI機能のレスポンスが大事です。その内容が合ってるかどうかを見なければならないので、画面上にXMLで表示されても困るわけです。
正しい結果が返ってきているかどうかを確認するのは、なかなか難しいことです。もちろんサーバー側のデータを固定にしておいて、固定の結果が返ってきているかを見れば、データが合っているかは確認できるでしょう。しかしさらに、レスポンスデータの項目名や階層などが正しいかどうかも確認しなくてはいけません。
そこでQAチームはファイルの差分を見るようにしたそうです。最初の1回は正しいレスポンスであることを確認する必要がありますが、その後は結果の差分だけ確認すればいいのです。差分を確認するツールは既にQAチームが持っていたので、XMLで表示していたものをファイルとして出力できればよいとのことでした。
ここでいくつかポイントがありました。
- ファイル名を入力するポップアップが出てしまうのは Seleniumで扱いにくいからダメ
- 勝手にファイル名をつけて自動で保存すると、どのテストケースとどの結果が対応しているのかわからなくなるのでダメ
■バリデーションしてほしい
取得したレスポンスの形式が間違っていたら警告メッセージを出すようにしました。レスポンスの項目が間違っていることもありますし、WSDLが間違っていることもあります。
問題なのは、レスポンスの項目が足りていないときに警告メッセージが出ないことでしょうか。形式が合っているかどうかを見ているだけなので、定義上存在しないこともある項目の場合、存在していないことが正しいのか、バグで欠けているのかわかりません。これを検出することができないという問題は未だ残っています。
ツールとしてはまだ足りない部分もあると思いますが、今のところは自動テストをどんどん作ってもらえているようです。
個人的にはAPIを開発したときの動作確認にも使うので、確認まで自動でやってくれないかなーとか思っています。検索条件・並び変えに指定できるパラメータ全てを複数組み合わせることを考えると、全パターンというのは膨大な数です。
実行する数は全パターンでもその中から適当な方法で抽出してもよいと思っていますが、結果として得られたデータが正しいかどうかの確認まで自動でできないものだろうか…と思うのです。サーバー側のデータをうまく作っておけばできそうな気もするのですが、シンプルで間違いのない方法にはならなさそうですし、うまいやり方というのはあるのでしょうか？
以上、Seleniumでテストするためのテスト補助ツールを作ったときの経験談でした。世の中のAPIサービスはどのように自動テストが組まれているんでしょうね。
.
