JP2010231782A - 機能自動化のための方法およびシステム - Google Patents

Abstract

【課題】ソフトウェア開発ライフ・サイクル（ＳＤＬＣ）プロセスを能率化して開発チームの各メンバーにかかる綜合的な負担を軽減しながら製品の綜合的な品質を向上させる。
【解決手段】機能自動化プロセスは、好ましくは、多数のハイレベルなステップまたは段階を含む。第1ステップ（段階）は機能キックオフ１００である。次いで、ハイレベル・レビュー２００が行なわれる。ハイレベル・レビュー・ステップの次が詳細レビュー・ステップ３００である。詳細レビュー・ステップの次が開発/デバグ・ステップ４００である。最終ステップ５００でプロセスが完了する。
【選択図】図１

Description

発明の背景

本発明はソフトウェア製品または機能の設計および開発にソフトウェア試験自動化を組み込む技術に係わる。

公知技術の説明

ソフトウェア開発ライフ・サイクル（ＳＤＬＣ）はソフトウェア工学における公知のコンセプトであり、ソフトウェア・システムを作成または変更するプロセスに関連する。ＳＤＬＣは典型的には事業体およびその従業員（またはコンサルタント）によって、情報システムを開発することを目的に実行される論理プロセスであり、通常、複数のステップ、例えば、プランニング、分析、設計および実行のステップを含む。典型的なソフトウェア開発ライフ・サイクルはそれぞれのステップの出力が次のステップへの入力となる一連の状態を含む。代表的なシーケンスは下記の通り：即ち、プロジェクトの定義、ユーザー要求の定義、システム要件の定義、分析および設計、（コーディングおよび試験を含む）システム設定/プロトタイピング、および保守である。

従来、自動化ソフトウェア試験は組織的な目標事項ではなく、品詞保証（ＱＡ）チームによるその場限りの自動化試験の副産物である。このような試験の開発は反復性のあるプロセスを辿るものではなく、かかるソフトウェア試験は伝統的にソフトウェア開発チーム内の個人の主要な役割と見做されてもいない。従って、ソフトウェア・エンジニアリング産業の分野において、信頼でき、反復性のある結果を出す試験自動化を提供するための具体的な方法は全く確立されていない。

さらに、自動化試験システムおよび方法は下記の代表的な特許から明らかなように、当該技術分野において周知である：米国特許第６，６６２，３１２号、第６，３０１，７０１号、第６，００２，８６９号、第５，５１３，３１５号および第５，７５１，９４１号。公知の試験フレームワークもＳＴＡＦ（ソフトウェア試験自動化フレームワーク−Software Testing Automation Framework）のようなソリューションを含む。

ここに開示するのはソフトウェア・アプリケーションの手動試験を自動化するためのソフトウェアに基づくビジネス・プロセスである。「機能自動化」プロセスは開発チームのそれぞれのメンバーが果すべき具体的な役割と責任を明確にし、開発のそれぞれのステップが良く見えるようにする。これによって、予測可能で、高品質且つ反復性のある結果が得られる。このプロセスでは、ソフトウェア・ツールを利用することによって自動化試験を実行し、分析のための試験結果を収集する。

機能自動化プロセスは機能または製品を開発する過程において、自動化エンジニアを関与させ、ソフトウェア試験自動化の内容を定義し、具体化し、検討する、という段階を追った指令を規定する。このプロセスは自動化エンジニアの役割と他の資源をソフトウェア開発ライフ・サイクル（ＳＤＬＣ）に一体化する。企業（およびその経営陣）はまず専門の自動化チームを創設し、必要または所望なら、資源を割り振り、このチーム内で専門家を育てる。機能自動化チームは好ましくは製品/機能チームと協働するもとによって、後者が自動化エンジニアの役割をより深く理解し、製品/機能の所要条件、設計および具体化活動の透明性をさらに高めるようにする。機能自動化プロセスは連携する品質保証（ＱＡ）チームの試験スクリプト作成、自動化フレームワーク、試験設計の作成、および試験
コードの具体化および保守の責務を（機能自動化チームに）肩代わりしてもらえるようにする。本発明のプロセスによれば、すべての利害関係者は試験の実施前に自動化フレームワークおよび試験設計のレビューに関与し、フレームワークの反復使用可能性と試験の安定性を高めることができる。

