JP5970617B2 - 開発支援システム - Google Patents

Description

本発明は、ソフトウェア開発の技術に関し、特に、プログラムの不具合確認等のためのテストにおけるテストケースを抽出する開発支援システムに適用して有効な技術に関するものである。

ソフトウェアプログラム（以下では単に「プログラム」と記載する場合がある）には、人為的なミスによる不良が含まれている。プログラム製品の出荷に先立って、プログラムに含まれる不良を探索し、修正するために、テストが行われるのが一般的である。テストの実施は、例えば、テスト対象のプログラムに対してさまざまな条件を設定して実行するテスト用のプログラムであるテストケースを順次実行し、不具合を発生させることで、テスト対象のプログラムにおける不良の場所および原因を明らかにする。

さらに、例えば、テストケースの実行を自動的に行ったりするような、いわゆる継続的インテグレーション（ＣＩ：Continuous Integration）に係るツールや技術が普及してきている。ＣＩを実現するツール等では、一般的に、複数人で開発されるプログラムは、中央の記憶サーバ上のリポジトリと呼ばれる記憶領域において集中的に管理される。そして、開発者が、開発したプログラムをリポジトリに登録するたびに、自動的にテストケースを実行し、登録されたプログラムに不良が存在しないかを調べることで、プログラムの品質確保が図られる。

また、リポジトリで管理されるプログラムのソースコードなどの関連物に対して、複数の開発者等が内容をチェックするレビューにより開発内容を承認するという仕組みが提供されているものがある。このような複数の開発者による共同開発やレビューによるソフトウェア開発の手法はソーシャルコーディングと呼ばれる。

一方、テストの実施に際しては、テストケースの量に伴い実行時間が増大するという課題が有る。プログラムの不良は、通常は特定の条件のみで発生するため、これを探索するには、あらゆる条件を想定した多数のテストケースを準備して実行する必要があることから、テストケースの実行に多くの時間を要する。

この課題に対して、例えば、特開２００８−２０４４０５号公報（特許文献１）には、過去に行われたテストのテストケースについての情報を保存しておき、その情報と対象プログラムを解析して得られた依存関係を組み合わせることにより、プログラムを変更した箇所に応じて優先的にテストすべき部分を自動的に抽出してリグレッションテストを行う技術が記載されている。

また、特開２０１０−１３４６４３号公報（特許文献２）には、リポジトリにテストケースの属性として重要度および実行実績時間を保持させ、開発者からソース登録を受けたソース構成管理ツールからＣＩツールにソース変更の通知があったときに、ＣＩツールから渡された変更ファイルの解析を行い、解析結果をリポジトリに格納し、ＣＩツールから渡された実施重要度および実施時間閾値と、リポジトリに格納されたテストケースの重要度および実行実績時間とから実行すべきテストケースを選択する技術が記載されている。

特開２００８−２０４４０５号公報 特開２０１０−１３４６４３号公報

上述した従来技術によるテスト方法は、いずれも、テストケースのうち重要なものに限定して実行することで、テストケースの実施に時間を要するという上記課題を解決しようとするものである。

しかしながら、従来技術によるテスト方法では、例えば、開発初期段階、中期段階、後期段階といったプログラムの開発状況や開発フェーズなどを考慮してテストケースを抽出することができない。また、テストを実施する操作者や、テスト実施の観点等といったテストの内容や実施状況などを考慮してテストケースを抽出することができない。

そこで本発明の目的は、プログラムの開発状況や、テストの状況などに応じて重要なテストケースを抽出する開発支援システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による開発支援システムは、１つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、前記構成管理部は、前記プログラムの開発状況を判定して、前記開発状況に基づいて前記各テストケースに優先度を設定し、前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、プログラムの開発状況や、テストの状況などに応じて重要なテストケースを抽出することが可能となる。

本発明の一実施の形態である開発支援システムの構成例について概要を示した図である。 本発明の一実施の形態における開発支援システムが解決しようとする課題について概要を説明する図である。 ソーシャルコーディングにおけるブランチの作成例について概要を示した図である。 ソーシャルコーディングにおけるブランチの統合例について概要を示した図である。 本発明の一実施の形態におけるテストケース作成の処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるテスト実行の処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における優先度算出処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるプログラムに対するレビューの処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態におけるテストケース管理テーブルのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるブランチ管理テーブルのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるコミット履歴のデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態における機能マスタのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態における開発者マスタのデータ構成と具体的なデータの例について概要を示した図である。 本発明の一実施の形態におけるレビュー管理テーブルのデータ構成と具体的なデータの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

