WO2020166345A1 - 検証装置および検証方法 - Google Patents

検証装置および検証方法 Download PDF

Info

Publication number
WO2020166345A1
WO2020166345A1 PCT/JP2020/003316 JP2020003316W WO2020166345A1 WO 2020166345 A1 WO2020166345 A1 WO 2020166345A1 JP 2020003316 W JP2020003316 W JP 2020003316W WO 2020166345 A1 WO2020166345 A1 WO 2020166345A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
phase
scenario
software program
snapshot
Prior art date
Application number
PCT/JP2020/003316
Other languages
English (en)
French (fr)
Inventor
裕二 深見
Original Assignee
日立オートモティブシステムズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Priority to US17/293,526 priority Critical patent/US11487649B2/en
Priority to JP2020572155A priority patent/JP7084505B2/ja
Publication of WO2020166345A1 publication Critical patent/WO2020166345A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Definitions

  • the present invention relates to a technology for verifying software using a virtual computer, and particularly to a verification technology suitable for developing an embedded system composed of a mechanism, hardware and software.
  • ECUs Electronic Control Units
  • the plurality of ECUs interlock with each other to control one vehicle as a system. Since the system for controlling the vehicle is complicated as described above, some modifications of the software program may affect a range not intended by the designer, causing a malfunction. Therefore, when a software program is modified, extensive regression testing is required to guarantee the quality of the system.
  • Non-Patent Document 1 proposes to test a software program of a system for controlling an automobile in a virtual verification environment by cloud computing using a virtual model and a simulator.
  • Non-Patent Document 1 By using the virtual verification environment as proposed in Non-Patent Document 1, it becomes possible to test a software program for controlling an automobile under various conditions, and it becomes easy to automatically execute the test. ..
  • the execution speed becomes slow.
  • the test speed in the virtual verification environment is 1/100 to 1/3000 as compared with the test using the actual vehicle.
  • Non-Patent Document 1 a virtual verification environment based on cloud computing as disclosed in Non-Patent Document 1, a plurality of physical computers are deployed and the tests are executed in parallel to execute the entire test. It is possible to reduce the time required.
  • One object of the present disclosure is to provide a technique for accelerating the testing of software programs.
  • a verification device emulates a microcomputer in which a software program to be tested is installed, and includes a virtual computer that verifies the software program and a plurality of test scenarios for verifying the software program.
  • a test execution control computer to be executed by the virtual computer, wherein the test execution control computer divides the test scenario into phases so as to cut out portions of the plurality of test scenarios that are common to each other as phases, and a common phase
  • the scenario division information in which the plurality of test scenarios are tree-structured is stored so as to branch the phases not common to each other from the common phase, and the common phase is executed according to the tree structure of the scenario division information.
  • the first test scenario is executed by the virtual machine so that the state of the virtual machine is saved as a snapshot, and the state in which the common phase is executed is reproduced by the snapshot, and then the non-common phase is restored.
  • the second test scenario is executed by the virtual machine as if it were executed.
  • a verification method is a verification method for verifying the software program by executing a plurality of test scenarios on a virtual computer that simulates a microcomputer on which a software program to be tested is installed. Then, the test execution control computer that causes the virtual machine to execute the plurality of test scenarios divides the test scenario into phases so as to cut out parts of the plurality of test scenarios that are common to each other, and divides the test scenarios into common phases.
  • the scenario division information in which the plurality of test scenarios are tree-structured is stored so as to branch the following non-common phases from the common phase, and the test execution control computer stores the common according to the tree structure of the scenario division information.
  • the first test scenario is executed by the virtual machine so that the state of the virtual machine is saved as a snapshot after executing the phase, and the state in which the common phase is executed is reproduced by the snapshot
  • the second test scenario is executed by the virtual machine so that the common phase is executed.
  • FIG. 3 is a diagram for explaining a test scenario division method and tree formation in the simulation system shown in FIG. 1.
  • 6 is a flowchart for explaining specific processing of the test execution control unit shown in FIG. 1.
  • 7 is a flowchart for explaining detailed processing of skip determination shown in FIG. 6.
  • 7 is a flowchart for explaining the test result determination and snapshot saving processing shown in FIG. 6.
  • FIG. 3 is a sequence diagram for explaining a communication operation between a test execution control unit, a simulator, and virtualization software when executing one phase in the simulation system shown in FIG. 1.
  • FIG. 1 is a diagram showing an example of a simulation system to which the verification device of this embodiment is applied.
  • the simulation system of this embodiment is configured to include a virtual computer management computer 200 and a test execution control computer 100.
  • the virtual computer management computer 200 is a physical computer in which the virtual computer 240 is installed.
  • the virtual machine 240 has a guest OS 250, and has a function of executing a simulator 260 including a microcomputer model 270 under the guest OS 250, thereby simulating a microcomputer on which a software program to be tested is installed and executing software. It verifies the program.
  • the virtual computer management computer 200 has a host OS 210, executes the virtualization software 220 under the host OS 210, and at a specific timing, a CPU (Central Processing Unit) state that serves as a processor of the virtual computer 240 and a virtual state.
  • a CPU Central Processing Unit
  • the virtual machine 240 has a function of saving the state of the virtual machine including the CPU state of the virtual machine 240, the memory state of the virtual machine 240, and the state of the storage device of the virtual machine 240 as a snapshot in the snapshot history 230.
  • the state of the microcomputer can be reproduced by the snapshot.
  • the processor state of the virtual machine 240 is data stored in the register of the processor
  • the memory state of the virtual machine 240 is data stored in the entire area of the memory. In that case, since the data stored in the register of the processor and the data in the entire area of the memory are recorded as a snapshot, the state of the microcomputer can be reproduced.
  • the test execution control computer 100 has a load file comparison processing unit 110 and a test execution control unit 120.
  • the load file comparison processing unit 110 compares the new ROM (Read Only Memory) load file 310 after the test execution with the old ROM load file 320 before the test execution, and determines the address where the ROM value matches the ROM match address 130. Output to a file.
  • ROM Read Only Memory
  • the old ROM load file 320 is a load file by the software program before correction when the software program of the microcomputer is corrected.
  • the new ROM load file 310 is a load file by the modified software program when the software program of the microcomputer is modified. Further, after the test is executed, when the software program of the microcomputer is modified, the test by the modified software program is executed. Then, before the test execution is before the test by the modified software program is executed, that is, after the test by the unmodified software program is executed.
  • the test execution control unit 120 causes the virtual machine 240 to execute a plurality of test scenarios for verifying the software program based on the ROM match address 130 and the execution result DB 340 of the previous test, and the simulation result is executed as the execution result. Write back to DB340.
  • the information recorded in the execution result DB 340 includes whether the test result by each test scenario is OK or NG, and the ROM address accessed in the test.
  • FIG. 2 is a diagram showing the configuration of the simulator 260 shown in FIG.
  • the simulator 260 shown in FIG. 2 includes a microcomputer model 270.
  • the microcomputer model 270 has a virtual CPU, a RAM (Random Access Memory), a ROM, and various peripherals, and can load and execute an object file of a CPU that can be executed by an actual machine. is there. Peripherals are various devices used by the CPU.
  • the accessed address of the ROM 271 (access destination address) is recorded by the ROM access monitor 262. If the ROM access information A261 from the previous test is input, the ROM access monitor 262 adds the access destination address of the new ROM 271 from this test to the ROM access information A261 and records it as the ROM access information B263.
  • FIG. 3 is a flowchart for explaining the processing of the entire test in the simulation system shown in FIG.
  • the person who performs the test starts the test (F010) and creates a test DB in the execution result DB 340 (F020).
  • FIG. 4 is a diagram showing the configuration of the execution result DB 340 shown in FIG.
  • the execution result DB 340 shown in FIG. 1 stores the execution order of the tests in the simulation system shown in FIG. 1, the files required for the simulation of each test, and the execution result of each test.
  • the result of the test using the old ROM load file 320 is stored in the execution result DB 340.
  • the result of the test using the new ROM load file 310 is stored in the execution result DB 340.
  • the execution result DB management table D100 as shown in FIG. 4 is set in the execution result DB 340 shown in FIG.
  • the execution result DB management table D100 includes a test name D110, a test scenario D120, a storage destination D130 of the expected value of the test result, a test result D130 that is a comparison between the expected value and the test result, and a snapshot after the test execution. Snapshot information D150 indicating the handling of the above, and a ROM access information storage destination D160 stored when the test is executed.
  • the execution result DB management table D100 is created in advance before the test is started. At the start of the test, each item in the table has no data.
  • test result DB 130 is updated by inputting the test results into the test DB as shown in FIG. 4 (F030).
  • FIG. 5 is a diagram for explaining a test scenario division method and tree formation in the simulation system shown in FIG. 1
  • the test execution control unit 120 divides a plurality of scenarios 1 to 5 executed in the verification in the simulation system shown in FIG. 1 into a plurality of phases A to C, respectively, and creates a scenario division vote S100. To do.
  • This scenario division vote S100 is performed by cutting out the common parts of the plurality of scenarios 1 to 5 as phases, while the plurality of scenarios 1 to 5 are originally composed of one scenario.
  • the test execution control unit 120 is a scenario division tree which is scenario division information which is a scenario division information in which a plurality of scenarios 1 to 5 are tree-formed so as to branch a common phase from a common phase. Create S200.
  • the test execution control unit 120 will determine the test execution order according to this tree.
  • the scenarios 1 to 3 are divided into three phases A, B, and C, respectively.
  • the test scenarios of the respective phases A, B and C are indicated by arrows.
  • Phase A and phase B are common in the three scenarios 1 to 3
  • phase C is different in the three scenarios 1 to 3.
  • the test execution control unit 120 creates a tree that determines the execution order of test scenarios. In the execution order of this example, first, PT. A1 and P phase B PT. Perform B1 only once each. Then, for scenario 1, PT. Carry out C1. For scenario 2, the implementation up to phase B is omitted, and the PT. Carry out C2. For scenario 3, the implementation up to phase B is omitted, and the PT. Carry out C3.
  • the test execution control unit 120 checks the expected value at the end of the test of each phase of the test scenario.
  • the expected value check is a process of comparing an output value obtained as a result of executing the test with an expected value assumed in advance and determining whether the test is OK or NG.
  • the state of the virtual machine 240 in the relevant phase is saved as a snapshot in the snapshot history 230.
  • the test execution control unit 120 regards the scenario division tree S200 as a tree and schedules the search order in the depth-first search as one of the methods for determining the execution order of each scenario.
  • the execution of the common phases can be omitted by reproducing the state of the virtual machine after executing the common phases with the snapshot.
  • a plurality of test scenarios are executed by the virtual machine, it is possible to speed up the test of the software program.
  • FIG. 6 is a flowchart for explaining specific processing of the test execution control unit 120 shown in FIG. After starting the process (F100), the test execution control unit 120 first determines whether to skip (omit) the test (F110).
  • FIG. 7 is a flowchart for explaining detailed processing of skip determination shown in FIG.
  • the test execution control unit 120 first clears the test skip label to 0 (F111).
  • the actual results of whether or not the software program has been tested in the past are confirmed (F112), and if there is the actual test results, the old ROM load file 320 is deleted.
  • the load file comparison processing unit 110 of the test execution control computer 100 refers to the new ROM load file 310 and the old ROM load file 320, and accesses where the values of the software program before change and the software program after change match.
  • the destination address is extracted and recorded in the file of the ROM matching address 130 as unchanged address information.
  • test execution control unit 120 refers to the ROM match address 130, and the access destination address from the beginning of the scenario related to this test to the common phase is the unchanged address information. (F114).
  • test execution control unit 120 leaves the test skip label at 0 (F115). As a result, the test is executed without being skipped.
  • test execution control unit 120 sets the label of test skip to 1 Yes (F116). As a result, the test is skipped.
  • test execution control unit 120 determines whether there is a preceding phase of that phase (F130). If there is the preceding phase, the test execution control unit 120 gives an instruction to load the snapshot of the preceding phase from the snapshot history 230 (F131). As a result, the state of the virtual machine 240 after the execution of the common phase can be reproduced by the snapshot.
  • the test execution control unit 120 instructs the next test execution (F140) when there is no preceding phase in F130 or after issuing the load instruction in F131, and waits for the completion of the test (F142). .. When the test is completed, the test execution control unit 120 determines the test result, saves the snapshot of the virtual machine 240 in the snapshot history 230, and updates the test result DB 130 (F150).
  • FIG. 8 is a flowchart for explaining the process of determining the test result, saving the snapshot, and updating the DB shown in FIG.
  • test execution control unit 120 refers to the scenario division tree S200 shown in FIG. 3 and continues to that phase. It is determined whether there is a subsequent phase (F153). If there is a subsequent phase, the test execution control unit 120 saves the state of the virtual machine 240 after causing the virtual machine 240 to execute that phase as a snapshot in the snapshot history 230 (F154), and at the same time, the test scenario
  • the execution result DB 340 is updated by storing the access destination address accessed by the virtual machine 240 from the beginning to the phase and the fact that the test result (F140) is OK (F155).
  • test execution control unit 120 does not perform the process of saving the state of the virtual machine 240 as a snapshot in the snapshot history 230.
  • the execution result DB 340 is updated by saving that the test result (F140) is NG (F155).
  • test execution control unit 120 determines whether or not all the tests are completed (F160, F170), and if there are unexecuted tests, the target test is updated (F180). , F110, the test is continued, and the process ends (F190).
  • the software program when the software program is changed, if the test result before the change is good and the value of the access destination address is common before and after the change, the first test in the second test scenario is performed. Since the execution of the test in the same phase as the scenario is omitted, it is possible to execute the retest for the part that is affected by the change of the software program and omit the process for the part that is not affected.
  • test result is good for each phase of the test scenario, and the state of the virtual machine after the execution of a certain phase in the subsequent phase is saved as a snapshot, and the virtual machine from the beginning of the test scenario to that phase is saved. Since the access destination address accessed by is stored, when the software program is changed, it is possible to easily generate the unchanged address information by using the access destination address.
  • test execution control unit 120 The communication operation between the test execution control unit 120, the simulator 260, and the virtualization software 220 in the simulation system shown in FIG. 1 will be described below.
  • FIG. 9 is a sequence diagram for explaining the communication operation among the test execution control unit 120, the simulator 260, and the virtualization software 220 when executing one phase in the simulation system shown in FIG.
  • test execution control unit 120 When performing the above-mentioned test execution, if it is not the first phase of the test scenario, the test execution control unit 120 issues a snapshot load instruction and a snapshot ID for identifying the snapshot to be loaded to the virtualization software 220 ( F201).
  • the virtualization software 220 loads the snapshot identified by the snapshot ID from the snapshot history 230, and when the loading of the snapshot is completed, a snapshot load completion report is sent to the test execution control unit 120. Perform (F202). In the first phase of the test scenario, F201 and F202 are not performed.
  • test execution control unit 120 issues to the simulator 260 a simulation start instruction, a test scenario, a ROM load file, and other auxiliary files necessary for simulation, such as sensor input information and trace information. (F203).
  • the simulator 260 executes a simulation by using the information issued from the test execution control unit 120, and when the simulation is completed, the simulator 260 reports to the test execution control unit 120 a simulation completion report, a test execution result which is a simulation result, and a ROM. Report access information (F204).
  • the test execution control unit 120 determines the test result reported from the simulator 260, and if the test result is the expected operation, the test execution control unit 120 notifies the virtualization software 220 of the snapshot save instruction and the snapshot.
  • the snapshot ID is designated (F205).
  • the virtualization software 220 saves the test result as a snapshot in the snapshot history 230 according to the instruction from the test execution control unit 120, and when the saving is completed, reports the snapshot save completion to the test execution control unit 120. Yes (F206).
  • test execution control computer 100 and the virtual computer management computer 200 are different computers. However, when the resources of the computer are reduced, the process executed by the test execution control computer 100 is executed by the virtual computer management computer 200. It may be performed under the control of the host OS.
  • the virtual computer 240 executes a model simulating an on-vehicle electronic control device and a simulator simulating an automobile on the on-vehicle electronic control device.
  • the test scenario may be for verifying "failure processing" or for verifying "each function in normal condition”.
  • the following describes an operation example when there is a defect in the test and a retest is performed after the software program is corrected to address the defect.
  • the test execution control unit 120 creates the test database in F020, and then executes the tests in order according to the DB management table in the test execution in F030 and the update process of the test DB. At that time, for example, when the test result of NO9 shown in FIG. 4 becomes NG, the test execution control unit 120 updates the test DB according to the processing flow without executing the subsequent test. After that, the defect is corrected and retested by the defect correction F050 in the flow shown in FIG.
  • the load file comparison processing unit 110 determines the addresses of the old ROM load file 320 before the defect correction and the new ROM load file 310 after the defect correction that have the same ROM values in the two load files. Extract. After that, processing is performed according to the processing flow of the test execution control unit 120.
  • the judgment at F114 shown in FIG. 7 is made. If the access destination in the new ROM is included in the ROM matching address 130, the ROM value of the address executed in the new ROM is the same as the ROM value of the address executed in the old ROM, and the software processing is the same. Become. In that case, the test result of the test is the same as the previous time, and thus the test is skipped.
  • the test of the test No. 9 shown in FIG. 4 becomes NG, and the range of change of the ROM due to the correction for eliminating the defect is the PT.
  • the correction of the ROM is PT. It also affects the subsequent phases of the B2 test. Therefore, NO6, 7, 9, and 10 in FIG. 4 are retested. For NO1 to NO5 and NO8, if the ROM address to be executed and the ROM value of the address are the same, those tests are skipped. As a result, the tests to be executed can be narrowed down, and the overall test time can be shortened.
  • test execution control computer 110: load file comparison processing unit, 120: test execution control unit, 130: ROM matching address

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