好ましくは、機能自動化プロセスを、それぞれが１つまたは２つ以上の機能自動化活動を含む一組の外部レビュー・チェックポイントによって規定する。チェックポイントは好ましくは：機能キックオフ、ハイレベル・レビュー、詳細レビュー、開発およびデバギング、および統合/試験スイート実行を含む。機能開発ライフ・サイクルの終盤近くまでソフトウェア自動化が始まらない公知技術とは異なり、本発明の技術では、自動化の条件および設計がもっと早い段階で始まる。

具体的には、本発明のアプローチを採用すれば、機能自動化プロセスは製品／機能開発の早い段階で始まり、自動化活動はサイクルの後段ではなくＳＤＬＣ全体に一体化されるようになる。このプロセスは自動化チーム内外の協調効果を高め、自動化開発フレームワークを改良し、自動化開発ライフサイクルを短縮し、コードの品質および保全性を高め、コードおよび試験の文書化を改善し、自動化チームの新人メンバーの訓練時間を短縮する。

以上、本発明の主な特徴を記述した。これらの特徴は例示にすぎない。開示した発明を異なる態様で、または後述のように変更を加えることによって他の多くの有益な結果をえることができる。

本発明の詳細と利点を添付の図面を参照して後述する。

図１は本発明の一実施態様による機能自動化プロセスのフローを示すプロセス・フロー・ダイアグラムである。 図２は機能自動化プロセスにおいて使用するための代表的な自動化ソフトウェア試験フレームワークを示す。 図３は機能キックオフ・ステップのコンポーネントの局面を示すプロセス・フロー・ダイアグラムである。 図４は詳細レビュー・ステップのコンポーネントの局面を示すプロセス・フロー・ダイアグラムである。 図５は機能キックオフ・ステップのコンポーネントの局面を示すプロセス・フロー・ダイアグラムである。 図６は開発/デバグ・ステップのコンポーネントの局面を示すプロセス・フロー・ダイアグラムである。 図７は最終ステップのコンポーネントの局面を示すプロセス・フロー・ダイアグラムである。

ソフトウェア工学の基本用語は周知であるとの前提で以下に説明する。本発明の機能自動化プロセスは、好ましくは、図１に示すような多数のハイレベルなステップまたは段階を含む。各ステップのコンポーネントの局面を以下に詳細に説明および定義するとともに、図３乃至図７に図解する。第1ステップ（段階）は参照符号１００で示す機能キックオフである。次いで、ステップ２００に相当するハイレベル・レビューが行なわれる。ハイレベル・レビュー・ステップの次が詳細レビュー・ステップ３００である。詳細レビュー・ステップの次が開発/デバグ・ステップ４００である。最終ステップ５００でプロセスが完了する。

図３を参照して、さらに詳細な局面を説明すると、機能キックオフ・ステップ１００は多くの場合一組のサブステップを有し、そのうちの第１サブステップは機能自動化リーダーの確認１０２である。このステップは、ステップ１０６に示すように、機能チーム・リーダーおよび/または自動化チーム・リーダー若しくは何らかの形での両者の連携によって行なわれる。次いで、機能自動化リーダー１０２が条件をレビューするが、これがサブステップ１０４である。条件レビュー・ステップは多くの場合多数の局面/タスクを有する。参照符号１０８で示すように、このような機能条件は特定のソフトウェアがリリースのために凍結された後、機能チーム・リーダーがこの機能条件を所有することが好ましい。参照符号１１０は機能チーム・リーダーが機能チームと一緒に条件をレビューすることを示す。ステップ１１２において、機能自動化チームの一組のメンバーが条件のレビューに参加/協力する。次いでステップ１１４において、自動化チームのメンバーが１つまたは２つ以上の試験ケースを作成し（即ち、試験プランおよび試験ケース作成においてＱＡを支援）、これらの試験ケースを自動化する。こうして条件レビュー・ステップが、従って、機能キックオフ・ステップ１００が完了する。

ハイレベル・レビュー・ステップ２００は、好ましくは、２つの主要なステップ、即ち、機能設計レビュー・ステップ２０２と試験プラン提供/レビュー・ステップ２０４を含む。これらをそれぞれ説明する。

