主にテストの話です。
テストの工数の肥大化
開発の効率化が進む中で、開発プロセスの効率化、開発資産の再利用、標準化が求められています。
テストの工数は増加し続けています。
１％のプログラムの修正でも、テストは１００％行う必要があります。
テスト工数は開発初期楮段階の何十倍にもなります。
テストを省くと、後でトラブルとなり、システムがダウンしたり損失が発生します。
開発は短縮できたがテストは短縮できず複雑になって来ています。
この状態が続くとソフトウエア業界が破綻する流れになっています。
マネージャーはテストの管理をしていますか？と聞くと．．．
ほとんどテストの管理をしていない。トータルでテストの品質管理をしていない。各部署、部下を信頼しているので、各部署でテストを行っていて、マネージャーが管理をしていないのが現状。
USの企業は管理ありき。
マネジメント層は、現場が煩雑となってでも管理をやらせます。
このままではグローバルの企業に負けてしまう。
開発環境に日本発が少ない。Rubyなどあるにはあるが。
１．予防コスト
２．評価コスト、自動化によるコスト削減。自動化しないとコスト破綻する。
１００の工数がかかった。マイナーの工数が５かかった。直したところが他の工数に影響を与えている可能性が有るので、テスト数は最初と変わらない。例）金融系のシステムなど。
JaSSTソフトウェアテストシンポジウムというイベントが有りますが、驚くほど認知度が低いそうです。
ニッチな市場なのでみんなが投資しないです。
テストのところを自動化して行くことを念頭に開発をする。
性能障害はなぜ恐ろしいか
どうして再現するのか、再現することが難しい。１０回に１回くらいでる。実運用が難しい。１００％再現が出れば対応ができます。
負荷テストの重要性
ボトルネックを突き止める。
事前見積もりと実際の性能が異なる。不具合が出し切れていない。テストをすると設計の数字が出てこない例が幾つもあったそうです。
単体レベルのテストは一人がアクセスできるレベル、現在は多数の人がアクセスして負荷がかかるのを前提としてテストをする。これが負荷テスト。
ソフトウエアは見た目がわからない、見えない。だから性能がわかりにくくなっている。
１から作る、９作ってあって１を加えてその１がどの程度の負荷がかかるのかがわかる。
負荷テストツールが出回っています。５つくらいの有償ツールが出ています。オープンソースのJMeterがあります。
負荷テストは期間となる１０％でかまわない。このテストはＷｅｂシステムのすべてにする必要はない。
テストをするとボトルネックがでる。ページの応答時間、負荷をかけて行く、ボトルネックがあると表示時間が遅くなる。スループレットはページビューが増えると上がり続けボトルネックの時点で横ばいとなります。
負荷試験の結果はＡＰサーバーかＤＢサーバーが７０％の原因となる。
９９％は負荷検証をすればボトルネックがある。
キーポイント
クライアント
マクロからミクロへ視点を移動する流れ。
機能レベルの単体テストを行う、負荷テストは最後に行う。２分かかる処理を１０秒にしたいとクライアントから要望が有れば開発か設計（アーキテクチャ）までさかのぼらなければできないので実質的には不可能。
作った側がミスを認めるのは難しい。そのためにはテスターがその場で言う必要があります。
Developers Summit 2009の備忘録として、出席をしたセミナーを記録にとどめておきます。セミナーの写真撮影が禁止でしたので文字だけの備忘録となっています。
mizunuma 2月 19th, 2009
Posted In: Developers Summit 2009