今のテストのパラダイム(?)だと、実際のデータ量でテストするシステムテストって、単体テスト、結合テストのあと、もう、リリースちょっと前にやりますよね。
これって、問題ないっすか?
たとえば、在庫を求めるプログラムを作ったとします。
そのプログラムが仮に、
在庫=期首在庫数 + 期首からの在庫の入庫数 - 期首からの在庫の出庫数
から、在庫数を求めたとします
(そんなばか、いねーよ!と思うかも知んないけど、いたとする)。
これは、在庫の基本公式であり、何一つ間違いございません!
簿記の教科書にも、このように書いてあります。
その上、単体テスト、結合テストでも動きます。
でも、仮にですよ、拠点が10箇所くらいあって、在庫の入庫回数が、1時間に1拠点10回、出庫回数が、1拠点1時間に15回あって、それを本部で集中管理!
複数端末で参照したり、入出庫するため、排他制御が必要で、さらに、入庫、出庫の数を狂わさないため、入庫テーブル、出庫テーブルにテーブルロックかけたら。。。
集中管理するから、1時間の入出庫アクセスは(10+15)*10=250回
3600(秒=1時間)/ 250=約14秒に1回、入出庫だけでもくる
これに、在庫検索が加わる。
在庫検索は、この会社が8時間営業したとして、200営業日めに検索をかけると、
8*250*200=40万
1アイテムの在庫検索に40万件を検索することになる。10アイテム検索すると、400万件、これのSUMを取る。
実際にこの状態で、在庫管理を複数端末で動かしたら、ロック待ちで、動かない。。。かもしんない!!
つーことで、システムテストで問題発生する。
で、じゃあ、問題発生したとき、どうするか?
ロジックを直す暇ないですよね、システムテストの段階でリリース直前だし、
もし、このような状況にならないために、ロジックを直す場合、
式をこのように変形します
期首在庫数=現在在庫数-期首からの在庫の入庫数+期首からの在庫の出庫数
プログラム的には、在庫テーブルに現在の在庫数を持たせておいて、
現在在庫数は、そのテーブルの数量を出す。
入出庫のときは、そのテーブルのレコードを修正する。
→このとき、そのレコードをレコードロックすればよい。
ある日の在庫(過去の在庫)を見たいときは、
現在在庫数から入庫数を引き、出庫数を足す
(=期首の日まで戻れば、期首在庫はわかる)
でも、この修正って、(在庫)テーブル修正(あるいは追加)っすよ!
そんな短時間ではできないっす。
まあ、ここまでおばかなシステム作るやつは、いないと思うけど
(いないよねえ ^^;)、こんなかんじで、システムテストで、データベースのパフォーマンスが出ないときって、困りますよねえ。
ロジック修正は間に合わないし、ロジックを直さないと、出来ることって限られてるし。。
うーん、テストのパラダイムを変えるべき?
え、ウィリアムのいたずらのまわりだけだって!?
そんなおばかな問題について考えてるのは!って。。。
そうかもしれない。。。
(つーか、そんなような話を聞いたとき、ウィリアムのいたずらは、開口一番、「それって、プログラム書いてるときに、気づけよ!」って言ってしまったが ^^;)