JP2024048916A - Information processing system, information processing method, and computer program - Google Patents

Abstract

[Problem] Testing is performed starting with a task with a higher priority. [Solution] An information processing system that supports the development of software to be executed by an in-vehicle device, comprising a control unit that adds a task provided from a repository storing multiple sources included in the software to a queue in which the task waits for execution of a test, the control unit reads priority information including information about the task from a storage that stores the priority information, calculates the priority of the task based on the priority information, compares the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adds the task to the queue with the execution order of the task with a higher priority. [Selected Figure] Figure 1

Description

The present disclosure relates to an information processing system, an information processing method, and a computer program.

Traditionally, in software development, methods known as Continuous Integration (CI) and Continuous Delivery (CD) are sometimes used. Note that Continuous Deployment (CD) is sometimes used instead of Continuous Delivery. Such development methods aim to prevent large-scale revision events and reduce the cost of revisions by frequently and automatically verifying software under development.

For example, in software development, multiple developers each create source code, and the operation of each source code is checked. However, when multiple source codes are integrated and run as a single piece of software, there is a risk of errors occurring. In this case, it becomes necessary to verify which combination of source codes caused the error one by one, which can result in time-consuming operation tests.

In a development method based on CI/CD, for example, multiple developers each create source code and store it in a repository on the cloud (push to the repository). Then, a source management tool (also called Source Code Management: SCM) such as GitHub (registered trademark) automatically creates tasks based on the source code stored in the repository each time the source code is updated (build tasks). The tasks are automatically tested by a CI/CD tool such as Jenkins (registered trademark).

In this way, by repeating integration in small cycles and frequently checking for integration errors, large-scale rework can be prevented.

Patent document 1 discloses a technique for selecting test cases to be executed based on the importance of the test and the execution time of the test. With the technique of Patent document 1, for example, test cases with low importance are not executed, so that the time required for automatic testing of CI can be reduced.

Patent document 2 discloses a technology that changes the order of execution target information in an automatic execution queue based on priority attributes and the like included in attribute information of a ticket corresponding to source code.

JP 2010-134643 A JP 2021-105866 A

The software executed by devices installed in vehicles such as automobiles (on-board devices) is becoming larger in scale every year, and development methods based on CI/CD are also being adopted for software for on-board devices.

Here, in the case of software for in-vehicle devices, it is necessary to use hardware resources such as development circuit boards and measurement jigs to perform task operation tests. Providing a large number of such hardware resources increases the cost of building a test environment, so the number of hardware resources is limited. For this reason, it is difficult to run many operation tests in parallel for software for in-vehicle devices, and there is a demand to more quickly find software corrections by running tests on tasks with higher priority.

In view of this problem, the present disclosure aims to provide an information processing system, an information processing method, and a computer program that can execute tests starting with tasks with higher priority.

The information processing system disclosed herein is an information processing system that supports the development of software to be executed by an in-vehicle device, and includes a control unit that adds a task provided from a repository storing multiple sources included in the software to a queue in which the task waits for test execution, and the control unit reads priority information including information about the task from a storage device that stores the priority information, calculates the priority of the task based on the priority information, compares the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adds the task to the queue with the task with the higher priority being executed first.

The information processing method disclosed herein is an information processing method for supporting the development of software to be executed by an in-vehicle device, and includes a step of adding a task provided from a repository storing multiple sources included in the software to a queue in which the task awaits execution of a test, the adding step including a first step of reading priority information from a storage storing priority information including information about the task, a second step of calculating the priority of the task based on the priority information, and a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue with the task with the higher priority being executed first.

The computer program disclosed herein is a computer program for supporting the development of software to be executed by an in-vehicle device, the computer program executing a step of adding a task provided from a repository storing multiple sources included in the software to a queue in which the task awaits execution of a test, the adding step including a first step of reading priority information from a storage storing priority information including information about the task, a second step of calculating the priority of the task based on the priority information, and a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue with the task with the higher priority being executed first.

According to this disclosure, testing can be performed starting with the higher priority task.

FIG. 1 is a diagram illustrating an example of an information processing system according to an embodiment. FIG. 2 is a diagram illustrating an example of software according to an embodiment. FIG. 3 is a diagram illustrating an example of an internal configuration of the information processing device according to the embodiment. FIG. 4 is a diagram illustrating an example of a test environment according to the embodiment. FIG. 5 is a table showing an example of version information according to the embodiment. FIG. 6 is a table illustrating an example of execution time information according to the embodiment. FIG. 7 is a table illustrating an example of required time information according to the embodiment. FIG. 8 is a table showing an example of test result information according to the embodiment. FIG. 9 is a table illustrating an example of safety standard information according to the embodiment. FIG. 10 is a table illustrating an example of environmental information according to the embodiment. FIG. 11 is a flowchart illustrating an example of an information processing method according to the embodiment. FIG. 12 is a flowchart showing an information processing method according to a modified example. FIG. 13 is a diagram for explaining the priority of each task according to the modified example. FIG. 14 is a table showing test result information according to a modified example.

[Description of the embodiments of the present disclosure]
The gist of the present disclosure includes the following configurations.

(1) The information processing system disclosed herein is an information processing system that supports the development of software to be executed by an in-vehicle device, and includes a control unit that adds a task provided from a repository storing multiple sources included in the software to a queue in which the task awaits test execution, and the control unit reads priority information including information about the task from a storage device that stores the priority information, calculates the priority of the task based on the priority information, compares the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adds the task to the queue with the task with the higher priority being executed first.

By configuring it like this, you can run tests on higher priority tasks first.

(2) In the information processing system of (1), the in-vehicle device may include an in-vehicle ECU.

Since software development for automotive ECUs tends to be large-scale, it is particularly useful to test higher priority tasks first.

(3) In the information processing system of (1) or (2), the priority information may include information regarding at least one of the test environment, the results of past tests of the task, the time when the past tests of the task were performed, and the time required for the past tests of the task.

Because the priority information includes test environments, etc., it is possible to determine appropriate priorities according to tasks.

(4) In any of the information processing systems described in (1) to (3), the priority information may include information regarding vehicle safety standards required for the task.

Because the priority information includes information regarding vehicle safety standards, it is possible to determine appropriate priorities according to the type of vehicle and the onboard devices installed in the vehicle.

