skillup

技術ブログ

ドキュメント作成 プログラミング全般

テスト環境のデータ作りに関して

投稿日:2021年12月11日 更新日:

単体テスト以降の環境ですとテストのデータを作ることがなかなか大変だと思います。マスタなどはそのままもらうこともあると思いますので、主にトランザクションデータについて。

以前もこのネタに関しては色々書いてますね。

ダミーデータの作り方 まとめ

テストデータを作るのが大変・・・といっても色々あると思いますが、以下のような点ですかね。

問題点

  • 仕様的に整合性のある正しい(生きた)データを作るのがそもそも大変
  • 上記の条件を満たしており、テストを網羅できる大量のデータを作るのがそもそも大変

対策全般

共通で必要になる対策

仕様がわかる人材、お客さん、あるいは近いフェーズの人のアドバイスによるデータ作成

個別対策その1プログラムをそのまま使う

登録系の処理を利用して、登録部分のモジュールを走らせ、テストデータを大量に入れる手法です。(一番確実で綺麗なデータが作れます)

メリット

  • 仕様的にデータの整合が取れる
  • 乱数、日付の範囲選択などカスタマイズされたお手軽なデータも自在に作れる
  • 大量データも自在に作成可能

デメリット

  • この条件を揃えることが難しい
    (プログラムで回せるように登録処理が書かれていることが前提になる、そもそも登録処理自体が他のベンダー開発担当でさわれない・・・など制約がないか)
  • 仕様をある程度理解していないとNG

個別対策その2 シーディング(Seeding)

データ投入用のプログラムを用意しておき、そこから入れる方法です。

テスト Seederで検索するとほとんどLaravelがでてきますね・・・

個別対策その1と3の中間という感じでしょうか。

メリット

  • プログラムを簡単に書ける(繰り返しや条件分岐など)
  • プログラムを最大限、活用できる(継承や抽象化など)
  • DB制約に気づけ、テーブル間の整合性にある程度気付ける(外部キーで落ちるなど)
  • 仕様が完全にわかっていなくても使える
  • 大量のデータなども自由自在

デメリット

  • 名前空間が分かれている場合、本体側のプログラムを使うことに制限がでてくる
  • 仕様をそれほど理解していなくてできる反面、あり得ないデータができてしまう
  • Modelのディフォルト値や可変な値を自由に切り替えられる仕組み(Laravelでいうfactory()->create())がないと面倒

個別対策その3 Excel

一般的によく使われてる方法だと思いますが、Excelで機械的に作る方法です。

メリット

  • 単純な乱数やマスタ参照なども作成が用意
  • ExcelがあればOKなのでほぼ環境に依存しない
  • マクロ、標準対策の関数を組むことで、ちょっとしたカスタマイズが可能
  • 大量データを作るのがある程度可能(万をこえるものはやめた方がよいかも)
  • 簡単なGUIの画面などをつくることも不可能ではない

デメリット

  • 生きたデータを作るのが難しい
    (アドバイザーがいないと仕様的に正しくても実ケースに即したデータ作りにくい)
  • ものすごい大量のデータを作ろうとするとファイルが重くなる
    (1テーブル1万程度が目安)
  • 関連テーブルが多くなると整合を取るのが難しい
  • GUIなど凝ったものを作ることは難しい

個別対策その4 ノーコード &ローコードアプリ

やったことないんですけどモック &模擬テストデータとして、ノーコードやローコードなどで簡単な画面とデータの関連を作る方法です。(やや妄想です。)

ローコード自体はkintoneってアプリで過去やったことあるんですが、その時の記憶を頼りにメリデメを挙げております。

メリット

  • 低コスト(インフラ、プログラミング環境構築不要)で、画面+簡単なデータ環境を作ることが用意
  • 関連テーブル数が多くなっても仕様的に正しいデータを作ることができる
  • モックレベルのものが簡単にできる
  • 環境をweb上に公開するので共有が楽(お客さんに共有しやすい)
  • ちょっとしたプログラムを組めることもある(kintoneの場合はJavaScript)

デメリット

  • ある程度の学習コストが必要(学習コストはExcel以上、プログラミング言語での環境構築以下という感じ)
  • カスタマイズに限界がある(カスタマイズ性はExcel以上、プログラミング言語での環境構築以下という感じ)
  • 画面から入力することになるので、大量のデータを作ることがそんなに簡単ではない

現実のプロジェクトではその2をベースに部分的にその1、3を活用するのがいいのでは・・・・と思っております。モックまで作らせてくれるケースはあまりないですかね?

なお、以前あげたwebサービス(人名とか)活用とかは利用できる範囲が狭いのでちょっと難しいですね・・・

記事書いたらkintoneやりたくなってきました・・・(汗)

-ドキュメント作成, プログラミング全般
-, ,

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

テスト分類について

一般的なテスト工程での分類や個人的に大事だと思うこと Contents1 全プロセス共通1.1 テストデータ作成バッチ1.2 ローカル、開発、ステージング、本番の分岐2 PT(プログラムテスト)、単体 …

no image

テストコードの書き方の注意点

テストコードを実装する様になって1年ぐらいたったのですが、そこできづいたことなどを。 Contents1 タイトルをわかりやすく2 値をなるべく具体的に書く3 疑似的な仕組みはなるべく避ける(例:Mo …

no image

調査スキルについて

本日は実務でとても大切な不具合の発見方法について 通常のプログラマとして仕事をしておりますと、通常の実装よりは不具合時の調査のほうが難しいことが多々あります。 もちろんものによるんですが、経験のある人 …

no image

命名規則について

リーダブルコードシリーズ第2段、名称について。 コードにおいては名称がとても大切で、正しい命名づけなどはなかなか難しいです。 以下に大事で重要だと思ったポイントを。 Contents1 具体的でわかり …

no image

業務フローの分解について

上流工程を担当するようになり、プロジェクトマネジメントや、要件定義、業務フロー分解などについて勉強しておいたほうがいいなーと思い、最近では読書をしております。 本日読んでわかりやすかった本は「はじめよ …

アーカイブ