ソフトウェアプログラムのテストを高速化する。テスト対象であるソフトウェアプログラムが搭載されるマイクロコンピュータを擬似する仮想計算機２４０と、複数のテストシナリオの共通する部分をフェーズとして切り出すようにテストシナリオをフェーズに分割し、共通するフェーズに続く共通しないフェーズを共通するフェーズから枝分かれさせるように複数のテストシナリオをツリー化して記憶しておき、このツリー構造に従って、共通するフェーズを実行させた後に仮想計算機２４０の状態をスナップショットとして保存させるように第１のテストシナリオを仮想計算機２４０に実行させ、スナップショットにより共通するフェーズを実行した状態を再現させた後に共通しないフェーズを実行させるように第２のテストシナリオを仮想計算機２４０に実行させるテスト実行制御計算機１００とを有する。

Description

検証装置および検証方法
　本発明は、仮想計算機を用いてソフトウェアを検証する技術に関し、特に、メカニズム、ハードウェアおよびソフトウェアで構成される組み込みシステムの開発に適した検証技術に関する。
　近年、自動車の車両の制御が高機能化し複雑化しており、それに伴い、１台の車両に搭載されるＥＣＵ（Electric Control Unit）の数が増加している。そして、それら複数のＥＣＵが相互に連動してシステムとして１台の車両の制御を行っている。このように車両を制御するシステムが複雑化しているため、ソフトウェアプログラムの一部の修正が設計者も意図していない範囲に影響し、不具合を生じさせることがある。そのため、ソフトウェアプログラムを修正したときには、システムとしての品質を保証するために、広範にわたる回帰テストを行うことが求められる。
　また、自動車の高い安全性および高い信頼性を確保するために、自動車の電子機能安全規格（ISO26262）、ＦＴＡ（故障の木解析）およびＦＭＥＡ（故障モード影響解析）などの知見あるいは手法を活用することが求められている。それらの活用は自動車の安全性および信頼性の向上につながるが、一方でテスト自体を増大させることにもなる。
　非特許文献１には、自動車を制御するシステムのソフトウェアプログラムを、仮想的なモデルおよびシミュレータを用いたクラウドコンピューティングによる仮想検証環境でテストすることが提案されている。
宮崎義弘、「機能安全ISO26262と仮想ECU応用技術, p10, 次世代のソフト検証環境: V2Cloud」、［online］、2012年11月14日、[2019年1月11日検索]、インターネット<URL: http://www.edsfair.com/2012/special/pdf/eds2012_sp01_2.pdf >
　非特許文献１に提案されているような仮想検証環境を用いることで、自動車を制御するソフトウェアプログラムを様々な条件でテストすることが可能となり、またそのテストを自動で実行することも容易になる。
　また、自動車の開発には短期化も求められている。そのため、試作車を作製することなく自動車を開発するといった自動車開発の試作レス化の動きが加速している。試作レスで自動車を開発する場合、ソフトウェアプログラムのテストには、実車が無い環境で、短期間で効率よく行い、かつ高い品質を確保することが求められる。
　しかし、仮想検証環境でのテストでは、実車の各部の機械および電子回路をそれぞれモデルおよびシミュレータで仮想的に模擬して行うことになるので、実行速度が低速になる。一般に仮想検証環境でのテストは、実車を使ったテストに比べると実行速度が1/100～1/3000となる。
　また、近年では自動車に搭載される車載用マイコンは、動作周波数が上がり、マルチコア化および多機能化も進んでいる。それに伴い、仮想検証環境において車載用マイコンを模擬するマイコンモデルも複雑となり、シミュレーションの実行に要する処理負荷が増大している。
　これらに対して、非特許文献１に開示されているようなクラウドコンピューティングによる仮想検証環境では、複数の物理計算機を配備し、それらに並列でテストを実行させることでテスト全体を実行するのに要する時間を短縮することは可能である。
　しかしながら、クラウドコンピューティングによるシミュレーションで実車を使ったテストと同等の速度を得ようとすると、リソースとして多数の物理計算機を備えた大規模なクラウド環境の準備が必要となる。そして、その場合には、物理計算機に用いるツールについて物理計算機毎にそれぞれライセンスを取得する必要があり、コストも増大する。
　このような問題点は、上述したような自動車開発に限らず、一般的なソフトウェアプログラムの開発においても同様に生じるものである。
　本開示のひとつの目的は、ソフトウェアプログラムのテストを高速化する技術を提供することである。
　本開示のひとつの態様による検証装置は、テスト対象であるソフトウェアプログラムが搭載されるマイクロコンピュータを擬似し、前記ソフトウェアプログラムを検証する仮想計算機と、前記ソフトウェアプログラムを検証するための複数のテストシナリオを前記仮想計算機に実行させるテスト実行制御計算機とを有し、前記テスト実行制御計算機は、前記複数のテストシナリオの互いに共通する部分をフェーズとして切り出すように前記テストシナリオをフェーズに分割し、共通するフェーズに続く互いに共通しないフェーズを前記共通するフェーズから枝分かれさせるように前記複数のテストシナリオをツリー化したシナリオ分割情報を記憶しておき、前記シナリオ分割情報のツリー構造に従って、前記共通するフェーズを実行させた後に前記仮想計算機の状態をスナップショットとして保存させるように第１のテストシナリオを前記仮想計算機に実行させ、前記スナップショットにより前記共通するフェーズを実行した状態を再現させた後に前記共通しないフェーズを実行させるように第２のテストシナリオを前記仮想計算機に実行させる。
　また、本開示のひとつの態様による検証方法は、テスト対象であるソフトウェアプログラムが搭載されるマイクロコンピュータを擬似する仮想計算機にて複数のテストシナリオを実行させることで前記ソフトウェアプログラムを検証する検証方法であって、前記複数のテストシナリオを前記仮想計算機に実行させるテスト実行制御計算機が、前記複数のテストシナリオの互いに共通する部分をフェーズとして切り出すように前記テストシナリオをフェーズに分割し、共通するフェーズに続く互いに共通しないフェーズを前記共通するフェーズから枝分かれさせるように前記複数のテストシナリオをツリー化したシナリオ分割情報を記憶し、前記テスト実行制御計算機が、前記シナリオ分割情報のツリー構造に従って、前記共通するフェーズを実行させた後に前記仮想計算機の状態をスナップショットとして保存させるように第１のテストシナリオを前記仮想計算機に実行させ、前記スナップショットにより前記共通するフェーズを実行した状態を再現させた後に前記共通しないフェーズを実行させるように第２のテストシナリオを前記仮想計算機に実行させる。
　本開示のひとつの態様によれば、テスト全体の計算負荷を下げることで、テストの実行時間を短くすることが可能となる。
本実施形態の検証装置が適用されるシミュレーションシステムの一例を示す図である。 図１に示したシミュレータの構成を示す図である。 図１に示したミュレーションシステムにおけるテスト全体の処理を説明するためのフローチャートである。 図１に示した実行結果ＤＢの構成を示す図である。 図１に示したシミュレーションシステムにおけるテストシナリオの分割方法とツリー化を説明するための図である。 図１に示したテスト実行制御部の具体的な処理を説明するためのフローチャートである。 図６に示したスキップ判定の詳細な処理を説明するためのフローチャートである。 図６に示したテスト結果の判定とスナップショットの保存処理を説明するためのフローチャートである。 図１に示したシミュレーションシステムにおいて１つのフェーズを実行する際のテスト実行制御部とシミュレータと仮想化ソフトウェアとの間の通信動作を説明するためのシーケンス図である。
　以下に、本開示の実施形態について図面を参照して説明する。
　図１は、本実施形態の検証装置が適用されるシミュレーションシステムの一例を示す図である。
　本形態のシミュレーションシステムは図１に示すように、仮想計算機管理計算機２００と、テスト実行制御計算機１００とを有して構成されている。
　仮想計算機管理計算機２００は、仮想計算機２４０を配備した物理的な計算機である。
　仮想計算機２４０は、ゲストＯＳ２５０を有し、このゲストＯＳ２５０配下でマイコンモデル２７０を含むシミュレータ２６０を実行する機能を具備することで、テスト対象であるソフトウェアプログラムが搭載されるマイクロコンピュータを擬似し、ソフトウェアプログラムを検証するものである。また、仮想計算機管理計算機２００は、ホストＯＳ２１０を有し、このホストＯＳ２１０の配下で仮想化ソフトウェア２２０を実行し、特定のタイミングで仮想計算機２４０のプロセッサとなるＣＰＵ（Central Processing Unit）状態と、仮想計算機２４０のメモリ状態と、仮想計算機２４０の記憶装置の状態とを含めた仮想計算機の状態をスナップショットとしてスナップショット履歴２３０に保存する機能と、スナップショット履歴２３０に記録された情報を用いて仮想計算機２４０をある特定の状態に戻す機能を有する。このように、仮想計算機２４０のＣＰＵ状態と、仮想計算機２４０のメモリ状態と、仮想計算機２４０の記憶装置の状態とを含めた仮想計算機の状態をスナップショットとしてスナップショット履歴２３０に保存する機能を有することにより、スナップショットによりマイクロコンピュータの状態を再現することができる。また、一例として、仮想計算機２４０のプロセッサの状態が、プロセッサのレジスタに格納されているデータであり、仮想計算機２４０のメモリの状態が、メモリの全領域に格納されているデータである。その場合であれば、プロセッサのレジスタに格納されているデータとメモリの全領域のデータとをスナップショットとして記録するので、マイクロコンピュータの状態を再現することができる。
　テスト実行制御計算機１００は、ロードファイル比較処理部１１０と、テスト実行制御部１２０とを有している。ロードファイル比較処理部１１０は、テスト実行後の新ＲＯＭ（Read Only Memory）ロードファイル３１０と、テスト実行前の旧ＲＯＭロードファイル３２０とを比較し、ＲＯＭ値が一致したアドレスをＲＯＭ一致アドレス１３０のファイルに出力する。
　ここで、旧ＲＯＭロードファイル３２０は、マイコンのソフトウェアプログラムが修正された場合の修正前のソフトウェアプログラムによるロードファイルである。新ＲＯＭロードファイル３１０は、マイコンのソフトウェアプログラムが修正された場合の修正後のソフトウェアプログラムによるロードファイルである。また、テスト実行後は、マイコンのソフトウェアプログラムが修正された場合の修正後のソフトウェアプログラムによるテストを実行した後のことである。そして、テスト実行前は、修正後のソフトウェアプログラムによるテストを実行する前、すなわち修正前のソフトウェアプログラムによるテストを実行した後のことである。
　テスト実行制御部１２０は、ＲＯＭ一致アドレス１３０と、前回のテストの実行結果ＤＢ３４０とに基づいて、ソフトウェアプログラムを検証するための複数のテストシナリオを仮想計算機２４０に実行させ、そのシミュレーション結果を実行結果ＤＢ３４０に書き戻す。実行結果ＤＢ３４０に記録される情報には、各テストシナリオによるテスト結果がＯＫであったかＮＧであったかと、そのテストにおいてアクセスされたＲＯＭアドレスと、が含まれる。
　ここで前回のテストというのは、マイコンのソフトウェアプログラムが修正された場合の修正後のソフトウェアプログラムでのテストを実行する前に行われたテストである。すなわち、修正前のソフトウェアプログラムでのテストである。アクセスされるＲＯＭアドレスがソフトウェアプログラムの修正の影響を受けずかつテスト結果がＯＫであったところまでは、修正後のソフトウェアプログラムでのテストシナリオの実行が省かれる。
　図２は、図１に示したシミュレータ２６０の構成を示す図である。
　図２に示したシミュレータ２６０はマイコンモデル２７０を含んでいる。マイコンモデル２７０は図２に示すように、仮想的なＣＰＵやＲＡＭ（Random Access Memory）、ＲＯＭ、各種ペリフェラルを搭載しており、実機で実行可能なＣＰＵのオブジェクトファイルをロードして実行できるものである。ペリフェラルはＣＰＵが利用する各種機器である。アクセスされたＲＯＭ２７１のアドレス（アクセス先アドレス）は、ＲＯＭアクセスモニタ２６２によって記録される。ＲＯＭアクセスモニタ２６２は、前回のテストによるＲＯＭアクセス情報Ａ２６１の入力があれば、そのＲＯＭアクセス情報Ａ２６１に、今回のテストによる新たなＲＯＭ２７１のアクセス先アドレスを加えて、ＲＯＭアクセス情報Ｂ２６３として記録する。
　以下に、上記のように構成されたシミュレーションシステムにおける処理について説明する。
　まず、図１に示したシミュレーションシステムにおけるテスト全体の処理について説明する。
　図３は、図１に示したシミュレーションシステムにおけるテスト全体の処理を説明するためのフローチャートである。
　図１に示したシミュレーションシステムにおいてテストを実施する場合は、まず、テストを実施する者が、テストを開始するにあたり（Ｆ０１０）、実行結果ＤＢ３４０にテストＤＢを作成する（Ｆ０２０）。
　図４は、図１に示した実行結果ＤＢ３４０の構成を示す図である。
　図１に示した実行結果ＤＢ３４０には、図１に示したシミュレーションシステムにおけるテストの実行順序と、各テストのシミュレーションに必要なファイルと、各テストの実行結果とが格納される。新ＲＯＭロードファイル３１０のテスト実行前は、実行結果ＤＢ３４０には、旧ＲＯＭロードファイル３２０を用いたテストの結果が格納されている。新ＲＯＭロードファイル３１０のテスト実行後は、実行結果ＤＢ３４０に、新ＲＯＭロードファイル３１０を用いたテストの結果が格納される。
　図１に示した実行結果ＤＢ３４０には、図４に示すような実行結果ＤＢ管理テーブルＤ１００が設定される。実行結果ＤＢ管理テーブルＤ１００は、テスト名Ｄ１１０と、テストシナリオＤ１２０と、テスト結果の期待値の格納先Ｄ１３０と、期待値とテスト結果との比較であるテスト結果Ｄ１３０と、テスト実行後のスナップショットの扱いを示すスナップショット情報Ｄ１５０と、テストを実行した際に格納されるＲＯＭアクセス情報格納先Ｄ１６０とを含んでいる。実行結果ＤＢ管理テーブルＤ１００は、テストが開始される前に予め作成されている。テスト開始時においては、テーブルの各項目はデータが入っていない状態となっている。
　上記のようなテストＤＢを作成した後、テストを実行し（Ｆ０３０）、図４に示したようにテストの結果をテストＤＢに入力していくことでテスト結果ＤＢ１３０を更新する（Ｆ０３０）。
　その後、全てのテストが完了したかどうかを判断し（Ｆ０４０）、テストが完了していない場合は、ソフトウェアプログラムに不具合があると考えられるので、不具合を修正する作業を行い（Ｆ０５０）、Ｆ０３０に戻ってテストをやり直す。また、全てのテストが完了した場合は、テストを終了する（Ｆ０６０）。
　ここで、図１に示したシミュレーションシステムは、テストに係るテストシナリオを分割してツリー化しておき、そのツリーに従ってテストを実行する。以下に、テストシナリオのツリー化の方法について説明する。
　図５は、図１に示したシミュレーションシステムにおけるテストシナリオの分割方法とツリー化を説明するための図である。
　テスト実行制御部１２０は、図５に示すように、図１に示したシミュレーションシステムにおける検証で実行する複数のシナリオ１～５をそれぞれ複数のフェーズＡ～Ｃに分割してシナリオ分割票Ｓ１００を作成する。このシナリオ分割票Ｓ１００は、複数のシナリオ１～５はそれぞれ元々１本のシナリオで構成されているところ、複数のシナリオ１～５の互いに共通する部分をフェーズとして切り出すようにして行う。
　テスト実行制御部１２０はその後、図５に示すように、共通するフェーズに続く共通しないフェーズを共通するフェーズから枝分かれさせるように複数のシナリオ１～５をツリー化したシナリオ分割情報となるシナリオ分割ツリーＳ２００を作成する。テスト実行制御部１２０は、このツリーに従ってテストの実行順序を決めることになる。
　例えば、図５の例において、シナリオ分割表Ｓ１００のシナリオ１～３に着目すると、シナリオ１～３は、それぞれにフェーズＡ，Ｂ，Ｃの３つに分けられている。シナリオ分割表Ｓ１００には、それぞれのフェーズＡ，Ｂ，Ｃのテストシナリオが矢印で示されている。３つのシナリオ１～３においてフェーズＡとフェーズＢは共通であり、フェーズＣは３つのシナリオ１～３で互いに異なる。この構成に応じて、テスト実行制御部１２０は、テストシナリオの実施順序を決めるツリーを作成する。本例の実行順序では、まず、フェーズＡのＰＴ．Ａ１とＰフェーズＢのＰＴ．Ｂ１をそれぞれ１回のみ実施する。そして、シナリオ１については更にフェーズＣのＰＴ．Ｃ１を実施する。シナリオ２についてはフェーズＢまでは実施を省き、フェーズＣのＰＴ．Ｃ２を実施する。シナリオ３についてはフェーズＢまでは実施を省き、フェーズＣのＰＴ．Ｃ３を実施する。
　その際、テスト実行制御部１２０は、テストシナリオについての各フェーズのテスト終了時に期待値チェックを行う。期待値チェックとは、テストを実行した結果として得られた出力値と、予め想定されている期待値とを比較し、テストがＯＫであったかＮＧであったか判断する処理である。その後、当該フェーズに後続フェーズがある場合は、当該フェーズにおける仮想計算機２４０の状態をスナップショットとしてスナップショット履歴２３０に保存しておく。そして、異なるテストシナリオを仮想計算機２４０にて実行する際、共通するフェーズについては、スナップショット履歴２３０に保存されたスナップショットにより仮想計算機２４０に共通するフェーズを実行させた状態を再現させ、その後、それに続く共通しないフェーズを仮想計算機２４０に実行させる。なお、テスト実行制御部１２０は、各シナリオの実行順序の決め方の１つとして、シナリオ分割ツリーＳ２００をツリーとみなし、深さ優先探索の検索順にスケジューリングする。
　このように、複数のテストシナリオに共通するフェーズを繰り返し実行するのではなく、スナップショットで、共通するフェーズを実行した後の仮想計算機の状態を再現することで、共通するフェーズの実行を省略するように、複数のテストシナリオを仮想計算機に実行させるので、ソフトウェアプログラムのテストを高速化することができる。
　次に、図１に示したテスト実行制御部１２０の具体的な処理について説明する。
　図６は、図１に示したテスト実行制御部１２０の具体的な処理を説明するためのフローチャートである。
　テスト実行制御部１２０は、処理開始後（Ｆ１００）、まず、テストをスキップ（省略）するかどうかを判定する（Ｆ１１０）。
　図７は、図６に示したスキップ判定の詳細な処理を説明するためのフローチャートである。
　スキップ判定においては、テスト実行制御部１２０はまず、テストスキップのラベルを０にクリアする（Ｆ１１１）。
　次に、例えば、変更されたソフトウェアプログラムの検証を行う場合、過去にそのソフトウェアプログラムについてテストを行ったかどうかの実績を確認し（Ｆ１１２）、テストの実績がある場合は、旧ＲＯＭロードファイル３２０を参照し、その前回のテスト結果が良好であったかどうかを判断する（Ｆ１１３）。ここで、テスト実行制御計算機１００のロードファイル比較処理部１１０は、新ＲＯＭロードファイル３１０および旧ＲＯＭロードファイル３２０を参照し、変更前のソフトウェアプログラムと変更後のソフトウェアプログラムとで値が一致するアクセス先アドレスを抽出して変更無しアドレス情報としてＲＯＭ一致アドレス１３０のファイルに記録しておく。
　前回のテスト結果が良好であった場合は、テスト実行制御部１２０は、ＲＯＭ一致アドレス１３０を参照し、今回のテストに係るシナリオの先頭から共通するフェーズまでのアクセス先アドレスが、変更無しアドレス情報に含まれているかどうかを判断する（Ｆ１１４）。
　そして、テストの実績がない場合、前回のテストの結果が良好ではない場合、あるいは、今回のテストに係るシナリオの先頭から共通するフェーズまでのアクセス先アドレスが、変更無しアドレス情報に含まれていない場合、テスト実行制御部１２０は、テストスキップのラベルを０のままとする（Ｆ１１５）。これにより、当該テストはスキップされずに実施されることになる。
　一方、Ｆ１１４にて、今回のテストに係るシナリオの先頭から共通するフェーズまでのアクセス先アドレスが、変更無しアドレス情報に含まれている場合、テスト実行制御部１２０は、テストスキップのラベルを１とする（Ｆ１１６）。これにより当該テストはスキップされることとなる。
　図６に戻り、テストスキップのラベルが１ではない場合は（Ｆ１２０）、テスト実行制御部１２０は、そのフェーズの前段フェーズがあるかどうかを判断する（Ｆ１３０）。前段フェーズがある場合、テスト実行制御部１２０は、前段フェーズのスナップショットをスナップショット履歴２３０からロードする旨の指示を出す（Ｆ１３１）。これにより、共通するフェーズの実行後の仮想計算機２４０の状態をスナップショットにより再現させることができる。
　テスト実行制御部１２０は、Ｆ１３０にて前段フェーズが無いとき、あるいは、Ｆ１３１にてロード指示を行った後、次にテストの実行を指示し（Ｆ１４０）、テストが完了するのを待つ（Ｆ１４２）。テストが完了すると、テスト実行制御部１２０は、テスト結果の判定と仮想計算機２４０のスナップショットのスナップショット履歴２３０への保存と、テスト結果ＤＢ１３０の更新を行う（Ｆ１５０）。
　図８は、図６に示したテスト結果の判定とスナップショットの保存とＤＢ更新の処理を説明するためのフローチャートである。
　テスト実行制御部１２０は、テスト結果の判定において（Ｆ１５１）、テストシナリオのフェーズについてのテスト結果が良好である場合（Ｆ１５２）、図３に示したシナリオ分割ツリーＳ２００を参照してそのフェーズに続く後続フェーズがあるかどうかを判断する（Ｆ１５３）。後続フェーズがある場合は、テスト実行制御部１２０は、そのフェーズを仮想計算機２４０に実行させた後の仮想計算機２４０の状態をスナップショットとしてスナップショット履歴２３０に保存するとともに（Ｆ１５４）、テストシナリオの先頭から該フェーズまでに仮想計算機２４０がアクセスしたアクセス先アドレスとテスト結果（Ｆ１４０）にOKであることを保存することで実行結果ＤＢ３４０を更新する（Ｆ１５５）。そして、ソフトウェアプログラムが変更されたとき、保存されたアクセス先アドレスを変更無しアドレス情報を生成するのに利用することになる。テスト結果が良好でない場合（Ｆ１５２）、そのフェーズに続く後続フェーズがない場合（Ｆ１５３）、テスト実行制御部１２０は、仮想計算機２４０の状態をスナップショットとしてスナップショット履歴２３０に保存する処理を行わず、テスト結果（Ｆ１４０）にNGであることを保存することで実行結果ＤＢ３４０を更新する（Ｆ１５５）。
　図６に戻り、その後、テスト実行制御部１２０は、全てのテストが完了したかどうかを判断し（Ｆ１６０，Ｆ１７０）、未実行のテストが残っている場合は、対象テストを更新し（Ｆ１８０）、Ｆ１１０の処理に戻りテストを継続し、処理を終了する（Ｆ１９０）。
　このように、ソフトウェアプログラムが変更されたときには、変更前のテスト結果が良好でありかつ変更前と変更後でアクセス先アドレスの値が共通する場合に、第２のテストシナリオにおける、第１のテストシナリオと共通するフェーズのテストの実行を省略するので、ソフトウェアプログラムの変更で影響する部分については再テストを実行し、影響しない部分については処理を省略するということが可能となる。
　また、テストシナリオの各フェーズについてテスト結果が良好であり、後続のフェーズがあるフェーズを実行させた後の仮想計算機の状態をスナップショットとして保存するとともに、テストシナリオの先頭からそのフェーズまでに仮想計算機がアクセスしたアクセス先アドレスを保存しておくので、ソフトウェアプログラムが変更されたとき、そのアクセス先アドレスを利用して変更無しアドレス情報を容易に生成することができる。
　以下に、図１に示したシミュレーションシステムにおけるテスト実行制御部１２０とシミュレータ２６０と仮想化ソフトウェア２２０との間の通信動作について説明する。
　図９は、図１に示したシミュレーションシステムにおいて１つのフェーズを実行する際のテスト実行制御部１２０とシミュレータ２６０と仮想化ソフトウェア２２０との間の通信動作を説明するためのシーケンス図である。
　上述したテスト実行する際、テストシナリオの先頭フェーズでない場合は、テスト実行制御部１２０から仮想化ソフトウェア２２０に対して、スナップショットロード指示と、ロードするスナップショットを識別するスナップショットＩＤを発行する（Ｆ２０１）。
　これを受けた仮想化ソフトウェア２２０は、スナップショット履歴２３０からスナップショットＩＤによって識別されるスナップショットをロードし、スナップショットのロードが完了すると、テスト実行制御部１２０に対してスナップショットロード完了報告を行う（Ｆ２０２）。なお、テストシナリオの先頭フェーズであれば、Ｆ２０１，Ｆ２０２は行われない。
　次にテスト実行制御部１２０は、シミュレータ２６０に対して、シミュレーション開始指示と、テストシナリオと、ＲＯＭのロードファイルと、センサの入力情報やトレース情報等のその他シミュレーションに必要な付属ファイルとを発行する（Ｆ２０３）。
　シミュレータ２６０は、テスト実行制御部１２０から発行された情報を用いてシミュレーションを実行し、シミュレーションが完了すると、テスト実行制御部１２０に対して、シミュレーション完了報告と、シミュレーション結果であるテスト実行結果とＲＯＭアクセス情報とを報告する（Ｆ２０４）。
　テスト実行制御部１２０は、シミュレータ２６０から報告されたテスト結果を判定し、テスト結果が期待通りの動作であれば、仮想化ソフトウェア２２０に対し、スナップショットセーブ指示と、スナップショットを識別するためのスナップショットＩＤを指示する（Ｆ２０５）。
　仮想化ソフトウェア２２０は、テスト実行制御部１２０からの指示に従って、テスト結果をスナップショットとしてスナップショット履歴２３０に保存し、保存が完了したところで、テスト実行制御部１２０に対してスナップショットセーブ完了を報告する（Ｆ２０６）。
　図１に示したシミュレーションシステムにおいては、テスト実行制御計算機１００および仮想計算機管理計算機２００を上述したように連動させることで、シミュレーション途中結果の再利用を可能とし、計算機の負荷を下げ、シミュレーション全体の実行時間を短縮する。
　なお、本形態においては、テスト実行制御計算機１００と仮想計算機管理計算機２００は別の計算機としているが、計算機のリソースを減らす場合は、テスト実行制御計算機１００で行う処理を仮想計計算機管理計算機２００のホストＯＳ配下で行ってもよい。
　また、上述したシミュレーションシステムは、自動車に搭載される車載電子制御装置の各種機能を検証するものに適用することが考えられる。その場合、仮想計算機２４０が車載電子制御装置を擬似するモデルと、車載電子制御装置に対して自動車を疑似するシミュレータとを実行することになる。また、そのような検証においては、テストシナリオは、「障害処理」を検証するためのものや、「正常時の各機能」を検証するためのものが考えられる。
　以下に、テストにおいて不具合があり、ソフトウェアプログラムに不具合に対処する修正を行った後、再テストを実施する場合の動作例について説明する。
　テスト実行制御部１２０は、図３に示したテストフローに従い、Ｆ０２０におけるテストデータベースの作成の後、Ｆ０３０におけるテスト実行とテストＤＢの更新処理においてＤＢ管理テーブルに従って順にテストを実施する。その際、例えば、図４に示したＮＯ９のテスト結果がＮＧとなった場合、テスト実行制御部１２０は、処理フローに従い、後続のテストを実行せずに、テストＤＢを更新する。この後、図３に示したフローにおける不具合修正Ｆ０５０にて、不具合を修正して再テストを実施する。
　再テストの実施に際し、ロードファイル比較処理部１１０が、不具合修正前の旧ＲＯＭロードファイル３２０と不具合修正後の新ＲＯＭロードファイル３１０とについてそれら２つのロードファイルにおけるＲＯＭ値が互いに同じであるアドレスを抽出する。この後、テスト実行制御部１２０の処理フローに従って処理する。
　各テストの実行において、図７に示したＦ１１４における判断が行われる。新ＲＯＭにおけるアクセス先がＲＯＭ一致アドレス１３０に含まれていれば、新ＲＯＭで実行するアドレスのＲＯＭ値が、旧ＲＯＭで実行したアドレスのＲＯＭ値と同じであり、ソフトウェアの処理は同一ということになる。その場合、当該テストのテスト結果は前回と同じとなるので、当該テストはスキップされる。
　ここで、図４に示したテストＮＯ９のテストがＮＧとなり、その不具合を解消する修正によるＲＯＭの変更範囲が、フェーズＢのＰＴ．Ｂ２テストで実行されるとする。その場合、ＲＯＭの修正がＰＴ．Ｂ２テストの後続のフェーズにも影響する。したがって、図４におけるＮＯ６，７，９，１０が再テストとなる。ＮＯ１～ＮＯ５およびＮＯ８は、実行するＲＯＭのアドレスおよびそのアドレスのＲＯＭ値が同じであれば、それらのテストはスキップされる。これにより、実行するテストを絞り込むことができ、全体のテスト時間短縮することができる。
　上述した実施形態は、本開示の説明のための例示であり、本開示の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、発明の範囲を逸脱することなしに、他の様々な態様で実施することができる。
１００：テスト実行制御計算機、１１０：ロードファイル比較処理部、１２０：テスト実行制御部、１３０：ＲＯＭ一致アドレス、２００：仮想計算機管理計算機、２１０：ホストＯＳ、２２０：仮想化ソフトウェア、２３０：スナップショット履歴、２４０：仮想計算機、２５０：ゲストＯＳ、２６０：シミュレータ、２６１，２６３：ＲＯＭアクセス情報、２６２：ＲＯＭアクセスモニタ、２７０：マイコンモデル、２７１：ＲＯＭモデル、２７２：バス、３１０，３２０：ＲＯＭのロードファイル、３４０：実行結果ＤＢ

