A software version risk assessment method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a software version risk assessment method and device, electronic equipment and storage medium. The method comprises: obtaining a risk assessment request, the risk assessment request comprising a version number to be assessed, the version number to be assessed corresponding to a first version node in a preset knowledge graph; determining each second version node associated with the first version node based on a first type of edge between each version node in the preset knowledge graph, the first type of edge indicating that there is a preset version relationship between version nodes; determining a risk assessment result corresponding to the version number to be assessed according to a second type of edge between each candidate version node and a problem node in the preset knowledge graph, the second type of edge indicating that there is a preset problem relationship between version nodes and problem nodes, and the candidate version node comprising the second version node and the first version node. The technical solution provided by the embodiments of the present application can assess the risk of a software version in the case that there are multiple software versions in a product.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a software version risk assessment method, apparatus, electronic device, and storage medium. Background Technology

[0002] Once a product is released, its software versions are continuously upgraded and updated, resulting in iterative releases. However, users don't constantly upgrade to new software versions, leading to a wide variety of software versions of the same product installed on the market. A single software version may inherit problems introduced in previous versions, introduce new problems, or resolve existing issues. Furthermore, the way a single software version is presented can vary, making it difficult for product developers to pinpoint unresolved issues in each version and whether these issues have been addressed in subsequent versions. This makes it difficult for users to understand the risks associated with their current software version. Summary of the Invention

[0003] The purpose of this application is to provide a software version risk assessment method, apparatus, electronic device, and storage medium to accurately locate software version problems and conduct risk assessments when multiple software versions exist for a product. The specific technical solution is as follows:

[0004] In a first aspect, embodiments of this application provide a software version risk assessment method, the method comprising:

[0005] Obtain a risk assessment request, the risk assessment request including the version number to be assessed, the version number to be assessed corresponding to the first version node in a preset knowledge graph;

[0006] Based on the first type of edge between each version node in the preset knowledge graph, each second version node associated with the first version node is determined, and the first type of edge indicates that there is a preset version relationship between the version nodes connected by the first type of edge.

[0007] Based on the second type of edge between each candidate version node and the problem node in the preset knowledge graph, the risk assessment result corresponding to the version number to be evaluated is determined. The second type of edge indicates that there is a preset problem relationship between the version node and the problem node connected by the second type of edge. The candidate version node includes the second version node and the first version node.

[0008] In one embodiment, the step of determining the various second version nodes associated with the first version node based on the first type of edges between each version node in the preset knowledge graph includes:

[0009] Based on the first type of edges between each version node in the preset knowledge graph, the version node that has a reachable path with the first version node corresponding to the version number to be evaluated is determined as the second version node.

[0010] In one embodiment, the preset version relationship includes one or more of inheritance, inclusion, and equivalence relationships;

[0011] The reachable path is: starting from the first version node, the path formed by all the first type edges traversed by the first type edges that satisfy the preset rules to reach other version nodes, where the other version nodes are the second version nodes;

[0012] The preset rules include a first type of rule for determining unresolved issues in the first version node, and / or a second type of rule for determining whether the issues in the first version node have been resolved;

[0013] The first type of rule includes at least one of the following rules:

[0014] Rule 1: The version node inherited by the first version node;

[0015] Rule 2, the version nodes included in the first version node;

[0016] Rule 3: Version nodes inherited by version nodes contained in the first version node;

[0017] Rule 4: Version nodes equivalent to the first target version node, where the first target version node includes the first version node, version nodes that satisfy Rule 1, version nodes that satisfy Rule 2, and version nodes that satisfy Rule 3.

[0018] Rule 5: The version node that is inherited by the version node that is equivalent to the first target version node;

[0019] Rule 6: Version nodes contained in a version node that is equivalent to the first target version node;

[0020] Rule 7: A version node that is inherited by a version node contained in a version node that is equivalent to the first target version node;

[0021] The second category of rules includes at least one of the following rules:

[0022] Rule 8: Inherit the version node of the first version node;

[0023] Rule 9: Inherit the version node of the version node contained in the first version node;

[0024] Rule 10: Inherit the version node that is equivalent to the first version node;

[0025] Rule 11, a version node equivalent to the second target version node, the second target version node including the version node that satisfies rule 8, the version node that satisfies rule 9 and the version node that satisfies rule 10;

[0026] Rule 12: Inherit the version node of the version node that is equivalent to the second target version node.

[0027] In one embodiment, the preset problem relationship includes an introduction problem relationship and a problem-solving relationship;

[0028] The step of determining the risk assessment result corresponding to the version number to be evaluated based on the second type of edges between each candidate version node and the problem node in the preset knowledge graph includes:

[0029] Based on the second type of edges between each candidate version node and the question node in the preset knowledge graph, candidate question nodes are determined. The candidate question node and the candidate version node have a second type of edge indicating the relationship of introducing a question, and the candidate question node and the candidate version node do not have a second type of edge indicating the relationship of solving a problem.

[0030] Based on the issues indicated by the candidate issue nodes, a risk assessment result corresponding to the version number to be evaluated is generated.

[0031] In one embodiment, the method further includes:

[0032] Obtain a first query request, which includes the version number to be evaluated and the query question, wherein the query question corresponds to a target question node in the preset knowledge graph;

[0033] From the preset knowledge graph, determine the third version node that has a second type of edge with the target problem node;

[0034] Based on the position of the third version node in the preset knowledge graph and the position of the first version node corresponding to the version number to be evaluated, a problem evaluation result is generated. The problem evaluation result indicates whether the problem to be queried is a problem existing in the version number to be evaluated.

[0035] In one embodiment, the method further includes:

[0036] Obtain a second query request, which includes the version knowledge to be queried;

[0037] Based on the layout of each version node in the preset knowledge graph, the query results of the version knowledge to be queried are generated.

[0038] Secondly, embodiments of this application provide a software version risk assessment device, the device comprising:

[0039] The first acquisition unit is used to acquire a risk assessment request, the risk assessment request including a version number to be assessed, the version number to be assessed corresponding to a first version node in a preset knowledge graph;

[0040] The first determining unit is used to determine each second version node associated with the first version node based on the first type of edge between each version node in the preset knowledge graph. The first type of edge indicates that there is a preset version relationship between the version nodes connected by the first type of edge.

