“テスト自動化”で進む、システム/データベース・テストのさらなる効率化──「JaSST’13 Tokyo」レポート

2013年1月30日~31日の2日間にわたり、“ソフトウェア・テスト”をテーマにした年次シンポジウム「ソフトウェアテストシンポジウム2013 東京(通称:JaSST’13 Tokyo) 」が都内で開催された。企業活動においてITシステムが果たす役割が広がるのに伴い、性能も含めたITシステムの品質確保はますます重要な課題となっている。ここでは、JaSST’13 Tokyo の初日に行われた講演の中から、近年、多くの関心を集める“テスト自動化”を巡る話題、そして企業システムの中核を成すデータベースの性能テストに関する話題を紹介する。(編集部)

ソフトウェア・テストの“生き字引”、ドロシー・グラハム氏が講演

 企業活動を支えるシステムの数が年々増加し、その規模や複雑性が増す中で、システムの品質を確保するためのソフトウェア・テストをいかに効率化するかが悩ましい課題となっている。そうした事情から関心が高まっているのが、ツールを活用し、テストを効率的かつ確実に実施するための“テスト自動化”だ。

ソフトウェア・テスト・コンサルトのドロシー・グラハム氏
 JaSST’13 Tokyo初日の基調講演には、書籍『ソフトウェアテストの基礎:ISTQBシラバス準拠』や『ソフトウェアインスペクション』の著者として知られるソフトウェア・テスト・コンサルタントのドロシー・グラハム氏が登壇。「ソフトウェアテストのチャレンジ」と題した講演の中で、ソフトウェア・テストを効果的に実践するためのアドバイスとともに、テスト自動化の今後についての展望を語った。

 ソフトウェア・テストの国際委員会「ISEB Software Testing Board」の設立に尽力し、約40年間にわたってソフトウェア・テストの分野をリードしてきたグラハム氏は講演の冒頭、「過去の状況と比べれば、今日ではソフトウェア・テストの重要性に対する人々の認識は大きく高まっている」と現状を評価。ただし、「業界を見渡すと、以前と変わったところもあれば、まだ変わっておらず改善が必要なところもある」として、次の点を挙げた。

  • ソフトウェア・テストで何ができて、何ができないのか」といったことに対する理解がまだ広く浸透していない
  • 教育機関には、ソフトウェア・テストのカリキュラムを用意していないところがまだ多い
  • 「すべての問題はツールさえ使えば解決できる」という“迷信”がいまだに広く信じられている
  • ソフトウェア・テストの世界に新たに入ってきた方々のための“知の集積”がまだ不足している

 これらの課題の解消に向け、引き続き業界を挙げて取り組む必要性を示唆したうえで、グラハム氏はソフトウェア・テストに関する実践的なアドバイスをいくつか披露した。その1つは、ソフトウェア・テストの価値を測定する指標「DDP(Defect Detection Percentage:欠陥検出率)」だ。

 DDPとは、ソフトウェアのテストから保守における各フェーズでどの程度の欠陥が見つかったのかを示す指標であり、次の数式によって導かれる。

「各フェーズで見つかった欠陥の数」/「全フェーズで見つかった欠陥の数」


 例えば、テスト・フェーズで150個の欠陥が見つかり、リリース後に50個の欠陥が見つかったすれば、テスト・フェーズにおけるDDPは150/200=75%となる。当然、リリースから期間を経るごとに見つかる欠陥の数は増えるので、DDPの値は徐々に下がっていく。また、リリース直後の欠陥が見つかっていない状況では100%(上の例なら、150/150=100%)となるが、「このような使い方には意味がない」とグラハム氏は注意する。

 「DDPは、保守フェーズまで含めた一定期間の中で、『各フェーズにおけるテストの効果(価値)に関する傾向をつかむための指標』として有効。短い期間を対象にしたり、個々のテスト担当者の業績を測る指標として使ったりするものではない」(グラハム氏)

 また、グラハム氏はテスト自動化に関してよく見られる“誤解”も指摘した。

 グラハム氏があるテスト・カンファレンスに参加した際、企業でテスト担当マネジャーを勤める人物から、「これまで回帰テストを自動化して実行してきたが、もうやめようと考えている」と打ち明けられた。グラハム氏がその理由を尋ねると、「バグが見つからないからだ」という答えが返ってきたという。「ここで自動化を批判するのは間違いだ」とグラハム氏は憤る。

 「テストの目的は欠陥を見つけることだが、自動化によって欠陥が見つかるわけではない。テストの方法が適切であれば、自動でやっても、手動でやっても、欠陥は見つかるだろう」(グラハム氏)

 自動化はテストを効率的に行うための方法であり、欠陥が見つからない理由を自動化に求めるのは誤りだというわけだ。そのうえでグラハム氏は、欠陥を見つけやすいテスト方法として、テスト結果に応じて次のテストの内容を絞り込みながらテストを繰り返す探索型テストを挙げた。

 最後にグラハム氏は、ソフトウェア・テストを巡る今後の展望を語る中で、テスト自動化に関して次のような見解を示した。

 「今後、継続的インテグレーションにおける単体テストや回帰テストなど、さまざまな領域でさらなる自動化が進むだろう。テストをより効率化するために、“スクリプトレス化”など、より高いレベルでの自動化も必要になるはずだ」

