(57)【要約】【課題】複数の制御装置が通信接続された制御システムの表示装置を含む組合せ試験のシナリオ自動実行、表示装置の画面に表示された結果の自動判定を行う。【解決手段】入力データ再生部３０２は、試験シナリオ３０３に書かれた入力データを１つずつ再生する。描画命令保存部３０５は被試験ソフトウェア３１３が実行する描画命令を描画命令ログ３０６に保存する。属性名／描画命令対応表３０４には描画命令と試験シナリオ３０３に記述された属性名との対応が記述されている。描画命令ログ３０６と試験シナリオ３０３と属性名／描画命令対応表３０４を用いて結果判定部３０１が自動で試験結果を判定する。【選択図】図３
2015141439.tif 000002
【特許請求の範囲】
【請求項１】
表示アプリケーションを有する被試験ソフトウェアを判定する試験装置であって、
前記表示アプリケーションでは、表示装置１５に表示される表示単位を構成する少なくとも一つの表示要素を表示する描画命令が、入力データに基づいて採用され、
前記入力データと、前記表示要素の表示形態を示す属性名及び前記属性名の期待値を含む確認事項とを関連づける試験シナリオと、
前記属性名と前記描画命令とを対応させる属性名／描画命令対応表と、
前記試験シナリオに基づいて前記入力データを前記被試験ソフトウェアに入力する入力データ再生部と、
前記表示アプリケーションで採用された前記描画命令が有する値と、前記試験シナリオに含まれる前記期待値とが一致するか否かで、前記被試験ソフトウェアの良否を判定する結果判定部と
を備えたソフトウェア試験装置。
【請求項２】
一の前記表示要素の前記表示形態を得るための前記描画命令は複数存在し、
前記属性名／描画命令対応表は、前記一の前記表示要素についての前記表示形態を得るための複数の前記描画命令が、前記一の前記表示要素についての前記表示形態を示す前記属性名と対応させる、請求項１記載のソフトウェア試験装置。
【請求項３】
前記被試験ソフトウェアは、制御アプリケーションをも有し、
前記制御アプリケーションでは、制御対象への操作を指定する制御アプリケーションデータが、入力データに基づいて採用され、
前記結果判定部は、前記入力データと前記制御アプリケーションデータとが一致するか否かも判定する、請求項１または請求項２に記載のソフトウェア試験装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、表示装置と複数の制御装置が接続された制御システムのソフトウェアの良否を試験する装置に関する。
【背景技術】
【０００２】
制御監視システムには、制御装置や当該制御装置の制御の対象となる被制御装置を表示する表示装置が設けられることがある。当該表示装置は、その画面において、制御装置や被制御装置を様々な図形や文字を用いて表現する。また当該表示装置は、その画面において、制御装置や被制御装置の状態を図形や文字の色、大きさ等を用いて表現する。かかる表示装置、あるいはこれを含む監視制御システムの試験では、かかる図形や文字を目視で判定する。
【０００３】
例えば特許文献１には、プラントなどの制御監視システムが開示されている。制御監視システムについての試験結果の画面画像は保存され、仕様書から生成した正解画像と比較される。これにより、人手による目視ではなく、自動で判定を行うことが可能である。
【０００４】
例えば特許文献２には、仕様書に記述されたＧＵＩ部の属性値と、被試験ソフトウェアの属性値を比較する技術が開示されている。これにより、画面の確認を自動で行うことが可能である。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−２２６６８３号公報
【特許文献２】特開平９−２２３０４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
（Ｉ）画面表示の試験結果が不良と判定された場合、画面表示から、その不良の原因を分析することが望ましい。具体的には、図形と文字が重なる表示を行うべく設計された画面仕様について、不良の原因が図形に由来するのか、文字に由来するのかを区別することが望ましい。同様に、図形同士が重なる表示を行うべく設計された画面仕様について、不良の原因がいずれの図形に由来するのかを区別すること（以下、原因の「切り分け」とも称す）が望ましい。
【０００７】
例えば、矩形の中に文字がある表示を行う場合、矩形と文字を重ねた画面仕様が設計される。かかる表示の良否の判定を、矩形と文字をまとめてこれらを１つの表示要素として把握して行う場合には、上記の区別はできない。つまり判定の結果が不良であった場合、矩形の色と文字列のどちらに由来して不良となったのか、原因が切り分けられない。
【０００８】
よって不良を招来した原因を区別するには、互いに重なりあって表示された図形や文字を分離する必要がある。しかしながら特許文献１に記載されているような、画像判定を用いた判定では、図形と文字列とを分離して判定することは困難である。
【０００９】
（ＩＩ）特許文献２では、被試験ソフトウェアのシステムが管理している属性名を用いて、仕様や期待値を定義している。このような場合に、被試験ソフトウェアのシステムの種類に応じて定義する内容を変更しなければならない。かかる技術では、異なるシステム間で共通の属性名を用いた定義は困難である。
【００１０】
（ＩＩＩ）同じ画面仕様を設計する方法が複数存在する場合がある。例えば、矩形を描画する場合、矩形自体を使用して描画する場合と、直線の描画を４回実行する場合がある。矩形の属性名を用いて期待値が定義されている一方で、ソフトウェアでは直線を用いて設計されている場合は、画面の表示自体は矩形であって仕様通りである。
【００１１】
しかし特許文献２のように、属性名同士を直接比較する場合、試験工程で不良と判定されてしまう。これは自動判定を正しく行うことが困難となる。
【００１２】
この発明は、上記のような問題点を解決するためになされたものであり、一つの表示単位において複数の表示要素が重なった場合でも適切に原因の切り分けを行うことを目的としている。
【００１３】
また、被試験ソフトウェアのシステムに依存しない属性名を用いた期待値の定義が可能な技術を提供することを目的とする。
【００１４】
更に、複数の画面設計方法に対応して自動判定が可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
この発明にかかるソフトウェア試験装置は、表示アプリケーションを有する被試験ソフトウェアを判定する試験装置である。前記表示アプリケーションでは、表示装置に表示される表示単位を構成する少なくとも一つの表示要素を表示する描画命令が、入力データに基づいて採用される。
【００１６】
そしてその第１の態様は、前記入力データと、前記表示要素の表示形態を示す属性名及び前記属性名の期待値を含む確認事項とを関連づける試験シナリオと、前記属性名と前記描画命令とを対応させる属性名／描画命令対応表と、前記試験シナリオに基づいて前記入力データを前記被試験ソフトウェアに入力する入力データ再生部と、前記表示アプリケーションで採用された前記描画命令が有する値と、前記試験シナリオに含まれる前記期待値とが一致するか否かで、前記被試験ソフトウェアの良否を判定する結果判定部と備える。
【００１７】
この発明にかかるソフトウェア試験装置の第２の態様は、その第１の態様であって、一の前記表示要素の前記表示形態を得るための前記描画命令は複数存在し、前記属性名／描画命令対応表は、前記一の前記表示要素についての前記表示形態を得るための複数の前記描画命令が、前記一の前記表示要素についての前記表示形態を示す前記属性名と対応させる。
【００１８】
この発明にかかるソフトウェア試験装置の第３の態様は、その第１の態様または第２の態様であって、前記被試験ソフトウェアは、制御アプリケーションをも有し、前記制御アプリケーションでは、制御対象への操作を指定する制御アプリケーションデータが、入力データに基づいて採用され、前記結果判定部は、前記入力データと前記制御アプリケーションデータとが一致するか否かも判定する。
【発明の効果】
【００１９】
この発明にかかるソフトウェア試験装置の第１の態様によれば、表示単位に含まれる表示要素についての描画命令について判定を行うので、表示単位において複数の表示要素が重なっている場合でも、その良否を表示要素毎に切り分けて判定できる。
【００２０】
また、属性名／描画命令対応表を用いて描画命令と属性名の対応をとるので、被試験ソフトウェアのシステムに依存しない属性名を使用した期待値を定義して判定を行うことができる。
【００２１】
この発明にかかるソフトウェア試験装置の第２の態様によれば、被試験ソフトウェアの設計方法と試験シナリオの設計方法とが異なっていても、表示形態が同じか否かによって結果判定を行うことができる。
【００２２】
この発明にかかるソフトウェア試験装置の第３の態様によれば、組合せ試験の原因が制御アプリケーションに由来するのか、表示アプリケーションに由来するのか、を切り分けることができる。
【図面の簡単な説明】
【００２３】
【図１】監視制御システムの構成を例示するブロック図である。
【図２】監視制御システムの画面表示を例示する模式図である。
【図３】実施の形態１における試験システムの構成を例示するブロック図である。
【図４】実施の形態１における試験シナリオの構成を例示する図である。
【図５】実施の形態１における試験シナリオの入力データの一覧を示す図である。
【図６】実施の形態１における試験シナリオの属性名の一覧を示す図である。
【図７】実施の形態１における試験システムの動作を示すフローチャートである。
【図８】実施の形態１における描画命令の一覧を例示する図である。
【図９】実施の形態１において表示アプリケーションから描画命令を出力するためのプログラミングルールの一覧を示す図である。
【図１０】実施の形態１において描画命令を出力するためのプログラミングルールに従って記述したプログラムを例示する図である。
【図１１】実施の形態１において描画命令を出力するためのプログラミングルールに従って記述したプログラムを例示する図である。
【図１２】実施の形態１において描画命令を出力するためのプログラミングルールに従って記述したプログラムを例示する図である。
【図１３】実施の形態１において試験装置が受信するログを例示する図である。
【図１４】実施の形態１における結果判定部の動作を表すフローチャートである。
【図１５】実施の形態１における属性名／描画命令対応表の一覧を例示する図である。
【図１６】実施の形態１における結果判定を例示する図である。
【図１７】実施の形態２における試験システムの構成を例示するブロック図である。
【図１８】実施の形態２における属性名／描画命令対応表の一覧を例示する図である。
【図１９】実施の形態３において表示アプリケーションから描画命令を出力するためのプログラミングルールの一覧を示す図である。
【図２０】実施の形態３において表示アプリケーションから描画命令を出力するためのプログラミングルールに従って記述したプログラムを例示する図である。
【図２１】実施の形態３において試験装置が受信するログを例示する図である。
【図２２】実施の形態３における結果判定を例示する図である。
【発明を実施するための形態】
【００２４】
図１は後述する実施の形態にかかるソフトウェア試験装置の試験対象となる、監視制御システムの構成を例示するブロック図である。
【００２５】
図１において、監視制御システム１は、制御装置１０−１〜１０−ｎ（ｎは１以上の整数）と、制御ネットワーク１１と、入出力ネットワーク１２−１〜１２−ｎと、制御対象装置１３−１−１〜１３−１−ｍ１，…，１３−ｎ−ｍｎ〜１３−ｎ−ｍｎ（ｍ１，…，ｍｎはそれぞれ１以上の整数）と、表示装置１５と、表示装置ネットワーク１６とを備えている。
【００２６】
制御装置１０−１〜１０−ｎにはそれぞれ制御アプリケーション（図中では「制御ＡＰ」と表記される）１４−１〜１４−ｎが搭載されている。制御装置１０−１〜１０−ｎは制御ネットワーク１１で相互に接続され、制御ネットワーク１１を介して互いに通信する。制御装置１０−ｋは、それぞれ入出力ネットワーク１２−ｋを介して、制御対象装置１３−ｋ−１〜１３−ｋ−ｍｋを監視・制御する（ｋは１以上の整数）。
【００２７】
表示装置１５には表示アプリケーション１７（図中では「表示ＡＰ」と表記される）が搭載されている。制御装置１０−１〜１０−ｎと表示装置１５とは表示装置ネットワーク１６を介して互いに通信する。表示アプリケーション１７と制御アプリケーション１４−１〜１４−ｎとは、表示装置ネットワーク１６を通じて互いに通信する。
【００２８】
後述する実施の形態では、監視制御システム１の制御アプリケーション１４−１〜１４−ｎの試験や、制御アプリケーション１４−１〜１４−ｎと表示アプリケーション１７とを組合せた試験（以下「組合せ試験」）を自動化して実行する技術を説明する。
【００２９】
当該監視制御システム１として、例えば、列車監視制御システムが挙げられる。ここで言う列車監視制御システムは、列車に搭載される様々な機器の監視・制御を行う。以下、列車監視制御システムを例に挙げて説明する。
【００３０】
列車監視制御システムでは、制御装置が各車両に搭載される。そして各車両に搭載されて当該制御装置による制御対象となる機器(トイレ、ドア、空気調和機、ブレーキ、モータ等)が監視の対象ともなる。
【００３１】
図２は、監視制御システム１の表示装置１５に表示される、画面表示２を例示する模式図である。ここでは空気調和の情報（以下、「空調情報」と称す）を表示する場合を例示する。
【００３２】
画面表示２は表示単位２０―１〜２０−６，２１―１〜２１−６，２２−１〜２２−３を含む。換言すれば表示装置１５は表示単位２０―１〜２０−６，２１―１〜２１−６，２２−１〜２２−３を含む画面表示２を、表示アプリケーション１７に基づいて表示する。
【００３３】
表示単位２０―１〜２０−６はそれぞれ異なる車両について、当該車両に搭載される空気調和機の現在の設定温度を表示する。具体的には、表示単位２０―１〜２０−６は、表示要素たる矩形と、その中に配置された表示要素たる文字とで表現される。当該矩形は設定温度の範囲を色で表示する。当該文字は設定温度を表示する。このように表示単位は少なくとも一つの表示要素を含んで構成される。
【００３４】
表示単位２０―１〜２０−６の矩形の色は、通常時と緊急事態とでは異なる。緊急事態とは、例えば設定温度がある一定の範囲（例えば摂氏１８〜２８度）を超えた場合である。当該矩形の色は、例えば通常時において白、緊急事態において赤が採用される。図２では第３号車に対応する表示単位２０―３において、文字は設定温度が３０度であることを示し、矩形の色は緊急事態であることを示す場合が例示される。
【００３５】
表示単位２１−１〜２１−６は設定温度を変更する対象となる空気調和機が搭載された車両を示し、かつその車両を設定する。例えば表示装置１５はタッチパネルを備え、表示単位２１−３の表示箇所にタッチすることにより、第３号車の空気調和機を設定温度を変更する対象として設定できる。
【００３６】
表示単位２２−２，２２−３は設定温度を変更する方向を示し、かつその方向への変更を設定する。例えば表示装置１５はタッチパネルを備える。表示単位２２−２の表示箇所にタッチする度に、表示単位２１−１〜２１−６で示されたいずれかの号車の空気調和機の設定温度を、１度ずつ上昇させる。表示単位２２−３の表示箇所にタッチする度に、表示単位２１−１〜２１−６で示されたいずれかの号車の空気調和機の設定温度を、１度ずつ下降させる。この設定温度の変更は、表示単位２２−１が含む表示要素たる文字列において表現される。例えば表示単位２１−３の表示箇所にタッチしていた場合には、表示単位２２−１と表示単位２０−３とは、それぞれの文字で表現される設定温度が一致する。
【００３７】
表示単位２２−２の表示箇所にタッチする度に、表示単位２２−２が表示する矩形の色が一定時間変更されてもよい。表示単位２２−３についても同様である。
【００３８】
このような列車監視制御システムにおける組合せ試験では、（ａ）制御対象となる装置の状態に対する画面表示２の変化(上述の例では空気調和機の設定温度を示す表示単位２０−１〜２０−６の表示の変化)や、（ｂ）表示装置１５に対するユーザのアクション(上述の例では表示単位２１−１〜２１−６，２２−２，２２−３が配置された位置へのタッチ）に対する表示の変化(上述の例では表示単位２２−２〜２２−３が配置された位置へのタッチに対応した表示単位２２−１の表示の変化、表示単位２１−３が配置された位置へのタッチに対応した表示単位２０−３が表示する設定温度と表示単位２２−１とが表示する設定温度の一致)について、良否が判定される。
【００３９】
より具体的には上記項目（ａ）に関しては、表示単位２０−１〜２０−６について、矩形の色と矩形の中の数字とが正しく対応して表示されているか否かを判定する。例えば表示単位２０−３において、設定温度が３０度であることを文字が表示しながらも、矩形の色が通常時に対応する色である場合には当該判定の結果は「不良」である。また上記項目（ｂ）に関しては、表示単位２２−２，２２−３の表示する色が、それぞれの表示箇所にタッチする度に、一定期間変更されているか否かを判定する。あるいはこれに伴って表示単位２２−１や表示単位２０−１〜２０−６のいずれか一つの文字が正しく変化するか否かを判定する。
【００４０】
そして上記の判定結果が「不良」であった場合、矩形の色と数字のどちらが不良であったか原因の切り分けを行うことが望まれる。
【００４１】
実施の形態１．
図３は、本発明の実施の形態１における試験システムの構成を例示するブロック図である。当該試験システムにおいてソフトウェア試験装置３０及び被試験装置３１が相互に通信可能である。被試験装置３１はソフトウェア試験装置３０が行う試験の対象である。
【００４２】
ソフトウェア試験装置３０は結果判定部３０１、入力データ再生部３０２、試験シナリオ３０３、属性名／描画命令対応表３０４、描画命令保存部３０５、描画命令ログ３０６を備える。
【００４３】
被試験装置３１は、描画命令送信部３１１、入力データ実行部３１２、被試験ソフトウェア（図において「被試験Ｓ／Ｗ」と表記）３１３を備える。
【００４４】
図４は試験シナリオ３０３の構成を例示する図である。試験シナリオ３０３において、試験番号と、入力データと、入力データのそれぞれに対する確認事項とが関連づけられている。試験番号は、入力データ毎に割り付けられている。換言すれば、試験シナリオ３０３は、試験番号に対して、入力データ及びこれに対応する確認事項を定義付ける。
【００４５】
図５は入力データの一覧を例示する図である。入力データには、表示アプリケーション１７（図１の表示装置１５を参照）に対する操作と制御アプリケーション１４−１〜１４−ｎ（図１の制御装置１０−１〜１０−ｎを参照）に対する操作とがある。被試験ソフトウェア３１３は表示アプリケーション１７と制御アプリケーション１４−１〜１４−ｎとを包含する。
【００４６】
表示アプリケーション１７についての操作としては、「画面遷移」（No1）と「押下」（No2）との二つの命令が例示されている。
【００４７】
「画面遷移」命令は、指定した画面符号（図中では「画面ＩＤ」と表記される）への画面を遷移させる命令である。「画面符号」とは、画面毎に一意に付けられた識別符号を指す。
【００４８】
また、「押下」命令とは、指定したオブジェクト符号（図中では「オブジェクトＩＤ」と表記される）に対応する表示単位をタッチして操作する命令である。本命令は、タッチによる操作が可能な表示単位についてのみ有効である。
【００４９】
「オブジェクト符号」とは、画面の表示単位に一意に付けられた識別符号である。例えば、図２の表示単位２０−１〜２０−６、２１−１〜２１−６、２２−１〜２２−３に対してそれぞれ一意なオブジェクト符号が対応付けられる。
【００５０】
オブジェクト符号は表示アプリケーション１７の中で定義される。表示アプリケーション１７でのオブジェクト符号の定義方法は後述する。
【００５１】
制御アプリケーション１４−ｋについての操作としては、「制御対象装置のデータ設定」（No3）がある。当該操作は、制御対象装置たるトイレやドアなどの機器の状態を、データとして設定する命令である。
【００５２】
例えば図４の試験番号１の入力データの形式には、図５の記述方式No1が採用される。例えば画面符号DispIDとしての値「１」は、図２に示されるような空調情報を示す画面表示２に対応する。他の画面表示を行う場合にはこの画面符号DispIDの値が他の値を採る。
【００５３】
また図４の試験番号２〜５の入力データの形式には、図５の記述方式No3が採用される。
【００５４】
図４において確認事項は「オブジェクト符号．属性名＝期待値」で表現される。図６は試験シナリオ３０３で定義される属性名を示す図である。属性名は「種別．属性」で表現される。例えば、矩形の塗り潰しの色に対応する属性名は、Rectangle.fillColorとなる（図６の上から二段目、かつ左から４つ目のブロックを参照）。
【００５５】
本実施の形態及び以下の実施の形態において、属性名は表示単位に含まれる表示要素毎に設定され、当該属性名はその対応する表示要素が表示される形態（図形の種類、色、大きさ、位置、文字列など：以下「表示形態」と称す）を指定する。
【００５６】
例えば図４を参照して、試験番号２のとき入力データは、１号車の空調装置の設定温度を「２５」にする意味を有する。このときの期待値として、オブジェクト符号Ｏ１に対応する表示単位２０−１のうちの一つの表示要素たる文字列が「２５」と定義されている。また、試験番号３のとき入力データは、２号車の空気調和機の設定温度を「０」にする意味を有する。このときの期待値として、オブジェクト符号Ｏ２に対応する表示単位２０−３のうちの一つの表示要素たる矩形の塗り潰しの色が「赤」（設定温度０度は摂氏１８〜２８度の範囲を超える）、他の表示要素たる文字列が「０」として定義されている。
【００５７】
図３に戻り、入力データ再生部３０２は、試験シナリオ３０３の入力データを、区々に被試験装置３１（より具体的には入力データ実行部３１２）へ送信する。
【００５８】
図７は試験システムの全体の動作を示すフローチャートである。ステップＬ１，Ｌ１Ｅで挟まれた各ステップＳ１〜Ｓ１０は、試験シナリオ３０３に書かれた入力データの数に対応して繰り返して実行される。これにより、試験シナリオ３０３に記述された試験番号の数に対応してソフトウェア試験が行われることになる。
【００５９】
ステップＳ１，Ｓ２は、入力データ再生部３０２が実行する処理である。ステップＳ１では、試験シナリオ３０３に記述された試験番号が結果判定部３０１に送信される。次にステップＳ２では、ステップＳ１で送信した試験番号の入力データが、被試験装置３１に、より具体的には入力データ実行部３１２に対して送信される。
【００６０】
ステップＳ３は、入力データ実行部３１２が実行する処理である。ステップＳ３では、入力データ再生部３０２から受信された入力データが、被試験ソフトウェア３１３に対して入力される。この際、図６で示される入力データの一覧から、入力データの種類に応じて、被試験ソフトウェア３１３のうち制御アプリケーション１４−１〜１４−ｎと表示アプリケーション１７とのいずれに入力データを設定するかを選択する。
【００６１】
ステップＳ４は被試験ソフトウェア３１３が実行する処理である。ステップＳ４では、被試験ソフトウェア３１３の処理記録（以下、「ログ」と称し、図中でも「ログ」と表記される）が出力される。当該ログは描画命令、オブジェクト符号、描画終了フラグ（図中では「描画終了flag」と表記される）の三種類に区分される。
【００６２】
描画命令については後に図８を用いて説明する。描画終了フラグは、画面全体の描画が終了したことを示す。描画終了フラグには文字列”drawEnd”や、数字”-1”等が採用され、描画命令とは区別可能となっている。ログを出力するためのプログラミング方法は、後に図９を用いて説明する。
【００６３】
ステップＳ５は、描画命令送信部３１１の動作である。ステップＳ５では、ステップＳ４で出力されたログが、ソフトウェア試験装置３０、より具体的には描画命令保存部３０５へ送信される。
【００６４】
ステップＳ６，Ｓ７，Ｓ８，Ｓ１０は、描画命令保存部３０５が実行する処理である。ステップＳ６では、描画命令送信部３１１からステップＳ５で送信されてきたログを描画命令保存部３０５が受信する。ステップＳ７では、ステップＳ６で受信したログが描画終了フラグか否かが判定される。
【００６５】
ログが描画終了フラグであると判断された場合は、処理がステップＳ７からステップＳ８へ進み、ログが描画終了フラグではないと判断された場合は、処理がステップＳ７からステップＳ１０へ進む。
【００６６】
ステップＳ８では、ステップＳ６で受信したログである描画命令終了フラグが、入力データ再生部３０２へ送信される。ステップＳ１０では、実行中の試験番号の描画命令として、ログが描画命令ログ３０６として保存される。ステップＳ１０が実行された後、再びステップＳ４の処理が実行され、あらたなログが被試験ソフトウェア３１３から送信される。
【００６７】
ステップＳ９は入力データ再生部３０２が実行する処理である。ステップＳ７の判断が肯定的であるということは、画面全体の描画が終了したということである。よって他の試験番号に対応する試験を実行するために、ステップＳ９では入力データ再生部３０２が試験番号を更新し、新しい入力データを被試験装置３１に送信する。
【００６８】
以上の様にして、ステップＬ１とステップＬ１Ｅに挟まれたステップが、試験シナリオ３０３に設定された試験番号の全てに対応して繰り返して実行される。
【００６９】
ステップＳ１１は結果判定部３０１が実行する処理である。ステップＳ１１では、ステップＳ１０で保存された描画命令ログ３０６の判定を行う。属性名／描画命令対応表３０４を用いた照合によって、試験シナリオ３０３に記述されている属性名の期待値と、描画命令ログ３０６に保存された描画命令との対応をとり、試験の結果判定を行う。例えば結果判定部３０１は出力部を備え、そこから結果判定を出力することができる。詳細な判定方法の説明は、図１４及び図１５を用いて後に説明する。
【００７０】
図８は描画命令の一覧を例示する図である。描画命令によって表示要素が表示される。描画命令は入力データ実行部３１２によって設定された入力データに基づいて採用される。
【００７１】
描画命令は種々の描画について関数（以下「描画関数」と称す）の形式で示される。以下、図９を用いて、被試験ソフトウェア３１３がログとして出力する描画命令を、描画関数を用いて作成する手順を説明する。当該手順に基づいて、被試験ソフトウェア３１３において表示アプリケーション１７が記述されている。当該表示アプリケーション１７はプログラマーによって作成される。
【００７２】
ルールＮＯ１は、画面遷移関数についてのプログラミングルールである。ルールＮＯ１では、画面毎に一意に画面符号を付加する。そして画面符号を用いて、画面遷移が可能な関数を作成する。画面遷移関数は、図５で示された入力データ一覧の入力データのうち、記述方式No1が採用される「画面遷移」の命令を実現する。
【００７３】
ルールＮＯ２は、描画関数についてのプログラミングルールである。出力される描画命令のうち、どこまでが一画面分の描画命令であるかを識別するために採用されるルールである。具体的には一画面の全体の描画命令が終了したら、最後の描画関数に続いて描画終了フラグを出力する。
【００７４】
ルールＮＯ３〜ＮＯ６はＧＵＩ（graphical user interface）部品の描画関数についてのプログラミングルールである。ここで「部品」とは、表示単位の見た目の描画及びロジックが共通する部分（例えば矩形の描画と、塗り潰しの色を設定するというロジック）をカプセル化したものである。
【００７５】
ルールＮＯ３は、オブジェクト毎に描画命令を出力可能とするために、各ＧＵＩ部品を記述する関数drawPartsを作成する。
【００７６】
ルールＮＯ４では、drawParts関数の最初に、オブジェクト毎に一意に付けられたオブジェクト符号を付加して出力する。これは、オブジェクト毎に描画命令を分類できるようにするためである。
【００７７】
ルールＮＯ５では、関数drawPartsの中で、図８に示す描画関数で表現される描画命令が呼び出され、実行される。ここで実行される描画命令は、表示アプリケーション１７において採用される描画命令である、と把握することができる。
【００７８】
ルールＮＯ６では、関数drawPartsの最後に、もう一度オブジェクト符号を出力する。これは、ＧＵＩ部品が階層化されていた場合に、各階層のオブジェクト毎の描画命令を取得可能とするためである。
【００７９】
図１０は関数drawPartsの、呼出元関数を例示する図である。ここでは空気調和機の設定温度についてのＧＵＩ部品を描画する場合の呼出元関数（第３行目の破線枠）を例示する。
【００８０】
図１１はルールＮＯ３〜６に従って記述したdrawParts関数を例示する図である。図１１の第１行目（破線枠）において、ルールＮＯ３に従って“void drawParts()”によって関数drawPartsが定義される。試験モード（値Logが"testMode"）では、ルールＮＯ４に従ってオブジェクト符号をログに出力する（第７行において記述される関数sendIDにより、オブジェクト符号の値partsIDをログの値Logへ出力する：破線枠参照）。またルールＮＯ６に従ってオブジェクト符号を出力する（第１９行の破線枠参照）。そして図１１で示された関数drawPartsでは、ルールＮＯ５に従って、矩形描画関数drawRectangle及び文字列描画関数drawStringを、関数DrawCommandとして呼び出す場合が例示されている（第１１から１４行の破線枠参照）。
【００８１】
ルールＮＯ７は描画命令についてのプログラミングルールである。図８に示された描画関数で示される描画命令を実行する際に、描画命令の関数名とその関数の実引数を出力する。図１２は、ルールＮＯ７に従って記述した描画命令を例示する図である。関数sendDrawCommandは関数Commandで指定された描画命令の関数名及び実引数をログに出力する（第８−９行、第２４−２５行の破線枠参照）。当該実引数は当該描画命令が有する値（数値、あるいは文字列）であると把握することもできる。
【００８２】
ルールＮＯ３〜ＮＯ６に準拠したプログラミングを容易にすることが望まれる。よってオブジェクト指向の言語やＧＵＩ設計ツールを用いた開発を行うことが望ましい。
【００８３】
図１３はソフトウェア試験装置３０の描画命令保存部３０５が、被試験装置３１の描画命令送信部３１１から受信したログ（ステップＳ６）の、ある試験番号に対応する描画命令を例示する図である。
【００８４】
ログ内には、オブジェクトのそれぞれに対する描画命令が出力される。ルールＮＯ４，ＮＯ６に従って同じオブジェクト符号で挟まれた領域が、ルールＮＯ５に従った各オブジェクトの描画命令である。ここではオブジェクト符号Ｊ１についての描画命令の下層にオブジェクト符号Ｊ１１についての描画命令が出力される場合が例示されている。
【００８５】
つまりオブジェクト符号Ｊ１１についての描画命令Ｄ１１は、線描画関数drawLine及び文字列描画関数drawStringを含む。オブジェクト符号Ｊ１についての描画命令Ｄ１は、矩形描画関数drawRectangle、文字列描画関数drawString、及び線描画関数drawLineを含む。オブジェクト符号Ｊ２についての描画命令Ｄ２は、矩形描画関数drawRectangle及び文字列描画関数drawStringを含む。
【００８６】
図１４は結果判定部３０１が実行する判定処理を示すフローチャートであり、その全体が図７のステップＳ１１に相当する。
【００８７】
ステップＭ１，Ｍ１Ｅで挟まれた、ステップＴ１及びステップＭ２，Ｍ２Ｅで挟まれたステップＴ２〜Ｔ６は、試験シナリオ３０３に書かれた入力データの数に対応して繰り返して実行する。これにより、試験シナリオ３０３に記述された試験番号の数に対応してソフトウェア試験が行われることになる。
【００８８】
ステップＴ１では、（ステップＳ１において入力データ再生部３０２から入力された試験シナリオ３０３であった）試験番号（例えばＮとする）に対応する確認事項を取得する。ステップＭ２，Ｍ２Ｅで挟まれたステップＴ２〜Ｔ６は、試験番号Ｎが割り付けられた確認事項中に書かれた確認事項の数（例えばＭとする）で繰り返される。図４を参照して、例えばＮ＝１，２，３，４，５にはそれぞれＭ＝０，１，２，２，１が対応する。
【００８９】
ステップＴ２では、試験シナリオ３０３に記述された試験番号Ｎの確認事項を順次に取得する。ステップＴ３では、ステップＴ２で取得された確認事項の属性名を、描画命令ログ３０６から取得する。
【００９０】
但し期待値は属性名に対応して定義されている。よって描画命令と属性名との対応をとる必要がある。そこで、ステップＴ４において、属性名／描画命令対応表３０４を用いて対応する属性名と描画命令の対応をとる。
【００９１】
図１５は属性名／描画命令対応表３０４の一覧を例示する図である。図１５において属性名（図６参照）と描画命令（図８参照）との対応が示されている。但し、図６で示されるように、属性名は「種別．属性」で表現される。つまり「種別」が同じでも、「属性」が異なれば属性名は異なる。よって一つの属性名については、描画命令では種別に対応する描画関数の名称（「関数名」）と、属性に対応する仮引数の名称（「引数名」）との一対が対応している。
【００９２】
例えば、属性名が「String.text」の場合、対応する描画命令は、文字列描画関数drawStringとその仮引数textである。
【００９３】
ステップＴ５では、試験の結果判定が行われる。ステップＴ６では、ステップＴ５で得られた判定の結果が出力される。
【００９４】
図１６は結果判定を例示する図である。左側の三つの欄は試験シナリオ３０３と対応する。ここでは図４で例示された試験シナリオ３０３が全て採用される場合を例示しており、図１６の当該三つの欄が図４の試験シナリオ３０３と（順序を含めて）一致している。図１３で示された描画命令の一覧とは直接の関連はない。
【００９５】
例えばステップＳ２（図７参照）において入力データ再生部３０２が結果判定部３０１に送信する試験番号は、試験シナリオ３０３の全てである必要はなく、また順序も一致する必要はない。
【００９６】
右側の二つの欄は、試験シナリオ３０３の試験番号に対応して取得された描画命令（図中、及び以下では「対応描画命令」と称す）と、結果判定とを示す。即ち、結果判定は、シナリオ(入力データと確認事項)の期待値に対応する描画命令を付加し、その結果判定を記載する。
【００９７】
例えば、試験シナリオ３０３において、試験番号２に対応する確認事項は「Ｏ１．String.text="25"」である。よって試験番号２に対応して試験シナリオ３０３からステップＴ２で取得される期待値は、オブジェクト符号Ｏ１の文字列の期待値であって、値は「25」である。ステップＴ３で試験番号２に対応して取得された対応描画命令は「drawString("25",4,200,100,1）」である。ステップＴ４では、属性名／描画命令対応表３０４に基づいて、試験番号２に対応する確認事項のうち、属性名String.textと、描画命令の描画関数drawStringと仮引数textとの対応を取得する。
【００９８】
ところで図８に示されるように、描画関数drawStringは文字列描画関数であって、その仮引数textは、文字列描画関数drawStringの実引数の第１番目に対応する。よってステップＴ５で行われる判定は、ステップＴ３で取得された対応描画命令drawString("25",4,200,100,1）が有する値（より具体的にはその実引数の第１番目）が、ステップＴ２で取得された期待値「25」と一致するか否かの判定である。
【００９９】
ここで示された試験番号２についての例示では、対応描画命令drawString("25",4,200,100,1）の関数名及び実引数の第１番目は、属性名String.textに対応する文字列描画関数及びその仮引数についての期待値と一致する。よって判定結果は「ＯＫ」（良）となる。
【０１００】
一方、試験番号が３の場合、期待値は二つある。一つの期待値は一つの確認事項に対応して設定されているので確認事項も二つある。最初の確認事項は「Ｏ２．drawRectangle.fillColor＝赤」である。図８を参照して、これはオブジェクト符号Ｏ２の塗り潰しの色が赤色で、文字列が「０」となることを意味する。よって表示要素たる色と、別の表示要素たる文字列のそれぞれについて個別に、対応描画命令が期待値を満足するか否かを確認する必要がある。
【０１０１】
まず塗り潰しの色について、その属性名Rectangle.fillColorに対応する描画命令は、図１５で示された属性名／描画命令対応表３０４の一覧を参照して、描画関数drawRectangle及びその仮引数fillColorである。図８で示された描画命令の一覧から、描画関数drawRectangleは矩形描画関数であって、その仮引数fillColorは実引数の第３番目に対応することが判る。矩形描画関数drawRectangleにおける仮引数fillColorに対応する実引数の第３番目は、その値０が白、値１が赤、値２が青、値３が黄、値４が黒を、それぞれ示すものとする。
【０１０２】
そこで対応描画命令を見ると、その描画関数drawRectangleは属性名Rectangle.fillColorに対応する矩形描画関数と一致する。しかし対応描画命令の実引数の第３番目に対応する仮引数fillColorの値は０であり、これは白を意味する。これは確認事項における期待値「赤」とは異なっている。よって判定結果は「ＮＧ」（不良）となる。
【０１０３】
同じ試験番号３についての次の期待値を記載する確認事項は「Ｏ２．String.text="０"」である。つまりこの確認事項における期待値はオブジェクト符号Ｏ２の文字列の期待値であって、値は「０」である。試験番号２の確認事項において説明したように、対応描画命令drawString及びその実引数の第１番目は、属性名String.textに対応した文字列描画関数drawString及びその仮引数textに対応する。ここでは対応描画命令drawStringの実引数の第１番目は、属性名String.textに対応した期待値「０」と等しい。よって文字列についての判定は「ＯＫ」（良）となる。
【０１０４】
このようにして、ここでの例示では、試験番号３に対応する結果判定は、塗り潰しの色がＮＧで、文字列がＯＫである。つまり、オブジェクト符号Ｏ２が対応する表示単位において複数の表示要素（例えば矩形と文字列）が重なっていても、そのいずれが不良であるのかを切り分けて自動で判定することができる。
【０１０５】
また、属性名／描画命令対応表３０４を用いて描画命令と属性名の対応をとる。これにより、被試験ソフトウェア３１３のシステムに依存しない属性名を使用した期待値を定義して、被試験ソフトウェア３１３の試験に採用することができる。
【０１０６】
実施の形態２．
図１７は、実施の形態２における試験システムの構成を例示するブロック図である。本実施の形態ににかかるソフトウェア試験装置３０の構成は、図３に示されたソフトウェア試験装置３０の構成に属性名／描画命令対応関係追加部１８０を追加して得られる。他の構成は実施の形態１と同様である。よって対応する部分に同一符号を付してその説明を省略する。
【０１０７】
属性名／描画命令対応関係追加部１８０は、属性名／描画命令対応表３０４に対して、対応関係を追加する。
【０１０８】
上記「発明が解決しようとする課題」の欄で項目（ＩＩＩ）として説明したように、同じ画面仕様を得るには、複数の作成パターンが存在する場合がある。例えば、矩形を描画する場合、矩形の描画命令を使用する場合と、直線の描画命令を４度実行して実現する場合がある。また、文字列を描画する場合も、一文字ずつ描画命令を複数回実行する場合と、複数の文字を一つの文字列にまとめて、描画命令を一度実行する場合がある。
【０１０９】
このような場合、得られる画面が同一であれば、表示アプリケーション１７で採用される描画命令の相違は画面表示としては問題がない。
【０１１０】
そこで、本実施の形態では属性名／描画命令対応関係追加部１８０を備え、様々な設計パターンに対応した自動判定を行う。
【０１１１】
矩形の辺の色に対応する属性名Rectangle.sideColor（図６参照）に対する期待値が定義されていた場合を例にとって説明する。これに対応する描画命令は、図１５で示された属性名／描画命令対応表３０４から、矩形描画関数drawRectangleとその仮引数sideColorである。よって実施の形態１に則った処理では、ステップＴ５において、描画命令ログ３０６から関数drawRectangleの実引数の第２番目が検索される（図８において示される矩形描画関数drawRectangleの仮引数sideColorは実引数の第２番目に対応する）。
【０１１２】
しかし、表示アプリケーション１７において、矩形を描画するための方法として矩形の辺に相当する４本の直線を描画する手法、つまり線描画関数drawLineを四回用いて矩形を描画することが記述されているかも知れない。この場合、描画命令ログ３０６から取得される対応描画命令は線描画関数drawLineを四つ含むことになる。
【０１１３】
例えば当該直線の色について見れば、実施の形態１で示された手法では属性名Rectangle.sideColorに対応する描画命令は、属性名／描画命令対応表３０４では矩形描画関数drawRectangleの仮引数sideColorに対応する。よって結果判定部３０１は関数drawRectangleの実引数の第２番目を検索しても、線描画関数drawLineは検索しない。
【０１１４】
そこで本実施の形態では、属性名／描画命令対応関係追加部１８０において、４直線の端点が一対ずつ一致する前提の下で、矩形と判断するという対応関係を定義し、当該対応関係を属性名／描画命令対応表３０４に追加する。
【０１１５】
図１８は、本実施の形態における属性名／描画命令対応表３０４の一覧を例示する図である。図１５において示された属性名と描画命令との対応は図１８において対応関係３０４ａとして示されている。また図１５において示されなかった属性名と描画命令との対応は図１８において追加対応関係３０４ｂとして示されている。
【０１１６】
例えば上述の矩形の描画について言えば、その辺の色を指定する属性名Rectangle.sideColorには対応する描画命令は、矩形描画関数drawRectangleの仮引数sideColorのみならず、線描画関数drawLineの仮引数Colorも対応する。よって結果判定部３０１は関数drawRectangleの実引数の第２番目のみならず、線描画関数drawLineの実引数の第２番目も検索される（図８において示される矩形描画関数drawRectangleの仮引数Colorは実引数の第２番目に対応する）。
【０１１７】
但し、この例で言えば、４直線で矩形が描画される。よって以下の条件が全て満足されて、対応描画命令が「ＯＫ」と判定されることになる：
（Ａ）前提として４直線の端点が一対ずつ一致すること。これは線描画関数drawLineの仮引数nX,nY,angle,length（それぞれ始点のｘ座標、始点のｙ座標、回転角、長さを指定する）から計算することができる。ここでは繁雑となるのでその詳細は省略する；
（Ｂ）属性名Rectangle.sideColorの期待値を含む入力データ一つに対して、四つの線描画関数drawLineの実引数の第２番目が全て、当該期待値と等しい。
【０１１８】
また、矩形の描画の位置について言えば、上記（Ａ）を前提として以下の条件が全て満足されて、対応描画命令が「ＯＫ」と判定されることになる：
（Ｃ）矩形描画関数drawRectangleの仮引数nX（矩形の左上の頂点のｘ座標）が、四つの線描画関数drawLineの仮引数nX（これは実引数の第３番目に対応する）のうち最も小さい値と等しい；
（Ｄ）矩形描画関数drawRectangleの仮引数nＹ（矩形の左上の頂点のｙ座標）が、四つの線描画関数drawLineの仮引数nＹ（これは実引数の第４番目に対応する）のうち最も大きい値と等しい。
【０１１９】
このように、追加対応関係３０４ｂを対応関係３０４ａに追加することによって、表示要素に対する判定を表示アプリケーション１７の設計方法に依存せず適切に判定することができる。つまり、表示アプリケーション１７の設計方法と試験シナリオ３０３での定義方法が異なった場合でも、正しく結果判定を行うことができる。
【０１２０】
換言すれば、矩形という表示要素の、辺の色という表示形態を得るための描画命令は、矩形描画関数drawRectangleの仮引数sideColorと線描画関数drawLineの仮引数Colorが対応する。つまりこれらの複数の描画命令が属性名Rectangle.sideColorに対応する。属性名／描画命令対応表３０４が対応関係３０４ａ及び追加対応関係３０４ｂを含むことにより、被試験ソフトウェア３１３の設計方法と試験シナリオ３０３の設計方法とが異なっていても、辺の色という表示形態が同じか否かによって結果判定を行うことができる。
【０１２１】
実施の形態３．
監視制御システムにおける組合せ試験では、制御アプリケーション１４−１〜１４−ｎに対して入力データを与える場合、制御アプリケーション１４−１〜１４−ｎと表示アプリケーション１７での両方で加工した結果を表示画面に出力し、表示画面の表示結果を判定している。
【０１２２】
組合せ試験の結果判定が「ＮＧ」（不良）であった場合、それが制御アプリケーション１４−１〜１４−ｎに由来するのか、表示アプリケーション１７に由来するのかという、原因の切り分けが望まれる。
【０１２３】
そこで、本実施の形態では、試験結果の原因の切り分けを容易にするために、表示アプリケーション１７が取得した制御アプリケーション１４−１〜１４−ｎの値をログに追加する。換言すれば、制御アプリケーション１４−１〜１４−ｎからの表示アプリケーション１７に対する入力の値を、ログに追加する。
【０１２４】
図１９は本実施の形態３において描画命令を出力するためのプログラミングルールの一覧を示す図である。本実施の形態における当該一覧は、図９で示された実施の形態１における当該一覧に対して、制御アプリケーション１４−ｋのデータを取得するためのコードを追加するためにルールＮＯ５−１が追加されている。他のルールは実施の形態１と同様である。よって、対応する部分に同一符号を付してその説明を省略する。
【０１２５】
ルールＮＯ５−１はＧＵＩ部品に紐付けられた制御アプリケーション１４−ｋの値をログに追加するためのルールである。具体的にはルールＮＯ５−１では、関数drawPartsの中で、図５に示す操作のうち制御アプリケーション１４−ｋに対する「制御対象装置のデータ設定」（No3）で表現される命令が呼び出され、実行される。ここで実行される命令は、制御アプリケーション１４−ｋにおいて採用される操作を指定する操作命令である、と把握することができる。
【０１２６】
図２０は、本実施の形態における関数drawPartsを例示する図である。ルールＮＯ５−１に従って、制御アプリケーション１４−ｋのデータを取得する関数sendRefDataが破線枠で示されている。具体的には関数sendRefDataで呼び出される「制御対象装置のデータ設定」が空気調和機の温度を設定する操作に対応する場合、仮引数dataNum,gousha,refDataは、それぞれ空気調和であることと、対象となる号車と、設定温度とに対応する。
【０１２７】
図２１は、ソフトウェア試験装置３０の結果判定部３０１が被試験装置３１から受信するログの例である。描画命令の間に各オブジェクトに紐付いた制御アプリケーションのデータ（以下「制御アプリケーションデータ」）Ｃ１〜Ｃ４が追加されている。制御アプリケーションデータＣ１〜Ｃ４は、それぞれが入力データに基づいて採用される。
【０１２８】
例えば制御アプリケーションデータＣ１，Ｃ２，Ｃ３，Ｃ４は、いずれも空調温度の設定についての操作命令である。また制御アプリケーションデータＣ１，Ｃ２，Ｃ３，Ｃ４は、それぞれ１号車、２号車、３号車、４号車に対応する。例えば制御装置１０−ｋ（図１参照）がｋ号車の制御を行い、制御対象装置１３−ｋ−１が空気調和機である場合を想定する。この場合、制御アプリケーションデータＣ１は制御装置１０−１が制御する空気調和機たる制御対象装置１３−１−１についての制御アプリケーション１４−１の「制御対象装置のデータ設定」（図５参照）に相当する。また、制御アプリケーションデータＣ１，Ｃ２，Ｃ３，Ｃ４は、それぞれ設定温度２５，０，３０，２６（度）に対応する。
【０１２９】
図２１には、図１３において示されたオブジェクト符号Ｊ１，Ｊ２に対応する描画命令Ｄ１，Ｄ２、及び描画命令Ｄ３，Ｄ４も示されている。但し描画命令Ｄ３，Ｄ４についての試験は試験番号が２となっており、オブジェクト符号Ｊ１，Ｊ２について描画命令Ｄ１，Ｄ２の試験とは異なる試験が例示されている。
【０１３０】
図２２は本実施の形態における結果判定を例示する図である。実施の形態１の結果判定（図１６参照）に、試験番号毎の入力データに対応する制御アプリケーションデータの項目（図中では「対応制御ＡＰデータ」と表示）が追加されている。
【０１３１】
試験番号３について、確認事項「Ｏ２.Rectangle.fillColor」(矩形の塗り潰しの色)の期待値は赤である。対応描画命令において描画関数drawRectangleの実引数の第３番目の値は「０」であり、これは白を意味する。よって結果判定は「ＮＧ」（不良）である。しかし対応制御アプリケーションデータは「２号車．空調．設定温度＝０」であって設定温度は入力データを正しく反映している。よって結果判定が不良となった原因は表示アプリケーション１７に由来し、より具体的には描画命令の処理の不良にあることが判る。
【０１３２】
試験番号４について、入力データは３号車の空調装置の設定温度を示す。しかし確認事項のオブジェクト符号Ｏ３に紐付けられた制御アプリケーションデータは、１号車の空調装置の設定温度となっており、表示アプリケーション１７うちで、紐付けられた制御アプリケーションデータの種別が間違っていることが判る。
【０１３３】
試験番号５について、入力データでは４号車の空調装置の設定温度が「２５」であるにも拘わらず、対応制御アプリケーションデータでは設定温度が「１０」であることを示している。このとき、試験結果が「ＮＧ」となる原因は、制御アプリケーション１７に由来することが判る。
【０１３４】
このようにして、制御アプリケーションデータを付加することにより、組合せ試験において不良となった原因を切り分ける作業が支援される。
【０１３５】
変形例．
ソフトウェア試験装置３０は、例えばマイクロコンピュータと記憶装置を含んで構成される。マイクロコンピュータは、プログラムに記述された各処理ステップ（換言すれば手順）を実行する。上記記憶装置は、例えばＲＯＭ(Read Only Memory)、ＲＡＭ(Random Access Memory)、書き換え可能な不揮発性メモリ（ＥＰＲＯＭ(Erasable Programmable ROM)等）、ハードディスク装置などの各種記憶装置の１つ又は複数で構成可能である。当該記憶装置は、各種の情報やデータ等を格納し、またマイクロコンピュータが実行するプログラムを格納し、また、プログラムを実行するための作業領域を提供する。なお、マイクロコンピュータは、プログラムに記述された各処理ステップに対応する各種手段として機能するとも把握でき、あるいは、各処理ステップに対応する各種機能を実現するとも把握できる。また、ソフトウェア試験装置３０はこれに限らず、ソフトウェア試験装置３０によって実行される各種手順、あるいは実現される各種手段又は各種機能の一部又は全部をハードウェアで実現しても構わない。
【０１３６】
なお、本発明は、その発明の範囲内において、各実施の形態及び変形例同士を自由に組合せたり、各実施の形態及び変形例を適宜、更に変形したり、省略したりすることが可能である。
【符号の説明】
【０１３７】
１２−１〜１２−ｎ  制御対象装置、１３−１−１〜１３−１−ｍ１〜１３−ｎ−１〜１３−ｎ−ｍｎ  制御対象装置、１４−１〜１４−ｎ  制御アプリケーション、１５  表示装置、３０  ソフトウェア試験装置、３０１  結果判定部、３０２  入力データ再生部、３０３  試験シナリオ、３０４  属性名／描画命令対応表、３１３  被試験ソフトウェア、Ｃ１〜Ｃ４  制御アプリケーションデータ、Ｄ１〜Ｄ４，Ｄ１１  描画命令。
【図１】
2015141439.tif 000003
【図２】
2015141439.tif 000004
【図３】
2015141439.tif 000005
【図４】
2015141439.tif 000006
【図５】
2015141439.tif 000007
【図６】
2015141439.tif 000008
【図７】
2015141439.tif 000009
【図８】
2015141439.tif 000010
【図９】
2015141439.tif 000011
【図１０】
2015141439.tif 000012
【図１１】
2015141439.tif 000013
【図１２】
2015141439.tif 000014
【図１３】
2015141439.tif 000015
【図１４】
2015141439.tif 000016
【図１５】
2015141439.tif 000017
【図１６】
2015141439.tif 000018
【図１７】
2015141439.tif 000019
【図１８】
2015141439.tif 000020
【図１９】
2015141439.tif 000021
【図２０】
2015141439.tif 000022
【図２１】
2015141439.tif 000023
【図２２】
2015141439.tif 000024