[0041] The second determining unit is used to determine the risk assessment result corresponding to the version number to be evaluated based on the second type of edge between each candidate version node and the problem node in the preset knowledge graph. The second type of edge indicates that there is a preset problem relationship between the version node and the problem node connected by the second type of edge. The candidate version node includes the second version node and the first version node.

[0042] In one embodiment, the first determining unit is specifically used for:

[0043] Based on the first type of edges between each version node in the preset knowledge graph, the version node that has a reachable path with the first version node corresponding to the version number to be evaluated is determined as the second version node.

[0044] In one embodiment, the preset version relationship includes one or more of inheritance, inclusion, and equivalence relationships;

[0045] The reachable path is: starting from the first version node, the path formed by all the first type edges traversed by the first type edges that satisfy the preset rules to reach other version nodes, where the other version nodes are the second version nodes;

[0046] The preset rules include a first type of rule for determining unresolved issues in the first version node, and / or a second type of rule for determining whether the issues in the first version node have been resolved;

[0047] The first type of rule includes at least one of the following rules:

[0048] Rule 1: The version node inherited by the first version node;

[0049] Rule 2, the version nodes included in the first version node;

[0050] Rule 3: Version nodes inherited by version nodes contained in the first version node;

[0051] Rule 4: Version nodes equivalent to the first target version node, where the first target version node includes the first version node, version nodes that satisfy Rule 1, version nodes that satisfy Rule 2, and version nodes that satisfy Rule 3.

[0052] Rule 5: The version node that is inherited by the version node that is equivalent to the first target version node;

[0053] Rule 6: Version nodes contained in a version node that is equivalent to the first target version node;

[0054] Rule 7: A version node that is inherited by a version node contained in a version node that is equivalent to the first target version node;

[0055] The second category of rules includes at least one of the following rules:

[0056] Rule 8: Inherit the version node of the first version node;

[0057] Rule 9: Inherit the version node of the version node contained in the first version node;

[0058] Rule 10: Inherit the version node that is equivalent to the first version node;

[0059] Rule 11, a version node equivalent to the second target version node, the second target version node including the version node that satisfies rule 8, the version node that satisfies rule 9 and the version node that satisfies rule 10;

[0060] Rule 12: Inherit the version node of the version node that is equivalent to the second target version node.

[0061] In one embodiment, the preset problem relationship includes an introduction problem relationship and a problem-solving relationship;

[0062] The second determining unit is specifically used for:

[0063] Based on the second type of edges between each candidate version node and the question node in the preset knowledge graph, candidate question nodes are determined. The candidate question node and the candidate version node have a second type of edge indicating the relationship of introducing a question, and the candidate question node and the candidate version node do not have a second type of edge indicating the relationship of solving a problem.

[0064] Based on the issues indicated by the candidate issue nodes, a risk assessment result corresponding to the version number to be evaluated is generated.

[0065] In one embodiment, the apparatus further includes:

[0066] The second acquisition unit is used to acquire a first query request, the first query request including the version number to be evaluated and the query question, the query question corresponding to the target question node in the preset knowledge graph;

[0067] The third determining unit is used to determine, from the preset knowledge graph, a third version node that has a second type of edge with the target question node;

[0068] The first generation unit is used to generate a problem evaluation result based on the position of the third version node in the preset knowledge graph and the position of the first version node corresponding to the version number to be evaluated. The problem evaluation result indicates whether the problem to be queried is a problem existing in the version number to be evaluated.

[0069] In one embodiment, the apparatus further includes:

[0070] The third acquisition unit is used to acquire a second query request, the second query request including the version knowledge to be queried;

[0071] The second generation unit is used to generate query results for the version knowledge to be queried based on the layout of each version node in the preset knowledge graph.

[0072] Thirdly, embodiments of this application provide an electronic device, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being prompted by the machine-executable instructions to implement any of the steps of the software version risk assessment method described above.

[0073] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the steps of the software version risk assessment method described above.

[0074] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to execute any of the software version risk assessment methods described above.

[0075] Beneficial effects of the embodiments in this application:

[0076] In the technical solution provided in this application embodiment, a knowledge graph is pre-defined. This pre-defined knowledge graph includes version nodes and issue nodes. Version nodes are connected by first-type edges indicating a pre-defined version relationship, and version nodes and issue nodes are connected by second-type edges indicating a pre-defined issue relationship. Based on the version nodes, issue nodes, first-type edges, and second-type edges in the pre-defined knowledge graph, the version nodes associated with the version number to be evaluated can be accurately and comprehensively determined, and thus the issue nodes associated with the version number to be evaluated can be determined. In this way, unresolved issues in the version number to be evaluated can be identified, and it can also be determined in which software version the unresolved issue was introduced and in which software version it was subsequently resolved. Therefore, when a product has multiple software versions, the issues of the software versions can be accurately located, and the risk assessment of the software versions can be accurately and comprehensively performed.

[0077] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0078] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0079] Figure 1 A schematic diagram of a version tree structure constructed based on version nodes and the first type of edges between version nodes, provided in an embodiment of this application;

[0080] Figure 2 To Figure 1 A schematic diagram of a pre-defined knowledge graph obtained by adding question nodes to the version tree shown;

[0081] Figure 3 A schematic diagram of the first flowchart of the software version risk assessment method provided in the embodiments of this application;

[0082] Figure 4 A second flowchart illustrating the software version risk assessment method provided in this application embodiment;

[0083] Figure 5 A schematic diagram of the third software version risk assessment method provided in the embodiments of this application;

[0084] Figure 6 A schematic diagram of the fourth process of the software version risk assessment method provided in the embodiments of this application;

[0085] Figure 7A fifth flowchart illustrating the software version risk assessment method provided in this application embodiment;

[0086] Figure 8 A schematic diagram of a software version risk assessment device provided in an embodiment of this application;

[0087] Figure 9 This is a schematic diagram of an electronic device used to implement the software version risk assessment method provided in the embodiments of this application. Detailed Implementation

[0088] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0089] Once a product is released, its software versions are continuously upgraded and updated, resulting in iterative releases. However, users don't constantly upgrade to new software versions, leading to a wide variety of software versions of the same product installed on the market. A single software version may inherit problems introduced in previous versions, introduce new problems, or resolve existing issues. Furthermore, the way a single software version is presented can vary, making it difficult for product developers to pinpoint unresolved issues in each version and whether these issues have been addressed in subsequent versions. This makes it difficult for users to understand the risks associated with their current software version.