テスト自動化は必然。成功のためのポイントは?

 グラハム氏の講演に続いては、テスト自動化のための知識体系「TABOK(Test Automation Body of Knowledge)」の国内現場における普及および適用に取り組む「テスト自動化研究会」のメンバーらにより、「なれる! Test Automator!~テスト自動化を成功に導く3つの真実~」と題したセッションが実施された。

 日ごろ、開発現場でテスト自動化の導入支援に携わるテスト自動化研究会のメンバーらも、グラハム氏と同様、「自動化ツールを“万能薬”と誤解する風潮がある」と戒める。スケジュールが遅延したプロジェクトで、工期短縮のために自動化ツールを導入したが、無分別に導入したためにテスト・スクリプトの作成などでかえって作業工数が増えたりしてしまうケースが実際に見られるという。そうした実情を踏まえ、研究会メンバーの本山絢子氏は、テスト自動化のポイントを次のようにアドバイスした。

 「自動化ツールの効果を得るには、ツールの特性を理解したうえで、効果の出やすい部分に対して使うこと。つまり、スコープを見極めたうえで、ROI(投資対効果)を意識して使うことが肝要」(本山絢子氏)

 また、セッション後半では、テスト自動化研究会メンバーのほか、テスト・ツール・ベンダーの立場から日本オラクルの中島良樹氏(製品戦略統括本部 プリンシパルセールスコンサルタント)らも加わり、パネル・ディスカッションが行われた。お題の1つは、「これから求められるテスト自動化エンジニア(Test Automator)像とは?」である。

 「これからのテスト自動化エンジニアに求められるのは、(A)プログラミング技術か、それとも(B)テスト設計技術か?」という問いについて、セッション聴講者の見解を挙手で求めたところ、多くの聴講者は(B)のテスト設計技術を推した。これに対して中島氏は、次のようにプログラミング技術の重要性を唱えた。

パネル・ディスカッションに登壇した日本オラクル 製品戦略統括本部 プリンシパルセールスコンサルタントの中島良樹氏
  「テスト・ツールをうまく使いこなすためには、ツールが相手にするものについてよく知ることが重要。つまり、システムがどうなっているのかを知らなければならない。データベースのテストであれば、SQLの仕組みを知ることは非常に有効だ」(中島氏)

 さらに中島氏は、「今後、生まれてくるテスト自動化エンジニアに向けたメッセージ」として、テスト・ツールを活用するユーザーらの声を紹介しながら、「プロジェクトを成功させるだけでなく、個々のエンジニアも幸せにできることを、ツール・ベンダーの者としていつも誇らしく感じている」と語った。 それでは、テスト・ツールの浸透により、やがてテストが100%自動化された世界では、テスト・マネジャーは何をするのだろうか?

 モデレーターを務めた松木晋祐氏によれば、現在の米国などは「ツールによってテストを自動化するのが当たり前の世界。ツールを活用できていない非効率な企業は、テスト・エンジニアを集めることすらままならなくなっている」という状況だ。中島氏は、「そうした世界では、変更管理やテスト計画の管理、テストをやりやすくする(品質保証の)ための環境作り、ソフトウェア開発にかかわる各部門へのフィードバックなどが重要な仕事になっている」と説明した。

 他の産業分野と同様、ソフトウェア・テストの世界でも、自動化(機械化)の進展により、エンジニアには、よりハイレベルな役割が求められるようになりそうだ。

データベースの性能問題で現場が抱える課題と、その解決アプローチは?

 テスト自動化の波は、データベース・テストの分野にも及んでいる。このデータベース・テストに関し、特に性能テストにフォーカスして現場の実情や課題、効果的なテストの実践に向けたアドバイスを贈ったのは、セッション「コンサルタントが語るDBシステムのテストの現場」に登壇した日本オラクルの大塚信男氏(テクノロジーソリューションコンサルティング統括本部 マネージングプリンシパルコンサルタント)である。