機能設計・レビュー・ステップ２０２は、図４に示すように、機能開発チームが機能設計の権限を所有するか、または機能設計を任せられるステップ２０６からスタートする。ステップ２０８において、機能自動化メンバーが機能設計のレビューに参加/協力する。ステップ２１０において、自動化メンバーは機能の全体的な設計を理解する；従って、機能の具体化に必要となる可能性がある機能フックおよびその他のインターフェースを認識し、（機能開発チームに）リクエストすることができる。こうして機能レビュー・ステップ２０２が完了する。試験プラン提供/レビュー・ステップ２０４は機能ＱＡチームが試験プランを所有するステップ２１２で始まる。ステップ２１４において、機能自動化チームが品質保証に必要な１つまたは２つ以上の試験プランを作成する。ステップ２１６において、機能自動化チームが機能試験プランのレビューに参加する。これによって機能自動化チームは機能試験をハイレベルで理解することができ、ステップ２１８においてハイレベルの自動化評価を下すことができる。こうして試験プラン提供/レビュー・ステップ２０４が完了し、従って、ハイレベル・レビュー・ステップ２００が完了する。

次のステップは詳細レビュー・ステップ３００であり、このステップは多数のサブステップ、即ち、試験ケース・レビュー・ステップ３０２、設計自動化試験ステップ３０４、共通機能識別ステップ３０６、製品フック・リクエスト・ステップ３０８、自動化設計・レビュー・ステップ３１０、および自動化プロジェクト・プラン/開発タスク・リスト・ステップ３１２を含む。それぞれのステップを以下に説明する。

図５に示すように、試験ケース・レビュー・ステップ３０２は機能試験ケースが機能ＱＡチームのメンバーの手中にあるか、またはこれらのメンバーに任せられるステップ３１４からスタートする。ステップ３１６において、機能自動化メンバーが機能の試験ケース・レビューに参加/協力する。ステップ３１８において、レビューの結果、機能自動化チームのメンバーは試験ケースを理解し、自動化のフレームワークと、必要なら、共通ライブラリとを設計することができる。サブステップはステップ３２０へ進み、必要に応じてさらにレビューを重ねることによって機能自動化チームが自動化を必要とする試験を明確に理解できるようにする。これによって、レビューを免れた試験ケースは皆無となる。ステップ３２２において、ＱＡチームが全員で試験自動化プランをレビューし、シナリオを詳細に評価する。これで試験ケース・レビュー・ステップが完了する。設計自動化試験ス
テップ３０２は機能自動化チームが自動化設計を所有するステップ３２４からスタートする。ステップ３２６において、機能自動化チームが共通ライブラリおよびサンプル・試験ケースと共にハイレベル・フレームワークを作成する。この時点で、且つ試験ケースを実行する前に、主要レビュー者と機能チームからなんらかの必要な承認を得る。これで設計自動化試験ステップ３０４が完了する。次のステップである「共通機能識別」ステップ３０６において、機能試験すべてに利用できる共通機能を識別し、機能-特異ライブラリを作成する。これがステップ３２８である。ステップ３３０において、チームは機能試験自動化における共通機能を利用する。このステップは共通機能のうち、共有ライブラリへ移せるものがあるかどうかを判断するため試験結果を評価するステップ３３２で完了する。製品フック・リクエスト・ステップ３０８は機能自動化チームが試験および機能設計・レビュー後に必要と予想される製品フックのリストを用意するステップ３３４からスタートする。製品フックは機能開発チームによって識別される。ステップ３３６において、機能開発チームはＳＮＭＰインターフェース、管理コマンド、データベース問い合わせ、等のような便利な形のフックを識別する。

自動化設計・レビュー・ステップ３１０は機能自動化チームが機能自動化の設計を所有するステップ３３８からスタートする。ステップ３４０において、機能自動化の主要なレビュー者は機能のタイプに適用できるものとして下記のタイプの試験の１つまたは２つ以上について提案されたフレームワーク、共用ライブラリ追加分およびサンプル試験ケースの具体化をレビューする。ステップ３４２において、機能自動化チームは１つまたは２つ以上のステップにおける主要レビュー者と共に設計をレビューする。最後に、自動化プロジェクト・プラン/開発タスク・リストステップ３１２は、機能自動化チームが好ましくは時間およびコストの評価と一緒に正式のプロジェクト・プランまたは開発タスク・リストを作成することからスタートする。これがステップ３４４である。ステップ３４６において、機能開発プランに加えられる自動化プランおよび自動化評価が機能チーム・リーダーに提供される。これによって設計の経緯を辿ることができる。これで詳細レビュー・ステップ３００が完了する。

