WO2022068190A1 - 版本验证方法、装置、电子设备及存储介质 - Google Patents

版本验证方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
WO2022068190A1
WO2022068190A1 PCT/CN2021/090382 CN2021090382W WO2022068190A1 WO 2022068190 A1 WO2022068190 A1 WO 2022068190A1 CN 2021090382 W CN2021090382 W CN 2021090382W WO 2022068190 A1 WO2022068190 A1 WO 2022068190A1
Authority
WO
WIPO (PCT)
Prior art keywords
version
information
verified
version number
code
Prior art date
Application number
PCT/CN2021/090382
Other languages
English (en)
French (fr)
Inventor
吴敏
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2022068190A1 publication Critical patent/WO2022068190A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version

Definitions

  • the present application relates to the technical field of data processing, and in particular, to a version verification method, apparatus, electronic device and storage medium.
  • the released version In order to ensure the smooth release and application of the version, the released version needs to be verified to a certain extent before the version is released.
  • the inventor realizes that the current version verification needs to be actively promoted by the person in charge of development, because some developers are responsible for People are not familiar with the whole process of version verification, which reduces the verification efficiency.
  • a first aspect of the present application provides a version verification method, the version verification method comprising:
  • a verification result of the to-be-verified version number is determined based on the execution result.
  • a second aspect of the present application provides an electronic device, the electronic device includes a processor and a memory, the processor is configured to execute at least one computer-readable instruction stored in the memory to implement the following steps:
  • a verification result of the to-be-verified version number is determined based on the execution result.
  • a third aspect of the present application provides a computer-readable storage medium on which at least one computer-readable instruction is stored, and the at least one computer-readable instruction is executed by a processor to implement the following steps:
  • a verification result of the to-be-verified version number is determined based on the execution result.
  • a fourth aspect of the present application provides a version verification device, the version verification includes:
  • a determining unit configured to determine the system to be verified and the version number to be verified according to the version verification request when a version verification request is received;
  • an obtaining unit configured to obtain version information and vulnerability information on the system to be verified according to the version number to be verified;
  • a verification unit configured to verify the story card on the system to be verified based on the version information and the vulnerability information
  • the obtaining unit is further configured to obtain a version number corresponding to the story card as a code version number when the story card passes the verification;
  • a detection unit for detecting whether the version number to be verified is consistent with the code version number
  • an extraction unit configured to extract a version script corresponding to the code version number when it is detected that the to-be-verified version number is consistent with the code version number, and obtain an execution result of the version script
  • the determining unit is further configured to determine a verification result of the to-be-verified version number based on the execution result.
  • the application can accurately determine the system to be verified and the version number to be verified through the version verification request, so as to avoid inaccurate verification results due to errors in the verified system and version number, and at the same time when verifying.
  • the vulnerability information is considered in the story card, which can avoid inaccurate verification of the story card caused by the existence of the vulnerability information on the system to be verified, ensure the verification accuracy of the story card, and can be used in all situations.
  • the code version number is obtained in time, which ensures real-time performance.
  • FIG. 1 is a flowchart of an embodiment of a version verification method of the present application.
  • FIG. 1a is a flowchart of an embodiment of the present application for determining the system to be verified and the version number to be verified.
  • FIG. 1b is a flowchart of an embodiment of the present application for obtaining version information and vulnerability information.
  • FIG. 1c is a flow chart of an embodiment of the present application for verifying a story card.
  • Fig. 1d is a flow chart of an embodiment of the present application for determining a target card.
  • FIG. 1e is a flowchart of another embodiment of the version verification method of the present application.
  • FIG. 1f is a flowchart of an embodiment of the present application for detecting whether the version number to be verified is consistent with the code version number.
  • FIG. 1g is a flow chart of an embodiment of an extract version script of the present application.
  • FIG. 1h is a flowchart of another embodiment of the version verification method of the present application.
  • FIG. 2 is a functional block diagram of an embodiment of the version verification apparatus of the present application.
  • FIG. 3 is a schematic structural diagram of an electronic device implementing an embodiment of a version verification method of the present application.
  • FIG. 1 it is a flowchart of an embodiment of the version verification method of the present application. According to different requirements, the order of steps in this flowchart can be changed, and some steps can be omitted.
  • the version verification method is applied in a smart city, and the version verification method is applied in one or more electronic devices, and the electronic device is a device that can automatically perform numerical calculations and/or according to pre-set or stored instructions.
  • Information processing equipment its hardware includes but is not limited to microprocessors, application specific integrated circuits (ASICs), programmable gate arrays (Field-Programmable Gate Arrays, FPGAs), digital processors (Digital Signal Processors, DSPs) ), embedded devices, etc.
  • the electronic device can be any electronic product that can interact with the user, such as a personal computer, a tablet computer, a smart phone, a personal digital assistant (PDA), a game console, an interactive network television ( Internet Protocol Television, IPTV), smart wearable devices, etc.
  • a personal computer a tablet computer
  • a smart phone a personal digital assistant (PDA)
  • PDA personal digital assistant
  • IPTV interactive network television
  • smart wearable devices etc.
  • the electronic equipment may also include network equipment and/or user equipment.
  • the network device includes, but is not limited to, a single network server, a server group formed by multiple network servers, or a cloud formed by a large number of hosts or network servers based on cloud computing (Cloud Computing).
  • the network where the electronic device is located includes, but is not limited to, the Internet, a wide area network, a metropolitan area network, a local area network, a virtual private network (Virtual Private Network, VPN), and the like.
  • VPN Virtual Private Network
  • the information carried in the version verification request includes, but is not limited to: a first label, a system identifier, a second label, the version number to be verified, and the like.
  • the version verification request may be triggered by the user responsible for the release of the version, or may be automatically triggered after the development of the system version is completed, which is not limited in this application.
  • the system to be verified refers to a system requiring version verification
  • the version number to be verified refers to the code of the version that needs to be verified.
  • the version number to be verified may be v1.2.
  • FIG. 1a is a flowchart of an embodiment of the present application for determining the system to be verified and the version number to be verified.
  • the electronic device determining the system to be verified and the version number to be verified according to the version verification request includes:
  • the first label and the second label refer to predefined labels, for example, the first label may be ID, and the second label may be NUM.
  • the mapping relationship between the first label and the system identifier may be ID: 2356; the mapping relationship between the second label and the version number to be verified may be NUM: V1.2.
  • the parsing efficiency can be improved.
  • the system to be verified can be accurately determined through the mapping relationship between the first label and the system identifier.
  • the mapping relationship between the label and the version number to be verified can accurately determine the version number to be verified.
  • the system to be verified and the version number to be verified can be accurately determined through the version verification request, so as to avoid inaccurate verification results due to errors in the verified system and version number.
  • S11 Acquire version information and vulnerability information on the system to be verified according to the version number to be verified.
  • the version information includes story cards, detailed descriptions, and acceptance information.
  • the story card includes three elements: system, task and goal.
  • the story card could be: As a bookstore keeper, I want to add a new book to the library so that book buyers can refer to this book.
  • the acceptance information may include: specific attributes, functional acceptance conditions, non-functional acceptance conditions, and the like.
  • the vulnerability information includes, but is not limited to: errors discovered by the user when developing the version number of the system to be verified, results caused by the errors, and the like.
  • FIG. 1b is a flowchart of an embodiment of the present application for acquiring version information and vulnerability information.
  • the electronic device acquiring the version information and vulnerability information on the system to be verified according to the version number to be verified includes:
  • S111 obtain creators of all files on the target path, and determine the positions of the creators
  • S113 Acquire information on the first file as the version information, and acquire information on the second file as the vulnerability information.
  • the configuration library stores the mapping relationship between multiple systems, multiple version numbers and multiple paths.
  • the storage system, version number and path in the configuration library may be in the form: system 228-V1.3-path 1.
  • the creator of the first job is responsible for the recording and storage of the version information
  • the creator of the second job is responsible for the recording and storage of the vulnerability information
  • the version information and the vulnerability information are created by users with different positions, the version information and the vulnerability information can be accurately acquired by identifying the position of the file creator.
  • the information of the story card includes: new functions developed for the system to be verified, and the like.
  • acceptance information refers to standard conditions for determining completion of the story card.
  • Fig. 1c is a flow chart of an embodiment of the present application for verifying a story card.
  • the electronic device verifying the story card on the system to be verified based on the version information and the vulnerability information includes:
  • S120 determine from the case set a target card whose similarity to the story card is greater than the configuration value, and obtain result information corresponding to the target card from the case set;
  • the case centrally stores multiple cards and execution results corresponding to the multiple cards.
  • the target card refers to a card whose similarity to the story card is greater than the configuration value, and the result information refers to the result obtained after completing the task in the target card.
  • FIG. 1d is a flowchart of an embodiment of the present application for determining a target card.
  • the electronic device determines from the case set, based on the distance formula, the target card whose similarity to the story card is greater than the configuration value includes:
  • S1202 Determine a card with a similarity greater than the configuration value as the target card.
  • the vulnerability information is considered when verifying the story card, so that the existence of the vulnerability information on the system to be verified can prevent the verification of the story card from being inaccurate and ensure the verification of the story card. Accuracy.
  • the story cards corresponding to the version numbers are also different accordingly.
  • the obtaining the version number corresponding to the story card as the code version number includes one or a combination of the following ways:
  • the electronic device determines the card library of the system to be verified, obtains an identification code corresponding to the story card from the card library, and determines the code version number according to the identification code;
  • the card library stores the correspondence between story cards and identification codes.
  • the electronic device uses the identification code to traverse the storage library, and determines the code version number corresponding to the identification code that has been traversed.
  • the code version number can be accurately determined.
  • the electronic device identifies the version number on the story card, and determines the latest version number from the identified version numbers as the code version number.
  • the identified version numbers are sorted in descending order to obtain a queue, and the first version number arranged in the queue is determined as the latest version number.
  • the version numbers on the story card are V1.0 and V1.1
  • the latest version number is determined to be V1.1 from V1.0 and V1.1
  • V1.1 is used as the code version number.
  • the code version number can be acquired in time after the story card is verified, ensuring real-time performance.
  • FIG. 1e is a flowchart of another embodiment of the version verification method of the present application. This embodiment is obtained by improving the version verification method shown in FIG. 1a to FIG. 1d.
  • the method further includes:
  • the electronic device determines the request number of the version verification request, and determines the number interval in which each level is located, and determines the target number interval in which the request number is located according to the number interval in which each level is located. The level corresponding to the target number interval is determined as the request level.
  • a corresponding transmission mode is set for each level.
  • the request level is level one
  • the sending method is email
  • the request level is level two
  • the sending method is SMS
  • the request level is level three
  • the sending method is telephone.
  • the appropriate sending method to send the prompt information can be determined by requesting the level.
  • the prompt information can be generated in time to ensure that the corresponding contact person The prompt information can be received in time.
  • FIG. 1f is a flowchart of an embodiment of the present application for detecting whether the version number to be verified is consistent with the code version number.
  • the electronic device detecting whether the to-be-verified version number is consistent with the code version number includes:
  • the detection result can be accurately determined.
  • the version script refers to script code for implementing a new story card.
  • the execution result refers to a result obtained after executing the version script, and the execution result includes: error information and script results when an error occurs when executing the version script.
  • FIG. 1g is a flowchart of an embodiment of the extract version script of the present application.
  • extracting, by the electronic device, a version script corresponding to the code version number includes:
  • the revision mode will be used to record the code in the system code, so the version script can be obtained accurately and completely.
  • the version script Since the version script has a revision mode in the system code, the version script can be quickly acquired through the above-mentioned implementation manner.
  • the above verification results can also be stored in a node of a blockchain.
  • the verification result includes two results: the version is incorrect and the version is correct.
  • FIG. 1h is a flowchart of another embodiment of the version verification method of the present application. This embodiment is obtained by improving on the basis of the version verification methods shown in FIG. 1 to FIG. 1g. As shown in FIG. 1h, in step S16 shown in FIG. 1, this embodiment determines the to-be-verified based on the execution result. After the verification result of the version number, the description may further include the following steps:
  • S161 obtain a log table of the initiating terminal, and obtain a login account corresponding to the initiation time from the log table;
  • the account that initiates the version verification request can be accurately determined, and the corresponding contact person can be notified of the verification result in a timely and accurate manner after the verification result is obtained.
  • the present application does not require the coordinator to advance the version verification process, which reduces the cost of communication between the coordinators and improves the verification efficiency.
  • the coordinator does not need to interfere in the version verification, it is possible to reduce the need for human effort.
  • the verification error caused by the interference thereby improving the verification accuracy.
  • the application can accurately determine the system to be verified and the version number to be verified through the version verification request, so as to avoid inaccurate verification results due to errors in the verified system and version number, and at the same time when verifying.
  • the vulnerability information is considered in the story card, which can avoid inaccurate verification of the story card caused by the existence of the vulnerability information on the system to be verified, ensure the verification accuracy of the story card, and can be used in all situations.
  • the code version number is obtained in time, which ensures real-time performance.
  • the version verification apparatus 11 includes a determination unit 110 , an acquisition unit 111 , a verification unit 112 , a detection unit 113 , an extraction unit 114 , a generation unit 115 and a transmission unit 116 .
  • the modules/units referred to in this application refer to a series of computer program segments that can be executed by the processor 13 and can perform fixed functions, and are stored in the memory 12 . In this embodiment, the functions of each module/unit will be described in detail in subsequent embodiments.
  • the determining unit 110 determines the system to be verified and the version number to be verified according to the version verification request.
  • the information carried in the version verification request includes, but is not limited to: a first label, a system identifier, a second label, the version number to be verified, and the like.
  • the version verification request may be triggered by the user responsible for the release of the version, or may be automatically triggered after the development of the system version is completed, which is not limited in this application.
  • the system to be verified refers to a system requiring version verification
  • the version number to be verified refers to the code of the version that needs to be verified.
  • the version number to be verified may be v1.2.
  • the determining unit 110 determining the system to be verified and the version number to be verified according to the version verification request includes:
  • the system to be verified is determined according to the system identifier.
  • the first label and the second label refer to predefined labels, for example, the first label may be ID, and the second label may be NUM.
  • the mapping relationship between the first label and the system identifier may be ID: 2356; the mapping relationship between the second label and the version number to be verified may be NUM: V1.2.
  • the parsing efficiency can be improved.
  • the system to be verified can be accurately determined through the mapping relationship between the first label and the system identifier.
  • the mapping relationship between the label and the version number to be verified can accurately determine the version number to be verified.
  • the system to be verified and the version number to be verified can be accurately determined through the version verification request, so as to avoid inaccurate verification results due to errors in the verified system and version number.
  • the acquiring unit 111 acquires version information and vulnerability information on the system to be verified according to the version number to be verified.
  • the version information includes story cards, detailed descriptions, and acceptance information.
  • the story card includes three elements: system, task and goal.
  • the story card could be: As a bookstore keeper, I want to add a new book to the library so that book buyers can refer to this book.
  • the acceptance information may include: specific attributes, functional acceptance conditions, non-functional acceptance conditions, and the like.
  • the vulnerability information includes, but is not limited to: errors discovered by the user when developing the version number of the system to be verified, results caused by the errors, and the like.
  • the acquiring unit 111 acquiring the version information and vulnerability information on the system to be verified according to the version number to be verified includes:
  • the information on the first file is acquired as the version information, and the information on the second file is acquired as the vulnerability information.
  • the configuration library stores the mapping relationship between multiple systems, multiple version numbers and multiple paths.
  • the format of the storage system, version number and path in the configuration library may be: system 228-V1.3-path 1.
  • the creator of the first job is responsible for the recording and storage of the version information
  • the creator of the second job is responsible for the recording and storage of the vulnerability information
  • the version information and the vulnerability information are created by users with different positions, the version information and the vulnerability information can be accurately acquired by identifying the position of the file creator.
  • the verification unit 112 verifies the story card on the system to be verified based on the version information and the vulnerability information.
  • the information of the story card includes: new functions developed for the system to be verified, and the like.
  • acceptance information refers to standard conditions for determining completion of the story card.
  • the verification unit 112 verifying the story card on the system to be verified based on the version information and the vulnerability information includes:
  • the result information is the same as the acceptance information, or the result information is the same as the vulnerability information, it is determined that the story card passes the verification.
  • the case centrally stores multiple cards and execution results corresponding to the multiple cards.
  • the target card refers to a card whose similarity to the story card is greater than the configuration value, and the result information refers to the result obtained after completing the task in the target card.
  • the verification unit 112 determines, from the case set, the target card whose similarity to the story card is greater than the configured value includes:
  • a card whose similarity is greater than the configuration value is determined as the target card.
  • the vulnerability information is considered when verifying the story card, so that the existence of the vulnerability information on the system to be verified can prevent the verification of the story card from being inaccurate and ensure the verification of the story card. Accuracy.
  • the obtaining unit 111 obtains the version number corresponding to the story card as the code version number.
  • the obtaining unit 111 obtains the version number corresponding to the story card as the code version number including one or a combination of the following ways:
  • the acquiring unit 111 determines the card library of the system to be verified, acquires the identification code corresponding to the story card from the card library, and determines the code version number according to the identification code.
  • the card library stores the correspondence between story cards and identification codes.
  • the obtaining unit 111 uses the identification code to traverse the storage library, and determines the traversed version number corresponding to the identification code as the code version number.
  • the code version number can be accurately determined.
  • the acquiring unit 111 identifies the version number on the story card, and determines the latest version number from the identified version numbers as the code version number.
  • the identified version numbers are sorted in descending order to obtain a queue, and the first version number arranged in the queue is determined as the latest version number.
  • the version numbers on the story card are V1.0 and V1.1
  • the latest version number is determined to be V1.1 from V1.0 and V1.1
  • V1.1 is used as the code version number.
  • the code version number can be acquired in time after the story card is verified, ensuring real-time performance.
  • the generating unit 115 when the story card fails the verification, the generating unit 115 generates prompt information according to the code version number;
  • the determining unit 110 determines the request level of the version verification request, and determines the sending mode of the prompt information according to the request level;
  • the sending unit 116 sends the prompt information in the sending manner.
  • the determining unit 110 determines the request number of the version verification request, and determines the number interval in which each level is located, and determines the target number interval in which the request number is located according to the number interval in which each level is located. The level corresponding to the target number interval is determined as the request level.
  • a corresponding transmission mode is set for each level.
  • the request level is level one
  • the sending method is email
  • the request level is level two
  • the sending method is SMS
  • the request level is level three
  • the sending method is telephone.
  • the appropriate sending method to send the prompt information can be determined by requesting the level.
  • the prompt information can be generated in time when the story card fails to pass the verification, so as to ensure the corresponding contact person.
  • the prompt information can be received in time.
  • the detection unit 113 detects whether the version number to be verified is consistent with the code version number.
  • the detection unit 113 detecting whether the version number to be verified is consistent with the code version number includes:
  • the detection result can be accurately determined.
  • the extracting unit 114 extracts the version script corresponding to the code version number, and obtains the execution result of the version script.
  • the version script refers to script code for implementing a new story card.
  • the execution result refers to a result obtained after executing the version script, and the execution result includes: error information and script results when an error occurs when executing the version script.
  • the extracting unit 114 extracting the version script corresponding to the code version number includes:
  • the code in revision mode is obtained from the system code as the version script.
  • the revision mode will be used to record the code in the system code, so the version script can be obtained accurately and completely.
  • the version script Since the version script has a revision mode in the system code, the version script can be quickly acquired through the above-mentioned implementation manner.
  • the determining unit 110 determines a verification result of the version number to be verified based on the execution result.
  • the above verification results can also be stored in a node of a blockchain.
  • the verification result includes two results: the version is incorrect and the version is correct.
  • the determining unit 110 determines the originating terminal and originating time of the version verification request
  • the acquiring unit 111 acquires the log table of the initiating terminal, and acquires the login account corresponding to the initiating time from the log table;
  • the sending unit 116 sends the verification result to the login account
  • the determining unit 110 determines that the verification result is sent successfully.
  • the account that initiates the version verification request can be accurately determined, and the corresponding contact person can be notified of the verification result in a timely and accurate manner after the verification result is obtained.
  • the present application does not require the coordinator to advance the version verification process, which reduces the cost of communication between the coordinators and improves the verification efficiency.
  • the coordinator does not need to interfere in the version verification, it is possible to reduce the need for human effort.
  • the verification error caused by the interference thereby improving the verification accuracy.
  • the application can accurately determine the system to be verified and the version number to be verified through the version verification request, so as to avoid inaccurate verification results due to errors in the verified system and version number.
  • the vulnerability information is considered in the story card, which can avoid inaccurate verification of the story card caused by the existence of the vulnerability information on the system to be verified, ensure the verification accuracy of the story card, and can be used in all situations.
  • the code version number is obtained in time, which ensures real-time performance.
  • FIG. 3 it is a schematic structural diagram of an electronic device implementing an embodiment of the version verification method of the present application.
  • the electronic device 1 includes, but is not limited to, a memory 12, a processor 13, and a computer program stored in the memory 12 and executable on the processor 13, such as Version Verifier.
  • the schematic diagram is only an example of the electronic device 1, and does not constitute a limitation on the electronic device 1, and may include more or less components than the one shown, or combine some components, or different Components, for example, the electronic device 1 may also include input and output devices, network access devices, buses, and the like.
  • the processor 13 may be a central processing unit (Central Processing Unit, CPU), or other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.
  • the processor 13 is the computing core and control center of the electronic device 1, and uses various interfaces and lines to connect the entire electronic device. 1, and the operating system that executes the electronic device 1, as well as various installed applications, program codes, and the like.
  • the processor 13 executes the operating system of the electronic device 1 and various installed application programs.
  • the processor 13 executes the application program to implement the steps in each of the above-mentioned embodiments of the version verification method, for example, the steps shown in FIG. 1 .
  • the computer program may be divided into one or more modules/units, and the one or more modules/units are stored in the memory 12 and executed by the processor 13 to complete the present invention.
  • the one or more modules/units may be a series of computer-readable instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device 1.
  • the computer program may be divided into a determination unit 110 , an acquisition unit 111 , a verification unit 112 , a detection unit 113 , an extraction unit 114 , a generation unit 115 , and a transmission unit 116 .
  • the memory 12 can be used to store the computer program and/or module, and the processor 13 can call the data stored in the memory 12 by running or executing the computer program and/or module stored in the memory 12, Various functions of the electronic device 1 are realized.
  • the memory 12 may mainly include a stored program area and a stored data area, wherein the stored program area may store an operating system, an application program required for at least one function (such as a sound playback function, an image playback function, etc.), and the like; the storage data area may Data and the like created according to the use of the electronic device are stored.
  • the memory 12 may include non-volatile memory and volatile memory such as hard disk, internal memory, plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, flash memory card (Flash Card), at least one disk storage device, flash memory device, or other storage device.
  • non-volatile memory and volatile memory such as hard disk, internal memory, plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, flash memory card (Flash Card), at least one disk storage device, flash memory device, or other storage device.
  • the memory 12 may be an external memory and/or an internal memory of the electronic device 1 . Further, the storage 12 may be a storage in physical form, such as a memory stick, a TF card (Trans-flash Card) and the like.
  • TF card Trans-flash Card
  • modules/units integrated in the electronic device 1 are implemented in the form of software functional units and sold or used as independent products, they may be stored in a computer-readable storage medium, and the computer storage medium may be non-volatile, It can also be volatile.
  • the present application can implement all or part of the processes in the methods of the above embodiments, and can also be completed by instructing the relevant hardware through a computer program.
  • the computer program can be stored in a computer-readable storage medium, and the computer When the program is executed by the processor, the steps of the foregoing method embodiments can be implemented.
  • the computer program includes computer program code
  • the computer program code may be in the form of source code, object code, executable file or some intermediate form, and the like.
  • the computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, removable hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory) , random access memory.
  • the blockchain referred to in this application is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • Blockchain essentially a decentralized database, is a series of data blocks associated with cryptographic methods. Each data block contains a batch of network transaction information to verify its Validity of information (anti-counterfeiting) and generation of the next block.
  • the blockchain can include the underlying platform of the blockchain, the platform product service layer, and the application service layer.
  • the memory 12 in the electronic device 1 stores at least one computer-readable instruction to implement a version verification method
  • the processor 13 can execute the at least one computer-readable instruction to implement:
  • a verification result of the to-be-verified version number is determined based on the execution result.
  • modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • each functional module in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.
  • the above-mentioned integrated units can be implemented in the form of hardware, or can be implemented in the form of hardware plus software function modules.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