上述したように、ネットワークを介して複数の開発者がプログラムの開発を行うソーシャルコーディングの環境において、テストの自動実行などのＣＩを実現するツール等が普及してきているが、自動実行とは言いながらも、膨大な数のテストケースを全て実行するには非常に時間がかかり非効率である。そこで、重要な部分のみに限定してテストケースを実行する、もしくは重要な部分を優先的に実行できるようにしたいという要望がある。

ここで、上述した特許文献等の従来技術では、テストケースのうち重要なものに限定して実行することで、テストケースの実施を効率化することができるものの、プログラムの開発状況や、テスト状況などを考慮することまではできていない。例えば、開発状況の考慮として、同一のプログラムにおいても、開発工程の進捗度（例えば、開発初期と開発後期との間など）や時間経過によるプログラム自体の成熟度に応じてテストしたい内容は異なり得る。また、プログラムに加えた修正を登録（コミット）する頻度が高い場合や修正量（差分）が小さい場合と、登録頻度が低い場合や修正差分が大きい場合との間でも、テストしたい内容は異なり得る。従来技術では、このような時間的観点を含む開発状況を考慮して重要度を判断するという観点が欠落している。

また、テスト状況の考慮として、同一のプログラムにおいても、例えば、開発者によるローカルでの単体テストと、プログラム統合による全体検証テストとの間では、テストしたい観点は異なり得る。従来技術では、このようなテスト実施の内容を考慮して重要度を判断するという観点が欠落している。

そこで、本発明の一実施の形態である開発支援システムは、ソーシャルコーディングの環境において、プログラムの開発状況や、テスト実施の観点に基づき、重要なテストケースを抽出し、あるいは優先的に実施できるようにするものである。これにより、膨大な数のテストケースを網羅的に全て実施することなく、効率的なテストの実施を可能とする。

図２は、上述した本発明の一実施の形態である開発支援システムが解決しようとする課題について概要を説明する図である。図中では、ソーシャルコーディングやバージョン管理、リポジトリ管理において、開発単位毎のプログラムを管理する領域であるブランチの分岐例と、ブランチにおいて開発したプログラムについての登録（コミット）の状況の例を左から右方向への時系列で示している。ここでは、メインブランチから開発者ＡおよびＢのそれぞれが自身の開発のためのブランチを分岐させて作成し、開発が完了した後にメインブランチに統合（マージ）している状態を示している。

プログラムは、上述したように、開発用途や開発者などの単位で個別に設けられたブランチ上で管理される。図３は、ソーシャルコーディングにおけるブランチの作成例について概要を示した図である。図中では、マスタとなるプログラムが登録されているマスタブランチ４０１（ブランチ名“ｍａｓｔｅｒ”）に、“Ａ．ｊａｖａ”および“Ｂ．ｊａｖａ”などのプログラム（ソースコード）が登録されていることを示している。新しいブランチは、任意のタイミングで作成することができ、例えば、既存のリポジトリをコピーすることで作成することができる。この場合、作成されたブランチは元のブランチから分岐したものとなる。なお、最初のブランチは新規に作成する。

図３の例では、マスタブランチ４０１から、開発用のメインブランチである開発用ブランチ４０２（ブランチ名“ｄｅｖｅｌｏｐ”）を分岐させて作成した状態を示している。さらに、開発用ブランチ４０２から、機能Ａについての開発用のブランチである機能Ａ開発用ブランチ４０３（ブランチ名“ｆｅａｔｕｒｅ＿Ａ”）を分岐させて作成し、さらに、機能Ａ開発用ブランチ４０３から、“ＸＸＸ”という名称の開発者用のブランチである機能Ａ開発者ＸＸＸ用ブランチ４０４（ブランチ名“ｆｅａｔｕｒｅ＿Ａ＿ＸＸＸ”）を分岐させて作成した状態を示している。

また、作成したブランチは、例えば開発対象のプログラムの完成など、任意のタイミングで分岐元のブランチに統合（マージ）することができる。図４は、ソーシャルコーディングにおけるブランチの統合例について概要を示した図である。図中では、分岐元である機能Ａ開発用ブランチ４０３に対して、分岐して作成した機能Ａ開発者ＸＸＸ用ブランチ４０４をマージした状態を示している。マージにより、機能Ａ開発用ブランチ４０３に対して、機能Ａ開発者ＸＸＸ用ブランチ４０４に登録されたプログラムの内容が上書きでマージされる。図２〜図４に示したように、開発の進展に伴って、複数のブランチに分岐したり、複数のブランチを統合したりしながら開発が進められる。