開発/デバグ・ステップ４００は多数のサブステップを有する。即ち、共用ライブラリ追加ステップ４０２、自動化試験実行ステップ４０４、自動化コード・レビュー・ステップ４０６、トリアージ自動化問題点ステップ４０８、およびデバグ自動化試験ステップ４１０を含む。これらのサブステップのそれぞれについて以下に説明する。

図６に示すように、共用ライブラリ増補ステップ４０２は機能自動化チームが共用ライブラリへの１つまたは２つ以上の追加分を識別するステップ４１２からスタートする。ライブラリ増補の提案はチームが機能設計および試験プランを見落としなくレビューした後に行なわれる。ステップ４１４において、機能自動化チームは必要に応じて１つまたは２つ以上の追加分を共用ライブラリに加える。ライブラリ増補は開発される機能のタイプに応じて異なる。即ち、もし機能が新規であれば、機能が増分的に補強または修正される場合よりも大幅に増補される可能性が高い。ステップ４１６において、共用ライブラリへの追加が実行される。これで共用ライブリ増補ステップ４０２が完了し、この時点で、自動化試験実行ステップ４０４が始まる。ステップ４１８において、（機能自動化チームによって）識別された１つまたは２つ以上の試験ケースを実行する。ステップ４２０において、チームはこの実行が試験ケースにおいて識別されたすべてのステップを漏れなくカバーしていることを立証する。ステップ４２２において、チームは適当なプロセス（例えば、PyChecker）を運用してエラーを無くし且つ/またはランタイムの問題を招く可能性を評価する。次いで、ステップ４２６において、コード・レビュー者は１つまたは２つ以上のステップにおけるコード・レビューをリクエストする。これで自動化試験実行ステップ４０４が完了する。

ここで自動化コード・レビュー・ステップ４０６が開始される。ステップ４０６の起点となるステップ４２８において、機能自動化チームはこのチームまたは他のチームからの主要レビュー者と共にコードをレビューする。ステップ４３０において、適用コーディング標準に合致していることを確認するためのレビューが行なわれる。ステップ４３２において、文書がレビューされる。ステップ４３４において、それぞれの試験ケースについて完全な試験カバレージが行なわれる。ステップ４３６において、エラー処理方法が評価される。ステップ４３８において、フレームワークが試験される。ステップ４４０において、共有ライブラリの具体化が試験される。ステップ４４２において、必要となる可能性があるツールが試験される。ステップ４４４において、エラー・チェックのため適当なプロセス（例えば、 PyChecker）が運用される。次いで、ステップ４４６において、コード・ブランチにさかのぼってコードがチェックされる。ステップ４４８において、機能のための共有ライブラリが識別される。ステップ４５０において、（もし必要なら）共有ライブラリの変更または増補が行なわれる。ステップ４５２において、試験のためのコードが完全なら、チームはＱＡに関与し、試験の論理カバレージを承認される。これを以って自動化コード・レビュー・ステップ４０６が完了する。

トリアージ自動化問題点ステップ４０８はステップ４５４からスタートする。このステップにおいて、機能に関連する自動化問題点（即ち、バグ）が識別され、問題点の原因について判断が下される。ステップ４５６において、チームはＱＡチームと、さらに、必要なら開発チームとも連携して、試験の欠陥が製品の問題点に起因するかどうか、また、どのように対処すべきかを判断する。これを以ってトリアージ自動化問題点ステップ４０８が完了する。最後に、デバグ自動化試験ステップ４１０はステップ４６０を伴い、このステップ４６０において、チームは欠陥を調査し、すべての試験がパスするまで適切な処置を行なう。これで開発/でバグステップ４００が完了する。

自動化コードの開発およびレビューには、好ましくは１つまたは２つ以上の市販のツールを利用することができる。例えば、Eclipse（ソフトウェア開発環境）、PyDev（ユーザーがPython開発のためにEclipseを使用することを可能にするプラグイン）、PyChecker（Pythonソース・コード中にバグを発見するためのツール）およびPyLint（モジュールがコーディング標準に合致しているかどうかをチェックするPythonツール）などである。但し、これらのツールは代表的な例であって、他にも使用可能なツールが存在する。

