Nuclear power software testing method, device and system

Abstract

The invention relates to a nuclear power software testing method, device and system. The method comprises the following steps: in response to a received test instruction for to-be-tested nuclear power software, obtaining target test demand data of a to-be-tested model from test demand information of the to-be-tested nuclear power software; generating a test demand document by using the target test demand data; planning the test process according to the test demand document to obtain a planning result; generating at least one test case based on the planning result and the test requirement document; aiming at each test case in the at least one test case, executing the test case in the to-be-tested nuclear power software according to the test data corresponding to the test case to obtain a test result, determining a deviation degree between the test result and a target result, and when the deviation degree does not meet a preset condition, executing the test case in the to-be-tested nuclear power software. And determining that the to-be-tested nuclear power software does not pass the test. According to the scheme, the testing efficiency and accuracy of the nuclear power software are improved, and the labor cost is reduced.

Description

Technical Field

[0001] The present disclosure relates to the technical field of software testing, and in particular to a nuclear power software testing method, device and system. Background Art

[0002] In related technologies, traditional nuclear power software testing is highly dependent on manual technical solutions, and the entire testing process requires a lot of manual intervention, such as test requirements analysis, test case design, test execution, test result analysis and feedback, etc. All links require manual intervention and supervision. This method has a long test cycle, insufficient test efficiency, high defect rate, and difficulty in dealing with complex system testing requirements and emergencies. In addition, as the complexity of nuclear power systems continues to increase, manual testing methods are difficult to meet the growing efficiency, safety and reliability requirements of nuclear power software testing. Summary of the invention

[0003] In order to overcome the problems existing in the related art, the present disclosure provides a nuclear power software testing method, device and system.

[0004] According to a first aspect of an embodiment of the present disclosure, a nuclear power software testing method is provided, comprising:

[0005] In response to receiving a test instruction for the nuclear power software to be tested, acquiring target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested;

[0006] Generate a test requirement document using the target test requirement data;

[0007] Plan the test process according to the test requirement document to obtain a planning result;

[0008] Generate at least one test case based on the planning result and the test requirement document;

[0009] For each test case in the at least one test case, the test case is executed in the nuclear power software to be tested according to the test data corresponding to the test case to obtain a test result, and the degree of deviation between the test result and the target result is determined. When the degree of deviation does not meet a preset condition, it is determined that the nuclear power software to be tested has failed the test.

[0010] According to a second aspect of an embodiment of the present disclosure, a nuclear power software testing device is provided, comprising:

[0011] an acquisition unit, configured to acquire target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested in response to receiving a test instruction for the nuclear power software to be tested;

[0012] A first generating unit, configured to generate a test requirement document using the target test requirement data;

[0013] A planning unit, used to plan the test process according to the test requirement document and obtain a planning result;

[0014] A second generating unit, configured to generate at least one test case based on the planning result and the test requirement document;

[0015] The testing unit is used to execute the test case in the nuclear power software to be tested according to the test data corresponding to the test case for each test case in the at least one test case, obtain the test result, determine the degree of deviation between the test result and the target result, and determine that the nuclear power software to be tested has failed the test when the degree of deviation does not meet the preset conditions.

[0016] According to a third aspect of an embodiment of the present disclosure, an electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method described in any one of the first aspects is implemented.

[0017] According to a fourth aspect of an embodiment of the present disclosure, there is provided a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the method according to any one of the first aspects is implemented.

[0018] According to a fifth aspect of an embodiment of the present disclosure, a computer program product is provided, comprising a computer program, wherein the computer program implements the method as described in any one of the first aspects when executed by a processor.

[0019] The technical solution provided by the embodiment of the present disclosure may include the following beneficial effects: by responding to receiving a test instruction for the nuclear power software to be tested, obtaining the target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested; generating a test requirement document using the target test requirement data; planning the test process according to the test requirement document to obtain the planning result; generating at least one test case based on the planning result and the test requirement document; for each test case in the at least one test case, executing the test case in the nuclear power software to be tested according to the test data corresponding to the test case, obtaining the test result, determining the degree of deviation between the test result and the target result, and determining that the nuclear power software to be tested has not passed the test when the degree of deviation does not meet the preset conditions. By automating the entire process from generating the requirement document to completing the test, the testing efficiency and accuracy of the nuclear power software are effectively improved, and the labor cost is reduced.