[0090] To address the aforementioned issues, this application provides a software version risk assessment method. This method pre-defines a knowledge graph, which includes version nodes and issue nodes. Version nodes are connected by first-type edges indicating pre-defined version relationships, and version nodes and issue nodes are connected by second-type edges indicating pre-defined issue relationships. Based on the version nodes, issue nodes, first-type edges, and second-type edges in the pre-defined knowledge graph, the version nodes associated with the version number to be assessed can be accurately and comprehensively determined, thereby identifying the issue nodes associated with the version number to be assessed. This allows for the identification of unresolved issues within the version number to be assessed, and also reveals in which software version the unresolved issue was introduced and subsequently resolved. Therefore, even when a product has multiple software versions, it is possible to accurately locate software version issues and conduct a comprehensive and accurate risk assessment of the software version.

[0091] Furthermore, in the pre-defined knowledge graph, version nodes are connected by first-type edges, which indicate various pre-defined version relationships between them. In this case, regardless of whether a software version has multiple version numbers due to diverse representation methods, or whether software version updates result in a product having multiple version numbers, the pre-defined knowledge graph can identify version nodes with the aforementioned relationships (also known as version relationships) with the first version node. This allows for the identification of all related issues for the first version node, facilitating the location of unresolved issues in the software version and improving the comprehensiveness and accuracy of software version evaluation.

[0092] The software version risk assessment method provided in this application will be described in detail below through specific embodiments. For ease of understanding, the following description uses an electronic device as the execution subject, without limitation.

[0093] In this embodiment, a knowledge graph, or preset knowledge graph, is pre-defined in the electronic device. This preset knowledge graph includes multiple version nodes and multiple issue nodes. Each version node corresponds one-to-one with a software version number. Different software version numbers can be managed using different types of version nodes. For example, PdtVersion (abbreviated as PdtV) can be used to manage kernel version nodes, PlatVersion (abbreviated as PlatV) can be used to manage platform version nodes, BootVersion (abbreviated as BootV) can be used to manage firmware version nodes, ReleaseVersion (abbreviated as RlsV) can be used to manage external version nodes, and BuildVersion (abbreviated as BV) can be used to manage internal version nodes, etc. Here, RlsV or BV can be understood as a complete system version, such as the system version of a switch; PdtV, PlatV, or BootV can be understood as the versions of various components within a system version. A system version includes versions of one or more components, and the versions of the components are independent of each other.

[0094] To facilitate the management of version nodes, corresponding attribute information can be established based on the version characteristics of the software version number itself, such as "whether it is a patch version" and "version release time".

[0095] In the pre-defined knowledge graph, version nodes are connected by edges. For ease of distinction, these edges will be referred to as first-type edges. First-type edges indicate that a pre-defined version relationship exists between the version nodes connected by the edge. This pre-defined version relationship includes one or more of inheritance, inclusion, and equivalence relationships. Version nodes and the first-type edges between them constitute a version tree, as shown below. Figure 1 The version tree shown is a part of a pre-defined knowledge graph, such as... Figure 2The knowledge graph shown can include not only version trees but also question data. Figure 1 and Figure 2 In the diagram, each circle represents a node, such as a version node or an issue node. Edges with the word "inheritance" indicate inheritance relationships, edges with the word "containment" indicate containment relationships, and edges with the word "equivalence" indicate equivalence relationships.

[0096] Inheritance relationships can include "sub-version" relationship data, such as... Figure 1 The relationship between RlsV1 and RlsV2 is shown, where RlsV1 is inherited by RlsV2, and RlsV2 inherits from RlsV1. Inheritance relationships can also include "grandchild version" relationships, such as... Figure 2 The relationship between RlsV1 and RlsV3 is shown below. Figure 2 (Not shown in the image). This inheritance relationship can be used to associate the inheritance relationship between two software version numbers. Inheritance relationships can also include other inheritance class data, without limitation.

[0097] The containment relationship is a type of data that includes other data. For example, RlsV contains PdtV, PlatV, and BootV, meaning that PdtV, PlatV, BootV, and RlsV have a unique mapping relationship. Figure 1 In this context, RlsV1 includes PdtV5, PlatV1, and BootV5, and PdtV5, PlatV1, BootV5, and RlsV1 have a unique mapping relationship. This inclusion relationship clearly shows the version numbers of each software component included in each publicly released system version.

[0098] Equivalence relations are data of the "equivalence" relation type. Equivalence relations are used to connect two version nodes that have the same software version but different version numbers. For example, for the same software version, the version number released for the overseas market is 'a', and the version number released for the domestic market is 'b'. In the pre-defined knowledge graph, nodes 'a' and 'b' have an equivalence relation. If two equivalent version nodes each have multiple version nodes, these multiple version nodes correspond one-to-one. Here, the corresponding two version nodes are equivalent nodes. For example, equivalent RlsV and BV have a one-to-one correspondence in their version nodes. Figure 1 As shown, RlsV1 is equivalent to RlsV4, RlsV4 is equivalent to BV1, and RlsV1 includes RlsV2 and RlsV5. Therefore, BV1 should include a version node corresponding to RlsV2 and a version node corresponding to RlsV5.

[0099] In this embodiment of the application, to make the version tree and knowledge graph clearer, version nodes of the same type are grouped together, and a version subtree corresponding to the group of version nodes is established according to the version relationships between the version nodes in that group, such as... Figure 1 and Figure 2 As shown, each rectangle containing a version node represents a version subtree. Figure 1 Let's take an example to illustrate. Figure 1 In this context, PdtV is grouped together to construct version subtree 1; PlatV is grouped together to construct version subtree 2; BootV is grouped together to construct version subtree 3; RlsV is grouped together to construct version subtree 4; BV is grouped together to construct version subtree 5, and so on.

[0100] The pre-defined knowledge graph also includes question nodes. A question node indicates a question, meaning that question nodes are used to manage the corresponding questions.

[0101] In the pre-defined knowledge graph, version nodes and issue nodes are connected by edges. For ease of distinction, these edges will be referred to as second-type edges. Second-type edges indicate that there is a pre-defined issue relationship between the version node and the issue node connected by the second-type edge. This pre-defined issue relationship may include introductory issue relationships and problem-solving relationships, etc.