(5) In the information processing system of (3), the tasks may include a first task and a second task whose most recent execution time is earlier than the most recent execution time of the first task. In this case, the control unit may calculate the priority of the second task to be higher than the priority of the first task.

By running tests sooner on tasks that haven't been tested for a while, you can prevent source modifications from becoming too large.

(6) In the information processing system of (3) or (5), the tasks may include a first task and a second task whose required time is shorter than the required time of the first task. In this case, the control unit may calculate the priority of the second task to be higher than the priority of the first task.

By running tests for tasks that can be executed in a short time first, you can run more tests per hour and reduce the number of tasks waiting to be executed.

(7) In the information processing system of (3), (5), or (6), the tasks may include a first task whose most recent result is success and a second task whose most recent result is failure. In this case, the control unit may calculate the priority of the second task to be higher than the priority of the first task.

By running tests on failed tasks first, you can determine more quickly whether the error has been resolved.

(8) In the information processing system of (3), (5), (6), or (7), the test environment may include a test set including a circuit board and a measurement unit that measures the operation of the circuit board, and an execution unit that executes a test of the task by controlling the test set based on the task output from the queue. In this case, the priority information may include environmental information that links the task and the test set used in the test of the task, and the control unit may calculate the priority of the task based on the environmental information.

Both the circuit board and the measurement unit are hardware resources. Providing a large number of test sets that include such hardware resources would be costly to build a test environment, so it is necessary to perform software operation tests using a limited number of test sets. As a result, it is difficult to execute many tasks in parallel when developing software for in-vehicle devices. As a result, it is particularly useful to perform tests on higher priority tasks first in order to more quickly find software corrections.

(9) In the information processing system of (8), the test sets may include a plurality of first test sets and a second test set that is less in number than the plurality of first test sets. In this case, the tasks may include a first task linked to the first test set and a second task linked to the second test set in the environment information, and the control unit may calculate the priority of the second task to be higher than the priority of the first task.

By running tests on the rarer test sets first, the rarer test sets will have less free time.

(10) In the information processing system of (4), the tasks may include a first task and a second task, the safety standard required for which is stricter than the safety standard required for the first task. In this case, the control unit may calculate the priority of the second task to be higher than the priority of the first task.

Tasks with stricter safety standards have a narrower range of allowable values for testing and are more prone to errors. By testing these tasks first, you can find source errors more quickly.

(11) In the information processing system of (10), the safety standard is ISO26262 ASIL (Automotive Safety Integrity Level).

(12) In any of the information processing systems (1) to (11), the control unit may calculate the priority of the tasks already stored in the queue based on the priority information, and rearrange the order of tasks stored in the queue so that a fourth task, which has a higher priority than a third task, among the tasks already stored in the queue, is executed before the third task.

By configuring it in this way, the order in which multiple tasks are already stored in the queue can be reviewed, making it possible to more reliably execute tests on tasks with higher priority first.

(13) In any of the information processing systems (1) to (12), the control unit may divide the task into a plurality of divided tasks based on at least one of the test environment, the safety standard, the result, the execution time, and the required time, calculate priorities of the plurality of divided tasks based on the priority information, and accumulate a second divided task, which has a higher priority than a first divided task, in the queue in the order of execution prior to the first divided task.

This configuration allows you to check the test results in more detail. This makes it easier to narrow down which part of the task is causing the error, allowing you to respond to the error more quickly.

(14) The information processing method disclosed herein is an information processing method for supporting the development of software to be executed by an in-vehicle device, and includes a step of adding a task provided from a repository storing multiple sources included in the software to a queue in which the task awaits execution of a test, the adding step including a first step of reading priority information from a storage storing priority information including information about the task, a second step of calculating the priority of the task based on the priority information, and a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue with the task with the higher priority being executed first.

By configuring it this way, you can run tests on higher priority tasks first.

(15) The computer program of the present disclosure is a computer program for supporting the development of software to be executed by an in-vehicle device, the computer program executing a step of adding a task provided from a repository storing multiple sources included in the software to a queue in which the task awaits execution of a test, the adding step including a first step of reading priority information from a storage storing priority information including information about the task, a second step of calculating the priority of the task based on the priority information, and a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue with the task with the higher priority being executed first.

By configuring it this way, you can run tests on higher priority tasks first.

1. Details of the embodiment of the present disclosure
Hereinafter, the details of the embodiments of the present disclosure will be described with reference to the drawings.

[1.1 Overall configuration of information processing system]
FIG. 1 is a diagram showing an example of the configuration of an information processing system 1 according to an embodiment.
The information processing system 1 is a system that supports the development of software SW1 that is executed in an apparatus mounted on a vehicle such as an automobile (hereinafter, referred to as an "on-vehicle apparatus").

The software SW1 is software used, for example, in an on-board device, such as an on-board ECU (Electronic Control Unit). More specifically, the software SW1 is used in a central ECU or integrated ECU that has the function of managing multiple ECUs. Such software SW1 tends to involve large-scale development, making development support by the information processing system 1 particularly useful.

The information processing system 1 includes an information processing device 10, a repository 20, a test tool 30, a test environment 40, and a storage 50. The information processing system 1 may be realized by a single device (e.g., a server device) concentrated in one location, or may be realized by multiple devices distributed in multiple locations with each unit 10, 20, 30, 40, 50 connected to each other so as to be able to communicate with each other via a network such as the Internet.

1.2 Software and Tasks
Fig. 2 is a diagram showing an example of the software SW1 according to the embodiment. The software SW1 and the task Tx will be described with reference to Fig. 2. As described above, the software SW1 is software executed by the in-vehicle device. The software SW1 includes a plurality of components X1, X2, and X3. The component X1 includes a plurality of modules a1, a2, and a3, and the component X2 includes a plurality of modules b1 and b2.

These components X1, X2, and X3 and modules a1, a2, a3, b1, and b2 are collectively referred to as "sources." In other words, the software SW1 includes multiple sources. These sources may be data written in a specific programming language called source code, or may be data written in binary code after the source code is converted into machine language.

These sources are created individually, for example, on multiple terminals (called terminal group 60) operated by multiple developers (suppliers). In the information processing system 1, operation tests are performed on the source alone, and operation tests in a state where the multiple sources are combined (integrated). Here, the test items performed in the information processing system 1 are called tasks Tx. Tasks Tx are also called "job tasks".