[0020] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0022] Figure 1 The present invention is a flowchart of a nuclear power software testing method according to an exemplary embodiment.

[0023] Figure 2 It is the experimental measurement value curve and the software prediction value curve shown in the embodiment of this application.

[0024] Figure 3 It is a schematic diagram of a parallel execution test case shown in an embodiment of the present application.

[0025] Figure 4 It is a multi-role nuclear power software testing flowchart shown in an embodiment of the present application.

[0026] Figure 5 The invention is a block diagram of a nuclear power software testing device according to an exemplary embodiment.

[0027] Figure 6 It is a block diagram of a device for a nuclear power software testing method according to an exemplary embodiment. DETAILED DESCRIPTION

[0028] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0029] The terms used in the disclosed embodiments are only for the purpose of describing specific embodiments, and are not intended to limit the disclosed embodiments. The singular forms "a", "an" and "the" used in the disclosed embodiments and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0030] It should be understood that although the terms first, second, third, etc. may be used to describe various information in the disclosed embodiments, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the disclosed embodiments, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the words "if" and "if" as used herein may be interpreted as "at" or "when" or "in response to determination".

[0031] In addition, various forms of processes shown in the embodiments of the present disclosure may be used to reorder, add or delete steps. For example, the steps described in the present application may be performed in parallel, sequentially or in different orders, as long as the desired results of the technical solution disclosed in the present application can be achieved, and this document does not limit this.

[0032] In related technologies, traditional nuclear power software testing is highly dependent on manual technical solutions, and the entire testing process requires a lot of manual intervention, such as test requirements analysis, test case design, test execution, test result analysis and feedback, etc. All links require manual intervention and supervision. This method has a long test cycle, insufficient test efficiency, high defect rate, and difficulty in dealing with complex system testing requirements and emergencies. In addition, as the complexity of nuclear power systems continues to increase, manual testing methods are difficult to meet the growing efficiency, safety and reliability requirements of nuclear power software testing.

[0033] In order to solve the above problems, the present disclosure provides a nuclear power software testing method, device and system, which obtains the target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested in response to receiving a test instruction for the nuclear power software to be tested; generates a test requirement document using the target test requirement data; plans the test process according to the test requirement document to obtain the planning result; generates at least one test case based on the planning result and the test requirement document; for each test case in the at least one test case, executes the test case in the nuclear power software to be tested according to the test data corresponding to the test case, obtains the test result, determines the degree of deviation between the test result and the target result, and determines that the nuclear power software to be tested has not passed the test when the degree of deviation does not meet the preset conditions. By automating the entire process from generating the requirement document to completing the test, the testing efficiency and accuracy of the nuclear power software are effectively improved, and the labor cost is reduced.

[0034] Figure 1 is a flowchart of a nuclear power software testing method according to an exemplary embodiment. Figure 1 As shown, it should be noted that the nuclear power software testing method of the embodiment of the present application is applied to a nuclear power software testing device. Figure 1 As shown, the method may include the following steps:

[0035] Step 101 , in response to receiving a test instruction for the nuclear power software to be tested, obtaining target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested.

[0036] It should be noted that nuclear power software refers to various software systems used in the nuclear energy industry, which can cover all aspects of the operation of nuclear power facilities, including nuclear reactor design and simulation, radiation monitoring and protection, nuclear fuel management, safety analysis, operation control systems, etc. Nuclear power software plays a vital role in the nuclear energy industry, helping engineers and operators to design, analyze, monitor and manage nuclear energy systems to ensure the safe operation and efficiency of nuclear power plants.

[0037] In one example, the test requirement information may be information formed through questionnaires, interviews, competitive product analysis, etc. The test requirement information may be in any one or more forms of audio, video, text, and tables.

[0038] In the embodiment of the present application, in response to receiving a test instruction for the nuclear power software to be tested, the target test requirement data of the model to be tested is obtained from the above test requirement information. The acquisition method can be selected according to the type of test requirement information and actual needs. In addition, the acquisition method is a conventional prior art and will not be described in detail here.

[0039] In some embodiments of the present application, it is also possible to interact with the user through a terminal device, that is, to request the user to provide the required test requirement data.

[0040] Step 102: Generate a test requirement document using the target test requirement data.

