JP2018156164A - テスト範囲出力プログラム、テスト範囲出力装置及びテスト範囲出力方法 - Google Patents

Abstract

【課題】医療リスクに関わる機能に対するテスト漏れを効率的に防止可能とすること。【解決手段】テスト範囲出力プログラムは、医療に関するコンピュータシステムのソースコードの変更を受け付け、前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定し、前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定し、医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する、処理をコンピュータに実行させる。【選択図】図３

Description

本発明は、テスト範囲出力プログラム、テスト範囲出力装置及びテスト範囲出力方法に関する。

電子カルテシステムをはじめとする医療システムの機能の中には、例えば、注射業務に関する機能やアレルギー情報を扱う機能等、当該機能の不具合が患者の身体に影響を与える可能性が高いハイリスクな機能（以下、「医療リスク機能」という。）が存在する。医療リスク機能の開発や改修において、バグ等が混入した場合、患者の身体が害される可能性が有るため、医療リスク機能の開発及び改修は、特に厳格に管理される必要がある。

特開２００８−０３３５４５号公報 特開２００９−１２２７５４号公報 特開平８−２９７５７０号公報 特開２０１４−２２８９０７号公報

しかしながら、診療報酬改定や医療システムの機能追加により医療リスク機能を改修する機会は度々発生する。また、医療システムの規模が大きくなるにしたがい、一つの医療リスク機能に対する影響範囲が広がるため、開発者がソースコードを変更する場合に、意図せずに医療リスク機能に影響を与える危険性が有る。斯かる危険性を回避して、医療リスク機能の品質を担保するために、闇雲にレビューやテストをすると、人的・時間的コストが増大してしまう。

そこで、一側面では、本発明は、医療リスクに関わる機能に対するテスト漏れを効率的に防止可能とすることを目的とする。

一つの態様では、テスト範囲出力プログラムは、医療に関するコンピュータシステムのソースコードの変更を受け付け、前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定し、前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定し、医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する、
処理をコンピュータに実行させる。

一側面として、医療リスクに関わる機能に対するテスト漏れを効率的に防止可能とすることができる。

本発明の実施の形態のシステム構成例を示す図である。 本発明の実施の形態における開発端末１０のハードウェア構成例を示す図である。 本発明の実施の形態における開発端末１０及びサーバ装置２０の機能構成例を示す図である。 開発端末１０が実行する処理手順の一例を説明するためのフローチャートである。 開発者情報記憶部２１の構成例を示す図である。 各ソースコードへの一意なタグ付けの一例を示す図である。 タグ情報記憶部２３の構成例を示す図である。 機能コード記憶部２４の構成例を示す図である。 メソッド間の参照関係に応じたタグ付けの一例を示す図である。 医療リスク機能記憶部２５の構成例を示す図である。 テスト範囲記憶部２６の構成例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態のシステム構成例を示す図である。図１において、サーバ装置２０と１以上の開発端末１０とは、ＬＡＮ（Local Area Network）、イントラネット、又はインターネット等のネットワークを介して接続される。

開発端末１０は、電子カルテシステム等の病院において利用されるコンピュータシステムである医療システムの開発者が、システムの開発に利用するＰＣ（Personal Computer）等の端末である。以下、本実施の形態において開発対象の医療システムを「対象システム」という。

サーバ装置２０は、各開発端末１０において共有される情報を記憶する１以上のコンピュータである。

図２は、本発明の実施の形態における開発端末１０のハードウェア構成例を示す図である。図２の開発端末１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

開発端末１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って開発端末１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等であり、様々な操作指示を入力させるために用いられる。

なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

なお、サーバ装置２０も図２に示されるようなハードウェア構成を有していてもよい。但し、サーバ装置２０は、表示装置１０６及び入力装置１０７を有さなくてもよい。