The task Tx includes any one of the following test items (1) to (4).
(1) A test item that verifies whether one module (e.g., module a1) operates independently.
(2) A test item that verifies whether multiple modules (e.g., module a1 and module a2) included in one component operate in a combined state.
(3) A test item that verifies whether one component (e.g., component X1) works, that is, whether all modules included in the component (e.g., modules a1, a2, and a3) work when combined.
(4) A test item that verifies whether multiple components (e.g., component X1 and component X2) operate in a combined state.

1.3 Repository
Please refer to Fig. 1. The repository 20 is a database constructed on a cloud, which is realized by, for example, a mass storage device. The repository 20 is connected to a group of terminals 60 via a network. A developer transmits a plurality of sources created on each of the group of terminals 60 to the repository via the network. The repository 20 stores the received plurality of sources.

The repository 20 is provided with a source code management tool (also called SCM: Source Code Management) such as GitHub. The SCM automatically generates a task Tx based on multiple sources stored in the repository 20. The generated task Tx is provided from the repository 20 to the information processing device 10.

[1.4 Information processing device]
FIG. 3 is a diagram illustrating an example of the internal configuration of the information processing device 10 according to the embodiment.
The information processing device 10 is a device for executing a process of adding a task Tx to a queue 31 managed by a test tool 30. The information processing device 10 has a control unit 11, a storage unit 12, a communication unit 13, and a reading unit 14. Each of these units 11 to 14 is electrically connected to each other via a bus.

The control unit 11 includes a circuit configuration (circuitry) such as a processor. Specifically, the control unit 11 includes one or more central processing units (CPUs). The control unit 11 reads out computer programs stored in the memory unit 12 and executes various calculations and controls.

The control unit 11 may include a processor in which a predetermined program is written in advance. For example, the control unit 11 may be an integrated circuit such as a CPLD (Complex Programmable Logic Device), an FPGA (Field-Programmable Gate Array), or an ASIC (Application Specific Integrated Circuit). In this case, the control unit 11 executes various information processing operations based on the programs written in advance.

The storage unit 12 has a volatile memory and a non-volatile memory, and stores various data. The volatile memory includes, for example, a RAM (Random Access Memory). The non-volatile memory includes, for example, a flash memory, a HDD (Hard Disk Drive), a SSD (Solid State Drive), or a ROM (Read Only Memory). The storage unit 12 stores, for example, computer programs and various parameters in the non-volatile memory.

The communication unit 13 is a communication interface that communicates with the repository 20, the test tool 30, and the storage 50. The communication unit 13 may communicate with each of these units 20, 30, and 50 wirelessly via a network, or may communicate wired via a communication line. When performing wireless communication, the communication unit 13 has an antenna.

The reading unit 14 reads information from a computer-readable recording medium 15. The recording medium 15 is, for example, an optical disk such as a CD or DVD, or a USB flash memory. The reading unit 14 is, for example, an optical drive or a USB terminal. A computer program and various parameters are recorded on the recording medium 15, and by having the reading unit 14 read the recording medium 15, the computer program and various parameters are stored in the non-volatile memory of the storage unit 12.

The task Tx provided from the repository 20 is received by the communication unit 13 and input to the control unit 11 via the bus. Priority information 51 (described below) read from the storage 50 is also received by the communication unit 13 and input to the control unit 11 via the bus. The control unit 11 calculates the priority of the task Tx based on the priority information 51 in accordance with the computer program read from the memory unit 12. Then, the control unit 11 adds the task Tx to a specified position in the queue 31 based on the calculated priority.

1.5 Test Tools
Please refer to Fig. 1. The test tool 30 is a CI/CD tool such as Jenkins or CircleCI (registered trademark), and is realized by a computer device including a processor and a memory. The test tool 30 manages a queue 31 in which a plurality of tasks Tx wait for test execution. Specifically, the test tool 30 automatically outputs the tasks Tx stored in the queue 31 to an execution unit 41 of the test environment 40 in sequence.

Queue 31 is a memory that stores multiple tasks Tx, for example, in a first-in, first-out (FIFO) manner. In the example of FIG. 1, four tasks Tx (referred to as T1, T2, T3, and T4 when distinguishing between them) are stored in queue 31.

In FIG. 1, task T1, task T2, and task T3 are already stored in the queue 31 in that order, and task T4 output from the information processing device 10 (specifically, the control unit 11) is added in the execution order between tasks T1 and T2, not in FIFO order. In this case, the test tool 30 outputs the tasks Tx stored in the queue 31 to the execution unit 41 in the order of tasks T1, T4, T2, and T3.

1.6 Test Environment
1. The test environment 40 includes an execution unit 41 and a test set 42. The execution unit 41 is a computer device (e.g., a laptop PC) including a processor and a memory, and is also called a "node." The execution unit 41 controls the test set 42 based on the task Tx output from the queue 31 to execute the test of the task Tx. The execution unit 41 also collects information such as the results of the test of the task Tx executed in the test set 42 (e.g., the time when the test was executed, the time required for execution, and a history indicating whether the test was successful or failed), and outputs the information to the storage 50.

The test set 42 is a hardware resource that mimics the production environment in which the software SW1 operates. Because the software SW1 is so-called "embedded software" that runs on an in-vehicle device, in order to test its operation, it is necessary to use hardware resources that mimic the production environment, such as the test set 42. Specifically, the test set 42 includes a circuit board 43 and a measurement unit 44.

Circuit board 43 (also called development board) is a board that imitates a circuit board (e.g., a board mounted on an ECU) that is to be incorporated into an in-vehicle device. Circuit board 43 may be the circuit board itself that is to be incorporated into an in-vehicle device, or may be a prototype of the circuit board that is to be incorporated into an in-vehicle device. Measurement unit 44 is a tool that measures the operation of circuit board 43. Measurement unit 44 is, for example, a software tool for communications such as CANoe (registered trademark).

Figure 4 is a diagram showing an example of a test environment 40 according to an embodiment. Figure 4 illustrates an example in which the test environment 40 includes multiple test sets 42. The multiple test sets 42 include multiple (two in Figure 4) first test sets 42a and second test sets 42b. The number of second test sets 42b is smaller than the number of first test sets 42a, and is one in Figure 4. Note that the multiple test sets 42 may include multiple second test sets 42b.