開発の各段階でテストが行われるが、上述した、重要なテストケースを抽出する際の考慮点のうち、時間的観点を含むプログラムの開発状況を考慮した抽出の手法については、例えば、図２の（１）に示したように、開発の進捗度（開発初期や成熟期など）に応じて適当な種類のテストケースを抽出することが含まれる。また、図２の（２）に示したように、コミットの頻度が多い（間隔が短い）場合や修正差分の量が多い場合にテストケースを間引いて抽出したり、複数のテストを分散実行したりすることなどが含まれる。

一方、重要なテストケースを抽出する際の考慮点のうち、テスト実施の観点を考慮した抽出の手法については、例えば、図２の（３）に示したように、対象のブランチに応じてテスト対象を変えて適当なテストケース（例えば、開発者ブランチの場合はローカルでの単体テスト、メインブランチの場合はプログラムを統合した後の全体検証テストなど）を抽出することが含まれる。

＜システム構成＞
図１は、本発明の一実施の形態である開発支援システムの構成例について概要を示した図である。開発支援システム１は、例えば、開発支援サーバ１００に対して、ＬＡＮ（Local Area Network）などのネットワークを介して、各ユーザがそれぞれ使用する開発用クライアント２００が複数接続され、相互に通信可能な構成を有する。

開発支援サーバ１００は、例えば、テストケースの抽出やテストの自動実行などの機能を有するサーバシステムであり、一般的なサーバ機器やクラウドコンピューティング環境上に構築された仮想サーバなどにより実装され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムにより実装される構成管理部１１０およびテスト実行部１２０などの各部を有する。

また、複数の開発者により開発されたプログラムや各種成果物を記憶して集中的に管理するデータベース等の記憶領域であるリポジトリ１３０を有する。リポジトリ１３０には、例えば、後述するブランチ管理テーブル１３１やテストケース管理テーブル１３２などのテーブルの他に、開発されたプログラム１３３や、抽出・作成されたテストケース１３４、テスト実施結果であるテスト結果１３５などの各種データが保持される。

構成管理部１１０は、プログラム開発の全体的な構成を管理する機能を有し、例えば、ソーシャルコーディング機能やリポジトリ管理機能、バージョン管理機能などを提供するシステムやツールのサーバプログラムによって構成される。これらのツールとしては、例えば、Ｇｉｔなどの一般に普及しているものを適用することができる。構成管理部１１０は、例えば、後述する開発用クライアント２００からの要求等に基づいて、開発されたプログラム１３３をリポジトリ１３０に登録する。このとき、前回の登録時からの変更や差分が把握できるような情報を履歴情報として併せて格納する。また、プログラム１３３に対して作成されたテストケース１３４をリポジトリ１３０に登録するとともに、テストケース管理テーブル１３２を更新する機能も有する。また、作成されたブランチの情報をブランチ管理テーブル１３１によって管理する機能も有する。

テスト実行部１２０は、構成管理部１１０からの指示により、リポジトリ１３０に登録されたテストケース１３４に基づいてテストを自動実行する機能を有し、例えば、ＪＵｎｉｔなどの一般に普及しているテストフレームワークなどを適用することができる。本実施の形態では、後述する手法により、テストケース１３４のうち優先度が高いものを抽出して、抽出されたテストケース１３４に絞ってテストを実施することで、効率的なテストの実施を可能とする。実行するテストケース１３４については、テストケース管理テーブル１３２によって管理し、また、テストの実行の結果として得られるテスト結果１３５についてもリポジトリ１３０に格納して管理する。

開発用クライアント２００は、例えば、開発者等の各ユーザがプログラム１３３の開発やテストケース１３４の作成などの作業を行うＰＣ（Personal Computer）等の情報処理端末であり、図示しないＯＳなどのミドルウェア上で稼働するソフトウェアプログラムにより実装されるＷｅｂブラウザ２１０やコード記述部２２０、構成管理操作部２３０などの各部を有する。

コード記述部２２０は、開発者がプログラム１３３を開発・作成したり、テストケース１３４を作成したりするための機能を有し、例えば、Ｅｃｌｉｐｓｅなどの一般に普及しているプログラム開発ツールや開発環境などを適宜利用することができる。コード記述部２２０を利用して開発者により開発・作成されたプログラム１３３やテストケース１３４、テストケース１３４に関する情報であるテストケース付加情報２０１は、後述する構成管理操作部２３０により、開発支援サーバ１００上のリポジトリ１３０に登録される。