図３は、本発明の実施の形態における開発端末１０及びサーバ装置２０の機能構成例を示す図である。図３において、開発端末１０は、認証部１１、改修部１２、タグ付与部１３、差分抽出部１４、影響範囲特定部１５、テスト範囲判定部１６及び出力部１７等を有する。これら各部は、開発端末１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。一方、サーバ装置２０は、開発者情報記憶部２１、ソースコード記憶部２２、タグ情報記憶部２３、機能コード記憶部２４、医療リスク機能記憶部２５及びテスト範囲記憶部２６等を有する。これら各記憶部は、例えば、サーバ装置２０の補助記憶装置、又はサーバ装置２０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

認証部１１は、開発者の認証を行う。改修部１２は、開発者の指示に応じて対象システムのソースコードを改修（変更、編集又は生成等）する。タグ付与部１３は、ソースコード内の各メソッドの定義に対してタグを付与する。タグは、各メソッドの識別情報として用いられる。但し、他のメソッドから処理結果が参照される（呼び出される）メソッドには、参照元のメソッドのタグも付与される。

差分抽出部１４は、改修部１２による改修前後のソースコードの差分を抽出する。影響範囲特定部１５は、改修による影響範囲を特定する。影響範囲には、改修対象のメソッドと、当該メソッドの再帰的な参照元とが含まれる。テスト範囲判定部１６は、改修を行った開発者の経験や、改修の規模、及び影響範囲等に基づいて、当該改修に対して推奨されるテスト範囲を判定する。出力部１７は、テスト範囲判定部１６による判定結果を出力する。

開発者情報記憶部２１には、各開発者のＩＤ及びパスワードや、各開発者の開発経験を示す情報等が記憶されている。ソースコード記憶部２２には、対象システムのソースコード群が記憶されている。タグ情報記憶部２３には、タグごとに、当該タグの付与先のメソッドとの対応情報が記憶される。機能コード記憶部２４には、メソッドごとに、対象システムの機能の中で当該メソッドが対応する（当該メソッドによって実現される）機能の識別情報（以下、「機能コード」という。）が記憶されている。医療リスク機能記憶部２５には、対象システムの機能の中で医療的にハイリスクな機能（以下、「医療リスク機能」という。）の機能コードが記憶されている。テスト範囲記憶部２６には、改修を行った開発者の開発経験及び当該改修の規模、並びに当該改修の影響範囲における医療リスク機能の有無等に応じて、推奨されるテスト範囲を示す情報が記憶されている。

以下、開発端末１０が実行する処理手順について説明する。図４は、開発端末１０が実行する処理手順の一例を説明するためのフローチャートである。図４における処理手順は、或る開発者が開発端末１０を利用して、対象システムのソースコードの改修を行う状況において実行される。

例えば、開発端末１０において認証部１１によって表示装置１０６に表示されているログイン画面に対して、ユーザによって開発者ＩＤ及びパスワードが入力されると、認証部１１は、当該開発者ＩＤ及びパスワードの認証を実行する（Ｓ１０１）。認証は、開発者情報記憶部２１を参照して行われる。

図５は、開発者情報記憶部２１の構成例を示す図である。図５に示されるように、開発者情報記憶部２１には、対象システムの開発者ごとに、開発者ＩＤ、指名、パスワード、改修回数、総改修行数及び改修経験機能コード等を含む開発者情報が記憶されている。

開発者ＩＤは、開発者ごとの識別情報である。氏名は、開発者の氏名である。パスワードは、開発者のパスワードである。改修回数は、対象システムのソースコードの改修の回数である。例えば、改修回数は、ログインの回数によって評価されてもよい。総改修行数は、対象システムのソースコードを改修した行数（ステップ数）の累積値である。改修経験機能コードとは、対象システムが有する機能のうち、開発者がこれまでに改修したことのある機能の機能コードの一覧である。

ステップＳ１０１では、入力された開発者ＩＤ及びパスワードを含む開発者情報が開発者情報記憶部２１に記憶されていれば、認証は成功し、開発者のログインは許可される。そうでなければ認証は失敗し、開発者のログインは拒否される。認証が成功した場合に限って、ステップＳ１０２以降が実行される。以下、ログインに成功したユーザを「ログインユーザ」という。