The circuit board 43 and the measurement unit 44 included in the first test set 42a are referred to as the first circuit board 43a and the first measurement unit 44a. The first measurement unit 44a measures the operation of the first circuit board 43a. Similarly, the circuit board 43 and the measurement unit 44 included in the second test set 42b are referred to as the second circuit board 43b and the second measurement unit 44b. The second circuit board 43b is a board that has a different function from the first circuit board 43a. The second measurement unit 44b measures the operation of the second circuit board 43b.

See FIG. 1. Both the circuit board 43 and the measurement unit 44 are hardware resources and have low versatility. For example, the circuit board 43 is not a general-purpose board, but a dedicated board adjusted for an in-vehicle device. In other words, the circuit board 43 and the measurement unit 44 are used exclusively for testing the software SW1, and tend to be expensive. If a large number of such test sets 42 are provided, the construction of the test environment 40 will be costly, so it is necessary to perform operation tests of the software SW1 with a limited number of test sets 42.

As a result, when developing software SW1 for an in-vehicle device, it becomes difficult to execute many tasks Tx in parallel, and it is necessary to execute tests of tasks Tx with higher priority first in order to more quickly find corrections to software SW1.

Therefore, in the information processing system 1, when a task Tx is added to the queue 31, the task Tx is added to a position according to the priority of the task Tx, thereby enabling the test of a task Tx with a high priority to be executed earlier.

1.7 Storage
Refer to FIG. 1. The storage 50 is an auxiliary storage device such as a HDD or SSD. Priority information 51 is stored in the storage 50. The priority information 51 is information for calculating the priority of a task Tx. The priority information 51 includes, for example, version information D1, execution time information D2, required time information D3, test result information D4, safety standard information D5, and environment information D6. Note that, among the information D1 to the information D6, there may be information that is not included in the priority information 51. That is, the priority information 51 only needs to include at least one of the information D1 to the information D6. The priority information 51 may also include information other than the information D1 to the information D6.

FIG. 5 is a table TB1 showing an example of version information D1 according to an embodiment. Version information D1 is information about the version of the source at the time when a test of task Tx is executed. For example, version information D1 is provided from execution unit 41 to storage 50 each time execution unit 41 executes a test of task Tx. Version information D1 is shown as a hash value (i.e., a value uniquely determined for a source) assigned to the source by SCM, for example.

In the example of FIG. 5, the version of module a1 at execution time TM1 (e.g., the date and time when the test was executed) is shown as hash Ha1-1, and the version of module a2 at execution time TM1 is shown as hash H2-1. The version of module a1 at execution time TM2, which is later than execution time TM1 (an execution time closer to the present time), is shown as hash Ha1-2, and the version of module a2 at execution time TM1 is shown as hash H2-1.

That is, at execution time TM2, the version of module a1 is updated from hash Ha1-1 to hash Ha1-2. In the example of FIG. 5, sources other than module a1 are not updated between execution time TM1 and execution time TM2. Therefore, of the multiple sources, module a1 is the most recently updated source. In other words, by looking at the difference in hash values between multiple execution times in version information D1, it is possible to determine which source was most recently updated.

FIG. 6 is a table TB2 showing an example of execution time information D2 according to an embodiment. The execution time information D2 is information linking a task Tx with the execution time (most recent execution time) when a test of the task Tx was last executed. The execution time information D2 is provided from the execution unit 41 to the storage 50, for example, each time the execution unit 41 executes a test of the task Tx. The example of FIG. 6 shows that the integration test of modules a1 and a2 was last executed at execution time TM2, and the integration test of modules a2 and a3 was last executed at execution time TM1. In other words, based on the execution time information D2, it is possible to determine which task Tx was executed most recently and which task Tx has been left for a long time.

FIG. 7 is a table TB3 showing an example of required time information D3 according to the embodiment. Required time information D3 is information linking a task Tx with the time required to execute a test of the task Tx. The required time information D3 is provided from the execution unit 41 to the storage 50, for example, each time the execution unit 41 executes a test of the task Tx. The table TB3 in FIG. 7 stores the required time for each execution time TM1, TM2. For example, it is shown that the integration test of modules a1 and a2 took 1 minute 2 seconds at execution time TM1 and 1 minute 6 seconds at execution time TM2. It is also shown that the integration test of modules a2 and a3 took 2 minutes 30 seconds at execution time TM1 and was not executed at execution time TM2.

The required time information D3 makes it possible to obtain the time required for the most recent test. For example, the most recent integration test of modules a1 and a2 took 1 minute 6 seconds, and the most recent integration test of modules a2 and a3 took 2 minutes 30 seconds. Furthermore, the required time information D3 makes it possible to obtain statistics (e.g., average or median) of the time required for past tests. For example, the average time required for the most recent two integration tests of modules a1 and a2 is 1 minute 4 seconds.

Figure 8 is a table TB4 showing an example of test result information D4 according to an embodiment. Test result information D4 is information linking a task Tx with the test result of the task Tx. The test result includes a test failure (NG) and a test success (OK). Here, a test failure includes, for example, a case where the desired measurement value is not met in the measurement unit 44. Also, a test success includes, for example, a case where all the desired measurement values are met in the measurement unit 44.

Table TB4 in FIG. 8 stores test results for each execution time TM1, TM2. Test result information D4 is provided from the execution unit 41 to the storage 50, for example, each time the execution unit 41 executes a test of task Tx. For example, it is shown that the integration test of modules a1, a2 failed at execution time TM1 and was successful at execution time TM2. It is shown that the integration test of modules a2, a3 was successful at execution time TM1 and was not executed at execution time TM2. It is also shown that the integration test of components X3, X1 failed at both execution times TM1 and TM2.

The test result information D4 makes it possible to obtain the result of the most recent test. For example, the most recent test result of the integration test of modules a1 and a2 is a success, and the most recent test result of the integration test of modules a2 and a3 is a success. In contrast, the most recent test result of the integration test of components X3 and X1 is a failure. Furthermore, the test result information D4 makes it possible to obtain information on how many consecutive test failures have occurred in the past. For example, the most recent integration test of components X3 and X1 has failed twice in a row.