[0102] The data is categorized into two types: "Introducing Problems" and "Solving Problems." Based on these pre-defined problem relationships, the lifecycle of a problem can be determined. For example... Figure 2 As shown, the issues managed by issue1 are introduced by version node RlsV1 and resolved by version node RlsV3. Based on this, it can be known that the lifecycle of the issues managed by issue1 is RlsV1-RlsV3.

[0103] In this embodiment of the application, the preset problem relationship may also include inherited problem relationships, and this is not limited. For example... Figure 2 In this context, RlsV2 is a software version within the lifecycle of the issue managed by issue node issue1. Therefore, RlsV2 will inherit the issues managed by issue node issue1 introduced by RlsV1, meaning there will be an inheritance relationship between issue node issue1 and RlsV2.

[0104] In this embodiment of the application, a version node may introduce one or more problems, or resolve one or more problems. Taking the preset problem relationships, which include problem introduction relationships and problem resolution relationships, as an example, if a version node introduces multiple problems, and each problem corresponds to a problem node, then the version node will have problem introduction relationships with multiple problem nodes; if a version node resolves multiple problems, and each problem corresponds to a problem node, then the version node will have problem resolution relationships with multiple problem nodes.

[0105] Based on the aforementioned pre-defined knowledge graph, the software version risk assessment method provided in this application embodiment, such as... Figure 3 As shown, the steps include the following.

[0106] Step S31: Obtain a risk assessment request. The risk assessment request includes the version number to be assessed, which corresponds to the first version node in the preset knowledge graph.

[0107] In this embodiment, the user inputs a version number to be evaluated into the electronic device, which then generates a risk assessment request based on that version number. This risk assessment request includes the version number to be evaluated. For ease of distinction and understanding, the version node corresponding to the version number to be evaluated in the preset knowledge graph is referred to as the first version node.

[0108] Step S32: Based on the first type of edges between each version node in the preset knowledge graph, determine each second version node associated with the first version node. The first type of edges indicate that there is a preset version relationship between the version nodes connected by the first type of edges.

[0109] In this embodiment of the application, a first type of edge exists between version nodes in the preset knowledge graph, such as the edges indicating inheritance, inclusion, and equivalence relationships mentioned above. Based on the first type of edge between version nodes in the preset knowledge graph, the electronic device can determine the second version node associated with the first version node according to the rules of the application scenario. The rules for determining the second version node in different application scenarios are as follows.

[0110] 1. In application scenarios where the existence of a first version node is determined but the problem remains unresolved, the rules for determining a second version node include: a) version nodes inherited by the first version node, such as the parent version node of the first version node, the parent version node of that parent version node, etc.; b) version nodes contained in the first version node, such as version node x containing version node x1, and version node x1 containing version node x11, then version node x1 and version node x11 both belong to the version nodes contained in the first version node; c) version nodes inherited by version nodes contained in the first version node; d) version nodes equivalent to the first target version node (including the first version node and the version nodes described in rules a, b, and c in application scenario 1 above); e) version nodes inherited by version nodes equivalent to the first target version node; f) version nodes contained in version nodes equivalent to the first target version node; g) version nodes inherited by version nodes contained in version nodes equivalent to the first target version node, etc.

[0111] 2. In the application scenario where it is necessary to determine whether the problem of the first version node has been resolved, the rules for determining the second version node include: a) inheriting the version node of the first version node, such as the child version node of the first version node, the child version node of the child version node, etc.; b) inheriting the version node of the version node contained in the first version node; c) inheriting the version node equivalent to the first version node; d) the version node equivalent to the second target version node (including the version nodes mentioned in rules a, b and c in the above application scenario 2); e) inheriting the version node equivalent to the second target version node, etc.

[0112] In this embodiment of the application, when determining the second version node, the application scenario may not be considered. That is, the electronic device can use all the version nodes determined in the above application scenarios 1 and 2 as the second version node based on the first type of edges between version nodes in the preset knowledge graph. Figure 2 Taking the preset knowledge graph shown as an example, if the version number to be evaluated is RlsV2, the electronic device can determine that the second version node associated with RlsV2 may include RlsV1 and RlsV3, each PdtV, PlatV and BootV contained in RlsV1, each PdtV, PlatV and BootV contained in RlsV3, and other nodes that have inheritance, inclusion or equivalence relationships with the above version nodes.

[0113] Step S33: Based on the second type of edge between each candidate version node and the problem node in the preset knowledge graph, determine the risk assessment result corresponding to the version number to be evaluated. The second type of edge indicates that there is a preset problem relationship between the version node and the problem node connected by the second type of edge. The candidate version nodes include the second version node and the first version node.

[0114] In this embodiment, the electronic device uses the second version node and the first version node as candidate version nodes. Based on the second type of edges between each candidate version node and the problem node, it determines the unresolved issues, introduced problems, and resolved problems inherited from previous software versions in the version number to be evaluated, thereby generating a risk assessment result corresponding to the version number to be evaluated. This risk assessment result can be unresolved issues existing in the version number to be evaluated, such as unresolved issues inherited from previous software versions or problems introduced by the version itself. In one embodiment, the risk assessment result may also include the software version number that resolves the problems existing in the version number to be evaluated, as well as the resolved problems, to assist users in more accurately understanding the risks of the software version and promote the application and promotion of the software version.

[0115] To facilitate the management of issue nodes and risk assessment, each issue node in the pre-defined knowledge graph can include relevant issue attributes such as "issue database", "product line", "issue description", "solution", "root cause of failure" and "responsible person". Electronic devices can add the unresolved issue attributes and the resolved issue attributes of the version number to be assessed to the risk assessment results, so that users can better understand the issue and obtain solutions.

[0116] In the technical solution provided in this application embodiment, a knowledge graph is pre-defined. This pre-defined knowledge graph includes version nodes and issue nodes. Version nodes are connected by first-type edges indicating a pre-defined version relationship, and version nodes and issue nodes are connected by second-type edges indicating a pre-defined issue relationship. Based on the version nodes, issue nodes, first-type edges, and second-type edges in the pre-defined knowledge graph, the version nodes associated with the version number to be evaluated can be accurately and comprehensively determined, and thus the issue nodes associated with the version number to be evaluated can be determined. In this way, unresolved issues in the version number to be evaluated can be identified, and it can also be determined in which software version the unresolved issue was introduced and in which software version it was subsequently resolved. Therefore, when a product has multiple software versions, the issues of the software versions can be accurately located, and the risk assessment of the software versions can be accurately and comprehensively performed.