ステップＳ１０２において、タグ付与部１３は、ソースコード記憶部２２に記憶されている全てのソースコードへのタグの一括付与が実行済みであるか否かを判定する。斯かる判定は、例えば、タグ情報記憶部２３に１以上のレコードが記憶されているか否かに基づいて行われてもよい。すなわち、タグの一括付与は、いずれかの開発者のログインに伴って１回実行されればよい。または、タグの一括付与は、開発者のログインとは別に、事前に行われてもよい。

タグの一括付与が実行済みでない場合（Ｓ１０２でＮｏ）、タグ付与部１３は、各ソースコードに対して一意なタグ付けを付与する（Ｓ１０３）。

図６は、各ソースコードへの一意なタグ付けの一例を示す図である。図６には、２つのソースコードへのタグ付けの例が示されている。すなわち、図６において、上段は、ソースコードｃ１及びソースコードｃ２のそれぞれのタグ付け前の状態を示す。図６において下段は、ソースコードｃ１及びソースコードｃ２のそれぞれのタグ付け後の状態を示す。タグは、ソースコードに記述される処理手順に影響を与えない形式（例えば、コメント形式）で、ソースコード内に付与される。本実施の形態において、タグは、メソッドごとに付与され、メソッドごとに一意な文字列である。すなわち、タグは、メソッド間において呼び出し可能な単位ごとに付与される文字列である。

具体的には、ソースコードｃ１には、タグｔ１を含む記述（「／／ｔａｇ１／／」）が付与されている。当該記述（以下「タグ記述」という。）のうち、「ｔａｇ１」がタグの実体であり、タグの両側の「／／」は、タグをコメント化するための記号である。同様に、ソースコードｃ２には、「ｔａｇ２」というタグｔ２を含むタグ記述が付与されている。

続いて、タグ付与部１３は、タグとソースコードとの対応関係をタグ情報記憶部２３に記憶する（Ｓ１０４）。

図７は、タグ情報記憶部２３の構成例を示す図である。図７に示されるように、タグ情報記憶部２３には、いずれかのソースコード（メソッド）に付与されたタグごとに、タグ、クラス名、メソッド名及び機能コード等が記憶される。

クラス名及びメソッド名は、タグが付与されたメソッドのクラス名及びメソッド名である。機能コードは、当該メソッドが対応する機能の機能コードである。なお、本実施の形態では、対象システムにおいてクラス名の重複が無いこととする。したがって、クラス名及びメソッド名によって、１つのメソッド及び当該メソッドのソースコードを特定可能である。例えば、対象システムにおいて、複数のネームスペースが定義される場合、各ネームスペースの識別情報が、各タグに関連付けられればよい。

各タグに対応する機能コードは、機能コード記憶部２４を参照して特定される。図８は、機能コード記憶部２４の構成例を示す図である。図８に示されるように、機能コード記憶部２４には、クラス名に対応付けられて当該クラス名に係るクラスに対応する機能の機能コードが予め記憶されている。したがって、タグ付与部１３は、各タグが付与されたメソッドのクラス名に基づいて、当該タグに対応する機能コードを特定することができる。

続いて、タグ付与部１３は、メソッド間の参照関係に応じたタグ付けを、他のメソッドから参照される（呼び出される）メソッドを含むソースコードに対して実行する（Ｓ１０５）。例えば、図６のソースコードｃ１において、ｔａｇ１が付与されているＩｎｊｅｃｔメソッド内の記述ｄ１では、ＧｅｔＰａｔｉｅｎｔメソッドが呼び出されている。一方、ソースコードｃ２は、ＧｅｔＰａｔｉｅｎｔメソッドのソースコードである。この場合、ソースコードｃ２のＧｅｔＰａｔｉｅｎｔメソッドに対して、ソースコードｃ１のＩｎｊｅｃｔメソッドから参照されていること（Ｉｎｊｅｃｔメソッドが依存していること）を示すタグが付与される。

図９は、メソッド間の参照関係に応じたタグ付けの一例を示す図である。図９において、ソースコードｃ２には、タグｔ２の後に「：（コロン）」が付与され、更に、タグｔ１が付与されている。このことは、ソースコードｃ２のＧｅｔＰａｔｉｅｎｔメソッドが、タグｔ１（「ｔａｇ１」）が付与された他のメソッドから参照されていることを示す。つまり、タグ記述において「：（コロン）」以降のタグは、当該メソッドの参照元のメソッドのタグを示す。