日本オラクル テクノロジーソリューションコンサルティング統括本部 マネージングプリンシパルコンサルタントの大塚信男氏
 今日、企業システムの中核を担うデータベースが果たす役割は極めて大きく、その性能設計やサイジングを誤った場合は、システム全体の重大なボトルネックとなる。さらに、それが元でシステムが停止すれば、システムを利用して遂行される業務や顧客サービスも停止してしまう。企業としては、データベースの性能設計ミスや性能障害は何としても避けたい事態だ。そのためにも、性能テストを適切かつ十分に行う必要性が高まっている。

  それでは、そもそもデータベースの性能テストには、どのような種類のものがあり、それぞれ何をテストするのだろうか? 以下に改めて整理しておこう。

  • 単体テスト:個々のSQL文などに対し、単体での応答性能要件への適合性をテストする
  • 負荷テスト:リクエストの同時実行性要件、スループット要件、サーバのキャパシティ要件への適合性をテストする
  • 限界負荷テスト:ユーザー数やデータ量を増やしながら、どこまでの負荷に耐えられるのかをテストする。このテストにより、システムの最大キャパシティと、「限界状態では何が起きるのか」を事前に把握し、それも踏まえてシステムの限界性能を決定する
  • 長期走行テスト:負荷テストを長期間(例えば、運用要件で定めたサーバの定期停止間隔に相当する期間)実行し、稼働状況の安定性(性能の安定性、リソース使用量の安定性)を確認する。このテストにより、長時間稼働させた場合のスループットの低下やメモリ・リークなどの問題点を発見する

よく見られるデータベース・テストの失敗例

 以上のようなテストを十分に行って初めて、データベースの安定稼働が実現されるが、逆にテストが不十分な場合には問題が生じることがある。大塚氏は、よく見られる問題として、次のようなものを挙げた。


  • 負荷試験の失敗1
 まず多いのは、テストの実施方法に不備があり、それによって正確なテストが行えなかったために問題が生じるケースだ。

 例えば、負荷試験でよく見られる問題の1つに、データ・アクセスが局所化されたテスト・シナリオを使ったために、的確なテストを行えなかったといったものがある。「ユーザーAが、自分の発注明細100件を参照する」という処理を単純に増幅(秒間100回に増やすなど)してテストを行うようなケースだ。

 データベースは、1度アクセスされたデータは、2度目以降のアクセスに備えてキャッシュ上に保持する。100件程度のデータなら、そのすべてがキャッシュ上に保持されるだろう。そのため、上のようなケースでは、アクセスするデータがすべてキャッシュ・ヒットし、テスト環境では非常に高い性能が得られるはずだ。

 しかし、本番環境では、テスト時よりもユーザー数が増え、アクセスされるデータも広範囲にわたるのが普通である。そのため、すべてのアクセスがキャッシュ・ヒットするとは限らず、ディスク・アクセスはテスト時に比べて増大する。場合によっては、これによるI/Oがボトルネックとなり、性能が劣化する可能性がある。

 また、近年は数10GB~100GB規模の共有メモリを搭載するデータベース・サーバも珍しくないが、大きな共有メモリにアクセスした場合は仮想メモリの変換テーブルが肥大化する。テスト環境ならば、アクセスされる共有メモリ上のページ数も少量で済むだろうが、本番環境ではアクセスされるデータが広範囲にわたり、共有メモリ上の多くのページが参照される。それに伴い、プロセスごとのPTE(Page Table Entry)メモリが肥大化し、OSのメモリ領域が圧迫されてレスポンスが低下する場合がある。さらに、この事象をクラスタウェアが異常と判断した場合、最終的にはサーバが停止されてしまう可能性すらあるのだ。


  • 負荷試験の失敗2
 「精度の低い疑似データ」を使ってテストを行ったために、正確なテストが行えないケースも見られる。

 そもそも、高い精度のテスト・データを用意するのは簡単なことではない。そのため、負荷試験用のテスト・データを、わずかな疑似データを単純に増幅することによって準備している現場は少なくない。

 この場合、データベースのオプティマイザは、増幅された疑似データの特性に基づいてSQLの実行計画を作成する。テスト環境ではそれで問題が生じなかったとしても、本番環境で疑似データと傾向の異なるデータが使われると、大幅に性能が低下するといったことが起きる可能性がある。


  • 長期走行試験の失敗
 一方、長期走行試験に関してしばしば見られるのが、運用要件で定めた連続運転時間と同等時間分の長期走行試験を行っていなかったというケースだ。

 「例えば、『週次再起動』という運用要件であるのに、48時間程度しか長期走行試験を行っていなかったとする。このテストによって性能要件を満たすことを確認したが、本番稼働後、48時間以上が経過してから共有メモリの一部が徐々に肥大化してメモリ不足が発生し、内部的にメモリを再利用するための処理によるオーバーヘッドと内部ロック競合によって応答遅延が生じたという問題が現実に起きている」(大塚氏)

 このほか、システムに加えた変更が性能には影響しないと判断し、テストを行わなかったために問題が生じることもある。例えば、CPUがネックとなっていたシステムにCPUを追加したら、CPUキャッシュ間でデータの整合性をとる処理でオーバーヘッドが生じ、かえって性能が低下してしまったといったケースが挙げられる。

