WO2025258148A1 - 情報処理装置及びテストケース抽出方法 - Google Patents

情報処理装置及びテストケース抽出方法

Info

Publication number
WO2025258148A1
WO2025258148A1 PCT/JP2025/006762 JP2025006762W WO2025258148A1 WO 2025258148 A1 WO2025258148 A1 WO 2025258148A1 JP 2025006762 W JP2025006762 W JP 2025006762W WO 2025258148 A1 WO2025258148 A1 WO 2025258148A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
measurement conditions
target
requirement
condition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2025/006762
Other languages
English (en)
French (fr)
Inventor
直輝 宇佐美
正貴 橘
友典 田中
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Astemo Ltd
Original Assignee
Astemo Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Astemo Ltd filed Critical Astemo Ltd
Priority to JP2026527897A priority Critical patent/JPWO2025258148A1/ja
Publication of WO2025258148A1 publication Critical patent/WO2025258148A1/ja
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software

Definitions

  • the present invention relates to an information processing device and test case extraction method that extract test cases for testing performance verification based on system requirements specifications.
  • testing is carried out to verify whether the system meets the required specifications in order to ensure system quality.
  • One example of a technology that supports this testing process is one that uses a keyword library that stores test scenario keywords and automatically generates data-based test cases from the keywords, making testing more efficient.
  • the requirements documents describing the required specifications can sometimes contain ambiguity.
  • System tests can be expressed as a combination of the system performance of the system being verified and the measurement conditions under which that performance will be confirmed.
  • system tests it is difficult to identify the system performance and measurement conditions from the requirements documents due to issues with the relevant keywords, etc.
  • one aspect of the present invention aims to enable efficient testing for performance verification based on requirements specifications, even when the requirements text describing the system's requirements contains ambiguity.
  • One aspect of the present invention involves a test case extraction process for testing performance verification based on system requirements specifications.
  • This process involves reading input data including requirement sentences describing the requirements specifications, analyzing the requirement sentences, and identifying the semantic roles of target terms included in the requirement sentences.
  • This process also involves retrieving definitions corresponding to the identified roles for each target term from a dictionary database in which definitions of system-related terms are associated with each role.
  • This process then involves identifying, based on the definitions, the system performance to be verified by the test and the target range of measurement conditions for implementing the test.
  • This process also involves retrieving historical data of tests performed on system performance from a test asset database in which the system performance of previously performed tests and the measurement conditions already implemented in those tests are stored in association with each other.
  • This process also involves extracting measurement conditions to be included in test cases by comparing the implemented measurement conditions included in the historical data with the target range of measurement conditions identified based on the definitions of the target terms included in the requirement sentences.
  • FIG. 1 illustrates an example of a performance verification device.
  • FIG. 10 is a diagram illustrating an example of request sentence data.
  • FIG. 2 is a diagram illustrating an example of a dictionary database.
  • FIG. 10 is a diagram illustrating an example of required condition data.
  • FIG. 10 is a diagram illustrating an example of a test case table in a test asset database.
  • FIG. 10 is a diagram illustrating an example of a test history table of a test asset database.
  • FIG. 10 is a diagram illustrating an example of test condition data.
  • FIG. 10 is a diagram illustrating an example of test result data.
  • 10 is a flowchart illustrating an example of a performance verification process.
  • FIG. 10 is an explanatory diagram showing an example of measurement conditions for a test.
  • FIG. 10 is an explanatory diagram showing an example of measurement conditions for a test.
  • FIG. 10 is an explanatory diagram showing a specific example of data in a request identification process.
  • FIG. 10 is an explanatory diagram showing a target range of measurement conditions for a test and specific examples of historical data in a map format.
  • FIG. 2 is a diagram illustrating a hardware configuration of an information processing device that constitutes a performance verification device.
  • the present embodiment relates to support for the development of various systems in which programs are executed on information processing devices (including microcomputers).
  • development is performed based on a development process that applies a model known as the V-shaped development model, which is based on a process model such as A-SPICE (Automotive Software Process Improvement and Capability dEtermination).
  • V-shaped development model development is performed in the following order from upstream to downstream: (1) requirements definition for the system to be developed, (2) system architecture design, (3) software requirements analysis, (4) software architecture design, and (5) software detailed design. Then, for each of the processes (1) to (5), verification work is performed in the following order from downstream to upstream: (6) software unit verification, (7) software integration testing, (8) software qualification testing, (9) system integration testing, and (10) system qualification testing.
  • the system is dynamic and operated in a variety of usage scenarios, it is important to repeatedly test and verify the software running on that system by changing the system's usage scenario settings.
  • the vehicle's usage scenarios are diverse. For this reason, it is necessary to test and evaluate whether each software control operates normally and achieves the required performance under the measurement conditions of the onboard equipment that correspond to the vehicle's various usage scenarios.
  • examples of measurement conditions include parameters based on the system state, such as motor rotation speed x load conditions, battery voltage conditions, motor temperature conditions, motor control mode (rotation speed-based, torque-based), inverter control mode (modulation method, carrier frequency), and diagnostic status (normal or functional limitations due to fault detection).
  • motor rotation speed x load conditions battery voltage conditions
  • motor temperature conditions motor control mode (rotation speed-based, torque-based), inverter control mode (modulation method, carrier frequency), and diagnostic status (normal or functional limitations due to fault detection).
  • motor control mode rotation speed-based, torque-based
  • inverter control mode modulation method, carrier frequency
  • diagnostic status normal or functional limitations due to fault detection
  • the present embodiment solves the problems that exist in this technical background.
  • the ambiguity of the requirements text is reduced by analyzing the requirements text created in the upstream process of the system development process. Then, in this embodiment, it is possible to clearly identify from the requirements text the system performance and measurement conditions that should be verified by testing in order to satisfy the required specifications. Furthermore, in this embodiment, it is possible to automatically extract the measurement conditions that need to be tested within the target range of the identified system performance and measurement conditions, i.e., the measurement conditions that should be included in the test cases.
  • FIG. 1 is a diagram showing an example of a performance verification device 10 that performs performance verification of a vehicle system according to this embodiment.
  • the performance verification device 10 is an information processing device that includes a processor that executes a program and a storage device that stores data used in executing the program.
  • the performance verification device 10 includes a request identification unit 11, a condition extraction unit 12, and a test execution unit 13, whose functions are realized by a processor loading a program from memory and executing it.
  • the requirement identification unit 11 analyzes the requirement text and identifies the range of system performance and measurement conditions to be verified by testing in order to satisfy the requirement specifications indicated by the requirement text.
  • the requirement identification unit 11 includes a text analysis unit 11A and a definition acquisition unit 11B.
  • the sentence analysis unit 11A reads request sentence data 21 as input data and identifies the semantic roles of phrases (which may include a single word or a phrase combining multiple words) contained in the request sentence in the requirement specifications described in the request sentence.
  • the phrases for which such roles are identified are, for example, nouns or noun phrases, but are not limited to these. In this embodiment, such roles are classified into three roles: "condition,”"observationtarget,” and "expected behavior.”
  • the phrases in the request sentence for which the roles are identified are referred to as target phrases.
  • the definition acquisition unit 11B accesses the dictionary database 22 stored in the non-volatile memory of the storage device of the performance verification device 10 and acquires dictionary information corresponding to each target phrase included in the request sentence.
  • the performance verification device 10 can be implemented on a physical server or on a cloud server via a network; either method is acceptable.
  • the definition acquisition unit 11B then acquires definitions corresponding to the role of each target phrase from the acquired dictionary information. Based on these definitions, the definition acquisition unit 11B identifies the target ranges of system performance and measurement conditions that should be verified by testing in order to satisfy the required specifications indicated in the request sentence.
  • the definition acquisition unit 11B then generates requirement data 23 that includes these target ranges of system performance and measurement conditions.
  • the requirement data 23 is stored in the non-volatile memory of the storage device of the performance verification device 10 or in temporarily used volatile memory.
  • the condition extraction unit 12 extracts measurement conditions for testing to verify that the required specifications are satisfied, based on the system performance and the target range of measurement conditions indicated by the requirement condition data 23 generated by the requirement identification unit 11. In other words, the measurement conditions are measurement conditions to be included in test cases for verifying that the required specifications are satisfied.
  • the condition extraction unit 12 includes a history search unit 12A and a condition matching unit 12B.
  • the history search unit 12A accesses the test case table 24A of the test asset database 24 stored in the nonvolatile memory of the storage device of the performance verification device 10, and searches for and acquires data (records) that match the system performance indicated by the requirement condition data 23. Then, it accesses the test history table 24B associated with that data, and searches for and acquires history data whose measurement conditions fall within the range of the measurement conditions indicated by the requirement condition data 23.
  • the condition matching unit 12B extracts measurement conditions for the test case based on the search results for the history data in the test history table 24B. Specifically, the condition matching unit 12B matches the measurement conditions included in the history data already stored in the test history table 24B (i.e., the measurement conditions that have already been implemented in tests that have already been implemented) with the target range of measurement conditions indicated by the required condition data 23. The condition matching unit 12B then extracts, from the measurement conditions that can be included in the target range of measurement conditions indicated by the required condition data 23, measurement conditions excluding the measurement conditions of the history data already stored in the test history table 24B, as measurement conditions to be included in the test case. These measurement conditions are measurement conditions for which testing has not yet been implemented. The condition matching unit 12B outputs test condition data 25 that includes the system performance indicated by the required condition data 23 and the measurement conditions that have not yet been implemented.
  • the test execution unit 13 obtains data corresponding to the system performance test cases indicated by the test condition data 25 from the test case table 24A.
  • the test execution unit 30 then executes tests under the measurement conditions indicated by the test condition data 25 based on the test scenario (automated test script) associated with this data.
  • the test execution unit 30 then generates a test report including test result data 26 containing the execution results of the tests.
  • the execution results of the tests indicated by the test result data 26 are reflected in the test history table 24B of the test asset database 24.
  • the requirements text data 21 is data in which requirements text included in requirements specifications for system development is stored in a format that can be read by an information processing device.
  • Fig. 2 shows an example of the requirements text data 21.
  • the requirements text data 21 includes multiple requirements texts, it can also include a requirement ID for identifying the requirements text, the requirements text, the chapter to which the requirements text belongs in the requirements specifications, etc., in a format such as CSV (Comma Separated Values).
  • the dictionary database 22 is a database in which definitions (specific semantic content and quantitative information related to the term) are associated with terms related to the system being developed.
  • Figure 3 shows an example of the data structure of the dictionary database 22.
  • the dictionary database 22 associates a definition with each term as dictionary information for each semantic role in the requirements specifications. In this embodiment, these roles are classified into three roles: "condition,” "observation target,” and "expected behavior.” Note that the role classification is not limited to this example and can be set arbitrarily based on the content and characteristics of the system requirements. Furthermore, it is not necessary for all terms to be associated with definitions of all three roles; some terms may be associated with only one of the three definitions.
  • the dictionary information in the dictionary database 22 can be registered arbitrarily throughout the system development process. In particular, by registering dictionary information in the dictionary database 22 during downstream processes in the system development process, more detailed definitions can be assigned to terms.
  • Such a dictionary database 22 can be created in a format such as JSON (JavaScript Object Notation).
  • Requirement data 23 includes the range of system performance and measurement conditions to be verified by testing in order to meet the requirements specified in the requirements document.
  • Figure 4 is an example of requirement data 23.
  • system performance may include target performance, which indicates the performance itself to be verified by testing, the object to be observed in testing, and verification criteria, which serve as the basis for determining whether the results of test execution meet the requirements specifications.
  • the test asset database 24 is a relational database and includes a test case table 24A and a test history table 24B.
  • the test case table 24A is a table that stores data including various information related to test cases. As shown in Fig. 5, the test case table 24A has test history table items that record the test case identifier, the system performance to be tested (target performance, observation target, verification criteria), the automated test script, and the measurement conditions under which tests have already been performed.
  • the data in the test history table items is associated with the test history table 24B, which will be described later. At least for test cases that have already been tested, the definitions in the dictionary database 22 and the system performance in the test case table 24A of the test asset database 24 are synchronized and have a corresponding relationship.
  • Test history table 24B is a table that stores historical data on the measurement conditions under which tests were performed in the test cases indicated by the data in test case table 24A. As shown in Figure 6, test history table 24B has fields for the identifier of the measurement point in the measurement conditions, the measurement parameters, the output value resulting from the test, and the verification result indicating whether the output value meets the verification criteria for the test. In the specific example of test history table 24B shown in Figure 6, there are two types of measurement parameters: torque (motor load) and motor rotation speed. The number of measurement parameter fields can vary depending on the content of the test case.
  • the test condition data 25 is data in which unimplemented measurement conditions are extracted from the target range of the measurement conditions indicated in the required condition data 23.
  • the measurement conditions in the test condition data 25 include a combination of the system performance (target performance, observation target, and verification standard) and the values of the measurement parameters of torque and motor rotation speed as measurement conditions to be included in the test case, as shown in FIG.
  • the test result data 26 is data indicating the results of a test conducted under the measurement conditions included in the test condition data 25.
  • the test result data 26 may include the following content: That is, as illustrated in FIG.
  • the test result data 26 includes an electricity consumption accuracy output value (%) resulting from a test conducted for a combination of measurement parameter values of torque and motor rotation speed, in association with the measurement conditions in the test result data 26, and a verification result (Passed or Failed) based on the output value.
  • FIG. 9 is a flowchart showing the performance verification process executed by the performance verification device 10 in this embodiment.
  • step 1001 denoted as S1001 in the figure, and the same applies hereinafter
  • the sentence analysis unit 11A of the request identification unit 11 reads the request sentence data 21 from the storage device. Then, the sentence analysis unit 11A performs sentence analysis processing on the request sentence included in the request sentence data 21.
  • the text analysis process includes, for example, the following three processes.
  • (1) Morphological Analysis The sentence analysis unit 11A divides the request sentence into morphemes, which are the smallest units that have meaning in a language, and performs morphological analysis to determine the part of speech and inflections of each morpheme.
  • Existing technologies can be used for the morphological analysis. For example, analysis tools such as MeCab and JUMAN are provided, and an existing corpus can also be used as a dictionary to be used in the analysis process.
  • the sentence analysis unit 11A performs syntactic analysis (dependency analysis) to analyze the relationships between each word in the request sentence based on the results of the morphological analysis.
  • syntactic analysis dependsency analysis
  • Existing technology can be used for the syntactic analysis, and for example, a tool based on a machine learning algorithm can be used.
  • a tool based on a machine learning algorithm can be used.
  • one such tool is SyntaxNet, which is a recurrent neural network (RNN) model built using TensorFlow and is specialized for natural language understanding (NLU).
  • the sentence analysis unit 11A identifies the role of a target phrase in a request sentence (whether it is a "condition,”"object of observation,” or “expected action") based on the results of the morphological analysis and syntactic analysis.
  • the role classification at this time is to be consistent with the role classification that can be set in the dictionary information of the dictionary database 22.
  • Such role analysis processing can be realized, for example, by deep learning based on a machine learning algorithm. As a specific example of an existing technology that realizes such deep learning, a neural network framework written in Python or the like can be used.
  • training data can be prepared that classifies the roles of words used in requirement sentences into "condition,” "observation target,” and "expected behavior.” Learning processing can then be performed using this training data to generate a learning model.
  • the input layer for deep learning can include, for example, the target phrase itself, the grammatical structure of the requirement sentence, the chapter to which the requirement sentence belongs in the requirements specification, and keywords contained in the requirement sentence.
  • Information indicating the grammatical structure of the requirement sentence is, for example, information indicating the types of words before and after the target phrase. As a specific example, this information can be used to analyze whether the role of the target phrase is likely to be "condition” if a phrase such as "in” or "when” is present immediately after the target phrase.
  • the output layer can be information indicating the role of the aforementioned phrase, i.e., "condition,” "observation target,” or "expected behavior.”
  • the training data and learning model data used in this deep learning are also stored in the storage device of the performance verification device 10.
  • the definition acquisition unit 11B accesses the dictionary database 22 and searches for and acquires dictionary information corresponding to each of the target phrases included in the request sentence.
  • the dictionary information extracted from the dictionary database 22 includes definitions corresponding to all or part of the roles of the target phrases in the request sentence, i.e., "condition,” "object of observation,” and "expected action.” Note that if dictionary information corresponding to the target phrase does not exist in the dictionary database 22, the dictionary database 22 may be searched using synonyms of the target phrase. Then, for each of the target phrases included in the request sentence, for which dictionary information has been extracted from the dictionary database 22, the definition acquisition unit 11B acquires a definition from the dictionary information corresponding to the role of the target phrase identified by the sentence analysis unit 11A.
  • the definition acquisition unit 11B identifies definitions that correspond to the target range of the system performance (target performance, observation target, verification criterion) and measurement conditions of the test from the definitions of target words and phrases included in the request sentence, and generates the request condition data 23.
  • the "observation target” may be the target performance or observation target of the system performance to be tested
  • the "expected behavior” may be the verification criterion
  • the "condition” may be the target range of the measurement conditions.
  • the history search unit 12A of the condition extraction unit 12 accesses the test case table 24A, searches for data corresponding to the system performance of the requirement condition data 23, and acquires the data.
  • the data includes information indicating a correspondence with the test history table 24B in which the measurement conditions under which the test corresponding to the system performance of the requirement condition data 23 was performed are recorded.
  • step 1005 the history search unit 12A searches the test history table 24B associated with the acquired data, and acquires information on measurement conditions that have already been tested and are included in the target range of the measurement conditions in the required condition data 23.
  • step 1006 the condition matching unit 12B determines whether a test for a measurement condition included in the target range of the measurement conditions in the requirement condition data 23 has not been performed. Specifically, the condition matching unit 12B matches the measurement conditions included in the history data already stored in the test history table 24B with the target range of the measurement conditions indicated by the requirement condition data 23.
  • condition matching unit 12B determines that a test has not been performed if there is a measurement condition that can be included in the target range of the measurement conditions indicated by the requirement condition data 23 and whose history data is not stored in the test history table 24B. If the test has not been performed, proceed to step 1006 (Yes); if not, end the process.
  • the condition matching unit 12B extracts measurement conditions to be performed this time within the target range of the measurement conditions in the requirement condition data 23 for a test corresponding to the system performance of the requirement condition data 23. For example, when performing a test by changing the value of a measurement parameter by a predetermined number, the condition matching unit 12B performs the following process. That is, from among the measurement parameters that vary by the predetermined number within the target range of the measurement conditions in the requirement condition data 23, the condition matching unit 12B extracts those that do not exist in the measurement conditions of the history data in the test history table 24B.
  • the condition matching unit 12B extracts, as measurement conditions to be included in the test case, measurement conditions other than those already stored as history data in the test history table 24B.
  • the condition matching unit 12B then generates test condition data 25 that includes the measurement conditions to be performed this time. Note that in this embodiment, the processing of steps 1001 to 1007 of the performance verification process up to this point is referred to as the test case extraction process.
  • the test execution unit 13 obtains data corresponding to the system performance included in the test condition data 25 from the test case table 24A.
  • the data includes information indicating the automatic test script.
  • the test execution unit 13 generates a test scenario by modifying the automatic test script so as to execute tests for unexecuted measurement conditions included in the test condition data 25, and executes the test.
  • the test execution unit 13 compares the output values obtained as a result of the test execution with the verification criteria, and verifies whether the execution results satisfy the verification criteria.
  • the test execution unit 13 generates test result data 26 that includes the measurement conditions under which the test was executed, the output values of the test execution results under the measurement conditions, and the verification results.
  • the test execution unit 13 updates the test history table 24B with the measurement conditions under which the test was performed, the output values of the test execution results under those measurement conditions, and the verification results, all of which are included in the test result data 26. Specifically, the test execution unit 13 registers data including the measurement conditions, the output values of the test execution results, and the verification results in the test history table 24B.
  • the system requirements are to improve the electric fuel economy of a hybrid vehicle with an inverter-driven permanent magnet synchronous motor (PMSM).
  • PMSM permanent magnet synchronous motor
  • the requirement is to verify the accuracy of the calculation of electric fuel economy when driving uphill at high speeds and high loads.
  • the reason for this requirement is that when driving a hybrid vehicle on a highway with many uphill lanes, the motor's energy efficiency is high, making it desirable to actively utilize the motor.
  • this is also a region where the gradient of motor efficiency changes is high, requiring high estimation accuracy.
  • FIG. 10 illustrates the "high-speed driving x hill-climbing" requirement. Under these driving conditions, it is desirable to accurately determine whether torque derating is necessary to address motor overheating issues and to appropriately determine the optimal balance between motor and engine drive. Therefore, performance verification under various measurement conditions that meet these driving conditions is essential during the vehicle development process.
  • FIG. 11 shows a specific example of processing by the sentence analysis unit 11A and the definition acquisition unit 11B when the request sentence data 21 is a sentence such as, "I would like to confirm whether the accuracy of the calculation of the electric consumption when traveling uphill and at high RPM and high load is sufficient.”
  • the request sentence can be divided into, for example, "I would like to confirm whether the accuracy of the electricity consumption calculation when the vehicle is traveling uphill and the engine is running at high speed and high load is sufficient.”
  • the part “when the vehicle is traveling uphill and the engine is running at high speed and high load” can be analyzed as a modifier (M) because of the inclusion of the word "when.”
  • the part “the accuracy of the electricity consumption calculation” can be analyzed as a subject (S) based on word order, part of speech, etc.
  • the part “sufficient” can be analyzed as a complement (C) based on word order, part of speech, etc.
  • the role of each phrase is further identified. For example, “The vehicle is traveling uphill, with high engine speeds and a high load” can be identified as having a “condition” role in the request sentence because it is included in the modifier and contains the phrase "when.” "Electricity consumption calculation accuracy” can be identified as having a "target of observation” role in the request sentence because it is included in the subject. "Sufficient” can be identified as having a “desired behavior” role in the request sentence because it is a complement and included in the predicate.
  • the definition acquisition unit 11B searches the dictionary database 22 using each term as a key to extract dictionary information.
  • the definition acquisition unit 11B can also refer to a database (not shown) that stores synonyms, convert the term contained in the request sentence into another term with a similar meaning, and search the dictionary database 22.
  • dictionary information is extracted from the dictionary database 22 shown in Figure 3 for each of the terms “hill climbing conditions,” “high rotation and high load,” and “electricity consumption calculation accuracy,” which are converted from “driving on an uphill road.”
  • Each dictionary information includes the roles of the terms “condition,” “observation target,” and “expected behavior,” as well as definitions associated with each of these roles.
  • the definition of the role “condition” is extracted: “torque: 300 to 400 Nm, rotation speed: 2000 to 8000 rpm.”
  • the definition of the role “condition” -- “torque: 200 to 400 Nm, rotation speed: 6000 to 10000 rpm” -- is extracted.
  • the phrase “electricity consumption calculation accuracy” first, “Signal A” -- the definition of the role “observation target” -- is extracted.
  • the phrase extracted as having the role "expected operation” is "sufficient,” a phrase that indicates sufficiency of performance.
  • the definition acquisition unit 11B acquires the definition of the role "expected operation” set in the dictionary database 22 for the phrase “electricity consumption calculation accuracy,” whose role is “observation target.” In other words, the definition acquisition unit 11B extracts the definition of the role “expected operation” of the phrase “electricity consumption calculation accuracy,” which is "when torque is 0 to 100 Nm: ⁇ 2%, when torque is 100 to 400 Nm: ⁇ 3%.”
  • the definition acquisition unit 11B then generates requirement data 23 including definitions extracted from the dictionary database 22 for each of these terms.
  • FIG. 4 shows an example of the requirement data 23 generated based on the definitions acquired from the dictionary database 22 shown in FIG. 3.
  • the definition acquisition unit 11B sets the target performance, among the system performances in the requirement data 23, to the term "electricity consumption calculation accuracy" itself, which has been identified as having the role "observation target.”
  • the definition acquisition unit 11B also sets the observation target to "Signal A,” which is the definition of the role "observation target” for the term “electricity consumption calculation accuracy.”
  • the definition acquisition unit 11B sets the verification standard to "when the torque is 0 to 100 Nm: ⁇ 2%, when the torque is 100 to 400 Nm: ⁇ 3%,” which is the definition of the role "expected operation” for the term “electricity consumption calculation accuracy.”
  • the definition acquisition unit 11B sets the target range of the measurement conditions in the required condition data 23 as follows.
  • the definition acquisition unit 11B identifies a condition (AND condition) that satisfies both the definition of the phrase “hill climbing condition” whose role is identified as “condition” and the definition of the phrase “high rotation, high load.”
  • the definition acquisition unit 11B sets "torque: 300 to 400 Nm, rotation speed: 6000 to 8000 rpm" as the target range of the measurement conditions in the required condition data 23.
  • the history search unit 12A of the condition extraction unit 12 searches the test case table 24A of the test asset database 24 based on the requirement condition data 23.
  • the history search unit 12A obtains information from the test history table 24B associated with that data.
  • the history search unit 12A obtains from the test history table 24B measurement conditions that have already been tested, within the target range of measurement conditions indicated in the requirement condition data 23.
  • Figure 12 shows the data in the test history table 24B, which registers the history of tests verifying the system performance of the example requirement data 23 described above, in map format, with two measurement conditions, torque and engine speed, as axes.
  • the vertical axis represents engine speed
  • the horizontal axis represents torque.
  • the engine speed on the vertical axis assumes a test conducted by varying the engine speed from 0 to 2000 rpm, and then in increments of 2000 rpm thereafter, with rows generated for every 2000 rpm.
  • the torque on the horizontal axis assumes a test conducted by varying the torque from 0 to 100 Nm, and then in increments of 100 Nm thereafter, with columns generated for every 100 Nm.
  • the target range of measurement conditions identified from the requirement text in the requirement text data 21 is as follows: That is, the target range of measurement conditions for "hill climbing conditions” is “torque: 300-400 Nm, rotation speed: 2000-8000 rpm,” and the target range of measurement conditions for "high rotation, high load” is “torque: 200-400 Nm, rotation speed: 6000-10000 rpm.” Furthermore, the target range of measurement conditions that meets both of these is “torque: 300-400 Nm, rotation speed: 6000-8000 rpm,” as indicated in the required condition data 23.
  • the target range of the measurement condition "torque: 300-400 Nm, rotation speed: 6000-8000 rpm” includes the following measurement conditions, as shown in the shaded area in Figure 12.
  • the target range of this measurement condition includes four measurement conditions: “torque: 300 Nm, rotation speed: 6000 rpm,” “torque: 300 Nm, rotation speed: 8000 rpm,” “torque: 400 Nm, rotation speed: 6000 rpm,” and “torque: 400 Nm, rotation speed: 8000 rpm.”
  • the condition matching unit 12B extracts the other three measurement conditions as unexecuted measurement conditions, i.e., as measurement conditions to be included in the test case, as illustrated in Figure 7.
  • Test condition data 25 is then generated that includes these measurement conditions.
  • the test execution unit 13 searches the test case table 24A to obtain data corresponding to the system performance of the test condition data 25, and identifies the automatic test script indicated by that data.
  • the test execution unit 13 then generates a test scenario in which the automatic test script is modified to execute tests for measurement conditions included in the test condition data 25 that have not yet been implemented, and executes the test.
  • the test execution unit 13 then generates test result data 26, as shown in FIG. 8.
  • the measurement conditions and test results included in the test result data 26 are reflected in the test history table 24B.
  • test cases from ambiguous requirements text to verify performance that meets the requirements specifications. Furthermore, not only can such test cases be automatically generated, but test cases can also be generated that take into account measurement conditions that have already been verified at the current stage. This significantly reduces the workload associated with generating test cases for performance verification based on the requirements specifications of a system, thereby improving the efficiency of system development.
  • the semantic roles of target phrases included in a request sentence are identified in the request sentence, and definitions corresponding to the identified roles for each target phrase are obtained from the dictionary database 22, in which definitions of system-related phrases are associated with each role.
  • definitions corresponding to the roles of each phrase in this manner provides the following advantages. That is, even for the same phrase, the meaning (target) indicated by the phrase may differ depending on, for example, the context of each request sentence. Therefore, simply referencing a unique definition for a phrase does not necessarily mean that the definition is accurate for each request sentence.
  • definitions corresponding to roles are associated with phrases in the dictionary database 22.
  • the measurement conditions included in the target range of the measurement conditions identified based on the requirement sentence, excluding the measurement conditions included in the history data stored in the test history table 24B, are extracted as the measurement conditions to be tested. This makes it possible to automatically generate test cases that target only the measurement conditions that have not yet been implemented, significantly reducing the effort required to identify such measurement conditions.
  • the measurement conditions include multiple parameters, such as the torque and engine speed described above, the measurement conditions under which the test is performed are extracted from the measurement conditions under which all of the multiple parameters are included in the target range. In this way, even if the pattern of measurement conditions under which the test is performed is complex, it is possible to accurately extract the measurement conditions necessary for performance verification of the required specifications.
  • condition extraction unit 12 may further extract the measurement conditions of the history data as measurement conditions to be included in the test case. This makes it possible to retest not only measurement conditions that have not been tested, but also measurement conditions that did not satisfy the verification criteria in previous tests, thereby enabling further performance verification.
  • condition extraction unit 12 may process the situation as if there is no measurement condition to be tested if there is one or more pieces of history data in the test history table 24B where the measurement condition is included in the target range of the measurement conditions in the required condition data 23.
  • the performance verification device 10 is equipped with all of the request identification unit 11, condition extraction unit 12, and test execution unit 13.
  • this configuration is merely an example, and these components may be implemented in different information processing devices.
  • the request identification unit 11 and condition extraction unit 12 may be implemented in one information processing device, and the test execution unit 13 may be implemented in another information processing device.
  • the dictionary database 22 and test asset database 24 are provided, but these do not necessarily have to be included in the same information processing device.
  • this data may be stored in a storage device provided by a server on the cloud. The same applies to other data.
  • the test asset database 24 stores the test case table 24A and the test history table 24B as a relational database, but the data can also be stored in other formats.
  • the data can be stored as a two-dimensional array, a JSON file, or the like.
  • the present embodiment has been described using a vehicle system as an example, the present invention can also be applied to performance verification of various systems other than vehicles.
  • [Hardware configuration] 12 shows an example of the hardware configuration of an information processing device that constitutes the performance verification device 10 in the above embodiment.
  • This information processing device includes a processor 910, a memory 920, a storage 930, a portable storage medium drive device 940, an input/output device 950, and a communication interface 960.
  • the processor 910 includes a control unit, an arithmetic unit, an instruction decoder, etc., and the execution unit executes arithmetic and logic operations using the arithmetic unit in accordance with program instructions decoded by the instruction decoder and control signals output from the control unit.
  • the processor 910 also includes a control register that stores various information used for control, a cache that can temporarily store the contents of previously accessed memory 920, etc.
  • the processor 910 may also be configured with multiple CPU (Central Processing Unit) cores.
  • CPU Central Processing Unit
  • Memory 920 is a storage device such as RAM (Random Access Memory), and is the main memory into which programs executed by processor 910 are loaded and into which data used in processor 910 processing is stored.
  • Storage 930 is a storage device such as an HDD (Hard Disk Drive) or flash memory, and stores programs and various data.
  • Portable storage medium drive 940 is a device that reads data and programs stored in portable storage medium 970.
  • Portable storage medium 970 is, for example, a magnetic disk, optical disk, magneto-optical disk, or flash memory.
  • Processor 910 executes programs stored in storage 930 or portable storage medium 970 while cooperating with memory 920 and storage 930.
  • the programs executed by processor 910 and the data to be accessed may be stored in another device capable of communicating with the information processing device. It is also possible to store a program that causes the information processing device to execute the above-mentioned test case extraction process in portable storage medium 970.
  • the input/output device 950 is an input and output means such as a touch panel, keyboard, display, etc., and accepts operational commands from user operations, etc., while outputting the results of processing by the information processing device.
  • the communication interface 960 enables data communication with the outside.
  • the components of the information processing device described above are connected by a bus 980.
  • 10 ...Performance verification device, 11...Requirement identification unit, 11A...Text analysis unit, 11B...Definition acquisition unit, 12...Condition extraction unit, 12A...History search unit, 12B...Condition matching unit, 13...Test execution unit, 21...Requirement text data, 22...Dictionary database, 23...Requirement condition data, 24...Test asset database, 24A...Test case table, 24B...Test history table, 25...Test condition data, 26...Test result data

Landscapes

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

Abstract

開発対象のシステムに対する要求仕様に基づく性能検証のためのテストを行うテストケースを抽出する処理は、要求仕様が記述された要求文章の文章解析を行い、要求文章に含まれる対象語句の意味上の役割を識別する。また、本処理は、辞書データベースから、対象語句の役割に応じた定義を取得し、当該定義に基づいて、検証するシステム性能及び計測条件の対象範囲を識別する。さらに本処理は、すでに実施されたテストのシステム性能及び計測条件が対応付けられたテスト資産データベースから、テストの履歴データを取得する。そして本処理は、当該履歴データに含まれる実施済み計測条件と、識別された計測条件の対象範囲とを照合して、テストケースに含める計測条件を抽出する。これにより、システムの要求仕様が記述された要求文章に曖昧さが含まれている場合でも、要求仕様に基づく性能検証のためのテストを効率的に実現できる。

Description

情報処理装置及びテストケース抽出方法
　本発明は、システムに対する要求仕様に基づく性能検証のためのテストを行うテストケースを抽出する情報処理装置及びテストケース抽出方法に関する。
　ソフトウェアプログラムが処理される各種システムの開発工程においては、システムの品質を担保するべく、当該システムが要求仕様を満たしているかを検証するためのテストが行われる。かかるテスト作業を支援する技術の一例として、テストシナリオのキーワードが蓄積されたキーワードライブラリを用い、キーワードからデータ形式のテストケースを自動生成することでテストを効率化する技術が提案されている。
特開２０２２－１２６０９４号公報
　ここで、上記のようなシステムの開発工程のうち特に上流工程においては、要求仕様が記述された要求文章が曖昧さを含むことがある。このとき、同じ対象をさしていても要求文章とシステム上で管理するキーワードの間で表現が異なり直接的に結びつかない場合が生じる。システムテストは、システム検証対象のシステム性能と、当該性能をどのような条件で確認するかを表す計測条件の組み合わせで表現可能である。今、既存のテストから要求文章に則したシステムテストを自動選択する場合、係るキーワードの問題等により、要求文章からシステム性能と計測条件とを特定することが難しかった。
　そこで、本発明の一側面においては、システムの要求仕様が記述された要求文章に曖昧さが含まれている場合においても、要求仕様に基づく性能検証のためのテストを効率的に実現できるようにすることを目的とする。
　本発明の一側面においては、システムに対する要求仕様に基づく性能検証のためのテストを行うテストケース抽出処理を行う。本処理は、要求仕様が記述された要求文章を含む入力データを読み出して、要求文章の文章解析を行い、要求文章に含まれる対象語句の当該要求文章における意味上の役割を識別することを含む。また、本処理は、システムに関連する語句の定義が役割ごとに対応付けられた辞書データベースから、対象語句のそれぞれについて識別された役割に応じた定義を取得することを含む。そして、本処理は、当該定義に基づいて、テストによって検証するシステム性能及び当該テストを実施する計測条件の対象範囲を識別することを含む。さらに、本処理は、すでに実施されたテストのシステム性能及び当該テストにおける実施済み計測条件が対応付けられて格納されたテスト資産データベースから、システム性能について実施されたテストの履歴データを取得することを含む。また、本処理は、当該履歴データに含まれる実施済み計測条件と、要求文章に含まれる対象語句の定義に基づいて識別された計測条件の対象範囲とを照合して、テストケースに含める計測条件を抽出することを含む。
　本発明の一側面によれば、システムの要求仕様が記述された要求文章に曖昧さが含まれている場合においても、要求仕様に基づく性能検証のためのテストを効率的に実現できるようにすることができる。
性能検証装置の一例を示す図である。 要求文章データの一例を示す図である。 辞書データベースの一例を示す図である。 要求条件データの一例を示す図である。 テスト資産データベースのテストケーステーブルの一例を示す図である。 テスト資産データベースのテスト履歴テーブルの一例を示す図である。 テスト条件データの一例を示す図である。 テスト結果データの一例を示す図である。 性能検証処理の一例を示すフローチャートである。 テストの計測条件の一例を示す説明図である。 要求識別処理のデータ具体例を示す説明図である。 テストの計測条件の対象範囲及び履歴データのデータ具体例をマップ形式で示す説明図である。 性能検証装置を構成する情報処理装置のハードウェア構成を示す図である。
　以下、添付された図面を参照し、本発明を実施するための実施形態について詳述する。
［本実施形態が適用される技術領域］
　まず、本実施形態に関する理解を容易にするべく、本実施形態が適用される技術領域（背景）の一例について説明する。本実施形態は、情報処理装置（マイクロコンピュータを含む）においてプログラムが実行される各種システムの開発支援に関連するものである。一例として、車両システムの開発においては、Ａ－ＳＰＩＣＥ（Automotive Software Process Improvement and Capability dEtermination）等のプロセスモデルに基づき、Ｖ字開発モデルと呼ばれるモデルを適用した開発工程に基づいた開発を行う。当該Ｖ字開発モデルにおいては、上流工程から下流工程の順、すなわち、（１）開発対象のシステムに対する要求（要件）定義、（２）システムアーキテクチャの設計、（３）ソフトウェア要件分析、（４）ソフトウェアアーキテクチャの設計、（５）ソフトウェア詳細設計、の順で開発を行う。そして、（１）～（５）の各工程について、下流工程から上流工程の順に、（６）ソフトウェア単体検証、（７）ソフトウェア統合テスト、（８）ソフトウェア適格性確認テスト、（９）システム統合テスト、（１０）システム適格性確認テスト、の検証作業を行う。
　ここで、前述のような開発工程において、例えば上流工程である（１）では、システムに対する要求仕様（要件）が記述されている要求仕様書を分析し、要求を満たすためシステムが備えるべき要件を、システム要件として定義する。このような要求仕様書等に含まれる、要求仕様が記述された要求文章は、例えば（５）のソフトウェア詳細設計の工程等において作成される詳細設計書等に比べると、より抽象的で曖昧であることが多い。したがって、（１）の工程において、要求分析はアナリスト等の技量に依存する部分が大きい。そして、（１）の工程が正しく行われたかについて検証する（１０）の工程においてシステムの適格性を確認する際、テストケースと要求との対応関係は、途中の要件定義を介するため直接にはつながらない。したがって、要求の文言が曖昧であるほどテストとの対応関係もまた明確でなくなる。要求の文言自体に追加および変更があった場合にどのようなシステム性能をどのような条件で検証するべきなのかがわからない。通常、V字の各工程を経ることで、システム要件が定義され、それに則したソフトウェアの開発と検証を経て、システム挙動を見るため、かかる曖昧さが検証を実施不可能にすることはないが、システムの改修を実施する前に、要求の変更に際し、現行システムの性能を評価したい場面においては、どの過去テストを実施すべきかが、特定できない問題が生じていた。
　また、システムが様々な利用シーンで運用される動的システムである場合、当該システムで動作するソフトウェアを、システムの利用シーンの設定を変えて繰り返しテストして検証することが重要である。例えば、車両に搭載されたシステムの場合、車両の利用シーンは多岐にわたる。このため、車両の様々な利用シーンに応じた車載機器の計測条件下において、各ソフトウェア制御が正常に動作し、要求される性能が実現できているかをテストして評価する必要がある。例えば、モータを動力とする電動車両システムの性能検証の場合、計測条件の例として、モータ回転数×負荷条件、バッテリ電圧条件、モータ温度条件、モータ制御モード（回転数ベース、トルクベース）、インバータ制御モード（変調方式、キャリア周波数）、診断状況（通常又は故障検知による機能制限の発生）などのシステム状態によるパラメータがある。これ加えて、雨天や凍結による路面スリップ、凹凸路での路面負荷の急変動など特殊な事象を組み合わせれば、利用シーンに基づく計測条件は無数である。
　加えて、これらの条件のうち、モータ回転数×負荷条件をとっても、当該2要素をベクトルとして張る平面空間を、最大最小回転数、最大最小負荷で限定した閉空間内に対し、どのような稠密さで計測点を取るかも問われる。無限に細かく計測点を取ることはできないため、100rpm単位、10Nメートル単位など一定の粒度で区切った格子点ごとに計測を行うこととなる。そして、これらの格子点の取り方は目的に応じて可変に取るのがシステム検証の常套手法である。つまり、トルク精度のようなシステム性能に大きく影響する検証について高い密度にする必要がある。したがって、システム検証では、検証対象のシステム性能に応じて、多岐にわたる計測条件を、格子点の密度を変えて計測することになり複雑なデータ構造を持つ。
　ところで、上記システムにおいて、特定の利用シーン（運転状況）でのみ発生する不具合が生じた場合を考える。システム検証としては、不具合の再現テストを試みることになるが、その前に、システム不具合の発生した利用シーンを計測条件としたテストが過去に実施されていたかを即座に把握することが重要となる。
　通常、不具合は、自然言語で報告されるため、何の性能が、どの計測上条件で誤作動しているのかを分析するには、システムのアーキテクチャを把握したエンジニアの分析を待つ必要がある。不具合の発生時に、自動的に、過去の計測データがあるかを判別し、必要なら自動実行する仕組みが期待されるが、これまでその方法はなかった。
　あるいは、システムに対して、特定の条件での性能の改善を試みたい要求が生じたとき、所望の条件で所望の性能に関する過去のテストデータがあるか調べたい場合、自然言語で記述した要求の時点では、関連する過去のテストデータの有無を自動的に判別し、実施していなければ自動的に実施する仕組みもなかった。
　以下に説明する本実施形態は、このような技術的背景における課題を解決するものである。まず、システムの開発工程における上流工程において作成される要求文章についての解析を行うことにより、要求文章の曖昧さを低減させる。そして、本実施形態では、要求文章から、要求仕様を満たすためにテストによって検証するべきシステム性能及び計測条件を明確に識別できるようにする。さらに、本実施形態では、識別されたシステム性能及び計測条件の対象範囲において、テストを実施する必要のある計測条件、即ち、テストケースに含めるべき計測条件を自動で抽出できるようにする。
［システム構成］
　図１は、本実施形態における、車両システムの性能検証を行う性能検証装置１０の一例を示す図である。性能検証装置１０は、情報処理装置であり、プログラムを実行するプロセッサ及びプログラムの実行に用いるデータが格納される記憶装置を備える。
　性能検証装置１０は、プロセッサがプログラムをメモリからロードして実行することによってその機能が実現される、要求識別部１１、条件抽出部１２及びテスト実行部１３を備える。
　要求識別部１１は、要求文章の解析を行い、要求文章が示す要求仕様を満たすためにテストによって検証するべきシステム性能及び計測条件の対象範囲を特定する。要求識別部１１は、文章解析部１１Ａ及び定義取得部１１Ｂを備える。
　文章解析部１１Ａは、入力データとして要求文章データ２１を読み出し、要求文章に含まれる語句（１つの語、又は複数の語を結合した句を含み得る）について、当該要求文章に記述された要求仕様における意味上の役割を識別する。このような役割を識別する対象となる語句は、例えば名詞又は名詞句等であるが、これに限定されるものではない。本実施形態では、このような役割を、「条件」、「観測対象」及び「期待動作」の３つの役割に分類している。なお、以下の説明では、要求文章において当該役割を識別する対象となる語句を対象語句という。
　定義取得部１１Ｂは、性能検証装置１０の記憶装置の不揮発性メモリに格納された辞書データベース２２にアクセスし、要求文章に含まれるそれぞれの対象語句に対応する辞書情報を取得する。なお、当該性能検証装置１０の実装としては物理サーバで実現することも、ネットワークを介したクラウドサーバ上に構築することも可能であり、その別を問わないものである。そして、定義取得部１１Ｂは、取得された辞書情報から、それぞれの対象語句の役割に応じた定義を取得する。さらに、定義取得部１１Ｂは、当該定義に基づいて、要求文章が示す要求仕様を満たすためにテストによって検証するべきシステム性能及び計測条件の対象範囲を識別する。そして、定義取得部１１Ｂは、これらのシステム性能及び計測条件の対象範囲を含んだ要求条件データ２３を生成する。当該要求条件データ２３は、性能検証装置１０の記憶装置の不揮発性メモリ又は一時的に用いられる揮発性メモリに格納される。
　条件抽出部１２は、要求識別部１１によって生成された要求条件データ２３が示すシステム性能及び計測条件の対象範囲に基づき、要求仕様を満たすことを検証するためにテストを実施するべき計測条件を抽出する。換言すれば、当該計測条件は、要求仕様を満たすことを検証するためのテストケースに含めるべき計測条件である。条件抽出部１２は、履歴検索部１２Ａ及び条件照合部１２Ｂを備える。
　履歴検索部１２Ａは、性能検証装置１０の記憶装置の不揮発性メモリに格納されたテスト資産データベース２４のテストケーステーブル２４Ａにアクセスし、要求条件データ２３が示すシステム性能に合致するデータ（レコード）を検索して取得する。そして、当該データによって関連付けられたテスト履歴テーブル２４Ｂにアクセスし、計測条件が要求条件データ２３の示す計測条件の範囲に含まれる履歴データを検索して取得する。
　条件照合部１２Ｂは、テスト履歴テーブル２４Ｂにおける履歴データの検索結果に基づいて、テストケースにおける計測条件を抽出する。具体的には、条件照合部１２Ｂは、テスト履歴テーブル２４Ｂにすでに格納されている履歴データに含まれる計測条件（即ち、すでに実施されたテストにおける実施済み計測条件）と、要求条件データ２３が示す計測条件の対象範囲とを照合する。そして、条件照合部１２Ｂは、要求条件データ２３が示す計測条件の対象範囲に含まれ得る計測条件のうち、テスト履歴テーブル２４Ｂにすでに格納されている履歴データの計測条件を除いた計測条件を、テストケースに含める計測条件として抽出する。当該計測条件は、即ち、テストが未実施の計測条件である。条件照合部１２Ｂは、要求条件データ２３が示すシステム性能及び当該未実施の計測条件を含んだテスト条件データ２５を出力する。
　テスト実行部１３は、テスト条件データ２５が示すシステム性能のテストケースに対応するデータをテストケーステーブル２４Ａから取得する。そして、テスト実行部３０は、当該データによって対応付けられているテストシナリオ（自動テスト用スクリプト）に基づき、テスト条件データ２５が示す計測条件におけるテストを実行する。そして、テスト実行部３０は、当該テストの実行結果を含んだテスト結果データ２６を含んだテストレポートを生成する。テスト結果データ２６が示すテストの実行結果は、テスト資産データベース２４のテスト履歴テーブル２４Ｂに反映される。
　次に、上記の要求識別部１１、条件抽出部１２及びテスト実行部１３が用いるデータについて説明する。
　要求文章データ２１は、システム開発における要求仕様書に含まれる要求文章が、情報処理装置によって読み取ることが可能なフォーマットで格納されたデータである。図２は、要求文章データ２１の一例を示している。なお、要求文章データ２１は、複数の要求文章を含む場合、例えばＣＳＶ（Comma Separated Values）形式等で、要求文章を識別するための要求ＩＤ、要求文章、要求仕様書の中で要求文章が属するチャプター（章節）等を含むことも可能である。
　辞書データベース２２は、開発対象のシステムに関連する語句について、その定義（当該語句に関する具体的な意味内容や定量的な情報）が対応付けられているデータベースである。図３は、辞書データベース２２のデータ構造の一例を示す。図３に示すように、辞書データベース２２では、辞書情報として、それぞれの語句に対し、要求仕様における意味上の役割ごとに、定義が対応付けられている。本実施形態では、このような役割が、「条件」、「観測対象」及び「期待動作」の３つの役割に分類されている。なお、役割の分類はこのような例に限定されるものではなく、システムにおける要求文章の内容や特性によって任意に設定することが可能である。また、全ての語句についてこれらの３つの役割全ての定義が対応付けられている必要はなく、語句によっては３つのうちのいずれかの定義のみ対応付けられていてもよい。当該辞書データベース２２の辞書情報は、システム開発工程の全てにおいて任意に登録することが可能である。特に、システム開発工程の下流工程において当該辞書データベース２２に辞書情報を登録することにより、語句に対し、より詳細な定義付けを行うことが可能である。このような辞書データベース２２は、例えば、ＪＳＯＮ（JavaScript Object Notation）等のフォーマットで作成することが可能である。
　要求条件データ２３は、要求文章が示す要求仕様を満たすためにテストによって検証するべきシステム性能及び計測条件の対象範囲を含んだデータである。図４は、要求条件データ２３の一例である。システム性能は、詳細には、テストによって検証する対象となる性能自体を示す対象性能、テストにおける観測対象、テストの実行結果が要求仕様を満たしているか否かを判定する基準となる検証基準を含み得る。
　テスト資産データベース２４は、リレーショナルデータベースであり、テストケーステーブル２４Ａ及びテスト履歴テーブル２４Ｂを備える。
　テストケーステーブル２４Ａは、テストケースに関する各種情報を含んだデータが格納されるテーブルである。テストケーステーブル２４Ａは、図５に例示するように、テストケースの識別子、テスト対象となるシステム性能（対象性能、観測対象、検証基準）、自動テスト用スクリプト及びすでにテストが実施された計測条件が記録されるテスト履歴テーブルの項目を有する。当該テスト履歴テーブルの項目のデータは、後述するテスト履歴テーブル２４Ｂに対応付けられている。
　なお、少なくとも、すでにテストが実施されたテストケースについては、辞書データベース２２の定義と、テスト資産データベース２４のテストケーステーブル２４Ａのシステム性能とが同期しており、対応関係を有している。
　テスト履歴テーブル２４Ｂは、テストケーステーブル２４Ａのデータが示すテストケースにおいてテストが実施された計測条件の履歴データが格納されるテーブルである。テスト履歴テーブル２４Ｂは、図６に例示するように、計測条件における計測点の識別子、計測パラメータ、テストを実施した結果の出力値及び当該出力値がテストの検証基準を満たしているか否かを示す検証結果の項目を有する。図６に示すテスト履歴テーブル２４Ｂの具体例では、計測パラメータがトルク（モータ負荷）及びモータ回転数の２種類である。この計測パラメータの項目数は、テストケースの内容に応じて変動し得る。
　テスト条件データ２５は、要求条件データ２３で示される計測条件の対象範囲のうち未実施の計測条件が抽出されたデータである。テスト条件データ２５の計測条件は、例えば、システム性能が電費計算精度の場合、図７に例示するように、システム性能（対象性能、観測対象、検証基準）と、テストケースに含める計測条件として、トルク及びモータ回転数の計測パラメータの値の組合せを含む。
　テスト結果データ２６は、テスト条件データ２５に含まれる計測条件におけるテストが実施された結果を示すデータである。例えば、テスト結果データ２６は、前述の図７に例示したテスト条件データ２５に基づいてテストが実行された場合、次のような内容を含み得る。即ち、テスト結果データ２６には、図８に例示するように、テスト結果データ２６の計測条件と対応付けて、トルク及びモータ回転数の計測パラメータの値の組合せにおけるテストを実施した結果の電費精度出力値（％）及び当該出力値に基づく検証結果（Passed又はFailed）が追加される。
［性能検証処理］
　図９は、本実施形態における性能検証装置１０において実行される性能検証処理を示すフローチャートである。
　ステップ１００１（図ではＳ１００１と表記する。以下同様）で、要求識別部１１の文章解析部１１Ａは、記憶装置から要求文章データ２１を読み出す。そして、文章解析部１１Ａは、要求文章データ２１に含まれる要求文章について、文章解析処理を行う。
　ここで、文章解析処理には、例えば、次の３つの処理が含まれる。
　（１）形態素解析
　文章解析部１１Ａは、要求文章について、言語上で意味を持つ最小単位である形態素に分割し、それぞれの形態素の品詞や語形変化を判別する形態素解析を行う。形態素解析には既存技術を用いることができ、具体例としてはMeCabやJUMAN等の解析ツールが提供されているほか、解析処理に用いる辞書として既存のコーパス等を利用することが可能である。
　（２）構文解析
　次に、文章解析部１１Ａは、形態素解析の結果に基づき、要求文章に含まれるそれぞれの語句の関係性について解析する構文解析（係り受け解析）を行う。構文解析には既存技術を用いることができ、例えば、機械学習のアルゴリズムに基づくツールを利用することが可能である。このようなツールとして、例えば、TensorFlowを利用して構築された再帰型ニューラルネットワーク（ＲＮＮ（Recurrent Neural Network））モデルであり、自然言語理解（ＮＬＵ（Natural Language Understanding））に特化したSyntaxNet等がある。
　（３）語句の役割解析（意味解析）
　文章解析部１１Ａは、形態素解析及び構文解析の結果に基づき、要求文章に含まれる対象語句について、要求文章中における役割（「条件」、「観測対象」、「期待動作」のいずれであるか）を識別する。このときの役割の分類は、辞書データベース２２の辞書情報において設定され得る役割の分類と一致させるものとする。このような役割の解析処理は、例えば、機械学習のアルゴリズムに基づくディープラーニングによって実現することができる。このようなディープラーニングを実現する既存技術の具体例として、Python等で記述されたニューラルネットワークのフレームワークを用いることができる。
　ディープラーニングによる処理の一例として、要求文章において用いられる語の役割を「条件」、「観測対象」、「期待動作」に分類した教師データを用意し、当該教師データを用いて学習処理を行い、学習モデルを生成することが可能である。また、ディープラーニングの入力層としては、例えば、対象の語句自体、要求文章の文法構造、要求仕様書の中で要求文章が属するチャプター、要求文章に含まれるキーワード等を含めることができる。要求文章の文法構造を示す情報は、例えば、対象の語句の前後の語がどのような語であるかを示す情報である。具体例としては、当該情報は、対象の語句の直後に「において」や「ときの」等の語句があれば、役割が「条件」である可能性が高い、といった解析に用いることができる。また、出力層は、前述した語句の役割、すなわち、「条件」、「観測対象」及び「期待動作」のいずれかを示す情報とすることができる。なお、図１では図示を省略しているが、当該ディープラーニングに用いる教師データや学習モデルのデータも性能検証装置１０の記憶装置に格納されている。
　ステップ１００２で、定義取得部１１Ｂが、辞書データベース２２にアクセスし、要求文章に含まれる対象語句のそれぞれに対応する辞書情報を検索して取得する。辞書データベース２２から抽出される辞書情報には、図３に示したように、要求文章における対象語句の役割、すなわち、「条件」、「観測対象」及び「期待動作」の全部又は一部にそれぞれ対応する定義が含まれる。なお、対象語句に対応する辞書情報が辞書データベース２２に存在しない場合には、対象語句の類義語句を用いて辞書データベース２２を検索するようにしてもよい。そして、定義取得部１１Ｂは、要求文章に含まれる対象語句のうち、辞書データベース２２から辞書情報が抽出された対象語句のそれぞれについて、辞書情報から、文章解析部１１Ａによって識別された対象語句の役割に応じた定義を取得する。
　ステップ１００３で、定義取得部１１Ｂが、要求文章に含まれる対象語句の定義から、テストのシステム性能（対象性能、観測対象、検証基準）及び計測条件の対象範囲に該当する定義を識別し、要求条件データ２３を生成する。例えば、「条件」、「観測対象」及び「期待動作」の役割に対応する定義においては、「観測対象」がテストを行うシステム性能のうちの対象性能や観測対象、「期待動作」が検証基準、「条件」が計測条件の対象範囲となり得る。
　ステップ１００４で、条件抽出部１２の履歴検索部１２Ａは、テストケーステーブル２４Ａにアクセスし、要求条件データ２３のシステム性能に対応するデータを検索し、当該データを取得する。当該データには、要求条件データ２３のシステム性能に対応するテストが実施された計測条件が記録されているテスト履歴テーブル２４Ｂへの対応付けを示す情報が含まれている。
　ステップ１００５で、履歴検索部１２Ａは、取得したデータによって対応付けられているテスト履歴テーブル２４Ｂを検索し、すでにテストが実施された計測条件のうち、要求条件データ２３の計測条件の対象範囲に含まれる計測条件の情報を取得する。
　ステップ１００６で、条件照合部１２Ｂは、要求条件データ２３の計測条件の対象範囲に含まれる計測条件のテストが未実施であるか否かを判定する。具体的には、条件照合部１２Ｂは、テスト履歴テーブル２４Ｂにすでに格納されている履歴データに含まれる計測条件と、要求条件データ２３が示す計測条件の対象範囲とを照合する。そして、条件照合部１２Ｂは、要求条件データ２３が示す計測条件の対象範囲に含まれ得る計測条件に、テスト履歴テーブル２４Ｂに履歴データが格納されていない計測条件が存在する場合に、テストが未実施であると判定する。テストが未実施である場合にはステップ１００６に進み（Ｙｅｓ）、そうでない場合には処理を終了する。
　ステップ１００７で、条件照合部１２Ｂは、要求条件データ２３のシステム性能に対応するテストについて、要求条件データ２３の計測条件の対象範囲において今回実施するべき計測条件を抽出する。例えば、計測パラメータの値を所定数ずつ変化させてテストを実施する場合、条件照合部１２Ｂは、次のような処理を行う。即ち、条件照合部１２Ｂは、要求条件データ２３の計測条件の対象範囲において、その所定数ずつ異なる計測パラメータのうち、テスト履歴テーブル２４Ｂの履歴データの計測条件に存在しないものを抽出する。換言すれば、条件照合部１２Ｂは、要求条件データ２３の計測条件の対象範囲において、その所定数ずつ異なる計測パラメータのうち、テスト履歴テーブル２４Ｂの履歴データとしてすでに格納されている計測条件以外を、テストケースに含める計測条件として抽出する。そして、条件照合部１２Ｂは、今回実施するべき計測条件を含んだテスト条件データ２５を生成する。なお、本実施形態では、性能検証処理のうち、ここまでのステップ１００１～１００７の処理を、テストケース抽出処理と称する。
　ステップ１００８で、テスト実行部１３は、テストケーステーブル２４Ａから、テスト条件データ２５に含まれるシステム性能に対応するデータを取得する。当該データには、自動テスト用スクリプトを示す情報が含まれている。
　ステップ１００９で、テスト実行部１３は、自動テスト用スクリプトを、テスト条件データ２５に含まれる未実施の計測条件のテストを実行するように変更したテストシナリオを生成し、テストを実施する。そして、テスト実行部１３は、テストの実行結果として得られた出力値と検証基準とを比較し、実行結果が検証基準を満たしているかの検証を行う。さらに、テスト実行部１３は、当該テストを実施した計測条件、当該計測条件におけるテストの実行結果の出力値と検証結果とを含んだテスト結果データ２６を生成する。
　ステップ１０１０で、テスト実行部１３は、テスト結果データ２６に含まれる、テストを実施した計測条件、当該計測条件におけるテストの実行結果の出力値と検証結果で、テスト履歴テーブル２４Ｂを更新する。具体的には、テスト実行部１３は、テスト履歴テーブル２４Ｂに、当該計測条件、テストの実行結果の出力値及び検証結果を含んだデータを登録する。
［性能検証処理の具体例］
　次に、上記の性能検証処理について、データの具体例を示して説明する。
　まず、システムに対する要求仕様がPMSM(永久磁石同期モーター)をインバータで駆動する電動システム有するハイブリッドカーにおける電費の改善であり、特に、「登坂路を走行しており高回転高負荷であるときの電費計算精度が十分にでているか確認したい」というものであるとする。このような要求仕様が存在する背景として、当該ハイブリッドカーで登坂車線が続く高速道路を走行するシーンはモータのエネルギー効率が高いためモータを積極的に使いたい一方、モータ効率の変化勾配が高い領域でもあるため、高い推定精度が求められる背景がある。また、モータ効率は熱エネルギーに散逸する割合と表裏一体であり、熱的上限からその領域でどのくらいの時間モータ駆動が可能かをシステムが把握する上でも電費精度が重要である。なお、図１０は、当該要求仕様における「高速走行×登坂条件」を図式化したものである。このような走行条件においては、モータ加熱の問題からのトルクディレーティングの要否を正確に判断し、モータ駆動とエンジン駆動との最良のバランスを適切に判断することが望ましい。このため、車両の開発工程において、このような走行条件を満たす様々な計測条件における性能検証を行うことが求められる。
　図１１は、要求文章データ２１が「登坂路を走行しており高回転高負荷であるときの電費計算精度が十分であるかを確認したい」という文章である場合における、文章解析部１１Ａ及び定義取得部１１Ｂによる処理の具体例を示している。
　当該要求文章について、文章解析部１１Ａが文章解析処理のうちの形態素解析及び構文解析を行った結果、当該要求文章は、例えば「登坂路　を　走行しており　高回転高負荷　である　ときの　電費計算精度　が　十分　である　か　確認したい」と分割され得る。そして、これらのうち、「登坂路を走行しており高回転高負荷である」の部分は、「ときの」という記述があること等により修飾語（Ｍ）と解析され得る。「電費計算精度が」の部分は、語順や品詞等により主語（Ｓ）と解析され得る。「十分である」の部分は、語順や品詞等により「補語（Ｃ）」と解析され得る。
　そして、当該解析結果に基づいて、さらにそれぞれの語句の役割が識別される。例えば、「登坂路を走行しており高回転高負荷である」は、修飾語に含まれていることや「ときの」という記述等により、要求文章中における役割が「条件」であると識別され得る。「電費計算精度」は、主語に含まれること等から、要求文章中における役割が「観測対象」であると識別され得る。「十分である」は、補語であることや述語に含まれていること等から、要求文章中における役割が「期待動作」であると識別され得る。
　次に、それぞれの語句について、定義取得部１１Ｂは、それぞれの語句をキーとして辞書データベース２２の検索を行い、辞書情報を抽出する。このとき、定義取得部１１Ｂは、類義語句が格納されたデータベース等（図示省略）を参照し、要求文章中に含まれる語句を、意味が類似する別の語句に変換して辞書データベース２２の検索をすることもできる。本具体例においては、図３に示した辞書データベース２２から、「登坂路を走行しており」が変換された「登坂条件」、「高回転高負荷」、「電費計算精度」の語句のそれぞれについて、辞書情報が抽出されるものとする。それぞれの辞書情報には、語句の役割「条件」、「観測対象」及び「期待動作」と、これらのそれぞれの役割に対応付けられた定義とが含まれる。具体的には、語句「登坂条件」については、役割「条件」の定義である「トルク：300～400Nm、回転数：2000～8000rpm」が抽出される。語句「高回転高負荷」については、役割「条件」の定義である「トルク：200～400Nm、回転数:6000～10000rpm」が抽出される。語句「電費計算精度」については、まず、役割「観測対象」の定義である「SignalA」が抽出される。ここで、役割が「期待動作」として抽出された語句が「十分である」という、性能の十分性を意味する語句である。この場合は、定義取得部１１Ｂは、役割が「観測対象」である語句「電費計算精度」について辞書データベース２２に設定された、役割「期待動作」の定義を取得するものとする。即ち、定義取得部１１Ｂは、語句「電費計算精度」の役割「期待動作」の定義である「トルクが0～100Nmの場合：±2％、トルクが100～400Nmの場合：±3％」を抽出する。
　そして、定義取得部１１Ｂは、これらの語句のそれぞれについて辞書データベース２２から抽出した定義を含んだ要求条件データ２３を生成する。図４は、図３で示した辞書データベース２２から取得された定義に基づいて生成された要求条件データ２３の例を示している。定義取得部１１Ｂは、要求条件データ２３のシステム性能のうち、対象性能を、役割が「観測対象」として識別された語句「電費計算精度」自体とする。また、定義取得部１１Ｂは、観測対象を、語句「電費計算精度」の役割「観測対象」の定義である「SignalA」とする。さらに、定義取得部１１Ｂは、検証基準を、語句「電費計算精度」の役割「期待動作」の定義である「トルクが0～100Nmの場合：±2％、トルクが100～400Nmの場合：±3％」とする。
　さらに、定義取得部１１Ｂは、要求条件データ２３の計測条件の対象範囲を次のようにする。即ち、定義取得部１１Ｂは、役割が「条件」と識別された語句「登坂条件」の定義と語句「高回転高負荷」の定義との両方の条件を満たす条件（AND条件）を識別する。この例では、定義取得部１１Ｂは、「トルク：300～400Nm、回転数：6000～8000rpm」を、要求条件データ２３の計測条件の対象範囲とする。
　そして、条件抽出部１２の履歴検索部１２Ａは、要求条件データ２３に基づいて、テスト資産データベース２４のテストケーステーブル２４Ａを検索する。ここで、要求条件データ２３のシステム性能（対象性能、観測対象、検証基準）に対応するデータがテストケーステーブル２４Ａに存在する場合には、履歴検索部１２Ａは、当該データに対応付けられたテスト履歴テーブル２４Ｂの情報を取得する。そして、履歴検索部１２Ａは、テスト履歴テーブル２４Ｂから、要求条件データ２３で示される計測条件の対象範囲のうち、すでにテストが実施されている計測条件を取得する。
　ここで、図１２は、前述した要求条件データ２３の例のシステム性能を検証するテストの履歴が登録されるテスト履歴テーブル２４Ｂのデータを、トルク及びエンジンの回転数の２つの計測条件を軸としてマップ形式で示したものである。当該マップは、縦軸がエンジンの回転数、横軸がトルクを示す。縦軸のエンジンの回転数は、0～2000rpmの値と、以降は2000rpmごとにエンジンの回転数を変化させてテストを実施する場合を想定し、2000rpmごとに行が生成されている。一方で、横軸のトルクは、0～100Nmと、以降は100Nmごとにトルクを変化させてテストを実施する場合を想定し、100Nmごとに列が生成されている。そして、エンジンの回転数の行とトルクの列とが交差している格子点に、テストの出力値に基づく検証結果が示されている。そして、前述したように、要求文章データ２１の要求文章から識別される計測条件の対象範囲は次の通りである。即ち、「登坂条件」の計測条件の対象範囲が「トルク：300～400Nm、回転数：2000～8000rpm」であり、「高回転高負荷」の計測条件の対象範囲が「トルク：200～400Nm、回転数:6000～10000rpm」である。さらに、これらの両方を満たす計測条件の対象範囲が、要求条件データ２３で示される「トルク：300～400Nm、回転数：6000～8000rpm」である。
　ここで、この「トルク：300～400Nm、回転数：6000～8000rpm」の計測条件の対象範囲には、エンジンの回転数を2000rpmごと、トルクを100Nmごとに変化させる場合、図１２の網掛け部分に示されるように、次の計測条件が含まれる。即ち、当該計測条件の対象範囲には、「トルク：300Nm，回転数：6000rpm」、「トルク：300Nm，回転数：8000rpm」、「トルク：400Nm，回転数：6000rpm」、「トルク：400Nm，回転数：8000rpm」の４つの計測条件が含まれる。これらの計測条件のうち、「トルク：400Nm，回転数：8000rpm」については、すでにテスト履歴テーブル２４Ｂにデータが登録されている。このため、条件照合部１２Ｂは、図７に例示するように、他の３つの計測条件を、未実施の計測条件、即ち、テストケースに含める計測条件として抽出する。そして、これらの計測条件を含んだテスト条件データ２５を生成する。
　その後、テスト実行部１３は、テストケーステーブル２４Ａを検索して、テスト条件データ２５のシステム性能に対応するデータを取得し、当該データが示す自動テスト用スクリプトを特定する。そして、テスト実行部１３は、自動テスト用スクリプトを、テスト条件データ２５に含まれる未実施の計測条件のテストを実行するように変更したテストシナリオを生成し、テストを実施する。そして、テスト実行部１３は、図８に例示するようなテスト結果データ２６を生成する。当該テスト結果データ２６に含まれる計測条件及びテスト結果は、テスト履歴テーブル２４Ｂに反映される。
［本実施形態による効果、変形例等］
　本実施形態によれば、開発対象のシステムに対する要求仕様に基づく性能検証のためのテストを行う際に、次のような処理が実行される。まず、要求仕様が記述された要求文章について、形態素解析や構文解析、意味解析が行われる。これにより、要求文章の曖昧さが低減される。そして、要求文章から、テストによって検証するシステム性能及び当該テストを実施する計測条件の対象範囲が識別される。さらに、識別されたシステム性能及び計測条件の対象範囲と、テスト資産データベース２４のテスト履歴テーブル２４Ｂに格納された、すでに実施されたテストにおける計測条件とが照合され、テストケースに含める計測条件が抽出される。これにより、要求仕様を満たす性能を検証するためのテストケースを曖昧な要求文章から自動生成することが可能になる。さらに、単にこのようなテストケースを自動生成するのみならず、現段階ですでに検証が済んでいる計測条件を考慮したテストケースを生成することができる。このため、システムに対する要求仕様に基づく性能検証のためのテストを行うテストケースを生成する作業に伴う負担が大幅に軽減され、システム開発の効率化が実現される。
　また、本実施形態によれば、要求文章に含まれる対象語句の要求文章における意味上の役割を識別し、システムに関連する語句の定義が役割ごとに対応付けられた辞書データベース２２から、対象語句のそれぞれについて識別された役割に応じた定義が取得される。このように各語句の役割に応じた定義を参照することが可能となることは、次のような効果を奏する。すなわち、同じ語句であっても、例えば、それぞれの要求文章における文脈等によって、その語句が示す意味（対象物）が異なる場合がある。このため、単に語句に対して一意に設定された定義を参照することができても、その定義がそれぞれの要求文章において必ずしも的確であるとは限らない。この点につき、本実施形態では、辞書データベース２２において、語句に対して役割に応じた定義が役割ごとに対応付けられている。そして、要求文章に含まれる対象語句について、当該対象語句について識別された役割に応じた定義が取得される。これにより、要求仕様の内容に応じた的確なテストケースを生成することが可能となる。
　さらに、本実施形態では、この役割を「条件」、「観測対象」及び「期待動作」に分類し、これらの役割に応じた定義を抽出している。これにより、テストケースの抽出に必要な情報、即ち、要求文章で記述された要求仕様がどのような条件を前提としているのか、また、観測対象が何であるのか、さらに、その観測対象がどのように動作するべきであるのか、を明確にすることが可能となる。
　また、本実施形態によれば、要求文章に基づいて識別された計測条件の対象範囲に含まれる計測条件のうち、テスト履歴テーブル２４Ｂに格納された履歴データに含まれる計測条件を除いた計測条件が、テストを実施する計測条件として抽出される。このため、未実施の計測条件のみを対象とするテストケースの自動生成が可能になり、このような計測条件の洗い出しをする手間が大幅に軽減される。
　さらに、本実施形態によれば、前述したトルクとエンジン回転数のように、計測条件に複数のパラメータが含まれている場合には、当該複数のパラメータの全てが対象範囲に含まれている計測条件から、テストを実施する計測条件が抽出される。このように、テストを実施する計測条件のパターンが複雑であっても、要求仕様の性能検証に必要な計測条件を的確に抽出することが可能となる。
　ここで、前述の例で示した要求文章のように、システム性能に関する要求文章において、役割が「期待動作」である対象語句が性能の十分性を示す意味を有している場合は多い。このような場合、本実施形態では、役割が「観測対象」である対象語句について辞書データベース２２に設定された、当該対象語句の役割が「期待動作」である場合の定義が取得される。そして、当該定義がシステム性能の検証基準として識別される。このため、より文章の意図する意味に適合したテストケースを生成することが可能となる。
　なお、本実施形態の変形例として、条件抽出部１２は、テスト履歴テーブル２４Ｂの履歴データに含まれるテストの出力値に基づく検証結果が検証基準を満たしていない場合には、当該履歴データの計測条件を、テストケースに含める計測条件としてさらに抽出してもよい。そうすることで、未実施の計測条件のみならず、これまでのテストでは検証基準を満たしていなかった計測条件についても再度テストをし、さらなる性能検証をすることが可能となる。
　また、システムの性能検証を行う際に、要求仕様によっては、計測条件の対象範囲に含まれる全ての計測条件についてテストを実行する必要がなく、１つの計測条件でもテストが行われていれば検証が十分である場合もあり得る。このため、本実施形態のさらなる変形例として、条件抽出部１２は、計測条件が要求条件データ２３の計測条件の対象範囲に含まれる履歴データがテスト履歴テーブル２４Ｂに１件以上存在する場合には、テストを実施する計測条件が存在しないものとして処理してもよい。
　ここで、本実施形態では、性能検証装置１０が、要求識別部１１、条件抽出部１２及びテスト実行部１３の全てを備えている。しかし、このような構成は一例に過ぎず、例えば、これらの構成要素はそれぞれ別の情報処理装置において実装されてもよい。また、例えば、要求識別部１１と条件抽出部１２とが１つの情報処理装置に実装され、テスト実行部１３が他の情報処理装置に実装されてもよい。同様に、本実施形態では、辞書データベース２２及びテスト資産データベース２４を備えているが、これらも必ずしも同じ情報処理装置に含まれる必要はない。例えば、これらのデータをクラウド上にあるサーバが備える記憶装置において格納することも可能である。他のデータについても同様である。
　また、本実施形態では、テスト資産データベース２４がテストケーステーブル２４Ａやテスト履歴テーブル２４Ｂをリレーショナルデータベースとして保持しているが、他の態様でデータを保持することも可能である。例えば、これらのデータは、二次元配列やＪＳＯＮファイル等としても保持され得る。
　また、本実施形態では車両のシステムを例として記載しているが、本発明は、車両以外の様々なシステムの性能検証においても適用可能である。
［ハードウェア構成］
　図１２は、上記の実施形態における性能検証装置１０を構成する情報処理装置のハードウェア構成の一例を示す。本情報処理装置は、プロセッサ９１０、メモリ９２０、ストレージ９３０、可搬記憶媒体駆動装置９４０、入出力装置９５０及び通信インタフェース９６０を備える。
　プロセッサ９１０は、制御ユニット、演算ユニット及び命令デコーダ等を含み、実行ユニットが、命令デコーダで解読されたプログラムの命令に従い、制御ユニットより出力される制御信号に応じ、演算ユニットを用いて算術・論理演算を実行する。かかるプロセッサ９１０は、制御に用いる各種情報が格納される制御レジスタ、既にアクセスしたメモリ９２０等の内容を一時的に格納可能なキャッシュ等を備える。なお、プロセッサ９１０は、ＣＰＵ（Central Processing Unit）コアが複数設けられている構成でもよい。
　メモリ９２０は、例えばＲＡＭ（Random Access Memory）等の記憶装置であり、プロセッサ９１０で実行されるプログラムがロードされるとともに、プロセッサ９１０の処理に用いるデータが格納されるメインメモリである。また、ストレージ９３０は、例えばＨＤＤ（Hard Disk Drive）やフラッシュメモリ等の記憶装置であり、プログラムや各種データが格納される。可搬記憶媒体駆動装置９４０は、可搬記憶媒体９７０に記憶されたデータやプログラムを読み出す装置である。可搬記憶媒体９７０は、例えば磁気ディスク、光ディスク、光磁気ディスク又はフラッシュメモリ等である。なお、プロセッサ９１０は、メモリ９２０やストレージ９３０と協働しつつ、ストレージ９３０や可搬記憶媒体９７０に格納されたプログラムを実行する。なお、プロセッサ９１０が実行するプログラムや、アクセス対象となるデータは、当該情報処理装置と通信することが可能な他の装置に格納されていてもよい。なお、上記のテストケース抽出処理を情報処理装置に実行させるプログラムを、可搬記憶媒体９７０に格納することも可能である。
　入出力装置９５０は例えばタッチパネル、キーボード等やディスプレイ等の入力手段及び出力手段であり、ユーザ操作等による動作命令を受け付ける一方、情報処理装置による処理結果を出力する。通信インタフェース９６０は、外部とのデータ通信を可能にする。前述した情報処理装置の各構成要素は、バス９８０で接続されている。
［その他］
　以上説明した本発明の実施形態は、本発明の技術的範囲で考え得る実施態様の一部に過ぎず、本発明の技術的範囲を制限するものではない。また、各実施形態における機能的構成及び物理的構成は、前述の態様に限定されるものではなく、例えば、各機能や物理的資源を統合して実装したり、逆に、さらに分散して実装したり、さらには、構成の一部について他の構成の追加、削除、置換等をすることも可能である。
１０…性能検証装置、１１…要求識別部、１１Ａ…文章解析部、１１Ｂ…定義取得部、１２…条件抽出部、１２Ａ…履歴検索部、１２Ｂ…条件照合部、１３…テスト実行部、２１…要求文章データ、２２…辞書データベース、２３…要求条件データ、２４…テスト資産データベース、２４Ａ…テストケーステーブル、２４Ｂ…テスト履歴テーブル、２５…テスト条件データ、２６…テスト結果データ

Claims (8)

  1. 　システムに対する要求仕様に基づく性能検証のためのテストを行うテストケースを抽出する情報処理装置であって、
    　前記要求仕様が記述された要求文章を含む入力データを読み出して、前記要求文章の文章解析を行い、前記要求文章に含まれる対象語句の当該要求文章における意味上の役割を識別し、前記システムに関連する語句の定義が前記役割ごとに対応付けられた辞書データベースから、対象語句のそれぞれについて識別された役割に応じた定義を取得し、当該定義に基づいて、テストによって検証するシステム性能及び当該テストを実施する計測条件の対象範囲を識別する要求識別部と、
    　すでに実施されたテストの前記システム性能及び当該テストにおける実施済み計測条件が対応付けられて格納されたテスト資産データベースから、前記システム性能について実施されたテストの履歴データを取得し、当該履歴データに含まれる前記実施済み計測条件と、前記要求文章に含まれる対象語句の定義に基づいて識別された前記計測条件の対象範囲とを照合して、前記テストケースに含める計測条件を抽出する条件抽出部と
    　を備えた、情報処理装置。
  2. 　前記条件抽出部は、前記要求文章に含まれる対象語句の定義に基づいて識別された前記計測条件の対象範囲に含まれる計測条件のうち、前記履歴データに含まれる前記実施済み計測条件を除いた計測条件を、前記テストケースに含める計測条件として抽出する、請求項１記載の情報処理装置。
  3. 　前記条件抽出部は、前記計測条件に複数のパラメータが含まれている場合には、当該複数のパラメータの全てが対象範囲に含まれている計測条件から、前記テストケースに含める計測条件を抽出する、請求項１記載の情報処理装置。
  4. 　前記役割は、前記要求文章が示す前記要求仕様の条件、観測対象、及び期待動作のいずれかであり、
    　前記要求識別部は、前記要求文章に含まれる対象語句のうち、前記役割が観測対象である対象語句の定義及び前記役割が期待動作である対象語句の定義を前記システム性能、前記役割が条件である対象語句の定義を前記計測条件の対象範囲として識別する、請求項１記載の情報処理装置。
  5. 　前記要求識別部は、前記役割が期待動作である対象語句が性能の十分性を示す意味を有する場合、前記役割が観測対象である対象語句について前記辞書データベースに設定された、当該対象語句の役割が期待動作である場合の定義を取得し、当該定義を前記システム性能として識別する、請求項４記載の情報処理装置。
  6. 　前記条件抽出部は、前記履歴データに含まれるテストの実行結果が前記システム性能の示す検証基準を満たしていない場合には、当該履歴データの前記実施済み計測条件を、前記テストケースに含める計測条件としてさらに抽出する、請求項２記載の情報処理装置。
  7. 　前記条件抽出部は、前記実施済み計測条件が前記計測条件の対象範囲に含まれる前記履歴データが１件以上存在する場合には、前記テストケースに含める計測条件が存在しないものとして処理する、請求項１記載の情報処理装置。
  8. 　システムに対する要求仕様に基づく性能検証のためのテストを行うテストケースを抽出するテストケース抽出方法であって、
    　前記要求仕様が記述された要求文章を含む入力データを読み出して、前記要求文章の文章解析を行い、前記要求文章に含まれる対象語句の当該要求文章における意味上の役割を識別し、前記システムに関連する語句の定義が前記役割ごとに対応付けられた辞書データベースから、対象語句のそれぞれについて識別された役割に応じた定義を取得し、当該定義に基づいて、テストによって検証するシステム性能及び当該テストを実施する計測条件の対象範囲を識別し、
    　すでに実施されたテストの前記システム性能及び当該テストにおける実施済み計測条件が対応付けられて格納されたテスト資産データベースから、前記システム性能について実施されたテストの履歴データを取得し、当該履歴データに含まれる前記実施済み計測条件と、前記要求文章に含まれる対象語句の定義に基づいて識別された前記計測条件の対象範囲とを照合して、前記テストケースに含める計測条件を抽出する、
    　処理を情報処理装置が実行するテストケース抽出方法。
PCT/JP2025/006762 2024-06-10 2025-02-27 情報処理装置及びテストケース抽出方法 Pending WO2025258148A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2026527897A JPWO2025258148A1 (ja) 2024-06-10 2025-02-27

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2024093995 2024-06-10
JP2024-093995 2024-06-10

Publications (1)

Publication Number Publication Date
WO2025258148A1 true WO2025258148A1 (ja) 2025-12-18

Family

ID=98050312

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2025/006762 Pending WO2025258148A1 (ja) 2024-06-10 2025-02-27 情報処理装置及びテストケース抽出方法

Country Status (2)

Country Link
JP (1) JPWO2025258148A1 (ja)
WO (1) WO2025258148A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003173277A (ja) * 2001-12-06 2003-06-20 Ns Solutions Corp 性能測定装置、性能測定システム、性能測定方法、記録媒体およびプログラム
CN103714040A (zh) * 2012-10-05 2014-04-09 国际商业机器公司 使用性能度量动态和选择性地管理集成点的方法和装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003173277A (ja) * 2001-12-06 2003-06-20 Ns Solutions Corp 性能測定装置、性能測定システム、性能測定方法、記録媒体およびプログラム
CN103714040A (zh) * 2012-10-05 2014-04-09 国际商业机器公司 使用性能度量动态和选择性地管理集成点的方法和装置

Also Published As

Publication number Publication date
JPWO2025258148A1 (ja) 2025-12-18

Similar Documents

Publication Publication Date Title
US7272752B2 (en) Method and system for integrating test coverage measurements with model based test generation
Finkbeiner et al. RVHyper: A runtime verification tool for temporal hyperproperties
US8402403B2 (en) Verifying a register-transfer level design of an execution unit
Srinivasan A study of two sampling methods for analyzing large datasets with ILP
US6553514B1 (en) Digital circuit verification
US8302078B2 (en) Lazy evaluation of geometric definitions of objects within procedural programming environments
CN114077782B (zh) 一种准确识别损失场景的stpa方法和装置
CN114841103B (zh) 门级电路的并行仿真方法、系统、存储介质及设备
CN110347598A (zh) 一种测试脚本生成方法、装置、服务器及存储介质
Ma et al. Mulcs: Towards a unified deep representation for multilingual code search
WO2021055868A1 (en) Associating user-provided content items to interest nodes
CN115618801B (zh) 缓存一致性检验方法、装置及电子设备
CN112306841A (zh) 轨道业务的自动化测试方法、装置及设备
CN119127921A (zh) 一种电力设备数据智能交互方法、系统、设备及介质
CN120386736A (zh) 一种自动化测试用例生成方法、设备及介质
JP7705322B2 (ja) 文章解析装置及び文章解析方法
US6792581B2 (en) Method and apparatus for cut-point frontier selection and for counter-example generation in formal equivalence verification
KR101501124B1 (ko) 고장 형태 영향 분석(Failure Mode and Effect Analysis(FMEA)) 문서의 시맨틱 모델 처리 방법
CN115686961A (zh) 处理器测试方法、装置及电子设备
CN119962673A (zh) 一种大纲生成模型设计方法、装置、存储介质和程序产品
Castillo et al. RDFMatView: Idexing RDF Data for SPARQL Queries
Triaji et al. Query execution performance analysis of column-oriented database in dashboard
Baier et al. Certificates and Witnesses for Multi-objective ω-Regular Queries in Markov Decision Processes
Alhaddad et al. Utilization of machine learning In RTL-GL signals correlation
Dong et al. Design and application of software performance testing process based on web application

Legal Events

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

Ref document number: 25821499

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2026527897

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2026527897

Country of ref document: JP