Loading
|
@IT > @IT ソフトウェアテスト・ミーティング レポート > エンピレックス |
|
品質の向上はソフトのライフサイクル単位で考える
高品質なソフトウェアは高品質であるが故に、エンドユーザーはその優秀さに気付きにくい。利用する側にとっては、求めた機能が実現できて当たり前であり、ユーザビリティに優れていればいるほど何の違和感もなく使えてしまうからだ。逆に不具合があるシステムにこそ意識は向きがちだ。特にシステムのパフォーマンスについては、カットオーバー後に噴出するケースが多く、クレームが入る率も高い。機能要件だけは満たしていても、こうした非機能要件については、エンドユーザーも開発側も見落としがちになるからだ。特に膨大なアクセスが予想されるWebシステム開発において、この問題は深刻だ。 なぜこうした事態が起きるのか。エンピレックス エンタープライズ・ソリューション・グループ 副社長の山岡英明氏は「テスト工程に入った時、システム性能で不具合が発生しても対処できないという状況がある。そもそもシステム性能は、アーキテクチャ全体を設計するプロジェクトの初期段階でポテンシャルが決定されてしまうので、一般的なバグつぶしと異なり手戻りできないためだ」と警鐘を鳴らす。この場合の具体的な対処策としては、ハードウェアを増設するなどしか手段がない。もちろんエンドユーザー側にとって、その分コストがかさむことになる。「高品質なソフトウェア」という観点において、いかに最初のシステム設計が重要かが分かる。 ◆ 性能テスト時の問題発覚はもはや手遅れ そもそも性能テストは、単体テストが終わり、各モジュールが統合されたときに「統合テスト」の一環として扱われる場合が多い。その時点で性能面に問題が発生しても、もはや対処しようがないというのが現実だ。 山岡氏によれば、性能ボトルネックの7割がアプリケーションサーバやデータベースサーバで発生するという。両方ともシステムを支える根幹の部分であるため、現実問題として手戻りできないのだ。ということは、設計段階から性能テストを視野に置き、テスト計画を立案することが必要になる。設計したアーキテクチャに基づき、実際に負荷テストを実施できればなおよい。 開発の初期段階からシステム性能を加味してアーキテクチャを設計するには、ユーザー側にも「性能要件をあらかじめ決定しておく」という姿勢が望まれる。とはいえ、要件定義の初期段階でそこまで決められるユーザーは少ない。山岡氏は「プロジェクトの初期段階で性能テスト計画をきっちり立てるのは難しいにしても、最低限決めておくべき項目が3つある」という。1つは性能テストの合否判断基準、次にテスト箇所の特定、最後にテスト期間という3つの項目だ。 これを決めた上で、統合テストだけではなく、単体レベルにおいても性能テストを行うことが望ましい。このレベルであればプログラム面での性能問題を解消することができ、品質改善の余地があるからだ。こうすることで総合テストにおける性能テストは、パフォーマンス最適化の一環として扱えるようになる。この結果はその後の保守・運用フェイズにも引き継ぐことができるので、エンドユーザーは常に安定したシステムの上で業務をこなせるようになる。 ◆ 開発後もソフトウェアの品質を向上し続けるには そもそも性能テストとは、パフォーマンスという観点から、システムの全体的な品質を検証するものだ。山岡氏は「アーキテクチャ策定の段階でテスト計画を立て、開発工程の中でも機能テストと負荷テストを実施すべき」と提言する。モジュールごとに機能とパフォーマンスをチェックし、フィードバックをかけることで、後工程で発生するリスクを低減。これを実施することで、開発を進める中でシステムの質を向上させることができる。単体テスト以降においては、システム全体の中で性能をチェックし、最適化を図っていけばよい。その結果を保守・運用フェイズで参照し、経常的に性能監視と最適化を重ねていけば、システムの品質も指数関数的に上昇していくという。 「エンピレックスが提案するソリューションは、開発工程から運用にいたるプロセスの中で品質向上を実現するもの。具体的には、Webシステムの負荷テストツール『e-Load』とWebの機能テストを実施する『e-Tester』、自動監視ツール『OneSight』を組み合わせ、ソフトウェアのライフサイクル全体においてシステムの品質を向上できる」(山岡氏)。 続いて山岡氏は、実際に関わった事例を紹介しながら、性能テストを軽視しているユーザーが多いことも指摘。優秀な開発パートナー企業がバックアップに付けばいいが、そうでない場合、カットオーバー後に不具合が生じてしまう。こうした事態を避けるためにも、早期の性能テストでリスクをつぶしておくことが重要だ。そこで有効なのがツールの活用だ、と山岡氏はいう。ツールにテストを任せることにより、人的リソースを開発に割けるようになるほか、テスト全体の期間を短縮できるからだ。 ◆ 有償ツールとフリーのツールはどちらが得か? 一口にツールといってもいろいろある。特に最近は、オープンソースの負荷テストツールなどがWebサイトから簡単にダウンロードできるようになっており、「テストツールは高価」という概念をくつがえしつつある。 山岡氏はツールを選ぶ基準として、「多様なスクリプト編集機能を備えているか、正確な負荷がかけられるか、テスト結果のデータをきちんと分析できるか」という3点を挙げる。ところが、フリーのテストツールの多くは、なかなかこの条件を満たすものが見当たらないという。 例えば、多数のプログラムコンポーネントが絡み合った複雑なWebシステムの検証には、フリーのツールは適用できない。複雑な動作を再現できるような機能を備えていないからだ。そして最大の問題は、取得する結果データの数が圧倒的に少ない点にある。「そもそもテストは一度やったら終わりというわけではなく、その結果を元に改善を続けていくために実施すべきもの。長期的な視点に立てば、フリーのテストツールだと逆にコストがかさむことが分かる」と指摘し、実際にある案件で試算した結果を表示した。それによると、同社のe-LoadとフリーのWeb負荷テストツールを比較した場合、3年後には100万円近い差が発生するという。 このコストの差は人件費。フリーのツールの場合、習熟するのに時間がかかる上、サポート体制も期待できないという状況がある。一方、市販製品を使えばトレーニングやサポートも充実しているほか、実際の利用シーンと同じ動作、同じ負荷をシステムに与えることで、正確なテストデータが収集できる。さらにこの結果を後工程にフィードバックすることにより、継続的に品質を高めていくことができるわけだ。 エンピレックスの製品なら、フリーのテストツールが検出できない問題箇所を特定できる。例えば、アプリケーションサーバをデータベースまでアクセスし 動的にコンテンツが変わるアプリケーションにおいて、誤ったコンテンツが返ってきた場合を想定してみよう。この場合、ブラウザがWebサーバから受け取るインターネットステータスコードは正常となっているため、 リターンコードだけで判定すると「何の問題もなかった」と判断してしまう。ところがOneSightであれば、バックエンドのエラーも検知。このように、一般のツールでは“見えない”細かな点もチェックできるのが特長だ。 最後に山岡氏は、e-Load、e-Test、OneSightなど同社のソリューション1つひとつについて、時折り事例をはさみながら特長を紹介。「特に性能と機能は、どちらかを立てればどちらかが立たず、と両立させるのが非常に難しい。しかし開発から運用まで、一気通貫でつなげられるツールを適用すれば、この2つを両立できるので、品質向上に大きく貢献できる」と語った。 主催:アイティメディア株式会社 協賛各社(順不同):マイクロソフト株式会社、 エンピレックス株式会社、 テクマトリックス株式会社、 マーキュリー・インタラクティブ・ジャパン株式会社 株式会社ベリサーブ 掲載内容有効期限:2005年7月24日 |
|