本申请涉及数据处理，提供一种版本验证方法、装置、电子设备及存储介质。该方法能够当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号，根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息，基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片，当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号，当检测到代码版本号与待验证版本号一致时，提取所述代码版本号对应的版本脚本，基于所述版本脚本的执行结果确定所述待验证版本号的验证结果。本申请提高了验证效率及验证准确度。此外，本申请还涉及区块链技术，所述验证结果可存储于区块链中。

Description

版本验证方法、装置、电子设备及存储介质
本申请要求于2020年09月29日提交中国专利局，申请号为202011053141.1，发明名称为“版本验证方法、装置、电子设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及数据处理技术领域，尤其涉及一种版本验证方法、装置、电子设备及存储介质。
背景技术
为了确保版本的顺利发版及应用，在版本发版之前，需要对发版的版本进行一定的验证，然而，发明人意识到，目前的版本验证需要通过开发负责人主动推进，由于部分开发负责人不熟悉版本验证的整个流程，从而降低了验证效率。
因此，如何构建一种版本验证方案，从而提高验证效率，成了有待解决的技术问题。
发明内容
鉴于以上内容，有必要提供一种版本验证方法、装置、电子设备及存储介质，能够提高验证效率及验证准确度。
本申请的第一方面提供一种版本验证方法，所述版本验证方法包括：
当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
检测所述待验证版本号与所述代码版本号是否一致；
当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
基于所述执行结果确定所述待验证版本号的验证结果。
本申请的第二方面提供一种电子设备，所述电子设备包括处理器和存储器，所述处理器用于执行所述存储器中存储的至少一个计算机可读指令以实现以下步骤：
当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
检测所述待验证版本号与所述代码版本号是否一致；
当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
基于所述执行结果确定所述待验证版本号的验证结果。
本申请的第三方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有至少一个计算机可读指令，所述至少一个计算机可读指令被处理器执行以实现以下步骤：
当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
检测所述待验证版本号与所述代码版本号是否一致；
当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
基于所述执行结果确定所述待验证版本号的验证结果。
本申请的第四方面提供一种版本验证装置，所述版本验证包括：
确定单元，用于当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
获取单元，用于根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
验证单元，用于基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
所述获取单元，还用于当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
检测单元，用于检测所述待验证版本号与所述代码版本号是否一致；
提取单元，用于当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
所述确定单元，还用于基于所述执行结果确定所述待验证版本号的验证结果。
由以上技术方案可以看出，本申请通过所述版本验证请求能够准确确定所述待验证系统及所述待验证版本号，避免验证的系统及版本号错误而导致验证结果不准确，同时在验证所述故事卡片时考虑了所述漏洞信息，能够避免所述待验证系统上的漏洞信息的存在造成所述故事卡片的验证不准确，确保了所述故事卡片的验证准确度，同时能够在所述故事卡片通过验证后及时获取代码版本号，确保了实时性，在提取所述代码版本号对应的版本脚本时，由于无需提取所述待验证系统上的所有系统代码，因此，能够提高提取效率，同时，由于无需对所有系统代码进行分析，提高版本脚本的分析效率。本申请无需通过统筹人员推进版本验证的流程，减少了统筹人员沟通的成本，提高了验证效率，同时，由于无需统筹人员干涉版本验证，因此，能够减少人为干涉带来的验证误差，从而提高验证准确度。
附图说明
图1是本申请版本验证方法的一实施例的流程图。
图1a是本申请确定待验证系统及待验证版本号的一实施例的流程图。
图1b是本申请获取版本信息及漏洞信息的一实施例的流程图。
图1c是本申请验证故事卡片的一实施例的流程图。
图1d是本申请确定目标卡片的一实施例的流程图。
图1e是本申请版本验证方法的另一实施例的流程图。
图1f是本申请检测待验证版本号与代码版本号是否一致的一实施例的流程图。
图1g是本申请提取版本脚本的一实施例的流程图。
图1h是本申请版本验证方法的另一实施例的流程图。
图2是本申请版本验证装置的一实施例的功能模块图。
图3是本申请实现版本验证方法的一实施例的电子设备的结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本申请进行详细描述。
如图1所示，是本申请版本验证方法的一实施例的流程图。根据不同的需求，该流程图 中步骤的顺序可以改变，某些步骤可以省略。
所述版本验证方法应用于智慧城市中，所述版本验证方法应用于一个或者多个电子设备中，所述电子设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。
所述电子设备可以是任何一种可与用户进行人机交互的电子产品，例如，个人计算机、平板电脑、智能手机、个人数字助理(Personal Digital Assistant，PDA)、游戏机、交互式网络电视(Internet Protocol Television，IPTV)、智能穿戴式设备等。
所述电子设备还可以包括网络设备和/或用户设备。其中，所述网络设备包括，但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量主机或网络服务器构成的云。
所述电子设备所处的网络包括，但不限于：互联网、广域网、城域网、局域网、虚拟专用网络(Virtual Private Network，VPN)等。
S10，当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号。
在本申请的至少一个实施例中，所述版本验证请求携带的信息包括，但不限于：第一标签、系统标识、第二标签、所述待验证版本号等。
在本申请的至少一个实施例中，所述版本验证请求可以由负责版本上线的用户触发，也可以在系统版本开发完成后自动触发，本申请对此不作限制。
在本申请的至少一个实施例中，所述待验证系统是指需要进行版本验证的系统，所述待验证版本号是指需要进行验证的版本的代码，例如，所述待验证版本号可以是V1.2。
参见图1a，图1a是本申请确定待验证系统及待验证版本号的一实施例的流程图。在本申请的至少一个实施例中，所述电子设备根据所述版本验证请求确定待验证系统及待验证版本号包括：
S100，解析所述版本验证请求的报文，得到所述版本验证请求的报文信息；
S101，获取第一标签及第二标签；
S102，从所述报文信息中获取与所述第一标签对应的信息作为系统标识，及从所述报文信息中获取与所述第二标签对应的信息作为所述待验证版本号；
S103，根据所述系统标识确定所述待验证系统。
其中，所述第一标签及所述第二标签是指预先定义好的标签，例如：所述第一标签可以为ID，所述第二标签可以为NUM。所述第一标签与所述系统标识的映射关系可以是ID：2356；所述第二标签与所述待验证版本号的映射关系可以是NUM：V1.2。
通过上述实施方式，由于无需解析所述版本验证请求的报文头，因此，能够提高解析效率，此外，通过第一标签与系统标识的映射关系，能够准确确定所述待验证系统，通过第二标签与待验证版本号的映射关系，能够准确确定所述待验证版本号。
在本申请的至少一个实施例中，通过所述版本验证请求能够准确确定所述待验证系统及所述待验证版本号，避免验证的系统及版本号错误而导致验证结果不准确。
S11，根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息。
在本申请的至少一个实施例中，所述版本信息包括故事卡片、详细描述、验收信息。
其中，所述故事卡片包括系统、任务及目标三个要素。例如，所述故事卡片可以是：作为一个书店管理员，我想要添加新书到书库，以便购书者能查阅到这本书。
进一步地，所述详细描述是指如何实现所述任务的描述。
更进一步地，所述验收信息可以包括：具体属性、功能性验收条件及非功能性验收条件等。
在本申请的至少一个实施例中，所述漏洞信息包括，但不限于：用户在开发所述待验证系统的所述待验证版本号时发现的错误、该错误引发的结果等。
参见图1b，图1b是本申请获取版本信息及漏洞信息的一实施例的流程图。在本申请的至少一个实施例中，所述电子设备根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息包括：
S110，从配置库中获取同时与所述待验证版本号及所述待验证系统对应的路径，作为目标路径；
S111，获取所述目标路径上所有文件的创建者，并确定所述创建者的职务；
S112，将职务为第一职务的创建者创建的文件确定为第一文件，将职务为第二职务的创建者创建的文件确定为第二文件；
S113，获取所述第一文件上的信息作为所述版本信息，并获取所述第二文件上的信息作为所述漏洞信息。
其中，所述配置库中存储多个系统、多个版本号与多个路径的映射关系。所述配置库中存储系统、版本号与路径的形式可以是：系统228-V1.3-路径1。
进一步地，所述第一职务的创建者负责所述版本信息的记录与保存，所述第二职务的创建者负责所述漏洞信息的记录与保存。
由于版本信息及漏洞信息是由不同职务的用户创建的，因此，通过识别文件创建者的职务，能够准确获取到所述版本信息及所述漏洞信息。
S12，基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片。
在本申请的至少一个实施例中，所述故事卡片的信息包括：对所述待验证系统进行开发的新功能等。
在本申请的至少一个实施例中，验收信息是指确定所述故事卡片完成的标准条件。
参见图1c，图1c是本申请验证故事卡片的一实施例的流程图。在本申请的至少一个实施例中，所述电子设备基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片包括：
S120，基于距离公式，从案件集中确定与所述故事卡片相似度大于配置值的目标卡片，并从所述案件集中获取与所述目标卡片对应的结果信息；
S121，提取所述版本信息中的验收信息；
S122，比对所述结果信息与所述验收信息是否相同，并比对所述结果信息与所述漏洞信息是否相同；
S123，当所述结果信息与所述验收信息不同，及/或所述结果信息与所述漏洞信息不同时，确定所述故事卡片未通过验证；
S124，当所述结果信息与所述验收信息相同，或者所述结果信息与所述漏洞信息相同时，确定所述故事卡片通过验证。
其中，所述案件集中存储多个卡片与所述多个卡片对应的执行结果。所述目标卡片是指与所述故事卡片的相似度大于所述配置值的卡片，所述结果信息是指完成所述目标卡片中的任务后得到的结果。
具体地，参见图1d，图1d是本申请确定目标卡片的一实施例的流程图。所述电子设备基于距离公式，从案件集中确定与所述故事卡片相似度大于配置值的目标卡片包括：
S1200，对所述案件集中所有卡片进行向量化，得到第一向量，并对所述故事卡片进行向量化，得到第二向量；
S1201，基于距离公式计算所述第一向量与所述第二向量的距离，得到所述案件集中每个卡片与所述故事卡片的相似度；
S1202，将相似度大于所述配置值的卡片确定为所述目标卡片。
通过上述实施方式，在验证所述故事卡片时考虑了所述漏洞信息，能够避免所述待验证系统上的漏洞信息的存在造成所述故事卡片的验证不准确，确保了所述故事卡片的验证准确度。
S13，当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号。
在本申请的至少一个实施例中，当所述待验证系统上的版本号不同时，与所述版本号对应的故事卡片也会随之不同。
在本申请的至少一个实施例中，所述获取与所述故事卡片对应的版本号作为代码版本号包括以下一种或者多种方式的组合：
(1)所述电子设备确定所述待验证系统的卡片库，从所述卡片库中获取与所述故事卡片对应的识别码，并根据所述识别码确定所述代码版本号；及/或
其中，所述卡片库中存储故事卡片与识别码的对应关系。
具体地，所述电子设备利用所述识别码遍历存储库，并将遍历到的与所述识别码对应的版本号确定为所述代码版本号。
通过上述实施方式，由于卡片库中存储故事卡片与识别码的映射关系，因此，能够准确确定所述代码版本号。
(2)所述电子设备识别所述故事卡片上的版本号，并从识别到的版本号中确定最新版本号，作为所述代码版本号。
具体地，对所述识别到的版本号按照从大至小的顺序进行排序，得到队列，并将排列在所述队列中最前的版本号确定为所述最新版本号。
例如：识别到所述故事卡片上的版本号有V1.0、V1.1，从V1.0、V1.1中确定出最新版本号为V1.1，并将V1.1作为代码版本号。
通过上述实施方式，由于无需从众多的卡片中遍历相应的识别码，因此，能够提高所述代码版本号的获取效率。
在本申请的至少一个实施例中，能够在所述故事卡片通过验证后及时获取代码版本号，确保了实时性。
进一步的，参见图1e，如图1e是本申请版本验证方法的另一实施例的流程图。本实施例是在图1a至图1d所示的版本验证方法的基础进行改进得到的，在本申请的至少一个实施例中，所述方法还包括：
S130，当所述故事卡片未通过验证时，根据所述代码版本号生成提示信息；
S131，确定所述版本验证请求的请求等级，根据所述请求等级确定所述提示信息的发送方式；
S132，以所述发送方式发送所述提示信息。
具体地，所述电子设备确定所述版本验证请求的请求编号，并确定每个等级所在的编号区间，根据每个等级所在的编号区间确定所述请求编号所在的目标编号区间，将与所述目标编号区间对应的等级确定为所述请求等级。
进一步地，每个等级均设定了相应的发送方式。例如，所述请求等级为等级一、所述发送方式为邮件方式，所述请求等级为等级二、所述发送方式为短信方式，所述请求等级为等级三、所述发送方式为电话方式。
由于提前设定了等级与发送方式的对应关系，因此，通过请求等级能够确定出合适的发送方式发送提示信息，同时，在所述故事卡片未通过验证时能够及时生成提示信息，确保相应联系人能够及时接收到所述提示信息。
S14，检测所述待验证版本号与所述代码版本号是否一致。
参见图1f，图1f是本申请检测待验证版本号与代码版本号是否一致的一实施例的流程图。在本申请的至少一个实施例中，所述电子设备检测所述待验证版本号与所述代码版本号是否一致包括：
S140，将所述待验证版本号中的字符与所述代码版本号中的字符依序进行比较；
S141，当所述待验证版本号中的字符与所述代码版本号中的字符都相同时，确定所述待验证版本号与所述代码版本号一致；或者
S142，当所述待验证版本号中的字符与所述代码版本号中的字符不都相同时，确定所述待验证版本号与所述代码版本号不一致。
通过将所述待验证版本号中的字符与所述代码版本号中的字符依序进行比较，能够准确确定检测结果。
S15，当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果。
在本申请的至少一个实施例中，所述版本脚本是指实现新建故事卡片的脚本代码。
在本申请的至少一个实施例中，所述执行结果是指执行所述版本脚本后得到的结果，所述执行结果包括：执行所述版本脚本时出现错误时的错误信息、脚本结果。
参见图1g，图1g是本申请提取版本脚本的一实施例的流程图。在本申请的至少一个实施例中，所述电子设备提取所述代码版本号对应的版本脚本包括：
S150，确定所述代码版本号的生成时间；
S151，根据所述生成时间获取所述待验证系统的系统代码；
S152，从所述系统代码中获取处于修订模式的代码，作为所述版本脚本。
可以理解的是，当每个代码版本号对应的代码完成开发时，都会记录该代码完成开发的具体时间，因此，通过完成开发的具体时间的记录，能够确定所述代码版本号的生成时间，并根据所述生成时间能够获取到所述系统代码。
进一步地，当每个代码版本号的代码在开发的过程中，都会利用修订模式将代码记载至系统代码中，因此，能够准确并完整地获取到所述版本脚本。
由于所述版本脚本在所述系统代码中具有修订模式，因此，通过上述实施方式，能够快速获取所述版本脚本。
S16，基于所述执行结果确定所述待验证版本号的验证结果。
需要强调的是，为进一步保证上述验证结果的私密和安全性，上述验证结果还可以存储于一区块链的节点中。
在本申请的至少一个实施例中，所述验证结果包括：版本有误及版本无误两种结果。
进一步的，参见图1h，如图1h是本申请版本验证方法的另一实施例的流程图。本实施例是在图1至图1g所示的版本验证方法的基础进行改进得到的，如图1h所示，本实施例在图1所示的步骤S16基于所述执行结果确定所述待验证版本号的验证结果之后，所述还可包括如下步骤：
S160，确定所述版本验证请求的发起终端及发起时间；
S161，获取所述发起终端的日志表，并从所述日志表中获取与所述发起时间对应的登录账号；
S162，将所述验证结果发送至所述登录账号；
S163，当接收到所述登录账号的反馈信息时，确定所述验证结果发送成功。
通过上述实施方式，能够准确确定发起所述版本验证请求的账号，进而能够在得到验证结果后及时并准确将验证结果告知相应联系人。
在本申请的至少一个实施例中，本申请无需通过统筹人员推进版本验证的流程，减少了统筹人员沟通的成本，提高了验证效率，同时，由于无需统筹人员干涉版本验证，因此，能够减少人为干涉带来的验证误差，从而提高验证准确度。
由以上技术方案可以看出，本申请通过所述版本验证请求能够准确确定所述待验证系统及所述待验证版本号，避免验证的系统及版本号错误而导致验证结果不准确，同时在验证所述故事卡片时考虑了所述漏洞信息，能够避免所述待验证系统上的漏洞信息的存在造成所述故事卡片的验证不准确，确保了所述故事卡片的验证准确度，同时能够在所述故事卡片通过验证后及时获取代码版本号，确保了实时性，在提取所述代码版本号对应的版本脚本时，由于无需提取所述待验证系统上的所有系统代码，因此，能够提高提取效率，同时，由于无需对所有系统代码进行分析，提高版本脚本的分析效率。本申请无需通过统筹人员推进版本验证的流程，减少了统筹人员沟通的成本，提高了验证效率，同时，由于无需统筹人员干涉版本验证，因此，能够减少人为干涉带来的验证误差，从而提高验证准确度。
如图2所示，是本申请版本验证装置的一实施例的功能模块图。所述版本验证装置11包括确定单元110、获取单元111、验证单元112、检测单元113、提取单元114、生成单元115及发送单元116。本申请所称的模块/单元是指一种能够被处理器13所执行，并且能够完成固定功能的一系列计算机程序段，其存储在存储器12中。在本实施例中，关于各模块/单元的功能将在后续的实施例中详述。
当接收到版本验证请求时，确定单元110根据所述版本验证请求确定待验证系统及待验证版本号。
在本申请的至少一个实施例中，所述版本验证请求携带的信息包括，但不限于：第一标签、系统标识、第二标签、所述待验证版本号等。
在本申请的至少一个实施例中，所述版本验证请求可以由负责版本上线的用户触发，也可以在系统版本开发完成后自动触发，本申请对此不作限制。
在本申请的至少一个实施例中，所述待验证系统是指需要进行版本验证的系统，所述待验证版本号是指需要进行验证的版本的代码，例如，所述待验证版本号可以是V1.2。
在本申请的至少一个实施例中，所述确定单元110根据所述版本验证请求确定待验证系统及待验证版本号包括：
解析所述版本验证请求的报文，得到所述版本验证请求的报文信息；
获取第一标签及第二标签；
从所述报文信息中获取与所述第一标签对应的信息作为系统标识，及从所述报文信息中获取与所述第二标签对应的信息作为所述待验证版本号；
根据所述系统标识确定所述待验证系统。
其中，所述第一标签及所述第二标签是指预先定义好的标签，例如：所述第一标签可以为ID，所述第二标签可以为NUM。所述第一标签与所述系统标识的映射关系可以是ID：2356；所述第二标签与所述待验证版本号的映射关系可以是NUM：V1.2。
通过上述实施方式，由于无需解析所述版本验证请求的报文头，因此，能够提高解析效率，此外，通过第一标签与系统标识的映射关系，能够准确确定所述待验证系统，通过第二标签与待验证版本号的映射关系，能够准确确定所述待验证版本号。
在本申请的至少一个实施例中，通过所述版本验证请求能够准确确定所述待验证系统及所述待验证版本号，避免验证的系统及版本号错误而导致验证结果不准确。
获取单元111根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息。
在本申请的至少一个实施例中，所述版本信息包括故事卡片、详细描述、验收信息。
其中，所述故事卡片包括系统、任务及目标三个要素。例如，所述故事卡片可以是：作为一个书店管理员，我想要添加新书到书库，以便购书者能查阅到这本书。
进一步地，所述详细描述是指如何实现所述任务的描述。
更进一步地，所述验收信息可以包括：具体属性、功能性验收条件及非功能性验收条件等。
在本申请的至少一个实施例中，所述漏洞信息包括，但不限于：用户在开发所述待验证系统的所述待验证版本号时发现的错误、该错误引发的结果等。
在本申请的至少一个实施例中，所述获取单元111根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息包括：
从配置库中获取同时与所述待验证版本号及所述待验证系统对应的路径，作为目标路径；
获取所述目标路径上所有文件的创建者，并确定所述创建者的职务；
将职务为第一职务的创建者创建的文件确定为第一文件，将职务为第二职务的创建者创建的文件确定为第二文件；
获取所述第一文件上的信息作为所述版本信息，并获取所述第二文件上的信息作为所述漏洞信息。
其中，所述配置库中存储多个系统、多个版本号与多个路径的映射关系。所述配置库中 存储系统、版本号与路径的形式可以是：系统228-V1.3-路径1。
进一步地，所述第一职务的创建者负责所述版本信息的记录与保存，所述第二职务的创建者负责所述漏洞信息的记录与保存。
由于版本信息及漏洞信息是由不同职务的用户创建的，因此，通过识别文件创建者的职务，能够准确获取到所述版本信息及所述漏洞信息。
验证单元112基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片。
在本申请的至少一个实施例中，所述故事卡片的信息包括：对所述待验证系统进行开发的新功能等。
在本申请的至少一个实施例中，验收信息是指确定所述故事卡片完成的标准条件。
在本申请的至少一个实施例中，所述验证单元112基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片包括：
基于距离公式，从案件集中确定与所述故事卡片相似度大于配置值的目标卡片，并从所述案件集中获取与所述目标卡片对应的结果信息；
提取所述版本信息中的验收信息；
比对所述结果信息与所述验收信息是否相同，并比对所述结果信息与所述漏洞信息是否相同；
当所述结果信息与所述验收信息不同，及/或所述结果信息与所述漏洞信息不同时，确定所述故事卡片未通过验证；
当所述结果信息与所述验收信息相同，或者所述结果信息与所述漏洞信息相同时，确定所述故事卡片通过验证。
其中，所述案件集中存储多个卡片与所述多个卡片对应的执行结果。所述目标卡片是指与所述故事卡片的相似度大于所述配置值的卡片，所述结果信息是指完成所述目标卡片中的任务后得到的结果。
具体地，所述验证单元112基于距离公式，从案件集中确定与所述故事卡片相似度大于配置值的目标卡片包括：
对所述案件集中所有卡片进行向量化，得到第一向量，并对所述故事卡片进行向量化，得到第二向量；
基于距离公式计算所述第一向量与所述第二向量的距离，得到所述案件集中每个卡片与所述故事卡片的相似度；
将相似度大于所述配置值的卡片确定为所述目标卡片。
通过上述实施方式，在验证所述故事卡片时考虑了所述漏洞信息，能够避免所述待验证系统上的漏洞信息的存在造成所述故事卡片的验证不准确，确保了所述故事卡片的验证准确度。
当所述故事卡片通过验证时，所述获取单元111获取与所述故事卡片对应的版本号作为代码版本号。
在本申请的至少一个实施例中，当所述待验证系统上的版本号不同时，与所述版本号对应的故事卡片也会随之不同。
在本申请的至少一个实施例中，所述获取单元111获取与所述故事卡片对应的版本号作为代码版本号包括以下一种或者多种方式的组合：
(1)所述获取单元111确定所述待验证系统的卡片库，从所述卡片库中获取与所述故事卡片对应的识别码，并根据所述识别码确定所述代码版本号。
其中，所述卡片库中存储故事卡片与识别码的对应关系。
具体地，所述获取单元111利用所述识别码遍历存储库，并将遍历到的与所述识别码对应的版本号确定为所述代码版本号。
通过上述实施方式，由于卡片库中存储故事卡片与识别码的映射关系，因此，能够准确确定所述代码版本号。
(2)所述获取单元111识别所述故事卡片上的版本号，并从识别到的版本号中确定最新版本号，作为所述代码版本号。
具体地，对所述识别到的版本号按照从大至小的顺序进行排序，得到队列，并将排列在所述队列中最前的版本号确定为所述最新版本号。
例如：识别到所述故事卡片上的版本号有V1.0、V1.1，从V1.0、V1.1中确定出最新版本号为V1.1，并将V1.1作为代码版本号。
通过上述实施方式，由于无需从众多的卡片中遍历相应的识别码，因此，能够提高所述代码版本号的获取效率。
在本申请的至少一个实施例中，能够在所述故事卡片通过验证后及时获取代码版本号，确保了实时性。
在本申请的至少一个实施例中，当所述故事卡片未通过验证时，生成单元115根据所述代码版本号生成提示信息；
所述确定单元110确定所述版本验证请求的请求等级，根据所述请求等级确定所述提示信息的发送方式；
发送单元116以所述发送方式发送所述提示信息。
具体地，所述确定单元110确定所述版本验证请求的请求编号，并确定每个等级所在的编号区间，根据每个等级所在的编号区间确定所述请求编号所在的目标编号区间，将与所述目标编号区间对应的等级确定为所述请求等级。
进一步地，每个等级均设定了相应的发送方式。例如，所述请求等级为等级一、所述发送方式为邮件方式，所述请求等级为等级二、所述发送方式为短信方式，所述请求等级为等级三、所述发送方式为电话方式。
由于提前设定了等级与发送方式的对应关系，因此，通过请求等级能够确定出合适的发送方式发送提示信息，同时，在所述故事卡片未通过验证时能够及时生成提示信息，确保相应联系人能够及时接收到所述提示信息。
检测单元113检测所述待验证版本号与所述代码版本号是否一致。
在本申请的至少一个实施例中，所述检测单元113检测所述待验证版本号与所述代码版本号是否一致包括：
将所述待验证版本号中的字符与所述代码版本号中的字符依序进行比较；
当所述待验证版本号中的字符与所述代码版本号中的字符都相同时，确定所述待验证版本号与所述代码版本号一致；或者
当所述待验证版本号中的字符与所述代码版本号中的字符不都相同时，确定所述待验证版本号与所述代码版本号不一致。
通过将所述待验证版本号中的字符与所述代码版本号中的字符依序进行比较，能够准确确定检测结果。
当检测到所述待验证版本号与所述代码版本号一致时，提取单元114提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果。
在本申请的至少一个实施例中，所述版本脚本是指实现新建故事卡片的脚本代码。
在本申请的至少一个实施例中，所述执行结果是指执行所述版本脚本后得到的结果，所述执行结果包括：执行所述版本脚本时出现错误时的错误信息、脚本结果。
在本申请的至少一个实施例中，所述提取单元114提取所述代码版本号对应的版本脚本包括：
确定所述代码版本号的生成时间；
根据所述生成时间获取所述待验证系统的系统代码；
从所述系统代码中获取处于修订模式的代码，作为所述版本脚本。
可以理解的是，当每个代码版本号对应的代码完成开发时，都会记录该代码完成开发的具体时间，因此，通过完成开发的具体时间的记录，能够确定所述代码版本号的生成时间， 并根据所述生成时间能够获取到所述系统代码。
进一步地，当每个代码版本号的代码在开发的过程中，都会利用修订模式将代码记载至系统代码中，因此，能够准确并完整地获取到所述版本脚本。
由于所述版本脚本在所述系统代码中具有修订模式，因此，通过上述实施方式，能够快速获取所述版本脚本。
所述确定单元110基于所述执行结果确定所述待验证版本号的验证结果。
需要强调的是，为进一步保证上述验证结果的私密和安全性，上述验证结果还可以存储于一区块链的节点中。
在本申请的至少一个实施例中，所述验证结果包括：版本有误及版本无误两种结果。
在本申请的至少一个实施例中，在基于所述执行结果确定所述待验证版本号的验证结果之后，所述确定单元110确定所述版本验证请求的发起终端及发起时间；
所述获取单元111获取所述发起终端的日志表，并从所述日志表中获取与所述发起时间对应的登录账号；
所述发送单元116将所述验证结果发送至所述登录账号；
当接收到所述登录账号的反馈信息时，所述确定单元110确定所述验证结果发送成功。
通过上述实施方式，能够准确确定发起所述版本验证请求的账号，进而能够在得到验证结果后及时并准确将验证结果告知相应联系人。
在本申请的至少一个实施例中，本申请无需通过统筹人员推进版本验证的流程，减少了统筹人员沟通的成本，提高了验证效率，同时，由于无需统筹人员干涉版本验证，因此，能够减少人为干涉带来的验证误差，从而提高验证准确度。
由以上技术方案可以看出，本申请通过所述版本验证请求能够准确确定所述待验证系统及所述待验证版本号，避免验证的系统及版本号错误而导致验证结果不准确，同时在验证所述故事卡片时考虑了所述漏洞信息，能够避免所述待验证系统上的漏洞信息的存在造成所述故事卡片的验证不准确，确保了所述故事卡片的验证准确度，同时能够在所述故事卡片通过验证后及时获取代码版本号，确保了实时性，在提取所述代码版本号对应的版本脚本时，由于无需提取所述待验证系统上的所有系统代码，因此，能够提高提取效率，同时，由于无需对所有系统代码进行分析，提高版本脚本的分析效率。本申请无需通过统筹人员推进版本验证的流程，减少了统筹人员沟通的成本，提高了验证效率，同时，由于无需统筹人员干涉版本验证，因此，能够减少人为干涉带来的验证误差，从而提高验证准确度。
如图3所示，是本申请实现版本验证方法的一实施例的电子设备的结构示意图。
在本申请的一个实施例中，所述电子设备1包括，但不限于，存储器12、处理器13，以及存储在所述存储器12中并可在所述处理器13上运行的计算机程序，例如版本验证程序。
本领域技术人员可以理解，所述示意图仅仅是电子设备1的示例，并不构成对电子设备1的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述电子设备1还可以包括输入输出设备、网络接入设备、总线等。
所述处理器13可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器13是所述电子设备1的运算核心和控制中心，利用各种接口和线路连接整个电子设备1的各个部分，及执行所述电子设备1的操作系统以及安装的各类应用程序、程序代码等。
所述处理器13执行所述电子设备1的操作系统以及安装的各类应用程序。所述处理器13执行所述应用程序以实现上述各个版本验证方法实施例中的步骤，例如图1所示的步骤。
示例性的，所述计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器12中，并由所述处理器13执行，以完成本申请。所述一个或多个 模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述计算机程序在所述电子设备1中的执行过程。例如，所述计算机程序可以被分割成确定单元110、获取单元111、验证单元112、检测单元113、提取单元114、生成单元115及发送单元116。
所述存储器12可用于存储所述计算机程序和/或模块，所述处理器13通过运行或执行存储在所述存储器12内的计算机程序和/或模块，以及调用存储在存储器12内的数据，实现所述电子设备1的各种功能。所述存储器12可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备的使用所创建的数据等。此外，存储器12可以包括非易失性存储器和易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他存储器件。
所述存储器12可以是电子设备1的外部存储器和/或内部存储器。进一步地，所述存储器12可以是具有实物形式的存储器，如内存条、TF卡(Trans-flash Card)等等。
所述电子设备1集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中，该计算机存储介质可以是非易失性，也可以是易失性的。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。
其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器。
本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
结合图1，所述电子设备1中的所述存储器12存储至少一个计算机可读指令以实现一种版本验证方法，所述处理器13可执行所述至少一个计算机可读指令从而实现：
当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
检测所述待验证版本号与所述代码版本号是否一致；
当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
基于所述执行结果确定所述待验证版本号的验证结果。
具体地，所述处理器13对上述指令的具体实现方法可参考图1对应实施例中相关步骤的描述，在此不赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个 单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。
因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附关联图标记视为限制所涉及的权利要求。
此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。说明书中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一、第二等词语用来表示名称，而并不表示任何特定的顺序。
最后应说明的是，以上实施例仅用以说明本申请的技术方案而非限制，尽管参照实施例对本申请进行了详细说明，本领域的普通技术人员应当理解，可以对本申请的技术方案进行修改或等同替换，而不脱离本申请技术方案的精神和范围。