[0041] In one embodiment, the target test requirement data can be identified and processed to obtain key requirements and main objectives associated with the nuclear power software to be tested, and the requirements can be organized and sorted using UML (Unified Modeling Language) or a requirement matrix to obtain a test requirement document.

[0042] Step 103, plan the test process according to the test requirement document to obtain a planning result.

[0043] In one example, the test process can be planned using the test requirement document according to preset constraints such as time constraints and resource constraints to obtain a planning result. The above constraints can be obtained from the test requirement document or from related project requirements and technical documents.

[0044] In an example, the planning result may include any one or more of a test strategy, a test scope, a resource allocation method, and a test schedule.

[0045] In some embodiments of the present application, step 103 may specifically include the following steps:

[0046] Get preset time constraints and resource constraints;

[0047] Based on the test requirement document, the test process is solved according to the time constraints and resource constraints to obtain the planning results.

[0048] For example, according to the constraints in the above test requirement document, it is determined that the test task is expected to be completed within one week, and it is estimated that 500 core-hours of computing resources are required to meet the requirements. Then, the test process can be determined according to the above requirements and the test environment and auxiliary tools that need to be called can be configured.

[0049] In some embodiments of the present application, after step 103, the method may further include the following steps:

[0050] Step a1: output planning results.

[0051] Step a2: receiving confirmation information from the user regarding the planning result.

[0052] The confirmation information includes whether the planning result meets the requirements or whether the planning result does not meet the requirements.

[0053] Step a3, when the information is confirmed to meet the requirements, execute the step of generating at least one test case based on the planning results and the test requirement document.

[0054] In some embodiments of the present application, when it is confirmed that the information meets the requirements, the test activities can also be coordinated according to the planning results. For example, the test tasks can be assigned according to the planning results, and the completion of the test tasks can be monitored; the monitoring results can also be sent to the terminal devices of the corresponding staff so that the relevant information can be synchronized in a timely manner.

[0055] Step a4: if the information is confirmed to not meet the requirements, return to the step of planning the test process according to the test requirement document.

[0056] It is understandable that in order to ensure that the planning results can meet actual needs, it is necessary to confirm with the user whether the planning results meet the needs after obtaining the planning results. If not, the planning results can be adjusted according to the feedback information from the user, or the test process can be re-planned according to the test requirements document until the user confirms that the planning results meet the user's needs.

[0057] Step 104: Generate at least one test case based on the planning result and the test requirement document.

[0058] In some embodiments, at least one test case may include test cases for functional requirements, and may also include test cases for non-functional requirements (such as software usability requirements) to fully test the nuclear power software and ensure the comprehensiveness and effectiveness of the test cases.

[0059] In some embodiments of the present application, step 104 may specifically include the following steps:

[0060] Step b1, based on the test requirement document, obtain configuration information associated with the nuclear power software to be tested.

[0061] In one embodiment, the specific scope of the nuclear power software to be tested can be determined according to the test requirement document, and the configuration information of the scope can be determined by determining the specific scope.

[0062] In some embodiments, the configuration information may be a formula or a configuration parameter.

[0063] Step b2: Acquire target results matching the configuration information from the first database.

[0064] In some embodiments, the first database may be any database related to the nuclear power software to be tested, and the first database may store mapping relationships between different configuration information and different target results.

[0065] In some embodiments, the target result may be an actual measured value obtained by performing a physical test under a certain configuration information.

[0066] Step b3, obtaining the test data constraint conditions and test data initial values ​​associated with the configuration information from the second database.

[0067] It should be noted that the second database may be the same as the first database or may be different from the first database.

[0068] In addition, there may be one or more first databases and second databases. The first database and the second database may be one or more of the computer software evaluation data sharing platform for nuclear power plant safety analysis.

[0069] In an embodiment of the present application, a data acquisition tool or the like may be used to acquire the test data constraint conditions and the test data initial values ​​associated with the configuration information from the second database.

[0070] Step b4, generating test data corresponding to the test case based on the test data constraint conditions and the test data initial values.

[0071] In some embodiments, the initial values ​​of the test data may be possible values ​​of different input parameters applied to the nuclear power software. The test data may include normal input, boundary input, and illegal input.

[0072] For example, the test data may include a test data name, a data description, and a data value.

[0073] It is understandable that the values ​​of different test data need to be selected within a reasonable range to reduce unnecessary test cases, thereby improving test efficiency.