なお、１つのメソッドは、複数のメソッドから参照されうる。複数のメソッドから参照されるメソッドのタグ記述には、当該複数のメソッドに付与されたタグが、「，（カンマ）」で区切られて付与される。例えば、ＧｅｔＰａｔｉｅｎｔメソッドが、更に、「ｔａｇ３」が付与されたメソッドからも参照されている場合、ＧｅｔＰａｔｉｅｎｔメソッドに付与されるタグは、「／／ｔａｇ２／／：／／ｔａｇ１，ｔａｇ３／／」となる。

ステップＳ１０５では、メソッド間の全ての参照関係において、参照先となるメソッドに対して、参照元のタグが付与される。

ステップＳ１０２でＹｅｓの場合、又はステップＳ１０５に続いて、改修部１２は、ソースコードの改修をログインユーザから受け付ける（Ｓ１０６）。例えば、既存のソースコードが編集されたり、新たなソースコードが追加されたりする。開発者によるコーディング作業が終了すると（Ｓ１０７でＹｅｓ）、差分抽出部１４は、改修された１以上のソースコードについて、改修前後の差分を抽出する（Ｓ１０８）。

続いて、タグ付与部１３は、改修によって新たなメソッドが追加された場合、当該メソッドの定義内に、当該メソッドに対するタグを付与すると共に、当該タグに対応するレコードをタグ情報記憶部２３に追加する（Ｓ１０９）。ここでのタグの付与は、ステップＳ１０３及びＳ１０４と同様の処理である。

続いて、タグ付与部１３は、改修対象のメソッド内に新たに他のメソッドの参照（呼び出し）が追加された場合、当該他のメソッドのタグ記述に対して改修対象のメソッドのタグを参照元のタグとして付与する（Ｓ１１０）。ここでのタグの付与は、ステップＳ１０５と同様の処理である。

続いて、影響範囲特定部１５は、改修対象とされたメソッド（以下、「対象メソッド」という。）のタグを対象タグとし、対象タグを影響範囲リストに追加する（Ｓ１１１）。対象タグは、改修対象とされたメソッドに付与されているタグ記述の先頭（コロンの前）のタグである。また、影響範囲リストとは、対象メソッドの改修によって影響を受ける（動作が変化する可能性の有る）メソッドのタグを格納するためのデータをいう。通常、メソッドＡを参照するメソッドＢ（メソッドＡに依存するメソッドＢ）は、メソッドＡの改修によって影響を受ける。したがって、影響範囲リストは、対象メソッドの参照元を再帰的に辿ることで特定される各メソッドのタグが格納されるデータである。

続いて、影響範囲特定部１５は、対象メソッドのタグ記述において、参照元として付与されているタグ（すなわち、参照元のタグ）を特定する（Ｓ１１２）。例えば、当該タグ記述が「／／ｔａｇ２／／：／／ｔａｇ１，ｔａｇ３／／」であれば、対象タグは「ｔａｇ２」であり、「ｔａｇ１」及び「ｔａｇ３」が、参照元として特定される。

続いて、影響範囲特定部１５は、参照元のタグが特定されたか否かを判定する（Ｓ１１３）。すなわち、対象メソッドのタグ記述に参照元のタグが１以上含まれていたか否かが判定される。参照元のタグが特定された場合（Ｓ１１３でＹｅｓ）、影響範囲特定部１５は、参照元の各タグを影響範囲リストに追加する（Ｓ１１４）。続いて、影響範囲特定部１５は、参照元の各タグのクラス名及びメソッド名（ソースコード）を、タグ情報記憶部２３（図７）を参照して特定する（Ｓ１１５）。なお、本実施の形態では、クラス名及びメソッド名に基づいてソースコードを格納したファイルが一意に特定されることとする。

