テストデータを作成する方法は、以下４つくらいが考えられるでしょう
- GUI操作によっての作成
- API利用しての作成
- DB操作での作成
- API + DB操作での作成(上記2,3の組み合わせだが、一応一つの種類と列挙する)
それぞれの特徴
GUI操作によっての作成
実際にシステムのGUI画面を操作して、テストデータを作成する手法
メリット：
- 一番直感的で、簡単且つシンプル
- 本当の利用プロセスと同じなので、本番利用と同じ正しさでデータが作れる
デメリット
-
テストデータの作成効率が低い
- 一回(一連)のGUI操作で、一つ(１セット)のデータしか作れない
- GUI操作自体が時間かかる
-
ツール化し難い
- GUI操作でデータを作成しようとすることは、GUI自体への自動化テストケース作成することに相当するので、コストと効率とともに テストデータ作成のいい選択とはいい難い
-
安定性が低い
- データ作成する部分のGUI処理の安定性に依存するため、関連ページの微調整でもテストデータ作成の失敗につながる
-
余計な依存関係が生じる
例： [ログイン機能]をテストテスト対象とする場合：
そのテストデータの[ログインユーザー]をGUIで作成するために、[登録機能]が問題なく動くことが前提となってしまう
以上によって、GUI操作でテストデータ作成することは、止む得ないケースじゃなければ、あんまりいい方法とは言えない
API利用しての作成
必要なAPI群を直接コールして、テストデータの作成する手法
メリット：
- テストデータの作成効率が高い(時間のかかるGUI操作がスキップされたため)
- ツール化しやすい(APIをラッピングして関数化することは、GUIの方より格段に楽)
- データ作成する機能の(GUIではなく)APIを依存するので、GUIを依存するより安定性が高い
デメリット：
- API利用だけで作れないデータがある
- ケースのよっては、複数のAPIの順次利用や、API間のデータ受け渡しなどが必要になり、複雑な操作が必要な場面が存在する
DB操作での作成
直接DBへのCRUD操作によってのテストデータ作成する手法
メリット：
- 柔軟性が高い
- この中で、データ作成のスピードが一番高い
デメリット：
- データ作成用sqlスクリプトの準備・作成コストが高い
- 整合性の担保が難しい。複数テーブル・操作が必要なうちに、どれか漏れたとしても、すぐに気づかないままのケースがある
- データ作成の該当する業務ロジックが変えれば、データ作成用sqlスクリプトもそれに合わせてメンテしないといけない
API + DB操作での作成
APIの利用とDB直接操作と組み合わせてのデータ作成手法
例： アルバムを作成するAPI createAlbum があるんですが、その アルバムの メイン言語を設定する処理が別の複雑なAPIにあるとして、指定したメイン言語のアルバムを作成することが目的の場合:
createAlbum(API利用) + アルバムのメイン言語を更新するsql文(DB操作) がいい選択肢かもしれない
纏め
- [GUI操作によっての作成]はシンプルで事前準備も要らず、特に手動テストには向いているでしょう
- [API + DB操作での作成]は、API利用法のメンテしやすいなどのメリットを利用しながら、DB操作法の柔軟性を取り入れたことで、特に自動テストでは一般的に利用していいでしょう
この記事は <<[如何准备测试数据？](http://gk.link/a/10WJ8) >> の読書メモ*
また、弊社は現在バックエンドエンドエンジニアを募集しておりますので、音楽好きな、データ/BizDev領域にも興味があるという方は是非ご連絡いただければと思います！