[0117] Furthermore, in the pre-defined knowledge graph, version nodes are connected by first-type edges, which indicate the pre-defined version relationships between them. In this case, regardless of whether a software version has multiple version numbers due to diverse representation methods, or whether software version updates result in a product having multiple software version numbers, based on this pre-defined knowledge graph, the electronic device can obtain all version nodes that have the aforementioned various relationships (also known as version relationships) with the first version node. This allows it to obtain all related issues concerning the first version node, improving the comprehensiveness and accuracy of software version evaluation.

[0118] In one embodiment of this application, a software version risk assessment method is also provided, such as... Figure 4 As shown, the method includes steps S41-S43, which are the same as steps S31 and S33 described above, and will not be repeated here.

[0119] Step S42: Based on the first type of edges between each version node in the preset knowledge graph, determine the version node that has a reachable path with the first version node corresponding to the version number to be evaluated, and use it as the second version node.

[0120] In this embodiment, starting from the first version node, traversing along the first type of edges that satisfy the rules for determining the second version node associated with the first version node in step S32, one can reach another version node; therefore, a reachable path exists between these two version nodes. The reachable path in step S42 refers to the path formed by all first type edges traversed from the first version node to other version nodes, where the other version nodes are the second version nodes. The preset rules may include any one or more rules from application scenarios 1 and 2 in step S32.

[0121] by Figure 1 Taking the version tree shown as an example, starting from RlsV1, and walking along the first type edge 1 that satisfies rule b in application scenario 1 of step S32 and the first type edge 2 that satisfies rule a in application scenario 1 of step S32, we can reach PlatV2. Therefore, there is a reachable path between RlsV1 and PlatV2, which includes the first type edge 1 and the first type edge 2.

[0122] After obtaining the version number to be evaluated, the electronic device determines the version nodes that have a reachable path to the first version node based on the first type of edges between each version node in the preset knowledge graph, and designates them as second version nodes. The number of second version nodes can be one or more.

[0123] In the technical solution provided in this application embodiment, an electronic device can determine a second version node with a reachable path to the first version node based on the first type of edges in a preset knowledge graph, thereby obtaining the risk assessment result corresponding to the version number to be evaluated. This method of determining the second version node is more intuitive and concise, enabling the electronic device to quickly determine the second version node, thereby improving the efficiency and accuracy of software version risk assessment.

[0124] In one embodiment of this application, the preset problem relationship includes an introduced problem relationship and a resolved problem relationship. An introduced problem relationship indicates that a version node introduced the problem indicated by the problem node, and a resolved problem relationship indicates that the version node resolved the problem indicated by the problem node. Based on this, embodiments of this application also provide a software version risk assessment method, such as... Figure 5 As shown, the method may include steps S51-S54. Steps S51 and S52 are the same as steps S31 and S32 described above, and will not be repeated here.

[0125] Step S53: Based on the second type of edges between each candidate version node and the question node in the preset knowledge graph, determine the candidate question node. The candidate question node and the candidate version node have a second type of edge indicating the relationship of introducing the question, and the candidate question node and the candidate version node do not have a second type of edge indicating the relationship of solving the problem.

[0126] In this embodiment of the application, the second type of edge indicates that there is a preset problem relationship between the version node and the problem node connected by the second type of edge. The preset problem relationship may include a problem-introducing relationship and a problem-solving relationship. That is, there may be a problem-introducing relationship and a problem-solving relationship between each candidate version node and the problem node connected by the second type of edge.

[0127] The electronic device can use the second version node and the first version node determined in application scenario 1 in step S32 above as candidate version nodes. From the multiple problem nodes connected by the second type of edge to these candidate version nodes, it can identify the problem nodes that have a problem-introducing relationship with each candidate version node but no problem-solving relationship, and use these problem nodes as candidate problem nodes.

[0128] Step S54: Based on the issues indicated by the candidate issue nodes, generate the risk assessment results corresponding to the version number to be evaluated.

[0129] In this embodiment, the issues indicated by the candidate issue nodes are the unresolved issues currently existing in the version number to be evaluated. The electronic device can obtain the issues indicated by each candidate issue node and generate a risk assessment result corresponding to the version number to be evaluated based on these issues.

[0130] In one example, after obtaining the issues indicated by each candidate issue node, the electronic device can directly use these issues as the risk assessment results corresponding to the version number to be evaluated.

[0131] In another example, the electronic device can pre-set the correspondence between the number of issues and risk levels. Based on the total number of issues indicated by the candidate issue nodes and the pre-set correspondence between the number of issues and risk levels, the electronic device determines the target risk level corresponding to the total number of issues indicated by the candidate issue nodes, and generates a risk assessment result corresponding to the version number to be evaluated from the target risk level.

[0132] In this embodiment of the application, the electronic device may also generate risk assessment results through other methods, and the risk assessment results may also include other information, which is not limited thereto.

[0133] In the technical solution provided in this application embodiment, the electronic device can acquire candidate problem nodes that have a problem-introducing relationship with candidate version nodes but no problem-solving relationship, and then determine the risk assessment result corresponding to the version number to be evaluated. This allows the electronic device to filter problem nodes, removing problem nodes that have a problem-solving relationship with candidate version nodes, and retaining only problem nodes corresponding to the unresolved problems of the current first version node, greatly reducing the number of identified candidate problem nodes, reducing the consumption of computing resources, and improving the efficiency of software version risk assessment.

[0134] In one embodiment of this application, a software version risk assessment method is also provided, such as... Figure 6 As shown, the method may include steps S61-S63.

[0135] Step S61: Obtain the first query request. The first query request includes the version number to be evaluated and the query question. The query question corresponds to the target question node in the preset knowledge graph.

[0136] In this embodiment, each question node in the preset knowledge graph indicates one or more questions. The target question node represents the question to be queried: the question to be queried is one of the one or more questions indicated by the target question node. The electronic device obtains a first query request containing an evaluation version number and the question to be queried.

[0137] Step S62: From the preset knowledge graph, identify the third version node that has a second type of edge with the target question node.

[0138] The pre-defined knowledge graph contains version nodes that have a problem-introducing relationship with the target problem node, and may also contain version nodes that have a problem-solving relationship with the target problem node. These version nodes all have a second type of edge with the target problem node. For ease of distinction and understanding, these version nodes that have a second type of edge with the target problem node are called third version nodes.