構成管理操作部２３０は、開発支援サーバ１００の構成管理部１１０と通信し、コード記述部２２０により開発・作成されたプログラム１３３やテストケース１３４、テストケース付加情報２０１などを送信してリポジトリ１３０に登録する機能を有する。例えば、開発支援サーバ１００の構成管理部１１０としてＧｉｔを用いている場合には、Ｇｉｔクライアントなどにより実装することができる。

Ｗｅｂブラウザ２１０は、ソーシャルコーディングにおいて開発者がコード記述部２２０や構成管理操作部２３０を用いたプログラム開発やレビュー等の作業を実施するためのユーザインタフェースを提供するＷｅｂブラウザプログラムであり、一般に普及しているものを適宜用いることができる。図示しない開発支援サーバ１００上のＷｅｂサーバプログラムを介して開発支援サーバ１００の構成管理部１１０等と通信を行う機能を有していてもよい。

＜処理フロー（テストケース作成）＞
以下では、本実施の形態におけるテスト実施の際の各処理について説明する。図５は、テストケース作成の処理の流れの例について概要を示したフローチャートである。まず、テストケースの作成者が、開発用クライアント２００を利用して、コード記述部２２０によりテストケース１３４を作成し、開発支援サーバ１００の構成管理部１１０を介してリポジトリ１３０に登録する（Ｓ０１）。このとき、構成管理部１１０では、テストケース１３４の種類などを含む関連情報を割り当てて、後述するテストケース管理テーブル１３２に併せて登録する（Ｓ０２）。

＜処理フロー（テスト実行）＞
図６は、作成されたテストケース１３４に基づくテスト実行の処理の流れの例について概要を示したフローチャートである。まず、プログラム１３３の開発者が、開発用クライアント２００を利用して、コード記述部２２０および構成管理操作部２３０により、開発したプログラム１３３を開発支援サーバ１００のリポジトリ１３０に登録（コミット）する（Ｓ１１）。ここでの登録は、例えば、変更や修正に係る差分のみを登録する形式とすることができる。登録したプログラム１３３の情報は、ブランチ毎に後述するブランチ管理テーブル１３１によって管理する。また、プログラム１３３を登録した履歴は、後述するコミット履歴１３１ａによって管理する。

プログラム１３３がリポジトリ１３０に登録されると、開発支援サーバ１００の構成管理部１１０もしくはテスト実行部１２０が、登録されたプログラム１３３について、テストケース管理テーブル１３２に登録された各テストケース１３４に係る優先度を所定の手法によりそれぞれ算出し、算出した優先度の値によってテストケース管理テーブル１３２を更新する（Ｓ１２）。優先度算出処理の内容については後述する。

その後、開発支援サーバ１００のテスト実行部１２０が、初期処理としてテスト経過時間をリセットした上で（Ｓ１３）、テストを実施する（Ｓ１４）。テストの実施の際は、テストケース管理テーブル１３２に登録された優先度が高いものから順に、もしくは優先度が所定の値より大きいものを、テストケース１３４とプログラム１３３をリポジトリ１３０から読み込んで実行し、テスト結果１３５をリポジトリ１３０に格納する。その後、テストの開始から所定の制限時間が経過したか否かを判定する（Ｓ１５）。所定の制限時間が経過していない場合は、ステップＳ１４に戻ってテスト実施を継続する。一方、所定の制限時間が経過している場合は、テスト実行を終了する。

以上の処理により、優先度の高いテストケース１３４に絞り込んでテストを実施することができ、テストの効率化を図ることができる。なお、ステップＳ１５で所定の制限時間の経過により実行されなかったテストケース１３４については、例えば、そのリストを保持しておき、夜間の定時処理などによって実施するようにしてもよい。また、所定の制限時間内でのステップＳ１４の実行においていずれかのテストケース１３４の実行が失敗した場合は、例えば、テスト実行処理の終了後、優先度が低いために実行をスキップしたテストケース１３４に対応するコミットについてもテストを実施し、どの時点で対象のテストケース１３４が失敗していたかを検証するのが望ましい。

＜処理フロー（優先度算出処理）＞
図７は、図６に示したテスト実行の処理フローにおける優先度算出処理（Ｓ１２）の流れの例について概要を示したフローチャートである。まず、開発支援サーバ１００の構成管理部１１０もしくはテスト実行部１２０が、テストの対象のプログラム１３３が登録されているリポジトリ１３０上のブランチの作業内容を判定する（Ｓ２１）。ブランチの作業内容は、例えば、図３に示したように、ブランチのネーミングルールに基づいて判断することができる。

