An interface automatic test case generation method

Abstract

The application provides an interface automatic test case generation method, comprising the following steps: step 1, acquiring knowledge information from a rule configuration platform by calling an interface; step 2, acquiring quality control rules and switch configurations of each quality control dimension from the rule configuration platform-into effect configuration; step 3, acquiring knowledge information according to the configured request template information; step 4, performing rule mapping splicing, automatically generating interface test cases, adapting to an existing automatic test framework, and executing the generated automation. The application uses existing knowledge data of the rule configuration platform, stores existing data as variables through interface calling, replaces corresponding variable values in a preset case request template, generates test cases suitable for a mature Pytest+Requests test framework, greatly improves test efficiency, realizes full regression as much as possible, and finally realizes automatic tool delivery, which is used for on-site environment regression of customers.

Description

Technical Field

[0001] This invention relates to the field of software testing, specifically to an automated test case generation method for a clinical decision support system (CDSS) medical order quality control engine scenario. Background Technology

[0002] In the field of software automation testing, ensuring the independence and accuracy of test cases is crucial. To achieve this goal, Setup and Teardown are common techniques in automated testing frameworks. The Setup process is mainly used to create or initialize the necessary test data and environment before each test case is executed, while the Teardown process is responsible for cleaning up this data and environment after each test case is executed, ensuring that each test case is executed in a clean test environment.

[0003] However, with the increasing complexity of testing requirements and logic, such as in the scenario of a Clinical Decision Support System (CDSS) medical order quality control engine, the combination of quality control point logic results in a large number of test cases, which are heavily dependent on the rule configuration platform data. This makes the workload of implementing traditional automated testing framework Setup / Teardown methods enormous. On the other hand, manually writing and maintaining test cases for a large number of test scenarios becomes both time-consuming and error-prone, making full regression testing impractical. This is unacceptable for clinical medical products, as these products have extremely high requirements for software quality.

[0004] To address this issue, this invention proposes an interface automated test case generation method. This method can automatically acquire the knowledge rules required for medical order quality control scenarios on the rule configuration platform and generate a test case that is compatible with the existing automated testing framework. This method can greatly reduce the workload of testers in writing and maintaining test cases, improve testing efficiency, achieve full regression testing as much as possible, and make it possible to release automated tools. Summary of the Invention

[0005] In view of the aforementioned technical problems, this invention proposes a method for generating automated interface test cases. It includes:

[0006] This invention proposes a method for generating automated test cases for APIs. It utilizes existing knowledge data from a rule-configured platform, storing this data as variables through API calls. These variables replace the corresponding variable values ​​in the preset test case request template, generating test cases compatible with the mature Pytest+Requests testing framework (a widely used automated testing solution for API testing). Instead of hardcoding the test case request data and constructing it through setup pre-processing, this method avoids numerous setup pre-processing operations to construct platform knowledge data and teardown post-processing operations to delete constructed data. This significantly improves testing efficiency, enables full regression testing as much as possible, and allows for the deployment of automated tools for regression testing in customer field environments.

[0007] The present invention proposes a method for generating automated interface test cases, as follows: Figure 3 As shown, it includes the following steps:

[0008] Step 1: Obtain the corresponding quality control dimension knowledge information from the rule configuration platform by calling the relevant platform interfaces; the rule configuration platform is the knowledge management configuration platform for the CDSS medical order quality control rule configuration, and the front-end display form is a web platform page. After logging in with an administrator account, the left-hand first-level tab menu includes dimensions such as [Department, Western Medicine Diagnosis, Traditional Chinese Medicine Diagnosis, Examination, Major Tests, Minor Tests, Surgery, Blood Components, Treatment, Process Rule Management, and Effective Configuration]. Clicking on the Examination dimension tab displays a list of each term, such as [Chest CT Examination]. Clicking the "View" button for the [Chest CT Examination] term leads to the second-level tab menu, which includes dimensions such as [Contraindications, Contraindications, Contraindications Medical History, Contraindications Surgical History, Contraindications Signs, Allergies, Age Factors, Marital Status, Physiological Status, Drug Effects, Sequential Items, Conflicting Items, Follow-up Interval, Custom Population, and Pre- / Post-Examination Precautions for Doctors]. Each second-level tab contains editable knowledge rules corresponding to that term. Clicking on [Contraindications] and then "Add" allows you to configure the knowledge rules for that term, such as adding a symptom like fever and specifying the contraindication level (prohibited, cautious, or warning). If you select "prohibited," the rule configuration for that term is complete, meaning the contraindication symptom for the term [Chest CT Examination] is [Fever] - prohibited. The rule configuration platform can call the corresponding implementation interface through coding. First, it can call the login interface ( / cdss / dashboard / api / login) to obtain the corresponding cookie, hospital and other information. Then, it can call the term list interface for each dimension ( / cdss / dashboard / api / knowledge / {category} / glossary) to obtain the terms. Finally, it can obtain the knowledge content of the terms ( / cdss / dashboard / api / knowledge / {category} / {entity_id}). Each term is distinguished by entity_id.

[0009] Step 2: From the rule configuration platform's primary tab - Effective Configuration, call the corresponding interface ( / cdss / dashboard / api / knowledge / configuration) to obtain the quality control rules and switch configurations for each quality control dimension. The Effective Configuration tab includes a terminology dimension selection dropdown menu [Western Medicine Diagnosis, Traditional Chinese Medicine Diagnosis, Examination, Major Laboratory Items, Minor Laboratory Items, Surgery, Blood Components, Treatment]. If Examination is selected, the list displays the script reminder templates, effective scenarios (outpatient, inpatient), and switch configuration options for each medical order quality control situation under the Examination dimension. For example, [Terminology]: The patient has [Contraindications], this item is [Contraindication Level]! For example, for the term [Chest CT Examination] configured in Step 1, the reminder script is [Chest CT Examination]: The patient has [High Fever], this item is [Prohibited]! When this term is read and used, the template for [Examination and Contraindications] of that contraindication dimension will be read from the Effective Configuration. If the switch is selected as [On], the rule takes effect; if selected as [Off], the rule is not triggered. Similarly, the effective configuration sets up a permutation and combination of rules for each term and each contraindication dimension (examination and contraindication diseases, examination and contraindication medical history, examination and contraindication surgical history, etc.). When a certain contraindication knowledge of the term is used, the rules in the effective configuration are read to determine whether to give a prompt.

[0010] Step 3: As Figure 5 As shown, based on the acquired knowledge dimension information, test cases are assembled through various judgments and combination logics, stored in a preset test case request template, and interface test cases are automatically generated. For example, if the terminology dimension - examination [chest CT scan] - contraindication symptom [fever] - contraindication level [prohibition] is acquired, then the code logic is written to match and judge. First, it is judged whether it is an examination dimension, then whether it is a contraindication symptom, and then it is judged according to the effective configuration to determine which template to read. Based on the acquired knowledge information, the corresponding fields in the preset template are replaced, such as assigning the acquired contraindication symptom entry to the field [chief complaint].

[0011] Code implementation snippet:

[0012] #Expected request

[0013] req["emr"]["admission record"]["chief complaint"] = entry

[0014] First, write the quality control point name, requested data, and expected results into a text file (.txt).

[0015] param type: Quality control point type: Inspection, major test items, surgery, treatment, etc.

[0016] param item terminology name: such as chest CT scan

[0017] param data requests data and expected results

[0018] return: Whether the write was successful.

[0019] Code implementation snippet:

[0020] case_name,case_req,case_expected=f"{item}-{type}QC-{type} and {data[0]}",\

[0021] json.dumps(data[1], ensure_ascii=False), json.dumps(data[2], ensure_ascii=False)

[0022] Finally, the data in the text file is transferred to Excel according to the automated test case format adapted to the Pytest+Requests testing framework. Figure 5 The use case format shown