[0139] After receiving the first query request, the electronic device determines the third version node from the preset knowledge graph that has a second type of edge with the target question node.

[0140] Step S63: Based on the position of the third version node in the preset knowledge graph and the position of the first version node corresponding to the version number to be evaluated, generate the problem evaluation result. The problem evaluation result indicates whether the problem to be queried is a problem existing in the version number to be evaluated.

[0141] Based on a pre-defined knowledge graph, the electronic device can determine the location of the version node corresponding to the version number to be evaluated. The electronic device can then compare the location of the version node corresponding to the version number to be evaluated with the location of a third-party version node to determine whether the query question is a problem existing in the version number to be evaluated, and generate a problem evaluation result.

[0142] like Figure 2 As shown, taking issue1 as the target issue node as an example, issue1 has an issue-introducing relationship with version node RlsV1, and issue1 has a problem-solving relationship with version node RlsV3. Therefore, both RlsV1 and RlsV3 can be considered as third version nodes. If the version node corresponding to the version number to be evaluated is RlsV2, then based on... Figure 2 The positions of RlsV1, RlsV3, and RlsV2 shown indicate that RlsV2 inherits from RlsV1, and RlsV3 inherits from RlsV2. Therefore, it can be determined that RlsV2 inherits the issues managed by the issue node `issue1` introduced by RlsV1. Only RlsV3 resolves the issue node `issue1` introduced by RlsV1. The issues managed by issue node `issue1` are problems existing in RlsV2. The electronic device generates an evaluation result indicating that the issues managed by issue node `issue1` are problems existing in RlsV2. If the version node corresponding to the version number to be evaluated is RlsV3, then based on... Figure 2 The positions of RlsV1 and RlsV3 shown indicate that RlsV3 resolves the issue managed by issue1 introduced by RlsV1. The issue managed by issue1 is not a problem existing in RlsV3, that is, RlsV3 has resolved the issue indicated by issue1. The electronic device generates an issue evaluation result indicating that issue1 is not a problem existing in RlsV3.

[0143] To facilitate understanding of the product's status, in this embodiment, the problem assessment result may further include an indication of which version node introduced the problem and which version node resolved it. This allows users to adjust the product's software version promptly and appropriately, without wasting excessive manpower resolving issues already addressed in subsequent software versions.

[0144] In the technical solution provided in this application, the electronic device determines a third version node with a second type of edge between itself and the target problem node in a preset knowledge graph corresponding to the query problem, thereby determining whether the query problem exists in the version number to be evaluated. This allows the electronic device to quickly locate the query problem to determine whether the problem exists in the version number to be evaluated. This improves the efficiency of problem location, thereby enhancing the efficiency of the software version risk assessment method and reducing the consumption of human and material resources.

[0145] In one embodiment of this application, a software version risk assessment method is also provided, such as... Figure 7 As shown, the method may include steps S71-S72.

[0146] Step S71: Obtain the second query request, which includes the version knowledge to be queried.

[0147] In this embodiment, the version knowledge to be queried may include one or more of the following: the correspondence between version nodes, version tree information, the software version number installed at the time the problem occurred, and the relationship between software version numbers. The electronic device can obtain a second query request containing the version knowledge to be queried.

[0148] Step S72: Based on the layout of each version node in the preset knowledge graph, generate query results for the version knowledge to be queried.

[0149] Electronic devices can query the knowledge of the version to be queried based on the layout of the version nodes corresponding to each software version number in a preset knowledge graph, and generate query results for the knowledge of the version to be queried.

[0150] For example, the version knowledge to be queried is the correspondence between version nodes. The electronic device, following natural language syntax, uses the first-type edges between the version nodes in a pre-defined knowledge graph to generate the query results for the version knowledge to be queried. Figure 1 As shown, when the version knowledge to be queried is the correspondence between RlsV1 and PlatV5, from... Figure 1 As can be seen from this, RlsV1 contains PlatV1, and PlatV1 is inherited by PlatV5. Based on this, the query result generated by the electronic device can be: PlatV5 is a sub-version node of PlatV1 contained in RlsV1.

[0151] For example, the version information to be queried might be the software version number installed when the problem occurred. The electronic device can obtain the issue node indicating the problem, identify version nodes that have both an issue-introducing relationship and a problem-solving relationship with that issue node, and then generate query results for the version information to be queried. For example... Figure 2As shown, when the version knowledge to be queried is Problem 1, and Problem 1 is a problem managed by the issue node issue1, there is an issue-introducing relationship between issue node issue1 and RlsV1, and an issue-solving relationship between issue node issue1 and RlsV3. Based on this, the query result generated by the electronic device can be: RlsV1 introduced Problem 1, and RlsV3 solved Problem 1.

[0152] For information on other versions, please refer to the above-mentioned version node correspondence and the query for the software version number installed when the problem occurred; these will not be repeated here.

[0153] In the technical solution provided in this application embodiment, the electronic device can query version knowledge in the preset knowledge graph, which increases the applicability of the software version risk assessment method. When the user needs to understand the preset knowledge graph, the user can query the version knowledge in the preset knowledge graph at any time, which greatly facilitates the user's understanding of the preset knowledge graph.

[0154] Corresponding to the above-mentioned software version risk assessment method, this application provides a software version risk assessment device, such as... Figure 8 As shown, the device includes:

[0155] The first acquisition unit 81 is used to acquire a risk assessment request. The risk assessment request includes the version number to be assessed, which corresponds to the first version node in the preset knowledge graph.

[0156] The first determining unit 82 is used to determine each second version node associated with the first version node based on the first type of edge between each version node in the preset knowledge graph. The first type of edge indicates that there is a preset version relationship between the version nodes connected by the first type of edge.

[0157] The second determining unit 83 is used to determine the risk assessment result corresponding to the version number to be evaluated based on the second type of edge between each candidate version node and the problem node in the preset knowledge graph. The second type of edge indicates that there is a preset problem relationship between the version node and the problem node connected by the second type of edge. The candidate version nodes include the second version node and the first version node.

[0158] In one embodiment, the first determining unit 82 may specifically be used for:

[0159] Based on the first type of edges between each version node in the preset knowledge graph, the version node with a reachable path to the first version node corresponding to the version number to be evaluated is identified as the second version node.