ステップＳ２１でブランチがメインブランチであると判定された場合は、全体について回帰テスト（リグレッションテスト）を実行するものとして、テストケース１３４のうち、テスト種別が「回帰テスト」であるものを選択して抽出する（Ｓ２２）。抽出に際しては、対象のテストケース１３４が必ず実行対象となるよう、優先度を最大値等に上げるようにしてもよい。すなわち、対象のテストケース１３４の優先度を最大値等に上げることは、対象のテストケース１３４を直接抽出することと等価である。テストケース１３４の種別は、例えば、後述するテストケース管理テーブル１３２に登録された内容によって判断してもよいし、テストケース１３４が格納されているフォルダの情報や、テストケース１３４に対して付与されたアノテーションの情報等に基づいて判断してもよい。

ステップＳ２１でブランチが機能ブランチであると判定された場合は、対象の機能に関連したテストを実行するものとして、テストケース１３４のうち、機能種別が対象の機能に対応するものを選択して抽出する（Ｓ２３）。ここでも、対象のテストケース１３４の優先度を最大値等に上げるようにしてもよい。テストケース１３４の機能種別は、例えば、後述するテストケース管理テーブル１３２や機能マスタ１３７に登録された内容によって判断してもよいし、対象の機能に係るプログラム１３３やテストケース１３４等が格納されているフォルダの情報や、アノテーションの情報等に基づいて判断してもよい。

ステップＳ２１でブランチが開発者ブランチであると判定された場合は、正常系のテストを実施する。まず、対象のプログラム１３３について前回のコミットからの経過時間が所定時間以上経過しているか否か（直近度が高いか否か）を判定する（Ｓ２４）。前回のコミットからの経過時間に代えて、過去数回のコミットの間隔の平均時間を用いてもよい。所定時間以上経過していない場合は、前回のテスト実施から時間があまり経過していない（直近度が高い）と推測されることから、テストの実行を行わずに先送りして間引くことでテスト間隔を調整するため、所定時間のタイマーを起動する（Ｓ２５）。

タイマーが終了するまでに次のテスト実行のトリガーが発生しない場合は、優先度算出処理を終了してテストの実施（図６のステップＳ１３以降）を自動的に行う。なお、直近度が高い場合に、テストの実行を先送りするのではなく、前回実施したテストケース１３４とは異なるテストケース１３４が抽出されるよう、これらのテストケース１３４の優先度を高くするようにしてもよい。

一方、ステップＳ２４で前回のコミットから所定時間以上経過している（直近度が低い）場合は、次に、対象のプログラム１３３の変更部分の差分量が所定以上あるか否かを判定する（Ｓ２６）。差分量が所定より少ない場合は、テスト実施の必要度が低いと判断し、ステップＳ２５に進んでテストの実行を先送りする。ステップＳ２６で差分量が所定以上ある場合は、テストを実行するためにタイマーを解除し（Ｓ２７）、テストケース１３４の抽出を行う（Ｓ２８）。

テストケース１３４の抽出では、下記の観点を用いて各テストケース１３４に優先度を設定して優先度の高いものが抽出されるようにすることができる。例えば、開発部分との関連度の高いテストケースとして、ブランチのネーミングルールから判別できる機能の種類によって、対応する機能に関連するテストケースを選択したり、対象のプログラム１３３を開発した開発者に割り当てられているタスクやロールなどに基づいて、これらの関連するテストケース１３４を選択することができる。すなわち、開発者がアプリケーションにおけるＰ層（プレゼンテーション層）を担当する開発者であるか、Ｆ層（ファンクション層）やＤ層（データ層）を担当する開発者であるかに応じて、Ｐ層、Ｆ層、Ｄ層に対応するテストケース１３４の優先度を高くすることができる。

また、対象のプログラム１３３の開発者自身が作成したテストケース１３４について優先度を高くするようにしてもよい。また、前回のテスト実施時に実行されなかったテストケース１３４、もしくは前回実施されてから所定時間以上実施されていないテストケース１３４について、一定期間テストがされていないことから、これらのテストケース１３４が抽出されるよう優先度を高く設定するようにしてもよい。

なお、図７の例では、テスト対象のブランチがメインブランチか機能ブランチか開発者ブランチかによって作業内容を判定し、テストケース１３４の抽出（優先度の設定）の手法を切り替えているが、対象となるブランチの作業内容としては上記のものに限らず、例えば、バグ対策やリリース準備、レビュー依頼など他の作業内容であることを判定するようにしてもよい。