[0023] Step 4: Adapt to the existing mature Pytest+Requests testing framework. This framework is a relatively mature API automation framework that can read test cases from Excel and perform assertion validation based on the expected rules in the test cases. Figure 5 In the preset response template shown, the message field in the assertion interface request return is compared with the assertion "result.result[0].message===

Chest Examination CT

high fever

prohibited

[0024] The advantages and beneficial effects of this invention are as follows:

[0025] (1) In the context of medical order quality control, there are many combinations of quality control dimensions and a large number of quality control points (each corresponding to a test case). Due to its strong dependence on the knowledge data of the rule configuration platform, if general automated testing methods are adopted, the cost of constructing data through setup operations is extremely high, and the risk of accidental deletion is brought about by calling the data deletion interface through teardown operations. This invention directly utilizes existing environmental data, and generates test cases that can be used for existing automated regression testing by calling existing data in the platform environment and through a series of code concatenation logic. This can greatly reduce the workload of testers in writing test cases, thereby greatly improving the efficiency of testers.

[0026] (2) In an environment with very complete data, since this method does not involve constructing test data through the interface or deleting data, it will not have any impact on the environment.

[0027] (3) The built-in medical knowledge base is currently being updated. Medical personnel are only evaluating and verifying a portion of the knowledge, which is insufficient for a full assessment. The test case generation method proposed in this invention can be used directly to generate test cases with very high coverage, thereby achieving full regression analysis of quality control points as much as possible and ensuring product quality.

[0028] (4) The test case generation method proposed in this invention is designed for the private deployment scenario of medical products. Due to its good code encapsulation, it can be deployed and executed with one click, realize the automation of tool delivery, and realize the regression of customer field environment. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the medical order quality control scenario triggering process of the present invention.

[0030] Figure 2 A schematic diagram illustrating the addition of quality control knowledge to the rule configuration platform of this invention.

[0031] Figure 3 This is a schematic diagram illustrating the overall steps of the automated scenario test case generation method of the present invention.

[0032] Figure 4 This is a schematic diagram illustrating the specific steps of the automated scenario test case generation method of the present invention.

[0033] Figure 5 This is a schematic diagram of the test cases automatically generated by this invention in Excel format. Detailed Implementation

[0034] The present invention will now be described in further detail with reference to the accompanying drawings and examples, but this does not limit the invention to the scope of the embodiments described.

[0035] like Figure 1 The diagram illustrates the triggering process for a medical order quality control scenario. First, the doctor enters patient medical history information (including medical history, medical history, and patient complaint) into the Hospital Information System (HIS) after taking the patient's medical records. Following a diagnosis and recommendations for examinations and tests, the doctor then issues a medical order (e.g., an examination order). When this order encounters a knowledge configuration rule in the rule configuration platform (including quality control knowledge, quality control effective scenarios, quality control point names, and quality control reminder text), the system triggers a quality control reminder, which is ultimately displayed on the system's front-end page for the doctor to reference and adjust / optimize the medical order.

[0036] For such testing scenarios, automated testing typically requires first constructing the corresponding knowledge dimension data on the rule configuration platform through setup pre-processing. This includes: first adding institution information, then adding terminology (such as surgery, treatment plan, etc.), then adding quality control knowledge of terminology sub-dimensions (such as contraindications, contraindications, etc.), then writing the corresponding test case input parameter requests for the constructed data, and manually writing test cases adapted to the existing mature Pytest+Requests testing framework, such as... Figure 2 As shown, the existing Pytest+Requests API automation testing framework is used to read the input parameters, execute tests, assert the engine's return value as expected, and finally delete the constructed test data for the corresponding dimension through a Teardown post-operation.

[0037] The specific implementation process of this method is as follows: Figure 3 As shown, it can be divided into the following steps:

[0038] Step 1: First, configure the login rules platform through code, view the encryption method of the login password, and obtain the header, institution information (hospital field), etc. The headers contain cookie, hospital, and username information, which are the cookie information required for login, the hospital institution name (hospital), and the username information, which are needed for subsequent API calls.

[0039] Code implementation snippet:

[0040] #header contains information