[0160] In one embodiment, the preset version relationship includes one or more of inheritance, inclusion, and equivalence relationships;

[0161] The reachable path can be: starting from the first version node, the path formed by all the first type edges that the first type edges that the first version nodes traverse to other version nodes satisfy the preset rules are used; the other version nodes are the second version nodes.

[0162] The preset rules include a first category of rules to determine unresolved issues in the first version node, and / or a second category of rules to determine whether issues in the first version node have been resolved;

[0163] The first category of rules includes at least one of the following rules:

[0164] Rule 1: Version nodes inherited by the first version node;

[0165] Rule 2, the version nodes included in the first version node;

[0166] Rule 3: Version nodes inherited by version nodes contained in the first version node;

[0167] Rule 4: Version nodes equivalent to the first target version node, which includes the first version node, version nodes that satisfy Rule 1, version nodes that satisfy Rule 2, and version nodes that satisfy Rule 3.

[0168] Rule 5: A version node that is inherited by a version node that is equivalent to the first target version node;

[0169] Rule 6: Version nodes contained in a version node that is equivalent to the first target version node;

[0170] Rule 7: A version node that is inherited by a version node contained in a version node that is equivalent to the first target version node;

[0171] The second category of rules includes at least one of the following rules:

[0172] Rule 8: Inherit the version node of the first version node;

[0173] Rule 9: Inherit the version node of the version node contained in the first version node;

[0174] Rule 10: Inherit the version node that is equivalent to the first version node;

[0175] Rule 11: Version nodes equivalent to the second target version node, which includes version nodes that satisfy Rule 8, version nodes that satisfy Rule 9, and version nodes that satisfy Rule 10.

[0176] Rule 12: Inherit the version node of the version node that is equivalent to the second target version node.

[0177] In one embodiment, the preset problem relationship may include introducing a problem relationship and resolving a problem relationship;

[0178] The second determining unit 83 can be specifically used for:

[0179] Based on the second type of edges between each candidate version node and the question node in the preset knowledge graph, candidate question nodes are determined. There are second type edges between the candidate question node and the candidate version node that indicate the relationship of introducing a question, and there are no second type edges between the candidate question node and the candidate version node that indicate the relationship of solving a problem.

[0180] Based on the issues indicated by the candidate issue nodes, generate risk assessment results corresponding to the version number to be evaluated.

[0181] In one embodiment, the software version risk assessment device may further include:

[0182] The second acquisition unit is used to acquire the first query request, which includes the version number to be evaluated and the query question, and the query question corresponds to the target question node in the preset knowledge graph.

[0183] The third determining unit is used to determine, from the preset knowledge graph, the third version node that has a second type edge with the target question node;

[0184] The first generation unit is used to generate a problem evaluation result based on the position of the third version node in the preset knowledge graph and the position of the first version node corresponding to the version number to be evaluated. The problem evaluation result indicates whether the problem to be queried is a problem existing in the version number to be evaluated.

[0185] In one embodiment, the software version risk assessment device may further include:

[0186] The third acquisition unit is used to acquire the second query request, which includes the version knowledge to be queried.

[0187] The second generation unit is used to generate query results for the version knowledge to be queried based on the layout of each version node in the preset knowledge graph.

[0188] In the technical solution provided in this application embodiment, a pre-defined knowledge graph is established. This pre-defined knowledge graph includes version nodes and issue nodes. Version nodes are connected by first-type edges indicating a pre-defined version relationship, and version nodes and issue nodes are connected by second-type edges indicating a pre-defined issue relationship. Based on the version nodes, issue nodes, first-type edges, and second-type edges in the pre-defined knowledge graph, the version nodes associated with the version number to be evaluated can be accurately and comprehensively determined, and thus the issue nodes associated with the version number to be evaluated can be determined. In this way, known issues existing in the version number to be evaluated can be identified, and it can also be determined in which software version the known issue was introduced and in which software version it was subsequently resolved. Therefore, risk assessment results can be accurately and comprehensively generated without expending manpower and resources to locate the problem, thus solving the problem of wasted manpower and resources caused by problem location when a product has multiple software versions.

[0189] Furthermore, in the pre-defined knowledge graph, version nodes are connected by first-type edges, which indicate the pre-defined version relationships between them. In this case, regardless of whether a software version has multiple version numbers due to diverse representation methods, or whether software version updates result in a product having multiple software version numbers, based on this pre-defined knowledge graph, the electronic device can obtain all version nodes that have the aforementioned various relationships (also known as version relationships) with the first version node, thus obtaining all related issues for the first version node and improving the comprehensiveness and accuracy of software version evaluation.

[0190] Corresponding to the above-mentioned software version risk assessment method, this application embodiment also provides an electronic device, such as... Figure 9 As shown, it includes a processor 91 and a machine-readable storage medium 92, the machine-readable storage medium 92 storing machine-executable instructions that can be executed by the processor 91, the processor 91 being prompted by the machine-executable instructions to implement the steps of any of the above software version risk assessment methods.

[0191] Machine-readable storage media may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. The memory may also be at least one storage device located remotely from the aforementioned processor.

[0192] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0193] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above-described software version risk assessment methods.

[0194] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform the steps of any of the software version risk assessment methods described in the above embodiments.

[0195] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0196] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0197] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, electronic devices, storage media, and computer program products are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0198] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A software version risk assessment method, characterized by, The method comprises: obtaining a risk assessment request, the risk assessment request comprising a version number to be evaluated, the version number to be evaluated corresponding to a first version node in a preset knowledge graph; determining, based on a first type of edge between each version node in the preset knowledge graph, a version node existing a reachable path with the first version node corresponding to the version number to be evaluated as a second version node, the first type of edge indicating that a preset version relationship exists between version nodes connected by the first type of edge; determining a risk assessment result corresponding to the version number to be evaluated according to a second type of edge between each candidate version node and a problem node in the preset knowledge graph, the second type of edge indicating that a preset problem relationship exists between version nodes and problem nodes connected by the second type of edge, the candidate version node comprising the second version node and the first version node; the preset version relationship comprises one or more of inheritance relationship, inclusion relationship and equivalence relationship; the reachable path is a path formed by all first type of edges through which the first version node is walked to other version nodes along the first type of edges satisfying a preset rule, the other version node being a second version node; the preset rule comprises a first type of rule for determining an unresolved problem existing in the first version node, and / or a second type of rule for determining whether a problem existing in the first version node is solved; the first type of rule comprises at least one of the following rules: rule one, a version node inherited by the first version node; rule two, a version node included by the first version node; rule three, a version node inherited by a version node included by the first version node; rule four, a version node equivalent to a first target version node, the first target version node comprising the first version node, a version node satisfying the rule one, a version node satisfying the rule two and a version node satisfying the rule three; rule five, a version node inherited by a version node equivalent to the first target version node; rule six, a version node included by a version node equivalent to the first target version node; rule seven, a version node inherited by a version node included by a version node equivalent to the first target version node; the second type of rule comprises at least one of the following rules: rule eight, a version node inheriting the first version node; rule nine, a version node inheriting a version node included by the first version node; rule ten, a version node inheriting a version node equivalent to the first version node; rule eleven, a version node equivalent to a second target version node, the second target version node comprising a version node satisfying the rule eight, a version node satisfying the rule nine and a version node satisfying the rule ten; rule twelve, a version node inheriting a version node equivalent to the second target version node.