また、ブランチの内容によるもの以外に、テストを実施するトリガーとなったコミットの種類に基づいて作業内容を判定することもできる。例えば、対象のコミットが複数のブランチのマージコミットである場合は、機能統合の作業を行っていると推測されることから、全テストケースが実行されるようにしてもよい。また、対象のコミットが通常コミットの場合は、開発内容のアップデートがあったと推測されることから、回帰テストが実行されるよう、対応するテストケース１３４の優先度を高くするようにしてもよい。さらに、コミットの種類の他に、例えば、開発者ブランチが作成されるトリガーとなった課題（Ｉｓｓｕｅ）の種別に基づいて関連するテストケース１３４の優先度を高くするようにしてもよい。

また、プログラム開発の進捗度（成熟度）に基づいて関連するテストケース１３４が抽出されるように優先度を設定することもできる。例えば、開発したプログラム（ソースコード）に対するレビューの件数や、その結果（ＯＫ／ＮＧの件数）に応じて、進捗度をスコアリングし、進捗度が所定のレベルより低いと判定される場合には全てのテストケース１３４が実行され、進捗度が所定のレベルより高いと判定される場合には重要なテストケース１３４のみ実行されるように優先度を設定することができる。

図８は、プログラム１３３に対するレビューの処理の流れの例について概要を示したフローチャートである。まず、レビューの要求者が、自身の開発用クライアント２００を用いて、レビュー対象のプログラム１３３を開発支援サーバ１００のリポジトリ１３０から取得し、対象箇所のページをＷｅｂブラウザ２１０上などに表示させる（Ｓ４１）。その後、レビュー要求者が、レビュアーに対するコメントやレビューポイントなどを入力し（Ｓ４２、Ｓ４３）、プログラム１３３をコミットすることによって、レビュー要求を開発支援サーバ１００に対して送信する（Ｓ４４）。

開発支援サーバ１００では、レビュー要求を受信して、当該要求に係る情報を、例えば、リポジトリ１３０上の後述するレビュー管理テーブル１３６に登録する。その後、レビュアーが、自身の開発用クライアント２００を用いて対象のプログラム１３３の該当箇所をリポジトリ１３０から取得してレビューを実施すると（Ｓ４６）、レビュー結果に基づいて開発支援サーバ１００の構成管理部１１０等がレビュー管理テーブル１３６の内容を更新する（Ｓ４７）。

上記のようなレビューの件数や結果の情報の他にも、プログラム開発の進捗度を判断する指標としては、例えば、ソースコード中のいわゆる“ＴＯＤＯコメント”の数や空メソッドの数などに基づいて算出するソースコードの完成度や、対象のプログラム１３３に関連するテストケース１３４に対するレビューの進捗度などを用いることができる。また、前回実施したテストの結果、例えば成否の結果の割合や、成功の件数などを用いることもできる。

＜データ構成＞
図９は、開発支援サーバ１００のリポジトリ１３０上に保持されるテストケース管理テーブル１３２のデータ構成と具体的なデータの例について概要を示した図である。テストケース管理テーブル１３２は、テストケース１３４の種類などを含む関連情報を保持するテーブルであり、例えば、Ｎｏ．、テストクラス、機能種別、テスト種別、作成者、および優先度などの各項目を有する。

Ｎｏ．の項目は、各テストケース１３４を一意に識別することができるよう割り振られたシーケンス番号などの情報を保持する。テストクラスの項目は、対象のテストケース１３４として実行するテスト用プログラム（クラス）を特定する名称の情報を保持する。機能種別の項目は、対象のテストケース１３４が対応するアプリケーション上の機能の種別を特定するコード値等の情報を保持する。図９の例では、便宜上、“ＵＩ（User Interface）系”や、“ＤＢ系”、“ロジック系”などの名称によって示されている。

テスト種別の項目は、対象のテストケース１３４が対応するテストの種別を特定するコード値等の情報を保持する。図９の例では、便宜上、“リグレッション”、“正常系”、“異常系”などの名称によって示されている。作成者の項目は、対象のテストケース１３４を作成した開発者等のユーザを識別するＩＤ等の情報を保持する。この識別情報は、後述する開発者マスタ１３８に設定されている。優先度の項目は、対象のテストケース１３４に対して、上記の図７において示したような優先度算出処理によって算出された優先度の情報を保持する。図９の例では、優先度の値は“１”（抽出対象）もしくは“−１”（非抽出対象）となっているが、優先度の設定方法はこれに限らず、例えば、“１”〜“１０”や“１”〜“１００”等の数値範囲として設定したり、“Ａ”、“Ｂ”、“Ｃ”のようなランクにより設定したりすることも可能である。