最終ステップ５００は多数のサブステップを含む：即ち、自動化コード統合ステップ５０２、試験スイート実行ステップ５０４、および試験リスト更新ステップ５０６を含む。これらのサブステップのそれぞれを以下に説明する。

図７に示すように、自動化コード統合ステップ５０２はコードを融合するステップ５０８からスタートする。次いで、チームは残る問題点を識別し、修正する。これがステップ５１０である。ここで自動化コード統合ステップ５０２が完了する。ステップ５１２において試験スイート実行ステップが開始される。このステップにおいて、チームは試験スイートを実行し、（機能試験スイートおよびこれに従属する他のすべての試験に）発生する問題点を修正する。ステップ５１４において、ランタイム統計が分析され、必要ならば、所要の性能に合わせて試験スイートが調整される。これで試験スイート実行ステップが完了する。最後に、試験スイート・リスト更新ステップ５０６が行なわれる。この最終ステップ５１６において、機能自動化チームは既存の試験スイートに対する変化を反映させて自動化試験スイート・リストを更新する。

本発明の方法およびシステムには多くの利点がある。ここに開示する方法はソフトウェア製品開発組織体がこれを利用することによって容易にソフトウェア開発ライフ・サイクルに組み込むことができる。ＳＤＬＣプロセスを能率化して開発チームの各メンバーにか
かる綜合的な負担を軽減しながら製品の綜合的な品質を向上させることができる。さらに、自動化は下記のような便益を提供する：新製品開発のための自動化チームの定義付けを容易にし、開発サイクルの比較的早期に製品バグを識別することによって定期的な（例えば、年に二度の）リリースが必要となる場合、製品開発ライフ・サイクルが短縮され、製品品質に関する連続フィードバックが可能になり、機能チームが緊密に協働して高品質製品を提供することができ、任意のソフトウェア開発プロジェクトのため、堅牢且つ確実な自動化プラットホームを画定し、有効化することを可能にする。本発明の方法は組織のソフトウェア製品開発構想におけるソフトウェア試験自動化環境を画定するのに採用または調整できる繰返し可能なプロセスを提供する。さらにまた、事業体が試験自動化を通してソフトウェア品質保証（Ｑ/Ａ）の達成に向かって動くことを可能にする新規のソフトウェア組織モデルを明示する。

この方法は多様な形で利用することができる。ソフトウェア製品の試験を専門とする業界の組織ならば、この方法を利用して試験の自動化対策を確立し、実行することができる。複雑なソフトウェア製品の開発を手がける組織ならば、採用すべき自動化開発活動を画定し、実行することができる。また、ソフトウェア・プロセス・コンサルタント組織ならば、本発明の方法を利用することによって、製品の品質を高め、しかも、クライエントが負担する試験コストを軽減することができる。

これは１例に過ぎないが、この目的を達成するには、本出願人が所有する米国特許第２００７０２３４２９３号"Automated testing software framework"に記載されているようなソフトウェア自動化ツールを利用して図７のステップ５１２を実行することができる。このような自動化試験フレームワークはマシンにおいて（または複数マシンを通して）実行可能なプログラム・コードとして具体化することが好ましい。特定のマシンの詳細も作用環境もここでは問題ではない。このようなアプローチの１実施態様では、フレームワークによって要求される種々の機能を果す他のモジュールを呼び出す独立アプリケーションまたは「デーモン」としてコードが作用する。このようなモジュールの１つまたは２つ以上はフレームワークの一部であってもよいし、外部システムの一部であってもよい。デーモンが１つのマシンで実行し、サービス・モジュールの１つまたは２つ以上が同じまたは他のマシンで実行することができる。これによってフレームワークはプラットホーム共通のコンパチビリティを保証される。

１つの実施態様として、フレームワーク・デーモンは多数の支援ツールを有する。即ち、要求される種々の機能を提供する実行可能なモジュールを有する。例えば、フレームワーク・デーモンは一連の試験（またはバッチ）を実行し、その結果をデータベースに記録し、ローカル・マシンのウェブ・サーバーのウェブアクセス可能なディレクトリにノード・イメージおよびログを記憶させる。デーモンは好ましくはすべての例外、障害、クラッシュなどをe-メール受信者のターゲット群へe-メールするか、またはこれらの情報をバグ追跡システムに向かって転送する。このようにして、フレームワークは極めて設定が容易であり、且つ試験用語に煩わされない、機能的なクラスタ・レベル回帰試験ハーネスを提供することになる。フレームワークはまた、ホワイト-ボックス試験を行なうこともできる。一連のホスト、または単一のホストで行なうことのできる試験なら、自動化試験フレームワーク内で行なうことができる。