2. The method of claim 1, wherein, the preset problem relationship comprises an introduced problem relationship and a solved problem relationship; the step of determining a risk assessment result corresponding to the version number to be evaluated according to a second type of edge between each candidate version node and a problem node in the preset knowledge graph comprises: determine a candidate question node based on the second type of edges between each candidate version node and a question node in the preset knowledge graph, the candidate question node and the candidate version node have a second type of edge indicating an introducing problem relationship, and the candidate question node and the candidate version node do not have a second type of edge indicating a problem solving relationship; generate a risk assessment result corresponding to the version number to be evaluated based on the problem indicated by the candidate question node.

3. The method of claim 1, wherein, The method further comprises: obtaining a first query request, the first query request comprising the version number to be evaluated and a query question, the query question corresponding to a target question node in the preset knowledge graph; determining a third version node having a second type of edge with the target question node from the preset knowledge graph; generating a question assessment result based on the position of the third version node in the preset knowledge graph and the position of the first version node corresponding to the version number to be evaluated, the question assessment result indicating whether the query question is a problem existing in the version number to be evaluated.

4. The method of claim 1, wherein, The method further comprises: obtaining a second query request, the second query request comprising query version knowledge; generating a query result of the query version knowledge based on the layout of each version node in the preset knowledge graph.

5. A software version risk assessment apparatus characterized by comprising: The device comprises: a first obtaining unit configured to obtain a risk assessment request, the risk assessment request comprising a version number to be evaluated, the version number to be evaluated corresponding to a first version node in a preset knowledge graph; a first determining unit configured to determine, based on first type of edges between each version node in the preset knowledge graph, a version node having an accessible path with the first version node corresponding to the version number to be evaluated as a second version node, the first type of edge indicating that the version nodes connected by the first type of edge have a preset version relationship; a second determining unit configured to determine a risk assessment result corresponding to the version number to be evaluated according to a second type of edge between each candidate version node and a question node in the preset knowledge graph, the second type of edge indicating that the version nodes and the question node connected by the second type of edge have a preset problem relationship, the candidate version node comprising the second version node and the first version node; the preset version relationship comprises one or more of inheritance relationship, inclusion relationship and equivalence relationship; the accessible path is a path formed by all first type of edges traversed from the first version node as a starting point to other version nodes as second version nodes along the first type of edges satisfying a preset rule; the preset rule comprises a first type of rule for determining an unsolved problem existing in the first version node, and / or a second type of rule for determining whether the problem existing in the first version node is solved; The first type of rules includes at least one of the following rules: rule one, a version node inherited by the first version node; rule two, a version node contained in the first version node; rule three, a version node inherited by a version node contained in the first version node; rule four, a version node equivalent to a first target version node, the first target version node including the first version node, a version node satisfying the rule one, a version node satisfying the rule two, and a version node satisfying the rule three; rule five, a version node inherited by a version node equivalent to the first target version node; rule six, a version node contained in a version node equivalent to the first target version node; rule seven, a version node inherited by a version node contained in a version node equivalent to the first target version node; The second type of rules includes at least one of the following rules: rule eight, a version node inherited by the first version node; rule nine, a version node inherited by a version node contained in the first version node; rule ten, a version node inherited by a version node equivalent to the first version node; rule eleven, a version node equivalent to a second target version node, the second target version node including a version node satisfying the rule eight, a version node satisfying the rule nine, and a version node satisfying the rule ten; rule twelve, a version node inherited by a version node equivalent to the second target version node.

6. The apparatus of claim 5, wherein, The preset problem relationship includes an introduction problem relationship and a solution problem relationship. The second determination unit is specifically configured to: determine a candidate problem node based on the second type of edges between each candidate version node and a problem node in the preset knowledge graph, the candidate problem node and the candidate version node having a second type of edge indicating an introduction problem relationship, and the candidate problem node and the candidate version node not having a second type of edge indicating a solution problem relationship; generate a risk assessment result corresponding to the to-be-evaluated version number based on a problem indicated by the candidate problem node.

7. The apparatus of claim 5, wherein, The device further includes: a second acquisition unit configured to acquire a first query request, the first query request including the to-be-evaluated version number and a to-be-queried problem, the to-be-queried problem corresponding to a target problem node in the preset knowledge graph; a third determination unit configured to determine, from the preset knowledge graph, a third version node having a second type of edge with the target problem node; a first generation unit configured to generate a problem assessment result based on a position of the third version node in the preset knowledge graph and a position of the first version node corresponding to the to-be-evaluated version number, the problem assessment result indicating whether the to-be-queried problem is a problem existing in the to-be-evaluated version number.

8. The apparatus of claim 5, wherein, The device further includes: a third acquisition unit configured to acquire a second query request, the second query request including to-be-queried version knowledge; a second generation unit configured to generate a query result of the to-be-queried version knowledge based on a layout of each version node in the preset knowledge graph.

9. An electronic device, comprising: A computer program product comprising a processor and a machine readable storage medium storing machine executable instructions executable by the processor, the processor caused by the machine executable instructions to implement the method steps of any of claims 1-4.

10. A computer-readable storage medium, characterized in that, A computer program product comprising a processor and a machine readable storage medium storing machine executable instructions executable by the processor, the processor caused by the machine executable instructions to implement the method steps of any of claims 1-4.

Images