FIG. 9 is a table TB5 showing an example of safety standard information D5 according to the embodiment. The safety standard information D5 is information on the safety standard required for the source at the time when the test of the task Tx is executed. The safety standard information D5 is provided from the execution unit 41 to the storage 50, for example, every time the execution unit 41 executes the test of the task Tx. The safety standard is, for example, a safety standard for vehicles, more specifically, automobiles. The safety standard is, for example, ASIL (Automotive Safety Integrity Level) of ISO26262. In ASIL, multiple stages are set, for example, QM, ASIL-A, ASIL-B, ASIL-C, and ASIL-D, and the required standards become stricter in this order. In other words, the loosest conditions are imposed on QM, and the strictest conditions are imposed on ASIL-D.

In the example of Figure 9, the safety standard of module a1 at execution time TM1 is shown as QM, and the safety standard of module a1 at execution time TM2 is shown as ASIL-A. In other words, it shows that the safety standard of module a1 has become one level higher as a result of the update from execution time TM1 to execution time TM2 (Figure 5).

For sources other than module a1, there is no update from execution time TM1 to execution time TM2, so there is no change in safety standards. For example, the safety standard for modules a2, a3, b1, and b2 is QM, and the safety standard for component X3 is ASIL-D. By looking at the safety standard information at the most recent execution time (execution time TM2 in Figure 9) in safety standard information D5, it is possible to understand the safety standard required at the current time.

FIG. 10 is a table TB6 showing an example of environment information D6 according to an embodiment. The environment information D6 is information linking a task Tx with a test set 42 used in testing the task Tx. The environment information D6 is provided from the execution unit 41 to the storage 50, for example, each time the execution unit 41 executes a test of the task Tx. For example, it is indicated that the integration test of modules a1 and a2 and the integration test of modules a2 and a3 are executed using the first test set 42a, and that the integration test of modules a3 and a1 and the test of component X1 are executed using the second test set 42b. According to the environment information D6, it is possible to obtain the type of test set 42 used in testing the task Tx.

1.8 Information processing method
11 is a flowchart showing an example of an information processing method executed by the information processing system 1. First, a developer creates multiple sources using the terminal group 60, and stores the multiple sources in the repository 20 via the network. The multiple sources are stored in the repository 20 at appropriate times.

The SCM that manages the repository 20 creates a task Tx, for example, periodically (also called polling processing) or when a new source is stored in the repository 20 (also called push processing) (step S11). For example, when a new version of a module a1 is stored in the repository 20 while modules a1, a2, a3, b1, and b2 and component X3 are already stored in the repository 20, the SCM creates a task Tx related to the module a1. For example, the SCM creates a task Tx for executing an integration test of modules a1 and a2, a task Tx for executing an integration test of modules a1 and a3, a task Tx for executing a test of component X1, and a task Tx for executing an integration test including component X1 (for example, an integration test of components X1 and X2).

Then, the created task or tasks Tx are provided from the repository 20 to the information processing device 10. This completes step S11.

The communication unit 13 of the information processing device 10 outputs the task Tx received from the repository 20 to the control unit 11. When the control unit 11 accepts a new input of a task Tx, it reads the priority information 51 from the storage 50 (step S12). For example, the control unit 11 may read all of the information D1 to D6 included in the priority information 51, or may read only a portion of the information D1 to D6 used to calculate the priority of the task Tx. The read priority information 51 is input to the control unit 11 via the communication unit 13. This ends step S12.

The control unit 11 then calculates the priority of the task Tx based on the priority information 51 (step S13). The priority is calculated, for example, by at least one method among the first to fifth calculation examples shown below. The control unit 11 may calculate multiple types of priorities based on multiple pieces of information, from information D1 to information D6, by two or more calculation examples among the first to fifth calculation examples. Examples of priority calculation are described below.

[1.8.1 First Calculation Example: Prioritize neglected tasks]
The control unit 11 reads the execution time information D2 and calculates a higher priority for a task Tx that has been left for a long time (i.e., a task Tx for which a longer time has elapsed since the most recent test was executed). By executing a test sooner for a task Tx that has not been tested for a while, it is possible to prevent the scale of source modification from becoming large.

For example, in the case of FIG. 6, the most recent execution time TM1 of task Tx relating to integration testing of modules a2 and a3 (in this calculation example, an example of the "second task" of the present disclosure, and referred to as task a2-a3 as appropriate) is earlier (older) than the most recent execution time TM2 of task Tx relating to integration testing of modules a1 and a2 (in this calculation example, an example of the "first task" of the present disclosure, and referred to as task a1-a2 as appropriate).

For this reason, the control unit 11 calculates the priority of tasks a2-a3 to be higher than the priority of tasks a1-a2. If a higher numerical value is assigned to task Tx the higher the priority, the control unit 11 assigns, for example, a priority of "2" to tasks a2-a3 and a priority of "1" to tasks a1-a2.

The control unit 11 may calculate the priority according to the values of the execution times TM1 and TM2. For example, the time from the execution times TM1 and TM2 to the current time may be used as the priority value. In this case, since the time from the execution time TM2 to the current time is longer than the time from the execution time TM1 to the current time, a higher value is calculated as the priority of tasks a2-a3.

[1.8.2 Second calculation example: Prioritize tasks that can be executed in a short time]
The control unit 11 reads the required time information D3 and calculates a higher priority for a task Tx that can be tested in a short time. By testing the task Tx that can be tested in a short time first, the number of tests that can be executed per unit time can be increased and the number of tasks waiting to be executed can be reduced.

For example, in the case of FIG. 7, the time required for testing task Tx relating to integration testing of modules a1 and a2 (in this calculation example, an example of the "second task" of the present disclosure, and referred to as task a1-a2 as appropriate) is shorter than the time required for testing task Tx relating to integration testing of modules a2 and a3 (in this calculation example, an example of the "first task" of the present disclosure, and referred to as task a2-a3 as appropriate).

For this reason, the control unit 11 calculates the priority of tasks a1-a2 to be higher than the priority of tasks a2-a3. If a higher numerical value is assigned to task Tx the higher the priority, the control unit 11 assigns, for example, a priority of "2" to tasks a1-a2 and a priority of "1" to tasks a2-a3.