[0074] Step b5, based on the test requirement document, generate execution steps for testing the nuclear power software to be tested.

[0075] In the embodiments of the present application, the execution steps may follow the normative documents on computer software testing, and generally can be divided into execution according to a static testing method and execution according to a dynamic testing method.

[0076] Specifically, static testing methods can be divided into checklists and static analysis methods. The static testing method for documents is mainly carried out in the form of checklists, while the static testing method for codes generally adopts code review, code walkthrough and static analysis. Static analysis generally includes control flow analysis, data flow analysis, interface analysis and expression analysis.

[0077] Dynamic testing methods generally use white box testing methods and black box testing methods. Black box testing methods generally include functional decomposition, boundary value analysis, decision tables, cause-and-effect diagrams, state diagrams, random testing, guessing errors, and orthogonal testing methods; white box testing methods generally include control flow testing (statement coverage testing, branch coverage testing, condition coverage testing, condition combination coverage testing, path coverage testing), data flow testing, program mutation, program instrumentation, domain testing, and symbolic evaluation.

[0078] For example, for unit testing, the software unit's functions, performance, interfaces, local data structures, independent paths, error handling, boundary conditions, and memory usage can be tested. The order of precedence is clear: testing the software unit interface takes precedence over testing other contents. For a specific software unit, the specific content of the test can be determined based on the software testing contract (or project plan), the requirements of the software design document, and the selected test method.

[0079] Step b6, generating at least one test case based on the test data, execution steps, planning results and target results.

[0080] For example, when the test object is the Core and System Integrated Engine for design and analysis, COSINE, the wall condensation model in the software retrieves the mathematical formula of the wall condensation model according to the test requirement document, obtains the key parameters reflecting the function of the wall condensation model, such as pressure, temperature and condensation amount, and finds the experiment A by matching with the experimental database (Experiment A is a test conducted using a wall condensation entity, and multiple qualified experimental conditions can exist at the same time). The operating condition information of condition B includes the actually measured pressure, temperature and condensation amount, which can be used as the above-mentioned target result, that is, the accurate result expected.

[0081] Step 105, for each test case in at least one test case, execute the test case in the nuclear power software to be tested according to the test data corresponding to the test case, obtain the test result, determine the degree of deviation between the test result and the target result, and when the degree of deviation does not meet the preset conditions, determine that the nuclear power software to be tested has not passed the test.

[0082] In one embodiment, the integral relative deviation method can be used to calculate the deviation between the test result and the target result, and when the deviation is greater than or equal to a preset threshold, the degree of deviation between the test result and the target result is determined. Figure 2 As shown, for two known test measurement value (that is, the target result proposed in some embodiments of the present application) curves f1(x1) and f2(x2) (that is, the test results proposed in some embodiments of the present application), the integrals are taken relative to calculate the deviation to judge the test results.

[0083] For example, it is known that Figure 2 The two curves of temperature change over time are the experimental measurement curve (solid line) and the software prediction curve (dotted line). The definite integral values ​​of the two are calculated respectively. The integral value of the experimental measurement curve is 261305.64, and the integral value of the software prediction curve is 272878.01. The difference is taken and the absolute value is 11572.37. Then the difference 11572.37 is used as the dividend and the integral value 261305.64 of the experimental measurement curve is used as the divisor. The ratio is 0.044 (10-2 power level). The relative deviation of the integral is a value less than 1. The closer it is to 0, the smaller the deviation of the two curves. According to engineering experience, it is usually considered that the deviation is small enough to be ignored when the order of magnitude reaches 10-4 power level.

[0084] As an example, the target result may include a test case name, an expected result, and an actual result (measured data obtained through the test).

[0085] In some embodiments of the present application, the above test results and test process data can also be stored, tracked, and managed. Defect management tools can be used to record defects identified after the test is completed. For example, the status of each defect can be tracked from reporting to repair to final verification, and regular communications can be arranged to update the team on the status of the defect, and it can also be ensured that each defect is accompanied by complete reproduction steps and screenshots. In addition, repair tasks can be arranged according to defect priorities, and communication can be carried out with the development team and the test team to ensure timely repair and retesting, as well as regular reports and statistics can be provided to help management make decisions.

[0086] In some embodiments of the present application, step 105 may specifically include the following steps:

[0087] In the nuclear power software to be tested, multiple test cases are executed in parallel to obtain test results corresponding to each of the multiple test cases;

[0088] Determine the degree of deviation between each test result and the corresponding target result. If the degree of deviation does not meet the preset conditions, determine that the nuclear power software to be tested has failed the test.

[0089] It is understandable that since the test volume of the nuclear power software to be tested is large, in order to further improve the test efficiency, multiple test cases can be executed in parallel. After obtaining the test results, it is also possible to determine in parallel whether the prediction results of each test case meet the conditions.

[0090] For example, if Figure 3 As shown, for batch test cases generated by the generative pre-training model, test cases can be executed in parallel for different computing resource entities a, b, and c, and all test cases in the sequence formed by multiple test cases of the same computing resource entity can be executed in parallel, for example, a1, a2, and a3 in sequence a, b1, b2, and b3 in sequence b, and c1, c2, and c3 in sequence c can be executed in parallel.

[0091] It should be noted that the Generative Pre-trained Model (GPT) is a natural language processing model based on deep learning that can generate and understand natural language text. The core idea of ​​the generative pre-trained model is to obtain language knowledge through large-scale pre-training, and then fine-tune it on specific tasks to generate meaningful and coherent text. The input card of the test case is a text with established rules.

[0092] In some embodiments of the present application, after step 105, the method may further include the following steps:

[0093] When it is determined that the nuclear power software to be tested has not passed the test, the test result is output so that the user can adjust the nuclear power software to be tested based on the test result;

[0094] In response to monitoring the user's adjustment to the nuclear power software to be tested, the method returns to the step of acquiring target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested.

[0095] It is understandable that in order to further realize the automation of testing, when it is detected that the user has made adjustments to the nuclear power software to be tested, the nuclear power software to be tested is retested, which improves the test efficiency and automation and reduces labor costs.

[0096] In the embodiment of the present application, in order to ensure the comprehensiveness, accuracy and fairness of nuclear power software testing and improve testing efficiency and quality, the artificial intelligence entities can be divided into seven main testing stages (that is, different functional modules), and the roles and main responsibilities of each artificial intelligence entity in the testing process are defined, as shown in Table 1:

[0097] Table 1 The roles and main responsibilities of AI agents

[0098] Serial number stage Main Characters Main Responsibilities 1 Demand Analysis Test Requirements Analyst Collect and analyze requirements to determine testing requirements and goals 2 Test Plan Test Scheduler Develop test plans and coordinate testing activities 3 Test Design Test Case Modeler Design test cases, formulate test data and expected results 4 Test Execution Test Execution Assistant Execute test cases and record results and defects 5 Defect Management Test Defect Manager Record, track and manage defects, and communicate fixes 6 Test evaluation Third-party evaluation specialist Independently evaluate test results and provide final evaluation report 7 Test Report Quality Assurance Specialist Writing warranty reports

[0099] like Figure 4 As shown in the figure, according to the basic process of nuclear power software testing, the test requirement analyst collects the functional requirements of nuclear power software testing (which can be proposed by users), clarifies the test requirements and test objectives, and then the test requirement analyst evaluates the requirements, provides feedback on suggestions for optimizing the requirements, and fully communicates with users to ensure the accuracy and completeness of the requirements.

[0100] For example, during the software development process, a new function of a wall condensation model is added. The user issues an instruction to test the function. After evaluation by the test requirements analyst, if the requirement is unreasonable, suggestions for optimizing the requirement are provided until the requirement is reasonable, and the next step of formulating a test plan can be carried out.

[0101] After clarifying the requirements, it is necessary to specify a test plan in conjunction with the project nodes. The test schedule planner will develop a detailed test plan, including test strategy, test scope, resource allocation, schedule, etc. At the same time, the test environment and auxiliary tools are determined according to the requirements and goals. The test schedule planner is responsible for guiding and coordinating the entire test process to ensure that the test activities can proceed as planned.

[0102] The test case modeler is responsible for designing detailed test cases to ensure that all functional and non-functional requirements (such as software usability requirements) are fully tested. This role requires the development of test data and prediction results to ensure the comprehensiveness and effectiveness of test cases, and to work with test requirements analysts and other relevant agents to optimize test design and improve test coverage and quality.