図２は、例えば、図７のステップ５１２において使用するための自動化試験フレームワークの具体化を示すブロックダイアグラムである。上述したように、フレームワークはデーモンの形を取るラッパーを含むツールボックスである。これは機能試験を可能にする拡張可能なフレームワークであり、好ましくは共通の、拡張可能な、簡単なツール群で構成されている。

図２から明らかなように、この実施態様に基づくフレームワーク２０１は２つの層：即ち、フレームワーク層２０３とツール層２０５とから成る。フレームワーク層２０３はフレームワークがフレームワーク自体、試験されている製品/システム、および要求される試験（およびその実行）を「知る」上で必要なロジック、モジュール、スクリプトまたはデータベースを含む。これに対して、ツール層２０５はシステムの分散管理を可能にし、例えば、構成インストール、ログ管理、データベース問い合わせなど種々のタスクを行なうツールを含む。ツール（または少なくともその幾つか）は非対話型であり、自動化され、再使用可能であり、集中管理または制御を必要としないツールであることが好ましい。

図２において、別々の論理モジュールを利用することによって、試験用システム（ＳＵＴ）を割当て、インストールし、確認するネットワーク-アクセス可能なスクリプトである。デーモンは入ってくるリクエストに応えてターゲットである試験用システムに対して所与のパッケージソフトを運用する。結果ハンドラー・モジュール２０９は試験中に発生するデータを管理する。従って、例えば、デフォルト設定によって結果が結果ディレクトリに記録され、このディレクトリは好ましくは日/時/スイート/試験名によって識別される。それぞれの試験結果はフラット・テキスト・ファイル形式で記憶され、最新結果データベース・システムにアップロードされる。実行の完了後、結果アップロード・フラグが可能化されれば、デーモン２０７がこれらの結果を結果データベースにアップロードする。結果ハンドラー・モジュール２０９はまた結果をＣＳＶ-スタイル形式でｅ-メールすることによって他のシステムにアップロードし、これらの結果をデータベースに押し込むか、または最大アクセシビリティ・ディスク上のファイルに記憶させることもできる。試験実行モジュール２１１は究極的には実際の試験スイートの実行を担当するスクリプトである。このスクリプトは試験に必要なすべての細部（例えば、構成、初期化資源等）を扱う。このモジュールは好ましくは非閉鎖/タイムドアウトの態様で試験を実行する。即ち、試験が中断するか、または完了しないことを予期し；これらの試験をモニターし、必要に応じて停止させる。マスター試験システム・モジュール２１３は試験実行モジュール２１１を利用し、（個別スイートではなくフレームワーク・スイートのような）マスター・レベルのスイートを発生させることにより、（例えば、長時間のバーンイン、クイック・スモーク、パフォーマンス等のような）システム-レベル・カテゴリーのためのバッチ・システムとして作用する。コード・リポジトリ同期化モジュール２１５は（例えば、Perforceのような）すべてのリポジトリのリフレッシュを扱い、情報源管理サーバーからコード構造を引き出す。このモジュールに対して、データベース・モジュールは要求されている試験の位置と、これらの試験をリフレッシュすべきかどうかを教える。好ましくは、ローカル・コピーの有無に関係なく所与の試験スイートのためのファイルを同期化する。従って、情報源管理システムがマスター・コピーであると考えられる；これとは対照的に、フレームワークはそのローカル・コピーを当てにしない。データベース・リフレッシュ・モジュール２１７はすべてのデータベースの連結性を扱う。このモジュールはクラスタに関する情報を得て、この情報をデーモンに提供するのに利用される。リフレッシュ・モジュール２１７は要求されている試験/スイート情報を得るためにも利用される。試験情報データベース２１９は試験スイートにおけるそれぞれの試験に関する情報のほか、試験を実行するのに必要なあらゆる情報を含む。クラスタ情報データベース２２１はフレームワークが実行されるクラスタに関する該当情報を含む。このデータベースを試験実行の前に（または所与の試験スイートが実行される前に）ポーリングすることによって必要情報を見つけることができる。

