Test apparatus, test method, and test program

Abstract

To automatically test an OS incorporated in equipment or a control board.SOLUTION: An acquisition unit 51 that communicates with a repository via a network and acquires a source code of a target program from the repository, a build unit 52 that builds the target program using the acquired source code, a writing unit 53 that performs a process of writing the built target program to a storage unit of a target board, a reset unit 54 that performs a process of resetting the target board, a communication unit 55 that communicates with the target board, instructs a control unit of the target board to execute an automatic test, and receives a test result of the automatic test from the target board, and a determination unit 56 that performs a process of determining results of various tests executed on the target board based on the received test result.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present invention relates to a test device, a test method, and a test program. [Background technology]

[0002] An operating system (OS) is used to manage and control the overall operation of a computer. Various application software runs on the OS to provide desired functions. An OS acts as a bridge between application software and the hardware that makes up a computer, such as control devices such as a CPU (Central Processing Unit), storage media such as memory, hard disks and SSDs (Solid State Drives), input devices such as a keyboard and mouse, output devices such as a display, and network devices, providing a more convenient execution environment than operating the hardware directly.

[0003] Proprietary operating systems such as Windows (registered trademark) and iOS (registered trademark) are widely used as operating systems for personal computers and smartphones. However, in recent years, particularly in industrial machinery, operating systems built on open source software (OSS) such as Linux (registered trademark) have begun to be used, with the expectation of benefits such as reduced license costs and the elimination of black boxes. The same is true for operating systems that control the effect control devices that execute effects using images and sounds in gaming machines such as pachinko machines. OSS is software whose source code is publicly available. OSS source code is often published in repositories on the Internet. Software developers can build the source code published in the repository to implement and test modules, fix bugs, improve functionality, and add new features. The kernel, which is the core of the OS, as well as other drivers and libraries, are no exception. In public repositories that are made available on the Internet, an unspecified number of developers are involved in improving software, and in private repositories that are set up within a company and not made available on the Internet, many developers are also involved in improving software. Although developing software on a repository with many developers has the benefit of speeding up development, it is desirable to test the software uploaded to the repository before using it. Because the OS provides mechanisms for program loading and process protection, it is generally easy to automatically test the operation of application software that runs on the OS, and various methods are widely used (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2002-157144 A Summary of the Invention [Problem to be solved by the invention]

[0005] For the kernel and drivers that make up the OS, the development speed and quality can be increased by having many developers improve the source code in the repository. However, because the OS has a greater impact on the system than application software, it is necessary to perform more rigorous testing to ensure that the OS operates correctly using the uploaded modules. However, while there is a demand for improving the efficiency of OS development for the control boards of the industrial machinery and gaming machines mentioned above, it has been difficult to create an environment or equipment that allows for automatic OS testing. This is because there is no way to automatically load the OS itself, and the OS cannot be properly tested on a virtual machine, which is different from the actual machine. In one aspect, the present invention aims to enable automatic testing of an OS embedded in a device or a control board. [Means for solving the problem]

[0006] In one aspect, the test device of the present invention is a test device that tests an OS running on a control unit of a target board, and includes an acquisition unit that acquires the source code of the OS as an acquisition target from an external device on a network, a build unit that builds the OS using the acquired source code, a write unit that performs a process of writing the built OS to a memory unit of the target board, a startup unit that performs a process of starting the control unit based on the OS stored in the memory unit, a communication unit that communicates with the target board and receives from the target board the results of the test performed by the control unit based on a test program, and a judgment unit that judges the received results of the test. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to automatically test an OS embedded in a device or a control board. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating an aspect of an automatic test of an OS according to an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram illustrating the functional configuration of a test device and a board to be subjected to an automatic test. [Figure 3] FIG. 1 is a sequence diagram outlining the flow of processing for automatic testing according to the present embodiment. [Figure 4] FIG. 1 is a diagram showing a gaming machine to which a performance control device to be tested is applied. [Figure 5] 1 is a diagram illustrating in detail the configuration of the performance control device to be tested. [Figure 6] FIG. 2 is a diagram illustrating a test function unit included in a test device. [Figure 7] 10 is a flowchart illustrating an acquisition process executed by a test device. [Figure 8] 10 is a flowchart illustrating a test execution process executed by a testing device. [Figure 9] 10 is a flowchart illustrating a test determination process executed by a testing device. [Figure 10] FIG. 10 is a diagram illustrating a test result display screen. DETAILED DESCRIPTION OF THE INVENTION

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described in detail with reference to the accompanying drawings. In the following explanation, automatic testing of an OS incorporated into a device or control board will be explained using an example of a performance control board equipped with a performance control device including a CPU used for performance control of a pachinko game machine, etc. The automatic testing of this embodiment can also be applied to an OS incorporated into and operating in devices other than the performance control device of a gaming machine. In this specification, "automated testing" of an OS refers to a procedure in which a test device connected to the actual device or control board that runs the OS retrieves the source code for the OS and related programs for the actual device from a repository, writes the binary code of the OS etc. built from the source code into the memory unit of the device or control board, and obtains the test results of the OS executed on the OS started up on the device or control board. These steps are automatically repeated by the test equipment, and users of the test equipment can gain insight into available OS builds for real devices and identify any defects that arise, which can be used to improve development, simply by checking the test results collected by the test equipment. The automatic OS test of this embodiment will be described in more detail below.

[0010] FIG. 1 is a diagram for explaining an aspect of an automatic OS test according to this embodiment. As shown in Figure 1, in this embodiment, a test device 10 is connected to a performance control board 20 to be tested, and an automatic test of the OS used in the performance control board 20 is performed. A general-purpose PC (Personal Computer) can be used as the test device 10. Hereinafter, the test device 10 will be referred to as PC 10. 1, the PC 10 can be connected to a repository 30 via a network NW. The repository 30 can be a public repository published on the Internet or a private repository installed on an in-house network. The network NW can be the Internet or a local network within a company. Repository 30 is a data storage location that stores source code for software under development and can be shared among many developers. Many developers download the source code managed in repository 30 into their own environments, build and implement it, and can perform "commits" to make changes to the source code in repository 30, including additions, corrections, and deletions, in order to fix bugs and defects or add features. Repository 30 is also a version control system that manages software version information and change differences between versions.

[0011] Repository 30 stores the source code of the OS (hereinafter simply referred to as "OS") used by performance control board 20 and related programs (test programs, communication programs). The OS includes a kernel, which is the main body of the OS, and drivers and libraries as kernel modules. In the following explanation, each element that makes up the OS, including the kernel, will be referred to as an OS module. The test program is a program for testing the OS on performance control board 20, and the communication program is a program for causing performance control board 20 to communicate with PC 10. In the following description, as an example, an OS is divided into multiple modules, and source code packages for each module are managed in the repository 30. However, the present invention is not limited to this, and a single source code package including software for all OS modules may be managed in the repository 30. The repository 30 includes a repository database (DB) 31 and a repository server 32. The repository DB 31 is a storage or database that stores source code, etc. The repository server 32 receives new or modified source code from devices used by developers, etc., and stores the source code in the repository DB 31. The repository server 32 acts as a front end for external devices such as PC 10 that access the repository 30, and processes requests for information about commits and source code. The repository server 32 can respond to inquiries from PC 10 by sending version information and change differences for programs and OS modules, and can also push a commit notification to PC 10 when a commit has occurred.

[0012] The PC 10 acquires the source code of the OS and related programs (test programs, communication programs) stored in the repository 30 and builds them. The PC 10 connects to the performance control board 20 to be tested and writes the binary code of the built OS and related programs into the ROM of the performance control board 20. The PC 10 runs the OS written in the ROM on the performance control board 20 and executes the test program, thereby testing the OS.

[0013] FIG. 2 is a diagram illustrating the functional configuration of the test device and the board. The performance control board 20 includes a performance control device 21, a ROM (Read Only Memory) 22, a communication interface 23, a USB interface 24, and a power supply unit 25. When the performance control device 21 is used in the performance control board 20 of a gaming machine, the performance control device 21 is a processor that processes video output to the display device provided in the gaming machine, audio output to the speaker, lighting of LEDs, etc. The performance control device 21 is an SoC that integrates a CPU, RAM, and other controllers, as will be explained later in Fig. 5. The CPU provided in the performance control device 21 controls each function of the performance control board 20 based on the functions of Linux (registered trademark) that runs as the OS. The ROM 22 stores various content data such as images, sounds, illuminations, etc. used in the gaming machine. The OS and programs built by the PC 10 are also written to the ROM 22. The power supply unit 25 supplies power to the performance control board 20. Although Fig. 2 shows an example in which the power supply unit 25 is provided on the performance control board 20, the power supply unit 25 may be provided separately from the performance control board 20 as a power supply unit. The ROM 22 can only read data from the performance control device 21, but data can be written from the PC 10 via the USB interface 24. The PC 10 functions as a ROM writer and writes data to the ROM 22 while supplying power to the ROM 22 via the USB connection. An EEPROM (Electrically Erasable Programmable Read Only Memory) or the like can be used as the ROM 22.

[0014] The PC 10 also includes a control unit 11, a storage unit 12, a communication interface 13-1, a communication interface 13-2, a USB interface 14, and a display device 15. The control unit 11 includes a processor 11a such as a CPU and a memory 11b such as a RAM (Random Access Memory), and controls each component of the PC 10 to realize various functions. The storage unit 12 uses a hard disk, flash memory, or SSD. The storage unit 12 stores an OS and a test control program for the PC 10. The storage unit 12 may cache source code downloaded from the repository 30 and pre-built binary code.

[0015] The control unit 11 controls the entire PC 10 by executing an OS for the PC stored in the storage unit 12. The control unit 11 also realizes a test function unit 40 by executing a test control program stored in the storage unit 12. In the control unit 11, the processor 11a uses the memory 11b as a work area for storing programs and temporary data. The processor 11a reads the OS and test control program from the storage unit 12 into the memory 11b and executes them.

[0016] PC 10 connects to network NW using communication interface 13-1 and acquires source code from repository 30. PC 10 connects to performance control device 20 via Ethernet using communication interface 13-2, and issues test execution instructions to performance control device 20 and receives test results. In this case, communication interface 13-2 is directly connected to communication interface 23 via a LAN cable (cross cable). When connecting to performance control device 20 via a router or hub, a single communication interface is sufficient.

[0017] Furthermore, the PC 10 can transmit the binary code of the built OS and related programs to the performance control board 20 using a USB connection in order to write the binary code to the ROM 22 connected to the performance control board 20. Even if the OS has not yet been written to the ROM 22, the OS etc. can be written to the ROM 22 via a USB connection. Regarding communication between the PC 10 and the performance control device 21, redundancy can be provided by an Ethernet connection and a USB connection.

[0018] 3 is a sequence diagram outlining the process of the automatic test of this embodiment. The process shown in FIG. 3 is the process when the automatic test by the PC 10 and the performance control board 20 is completed normally. In step S1, the PC 10 monitors a commit to the repository 30. This may be a request to the repository server 32 to synchronize a software version. In step S2, the PC 10 downloads the committed source code from the repository 30. In step S3, the PC 10 builds the downloaded source code. In step S4, the PC 10 writes the built OS, test program, and communication program into the ROM 22 using a method to be described later. When the writing is completed, in step S5, the PC 10 resets the CPU of the performance control device 21 in a manner to be described later.

[0019] In step S6, the CPU 41 of the performance control device 21 reads and starts a new OS from the ROM 22 upon reset, and after startup, reads and executes a communication program from the ROM 22. The performance control device 21 also reads a test program from the ROM 22. The test program may be read later when an execution instruction for the test program is received from the PC 10. In step S7, PC 10 attempts to communicate with performance control device 21. In step S8, performance control device 21 responds to PC 10. As a result, communication between PC 10 and performance control board 20 is established. Once communication is established, in step S9, PC 10 instructs performance control device 21 to execute a test program (to execute an OS test). In response to the instruction, performance control device 21 reads and executes the test program from ROM 22 in step S10, and executes the OS test. In step S11, performance control device 21 transmits the test results to PC 10.

[0020] FIG. 4 is a diagram showing a gaming machine to which the performance control device to be tested is applied. A gaming machine to which a performance control board 20 equipped with a performance control device 21 can be applied will be outlined. 4, the gaming machine U includes a main control board (main board) 1A, a performance control board (sub-board) 20, a ROM 22, a display device 4, a sound device 5, a lighting device 6, and a drive device 7. The main control board 1A is equipped with a main control device (main CPU) 1. The performance control board 20 is equipped with a performance control device 21, which includes a CPU and functions as a sub-CPU. The gaming machine U is, for example, a pachinko gaming machine in which a game is played using a gaming ball as a gaming medium. Main control board 1A and performance control board 20, performance control board 20 and ROM 22, and performance control board 20, display device 4, sound device 5, lighting device 6, and drive device 7 are all connected so that they can communicate with each other. The test subject of this embodiment is the OS running on CPU 41 of performance control device 21 implemented on performance control board 20, so main control device 1 is not directly related to this embodiment.

[0021] If the gaming machine U is a pachinko gaming machine, when a gaming medium shot into the gaming area by the launching device enters a start winning slot provided in the gaming area, the main control device conducts a lottery using random numbers and determines whether a jackpot has occurred based on the result of this lottery. The main control board 1A outputs a command to the performance control board 20 specifying the time and pattern of symbol change based on the result of the jackpot determination. Alternatively, if no start winning occurs for a certain period of time, the main control board 1A puts the gaming machine U into a customer waiting state (standby state) and inputs a command indicating that the state has been entered into the customer waiting state to the performance control board 20. If a jackpot has been won in the jackpot determination, after the symbol change has finished, the gaming medium enters the opened attacker, and a jackpot is awarded, in which prize balls are paid out. The performance control device 21 executes various performances of the gaming machine U based on commands input from the main control board 1A. The performance control device 21 selects a performance to be executed using performance devices such as the display device 4, sound device 5, lighting device 6, and drive device 7, and controls the execution of the selected performance during the specified variable time or the performance while customers are waiting.

[0022] As will be explained in detail using Figure 5, the performance control device 21 comprises a CPU 41, an interrupt controller 42, a motor controller 43, an LED controller 44, an image controller 45, a sound controller 46, a drawing controller 47, a data transfer controller 48, a ROM controller 49a, an Ethernet controller 49b, a timer T, and a RAM 50, which are connected via a bus 100. The display device 4 is, for example, a display device such as an LCD (Liquid Crystal Display), a PDP (Plasma Display Panel), or an OLED (Organic Light Emitting Diode). The sound device 5 is, for example, a speaker. The lighting device 6 is, for example, a light-emitting device such as an LED (Light Emitting Diode). The driving device 7 is a motor, which drives stage props (not shown).

[0023] The ROM 22 is connected to the performance control device 21 via a ROM controller 49a provided in the performance control device 21. The ROM 22 stores various kinds of effect data used for the effects of the gaming machine U, a boot loader for starting the effect control device, and basic software such as an OS. The effect data includes, for example, image data, sound data, lighting data, and drive data used in game effects, customer waiting effects (standby effects), and effects during a big win. The image data also includes moving image data.

[0024] The performance control device 21 reads data from the ROM 22 based on commands input from the main control board 1A and performs various processes on the read data. The performance control device 21 performs drawing processing on the read image data and outputs the data to the display device 4 to display the image. The performance control device 21 also performs playback processing on the read audio data and outputs the data to the sound device 5 to output the audio. The performance control device 21 also outputs the read lighting data to the lighting device 6 to light the lamp. The performance control device 21 controls and drives the drive device 7 based on the drive data.

[0025] FIG. 5 is a diagram illustrating in detail the configuration of performance control device 21, which is the subject of the test. The performance control device 21 is an SoC (System on Chip) that integrates various controllers and RAM with a CPU 41 as an overall control unit. The performance control device 21 includes the CPU 41, an interrupt controller 42, a motor controller 43, an LED controller 44, an image controller 45, and a sound controller 46, which are connected via a bus 100. The performance control device 21 also includes a drawing controller 47, a data transfer controller 48, a ROM controller 49a, an Ethernet controller 49b, a timer T, and a RAM 50. Note that although the example described here shows the various controllers built into the SoC, they may be provided externally rather than built into the SoC.

[0026] The CPU 41 includes, for example, a plurality of cores. Each core includes a cache memory (LI cache), and the CPU 41 includes a cache memory (L2 cache) that is shared by the cores. The CPU 41 controls the execution of effects in the gaming machine U in response to commands input from the main control device 1. To this end, the CPU 41 controls effect controllers (motor controller 43, LED controller 44, image controller 45, sound controller 46, drawing controller 47), the interrupt controller 42, the data transfer controller 48, the ROM controller 49a, and the Ethernet controller 49b.

[0027] The interrupt controller 42 (when installed in an actual gaming machine) controls command notifications as external interrupts input from the main control device 1 to the CPU 41, and interrupt request signals input to the CPU 41 from the performance controllers 43 to 47, the data transfer controller 48, the ROM controller 49a, the Ethernet controller 49b, and the timer T. The interrupt controller 42, for example, allocates cores of the CPU 41 that control the interrupts. The motor controller 43 controls the motor 7 that operates the performance accessories (movable bodies) of the gaming machine U under the control of the CPU 41. The LED controller 44 controls the light emission of the lighting device 6 mounted on the gaming machine U under the control of the CPU 41.

[0028] The image controller 45, under the control of the CPU 41, controls the display device 4 to display effect images such as symbols (numbers) and character images indicating the results of the lottery drawn by the main control device 1. The effect images are images drawn by a drawing controller 47, which will be described later. The sound controller 46, under the control of the CPU 41, performs control to output effect sounds (BGM and sounds emitted by characters) from the sound device 5 using the sound data stored in the ROM 22. The drawing controller 47 uses the image data stored in the ROM 22 to draw the effect image that the image controller 45 displays on the display device 4.

[0029] The data transfer controller 48 controls the transfer of necessary performance data (audio data, image data, etc.) from the ROM 22 to the RAM 50. The Ethernet controller 49b controls the Ethernet connection. The Ethernet controller 49b controls the performance control board 20 to communicate with the PC 10 directly using the communication interface 23 without going through a local network, or via a local network.

[0030] FIG. 6 is a diagram illustrating the test function unit of the testing device 10. As shown in FIG. The test function unit is realized by the control unit 11 of the PC 10, which is a testing device, executing a test control program stored in the storage unit 12. The test function unit 40 includes an acquisition unit 51 , a build unit 52 , a write unit 53 , a reset unit 54 , a communication unit 55 , a determination unit 56 , and a display unit 57 . The acquisition unit 51 controls the communication interface 13 - 1 to connect the PC 10 to the network NW and performs processing to download the source code from the repository 30 . For example, the acquisition unit 51 automatically and periodically makes an inquiry (synchronization request) to the repository server 32 using a timer or the like provided in the PC 10 as to whether or not there is a commit to the OS, the test program, and the communication program.

[0031] As explained above, the repository server 32, which performs version management, responds to a request to acquire difference information from the acquisition unit 51. The acquisition unit 51 queries the repository server 32 for the latest version information. The repository server 32 acquires the latest version information from the repository DB 31 and transmits it to the PC 10. The PC 10 compares the received version information with the version information it holds, and if there is a difference, the acquisition unit 51 acquires the change differences of the entire source code of the latest version of the program from the repository DB 31 via the repository server 32. Alternatively, the repository server 32 may be configured to send a push notification to the PC 10 when a new version is committed. In this case, the acquisition unit 51 acquires the change differences of the entire source code of the latest version of the program from the repository DB 31 via the repository server 32 in the same procedure as described above. The acquisition unit 51 may re-download the latest set of source code for the OS, test program, and communication program regardless of whether a commit has been made or not. Alternatively, for software whose latest version has already been downloaded (cached) to the storage unit 12, the acquisition unit 51 may use the cached source code.

[0032] The build unit 52 uses a compiler to compile the downloaded source code and build the OS and programs. At this time, the build unit 52 builds only the downloaded source code of the OS, test programs, and communication programs. The OS, test programs, and communication programs may be rebuilt using source code cached in the storage unit 12 of the PC 10 or re-downloaded source code. As for the OS, the entire OS is rebuilt even if only some modules, such as drivers, have changed. The acquisition unit 51 and the build unit 52 may be implemented as independent tools, but may also be configured as part of an integrated development environment (IDE) executed on the PC 10. The IDE has a function of synchronizing the source code of the software under development with the repository 30. The acquisition unit 51 is incorporated into the IDE and runs periodically to acquire the difference in changes or the latest set of source code from the repository 30. When the source code is acquired, the build unit 52 builds the source code.

[0033] The writing unit 53 controls the USB I / F 14 to communicate with the performance control board 20 and writes the binary code of the built OS and program into the ROM 22 of the performance control board 20.

[0034] The reset unit 54 performs a process to reset the performance control board 20. To reset the performance control board 20, the power supply unit 25 of the performance control board 20 may be turned ON after being turned OFF. Therefore, the reset unit 54 also functions as a startup unit. Any method can be used to remotely turn the power supply unit 25 of the performance control board 20 ON / OFF, but for example, a relay device or the like connected to the power supply unit 25 may be connected to the USB port of the PC 10 using a USB cable, or a relay device or the like connected to the power supply unit 25 may be connected to the communication I / F of the PC 10 using an Ethernet cable. The reset unit 54 controls the relay device, which in turn controls the power supply unit 25. A reset may be performed by software control while power is being supplied to the performance control board 20. For example, a special packet or signal containing a command to restart the CPU 41 is input to the performance control device 21 via an Ethernet or USB connection. When resetting by software control, control may also be exercised to reset components necessary for restarting the OS, such as the ROM 22 and the Ethernet controller. The communication unit 55 controls the communication interface 13-2 to attempt communication with the performance control board 20, to instruct the performance control board 20 to execute an automatic test, and to receive the test results from the performance control board 20. The judgment unit 56 performs judgment processing of the results of various tests executed on the performance control board 20 based on the results of communication with the performance control board 20 by the communication unit 55 and the test results received by the communication unit 55. The display unit 57 performs processing to display a screen showing the result of the determination processing by the determination unit 56.

[0035] When power is applied to performance control board 20 with the OS and programs written to ROM 22, CPU 41 built into performance control device 21 starts up with the OS stored in ROM 22 and then remains in an idle state. If the OS is overwritten in ROM 22 of performance control board 20 while it is running, an error may occur in performance control board 20 as a whole. However, since performance control board 20 is in an idle state, there is no problem even if an error occurs. After the OS is overwritten in ROM 22, a reset process is performed and performance control device 21 starts up with the OS written in ROM 22, so there is no problem with the operation of performance control board 20.

[0036] FIG. 7 is a flowchart illustrating the acquisition process executed by the test device 10. In step S101, the PC 10 (acquisition unit 51) starts monitoring the repository 30 for the presence or absence of a commit for a specific program. More specifically, the PC 10 periodically sends an inquiry (synchronization request) to the repository server 32. Alternatively, the PC 10 waits for a notification from the repository server 32 that a commit has occurred. In step S102, the PC 10 (acquisition unit 51) acquires the version information and change difference data from the repository server 32, and if there is no difference with the version information and change difference data held by the PC 10, it determines that there is "no commit" (No in step S102), returns the process to step S101, and continues monitoring the repository 30. Also, when the repository server 32 issues a notification regarding a commit, the PC 10 acquires the version information and change difference data from the repository server 32 in the same manner as above, and checks whether there is a difference with the version information and change difference data held by the PC 10. If it is determined that a commit has occurred on PC10, i.e., if the data such as version information acquired from the repository server 32 does not match the data such as version information held by PC10 (Yes in step S102), PC10 (acquisition unit 51) downloads the source code of the committed program in step S103, returns to the processing of step S101, and continues monitoring the repository.

[0037] FIG. 8 is a flowchart illustrating the test execution process executed by the testing device 10. In step S111, the PC 10 (build unit 52) ​​determines whether or not there is newly downloaded source code. If it is determined that there is newly downloaded source code (Yes in step S111), the PC 10 (build unit 52) ​​compiles the downloaded source code using a compiler in step S112, and builds the OS or related programs (communication program, test program). If it is determined that there is no newly downloaded source code (No in step S111), the PC 10 ends the process.

[0038] In step S113, the PC 10 (writing unit 53) determines whether or not the build unit 52 has successfully built the OS or related programs. If the build is successful (Yes in step S113), the PC 10 (writing unit 53) writes the built OS or related programs to the ROM 22 of the performance control board 20 in step S114. After writing of the program to ROM 22 is completed, in step S115, PC 10 (reset unit 54) resets the power supply to performance control board 20. Alternatively, PC 10 instructs performance control device 21 of performance control board 20 to reset CPU 41. After the reset, and after a predetermined time has elapsed, the PC 10 (communication unit 55) attempts to communicate with the performance control board 20 in step S116. In step S117, the PC 10 (communication unit 55) determines whether communication has been established with the performance control board 20. If it is determined that communication has been established (Yes in step S117), the PC 10 in step S118 sends an instruction to the performance control board 20 to execute an automatic test. After a predetermined time has elapsed, in step S119, PC 10 (communication unit 55) acquires the test results of the automatic test executed by performance control device 21 based on the instruction to execute the automatic test from performance control board 20, and ends the test execution process. The performance control device 21 may start the automatic test without PC 10 instructing the performance control board 20 to execute the automatic test, but in that case, it is desirable to issue an execution instruction because it is unclear when the test results will be sent to PC 10.

[0039] If communication cannot be established in step S117 (No in step S117), PC 10 (communication unit 55) retries communication with performance control board 20 in step S120. In step S121, the PC 10 (communication unit 55) determines whether communication has been established with the performance control board 20. If it is determined that communication has been established (Yes in step S121), the PC 10 instructs the performance control board 20 to execute an automatic test in step S118. If it is determined in step S121 that communication could not be established (No in step S121), the PC 10 determines in step S122 whether the number of retry attempts for communication has reached a predetermined upper limit. If the number of retry attempts has not reached the predetermined number (No in step S122), the PC 10 returns the process to step S120 and retries communication. If it is determined that the number of retry attempts has reached the predetermined number (Yes in step S122), the PC 10 (communication unit 55) determines in step S123 that communication has not been established, and ends the test execution process. If the build has failed (No in step S113), the PC 10 (build unit 52) ​​determines in step S124 that the build has failed, and ends the test execution process.

[0040] The repository monitoring process shown in Fig. 7 and the test execution process shown in Fig. 8 can be performed in parallel. Therefore, depending on the timing of the source code commit and download shown in Fig. 7, it is possible that multiple test execution processes shown in Fig. 8 may be performed in parallel on the PC 10. However, since writing the build results to the performance control board 20 and testing cannot be performed simultaneously, processes other than the test execution process will wait for writing after the build has been completed. Alternatively, after the repository monitoring process in FIG. 7 is performed, the next repository monitoring may be performed after the test execution process in FIG. 8 for the downloaded source code is completed.

[0041] FIG. 9 is a flowchart illustrating the test determination process executed by the testing device. In step S201, the PC 10 (determination unit 56) determines whether or not there was a build failure in the current build. If it is determined that there was a build failure (Yes in step S201), the PC 10 identifies the OS module or program that caused the build failure in step S202 and ends the process.

[0042] If the PC 10 (determination unit 56) determines in step S201 that there is no build failure in the current build (No in step S201), the PC 10 determines in step S203 whether communication with the performance control board 20 has been lost. If it determines that communication has been lost (Yes in step S203), the PC 10 (determination unit 56) identifies a problem with the OS or the communication program in step S204 and ends the process. If communication is not established, it is possible that there is a problem with the built OS, causing it to fail to start, or that there is a problem with the communication program. Whether the cause of communication failure is a defect in either the OS or the communication program can be determined, for example, as follows. That is, if the OS has not been updated since the previous automated test in which communication was successfully established, but only the communication program has been updated, it can be determined that there is a defect in the updated communication program. Conversely, if the communication program has not been updated since the previous automated test in which communication was successfully established, but only the OS has been updated, it can be determined that there is a defect in the updated OS. Furthermore, an OS is composed of modules such as a kernel, drivers, and libraries. Multiple OS modules are developed independently and updated in the repository 30. If it can be determined that there is a problem with the OS, it can also be determined that there is a defect in an OS module that has been updated since the previous test.

[0043] If it is determined that communication has been established normally (No in step S203), the PC 10 (determination unit 56) determines whether or not all test results received from the performance control board 20 are OK. If all test results are OK (Yes in step S205), the PC 10 (determination unit 56) determines in step S206 that there are no problems with all OS modules, and ends the process. If the test results are not all OK (No in step S205), the PC 10 (determining unit 56) identifies the module that had the problem and details of the problem in step S207, and ends the process. The PC 10 (display unit 57) displays on the display device 15 a screen including information on the poorly built OS or program identified in step S202, the defective OS or communication program identified in step S204, and the problematic modules based on the test results identified in step S207.

[0044] The automatic test that the CPU 41 provided in the performance control device 21 of the performance control board 20 executes based on the test program will be described in detail below. The CPU 41 starts the OS stored in the ROM 22, and then executes a communication program stored in the ROM 22 to establish communication with the PC 10. After that, when the CPU 41 receives a test execution command from the PC 10, it executes the test program stored in the ROM 22 to perform an automatic test of the OS.

[0045] Automated testing includes (1) functional testing, (2) integration testing, and (3) non-functional testing. (1) Functional testing includes testing of memory and register access, driver testing, system call testing, program startup and termination testing, and interrupt testing. In the memory and register access test, the test program accesses the memory 50 from the CPU 41 and registers such as the data transfer controller 48 built into the performance control device 21, and tests whether the read values ​​match the expected values. This test verifies whether the means of accessing the memory 50 and registers provided by the OS (kernel) together with the UIO (User space I / O) driver are operating properly. The UIO driver is a driver that allows user programs to access the memory 50 and registers.

[0046] In the driver test, the test program tests the drivers included in the OS. The drivers include, for example, an Ethernet driver, a Universal Asynchronous Receiver Transmitter (UART) driver, a Direct Memory Access (DMA) driver, and the above-mentioned UIO driver. The Ethernet driver is a driver that controls the Ethernet controller 49b, which controls the communication interface 23. The UART driver controls the UART, which is a circuit that communicates with external devices asynchronously using serial signals. The DMA driver is a driver that controls the DMA controller. The DMA controller is the data transfer controller 48 in Figure 5, and controls data transfers directly between memories or between memories and peripheral devices without going through the CPU 41. The test program checks whether the Ethernet driver, UART (Universal Asynchronous Receiver Transmitter) driver, DMA (Direct Memory Access) driver, and UIO driver functions properly.

[0047] In the system call test, the test program calls system calls (open, read, write, etc.) provided by the OS and checks whether they operate properly. In the program start-up and end-up test, the test program checks whether the program start-up and end-up functions that should be guaranteed by the OS work properly. In the interrupt test, the test program generates an interrupt (an interrupt request signal input to the interrupt controller 42) and checks whether the CPU 41 can properly handle the interrupt without dropping it. In other words, it checks whether the interrupt controller 42 is properly configured by the OS.

[0048] (2) The integration test is a test to check whether the libraries provided by the OS are properly integrated with the OS (kernel). The libraries include functions for controlling the performance controllers provided in the performance control device 21, namely, the motor controller 43, the LED controller 44, the image controller 45, the sound controller 46, the drawing controller 47, etc. As an integration test, the test program performs, for example, a drawing test on the drawing controller 47. In the drawing test, the test program performs drawing using the drawing controller 47 through a drawing library. The test program determines whether the contents of the frame buffer match the expected values. Alternatively, the test program transfers the contents of the frame buffer to the PC 10, and the PC 10 (determination unit 56) determines whether the contents of the frame buffer match the expected values. The test program also verifies that the drawing library accesses the memory 50 (frame buffer) and that drawing completion interrupts (drawing completion signal input to the interrupt controller 42) are performed appropriately.

[0049] (3) Non-functional tests include CPU execution time tests and interrupt response time tests. In the non-functional test, the test program executes the program and verifies that the program completes within a specified time. The OS functions configure the CPU 41 cache and memory management unit (MMU), but if these settings are not configured properly, the program execution speed will be affected. Therefore, the test program performs this test as an OS test. In the non-functional test, the test program generates an interrupt (an interrupt request signal input to the interrupt controller 42) and tests whether the user program detects this interrupt within a predetermined time. The OS handles the interrupt and notifies the user program through the UIO driver, and this test checks whether this processing path is implemented properly.

[0050] FIG. 10 is a diagram illustrating the test result display screen. 9, the PC 10 can display a test result display screen on the display device 15. The PC 10 can also transmit the test results to a server device (not shown) and display them as a web page. Alternatively, the PC 10 can have web server functionality and publish the test results as a web page.

[0051] In this embodiment, PC 10 periodically and automatically obtains updated source code for the OS and programs from repository 30. PC 10 builds the obtained source code, writes the OS to ROM 22 of performance control board 20, and has performance control device 21 execute it. PC 10 obtains from performance control board 20 the results of a test of the OS executed by performance control device 21 using a test program, and displays a test result display screen. By checking the test result display screen shown in FIG. 10, the developer of the performance control device 21 can select the optimum build to be adopted for the performance control device 21, particularly for the OS.

[0052] The display in Figure 10 shows a part of the process of continuously retrieving sources, building, and retrieving test results. The display in Figure 10 is just an example. An OS module contains many drivers and libraries, but for the sake of convenience, we will explain it here as two drivers and two libraries. The functions of an OS are not realized by the kernel alone, or by one driver or library alone, but by various modules working together. Therefore, if an error occurs in an automated test, the cause cannot necessarily be traced to a single OS module. If an error that did not occur before upgrading a specific OS module occurs after the upgrade, it can be assumed that that OS module is partly responsible for the error.

[0053] The OS modules indicated by diagonal lines in the test result display screen of Figure 10 can be considered to be modules that have malfunctioned due to version upgrades, rather than being the direct cause of errors in the automated tests. Rather than searching for the cause of a problem, the user can use the test device and test result display screen of this embodiment to identify builds that did not produce build failures or test errors. The version numbers attached to the kernel, drivers, and libraries are for convenience only: drivers and libraries built for a specific kernel version cannot be integrated into other kernel versions and therefore are always built with the kernel.

[0054] The following explains the kernel, drivers, and libraries separately, but you can also obtain and build a single source package that includes all of the kernel, drivers, and libraries from a repository. In that case, the test results for the communications program and the entire OS will be displayed on the test result display screen in Figure 10. For communication programs and test programs, instead of building them from source code obtained from the repository 30, pre-built binaries obtained from the repository 30 or other download sites may be written to the ROM 22.

[0055] (1) For the sake of convenience, build 111, performed at 10:00 on May 1, 2024, is assumed to have all communication programs and OS modules (kernel, drivers, libraries) at version V1. In this build, the build was successful for all programs and modules. The OS modules and communication programs were written to ROM 22. The OS started up normally, the communication programs operated normally, and communication between PC 10 and performance control board 20 was established. The test execution command was successfully input to the performance control device 21, and the OS test using the test program was successfully performed. However, the test results notified from the performance control board 20 indicated that the contents of the frame buffer for library L2 did not match the expected value. Furthermore, the test results notified that the DMA transfer of data from ROM 22 to RAM 50 by the data transfer controller 48 for driver D2 was unsuccessful.

[0056] (2) Build 112, performed on May 1, 2024 at 11:14 PM, was successful because the communication program remained at version V1. The kernel version was upgraded to V2, resulting in a build failure. In this case, it is acceptable to display a message indicating that the kernel build failed. There are no updates to driver D1 and library L1, but driver D2 and library L2 have been upgraded to version V2. These builds were successful, but the kernel build failed. Therefore, the OS module and communication programs will not be written to ROM22. This may be displayed as a failed build (×).

[0057] (3) Build 114, performed on May 2, 2024 at 05:23, had the communication program version V1 unchanged, but the kernel version was increased to V3. This time, the build was successful. There were no updates to driver D1 (V1), driver D2 (V2), library L1 (V1), or library L2 (V2), and the build was successful, just like the previous build. PC 10 writes the OS module and communication program to ROM 22. Communication between PC 10 and performance control board 20 is established, and it is determined that the OS has started up normally and the communication program is operating normally. As a result of the test using the test program, all test items related to driver D1, driver D2, library L1, and library L2 were determined to be normal. However, the test results for the kernel notified from the performance control board 20 indicated that the value read from the register did not match the expected value. In this case, it is possible to display a message indicating that an error occurred in the test and a code that can identify the error.

[0058] (4) Build 115, performed at 11:42 on May 2, 2024, had the communication program version V1 unchanged, the kernel version increased to V4, and the build was successful. There were no updates to Driver D1 (V1), Driver D2 (V2), Library L1 (V1), or Library L2 (V2), and the build was successful, just like the previous build. The OS module and communication program were written to ROM 22. Communication between PC 10 and performance control board 20 was established, the OS started up normally, and it was determined that the communication program was operating normally. As a result of testing using the test program, all test items related to the kernel, Driver D1, Driver D2, Library L1, and Library L2 were determined to be normal. The test and build may be displayed as successful (○).

[0059] (5) Build 116, performed at 16:21 on May 2, 2024, updated the communication program to version V2 and was a successful build. There were no updates to the kernel (V4), driver D1 (V1), driver D2 (V2), library L1 (V1), or library L2 (V2), and the build was successful, just like the previous build. The OS module and communication program were written to ROM 22. However, communication between the PC 10 and the performance control board 20 was not established. In this case, it is possible that the OS is not starting up or running properly, there is a problem with the Ethernet driver, or there is a problem with the communication program. Since Build 115 confirmed that there was no problem with the OS in the current configuration, Build 116 can also determine that there was a problem with the communication program. Conversely, if there have been no updates to the communication program since Build 115, but an update to the Ethernet driver has resulted in communication between the PC 10 and the performance control board 20 no longer being established, it can be determined that there is a problem with the Ethernet driver. Furthermore, if there have been no updates to the communication program since Build 115, but an update to the kernel has prevented communication between the PC 10 and the performance control board 20, it can be determined that the OS has not started up or is not operating properly due to a kernel malfunction.

[0060] (6) Build 130, performed at 02:03 on May 5, 2024, updated the communication program to version V3 and was a successful build. There were no updates to the kernel (V4), driver D2 (V2), or library L2 (V2). Driver D1 and library L1 were updated to version V2, and all builds were successful. The OS module and communication program were written to ROM 22. Communication between PC 10 and performance control board 20 was established, the OS started up normally, and it was determined that the communication program was operating normally. As a result of the test using the test program, all test items related to the kernel, driver D2, library L1, and library L2 were determined to be normal. However, the test results notified from the performance control board 20 indicated that the user program could not access the register for driver D1. It is also possible to display a message indicating that an error occurred in the test and a code that can identify the error.

[0061] (7) Build 131, performed at 10:34 AM on May 5, 2024, had a successful build with the communication program remaining at version V3 and the kernel version remaining at V4. Driver D1 was upgraded to version V3, and there were no updates to driver D2 (V2), library L1 (V2), or library L2 (V2). The build was successful, just like the previous build. The OS module and communication program were written to ROM 22. Communication between PC 10 and performance control board 20 was established, the OS started up normally, and the communication program was determined to be operating normally. Test results using the test program indicated that all test items related to the kernel, driver D1, driver D2, library L1, and library L2 were successful. The test and build may be displayed as successful (○). In the above displays (1) to (7), the time required for each build may be displayed.

[0062] By using the test device 10 configured as described above and the test result display screen displayed by the test device 10, it is possible to automatically test the OS used in industrial machinery, the performance control board 20 of gaming machines, etc., thereby improving development efficiency. This embodiment is not limited to the embodiment described above, and various configurations or embodiments can be adopted within the scope of the gist of this embodiment. [Explanation of symbols]

[0063] 1 main control device, 1A main control board, 4 display device, 5 sound device, 6 lighting device, 7 drive device (motor), 10 test device (PC), 11 control unit, 12 memory unit, 13 communication interface, 14 USB interface, 15 display device, 20 performance control board, 21 performance control device, 22 ROM, 23 communication interface, 24 USB interface, 25 power supply unit, 30 repository, 31 repository DB, 32 repository server, 40 test function unit, 41 CPU, 42 interrupt controller, 43 motor controller, 44 LED controller, 45 image controller, 46 sound controller, 47 drawing controller, 48 data transfer controller, 49a ROM controller, 49b Ethernet controller, 50 memory, 51 acquisition unit, 52 build unit, 53 write unit, 54 reset unit, 55 communication unit, 56 judgment unit, 57 display unit, NW network, 100 bus

Claims

1. A test device for testing an OS running on a control unit of a target board, an acquisition unit that acquires the source code of the OS as an acquisition target from an external device on a network; a build unit that builds the OS using the acquired source code; a writing unit that writes the built OS into a storage unit of the target board; a startup unit that performs processing to start up the control unit based on the OS stored in the storage unit; a communication unit that communicates with the target board and receives from the target board the results of the test performed by the control unit based on the test program; a determination unit that determines the result of the test received by the communication unit; A test device comprising:

2. 2. The test device of claim 1, the acquisition unit acquires the source code to be acquired that has been updated on the external device or the source code required for building. A test device characterized in that:

3. 3. The test device according to claim 1, the acquisition unit acquires, as the acquisition target, a source code of a communication program that runs on the OS; the build unit builds the source code of the communication program, writing the communication program built by the writing unit into the storage unit; the control unit of the target board communicates with the test device by executing the communication program written in the storage unit after the OS is started; A test device characterized in that:

4. 3. The test device according to claim 1, the acquisition unit acquires a source code of a test program for the OS as the acquisition target, the build unit builds the source code of the test program; the writing unit writes the built test program into the storage unit; the control unit of the target board tests the OS by executing the test program written in the storage unit; A test device characterized in that:

5. 3. The test device according to claim 1, a display unit that displays a screen showing the determination result by the determination unit on a display device; A test device characterized in that:

6. 3. The test device according to claim 1, The writing unit writing the built OS into the storage unit via a USB interface provided on the test device and the target board, which are connected by a USB cable; A test device characterized in that:

7. 3. The test device according to claim 1, The startup unit resets the target board by turning off and then on a power supply unit for the target board, or A test device that instructs the control unit to reset.

8. 3. The test device according to claim 1, The OS test is Testing the functions provided by the kernel included in the OS; A test to check the operation of the drivers included in the OS; A test to check the operation of libraries included in the OS; A test device comprising at least one of the above.

9. 4. The test device according to claim 3, A test device characterized in that, when communication with the target board fails, the judgment unit judges that the problem is in the OS or the communication program.

10. 10. The test device of claim 9, The test device is characterized in that the determination unit determines that a defect has occurred in either the OS or the communication program when only one of the OS and the communication program has been updated since the previous test.

11. 4. The test device according to claim 3, When the build of the OS fails, the determining unit identifies the module that failed to be built among the modules that make up the OS.

12. A test method executed by a processor included in a test device, The test device tests an OS running on a control unit of the target board, The processor: Acquire the source code of the OS as an acquisition target from an external device on a network; Build the OS using the acquired source code; Write the built OS to a memory unit of the target board; performing a process of starting up the control unit based on the OS stored in the storage unit; communicating with the target board to instruct the control unit to execute a test of the OS based on a test program, and receiving test results from the target board; determining the received results of the test; A test method characterized by:

13. A test program that causes a processor included in a test device to execute a test method, The test device tests an OS running on a control unit of the target board, The processor: Acquire the source code of the OS as an acquisition target from an external device on a network; Build the OS using the acquired source code; Write the built OS to a memory unit of the target board; performing a process of starting up the control unit based on the OS stored in the storage unit; communicating with the target board to instruct the control unit to execute a test of the OS based on a test program, and receiving test results from the target board; determining the received results of the test; A test program characterized by:

Images