続いて、影響範囲特定部１５は、各参照元のタグを再帰的に対象タグとし、ステップＳ１１５において特定されたメソッドを、再帰的に対象メソッドとして（Ｓ１１６）、ステップＳ１１２以降を繰り返す。その結果、参照元のルート（根元）まで、影響範囲が走査される。

なお、改修対象のメソッドが複数である場合、ステップＳ１１１以降は、複数のタグが起点とされて再帰的に実行される。

再帰的な走査が終了すると（Ｓ１１３でＮｏ）、テスト範囲判定部１６は、影響範囲リストに含まれている各タグに対応する機能コードをタグ情報記憶部２３（図７）から取得する（Ｓ１１７）。続いて、テスト範囲判定部１６は、ステップＳ１１７において取得された機能コードの中に、医療リスク機能記憶部２５に記憶されている機能コードが有るか否かを判定する（Ｓ１１８）。すなわち、今回の改修について、医療リスク機能への影響の有無が判定される。

図１０は、医療リスク機能記憶部２５の構成例を示す図である。図１０に示されるように、医療リスク機能記憶部２５には、医療リスク機能ごとに、機能コード及び機能名称が記憶されている。なお、医療リスク機能については、リスク分析等によって洗い出しが行われてもよい。

続いて、テスト範囲判定部１６は、ログインユーザの開発経験情報を開発者情報記憶部２１（図５）から取得する（Ｓ１１９）。ログインユーザの開発者ＩＤは、ステップＳ１０１において入力されている。したがって、当該開発者ＩＤを含む開発者情報のうち、改修回数、総改修行数及び改修経験機能コードが、当該開発経験情報として開発者情報記憶部２１（図５）から取得される。

続いて、テスト範囲判定部１６は、今回の改修によって対象システムに異常が発生する（バグが混入する）リスク（以下、「改修リスク」という）を算出する（Ｓ１２０）。改修リスクは、改修を行った開発者の開発経験情報、及び改修の規模に基づいて算出される。開発者の開発経験（スキル）が豊富なほどバグが混入するリスクは低くなり、改修の規模が大きいほどバグが混入するリスクは高くなると考えられるからである。一例として、改修リスクは、以下の計算式に基づいて算出されてもよい。

改修リスクｆ＝今回の改修行数／（過去の総改修行数／過去の改修回数））×５０×ａ＋開発者の過去の総改修行数／全開発者の平均総改修行数×５０×ｂ
ａ＋ｂ＝１
但し、ｆが１００を上回る場合は１００に丸める。また、ａ及びｂは、改修行数の多寡によるリスクと、開発者の経験によるリスクの重み付けを決める係数であり、例えば、試行錯誤的に決定される。

例えば、ログインユーザの開発者ＩＤが「ＦＪ１９９９９９」であれば、図５より、改修回数＝４９、総改修行数＝２３，２３２行である。また、今回の改修行数が、２００行であり、全開発者の平均総改修行数が、２０，４００行であり、ａ＝０．３，ｂ＝０．７であるとする。この場合、改修リスクｆは、以下のように算出される。

改修リスクｆ＝２００／（２３，２３２／４９）×５０×０．３＋２３，２３２／２０４００×５０×０．７＝４６．２
なお、今回の改修行数は、例えば、ステップＳ１０８において抽出されている差分の行数である。

続いて、テスト範囲判定部１６は、テスト範囲記憶部２６を参照して、推奨されるテスト範囲を判定する（Ｓ１２１）。

図１１は、テスト範囲記憶部２６の構成例を示す図である。図１１に示されるように、テスト範囲記憶部２６には、改修リスクレベルと医療リスク機能有無との組み合わせごとに、推奨テスト範囲が記憶されている。

改修リスクレベルは、改修リスクｆの範囲によって、改修リスクｆを小、中、大の３つのレベルに分類する項目である。医療リスク機能有無は、今回の改修による影響範囲に医療リスク機能が有るか否かを区別する項目である。具体的には、医療リスク機能有無は、ステップＳ１１８における判定結果が当てはめられる項目である。すなわち、影響範囲に医療リスク機能が有るか否かによってテスト範囲が異なる。