図１０は、リポジトリ１３０上に保持されるブランチ管理テーブル１３１のデータ構成と具体的なデータの例について概要を示した図である。ブランチ管理テーブル１３１は、開発支援サーバ１００のリポジトリ１３０上に作成されたブランチを管理するテーブルであり、例えば、ブランチ名、およびファイルリストなどの各項目を有する。

ブランチ名の項目は、各ブランチを一意に識別することができる名称の情報を保持する。この名称は、例えば、図３に示したように、所定のネーミングルールに基づいて設定され、名称から対象のブランチの種別や作業内容等を判別することができるものとする。ファイルリストの項目は、対象のブランチに登録されているプログラム１３３が含まれるファイルのリストからなる情報を保持する。図１０の例では、便宜上ファイル名を列挙したデータとしているが、対象の全ファイル（プログラム１３３）を特定することができるデータ構造であればこれに限定されない。

図１１は、リポジトリ１３０上に保持されるコミット履歴１３１ａのデータ構成と具体的なデータの例について概要を示した図である。コミット履歴１３１ａは、ブランチにプログラム１３３を登録（コミット）した履歴の情報を保持するテーブルであり、例えば、ブランチ名、コミット日時、および修正内容などの各項目を有する。

ブランチ名の項目は、プログラム１３３が登録されたブランチを特定するブランチ名の情報を保持する。ブランチ名の情報は、上述した図１０のブランチ管理テーブル１３１に登録されている。コミット日時の項目は、対象のブランチにプログラム１３３がコミットされたタイムスタンプの情報を保持する。修正内容の項目は、対象のブランチに対して修正・変更分としてコミットされたプログラム１３３が含まれるファイル名の情報を保持する。

図１２は、機能マスタ１３７のデータ構成と具体的なデータの例について概要を示した図である。機能マスタ１３７は、開発対象の機能についてのマスタ情報を保持するテーブルであり、例えば、機能名、および機能種別などの各項目を有する。機能名の項目は、対象の機能を一意に識別するためのＩＤや名称等の情報を保持する。この名称は、上述したブランチのネーミングルールにおいて用いられるものである。機能種別の項目は、上述の図９の例における機能種別の項目と同様に、対象の機能の種別を特定するコード値等の情報を保持する。

図１３は、開発者マスタ１３８のデータ構成と具体的なデータの例について概要を示した図である。開発者マスタ１３８は、各開発者についてのマスタ情報を保持するテーブルであり、例えば、ユーザ名、および担当業務の各項目を有する。ユーザ名の項目は、対象の開発者を一意に識別することができるＩＤ等の識別情報を保持する。担当業務の項目は、対象の開発者がプログラム開発において担当する１つ以上の業務やタスク、ロール等を特定するためのコード値等の情報を保持する。

図１４は、リポジトリ１３０上に保持されるレビュー管理テーブル１３６のデータ構成と具体的なデータの例について概要を示した図である。レビュー管理テーブル１３６は、開発対象のプログラム１３３を含むブランチを分岐元のブランチにマージする際のレビューについて管理するテーブルであり、例えば、マージ要求、マージ対象、マージ先、レビュー件数、およびレビュースコアなどの各項目を有する。

マージ要求の項目は、各マージ要求を一意に識別することができるシーケンス番号やＩＤ等の情報を保持する。マージ対象およびマージ先の項目は、それぞれ、マージの対象となるマージ元のブランチ、およびマージ先（分岐元）のブランチを特定するブランチ名の情報を保持する。レビュー件数の項目は、対象のブランチのマージに係るレビュー要求に対して実施されたレビューの件数の情報を保持する。レビュー要求に対して複数のレビュアーが並行的にレビューを行うことも可能である。レビュースコアの項目は、対象のブランチのマージに係るレビューのスコアの情報を保持する。スコアが高ければ対象のプログラム１３３の品質は高いものと推測され、テストケース１３４の実行を重要なものに限定して行うなどの効率化を図ることも可能となる。

なお、上述の図９〜図１４で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

以上に説明したように、本発明の一実施の形態である開発支援システム１によれば、ソーシャルコーディングの環境において、プログラム１３３の開発状況や、テスト実施といった各種観点を考慮した上で、重要なテストケース１３４を抽出し、あるいは優先的に実施することが可能である。これにより、膨大な数のテストケースを網羅的に全て実施することなく、効率的なテストの実施が可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

