An automatic testing method based on oil product movement system
By combining Python and Robot Framework with automated testing methods for both web and consumer applications, the problem of low testing efficiency in oil product mobile systems was solved. This enabled effective testing of software interaction performance and stability, improving testing efficiency and quality.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SUPCON TECH CO LTD
- Filing Date
- 2022-08-12
- Publication Date
- 2026-07-31
AI Technical Summary
Existing oil product mobility system testing can only be done manually, which is inefficient and cannot effectively test the interaction performance and stability between software, and lacks convenient testing tools.
Using Python and Robot Framework in conjunction with both web and C-end interfaces, the system encapsulates the write-value interfaces for device tag numbers and tank parameters. Selenium is used to encapsulate the creation of new orders, order approval, creation of new tasks, task execution, and task termination. Performance monitoring tools are then used for automated testing.
It enables various tests of the oil product moving system, reduces manpower consumption, improves testing efficiency, and can effectively test the performance and stability of the software interaction part, supporting smoke testing, functional testing, performance testing, and long-term stability testing.
Smart Images
Figure CN115454816B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of performance testing technology for oil product moving systems, and more specifically to an automated testing method based on oil product moving systems. Background Technology
[0002] In the oil refining and petrochemical industry, the oil moving system (OMS) is a system used to move crude oil and its products through pipelines. It includes equipment and status management, movement path management, and drive equipment. Before executing an oil moving task, the OMS task system generates the movement path. During the task, equipment along the path needs to operate or shut down according to its type and location, following specific rules. Equipment status needs to be monitored during operation, and emergency handling logic needs to be executed when necessary. The control rules during the operation phase need to be adjusted according to the actual situation on site.
[0003] The oil movement control part of the existing OMS system runs in a distributed control system (DCS). The operation of the oil movement system is usually carried out by sending commands from the web terminal to the C terminal, which controls the on / off status of the monitoring equipment and returns the status to the web terminal. Therefore, the entire operation involves multiple software programs, the operation flow is long, and there are many business scenarios.
[0004] Currently, testing of oil product movement systems can only be done manually, such as using JMeter or LoadRunner to perform load testing on individual software components. However, the performance and stability of the interactions between software components cannot be tested. Furthermore, manual testing is inefficient, has a high rate of missed tests, and lacks convenient testing tools. Summary of the Invention
[0005] To overcome the shortcomings of the above technologies, this invention provides an automated testing method based on an oil product mobile system. It combines the web and C-end using Python and Robot Framework, and uses performance monitoring tools to monitor each server, thereby enabling multiple tests of the oil product mobile system, reducing manpower consumption, greatly improving testing efficiency, and testing the performance and stability of the interactive part.
[0006] The technical solution adopted by this invention to overcome its technical problems is: an automated testing method based on an oil product moving system, wherein the oil product moving system includes at least a web terminal and a C terminal, the web terminal sends commands to the C terminal, thereby controlling the operation of equipment in a distributed control system through the C terminal, and the automated testing method specifically includes: S1, encapsulating the web terminal's write-value interface for the equipment tag number and tank parameters of the distributed control system based on Python; S2, encapsulating the creation of new orders, order approval, creation of new tasks, task execution, subtasks, and task stopping based on Selenium; S3, script initialization, calling the write-value interface to batch write initial values to the equipment tag number and tank parameters of the distributed control system; S4, based on Robot... The Framework manages test cases based on business scenarios, including calling encapsulated new order creation, encapsulated order approval, encapsulated new task creation, encapsulated task execution, encapsulated subtasks, and encapsulated stop tasks. It also calls write-value interfaces to control the working status of distributed control devices based on business scenarios. In S5, it runs test scripts and calls write-value interfaces to set simulated tank operating parameters based on the business scenario corresponding to the test scripts. In S6, it controls the task to stop running based on preset simulated operating parameter thresholds, preset task loop times, or by simulating a stop button operation on the web interface using Selenium. In S7, it analyzes the running results and stability of orders and tasks based on Robot Framework, monitors the interaction performance between oil product mobile system software, and analyzes performance results using performance analysis tools.
[0007] Furthermore, in step S5, the write value interface is called and the simulated operating parameters of the tank are set based on the running business. Specifically, different simulated operating parameters are set for the tank according to different business scenarios. The simulated operating parameters include at least the magnitude and direction of the liquid level flow rate in the tank.
[0008] The magnitude and direction of the liquid level and flow velocity in the tank are used to simulate inflow and outflow, as well as the corresponding liquid flow velocities.
[0009] Furthermore, the step of controlling the task to stop running based on a preset simulated running parameter threshold, a preset task cycle time, or a Selenium simulated web interface operation specifically includes: if the liquid level in the tank of the business scenario reaches the preset simulated running parameter threshold, then the task stops running; or, if the task running time reaches the preset task cycle time, then the task stops running; or, if the task stops running by using a Selenium simulated web interface operation stop button.
[0010] Furthermore, in step S3, the script is initialized by calling the write value interface to perform initial write values on the device tag number and tank parameters of the distributed control system in batches. Specifically, this includes performing initial write values on at least the DCS device tag number, the upper and lower operating limits of the tank, the liquid level of the tank, and the simulated flow rate of the tank based on the encapsulated write value interface.
[0011] Furthermore, the encapsulation of task execution includes at least path selection, path saving, distribution, management, and startup.
[0012] Furthermore, the process includes at least calling the write-value interface to open the manual valve on the main task path, close the pump outlet manual valve, and close the manual valve on the bypass path.
[0013] Furthermore, the test script also includes obtaining the current state of the task during task execution by calling the API based on the request.
[0014] Furthermore, obtaining the current status of the task specifically includes: if the pipeline is being executed, determining whether the manual valve of the main path of the task is open, the manual valve of the pump outlet is closed, and the manual valve of the bypass is closed based on the request call interface; if the manual valve of the main path of the task is open, the manual valve of the pump outlet is closed, and the manual valve of the bypass is closed, then the pipeline continues to be executed; otherwise, the write value interface is called to open the manual valve of the main path of the task, close the manual valve of the pump outlet, and close the manual valve of the bypass.
[0015] Furthermore, obtaining the current state of the task also includes determining the shared state of the manual valve before the pipe is opened. If the manual valve is occupied by other tasks, the manual valve remains in its current state until the task ends.
[0016] Furthermore, obtaining the current status of the task specifically includes: when starting execution, based on the request call interface, determining whether the pump inlet and outlet are both manual valves, and whether the pump outlet manual valve is open. If both the pump inlet and outlet are manual valves, the C-end message needs to be confirmed based on pyautogui. After successful confirmation, the pump outlet valve is opened; otherwise, the task cannot start and the pump outlet manual valve is opened, so the start-up continues. Otherwise, the write value interface is called to ensure that both the pump inlet and outlet are manual valves and / or the pump outlet manual valve is open.
[0017] The beneficial effects of this invention are:
[0018] 1. Utilize Python + Robot Framework, combining web and C-end applications, and monitor the performance of each server through automated testing and performance testing tools;
[0019] 2. Solved the performance and stability testing of the software interaction part, and carried out smoke testing, functional testing, performance testing, long-term stability testing and regression testing, which reduced manpower consumption and greatly improved testing efficiency;
[0020] 3. By automating and simulating manual operations, more business scenarios can be executed, thus better ensuring software quality;
[0021] 4. For different business types, we can customize and select some special business scenarios to conduct smoke tests and regression tests;
[0022] 5. Using Robot Framework, we can write multiple business use case scenarios for functional testing. For example, in an oil collection business, manual testing would only perform oil collection tasks or sub-tasks on a few tanks. With this method, we can cover all tanks to perform main tasks or sub-tasks.
[0023] 6. By using multiple Python + Robot Framework environments to continuously execute business operations, we can simulate a real environment and conduct performance and long-term stability tests. Attached Figure Description
[0024] Figure 1 This is a flowchart of an automated testing method based on an oil product movement system according to an embodiment of the present invention;
[0025] Figure 2 This is a schematic diagram of the Robot Framework management test cases according to an embodiment of the present invention;
[0026] Figure 3 This is a schematic diagram illustrating the results analysis of an embodiment of the present invention. Detailed Implementation
[0027] To facilitate a better understanding of the present invention by those skilled in the art, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The following are merely exemplary and do not limit the scope of protection of the present invention.
[0028] An Oil Movement System (OMS) is an automated storage and transportation solution that integrates oil movement planning management, operation monitoring, control, execution, and tracking. Its purpose is to improve the reliability, safety, and efficiency of storage and transportation operations, while providing audit trails throughout the entire process.
[0029] Robot Framework is a functional automation testing framework written in Python. It boasts excellent scalability, supports keyword-driven testing, can test multiple types of clients or interfaces simultaneously, and enables distributed test execution. It is primarily used for acceptance testing with multiple rounds and Acceptance Test-Driven Development (ATDD).
[0030] Selenium: Selenium is an automated testing framework, mainly used to manipulate browsers and simulate web applications for automated testing.
[0031] Test case: A specific set of input data, operations, or various environmental settings and expected results provided to the system under test for the purpose of conducting tests;
[0032] Test scripts are scripts written for automated testing. Test scripts must correspond to specific test cases. By calling test scripts, different test cases are simulated, which in turn simulate different business scenarios.
[0033] OMSBatch is a software program that controls other software by controlling the OMS software.
[0034] VxAnywhere: A software that enables communication between OMS and VF. It is installed on both the VF client and VF server and communicates with the VF environment through VxAnywhere.
[0035] To facilitate a better understanding of the present invention by those skilled in the art, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The following are merely exemplary and do not limit the scope of protection of the present invention.
[0036] This invention discloses an automated testing method based on an oil product movement system, such as... Figure 1As shown, the oil product mobile system includes at least a web client and a client-side interface. The web client sends commands to the client-side, thereby controlling the operation of the distributed control system's equipment. The automated testing method specifically includes: S1, encapsulating the web client's write-value interface for the distributed control system's equipment tag number and tank parameters using Python; S2, encapsulating new order creation, order approval, new task creation, task execution, subtasks, and task stop using Selenium; S3, script initialization, calling the write-value interface to batch write initial values to the distributed control system's equipment tag number and tank parameters; S4, managing test cases based on business scenarios using Robot Framework, including calling the encapsulated new order creation, order approval, new task creation, task execution, subtasks, and task stop, and controlling the working status of the distributed control equipment by calling the write-value interface according to the business scenario; S5, running the test script, calling the write-value interface, and setting the simulated operating parameters of the tank based on the running business settings; S6, controlling the task to stop running based on preset simulated operating parameter thresholds, preset task loop times, or by simulating the web client's stop button operation via Selenium; S7, based on Robot Framework... The framework analyzes the execution results and stability of orders and tasks, monitors the interaction performance between oil product movement system software, and analyzes performance results using performance analysis tools.
[0037] The following describes the automated testing method for the VxOMS oil product movement system applied in the oil tank industry as an example, illustrating each step. The entire system includes a VF server, several VF clients, and an OMS server. The workflow of the VxOMS oil product movement system generally involves running a web application installed on a VF client or accessing it through a browser, requesting the OMS server, communicating with the client-side (C-end) installed on the VF client through the OMS server, and controlling the underlying DCS equipment through the C-end. The overall software operation process typically involves creating order tasks through VxOMS, using VxAnywhere to enable communication between VxOMS and VF, requesting the OMS server through any browser, and requesting control of the underlying DCS equipment through OMSBatch.
[0038] S1 is a Python-based web-based interface for writing device tag numbers and tank parameters to a distributed control system.
[0039] To improve the program's scalability, versatility, and writing efficiency, the writing interface is encapsulated using Python to perform batch bit writing.
[0040] S2. Based on Selenium, encapsulate the creation of new orders, order approval, creation of new tasks, task execution, subtasks, and task termination.
[0041] Selenium is used to encapsulate the creation of new orders, order approval, creation of new tasks, task execution, subtasks, and task termination.
[0042] The execution process of a task is encapsulated, such as tasks that are distributed, managed, or started.
[0043] The encapsulation of subtasks includes adding pumps, removing pumps, adding tanks, and removing tanks. Different subtasks are executed based on different business scenarios, and the Robot Framework is used for management of different scenarios, such as... Figure 2 As shown.
[0044] It should be noted that other subtasks can only be performed while a task is in progress.
[0045] S3. Script initialization: Call the write value interface to perform initial write values on the device tag number and tank parameters of the distributed control system in batches.
[0046] In an embodiment of the present invention, the script program is initialized by first writing values to the DCS device tag number, the upper and lower limits of the tank's operation, the current liquid level of the tank, and the simulated flow rate of the tank, so as to ensure the normal execution of subsequent automated order tasks.
[0047] S4. Based on Robot Framework, manage test cases according to business scenarios, including calling encapsulated new order, encapsulated order approval, encapsulated new task, encapsulated task execution, encapsulated subtask and encapsulated stop task according to test cases, and calling write value interface to control the working status of distributed control devices according to business scenarios.
[0048] The Robot Framework is used to manage test cases for order tasks, simulating the execution of multiple business scenarios in the field of the oil product mobile system. It calls the Selenium-based functions for creating new orders, approving orders, creating new tasks, and stopping tasks, simulating the web-based operations of the oil product mobile system.
[0049] If the execution of a task or subtask requires controlling the distributed control device through the C-end, then the distributed control device is controlled by calling the encapsulated write value interface.
[0050] In some implementations, when executing a pipeline task, a write-value interface is used to open the manual valve on the main path, close the manual valve at the pump inlet, and close the manual valve on the bypass path.
[0051] When starting the task, confirm that both the pump inlet and outlet valves are manual, and open the pump outlet manual valve. If both the pump inlet and outlet valves are manual, manual confirmation via the prompt message is required.
[0052] When pipe connection is initiated or execution begins, the current status of the task is obtained by calling the request interface. If the main valve of the task is open, the pump outlet valve is closed, and the bypass valve is closed during pipe connection, the pipe connection continues. Otherwise, the write value interface is called to open the main valve of the task, close the pump outlet valve, and close the bypass valve.
[0053] It should be noted that obtaining the current state of the task also includes determining the shared state of the manual valve before the pipe-through process begins. If the manual valve is occupied by another task, it will remain in its current state until the task ends. If the shared depth of the manual valve is greater than or equal to 1, meaning it is occupied by another task, then the manual valve will remain unchanged and its current state will be maintained. In this case, the pipe-through task will continue to execute.
[0054] The shared device state is consistent with the expected device state; however, because the previous task has already started or stopped, this task no longer needs to be operated. When stopping or ending a task, if the sharing depth is greater than 1, the device state also remains unchanged until the last task ends, at which point the device state will be changed. In one embodiment of this invention, the device refers to a hand valve.
[0055] S5 runs the test script and calls the write value interface to set the simulated running parameters of the tank based on the business scenario corresponding to the test script.
[0056] Depending on the business scenario, different parameters are set for the simulated flow rate of the tank based on the write-value interface to simulate the actual operation of the business on site.
[0057] If, during startup, the task is to call the interface based on the request to determine whether both the pump inlet and outlet are manual valves and whether the pump outlet manual valve is open, and if both the pump inlet and outlet are manual valves, the C-end message is confirmed based on pyautogui. If the confirmation is successful, the pump outlet valve is opened; otherwise, startup cannot proceed and the pump outlet manual valve is open. Otherwise, the write value interface is called to ensure that both the pump inlet and outlet are manual valves and / or that the pump outlet manual valve is open.
[0058] It should be noted that after the task is successfully issued, OpGuide on the C-side will start providing prompts for each subsequent step. When both the pump's inlet and outlet are manual valves, a confirmation message will be required upon task startup. pyautogui is a Python library.
[0059] S6 controls the task to stop running based on preset simulation run parameter thresholds, preset task cycle time, or the stop button in the Selenium simulated web interface.
[0060] For batch-type tasks, taking the preset simulated operating parameter threshold as the liquid level threshold as an example, when the liquid level in the tank reaches the preset liquid level of the corresponding tank during the task execution process, the automatic termination is triggered, and the script execution ends. For example, loading trucks or ships, this batch-type task ends when the tank is full, and the task can also end when the preset quantity is met.
[0061] For self-circulating tasks, the script terminates when the task execution time reaches the preset cycle time, triggering automatic termination, etc. For example, a tank continuously circulates its contents, allowing the solution within to mix continuously, creating a self-circulating task. When the preset cycle time is reached, the script terminates.
[0062] Alternatively, Selenium can be used to simulate a stop button on the web interface, allowing continuous tasks to run for a period of time before being stopped, simulating actual on-site operations. Here, "continuous" tasks, in contrast to "batch" tasks, are tasks that run continuously without interruption.
[0063] S7, based on Robot Framework, analyzes the execution results and stability of orders and tasks, monitors the interaction performance between oil product movement system software, and analyzes performance results using performance analysis tools.
[0064] In some implementations, the Robot Framework allows direct viewing of runtime logs, stability monitoring, and interaction performance between oil product mobility system software. The monitor can display the CPU usage of each server, such as... Figure 3 As shown.
[0065] In some implementations, the performance results of each server are detected using the Surveillant performance counter.
[0066] In some implementations, a single server or client can set up a Python+RobotFramework environment, using the same scripts, and utilize multiple Python+RobotFramework environments to simulate different tank farm tasks, i.e., different test cases, to achieve consistency with the actual running scenario.
[0067] Taking the test script for oil collection as an example, firstly, the script program is initialized by calling the Python-encapsulated C-end interface for writing values to the equipment tag number and tank parameters of the distributed control system, thereby setting the high and low liquid levels and tank flow rate of the equipment tank within a reasonable range.
[0068] Then, based on Robot Framework, test cases are managed according to the oil collection business scenario. These test cases call encapsulated new order creation, order approval, new task creation, and task execution, thus realizing the test flow of new order creation - order approval - new task creation - task saving - path selection - save path - distribution - pipe connection - startup - execution in progress - simulated tank level rise, setting positive flow rate - setting emergency backup tank - automatic tank switching upon reaching high level. Specifically, new order creation, order approval, and new task creation all simulate web-based command sending using Selenium. Distribution implements the web client sending commands to batches, thereby enabling web control of the C-end and ultimately controlling the underlying DCS equipment.
[0069] It also calls the write-value interface to set the simulated operating parameters of the tank, namely the flow rate and flow direction, thereby simulating the rise of the liquid level in the simulated tank. It also sets the parameters for the emergency backup tank and the automatic tank-switching threshold, so that when the liquid level in the tank reaches a high level, the tank is automatically switched off and the execution ends. Alternatively, the sub-task tank switching can be performed manually, allowing the task to be stopped and terminated after running for a period of time.
[0070] Using the above method, commands are sent from the web terminal to the C terminal to highly simulate actual on-site operation. The C terminal controls the on / off status of the monitoring equipment and returns the status to the web terminal. This enables smoke testing, functional testing, performance testing, long-term stability testing, and regression testing, reducing manpower consumption and greatly improving testing efficiency.
[0071] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.
[0072] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.
Claims
1. An automated testing method based on an oil product movement system, the oil product movement system comprising at least a web end and a C end, the web end sending commands to the C end to thereby control operation of devices of a distributed control system via the C end, characterized in that, The automated testing method specifically includes: S1 is an interface based on Python that encapsulates the writing of device tag numbers and tank parameters of a distributed control system via a web interface. S2 encapsulates the creation of new orders, order approval, creation of new tasks, task execution, subtasks, and task termination based on Selenium. S3, script initialization, calls the write value interface to batch write initial values to the device tag number and tank parameter of the distributed control system; S4, based on Robot Framework, manages test cases according to business scenarios, including calling encapsulated new order, encapsulated order approval, encapsulated new task, encapsulated task execution, encapsulated subtask and encapsulated stop task, as well as calling write value interface to control the working status of distributed control devices according to business scenarios. S5, run the test script and call the write value interface to set the simulated running parameters of the tank based on the business scenario corresponding to the test script; S6 controls the task to stop running based on preset simulation running parameter thresholds, preset task cycle time, or by simulating the stop button on the web interface using Selenium. S7, based on Robot Framework, analyzes the execution results and stability of orders and tasks, monitors the interaction performance between oil product movement system software, and analyzes performance results using performance analysis tools; In step S5, the write value interface is called and the simulated operating parameters of the tank are set based on the running business. Specifically, different simulated operating parameters are set for the tank according to different business scenarios. The simulated operating parameters include at least the magnitude and direction of the liquid level flow rate in the tank. The method of controlling the task to stop running based on preset simulation operation parameter thresholds, preset task loop time, or Selenium simulated web interface operations specifically includes: If the liquid level in the tank of the business scenario reaches the preset simulation operation parameter threshold, the task will stop running; Alternatively, if the task execution time reaches the task's preset cycle time, the task will stop running; Alternatively, you can use Selenium to simulate the stop button on the web interface to stop the task from running; Step S3 script initialization involves calling the write value interface to batch write initial values to the device tag numbers and tank parameters of the distributed control system, specifically including: At least the DCS device tag number, the upper and lower limits of tank operation, the tank level, and the simulated flow rate of the tank should be initially written based on the encapsulated write interface.
2. The automated testing method based on an oil product movement system according to claim 1, characterized in that, The encapsulation of the task execution includes at least path selection, path saving, distribution, management, and startup.
3. The automated testing method based on an oil product movement system according to claim 2, characterized in that, The passage pipe includes at least calling the write value interface to open the manual valve of the main task path, close the pump outlet manual valve, and close the bypass manual valve.
4. The automated testing method based on an oil product movement system according to claim 2, characterized in that, Also includes: The test script also includes obtaining the current state of the task during task execution by calling the API based on the request.
5. The automated testing method based on an oil product movement system according to claim 4, characterized in that, The process of obtaining the current status of the current task specifically includes: when the pipeline is being executed, the system calls the interface based on the request to determine whether the manual valve of the main path of the task is open, whether the manual valve of the pump outlet is closed, and whether the manual valve of the bypass is closed. If the manual valve of the main path of the task is open, the manual valve of the pump outlet is closed, and the manual valve of the bypass is closed, then the pipeline continues to be executed. Otherwise, the system calls the write value interface to open the manual valve of the main path of the task, close the manual valve of the pump outlet, and close the manual valve of the bypass.
6. The automated testing method based on an oil product movement system according to claim 5, characterized in that, The process of obtaining the current state of the current task also includes determining the shared state of the manual valve before the pipe is opened. If the manual valve is occupied by other tasks, the manual valve will remain in its current state until the task ends.
7. The automated testing method based on an oil product movement system according to claim 4, characterized in that, The process of obtaining the current status of the current task specifically includes: when starting execution, based on the request call interface, determining whether the pump inlet and outlet are both manual valves, and whether the pump outlet manual valve is open. If both the pump inlet and outlet are manual valves, the C-end message needs to be confirmed based on pyautogui. After successful confirmation, the pump outlet valve is opened; otherwise, the task cannot start and the pump outlet manual valve is open. Then, the start-up process continues. Otherwise, the write value interface is called to ensure that both the pump inlet and outlet are manual valves and / or the pump outlet manual valve is open.