The control unit 11 may calculate the priority according to the required time value. For example, the priority value may be a value obtained by subtracting the required time from a predetermined value E1. Here, the predetermined value E1 is set to a value sufficiently larger than each required time. In this case, since the value (E1-66) obtained by subtracting the most recent required time of tasks a1-a2 (for example, 1 minute 6 seconds = 66 seconds) from the predetermined value E1 is greater than the value (E1-150) obtained by subtracting the most recent required time of tasks a2-a3 (for example, 2 minutes 30 seconds = 150 seconds) from the predetermined value E1, a higher value is calculated as the priority of tasks a1-a2. Note that in calculating the priority, the control unit 11 may use the most recent required time value or a statistical value of the required time (for example, the average value of the required times for the past several times).

[1.8.3 Third calculation example: Prioritize tasks with recent failure history]
The control unit 11 reads the test result information D4 and calculates the priority of the task Tx that has the most recent failure history to be higher. By executing the test on the failed task Tx first, it is possible to check more quickly whether the error has been resolved.

For example, in the case of FIG. 8, the most recent test result of task Tx relating to integration testing of components X1 and X2 (in this calculation example, an example of the "first task" of the present disclosure, and appropriately referred to as task X1-X2) is a success, and the most recent test result of task Tx relating to integration testing of components X3 and X1 (in this calculation example, an example of the "second task" of the present disclosure, and appropriately referred to as task X3-X1) is a failure.

For this reason, the control unit 11 calculates the priority of tasks X3-X1 to be higher than the priority of tasks X1-X2. If a higher numerical value is assigned to task Tx the higher the priority, the control unit 11 assigns, for example, a priority of "2" to tasks X3-X1 and a priority of "1" to tasks X1-X2.

The control unit 11 may calculate the priority according to the most recent number of consecutive failures. For example, the priority may be a value obtained by adding a constant (for example, 1) to the number. In this case, the control unit 11 calculates the priority of tasks X1-X2 as 1 (=0+1) because the most recent number of consecutive failures for tasks X1-X2 is 0 (the most recent test result was a success). Similarly, the control unit 11 calculates the priority of tasks X3-X1 as 3 (=2+1) because the most recent number of consecutive failures for tasks X3-X1 is 2. This allows a higher priority to be calculated for task X3-X1, which has a longer failure history.

[1.8.4 4th calculation example: Prioritize tasks that require stricter safety standards]
The control unit 11 reads out the safety standard information D5 and calculates a higher priority for a task Tx that requires stricter safety standards. Tasks Tx that require stricter safety standards have a narrower range of values that are permitted in tests by the measurement unit 44, for example, and are more likely to cause errors. By executing tests on such tasks Tx first, source errors can be found more quickly.

For example, in the case of Figure 9, for the sources at the most recent execution time, the ASIL-D required for component X3 is the strictest, followed by the ASIL-A required for module a1. The QM required for other sources (e.g. modules a2, a3, etc.) is the lenientest.

Consider a task Tx that combines sources as shown in Figure 8. For example, when performing an integration test of modules a1 and a2, the safety standard required for task a1-a2, which includes modules a1 and a2, is ASIL-A (the safety standard for module a1), which is the strictest among the standards required for the sources included in task a1-a2. Also, when performing an integration test of modules a2 and a3, the safety standard required for task a2-a3, which includes modules a2 and a3, is QM (the safety standard for modules a2 and a3), which is the strictest among the standards required for the sources included in task a2-a3.

As a result of the above, the safety standard required for testing tasks a1-a2 (in this calculation example, an example of the "second task" of the present disclosure) is stricter than the safety standard required for testing tasks a2-a3 (in this calculation example, an example of the "first task" of the present disclosure), so the control unit 11 calculates the priority of tasks a1-a2 to be higher than the priority of tasks a2-a3. If a higher numerical value is assigned to task Tx the higher the priority, the control unit 11 assigns, for example, a priority of "2" to tasks a1-a2 and a priority of "1" to tasks a2-a3.

The control unit 11 may calculate the priority according to the strictness (level) of the safety standard. For example, the control unit 11 may assign a priority of "5" to task Tx, which requires the strictest ASIL-D, and a priority of "4" to ASIL-C, "3" to ASIL-B, "2" to ASIL-A, and "1" to QM.

[1.8.5 5th calculation example: Prioritize tasks that use smaller test sets]
The control unit 11 reads the environment information D6 and calculates a higher priority for the task Tx that uses a test set 42 that is fewer in number in the environment information D6. By executing tests on the rare test set 42 first, it is possible to reduce the free time of the rare test set 42.

For example, consider a case in which the test environment 40 includes two first test sets 42a and one second test set 42b as shown in FIG. 4. In the example of FIG. 10, there are fewer second test sets 42b linked to tasks Tx (in this calculation example, an example of a "second task" in the present disclosure and appropriately referred to as task a3-a1) related to integration testing of modules a3 and a1 than there are first test sets 42a linked to tasks Tx (in this calculation example, an example of a "first task" in the present disclosure and appropriately referred to as task a1-a2) related to integration testing of modules a1 and a2.

For this reason, the control unit 11 calculates the priority of task a3-a1 to be higher than the priority of task a1-a2. If a higher numerical value is assigned to task Tx the higher the priority, the control unit 11 assigns, for example, a priority of "2" to task a3-a1 and a priority of "1" to task a1-a2.

The control unit 11 may calculate the priority according to the number of test sets 42. For example, the priority value may be a value obtained by subtracting the number of test sets 42 from a predetermined value E2. Here, the predetermined value E2 is set to a value that is sufficiently larger than the number of each test set 42. In this case, since the value (E2-1) obtained by subtracting the number of second test sets 42b (1) from the predetermined value E2 is greater than the value (E2-2) obtained by subtracting the number of first test sets 42a (2) from the predetermined value E2, a higher value is calculated as the priority of task a3-a1 linked to the second test set 42b.

1.8.6 Adding a task to a queue
The calculated priority is stored, for example, in the storage unit 12. This ends step S13.

Next, the control unit 11 adds the task Tx to the queue 31 based on the priority (step S14). For example, consider a case where a new task T4 is added to the queue 31 when tasks T1, T2, and T3 are already stored in the queue 31 as shown in FIG. 1.

If the priority of task T4 is lower than that of task T1 but higher than that of task T2, the control unit 11 adds task T4 to the queue 31 after task T1 in the execution order but before task T2 (i.e., between tasks T1 and T2).

For example, when the priority calculation is based on the above "First Calculation Example", the priority of task T1 is "3", the priorities of tasks T2 and T3 are "1", and the priority of the newly added task T4 is "2", the control unit 11 adds task T4 between tasks T1 and T2 as described above. As a result, multiple tasks Tx are accumulated in the queue 31 in descending order of priority, so that the task Tx with the highest priority can be tested first.