ツール層２０５はそのコンポーネントとして、層中のツールのためのラッパーである分散コマンド・ハンドラー・モジュール２２３を含む。モジュール２２３はツールが非対話型態様でクラスタと相互作用することを可能にするＳＳＨ接続を介して、またはスクリプトまたはオープンＡＰＩを介してアクセスできることが好ましい。分散コマンド・ハンドラー・モジュールへのアクセスに認証を必要とすることが好ましい。ログ回転または「イ
メージャー」モジュール２２５はシステム・ログをダンピングし、クラスタ・ノード・ログ中のエラー・メッセージをチェックし、試験完了後、クラスタ・ノード全体を通したデータベースをイメージングする。デーモン・マスター・モジュール２２７は試験用システムにおけるデーモンに対する、例えば、開始および終了のような細分制御を可能にするスクリプトである。データベース・スナップショット・モジュール２２９はＳＵＴ全体に亘って展開するデータベースのスナップショット２３１を入手して、これをローカル・マシンへプルバックする。スナップショット・モジュール２２９はＳＵＴを実際にイメージするツールであり、ログ回転モジュールと協働することによって、所与の試験スイートの種々の試験実行間におけるＳＵＴノードのすべてからログを得ることができる。スナップショット・モジュール２２９はまた、システム中のすべてのノードにおける現在データベースのイメージを捕捉し、これらのファイルをローカル・マシンへコピーバックし、これらのファイルを試験/スイート実行のためのログと一緒に記憶する。スナップショット・モジュールはクラスタの完全性を立証することもできる。構成インストーラ・モジュール２３３は分散コマンド・ハンドラー・モジュールを利用することによって、必要な設定スクリプトを含む、ターゲット・クラスタ全域の明確な構成をインストールするスクリプトである。モジュール２３３は構成データベース中の情報に基づいて自動的に必要値を決定するスクリプトとして具体化することもできる。モジュール２３５はターゲット・システムをワイピングまたはクリーニングし、必要なら、ディスク、データベース、ログ、ファイル等を初期化する。ヘルス・モニター２３７は実行システムの完全性を立証し、有効/無効プロセス、スワップ使用等のチェックをも行なう。常時、コールされればヘルス・モニター２３７はＳＵＴに対するチェックを行なう。最後に、ゲートウェイ実装検証モジュール２３９は種々のゲートウェイの健全性を検証し、これらゲートウェイに対する種々のアクセス方法を実行するのに利用される；従って、このモジュールは試験実行モジュールが必要な資源の実装を要請するための実装システムとしても利用することができる。

フレームワークが使用できるツールは必ずしも図２にしめすツールに限定されることはなく、ほかにも種々のツールを使用することができる。また、図２においてツール層と機能/デーモン層との間に引かれている線は単に表現のためのものであって、発明の範囲を制限するものではない。上述したように、（実施態様に関係なく）フレームワークは「クリーン・ルーム」を提供しながらその中で試験を推進し、試験スイートが進行する間、状態を安定させるプラットホームに過ぎない。典型的な実施態様においては、自動化試験フレームワークはマシン起動商用ハードウェアおよびLinuxオペレーティング・システムで実行する。しかし、本発明はこれに制限されない。上述した通り、デーモンを所与のマシンで実行し、図２に示すモジュールの１つまたは２つ以上を同一のマシンまたは１つまたは２つ以上の他のマシンで実行することができる。即ち、フレームワークはLinux以外のオペレーション・システム、例えば、Solaris、HPUX, AIX, IRIX, OS/X, WinXP, Window 2000等で実行するクライエントにも対応することができる。従って、他の実施態様では、フレームワークが所与の試験のプラットホームを検知し、検知と同時に、この試験を支援することができる特異なプラットホームで実行する。

上述したように、マシンによっては異なるハードウェア、異なるソフトウェア、または異なるハードウェアと異なるソフトウェアとして実行することができる。結果として、フレームワークは高度の拡張可能性を有する。フレキシブルであり、容易に拡張することができ、さらには、試験言語およびクライエントのプラットホームに制約されなければ尚好ましい。このように実施すれば、フレームワークは言語の相違に制約されることなく、如何なる試験をも実行することができる。