Claims (7)

  1. 　テスト対象であるソフトウェアプログラムが搭載されるマイクロコンピュータを擬似し、前記ソフトウェアプログラムを検証する仮想計算機と、
    　前記ソフトウェアプログラムを検証するための複数のテストシナリオを前記仮想計算機に実行させるテスト実行制御計算機とを有し、
    　前記テスト実行制御計算機は、前記複数のテストシナリオの互いに共通する部分をフェーズとして切り出すように前記テストシナリオをフェーズに分割し、共通するフェーズに続く互いに共通しないフェーズを前記共通するフェーズから枝分かれさせるように前記複数のテストシナリオをツリー化したシナリオ分割情報を記憶しておき、前記シナリオ分割情報のツリー構造に従って、前記共通するフェーズを実行させた後に前記仮想計算機の状態をスナップショットとして保存させるように第１のテストシナリオを前記仮想計算機に実行させ、前記スナップショットにより前記共通するフェーズを実行した状態を再現させた後に前記共通しないフェーズを実行させるように第２のテストシナリオを前記仮想計算機に実行させる、検証装置。
  2. 　前記テスト実行制御計算機は、変更された前記ソフトウェアプログラムの検証を行うとき、変更前ソフトウェアプログラムと変更後ソフトウェアプログラムとで値が一致するアクセス先アドレスを抽出して変更無しアドレス情報として記録し、前記第２のテストシナリオにおける前記共通するフェーズが、当該共通するフェーズにて前記変更前ソフトウェアプログラムを検証したテスト結果が良好であり、かつ、前記テストシナリオの先頭から当該共通するフェーズまでのアクセス先アドレスが前記変更無しアドレス情報に含まれているものであるとき、前記共通するフェーズの実行後の前記仮想計算機の状態を前記スナップショットにより再現させる、請求項１に記載の検証装置。
  3. 　前記テスト実行制御計算機は、前記テストシナリオの各フェーズについてのテスト結果が良好であり、前記シナリオ分割情報のツリー構造において、該フェーズに続くフェーズがあれば、該フェーズを前記仮想計算機に実行させた後の前記仮想計算機の状態をスナップショットとして保存するとともに、前記テストシナリオの先頭から該フェーズまでに前記仮想計算機がアクセスしたアクセス先アドレスを保存しておき、前記ソフトウェアプログラムが変更されたとき、該アクセス先アドレスを前記変更無しアドレス情報を生成するのに利用する、請求項２に記載の検証装置。
  4. 　前記テスト実行制御計算機は、前記スナップショットとして、前記仮想計算機のプロセッサの状態と、前記仮想計算機のメモリの状態と、を、前記仮想計算機に保存させる、請求項１に記載の検証装置。
  5. 　前記仮想計算機のプロセッサの状態は、前記プロセッサのレジスタに格納されているデータであり、
    　前記仮想計算機のメモリの状態は、前記メモリの全領域に格納されているデータである、
    請求項４に記載の検証装置。
  6. 　前記マイクロコンピュータが、自動車に搭載される車載電子制御装置であり、
    　前記仮想計算機は、前記マイクロコンピュータを疑似するモデルと、前記マイクロコンピュータに対して前記自動車を疑似するシミュレータとを実行する、請求項１に記載の検証装置。
  7. 　テスト対象であるソフトウェアプログラムが搭載されるマイクロコンピュータを擬似する仮想計算機にて複数のテストシナリオを実行させることで前記ソフトウェアプログラムを検証する検証方法であって、
    　前記複数のテストシナリオを前記仮想計算機に実行させるテスト実行制御計算機が、前記複数のテストシナリオの互いに共通する部分をフェーズとして切り出すように前記テストシナリオをフェーズに分割し、共通するフェーズに続く互いに共通しないフェーズを前記共通するフェーズから枝分かれさせるように前記複数のテストシナリオをツリー化したシナリオ分割情報を記憶し、
    　前記テスト実行制御計算機が、前記シナリオ分割情報のツリー構造に従って、前記共通するフェーズを実行させた後に前記仮想計算機の状態をスナップショットとして保存させるように第１のテストシナリオを前記仮想計算機に実行させ、
    　前記スナップショットにより前記共通するフェーズを実行した状態を再現させた後に前記共通しないフェーズを実行させるように第２のテストシナリオを前記仮想計算機に実行させる、検証方法。