[0041] header="{"cookie":cookie,"hospital":hospital,"username":self.usr}

[0042] return header, hospital

[0043] Step 2: Call the platform interface ( / cdss / dashboard / api / knowledge / configuration) to obtain the rule configuration platform - effective configuration, in order to obtain the quality control point name (e.g., examination and contraindications), effective scenario (outpatient, inpatient), reminder template (e.g., [examination item]: the patient has [contraindications], this item is [reminder level]!) and reminder level (prohibited, caution, reminder).

[0044] The list of effective configurations here includes the following parameters:

[0045] param page: page number

[0046] param page_size: Number of items per page

[0047] param type: Search dimensions: examination, test, specimen, surgery, blood components, treatment, operation, etc.

[0048] param search: Search content

[0049] param generality: Project source: superior, own

[0050] param visit_type: Type of visit: outpatient, inpatient

[0051] param template: Reminder script template

[0052] param status: Enables / disables the effective configuration.

[0053] Step 3: Call the platform interface ( / cdss / dashboard / api / knowledge / {category} / glossary) to obtain the terminology list, and determine the pagination status of the list. If the terminology list is empty, return directly and continue to Step 3 to call other knowledge dimensions and replace the {category} field of the dimension; if the terminology list is not empty, proceed to Step 4.

[0054] Step 4: Traverse the term list, obtain the unique knowledge ID for each term, and use this knowledge ID to call the platform interface to obtain the quality control knowledge details for this term.

[0055] Code implementation snippet

[0056] #2. Method for obtaining knowledge details: ris_item_id is a unique knowledge ID for each term.

[0057] ris_item_details=dashboard.get_ris_item_detail(entity_id=ris_item_id)

[0058] For example, if the check for "Chest CT Scan" - Contraindication Symptom "Fever" - Contraindication Level "Prohibited" indicates that the His system will trigger a reminder when a patient has a fever symptom and a "Chest CT Scan" order is issued. Determine if the quality control knowledge for the term is empty. If empty, proceed to step 5; otherwise, proceed to step 6.