[0103] The actual modeling can be divided into four steps: 1. Establish a software input card according to the geometric parameters, initial conditions and boundary conditions of the experimental bench; 2. Obtain key parameters such as pressure and temperature in the experimental data; 3. Write a drawing script for drawing calculation results and experimental data; 4. Pass the input card, drawing script and experimental data results to the test execution assistant.

[0104] The test execution assistant is responsible for executing test cases in the configured test environment, recording test results and defects found. This role needs to carefully execute each test step, ensure the accuracy of the data, and promptly feedback the problems found to other agents in the test team and the R&D team in the form of test reports for defect analysis and repair to ensure software quality.

[0105] The test defect manager is responsible for recording, tracking and managing defects found during the testing process. This role needs to communicate with other agents in the test team and the R&D team to ensure that defects are fixed in a timely manner, verify the repaired defects, ensure that the problems are completely resolved, and maintain the accuracy and timeliness of the defect management system.

[0106] The third-party evaluator is independent of the development and testing team and is responsible for objectively evaluating the test results. This role requires verifying the integrity, effectiveness, suitability, and conservatism of the test process and results, providing an independent evaluation report, ensuring the transparency and fairness of the test process, and helping to identify potential risks and optimization directions.

[0107] The quality assurance specialist is responsible for communicating with other agents and writing detailed test reports, including the test process, test results, defect statistics and repair status, etc. This role needs to review the test report to ensure its accuracy and completeness, provide reliable test information support to stakeholders, and provide a basis for the final decision of the project. For example, the quality assurance specialist can collect test data and analyze it, write a detailed test report based on the analysis results, ensure that each data in the report has a reliable source, and review the test report to ensure that there are no errors and omissions, check whether the data in the report is consistent with the actual test results, give suggestions for report modifications, and guide improvements.

[0108] Through the above-mentioned multi-role division of labor and collaboration, the comprehensiveness, accuracy and fairness of nuclear power software testing can be ensured, and the testing efficiency and quality can be improved.

[0109] According to the nuclear power software testing device proposed in the embodiment of the present application, in response to receiving a test instruction for the nuclear power software to be tested, the target test requirement data of the model to be tested is obtained from the test requirement information of the nuclear power software to be tested; a test requirement document is generated using the target test requirement data; the test process is planned according to the test requirement document to obtain a planning result; at least one test case is generated based on the planning result and the test requirement document; for each test case in at least one test case, the test case is executed in the nuclear power software to be tested according to the test data corresponding to the test case, the test result is obtained, and the degree of deviation between the test result and the target result is determined. When the degree of deviation does not meet the preset conditions, it is determined that the nuclear power software to be tested has not passed the test. By automating the entire process from generating the requirement document to completing the test, the testing efficiency and accuracy of the nuclear power software are effectively improved, and the labor cost is reduced.

[0110] Figure 5 is a block diagram of a nuclear power software testing device according to an exemplary embodiment. Figure 5 The device includes an acquisition unit 501, a first generation unit 502, a planning unit 503, a second generation unit 504 and a testing unit 505.

[0111] The acquisition unit 501 is used to acquire target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested in response to receiving a test instruction for the nuclear power software to be tested;

[0112] A first generating unit 502 is used to generate a test requirement document using target test requirement data;

[0113] The planning unit 503 is used to plan the test process according to the test requirement document and obtain the planning result;

[0114] A second generating unit 504, configured to generate at least one test case based on the planning result and the test requirement document;

[0115] The testing unit 505 is used to execute the test case in the nuclear power software to be tested according to the test data corresponding to the test case for each test case in at least one test case, obtain the test result, determine the degree of deviation between the test result and the target result, and determine that the nuclear power software to be tested has not passed the test when the degree of deviation does not meet the preset conditions.

[0116] In some embodiments of the present application, the second generating unit 504 may be specifically used for:

[0117] Based on the test requirement document, obtain configuration information associated with the nuclear power software to be tested;

[0118] Acquire a target result matching the configuration information from the first database;

[0119] Acquire test data constraint conditions and test data initial values ​​associated with the configuration information from the second database;

[0120] Generate test data corresponding to the test case based on test data constraints and test data initial values;

[0121] Generate execution steps for testing the nuclear power software to be tested based on the test requirement document;

[0122] At least one test case is generated based on the test data, the execution steps, the planning results and the target results.

[0123] In some embodiments of the present application, the planning unit 503 may be specifically used for:

[0124] Get preset time constraints and resource constraints;

[0125] Based on the test requirement document, the test process is solved according to the time constraints and resource constraints to obtain the planning results.

[0126] In some embodiments of the present application, the testing unit 505 may be specifically used for:

[0127] In the nuclear power software to be tested, multiple test cases are executed in parallel to obtain test results corresponding to each of the multiple test cases;

[0128] Determine the degree of deviation between each test result and the corresponding target result. If the degree of deviation does not meet the preset conditions, determine that the nuclear power software to be tested has failed the test.

[0129] In some embodiments of the present application, the device may further include:

[0130] An output unit, used for outputting planning results;

[0131] A receiving unit, configured to receive confirmation information from a user regarding a planning result; the confirmation information includes whether the planning result meets the requirement or whether the planning result does not meet the requirement;

[0132] An execution unit, configured to execute the step of generating at least one test case based on the planning result and the test requirement document when the information is confirmed to meet the requirements;

[0133] The execution unit is also used to return to the step of planning the test process according to the test requirement document when the information is confirmed to not meet the requirements.

[0134] In some embodiments of the present application, the device may further include:

[0135] The output unit is further used to output the test result when it is determined that the nuclear power software to be tested has not passed the test, so that the user can adjust the nuclear power software to be tested based on the test result;

[0136] The execution unit is also used to return to execute the step of obtaining target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested in response to monitoring the user's adjustment to the nuclear power software to be tested.

[0137] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0138] According to the nuclear power software testing device proposed in the embodiment of the present application, in response to receiving a test instruction for the nuclear power software to be tested, the target test requirement data of the model to be tested is obtained from the test requirement information of the nuclear power software to be tested; a test requirement document is generated using the target test requirement data; the test process is planned according to the test requirement document to obtain a planning result; at least one test case is generated based on the planning result and the test requirement document; for each test case in at least one test case, the test case is executed in the nuclear power software to be tested according to the test data corresponding to the test case, the test result is obtained, and the degree of deviation between the test result and the target result is determined. When the degree of deviation does not meet the preset conditions, it is determined that the nuclear power software to be tested has not passed the test. By automating the entire process from generating the requirement document to completing the test, the testing efficiency and accuracy of the nuclear power software are effectively improved, and the labor cost is reduced.

[0139] Figure 6 6 is a block diagram of a device for a nuclear power software testing method according to an exemplary embodiment. For example, the device 600 may be an electronic device, such as a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0140] Reference Figure 6 , the device 600 may include one or more of the following components: a processing component 602 , a memory 604 , a power component 606 , a multimedia component 608 , an audio component 610 , an input / output (I / O) interface 612 , a sensor component 614 , and a communication component 616 .

[0141] The processing component 602 generally controls the overall operation of the device 600, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 602 may include one or more processors 620 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 602 may include one or more modules to facilitate the interaction between the processing component 602 and other components. For example, the processing component 602 may include a multimedia module to facilitate the interaction between the multimedia component 608 and the processing component 602.

[0142] The memory 604 is configured to store various types of data to support operations on the device 600. Examples of such data include instructions for any application or method operating on the device 600, contact data, phone book data, messages, pictures, videos, etc. The memory 604 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0143] The power component 606 provides power to the various components of the device 600. The power component 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device 600.

[0144] The multimedia component 608 includes a screen that provides an output interface between the device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 608 includes a front camera and / or a rear camera. When the device 600 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0145] The audio component 610 is configured to output and / or input audio signals. For example, the audio component 610 includes a microphone (MIC), and when the device 600 is in an operating mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 604 or sent via the communication component 616. In some embodiments, the audio component 610 also includes a speaker for outputting audio signals.

[0146] I / O interface 612 provides an interface between processing component 602 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0147] The sensor assembly 614 includes one or more sensors for providing various aspects of status assessment for the device 600. For example, the sensor assembly 614 can detect the open / closed state of the device 600, the relative positioning of components, such as the display and keypad of the device 600, and the sensor assembly 614 can also detect the position change of the device 600 or a component of the device 600, the presence or absence of user contact with the device 600, the orientation or acceleration / deceleration of the device 600, and the temperature change of the device 600. The sensor assembly 614 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 614 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 614 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0148] The communication component 616 is configured to facilitate wired or wireless communication between the device 600 and other devices. The device 600 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 616 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0149] In an exemplary embodiment, the apparatus 600 may be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to perform the above method.