PCT/JP2020/003316 2019-02-15 2020-01-30 検証装置および検証方法 WO2020166345A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/293,526 US11487649B2 (en) 2019-02-15 2020-01-30 Verification device and method for verifying a program using a tree structure of common and non-common test scenario phases
JP2020572155A JP7084505B2 (ja) 2019-02-15 2020-01-30 検証装置および検証方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2019-025538 2019-02-15
JP2019025538 2019-02-15

Publications (1)

Publication Number Publication Date
WO2020166345A1 true WO2020166345A1 (ja) 2020-08-20

Family

ID=72044940

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/003316 WO2020166345A1 (ja) 2019-02-15 2020-01-30 検証装置および検証方法

Country Status (3)

Country Link
US (1) US11487649B2 (ja)
JP (1) JP7084505B2 (ja)
WO (1) WO2020166345A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000231495A (ja) * 1999-02-10 2000-08-22 Nec Corp 仮想マシン
JP2007018254A (ja) * 2005-07-07 2007-01-25 Toshiba Corp 言語処理装置
JP2013120440A (ja) * 2011-12-06 2013-06-17 Nec Corp テストシステム、テスト方法、及び、プログラム
JP2017059210A (ja) * 2015-09-14 2017-03-23 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、ファームウェア更新方法及び制御プログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010112974A2 (en) * 2009-03-31 2010-10-07 Freescale Semiconductor, Inc. System for tree sequence testing of a device and method for tree sequence testing of a device in a test framework architecture
US11099870B1 (en) * 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
DE102019103445A1 (de) * 2019-02-12 2020-08-13 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Lizenzierung einer Toolkette

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000231495A (ja) * 1999-02-10 2000-08-22 Nec Corp 仮想マシン
JP2007018254A (ja) * 2005-07-07 2007-01-25 Toshiba Corp 言語処理装置
JP2013120440A (ja) * 2011-12-06 2013-06-17 Nec Corp テストシステム、テスト方法、及び、プログラム
JP2017059210A (ja) * 2015-09-14 2017-03-23 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、ファームウェア更新方法及び制御プログラム