Claims (20)

  1. 一种版本验证方法，其中，所述版本验证方法包括：
    当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
    根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
    基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
    当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
    检测所述待验证版本号与所述代码版本号是否一致；
    当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
    基于所述执行结果确定所述待验证版本号的验证结果。
  2. 根据权利要求1所述的版本验证方法，其中，所述根据所述版本验证请求确定待验证系统及待验证版本号包括：
    解析所述版本验证请求的报文，得到所述版本验证请求的报文信息；
    获取第一标签及第二标签；
    从所述报文信息中获取与所述第一标签对应的信息作为系统标识，及从所述报文信息中获取与所述第二标签对应的信息作为所述待验证版本号；
    根据所述系统标识确定所述待验证系统。
  3. 根据权利要求1所述的版本验证方法，其中，所述根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息包括：
    从配置库中获取同时与所述待验证版本号及所述待验证系统对应的路径，作为目标路径；
    获取所述目标路径上所有文件的创建者，并确定所述创建者的职务；
    将职务为第一职务的创建者创建的文件确定为第一文件，将职务为第二职务的创建者创建的文件确定为第二文件；
    获取所述第一文件上的信息作为所述版本信息，并获取所述第二文件上的信息作为所述漏洞信息。
  4. 根据权利要求1所述的版本验证方法，其中，所述基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片包括：
    基于距离公式，从案件集中确定与所述故事卡片相似度大于配置值的目标卡片，并从所述案件集中获取与所述目标卡片对应的结果信息；
    提取所述版本信息中的验收信息；
    比对所述结果信息与所述验收信息是否相同，并比对所述结果信息与所述漏洞信息是否相同；
    当所述结果信息与所述验收信息不同，及/或所述结果信息与所述漏洞信息不同时，确定所述故事卡片未通过验证；
    当所述结果信息与所述验收信息相同，或者所述结果信息与所述漏洞信息相同时，确定所述故事卡片通过验证。
  5. 根据权利要求1所述的版本验证方法，其中，所述获取与所述故事卡片对应的版本号作为代码版本号包括以下一种或者多种方式的组合：
    确定所述待验证系统的卡片库，从所述卡片库中获取与所述故事卡片对应的识别码，并根据所述识别码确定所述代码版本号；及/或
    识别所述故事卡片上的版本号，并从识别到的版本号中确定最新版本号，作为所述代码版本号。
  6. 根据权利要求1所述的版本验证方法，其中，所述提取所述代码版本号对应的版本 脚本包括：
    确定所述代码版本号的生成时间；
    根据所述生成时间获取所述待验证系统的系统代码；
    从所述系统代码中获取处于修订模式的代码，作为所述版本脚本。
  7. 根据权利要求1所述的版本验证方法，其中，在基于所述执行结果确定所述待验证版本号的验证结果之后，所述方法还包括：
    确定所述版本验证请求的发起终端及发起时间；
    获取所述发起终端的日志表，并从所述日志表中获取与所述发起时间对应的登录账号；
    将所述验证结果发送至所述登录账号；
    当接收到所述登录账号的反馈信息时，确定所述验证结果发送成功。
  8. 一种版本验证装置，其中，所述版本验证装置包括：
    确定单元，用于当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
    获取单元，用于根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
    验证单元，用于基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
    所述获取单元，还用于当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
    检测单元，用于检测所述待验证版本号与所述代码版本号是否一致；
    提取单元，用于当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
    所述确定单元，还用于基于所述执行结果确定所述待验证版本号的验证结果。
  9. 一种电子设备，其中，所述电子设备包括处理器和存储器，所述处理器用于执行存储器中存储的至少一个计算机可读指令以实现以下步骤：
    当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
    根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
    基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
    当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
    检测所述待验证版本号与所述代码版本号是否一致；
    当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
    基于所述执行结果确定所述待验证版本号的验证结果。
  10. 根据权利要求9所述的电子设备，其中，在所述根据所述版本验证请求确定待验证系统及待验证版本号时，所述处理器执行所述至少一个计算机可读指令以实现以下步骤：
    解析所述版本验证请求的报文，得到所述版本验证请求的报文信息；
    获取第一标签及第二标签；
    从所述报文信息中获取与所述第一标签对应的信息作为系统标识，及从所述报文信息中获取与所述第二标签对应的信息作为所述待验证版本号；
    根据所述系统标识确定所述待验证系统。
  11. 根据权利要求9所述的电子设备，其中，在所述根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息时，所述处理器执行所述至少一个计算机可读指令以实现以下步骤：
    从配置库中获取同时与所述待验证版本号及所述待验证系统对应的路径，作为目标路 径；
    获取所述目标路径上所有文件的创建者，并确定所述创建者的职务；
    将职务为第一职务的创建者创建的文件确定为第一文件，将职务为第二职务的创建者创建的文件确定为第二文件；
    获取所述第一文件上的信息作为所述版本信息，并获取所述第二文件上的信息作为所述漏洞信息。
  12. 根据权利要求9所述的电子设备，其中，在所述基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片时，所述处理器执行所述至少一个计算机可读指令用以实现以下步骤：
    基于距离公式，从案件集中确定与所述故事卡片相似度大于配置值的目标卡片，并从所述案件集中获取与所述目标卡片对应的结果信息；
    提取所述版本信息中的验收信息；
    比对所述结果信息与所述验收信息是否相同，并比对所述结果信息与所述漏洞信息是否相同；
    当所述结果信息与所述验收信息不同，及/或所述结果信息与所述漏洞信息不同时，确定所述故事卡片未通过验证；
    当所述结果信息与所述验收信息相同，或者所述结果信息与所述漏洞信息相同时，确定所述故事卡片通过验证。
  13. 根据权利要求9所述的电子设备，其中，在所述获取与所述故事卡片对应的版本号作为代码版本号时，所述处理器执行所述至少一个计算机可读指令用以实现以下步骤：
    确定所述待验证系统的卡片库，从所述卡片库中获取与所述故事卡片对应的识别码，并根据所述识别码确定所述代码版本号；及/或
    识别所述故事卡片上的版本号，并从识别到的版本号中确定最新版本号，作为所述代码版本号。
  14. 根据权利要求9所述的电子设备，其中，在所述提取所述代码版本号对应的版本脚本时，所述处理器执行所述至少一个计算机可读指令用以实现以下步骤：
    确定所述代码版本号的生成时间；
    根据所述生成时间获取所述待验证系统的系统代码；
    从所述系统代码中获取处于修订模式的代码，作为所述版本脚本。
  15. 一种计算机可读存储介质，其中，所述计算机可读存储介质存储有至少一个计算机可读指令，所述至少一个计算机可读指令被处理器执行时实现以下步骤：
    当接收到版本验证请求时，根据所述版本验证请求确定待验证系统及待验证版本号；
    根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息；
    基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片；
    当所述故事卡片通过验证时，获取与所述故事卡片对应的版本号作为代码版本号；
    检测所述待验证版本号与所述代码版本号是否一致；
    当检测到所述待验证版本号与所述代码版本号一致时，提取所述代码版本号对应的版本脚本，并获取所述版本脚本的执行结果；
    基于所述执行结果确定所述待验证版本号的验证结果。
  16. 根据权利要求15所述的存储介质，其中，在所述根据所述版本验证请求确定待验证系统及待验证版本号时，所述至少一个计算机可读指令被处理器执行以实现以下步骤：
    解析所述版本验证请求的报文，得到所述版本验证请求的报文信息；
    获取第一标签及第二标签；
    从所述报文信息中获取与所述第一标签对应的信息作为系统标识，及从所述报文信息中获取与所述第二标签对应的信息作为所述待验证版本号；
    根据所述系统标识确定所述待验证系统。
  17. 根据权利要求15所述的存储介质，其中，在所述根据所述待验证版本号获取所述待验证系统上的版本信息及漏洞信息时，所述至少一个计算机可读指令被处理器执行以实现以下步骤：
    从配置库中获取同时与所述待验证版本号及所述待验证系统对应的路径，作为目标路径；
    获取所述目标路径上所有文件的创建者，并确定所述创建者的职务；
    将职务为第一职务的创建者创建的文件确定为第一文件，将职务为第二职务的创建者创建的文件确定为第二文件；
    获取所述第一文件上的信息作为所述版本信息，并获取所述第二文件上的信息作为所述漏洞信息。
  18. 根据权利要求15所述的存储介质，其中，在所述基于所述版本信息及所述漏洞信息验证所述待验证系统上的故事卡片时，所述至少一个计算机可读指令被处理器执行用以实现以下步骤：
    基于距离公式，从案件集中确定与所述故事卡片相似度大于配置值的目标卡片，并从所述案件集中获取与所述目标卡片对应的结果信息；
    提取所述版本信息中的验收信息；
    比对所述结果信息与所述验收信息是否相同，并比对所述结果信息与所述漏洞信息是否相同；
    当所述结果信息与所述验收信息不同，及/或所述结果信息与所述漏洞信息不同时，确定所述故事卡片未通过验证；
    当所述结果信息与所述验收信息相同，或者所述结果信息与所述漏洞信息相同时，确定所述故事卡片通过验证。
  19. 根据权利要求15所述的存储介质，其中，在所述获取与所述故事卡片对应的版本号作为代码版本号时，所述至少一个计算机可读指令被处理器执行时用以实现以下步骤：
    确定所述待验证系统的卡片库，从所述卡片库中获取与所述故事卡片对应的识别码，并根据所述识别码确定所述代码版本号；及/或
    识别所述故事卡片上的版本号，并从识别到的版本号中确定最新版本号，作为所述代码版本号。
  20. 根据权利要求15所述的存储介质，其中，在所述提取所述代码版本号对应的版本脚本时，所述至少一个计算机可读指令被处理器执行用以实现以下步骤：
    确定所述代码版本号的生成时间；
    根据所述生成时间获取所述待验证系统的系统代码；
    从所述系统代码中获取处于修订模式的代码，作为所述版本脚本。