本発明は、プログラムの不具合確認等のためのテストにおけるテストケースを抽出する開発支援システムに利用可能である。

１…開発支援システム、
１００…開発支援サーバ、１１０…構成管理部、１２０…テスト実行部、１３０…リポジトリ、１３１…ブランチ管理テーブル、１３１ａ…コミット履歴、１３２…テストケース管理テーブル、１３３…プログラム、１３４…テストケース、１３５…テスト結果、１３６…レビュー管理テーブル、１３７…機能マスタ、１３８…開発者マスタ、
２００…開発用クライアント、２０１…テストケース付加情報、２１０…Ｗｅｂブラウザ、２２０…コード記述部、２３０…構成管理操作部、
３００…ネットワーク
４０１…マスタブランチ、４０２…開発用ブランチ、４０３…機能Ａ開発用ブランチ、４０４…機能Ａ開発者ＸＸＸ用ブランチ

Claims (15)

1. １つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
   前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
   前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
   前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
   前記構成管理部は、前記プログラムの開発状況を判定して、前記開発状況に基づいて前記各テストケースに優先度を設定し、
   前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。
2. 請求項１に記載の開発支援システムにおいて、
   前記構成管理部は、前記プログラムが登録されているブランチに基づいて前記開発状況を判定する、開発支援システム。
3. 請求項１に記載の開発支援システムにおいて、
   前記構成管理部は、前記プログラムを対応するブランチにコミットした際の当該コミットの種別に基づいて前記開発状況を判定する、開発支援システム。
4. 請求項１に記載の開発支援システムにおいて、
   前記構成管理部は、前記プログラムの開発に係る課題の種別に基づいて前記開発状況を判定する、開発支援システム。
5. 請求項１に記載の開発支援システムにおいて、
   前記構成管理部は、前記プログラムの開発者に割り当てられているタスクの種別に基づいて前記開発状況を判定する、開発支援システム。
6. １つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
   前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
   前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
   前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
   前記構成管理部は、前記プログラムの開発の進捗度を算出して、前記進捗度に基づいて前記各テストケースに優先度を設定し、
   前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。
7. 請求項６に記載の開発支援システムにおいて、
   前記構成管理部は、ブランチに登録された前記プログラムに対するレビューの件数に基づいて前記進捗度を算出する、開発支援システム。
8. 請求項６に記載の開発支援システムにおいて、
   前記構成管理部は、ブランチに登録された前記プログラムに対するレビューのスコアに基づいて前記進捗度を算出する、開発支援システム。
9. 請求項６に記載の開発支援システムにおいて、
   前記構成管理部は、ブランチに登録された前記プログラムにおけるＴＯＤＯコメントの記載の数に基づいて前記進捗度を算出する、開発支援システム。
10. １つ以上のテストケースの実行によりプログラムをテストする開発支援システムであって、
    前記プログラムおよび前記各テストケースをリポジトリに保持して管理する構成管理部と、
    前記テストケースを実行してテスト結果を前記リポジトリに格納するテスト実行部と、を有し、
    前記テストケースは、その種類の情報と関連付けて前記リポジトリにおいて管理され、
    前記構成管理部は、前記プログラムがブランチに登録されたタイミングに基づいて、登録の直近度を算出して、前記直近度に基づいて前記各テストケースに優先度を設定し、
    前記テスト実行部は、前記優先度に基づいて、実行する前記テストケースを抽出する、開発支援システム。
11. 請求項１０に記載の開発支援システムにおいて、
    前記構成管理部は、前記プログラムがブランチに前回登録されたタイミングから、今回登録されたタイミングまでの時間間隔に基づいて前記直近度を算出する、開発支援システム。
12. 請求項１０に記載の開発支援システムにおいて、
    前記構成管理部は、前記プログラムがブランチに登録された過去の所定の回数における、登録間の時間間隔の平均値に基づいて前記直近度を算出する、開発支援システム。
13. 請求項１０に記載の開発支援システムにおいて、
    前記構成管理部は、ブランチに登録された前記プログラムにおける前回の登録からの差分量に基づいて前記直近度を算出する、開発支援システム。
14. 請求項１０に記載の開発支援システムにおいて、
    前記構成管理部は、前記直近度が高い場合に、前記テスト実行部により前記テストケースが抽出されないようにする、開発支援システム。
15. 請求項１０に記載の開発支援システムにおいて、
    前記構成管理部は、前記直近度が高い場合に、前回のテスト実施時に実行された前記テストケースとは異なる前記テストケースの前記優先度を高くする、開発支援システム。

Images