テスト不備のツケを支払うのはユーザー自身。常にテスト計画の妥当性確認を

 こうした実例も踏まえ、大塚氏は「テストに対する指針」として、次のようなアドバイスを贈った。

 「まず、テストによって『運用開始後に、想定外の問題は起きない』ということまでは保証できない。通常、企業システムは、運用開始後も変更や拡張などによって変化し続ける。したがって、事前のテストで確認することと、その後の運用の中で管理することは、明確に分けて考える必要がある。

 また、運用開始後は、継続的なモニタリングと性能分析を行うことでトラブルの予兆を捉え、事前に対策を実施すべし。Oracle Databaseならば、予兆を捉えるためのさまざまな稼働統計情報をとることができる。ただし、そうした統計情報から予兆をつかむにはノウハウが要る。そこに不安を感じる場合は、Oracle Enterprise Managerの自動診断機能や、オラクルのコンサルティング・サービスなどを活用していただきたい」(大塚氏)

 Oracle Enterprise Managerやコンサルティング・サービスに加えて、オラクルはOracle Databaseを利用したシステムの包括的なテストを支援するツール・スイートとして「Oracle Application Testing Suite(ATS)」を提供している。

 Oracle ATSは、機能テストと回帰テスト、およびテスト・データの投入を自動化する「Oracle Functional Testing」、負荷テストによる性能検証を行う「Oracle Load Testing」、そして両ツールによるテスト工程を管理するためのツール「Oracle Test Manager」で構成され、システムを利用するユーザーの視点(サービス・レスポンスや実利用データ)も踏まえたテストを簡単かつスピーディに行えることを特徴とする。「Oracle E-Business Suite」や「Siebel CRM」など、オラクルの各種企業アプリケーションに対応している点も大きなメリットだ。

 また、オラクルはOracle Database 11g Enterprise Editionのオプションとして、データベースの性能診断機能などを備えた「Oracle Real Application Testing(RAT)」も提供している。

 こうしたツールを活用することで、テスト自体の信頼性を高め、システムの性能トラブルを未然に防げるようになるのだ。

 しかし残念ながら、プロジェクトの短期化や予算縮小の傾向が強まる昨今、とにかく動くシステムを作ることで精一杯となり、性能への配慮が後回しになっている現場が少なくない。また、インフラ・アーキテクチャやテストに対する知識の不足から、詳細設計やテスト結果の評価をきちんと行えないという企業も珍しくない。大塚氏はそうした現状を指摘したうえで、「性能とテストの原則」として次の点を強調した。

 「ハードウェア技術やソフトウェア技術の進化により、従来ボトルネックだったものが解消されてきているのは事実だが、一方でシステムの大規模化や新しいアーキテクチャの登場により、新たなボトルネックも生じている。

 いつの時代にも、必要な性能を備えたシステムが自然と出来上がることは決してない。“性能は、設計してシステムに作りこむもの”であり、その設計の正しさはテストによってしか確認できない。このことは今後も変わらない」

 そして最後に、SIerとユーザー企業のそれぞれに対して次のようなアドバイスを贈り、講演を締めくくった。

 「SIerの皆さんには、必要となるテストの内容と重要性をご理解いただいたうえで、十分なテスト計画をプロジェクトに盛り込むよう配慮していただきたい。また、テスト結果はアウトプットだけで評価するのではなく、内部の稼働状況まで評価し、トラブルの予兆を見逃さないよう努めてほしい。

 システムの発注者であるユーザー企業の皆さんには、まずデータベースの性能にまつわるリスクを認識し、必要な性能と品質を得るには投資が必要であることをご理解いただきたい。また、協力会社から提出されるテスト計画は十分に精査し、サービスイン直前に数日~1週間程度の負荷テスト期間しか設けないような認識の甘い計画は却下するといった厳しい姿勢で臨んでほしい」

 大塚氏が述べるように、必要な性能は、明確に設計しなければ得ることはできず、その設計の妥当性は的確なテストによって証明される。ユーザー企業は、その証明の過程までプロジェクト計画書にきちんと盛り込まれていることを常に確認すべきだ。テストが不十分なシステムを稼働させた結果生じる業務停止やサービス停止のツケを支払うのはユーザー企業自身なのである。

Comments:

Post a Comment:
Comments are closed for this entry.
About

Twitter
Facebook

Search

Recent Posts
Archives
« 4月 2014
  
1
2
3
4
5
6
7
9
10
11
12
13
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today