図示のプロセス・フロー・ダイアグラムおよび以上の説明では、本発明の幾つかの実施態様によって行なわれるオペレーションが特定の順序を辿ることになっているが、この順序は飽くまでも例として挙げたものであり、他の実施態様では異なる順序でオペレーショ
ンを行なうか、幾つかのオペレーションを組み合わせるか、幾つかのオペレーションをオーバーラップすることができる。上記の実施態様は特定の機能、構造、または特徴を含むが、すべての実施態様が特定の機能、構造、または特徴を含むとは限らない。

方法またはプロセスに関連して本発明を説明したが、本発明は上記オペレーションを実行するための装置にも係わる。この装置は使用目的に合わせて構成するか、またはコンピュータに記憶されているコンピュータ・プログラムによって選択的に作用させるかまたは再構成させることができる汎用コンピュータを内蔵させることができる。このようなコンピュータ・プログラムはコンピュータ可読記憶媒体、例えば、光学ディスク、CD-ROMおよび磁気光学ディスクのような任意のディスク、読み取り専用メモリ（ROM）、ランダムアクセスメモリ（RAM）、磁気または光学カード、または電子指令の記憶に好適な媒体に記憶され、いずれもコンピュータ・システム・バスに接続される。上述したように、本発明の所与の具体化は所与のプログラミング言語で書かれたソフトウェアであり、Linuxのようなオペレーティング・システムを運用する標準的ハードウェア・プラットホーム上で実行される。

システムの所与のコンポーネントを個別に記述したが、当業者には明らかなように、機能の幾つかを組み合わせるか、または所与の指令、プログラム・シーケンス、コード部分等に振り分けることができる。
以上、本発明を説明したが、特許請求の範囲は後記の通りである。

Claims (10)

1. 必要条件の収集と分析、設計、具体化、試験および統合のステップを含むソフトウェア開発ライフ・サイクルにおける改良であって、
   自動化チームを特定し;
   自動化チームをしてソフトウェア・設計および少なくとも１つの試験プランをレビューさせ；
   レビューに基づいて少なくとも１つの自動化試験を設計させ；
   少なくとも１つの自動化試験を行なうためのコードを作成し；
   前記コードを、試験すべき所与のソフトウェア機能を具体化するコードと統合し;
   統合されたコードに対して少なくとも１つの試験スイートを実行する
   ステップを含み、
   上記ステップの少なくとも１つはマシンにより具体化されることを特徴とする前記改良。
2. 実行のステップにおいて識別される統合コード中のエラーを識別し、修正するステップをも含むことを特徴とする請求項１に記載の改良。
3. 実行のステップにおいて自動化試験フレームワークを使用して少なくとも１つの試験スイートを実行することを特徴とする請求項１に記載の改良。
4. 実行ステップ中に収集されるデータに応じて試験スイートを調整するステップをも含むことを特徴とする請求項１に記載の改良。
5. 自動化チームをして、少なくとも１つの自動化試験を含む自動化フレームワークを作成させるステップをも含むことを特徴とする請求項１に記載の改良。
6. 自動化フレームワークが共通ライブラリと、少なくとも１つの自動化試験を含む一連のサンプル試験ケースを含むことを特徴とする請求項５に記載の改良。
7. 自動化チームが所与のソフトウェア機能に関して一組の機能試験に亘って使用すべき共通機能を識別することを特徴とする請求項１に記載の改良。
8. 共通機能を共用ライブラリへ移せるかどうかを決定するステップをも含むことを特徴とする請求項７に記載の改良。
9. 共通機能のコンポーネントを共用ライブラリへ移すステップをも含むことを特徴とする請求項８に記載の改良。
10. ソフトウェア開発方法であって、
    自動化チームを特定し;
    自動化チームをしてソフトウェア・設計および少なくとも１つの試験プランをレビューさせ；
    レビューに基づいて少なくとも１つの自動化試験を設計させ；
    少なくとも１つの自動化試験を行なうためのコードを作成し；
    前記コードを、試験すべき所与のソフトウェア機能を具体化するコードと統合し;
    統合されたコードに対して少なくとも１つの試験スイートを実行する
    ステップを含み、
    上記ステップの少なくとも１つはマシンで具体化されることを特徴とするソフトウェア開発方法。