推奨テスト範囲は、（１）〜（４）の４つのテスト範囲の中から、推奨されるテスト範囲を示す項目である。（１）〜（４）の意味は以下の通りである。
（１）軽微な修正のため、改修したメソッドをテスト範囲とし、改修したメソッドの入力パターン（メソッドの引数の入力パターン）の組み合わせについて、ペアワイズ法などでテストパターンを削減してもよい。
（２）医療リスク機能に影響を与えうるため、影響範囲内の医療リスク機能について特に入念にテストする。すなわち、（１）に加え、影響範囲内の医療リスク機能について、全てのテストパターンの組み合わせを検証する。
（３）改修のリスクは中程度であるため、改修したメソッドに加えて影響範囲内のメソッドもテスト範囲に含める。また、改修したメソッド及び影響範囲内のメソッドについて、直行法などによるテストパターンの削減を許容しつつも全て検証をする。
（４）影響が大きいため、影響範囲を含め入念にテストする。基本的には、改修したメソッド及び影響範囲内のメソッドについて全ての入力の組み合わせを検証する。

したがって、ステップ１２１では、ステップＳ１２０における改修リスクｆの算出結果、及びステップＳ１１８の判定結果に基づいて、テスト範囲が（１）〜（４）の中から選択される。なお、テスト範囲の区分は、図１１に示したものに限定されない。

続いて、出力部１７は、ログインユーザの開発者情報を更新する（Ｓ１２２）。具体的には、開発者情報記憶部２１（図５）において、ログインユーザの開発者ＩＤに対応する総改修行数に、今回の改修行数が加算される。また、当該開発者ＩＤに対応する改修経験機能コードに、今回の改修対象のメソッドのタグに対応する機能コードが追加される。また、当該開発者ＩＤに対応する改修回数が更新される。改修回数が、例えば、ログイン回数によってカウントされる場合、１が加算される。但し、ログインしたとしても改修を行っていない場合（例えば、今回の改修行数が０である場合）、改修回数の更新は行われない。

続いて、出力部１７は、ステップＳ１２１におけるテスト範囲の判定結果に基づいて、テスト指示を出力する（Ｓ１２３）。具体的には、テスト範囲の判定結果が（１）である場合、出力部１７は、改修対象のメソッドのクラス名及びメソッド名をテスト範囲として出力すると共に、当該メソッドの入力パターン（メソッドの引数の入力パターン）の組み合わせについて、ペアワイズ法などでテストパターンを削減してもよい旨を出力する。

テスト範囲の判定結果が（２）である場合、出力部１７は、（１）の場合と同様の出力に加え、ステップＳ１１８において医療リスク機能であると判定されたクラス名及びメソッド名について全てのテストパターンの組み合わせ検証する旨を出力する。

テスト範囲の判定結果が（３）である場合、出力部１７は、影響範囲リストにタグが含まれている全てのクラス名及びメソッド名をテスト範囲として出力すると共に、直行法などによるテストパターンの削減を許容しつつも全て検証をする旨を出力する。

テスト範囲の判定結果が（４）である場合、出力部１７は、影響範囲リストにタグが含まれている全てのクラス名及びメソッド名をテスト範囲として出力すると共に、これら全てのメソッドについて全ての入力の組み合わせを検証する旨を出力する。

なお、出力の形態は、表示装置１０６への表示であってもよいし、プリンタへの出力であってもよい。又は、出力内容が記述されたファイルが補助記憶装置１０２に記憶されてもよい。

上述したように、本実施の形態によれば、ソースコードが改修（変更）された場合、各メソッドに付与されたタグ記述に基づいて、改修の影響範囲が特定されて、当該影響範囲に医療リスク機能が含まれているか否かが判定される。当該当該影響範囲に医療リスク機能が含まれている場合には、そうでない場合と異なるテスト範囲が出力される。したがって、医療リスクに関わる機能に対するテスト漏れを効率的に防止可能とすることができる。

また、改修を行った開発者の開発経験や改修の規模に応じてテスト範囲を変化させることができる。したがって、改修に応じた適切なテスト範囲を提示することできる。