In addition, when calculating the priority based on multiple calculation examples, the importance may be preset for each calculation example, and when adding task Tx to queue 31, the priority may be evaluated in descending order of importance from the calculation example with the highest importance.

Here, consider a case where two types of priorities are calculated using the first calculation example and the second calculation example. For example, the importance of the priority calculated using the first calculation example (hereinafter referred to as the first priority) is set higher than the importance of the priority calculated using the second calculation example (hereinafter referred to as the second priority). This setting is set, for example, by an operator who manages the information processing device 10, and is stored in advance in the storage unit 12 as one of the parameters.

In this case, the control unit 11 first compares the first priority between tasks T1, T2, and T3 stored in the queue 31 and the newly added task T4. For example, if the first priority of tasks T1, T2, and T3 is "2" and the first priority of task T4 is also "2," the first priority alone cannot identify an optimal position for adding task T4 to the queue 31.

Then, the control unit 11 next compares the second priority between the tasks T1, T2, and T3 stored in the queue 31 and the newly added task T4. For example, if the second priority of task T1 is "3", the second priorities of tasks T2 and T3 are each "1", and the second priority of the newly added task T4 is "2", the control unit 11 adds task T4 between tasks T1 and T2 as described above.

In this way, by comparing the tasks Tx in order of importance among multiple types of priorities, it is possible to add the task Tx to a more suitable position in the queue 31. Note that if all priorities are the same, the newly added task Tx may be added to the queue in the execution order after the previously stored task Tx, based on the FIFO method.

In addition, when calculating the priority based on multiple calculation examples, a priority "weight" may be preset for each calculation example, and the position for adding task Tx to queue 31 may be determined based on an overall priority calculated by adding up the multiple priorities with each priority assigned a "weight."

For example, consider a case where the weight of the first priority is set to "2" and the weight of the second priority is set to "1." In this case, the overall priority is calculated as "first priority x 2 + second priority x 1." The weight of each priority is set, for example, by an operator who manages the information processing device 10, and is stored in advance in the memory unit 12 as one of the parameters.

This completes step S14. The tasks Tx stored in the queue 31 are output to the execution unit 41 at an appropriate timing by the test tool 30, and the tests are executed. This allows the tests to be executed starting with the task Tx with the higher priority.

2. Modifications
Modifications of the embodiment will be described below. In the modifications, the same components as those in the above embodiment will be denoted by the same reference numerals and the description thereof will be omitted.

[2.1 Variations of the information processing method]
12 is a flowchart showing an information processing method according to a modified example. In the above embodiment, for example, the priority of a task T4 to be newly added to the queue 31 is calculated, and compared with the priorities (already calculated priorities) of the tasks T1, T2, and T3 already stored in the queue 31, thereby determining the position at which the task T4 is to be added.

In contrast, in this modified example, when a new task T4 is added to the queue 31, the priorities of the tasks T1, T2, and T3 already stored in the queue 31 are recalculated. Then, based on the priorities, not only is task T4 simply added to the queue 31, but the order of tasks T1 to T3 in the queue 31 is also reassigned.

As shown in FIG. 12, steps S11 and S12 are executed in the same manner as in the above embodiment. After that, the control unit 11 calculates the priority of task T4 in the same manner as in step S13, and recalculates the priorities of tasks T1, T2, and T3 in the queue 31 (step S15).

Figure 13 is a diagram explaining the priority of each task in the modified example. For example, assume that the priorities of tasks T1, T2, and T3 already stored in queue 31 are "3," "2," and "1," respectively, before task T4 is added. Then, assume that in step S15, the priority of task T4 is calculated to be "3," and the priorities of tasks T1, T2, and T3 are recalculated to be "4," "1," and "2," respectively.

In this case, the control unit 11 rearranges the accumulation order of tasks T1 to T3 in the queue 31 based on their respective priorities after step S15. Specifically, the control unit 11 rearranges the tasks T1, T3, and T2 in order of decreasing priority. Then, the control unit 11 adds task T4 between tasks T1 and T3. As a result, the final accumulation order of tasks in the queue 31 is tasks T1, T4, T3, and T2 in order of earliest test execution.

In this way, not only is task T4 added to a suitable position, but in the above example, the order of tasks T2 and T3 is also swapped. Therefore, each time a task Tx is added to queue 31, the order of the tasks Tx already stored in queue 31 can be reviewed, so that the task Tx with the highest priority can be tested first with greater certainty. This method is particularly suitable when it is desired to move up the order of execution of a task Tx that has been put off for a long time in queue 31 (i.e., left unattended).

Note that if the priorities of all tasks Tx in the queue 31 are recalculated each time a task Tx is added to the queue 31, there is a risk of placing an excessive processing load on the control unit 11. For this reason, the control unit 11 may execute steps S15 and S16, for example, each time a predetermined number of tasks Tx are added to the queue 31, and execute steps S13 and S14 in other cases. In addition, recalculation of the priorities of the tasks Tx in the queue 31 may not be executed during push processing, and recalculation of the priorities of the tasks Tx in the queue 31 may be executed only during polling processing. With this configuration, it is possible to reorder the tasks Tx in the queue 31 while reducing the processing load on the control unit 11.

2.2 Task Variations
The control unit 11 may divide the task Tx into a plurality of divided tasks DTx for each test item, and then calculate the priorities of the plurality of divided tasks DTx. The control unit 11 divides the task Tx into a plurality of divided tasks DTx based on at least one of the test environment used by the task Tx, the safety standard required for the task Tx, the test result of the task Tx, the execution time of the test of the task Tx, and the time required for the test of the task Tx.

As an example, an example will be described in which a task Tx is divided into multiple split tasks DTx based on a safety standard. As shown in FIG. 9, a task Tx (hereinafter referred to as task X3) related to an operational test of a component X3 requires ASIL-D as a safety standard. However, ASIL-D is not required for all test items included in task X3; for example, some of the test items included in task X3 may include items that require QM as a safety standard.

For this reason, when calculating the priority, the control unit 11 divides task X3 into split tasks X3a and X3b, for example for each test item, based on the safety standard. For example, split task X3a includes only test items of task X3 that require QM. Also, split task X3b includes only test items of task X3 that require a safety standard of ASIL-A or higher (ASIL-A, B, C, D).