[0150] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions, and the instructions can be executed by a processor 620 of the device 600 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0151] In an exemplary embodiment, a computer program product is also provided, comprising a computer program, which implements the above method when executed by the processor 620 of the device 600 .

[0152] Those skilled in the art will readily appreciate other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art that are not disclosed in this disclosure. The specification and examples are to be considered exemplary only, and the true scope and spirit of the present invention are indicated by the following claims.

[0153] It should be understood that the present invention is not limited to the exact construction that has been described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A nuclear power software testing method, characterized in that: include: In response to receiving a test instruction for the nuclear power software to be tested, acquiring target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested; Generate a test requirement document using the target test requirement data; Plan the test process according to the test requirement document to obtain a planning result; Generate at least one test case based on the planning result and the test requirement document; For each test case in the at least one test case, the test case is executed in the nuclear power software to be tested according to the test data corresponding to the test case to obtain a test result, and the degree of deviation between the test result and the target result is determined. When the degree of deviation does not meet a preset condition, it is determined that the nuclear power software to be tested has failed the test.

2. The nuclear power software testing method according to claim 1, characterized in that: The generating at least one test case based on the planning result and the test requirement document comprises: Based on the test requirement document, obtaining configuration information associated with the nuclear power software to be tested; Acquire the target result matching the configuration information from the first database; Acquire test data constraint conditions and test data initial values ​​associated with the configuration information from a second database; Generate test data corresponding to the test case based on the test data constraint condition and the test data initial value; Based on the test requirement document, generating execution steps for testing the nuclear power software to be tested; The at least one test case is generated based on the test data, the execution steps, the planning results and the target results.

3. The nuclear power software testing method according to claim 1, characterized in that: The step of planning the test process according to the test requirement document to obtain a planning result includes: Get preset time constraints and resource constraints; Based on the test requirement document, the test process is solved according to the time constraint condition and the resource constraint condition to obtain the planning result.

4. The nuclear power software testing method according to claim 1, characterized in that: For each test case in the at least one test case, executing the test case in the nuclear power software to be tested according to the test data corresponding to the test case, obtaining a test result, determining a degree of deviation between the test result and a target result, and determining that the nuclear power software to be tested has failed the test when the degree of deviation does not meet a preset condition, includes: In the nuclear power software to be tested, multiple test cases are executed in parallel to obtain test results corresponding to each of the multiple test cases; Determine the degree of deviation between each test result and the corresponding target result. If the degree of deviation does not meet a preset condition, determine that the nuclear power software to be tested has failed the test.

5. The nuclear power software testing method according to claim 1, characterized in that: After planning the test process according to the test requirement document and obtaining the planning result, the method further includes: Outputting the planning result; Receiving confirmation information from a user regarding the planning result; the confirmation information includes whether the planning result meets the requirement or whether the planning result does not meet the requirement; In the case where the confirmation information satisfies the requirements, executing the step of generating at least one test case based on the planning result and the test requirement document; In the case that the confirmation information indicates that the requirements are not met, the process returns to the step of planning the test process according to the test requirement document.

6. The nuclear power software testing method according to claim 1, characterized in that: Also includes: When it is determined that the nuclear power software to be tested has not passed the test, outputting the test result so that the user can adjust the nuclear power software to be tested based on the test result; In response to monitoring the user's adjustment to the nuclear power software to be tested, return to execute the step of acquiring the target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested.

7. A nuclear power software testing device, characterized in that: include: an acquisition unit, configured to acquire target test requirement data of the model to be tested from the test requirement information of the nuclear power software to be tested in response to receiving a test instruction for the nuclear power software to be tested; A first generating unit, configured to generate a test requirement document using the target test requirement data; A planning unit, used to plan the test process according to the test requirement document and obtain a planning result; A second generating unit, configured to generate at least one test case based on the planning result and the test requirement document; The testing unit is used to execute the test case in the nuclear power software to be tested according to the test data corresponding to the test case for each test case in the at least one test case, obtain the test result, determine the degree of deviation between the test result and the target result, and determine that the nuclear power software to be tested has failed the test when the degree of deviation does not meet the preset conditions.

8. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that The computer program implements the method according to any one of claims 1 to 6 when executed by a processor.

Images