なお、本実施の形態において、医療リスク機能記憶部２５は、記憶部の一例である。開発端末１０は、テスト範囲出力装置の一例である。改修部１２は、受付部の一例である。影響範囲特定部１５は、特定部の一例である。テスト範囲判定部１６は、判定部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
医療に関するコンピュータシステムのソースコードの変更を受け付け、
前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定し、
前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定し、
医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する、
処理をコンピュータに実行させることを特徴とするテスト範囲出力プログラム。
（付記２）
前記出力する処理は、前記変更を行った開発者の開発経験を示す情報に基づいて、出力するテスト範囲を変化させる、
ことを特徴とする付記１記載のテスト範囲出力プログラム。
（付記３）
前記出力する処理は、前記変更の規模に基づいて、出力するテスト範囲を変化させる、
ことを特徴とする付記１又は２記載のテスト範囲出力プログラム。
（付記４）
医療に関するコンピュータシステムのソースコードの変更を受け付ける受付部と、
前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定する特定部と、
前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定する判定部と、
医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する出力部と、
を有することを特徴とするテスト範囲出力装置。
（付記５）
前記出力部は、前記変更を行った開発者の開発経験を示す情報に基づいて、出力するテスト範囲を変化させる、
ことを特徴とする付記４記載のテスト範囲出力装置。
（付記６）
前記出力部は、前記変更の規模に基づいて、出力するテスト範囲を変化させる、
ことを特徴とする付記４又は５記載のテスト範囲出力装置。
（付記７）
医療に関するコンピュータシステムのソースコードの変更を受け付け、
前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定し、
前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定し、
医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する、
処理をコンピュータが実行することを特徴とするテスト範囲出力方法。
（付記８）
前記出力する処理は、前記変更を行った開発者の開発経験を示す情報に基づいて、出力するテスト範囲を変化させる、
ことを特徴とする付記７記載のテスト範囲出力方法。
（付記９）
前記出力する処理は、前記変更の規模に基づいて、出力するテスト範囲を変化させる、
ことを特徴とする付記７又は８記載のテスト範囲出力方法。

１０ 開発端末
１１ 認証部
１２ 改修部
１３ タグ付与部
１４ 差分抽出部
１５ 影響範囲特定部
１６ テスト範囲判定部
１７ 出力部
２０ サーバ装置
２１ 開発者情報記憶部
２２ ソースコード記憶部
２３ タグ情報記憶部
２４ 機能コード記憶部
２５ 医療リスク機能記憶部
２６ テスト範囲記憶部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
Ｂ バス

Claims (5)

1. 医療に関するコンピュータシステムのソースコードの変更を受け付け、
   前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定し、
   前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定し、
   医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する、
   処理をコンピュータに実行させることを特徴とするテスト範囲出力プログラム。
2. 前記出力する処理は、前記変更を行った開発者の開発経験を示す情報に基づいて、出力するテスト範囲を変化させる、
   ことを特徴とする請求項１記載のテスト範囲出力プログラム。
3. 前記出力する処理は、前記変更の規模に基づいて、出力するテスト範囲を変化させる、
   ことを特徴とする請求項１又は２記載のテスト範囲出力プログラム。
4. 医療に関するコンピュータシステムのソースコードの変更を受け付ける受付部と、
   前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定する特定部と、
   前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定する判定部と、
   医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する出力部と、
   を有することを特徴とするテスト範囲出力装置。
5. 医療に関するコンピュータシステムのソースコードの変更を受け付け、
   前記変更の対象となるソースコードにより実現される第１の機能を特定すると共に、前記第１の機能による処理結果を参照する第２の機能を特定し、
   前記コンピュータシステムの機能ごとに医療リスクに関わる機能を示す情報を記憶した記憶部を参照して、特定した前記第１の機能及び前記第２の機能のいずれかが医療リスクに関わる機能か否かを判定し、
   医療リスクに関わる機能であると判定された場合に、医療リスクに関わる機能に関係するソースコードの変更が行われない場合のテスト範囲とは異なるテスト範囲を、前記ソースコードの変更に対するテスト範囲として出力する、
   処理をコンピュータが実行することを特徴とするテスト範囲出力方法。

Images