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