Figure 14 is a table TB4a showing test result information D4 relating to a modified example. In table TB4a, task X3 is divided into multiple split tasks X3a and X3b. By subdividing test result information D4 for each of the multiple split tasks X3a and X3b, it is possible to check the test results in more detail, for example, that the test of split task X3a was successful and the test of split task X3b was unsuccessful at execution time TM1. This makes it easier to narrow down which part of task X3 has an error, allowing the error to be responded to more quickly.

In step S13, the control unit 11 may calculate the priority of each of the multiple divided tasks TDx. In step S14, the control unit 11 may determine the position of the divided task TDx to be newly added to the queue 31 based on the priority of the multiple divided tasks TDx already stored in the queue 31. This allows tests to be executed in a more detailed manner.

[3. Notes]
This disclosure includes the contents set forth in the following appendices.

[Appendix 1]
An information processing device that supports development of software to be executed in an in-vehicle device,
a control unit that adds a task provided from a repository in which a plurality of sources included in the software are stored to a queue in which the task waits for execution of a test;
The control unit is
reading out priority information including information related to the task from a storage in which the priority information is stored;
Calculating a priority of the task based on the priority information;
comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue in a state where the task with the higher priority is given priority in the execution order;
Information processing device.

[4. Supplementary Notes]
In addition, at least a part of the above-mentioned embodiment and various modified examples may be arbitrarily combined with each other. In addition, the embodiment and modified examples disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present disclosure is indicated by the claims, and it is intended to include all modifications within the meaning and scope equivalent to the claims.

REFERENCE SIGNS LIST 1 Information processing system 10 Information processing device 11 Control unit 12 Memory unit 13 Communication unit 14 Reading unit 15 Recording medium 20 Repository 30 Test tool 31 Queue 40 Test environment 41 Execution unit 42 Test set 42a First test set 42b Second test set 43 Circuit board 43a First circuit board 43b Second circuit board 44 Measurement unit 44a First measurement unit 44b Second measurement unit 50 Storage 51 Priority information 60 Terminal group SW1 Software a1, a2, a3, b1, b2 Module X1, X2, X3 Component Tx, T1, T2, T3, T4 Task DTx Divided task D1 Version information D2 Execution time information D3 Required time information D4 Test result information D5 Safety standard information D6 Environmental information TB1, TB2, TB3, TB4, TB4a, TB5, TB6 Table TM1, TM2 Execution time E1, E2 Predetermined value

Claims (15)

An information processing system that supports development of software to be executed in an in-vehicle device,
a control unit that adds a task provided from a repository in which a plurality of sources included in the software are stored to a queue in which the task waits for execution of a test;
The control unit is
reading out priority information including information related to the task from a storage in which the priority information is stored;
Calculating a priority of the task based on the priority information;
comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue in a state where the task with the higher priority is given priority in the execution order;
Information processing system. The on-board device includes an on-board ECU,
The information processing system according to claim 1 . the priority information includes at least one of information regarding a test environment, a result of a past test of the task, a time point when the past test of the task was performed, and a time required for the past test of the task;
The information processing system according to claim 2 . The priority information includes information regarding a vehicle safety standard required for the task.
The information processing system according to any one of claims 1 to 3. the tasks include a first task and a second task whose most recent execution time is earlier than the most recent execution time of the first task;
the control unit calculates a priority of the second task to be higher than a priority of the first task;
The information processing system according to claim 3 . the tasks include a first task and a second task, the required time of which is shorter than the required time of the first task;
the control unit calculates a priority of the second task to be higher than a priority of the first task;
The information processing system according to claim 3 . the tasks include a first task whose most recent outcome is success and a second task whose most recent outcome is failure;
the control unit calculates a priority of the second task to be higher than a priority of the first task;
The information processing system according to claim 3 . The test environment includes:
a test set including a circuit board and a measurement unit for measuring the operation of the circuit board;
an execution unit that executes a test of the task by controlling the test set based on the task output from the queue;
having
the priority information includes environment information linking the task with the test set used in testing the task;
The control unit calculates a priority of the task based on the environmental information.
The information processing system according to claim 3 . The test sets include a plurality of first test sets and a plurality of second test sets, the number of which is smaller than the number of the first test sets;
the tasks include a first task associated with the first test set and a second task associated with the second test set in the environment information;
the control unit calculates a priority of the second task to be higher than a priority of the first task;
The information processing system according to claim 8. the tasks include a first task and a second task having a safety standard required for the second task that is stricter than the safety standard required for the first task;
the control unit calculates a priority of the second task to be higher than a priority of the first task;
5. The information processing system according to claim 4. The safety standard is ISO26262 ASIL (Automotive Safety Integrity Level),
The information processing system according to claim 10. The control unit is
Calculating the priority of the tasks already stored in the queue based on the priority information;
rearrange the order of accumulation in the queue so that a fourth task, which has a higher priority than the third task, among the tasks already accumulated in the queue, is executed before the third task;
The information processing system according to any one of claims 5 to 9. The control unit is
Dividing the task into a plurality of sub-tasks based on at least one of the test environment, the safety standard, the result, the execution time, and the required time;
Calculating priorities of the divided tasks based on the priority information;
a second divided task having a higher priority than the first divided task is stored in the queue in the order of execution prior to the first divided task, among the plurality of divided tasks;
The information processing system according to any one of claims 5 to 9. An information processing method for supporting development of software to be executed in an in-vehicle device, comprising:
adding a task provided from a repository in which a plurality of sources included in the software are stored to a queue in which the task is to be waited for execution of a test;
The adding step includes:
a first step of reading priority information including information related to the task from a storage in which the priority information is stored;
a second step of calculating a priority of the task based on the priority information;
a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue in a state in which the task with the higher priority is given priority in the execution order;
including,
Information processing methods. A computer program for supporting development of software executed in an in-vehicle device,
The computer program includes:
adding a task provided from a repository in which a plurality of sources included in the software are stored to a queue in which the task is to be tested;
The adding step includes:
a first step of reading priority information including information related to the task from a storage in which the priority information is stored;
a second step of calculating a priority of the task based on the priority information;
a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue in a state in which the task with the higher priority is given priority in the execution order;
including,
Computer program.

Images