Also Published As

Publication number Publication date
US20210406160A1 (en) 2021-12-30
US11487649B2 (en) 2022-11-01
JPWO2020166345A1 (ja) 2021-09-30
JP7084505B2 (ja) 2022-06-14

Similar Documents

Publication Publication Date Title
US11314907B2 (en) Simulation including multiple simulators
US10423571B2 (en) Method for configuring a real or virtual electronic control unit
JP5153465B2 (ja) シミュレーション方法、システム及びプログラム
US8768681B2 (en) Control unit simulation method, system, and program
JP2014203314A (ja) Ｅｃｕシミュレーション装置
US6285914B1 (en) Verification method by means of comparing internal state traces
WO2018003495A1 (ja) Ｅｃｕシミュレーション装置
JP5224957B2 (ja) シミュレーション方法、システム及びプログラム
Mahmood et al. A model-based security testing approach for automotive over-the-air updates
WO2020166345A1 (ja) 検証装置および検証方法
CN111581101A (zh) 软件模型的测试方法、装置、设备和介质
US20220300316A1 (en) Verification system, verification method, and recording medium
Zander-Nowicka et al. Automotive validation functions for on-line test evaluation of hybrid real-time systems
Lauber et al. Virtual test method for complex and variant-rich automotive systems
KR20160077901A (ko) 실시간 시뮬레이션 방법 및 실시간 시뮬레이션 장치
CN114721922A (zh) 一种服务器集群的性能评估方法、计算设备及存储介质
CN113254084A (zh) 一种基于处理器流水线分析的时间和时序校准方法及装置
EP4002096B1 (en) Design support apparatus and design support method
Francois New approaches in virtualization of ECU software development
US20220207438A1 (en) Automatic creation and execution of a test harness for workflows
Erkkinen Fixed-Point ECU Development with Model-Based Design
JP2010055249A (ja) シミュレーション方法、システム及びプログラム
CN117931641A (zh) 测试方法、装置、计算设备及存储介质
Dominka et al. Increasing test efficiency with automated feature-interaction-testing: Feature testing of engine ecu software
Keil et al. Evaluation of SiL Testing Potential—Shifting from HiL by Identifying Compatible Requirements with vECUs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20755669

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020572155

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20755669

Country of ref document: EP

Kind code of ref document: A1