PCT/CN2021/090382 2020-09-29 2021-04-28 版本验证方法、装置、电子设备及存储介质 WO2022068190A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011053141.1 2020-09-29
CN202011053141.1A CN112181482B (zh) 2020-09-29 2020-09-29 版本验证方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
WO2022068190A1 true WO2022068190A1 (zh) 2022-04-07

Family

ID=73946145

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/090382 WO2022068190A1 (zh) 2020-09-29 2021-04-28 版本验证方法、装置、电子设备及存储介质

Country Status (2)

Country Link
CN (1) CN112181482B (zh)
WO (1) WO2022068190A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112181482B (zh) * 2020-09-29 2023-03-21 平安科技（深圳）有限公司 版本验证方法、装置、电子设备及存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101382914A (zh) * 2008-10-15 2009-03-11 北大方正集团有限公司 软件更新文件的测试方法和装置
US8640119B2 (en) * 2010-02-26 2014-01-28 Red Hat, Inc. Determining compatibility of a software package update using a version identifier
US20140201712A1 (en) * 2013-01-15 2014-07-17 International Business Machines Corporation Integration of a software content space with test planning and test case generation
CN108427637A (zh) * 2018-01-18 2018-08-21 平安科技（深圳）有限公司 测试案例推荐方法、电子装置及可读存储介质
CN108959077A (zh) * 2018-06-25 2018-12-07 郑州云海信息技术有限公司 一种基于云计算技术的敏捷开发提测管理系统及方法
CN109408355A (zh) * 2017-08-16 2019-03-01 迈普通信技术股份有限公司 测试用例获取方法及装置
CN110109820A (zh) * 2019-03-19 2019-08-09 深圳壹账通智能科技有限公司 回归测试用例确定方法、装置、计算机设备及存储介质
CN112181482A (zh) * 2020-09-29 2021-01-05 平安科技（深圳）有限公司 版本验证方法、装置、电子设备及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100971139B1 (ko) * 2008-04-25 2010-07-20 주식회사 비즈모델라인 문서 저작권 관리 방법 및 시스템과 이를 위한 기록매체
CN106650460B (zh) * 2016-11-15 2019-07-19 上海华为技术有限公司 一种版本校验方法、装置及终端设备
CN110989994B (zh) * 2019-11-18 2024-04-26 腾讯科技（深圳）有限公司 基于区块链的代码版本管理方法、装置、终端及存储介质
CN111400719B (zh) * 2020-03-12 2023-03-14 中国科学院信息工程研究所 基于开源组件版本识别的固件脆弱性判别方法及系统
CN111639308A (zh) * 2020-04-24 2020-09-08 杭州溪塔科技有限公司 一种基于区块链的软件序列号分发验证方法和装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101382914A (zh) * 2008-10-15 2009-03-11 北大方正集团有限公司 软件更新文件的测试方法和装置
US8640119B2 (en) * 2010-02-26 2014-01-28 Red Hat, Inc. Determining compatibility of a software package update using a version identifier
US20140201712A1 (en) * 2013-01-15 2014-07-17 International Business Machines Corporation Integration of a software content space with test planning and test case generation
CN109408355A (zh) * 2017-08-16 2019-03-01 迈普通信技术股份有限公司 测试用例获取方法及装置
CN108427637A (zh) * 2018-01-18 2018-08-21 平安科技（深圳）有限公司 测试案例推荐方法、电子装置及可读存储介质
CN108959077A (zh) * 2018-06-25 2018-12-07 郑州云海信息技术有限公司 一种基于云计算技术的敏捷开发提测管理系统及方法
CN110109820A (zh) * 2019-03-19 2019-08-09 深圳壹账通智能科技有限公司 回归测试用例确定方法、装置、计算机设备及存储介质
CN112181482A (zh) * 2020-09-29 2021-01-05 平安科技（深圳）有限公司 版本验证方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN112181482A (zh) 2021-01-05
CN112181482B (zh) 2023-03-21