[0059] Step 5: Determine whether the terminology quality control knowledge dimensions on this page (

Contraindications symptoms, contraindications diseases, contraindications medical history, contraindications surgical history, contraindications physical signs, allergies, age factors, marital status, physiological state, drug effects, sequential items, conflicting items, follow-up examination interval, custom population, and doctor's pre / post-examination precautions

[0060] Step 6: Traverse the quality control knowledge and determine whether the quality control dimensions exist. If they exist, proceed to step 7; otherwise, proceed to step 8.

[0061] Step 7: As Figure 5 As shown, based on the acquired knowledge dimension information, test cases are assembled through various judgments and combination logics, stored in a preset test case request template, and interface test cases are automatically generated. For example, if the terminology dimension - examination [chest CT scan] - contraindication symptom [fever] - contraindication level [prohibition] is acquired, then the code logic is written to match and judge. First, it is judged whether it is an examination dimension, then whether it is a contraindication symptom, and then it is judged according to the effective configuration to determine which template to read. Based on the acquired knowledge information, the corresponding fields in the preset template are replaced, such as assigning the acquired contraindication symptom entry to the field [chief complaint].

[0062] Code implementation snippet:

[0063] #Expected request

[0064] req["emr"]["admission record"]["chief complaint"] = entry

[0065] First, write the quality control point name, requested data, and expected results into a text file (.txt).

[0066] param type: Quality control point type: Inspection, major test items, surgery, treatment, etc.

[0067] param item terminology name: such as chest CT scan

[0068] param data: Requested data and expected results

[0069] return: Whether the write was successful.

[0070] Code implementation snippet:

[0071] case_name,case_req,case_expected=f"{item}-{type}QC-{type} and {data[0]}",\

[0072] json.dumps(data[1], ensure_ascii=False), json.dumps(data[2], ensure_ascii=False)

[0073] Finally, the data in the text file is transferred to Excel according to the automated test case format adapted to the Pytest+Requests testing framework. Figure 5 The use case format shown

[0074] Code implementation snippet:

[0075]

[0076] Step 8: Record missing dimension reminders;

[0077] Step 9: Adapt to the existing mature Pytest+Requests testing framework, read the generated test cases and execute them, and verify whether the request meets expectations by writing appropriate assertions.

Claims

1. A method for generating automated test cases for interfaces, characterized in that, Includes the following steps: Step 1: Obtain knowledge information from the rule configuration platform by calling the interface; the rule configuration platform is the knowledge management and configuration platform for the Clinical Decision Support System (CDSS) medical order quality control rule configuration, and the front-end display form is a web platform page; after logging in with the administrator account, the left-hand first-level tab menu has the following dimensions in order: Department, Western Medicine Diagnosis, Traditional Chinese Medicine Diagnosis, Examination, Major Test Items, Minor Test Items, Surgery, Blood Components, Treatment, Process Rule Management, and Effective Configuration; Step 2: Obtain the quality control rules and on / off configurations for each quality control dimension from the rule configuration platform - effective configuration. Specifically, from the rule configuration platform's first-level tab - effective configuration, call the corresponding interface / cdss / dashboard / api / knowledge / configuration to obtain the quality control rules and on / off configurations for each quality control dimension. The effective configuration tab includes a terminology dimension selection dropdown including Western medicine diagnosis, traditional Chinese medicine diagnosis, examination, major laboratory tests, minor laboratory tests, surgery, blood components, and treatment. If examination is selected, the list displays the wording reminder templates, effective scenarios, and on / off configurations for each medical order quality control situation under the examination dimension. The rule configuration platform calls the corresponding implementation interface through coding. First, it calls the login interface / cdss / dashboard / api / login to obtain the corresponding cookie and hospital information. Then, it calls the terminology list interface for each dimension / cdss / dashboard / api / knowledge / {category} / glossary to obtain the terms. Finally, it obtains the knowledge content of the terms / cdss / dashboard / api / knowledge / {category} / {entity_id}, with each term distinguished by entity_id. Step 3: Based on the acquired knowledge information, request the information through the pre-configured template; among which, based on the acquired knowledge dimension information, use cases are spliced ​​through various judgments and combination logics, stored in the preset case request template, and interface test cases are automatically generated; Step 4: Perform rule mapping and assembly to automatically generate interface test cases that adapt to the existing automated testing framework and execute the generated automation. Specifically, adapting to the existing Pytest+Requests testing framework involves reading test cases from the Excel file and performing assertion validation based on the expected rules within the test cases. Assertions are made on the message field returned by the interface request, and assertion comparisons are performed. If the assertion succeeds, the test case passes; if the assertion fails, the test case fails. The execution status is then recorded back in the Excel test cases.

2. The method for generating automated interface test cases according to claim 1, characterized in that: After clicking on the "Examination Dimension" tab, a list of each term will be displayed. Clicking on a term and clicking the "View" button will take you to the secondary tab menu bar. The knowledge dimensions include contraindications, contraindications, contraindications, medical history, surgical history, physical signs, allergies, age, marital status, physiological status, drug effects, sequential items, conflicting items, follow-up interval, custom population, and doctor's pre- / post-examination precautions. Each secondary tab dimension contains the corresponding knowledge rules for that term and is editable.

3. The method for generating automated interface test cases according to claim 1, characterized in that: The effective configuration sets the permutation and combination of rules for each term and each taboo dimension. When a taboo knowledge of a term is used, the rules in the effective configuration are read to determine whether to give a prompt.

4. The method for generating automated interface test cases according to claim 1, characterized in that: First, determine if it is an inspection dimension, then determine if it is a contraindication symptom, then determine which template to read based on the effective configuration, replace the corresponding fields in the preset template based on the read knowledge information, and assign the obtained contraindication symptom entry to the field; write the quality control point name, request data and expected results into a text file (.txt), and finally transfer the data in the text file to Excel according to the automated test case format adapted to the Pytest+Requests test framework.

Images