人気ブログランキング | 話題のタグを見る
実際にやったDBの自動テスト方法
■目的
ここでは実際にやった、Databaseの自動テストにまわりについて記述する。
OracleとSQLServerが対象になる。

■環境について
ベストは開発者毎のインスタンスを用意する。
インスタンスが1つしか用意できない場合はスキーマーを区切る。

最悪は全ての開発者が1つの環境を使うことである。
なぜ最悪かというと、ある開発者がおこなったテストが別の開発者に影響をあたえる可能性があるからだ。
これは非常にリスクが高い。

また、開発者毎のPCにデータベースをおくかどうかは議論が出るところである。
少人数で制御がきくなら個人の端末に環境を用意したほうが望ましい。
しかし、その制御が利かない場合、必ず古い環境で開発を続行し続けるという人間がでる。
・・・であれば、DB管理者が全ての開発者のDBを管理するというのが望ましいかもしれない。

このあたりは開発者の力量しだいだろう。開発者を信頼できない場合は、絶対にローカルにDBを作らせない。
ローカルにDBをつくるメリットをはるかに超える余計な問題を生む。

■環境の同期
開発者毎に環境を用意した場合、問題になるのはDBの同期である。
ストアドプロシージャーはスクリプトで管理する。
これを自動で適用する。

なお、ほぼ全てのDBはストアドプロシージャーはシステム用のテーブルに格納されているので、そこから取得できる。
つまり、全てのファンクションを抜き出してMD5で表現してしまえば、自分の環境が最新かどうかチェックするのは容易だ。

問題はテーブル構成などが変わった場合。
これは自動で行うのは危険だ。慎重に行うべきだ。

なお、勘違いしている人もいるが、列の追加とか削除も大抵スクリプトでできる。


■テストの方法
自動テストは3段階にわかれる。

1.テストデータの準備
2.テストの実行
3.結果の検証。

1は確実に行える。
やりかたとしては2通りあり、テーブルを空にしたあと、INSERTのスクリプトを投げてテストデータを作る方法。
次にフルバックアップをリストアする方法だ。
フルバックアップは管理者権限がないと厳しいのでスクリプトをなげる方法のほうがいい。
あと、生データだとどんなデータか確認できるが、バイナリだと厳しい。

2テストの実行は任意のストアドなり、プログラムを動かせばよい。
ADO経由すればWSH経由でストアドだろうがなんだろうが実行できる。


3結果の検証が一番困難だ。
テストの実行の内容によってここは2種類ある。
1つは参照系のテスト実行だ。
これは、期待値を外部ファイルなりに保持しておき、それと参照した内容をつき合わせて確認する。
この時、注意すべきはどのデータを取得するべきかだ。
可変の列は比較から除いたほうがいい。たとえば、更新日やユーザー名は変わる可能性があるので、比較に使用しない方が望ましい。
ちなみにORDERBYを聞かせたほうがテストはらくだ。テスト対象のファンクションが行の順番不動の場合、結果の検証はめんどくさい。

つぎに更新系のテストだ。
これは更新をおこなったあと、テーブルを参照して期待どおりに更新されているか確認する必要がある。
理想を言えばのテーブルの内容を抜き出して関係ないテーブルに影響がないことを確認すべきだろう。
しかし、これは時間がかかるのでやめておいたほうがいい。
更新ロックがかかっているかどうかの試験もやろうと思えばできる。
これは、スクリプトで指定のテーブルに更新ロックを掛けて待機する。
その間にテスト対象の処理を実行して例外がかえってくることを確認する。
テストがおわったらスクリプトを終了してやって、再度、実行して今度は正常に動作することを確認すればよい。
これは、更新ロックのチェックがNOWAITの場合のみできる。

これらは、WindowsであればWSHでADOを使用すればスクリプト言語で全て記述できるし、おおくのDBの場合、コマンドプロンプトから実行できるようなツールが提供されている。

なお、どの環境でも、動くテストを記述することが重要だ。
ユーザー名とかはテスト用のユーザを共通でつかったほうが楽だろう。

■DBの自動テストの問題
DBのテストの最大の問題は時間がかかることだ。
テストデータの準備、テストの実行などは通常の単体テストよりコストのかかる処理だ。
自動テストを入れている場合、このDBのテストを行うかどうかはオプションで指定できるようにしたほうがのぞましい。


あと自動化のつねとして、本番環境を飛ばさないような工夫が必要だ。
本番環境とテスト環境のログインユーザーなどが同じなどは本番データを吹き飛ばす可能性があって危険だ。
とくにテストデータをスクリプトで管理していると、それをまちがって本番に流しかねないリスクがある。
可能なら、テストデータのスクリプトの先頭に想定以外のDBではテストを中断するなどのロジックが必要かもしれない。


以上
by mima_ita | 2012-10-03 00:40 | テスト
<< PHP Security を読... PHPUnitのマニュアルを読んだ >>



実験ですお

by mima_ita
検索
カテゴリ
最新の記事
.NET4.5におけるasy..
at 2014-07-02 00:46
.NETでTwitterを検..
at 2014-06-29 00:49
Redmineのプラグインで..
at 2014-06-28 03:29
IO.popenのwrite..
at 2014-06-28 03:25
RedmineのWikiでU..
at 2014-06-28 03:16
以前の記事
最新のトラックバック
その他のジャンル
ブログパーツ