Similar Documents

Publication Publication Date Title
JP6847187B2 (ja) 画像ベースのｃａｐｔｃｈａチャレンジ
US10073916B2 (en) Method and system for facilitating terminal identifiers
JP7352622B2 (ja) ブロックチェーン・タイムスタンプ協定
CN111163182B (zh) 基于区块链的设备注册方法、装置、电子设备和存储介质
US10740411B2 (en) Determining repeat website users via browser uniqueness tracking
JP2021518705A (ja) ブロックチェーン台帳のためのランタイム自己修正
JP5802848B2 (ja) モバイル環境用のトロイの木馬化されたアプリケーション（アプリ）を特定するためのコンピュータ実装方法、非一時コンピュータ読み取り可能な媒体およびコンピュータシステム
CN112636924A (zh) 网络资产识别方法及装置、存储介质及电子设备
CN109561085A (zh) 一种基于设备识别码的身份验证方法、服务器及介质
WO2022088666A1 (zh) 服务实例校验方法、装置、电子设备及存储介质
US10275329B2 (en) Fault isolation and identification in versioned microservices
JP2019507424A (ja) リスク管理方法及び装置
WO2022041889A1 (zh) 资金路由方法、装置、电子设备及存储介质
CN116325833A (zh) 将设备标识集成到区块链的许可框架中
US11748331B2 (en) Verifying structured data
JP6664585B2 (ja) 情報処理装置、情報処理方法、及び情報処理プログラム
WO2022068190A1 (zh) 版本验证方法、装置、电子设备及存储介质
CN109857634A (zh) 接口测试参数校验方法、装置、电子设备及存储介质
US11288151B2 (en) System and method of determining boot status of recovery servers
CN115037790B (zh) 异常注册识别方法、装置、设备及存储介质
CN114360732B (zh) 医疗数据分析方法、装置、电子设备及存储介质
CN112181485B (zh) 脚本执行方法、装置、电子设备及存储介质
CN112738175A (zh) 请求处理方法及相关设备
CN115001802B (zh) 基于共享屏幕的账号异常登录检测方法及相关设备
CN112395319B (zh) 缓存共用方法、装置、服务器及存储介质

Legal Events

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

Ref document number: 21873853

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21873853

Country of ref document: EP

Kind code of ref document: A1