WO2024021877A1 - 测试进度的跟踪方法、电子设备、计算机可读存储介质 - Google Patents

测试进度的跟踪方法、电子设备、计算机可读存储介质 Download PDF

Info

Publication number
WO2024021877A1
WO2024021877A1 PCT/CN2023/098537 CN2023098537W WO2024021877A1 WO 2024021877 A1 WO2024021877 A1 WO 2024021877A1 CN 2023098537 W CN2023098537 W CN 2023098537W WO 2024021877 A1 WO2024021877 A1 WO 2024021877A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
environment
plan
automated
items
Prior art date
Application number
PCT/CN2023/098537
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 WO2024021877A1 publication Critical patent/WO2024021877A1/zh

Links

Classifications

    • 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/3688—Test management for test execution, e.g. scheduling of test suites
    • 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
    • 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/3664—Environments for testing or debugging software

Definitions

  • the present disclosure relates to the field of testing technology, and in particular to a testing progress tracking method, an electronic device, and a computer-readable storage medium.
  • the testing field mainly tracks test progress based on test time or test logs. It is usually necessary to track the test progress of manual testing and automated testing separately, but less involves simultaneous tracking of the test progress of manual testing and automated testing.
  • the creation of the current test plan relies on manual creation by test experts, which requires a lot of labor.
  • the information obtained from tracking the test progress is not rich enough, resulting in poor user experience.
  • embodiments of the present disclosure provide a method for tracking test progress, which includes: establishing a test entry pool, the test entry pool including multiple test entries; according to the test scenario in the test environment, from the test entry pool Obtain a set of items to be tested, set a test plan; schedule the test items in the test plan on the test environment, update the test progress data; and push the tracking results of the test progress according to the test progress data.
  • embodiments of the present disclosure provide an electronic device, including: at least one processor; and a memory on which at least one computer program is stored.
  • the at least one processor is caused to implement the test progress tracking method of the embodiment of the present disclosure described in the first aspect.
  • an embodiment of the present disclosure provides a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed by a processor, the method for tracking test progress of the embodiment of the present disclosure described in the first aspect is implemented. .
  • Figure 1 is a flow chart of a method for tracking test progress in an embodiment of the present disclosure
  • Figure 2 is a flow chart of some steps in a method for tracking test progress in an embodiment of the present disclosure
  • Figure 3 is a block diagram of an electronic device in an embodiment of the present disclosure.
  • Figure 4 is a block diagram of a computer-readable storage medium in an embodiment of the present disclosure.
  • Figure 5 is a schematic diagram of a test progress tracking system in an embodiment of the present disclosure.
  • Figure 6 is a schematic diagram of a test progress tracking system in an embodiment of the present disclosure.
  • test progress tracking method electronic device, and computer-readable storage medium provided by the present disclosure will be described in detail below in conjunction with the accompanying drawings.
  • an embodiment of the present disclosure provides a method for tracking test progress, including steps S1 to S4.
  • test item pool includes multiple test items.
  • test scenario in the test environment, obtain a set of items to be tested from the test item pool, and set a test plan.
  • the test items in the test item pool may include automated test items or manual test items.
  • the embodiments of the present disclosure do not impose special limitations on this.
  • the test items in the test item pool may correspond to multiple test scenarios in multiple test environments. The embodiments of the present disclosure do not impose special limitations on this.
  • obtaining a set of items to be tested from a test item pool according to the test scenario in the test environment refers to extracting the test items corresponding to the test scenario from the test item pool to form a set of items to be tested.
  • Test item collection according to different test scenarios in different test environments, it is possible to obtain test item collections corresponding to different test scenarios in different test environments.
  • the set test plan is a subset of the test items in the set of items to be tested.
  • the embodiments of the present disclosure do not impose special limitations on this.
  • scheduling test items in the test plan on the test environment may include scheduling automatic test items on the test environment, or may include scheduling manual test items on the test environment.
  • the embodiments of the present disclosure do not impose special limitations on this.
  • the test environment is a test environment for a telecommunications network gateway product
  • the test scenario is a test scenario for a telecommunications network management product.
  • test progress tracking method In the test progress tracking method provided by the embodiment of the present disclosure, a test item pool is established, and the test items can be obtained from the test item pool according to the test scenario in the test environment and the test plan can be set, and then the tests in the test plan can be During the process of scheduling and placing items, the test progress data is updated and tracking results are pushed.
  • the test progress of automated testing and manual testing can be tracked on the same system, which helps users accurately perceive test progress and control risks in real time, reducing manpower. Investment improves user experience.
  • the embodiment of the present disclosure does not place special limitations on how to schedule test items in the test plan and update test progress data on the test environment.
  • the set of items to be tested is divided into a sub-set of automatic test items and a sub-set of manual test items, and the sub-set of automatic test items and the sub-set of manual test items are classified respectively.
  • the automated test plan and manual test plan when scheduling test items in the test plan, the automated test plan and manual test plan are scheduled independently.
  • scheduling the test items in the test plan on the test environment, and updating the test progress data includes steps S31 and S32.
  • the automated test items in the set of items to be tested are classified into the automated test plan, and the manual test items in the set of items to be tested are classified into the manual test plan.
  • automated test items refer to test items that can be automated and have completed the development of automated test scripts; manual test items refer to test items that cannot be automated or have not completed the development of automated test scripts.
  • the set of items to be tested is divided into mutually independent automated test plans and manual test plans, and the automated The test plan and the manual test plan are scheduled separately, which can realize the independence of automated testing and manual testing in the same test environment, thereby avoiding the mutual interference between automated testing and manual testing on the same test environment, and is conducive to the realization of automated testing and manual testing. Simultaneous tracking of manual testing.
  • the embodiments of this disclosure do not place special limitations on how to schedule test items in the automated test plan on the test environment.
  • scheduling the test items in the automated test plan on the test environment, and updating the test progress data of the automated test plan includes: scheduling the test items in the automated test plan on the test environment according to the scheduling configuration table.
  • the test entry, the execution strategy and test environment information are configured in the scheduling configuration table; the automated test script of the test entry is retrieved according to the automated test link field of the test entry in the automated test plan stored in the test plan sub-database. and execute; and collect the environment label, version label, use case number, use case title, test results, execution time, central processing unit (CPU, Central Processing Unit) resource information, memory resource information, execution report of the test environment, update to Use case analysis subdatabase.
  • CPU Central Processing Unit
  • the embodiment of the present disclosure does not place special restrictions on the execution policy in the scheduling configuration table.
  • the execution strategy includes any one of manual triggering, implementation triggering, and scheduled triggering.
  • the test environment information includes at least one of environment access Internet Protocol (IP, Internet Protocol), environment label, and test scenario.
  • IP Internet Protocol
  • environment label IP, Internet Protocol
  • test scenario test scenario
  • test progress tracking method for test items that can be automated, automated test scripts are developed according to the test steps of the test items, and the automated test scripts are stored in the test script sub-database; set Test entries for automated test plans and manual test plans are stored in the test plan sub-database.
  • the automated test link field of the test item of the automated test plan is used to save the path of the automated test script of the test item, so that the automated test script of the test item can be retrieved according to the automated test link field of the test item and implement.
  • the automated test items in the automated test plan can be scheduled multiple times. For example, when the test result of an automated test entry is failed, The automated test entry can be rescheduled.
  • scheduling the test items in the automated test plan on the test environment, and updating the test progress data of the automated test plan further includes: when any of the test items in the automated test plan When the test result is failure and the failure reason is non-fault, the final result field of the test entry in the use case analysis sub-database is updated to require rescheduling; the use case analysis sub-database is periodically retrieved according to the environment label and version label.
  • the final result field is the test entry that needs to be rescheduled; and the final result field of scheduled rescheduling is the test entry that needs to be rescheduled.
  • the embodiment of the present disclosure does not specifically limit the reasons for the failure of test entries.
  • the reasons for failure can include problems with the test environment, test item failures, use case design issues, business interface changes, etc.
  • the failure reason of the test item is non-fault, which means that the scheduling of the test item fails due to reasons other than the test item itself. For example, a problem with the test environment causes the scheduling of the test entry to fail.
  • the embodiment of the present disclosure does not place special limitations on how to schedule test items in the manual test plan on the test environment.
  • scheduling the test items in the manual test plan on the test environment, and updating the test progress data of the manual test plan includes: obtaining the test items in the manual test plan according to the environment label and the version label, so as to obtain the test items in the manual test plan according to the environment label and the version label.
  • the test steps of the test items are manually tested on the test environment; and according to the manual test results, the test results, execution time, failure reasons, CPU resource information, and memory resource information are updated into the use case analysis sub-database.
  • the tester filters out the corresponding test items through the environment label and version label, and performs manual testing in the test environment according to the test steps of the test items.
  • the embodiment of the present disclosure places no special limitations on how to establish a test entry pool.
  • establishing a test entry pool includes steps S11 to S13.
  • test items Add test items to the test item pool according to a predefined test item template.
  • steps S12 to S13 are only executed for test items that can be automated. Steps S11 to S13 are executed iteratively, and each iteration adds a test entry to the test entry pool. After several iterations, a pool of test entries was established.
  • the test entry template is predefined.
  • a user adds test items to a pool of test items based on a test item template.
  • the user analyzes whether the test items in the test item pool can be automated, and for the test items that can be automated, an automated test script is developed according to the test steps of the test item.
  • the automated test script in addition to executing test steps, can also automatically collect the environment label, version label, use case number, use case title, test result, execution time, and CPU resource information of the test environment after completing the test business. Memory resource information and execution reports are updated to the use case analysis sub-database.
  • the test item template is stored in the test item template sub-database, and the test items added to the test item pool are stored in the test item sub-database. Since the test entry is set based on the test entry template, the fields that make up the test entry are consistent with the fields that make up the test entry template.
  • This embodiment of the present disclosure does not place special limitations on the fields that make up the test entry template and the fields that make up the test entry.
  • test items in the test item pool are stored in a test item sub-database
  • test items stored in the test item sub-database include: use case number field, use case title field, test step field, expected result Fields, test scenario fields, automation identification fields, and automation test link fields.
  • the embodiment of this disclosure does not place any special limitations on how to set the test plan.
  • the set of items to be tested is divided into a sub-set of automatic test items and a sub-set of manual test items, and the sub-set of automatic test items and the sub-set of manual test items are classified respectively.
  • Plan for automated tests and manual tests to be able to schedule test items in the test plan Schedule automated test plans and manual test plans independently.
  • a set of items to be tested is obtained from the test item pool, and a test plan is set, including steps S21 to S23.
  • test entries of the set automated test plan and manual test plan are stored in the test plan sub-database.
  • the automated test plan and the manual test plan are stored in a test plan sub-database
  • the test entries stored in the test plan sub-database include: environment label field, version label field, use case number Fields, use case title field, test step field, test result field, test result field, automation identification field, automation test link field, latest result field, final result field, failure reason field, CPU resource field, memory resource field.
  • the automation identification field is used to indicate whether the test item has been automated, that is, whether the test item can be automated, and if it can be automated, whether the automated test script development has been completed. For example, if the test item cannot be automated or the automated test script development has not been completed when it can be automated, the test item has not been automated; if the test item can be automated and the automated test script development has been completed, the test item has been automated.
  • the embodiment of this disclosure does not place any special limitations on how to push the tracking results of the test progress based on the test progress data.
  • pushing the tracking results of the test progress according to the test progress data includes steps S41 and S42.
  • test progress tracking results of each test version in each test environment are automatically generated based on the environment tag and version tag, which can ensure the accuracy of the tracking results, help users accurately perceive the test progress and version quality, and track the test progress and version quality in real time. Control risks.
  • the embodiment of the present disclosure does not place special limitations on the tracking results.
  • the tracking results are used to display the implementation progress of the test services of each test environment and each test version, so that test progress early warnings can be pushed.
  • pushing the tracking results of the test progress of the test plans of each test environment and each test version according to the summary results includes: according to the summary results, real-time tracking of the test plans of each test environment and each test version. Provide early warning of test progress.
  • At least one of the failure reasons of failed use cases in different test versions in the same test environment or the resource information of successful use cases can be compared, thereby helping users perceive the quality of different test versions.
  • the tracking results of testing progress of the test plans of each test environment and each test version are pushed according to the summary results including: comparing the failure reasons of failed test entries in the same test environment and different test versions, or successful tests At least one of the resource information of the entry; push the comparison result.
  • the resource information includes CPU resource information, memory resource information, etc.
  • the embodiment of this disclosure does not place any special restrictions on how to push the tracking results.
  • the tracking results are displayed to the user's browser in real time through external web services.
  • the tracking results are periodically pushed to the user's mailbox through an external email service.
  • an embodiment of the present disclosure provides an electronic device, including: at least one processor 101; and a memory 102 on which at least one computer program is stored.
  • the at least one computer program is executed by at least one processor , causing at least one processor to implement the test progress tracking method of the embodiment of the present disclosure described in the first aspect; and
  • At least one I/O interface 103 is connected between the processor 101 and the memory 102, and is configured to realize information exchange between the processor 101 and the memory 102.
  • the processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU), etc.; the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); the I/O interface (read-write interface) 103 is connected between the processor 101 and the memory 102, and can realize processing
  • the information exchange between the device 101 and the memory 102 includes but is not limited to a data bus (Bus), etc.
  • processor 101 memory 102, and I/O interface 103 are connected to each other and, in turn, to other components of the computing device via bus 104.
  • an embodiment of the present disclosure provides a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed by a processor, the test progress of the embodiment of the present disclosure described in the first aspect is realized. tracking method.
  • This example is mainly aimed at the simultaneous tracking and real-time perspective of the two test progresses of automated testing and manual testing of multiple test scenarios and multi-project versions of telecommunications network management products.
  • test entry pool has fields such as case number, use case name, test steps, test scenarios, whether it has been automated, and automated test links. Users add test entries to the test entry pool according to the defined test entry template.
  • automated test plans and manual test plans are adaptively created and adjusted. These two test plans adaptively extract a subset of automated test items with environment labels and version labels from the test item pool based on the test scenario and version information of the test environment and whether the test items have been automated ( (i.e., automated test plan) and a subset of manual test items (i.e., manual test plan). All test items under the two test plans are automatically synchronized to the database periodically, and the maximum value of each test item in the database is New results and final results are uniformly initialized to untested.
  • automated test items can be scheduled multiple times, and can be mixed with manual test plans on the same test environment.
  • the scheduling module schedules the test items under the test plan on the test environment based on the execution strategy and test environment fields in the scheduling configuration table.
  • Each test item retrieves the corresponding automated test script based on its own automated test link field.
  • the scheduling management periodically retrieves the automated test items that need to be rescheduled from the database and reschedules them regularly; for manual test plans, The tester filters out the corresponding test items through the environment label and version label, performs manual testing in the test environment according to the displayed test steps, and updates the relevant information to the database.
  • This example provides test progress warning. Based on the environment tag and version tag, this example automatically and quickly summarizes the test progress data of each test environment in each version and then pushes the warning on demand (such as: real-time display on the large screen, scheduled push by email), and at the same time, it also looks into the results of different versions in the same environment. By comparing the failure reasons of failed test items with the resource information of successful test items, users can accurately perceive the current test progress and version quality, and realize real-time control of risks.
  • test progress tracking system in this example can communicate with all test environments of the object being tested.
  • the test results are stored in the system's database in real time.
  • the system collects statistics and summarizes the test progress data in the database, and then externally
  • the web service displays the summary results of the test progress to the user's browser in real time, and periodically pushes the summary results of the test progress to the user's mailbox through the external email service.
  • test progress tracking system in this example is shown in Figure 6, including: test item pool management, test script library, test plan management, scheduling management, use case analysis management, and summary push management.
  • Test item pool management Users add test items to the test item pool according to the defined test item template.
  • the test item template includes use case number, use case title, test Fields such as steps, expected results, test scenarios, whether it has been automated, automated test links, etc. All test items and test item templates in the test item pool are stored in the database system.
  • Test script library Automated test script developers develop automated test scripts according to the test steps of a certain test item in the test item pool. The developed test item updates the two field values of whether it has been automated and the automated test link.
  • Test plan management The system obtains the test scenario from the test environment through the remote service adapter, and then extracts the corresponding set of items to be tested from the test item pool according to the test scenario, then tracks whether the test items have been automated, and returns the set of items to be tested to Classify two subsets of automated test plans and manual test plans, and then label the two test plan subsets with environment labels and version labels based on the version fields and environment fields of the test environment. Finally, the two test plans are periodically synchronized to In the database system, each test entry in the database contains fields such as environment label, version label, use case number, use case title, test steps, test results, whether it has been automated, automated test links, etc. The latest results and final results of each test entry in the database All initialized as untested.
  • Scheduling management is based on the execution strategy (such as manual trigger, real-time trigger, scheduled trigger) and test environment information (such as environment access IP, environment label, version label, test scenario) fields in the scheduling configuration table in the test environment. Schedule the test items under the test plan. Each test item retrieves the corresponding automated test script according to its own automated test link field. After each automated test script completes its own business test, it automatically collects the environment label, version label, and Fields such as use case number, use case title, test results, execution time, and test execution report are updated to the database. Scheduling management will also periodically retrieve automated test entries that need to be rescheduled from the database for regular rescheduling.
  • execution strategy such as manual trigger, real-time trigger, scheduled trigger
  • test environment information such as environment access IP, environment label, version label, test scenario
  • Use case analysis and management For the manual test plan, the tester filters out the corresponding manual test entries on the test progress tracking system through the environment label and version label, then performs manual testing in the test environment according to the displayed test steps, and finally updates the final results to Database systems.
  • the test analyst For automated test items, if the latest result is failure, the test analyst will analyze the cause of the failure based on the execution report at the corresponding time point, and update the cause of the failure (such as failure, environmental issues, use case design issues, business interface changes, etc.) to the database. If The reason for the failure analyzed is non-business failure (for example: problems with the environment itself - broken links), use case analysis The final result of human correction is rescheduling, and the scheduling management will reschedule regularly.
  • Summary push management Based on the environment tag and version tag, the system automatically summarizes the test progress data of each test environment in each version and then pushes the warning on demand (for example: real-time display on the big screen, scheduled push by email), while also looking into different versions in the same environment. Comparison of the failure reasons of failed test entries and the resource information of successful test entries. Users can accurately perceive the current testing progress and the quality of product versions in iterative evolution, and can control risks in real time, which can greatly reduce the human investment in tedious data sorting, summary, and reporting.
  • the tracking of test progress includes: establishment of test item pool, setting of test plan, update of progress data, and push of test progress perspective.
  • Test entry pool creation Phase 1: Users add test items to the test item pool according to the defined test item template.
  • the test entry template contains fields such as use case number, use case title, test steps, expected results, test scenarios, whether it has been automated, and automated test links.
  • the second stage The user analyzes whether a certain test item in the test item pool can be automated. If the test item is determined to be automated after analysis, the automated test script will be developed according to the test steps of the test item. Each automated test script In addition to completing the implementation of the test steps, the collection of environment information, version information, and resource information (such as CPU, memory, etc.) will also be added.
  • environment information such as CPU, memory, etc.
  • test entry pool For test entries that have completed the development of automated test scripts, the user updates the whether the test entry has been automated field in the test entry pool to Yes, and adds the path of the automated test script to the automated test link field. After multiple iterations of the above three stages, the test entry pool was gradually established.
  • the test entry pool is divided into two sub-test entry pools from the dimension of whether it has been automated: automated test entry pool and manual test entry pool; it is divided into multiple sub-test entry pools from the test scenario: test scenario 1 test entry pool, test scenario 2 test Item pool,..., test scenario N test item pool. All test items and test item templates of the entire test item pool are stored in the test item sub-database and test item template sub-database in the database, and all automated test scripts are stored in the test script sub-database in the database.
  • Test plan settings Adaptively extract the corresponding set of items to be tested from the test item pool according to the test scenario of the test environment, then track whether the test items have been automated, and classify the set of items to be tested into two subsets: automated test plans and manual test plans. Then, based on the version field and environment field of the test environment, the two test plan subsets are labeled with environment labels and version labels. Finally, the two test plans are periodically synchronized to the test plan sub-database of the database. Each test in this sub-database is Entries include environment label, version label, use case number, use case title, test steps, test results, whether it has been automated, automated test links, latest results, final results, failure reasons, CPU resources, memory resources and other fields. Each entry in this sub-database The latest results and final results of each test item are initialized to untested.
  • Automated test items can be scheduled multiple times and can be mixed with manual test plans on the same test environment.
  • the scheduling module schedules on the test environment according to the execution strategy (such as manual trigger, real-time trigger, scheduled trigger) and test environment information (such as environment access IP, environment label, test scenario) in the scheduling configuration table.
  • each test item retrieves the corresponding automated test script according to its own automated test link field.
  • each automated test script completes its own business test, it automatically collects the environment label, version label, and use case number of the test environment. , use case title, test results, execution time, CPU resources, memory resources together with execution report and other information are updated to the use case analysis sub-database in the database.
  • the test results are updated to the latest results in the use case analysis sub-database. field, the test analyst combines the execution report at the corresponding time point to analyze the cause of the failure and confirm the cause of the failure (for example: failure, environmental problems, use case design problems, business interface changes, etc.), if the cause of this failure is non-fault (for example: the environment itself problem), the use case analyst updates the final result to rescheduling. Scheduling management will periodically retrieve all test entries under the environment label and version label in the use case analysis sub-database that ultimately result in rescheduling, and reschedule the above test entries regularly.
  • the tester filters out the corresponding test items in the system through the environment label and version label, performs manual testing in the test environment according to the displayed test steps, and updates the test results, execution time, failure reasons, CPU resources, and memory resources. information into the use case analysis subdatabase.
  • Test progress perspective push Based on the environment tags and version tags, the system automatically summarizes the test progress data of each test environment in each version in real time from the use case analysis sub-database, and then pushes the test progress data on demand (such as large-screen real-time display, scheduled email push), and can also see through the same Reasons for failure and successful testing of failed test entries in different versions of the environment Comparison of resource information for entries. Users can accurately perceive the current testing progress and the quality of product versions in iterative evolution, and can control risks in real time, which can greatly reduce the human investment in tedious data sorting, summary, and reporting.
  • Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).
  • computer storage media includes volatile and nonvolatile media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. removable, removable and non-removable media.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassettes, tapes, disk storage or other magnetic storage devices, or may Any other medium used to store desired information and that can be accessed by a computer.
  • communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开提供一种测试进度的跟踪方法，包括：建立测试条目池，所述测试条目池中包括多个测试条目；根据测试环境中的测试场景，从所述测试条目池中获取待测试条目集合，设定测试计划；在所述测试环境上调度所述测试计划中的测试条目，更新测试进度数据；以及根据所述测试进度数据推送测试进度的跟踪结果。本公开还提供一种电子设备、一种计算机可读存储介质。

Description

测试进度的跟踪方法、电子设备、计算机可读存储介质
相关申请的交叉引用
本申请要求于2022年7月28日提交的中国专利申请NO.202210900624.3的优先权，该中国专利申请的内容通过引用的方式整体合并于此。
技术领域
本公开涉及测试技术领域，特别涉及测试进度的跟踪方法、电子设备、计算机可读存储介质。
背景技术
测试领域主要基于测试时间或测试日志对测试进度进行跟踪，通常需要对手动测试和自动化测试的测试进度分别进行跟踪，而较少涉及手动测试和自动化测试的测试进度的同时跟踪。此外，当前测试计划的创建依赖于测试专家的手工创建，需要耗费大量的人工，而且对测试进度进行跟踪所获取的信息也不够丰富，用户体验不佳。
公开内容
第一方面，本公开实施例提供一种测试进度的跟踪方法，包括：建立测试条目池，所述测试条目池中包括多个测试条目；根据测试环境中的测试场景，从所述测试条目池中获取待测试条目集合，设定测试计划；在所述测试环境上调度所述测试计划中的测试条目，更新测试进度数据；以及根据所述测试进度数据推送测试进度的跟踪结果。
第二方面，本公开实施例提供一种电子设备，包括：至少一个处理器；以及存储器，其上存储有至少一个计算机程序，当所述至少一个计算机程序被所述至少一个处理器执行时，使得所述至少一个处理器实现第一方面所述的本公开实施例的测试进度的跟踪方法。
第三方面，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的本公开实施例的测试进度的跟踪方法。
附图说明
图1是本公开实施例中一种测试进度的跟踪方法的流程图；
图2是本公开实施例中一种测试进度的跟踪方法中部分步骤的流程图；
图3是本公开实施例中一种电子设备的组成框图；
图4是本公开实施例中一种计算机可读存储介质的组成框图；
图5是本公开实施例中一种测试进度跟踪系统的示意图；
图6是本公开实施例中一种测试进度跟踪系统的示意图。
具体实施方式
为使本领域的技术人员更好地理解本公开的技术方案，下面结合附图对本公开提供的测试进度的跟踪方法、电子设备、计算机可读存储介质进行详细描述。
在下文中将参考附图更充分地描述示例实施例，但是所述示例实施例可以以不同形式来体现，且本公开不应当被解释为限制性的。提供这些实施例的目的在于使本公开更加透彻和完整，并使本领域技术人员充分理解本公开的范围。
在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。
如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。
本文所使用的术语仅用于描述特定实施例，且不限制本公开。如本文所使用的，单数形式“一个”和“该”也包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在特定特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、 步骤、操作、元件、组件和/或其群组。
除非另外限定，否则本文所用的所有术语(包括技术术语和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。
第一方面，参照图1，本公开实施例提供一种测试进度的跟踪方法，包括步骤S1至S4。
S1、建立测试条目池，所述测试条目池中包括多个测试条目。
S2、根据测试环境中的测试场景，从所述测试条目池中获取待测试条目集合，设定测试计划。
S3、在所述测试环境上调度所述测试计划中的测试条目，更新测试进度数据。
S4、根据所述测试进度数据推送测试进度的跟踪结果。
在本公开实施例提供的测试进度的跟踪方法中，测试条目池中的测试条目可以包括自动化测试条目，也可以包括手动测试条目。本公开实施例对此不做特殊限定。在本公开实施例提供的测试进度的跟踪方法中，测试条目池中的测试条目可以对应于多个测试环境中的多个测试场景。本公开实施例对此不做特殊限定。
在本公开实施例提供的测试进度的跟踪方法中，根据测试环境中的测试场景从测试条目池中获取待测试条目集合，是指从测试条目池中提取该测试场景对应的测试条目，组成待测试条目集合；根据不同测试环境中的不同测试场景，能够获取对应不同测试环境中的不同测试场景的待测试条目集合。
在一些实施方式中，设定的测试计划为待测试条目集合中的测试条目所组成的子集合。本公开实施例对此不做特殊限定。
在本公开实施例提供的测试进度的跟踪方法中，在测试环境上调度测试计划中的测试条目，可以包括在测试环境上调度自动测试条目，也可以包括在测试环境上调度手动测试条目。本公开实施例对此不做特殊限定。
在一些实施方式中，测试环境为电信网网关产品的测试环境，测试场景为电信网网管产品的测试场景。本公开实施例对此不做特殊限定。
本公开实施例提供的测试进度的跟踪方法中，建立了测试条目池，并能够根据测试环境中的测试场景从测试条目池中获取测试条目并设定测试计划，然后在对测试计划中的测试条目进行调度放入过程中，更新测试进度数据、推送跟踪结果，能够在同一系统上对自动化测试和手动测试的测试进度进行跟踪，有利于用户精确感知测试进度并实时把控风险，减少了人力投入，提升了用户体验。
本公开实施例对于如何在测试环境上调度测试计划中的测试条目并更新测试进度数据不做特殊限定。
在一些实施方式中，根据测试条目是否为自动化测试条目，将待测试条目集合划分为自动测试条目子集合和手动测试条目子集合，并将自动测试条目子集合和手动测试条目子集合分别归类为自动化测试计划和手动测试计划，在调度测试计划中的测试条目时，对自动化测试计划和手动测试计划独立进行调度。
相应地，在一些实施方式中，参照图2，在所述测试环境上调度所述测试计划中的测试条目，更新测试进度数据包括步骤S31和S32。
S31、在所述测试环境上调度自动化测试计划中的测试条目，更新所述自动化测试计划的测试进度数据。
S32、在所述测试环境上调度手动测试计划中的测试条目，更新所述手动测试计划的测试进度数据。
所述待测试条目集合中的自动化测试条目归类为所述自动化测试计划，所述待测试条目集合中的手动测试条目归类为所述手动测试计划。
需要说明的是，自动化测试条目是指能够自动化并已完成自动化测试脚本开发的测试条目；手动测试条目是指无法自动化或未完成自动化测试脚本开发的测试条目。
在本公开实施例提供的测试进度的跟踪方法中，将待测试条目集合划分为相互独立的自动化测试计划和手动测试计划，并对自动化 测试计划和手动测试计划分别进行调度，能够实现自动化测试和手动测试在同一测试环境上测试业务的独立，从而能够避免同一测试环境上自动化测试和手动测试的相互干扰，有利于实现对自动化测试和手动测试的同时跟踪。
本公开实施例对如何在测试环境上调度自动化测试计划中的测试条目不做特殊限定。
在一些实施方式中，在所述测试环境上调度自动化测试计划中的测试条目，更新所述自动化测试计划的测试进度数据包括：根据调度配置表在所述测试环境上调度所述自动化测试计划中的测试条目，所述调度配置表中配置有执行策略、测试环境信息；根据测试计划子数据库存储的所述自动化测试计划中的测试条目的自动化测试链接字段，检索所述测试条目的自动化测试脚本并执行；以及采集所述测试环境的环境标签、版本标签、用例编号、用例标题、测试结果、执行时间、中央处理器(CPU，Central Processing Unit)资源信息、内存资源信息、执行报告，更新到用例分析子数据库。
本公开实施例对调度配置表中的执行策略不做特殊限定。例如，执行策略包括手工触发、实施触发、定时触发中的任意一者。
本公开实施例对调度配置表中的测试环境信息也不做特殊限定。例如，测试环境信息包括环境接入网际互连协议(IP，Internet Protocol)、环境标签、测试场景中的至少一者。
需要说明的是，在本公开实施例提供的测试进度的跟踪方法中，对于能够自动化的测试条目，根据测试条目的测试步骤开发自动化测试脚本，自动化测试脚本存储在测试脚本子数据库中；设定的自动化测试计划和手动测试计划的测试条目存储在测试计划子数据库中。测试计划子数据库中，自动化测试计划的测试条目的自动化测试链接字段用于保存该测试条目的自动化测试脚本的路径，从而能够根据测试条目的自动化测试链接字段，检索该测试条目的自动化测试脚本并执行。
在一些实施方式中，对于自动化测试计划中的自动化测试条目，能够多次编排调度。例如，在自动化测试条目的测试结果为失败时， 能够对该自动化测试条目进行重新调度。
相应地，在一些实施方式中，在所述测试环境上调度自动化测试计划中的测试条目，更新所述自动化测试计划的测试进度数据还包括：当任意一个所述自动化测试计划中的测试条目的测试结果为失败、且失败原因为非故障时，更新所述用例分析子数据库中所述测试条目的最终结果字段为需要重新调度；根据环境标签和版本标签，周期性检索所述用例分析子数据库中最终结果字段为需要重新调度的测试条目；以及定时重新调度最终结果字段为需要重新调度的测试条目。
本公开实施例对测试条目失败的原因不做特殊限定。例如，失败原因可以包括测试环境的问题、测试条目故障、用例设计问题、业务接口变更等。需要说明的是，在本公开实施例中，测试条目的失败原因为非故障，是指由测试条目自身因素以外的原因导致对该测试条目的调度失败。例如，由测试环境的问题导致对该测试条目的调度失败。
本公开实施例对于如何在测试环境上调度手动测试计划中的测试条目不做特殊限定。
在一些实施方式中，在所述测试环境上调度手动测试计划中的测试条目，更新所述手动测试计划的测试进度数据包括：根据环境标签和版本标签获取手动测试计划中的测试条目，以根据所述测试条目的测试步骤在所述测试环境上进行手动测试；以及根据手动测试结果，更新测试结果、执行时间、失败原因、CPU资源信息、内存资源信息到用例分析子数据库中。
需要说明的是，在本公开实施例中，对于手动测试计划，测试人通过环境标签和版本标签过滤出对应的测试条目，根据测试条目的测试步骤在测试环境中进行手动测试。
本公开实施例对于如何建立测试条目池不做特殊限定。
在一些实施方式中，参照图2，建立测试条目池包括步骤S11至S13。
S11、根据预先定义的测试条目模板向所述测试条目池中添加测试条目。
S12、获取所述测试条目的自动化测试脚本。
S13、更新所述测试条目的自动化标识，将所述自动化测试脚本的路径添加到所述测试条目中。
在本公开实施例提供的测试进度的跟踪方法中，对于能够自动化的测试条目，才执行步骤S12至步骤S13。步骤S11至步骤S13是迭代执行的，每一次迭代向测试条目池中添加一个测试条目。经过多次迭代，建立起测试条目池。
在本公开实施例中，预先定义了测试条目模板。在一些实施方式中，用户根据测试条目模板向测试条目池中添加测试条目。在一些实施方式中，用户分析测试条目池中的测试条目是否能够自动化，对于能够自动化的测试条目，根据测试条目的测试步骤开发自动化测试脚本。在一些实施方式中，自动化测试脚本除了执行测试步骤之外，还能够在完成测试业务之后自动采集测试环境的环境标签、版本标签、用例编号、用例标题、测试结果、执行时间、CPU资源信息、内存资源信息、执行报告，更新到用例分析子数据库。
在本公开实施例中，测试条目模板存储在测试条目模板子数据库中，添加到测试条目池中的测试条目存储在测试条目子数据库中。由于测试条目是根据测试条目模板设置的，故而组成测试条目的字段与组成测试条目模板的字段保持一致。
本公开实施例对组成测试条目模板的字段和组成测试条目的字段不做特殊限定。
在一些实施方式中，在测试条目子数据库中存储所述测试条目池中的测试条目，所述测试条目子数据库中存储的测试条目包括：用例编号字段、用例标题字段、测试步骤字段、期望结果字段、测试场景字段、自动化标识字段、自动化测试链接字段。
本公开实施例对于如何设定测试计划不做特殊限定。
在一些实施方式中，根据测试条目是否为自动化测试条目，将待测试条目集合划分为自动测试条目子集合和手动测试条目子集合，并将自动测试条目子集合和手动测试条目子集合分别归类为自动化测试计划和手动测试计划，从而能够在调度测试计划中的测试条目时 对自动化测试计划和手动测试计划独立进行调度。
相应地，在一些实施方式中，参照图2，根据测试环境中的测试场景，从所述测试条目池中获取待测试条目集合，设定测试计划，包括步骤S21至S23。
S21、从所述测试条目池中获取所述测试场景对应的测试条目，组成所述待测试条目集合。
S22、将所述待测试条目集合中的自动化测试条目归类为自动化测试计划，将所述待测试条目集合中的手动测试条目归类为手动测试计划。
S23、为所述自动化测试计划和所述手动测试计划中的测试条目添加环境标签和版本标签。
在本公开实施例中，设定的自动化测试计划和手动测试计划的测试条目存储在测试计划子数据库中。
相应地，在一些实施方式中，在测试计划子数据库中存储所述自动化测试计划和所述手动测试计划，所述测试计划子数据库存储的测试条目包括：环境标签字段、版本标签字段、用例编号字段、用例标题字段、测试步骤字段、测试结果字段、测试结果字段、自动化标识字段、自动化测试链接字段、最新结果字段、最终结果字段、失败原因字段、CPU资源字段、内存资源字段。
需要说明的是，自动化标识字段用于指示测试条目是否已自动化，也就是表示该测试条目是否能够自动化、以及在能够自动化的情况下是否已完成自动化测试脚本开发。例如，若测试条目无法自动化或在能够自动化的情况下未完成自动化测试脚本开发，则该测试条目未自动化；若测试条目能够自动化且自动化测试脚本开发已完成，则该测试条目已自动化。
本公开实施例对于如何根据测试进度数据推送测试进度的跟踪结果不做特殊限定。
在一些实施方式中，参照图2，根据所述测试进度数据推送测试进度的跟踪结果包括步骤S41和S42。
S41、根据环境标签和版本标签从用例分析子数据库中汇总各个 测试环境、各个测试版本的测试计划的测试进度数据。
S42、根据汇总结果推送各个测试环境、各个测试版本的测试计划的测试进度的跟踪结果。
在本公开实施例中，基于环境标签和版本标签自动化生成各个测试环境下各个测试版本的测试进度跟踪结果，能够确保跟踪结果的准确性，有利于用户精确感知测试进度和版本质量，并实时把控风险。
本公开实施例对跟踪结果不做特殊限定。
在一些实施方式中，跟踪结果用于展示各个测试环境、各个测试版本的测试业务的实施进度，从而能够进行测试进度预警推送。
相应地，在一些实施方式中，根据汇总结果推送各个测试环境、各个测试版本的测试计划的测试进度的跟踪结果包括：根据所述汇总结果，对各个测试环境、各个测试版本的测试计划的实时的测试进度进行预警。
在一些实施方式中，能够对同一测试环境下不同测试版本中失败用例的失败原因、或成功用例的资源信息中的至少一者进行对比，从而有利于用户感知不同测试版本的质量。
相应地，在一些实施方式中，根据汇总结果推送各个测试环境、各个测试版本的测试计划的测试进度的跟踪结果包括：对比相同测试环境、不同测试版本中失败测试条目的失败原因、或成功测试条目的资源信息中的至少一者；推送对比结果。
需要说明的是，资源信息包括CPU资源信息、内存资源信息等。
本公开实施例对于如何推送跟踪结果不做特殊限定。
在一些实施方式中，通过对外web服务将跟踪结果实时展示到用户浏览器。
在一些实施方式中，通过对外邮件服务周期性地将跟踪结果推送到用户邮箱。
第二方面，参照图3，本公开实施例提供一种电子设备，包括：至少一个处理器101；存储器102，其上存储有至少一个计算机程序，当至少一个计算机程序被至少一个处理器执行时，使得至少一个处理器实现第一方面所述的本公开实施例的测试进度的跟踪方法；以及 至少一个I/O接口103，连接在处理器101与存储器102之间，配置为实现处理器101与存储器102的信息交互。
处理器101为具有数据处理能力的器件，包括但不限于中央处理器(CPU)等；存储器102为具有数据存储能力的器件，包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)；I/O接口(读写接口)103连接在处理器101与存储器102间，能实现处理器101与存储器102的信息交互，包括但不限于数据总线(Bus)等。
在一些实施方式中，处理器101、存储器102和I/O接口103通过总线104相互连接，进而与计算设备的其它组件连接。
第三方面，参照图4，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现第一方面所述的本公开实施例的测试进度的跟踪方法。
为了使本领域技术人员能够更清楚地理解本公开实施例提供的技术方案，下面通过具体的3个实例，对本公开实施例提供的技术方案进行详细说明：
实例一
本实例主要是针对电信网网管产品的多测试场景、多项目版本的自动化测试和手动测试两种测试进度的同时跟踪与实时透视。
本实例定义了测试条目池。测试条目池中的每条测试条目有用例编号、用例名称、测试步骤、测试场景、是否已自动化、自动化测试链接等字段，用户按照已定义的测试条目模板添加测试条目到测试条目池中。
本实例中自适应创建、调整自动化测试计划和手动测试计划。这两个测试计划依据测试环境的测试场景和版本信息以及测试条目是否已自动化这两个维度，自适应地从测试条目池中分别抽取出带有环境标签和版本标签的自动化测试条目子集合(即自动化测试计划)和手动测试条目子集合(即手动测试计划)，两个测试计划下的全部测试条目周期性地自动同步到数据库中，数据库中每条测试条目的最 新结果、最终结果统一初始化为未测试。
本实例中自动化测试条目可以多次编排调度，并且可以和手动测试计划在同一个测试环境上混合执行。对于自动化测试计划，调度模块根据调度配置表中的执行策略和测试环境字段在测试环境上调度该测试计划下的测试条目，每条测试条目依据自身的自动化测试链接字段检索到对应的自动化测试脚本，每条自动化测试脚本完成自身业务测试后自动采集相关信息更新到数据库中，调度管理周期性地从数据库中检索出中需重新调度的已自动化的测试条目进行定时重新调度；对于手动测试计划，测试人通过环境标签和版本标签过滤出对应的测试条目，根据展示的测试步骤在测试环境进行手动测试，更新相关信息到数据库中。
本实例提供测试进度预警。本实例基于环境标签和版本标签自动且快速地汇总出各个测试环境在各个版本的测试进度数据后按需预警推送(比如：大屏实时展示、邮件定时推送)，同时透视同一环境下不同版本中失败测试条目的失败原因与成功测试条目的资源信息的对比，用户可以对当前测试进度和版本质量精确感知，能够实现对风险的实时把控。
实例二
本实例应用于迭代周期中手动测试和自动化测试两种测试进度都需要持续性跟进，并且被测对象有多种不同测试场景与测试版本的场景。如图5所示，本实例中的测试进度跟踪系统与被测对象的所有测试环境都能网络互通，测试结果实时存储到系统的数据库里，系统统计汇总数据库中的测试进度数据，随后通过对外web服务将测试进度的汇总结果实时展示到用户浏览器、同时通过对外邮件服务周期性将测试进度的汇总结果推送到用户邮箱。
本实例中的测试进度跟踪系统的架构如图6所示，包括：测试条目池管理、测试脚本库、测试计划管理、调度管理、用例分析管理、汇总推送管理。
测试条目池管理：用户按照已定义好的测试条目模板添加测试条目到测试条目池中，测试条目模板包含用例编号、用例标题、测试 步骤、期望结果、测试场景、是否已自动化、自动化测试链接等字段，测试条目池中全部测试条目和测试条目模板都存储到数据库系统。
测试脚本库：自动化测试脚本开发者按照测试条目池中的某条测试条目的测试步骤进行自动化测试脚本的开发，开发完毕的测试条目更新其是否已自动化和自动化测试链接这两个字段值。
测试计划管理：系统通过远程服务适配器从测试环境获取到测试场景，再按照该测试场景从测试条目池中提取对应的待测试条目集合，随之跟踪测试条目是否已自动化，将待测试条目集合归类成自动化测试计划和手动测试计划两个子集，之后再依据测试环境的版本字段和环境字段，给两个测试计划子集打上环境标签和版本标签，最后周期性地将两个测试计划同步到数据库系统中，数据库每条测试条目包含环境标签、版本标签、用例编号、用例标题、测试步骤、测试结果、是否已自动化、自动化测试链接等字段，数据库中每条测试条目的最新结果、最终结果都初始化为未测试。
调度管理：调度管理根据调度配置表中的执行策略(如：手工触发、实时触发、定时触发)、测试环境信息(如：环境接入IP、环境标签、版本标签、测试场景)字段在测试环境上调度该测试计划下的测试条目，每条测试条目依据自身的自动化测试链接字段检索到对应的自动化测试脚本，每条自动化测试脚本完成自身业务测试后自动采集测试环境的环境标签、版本标签、用例编号、用例标题、测试结果、执行时间连同测试执行报告等字段更新到数据库。调度管理还会周期性从数据库中检索出需重新调度的已自动化的测试条目进行定时重新调度。
用例分析管理：对于手动测试计划，测试人通过环境标签和版本标签在该测试进度跟踪系统上过滤出对应的手动测试条目，再按照展示的测试步骤在测试环境进行手动测试，最后更新最终结果到数据库系统。对于自动化测试条目，如果最新结果是失败，测试分析人结合对应时间点的执行报告来分析失败原因，更新失败原因(比如：故障、环境问题、用例设计问题、业务接口变更等)到数据库，若分析的失败原因是非业务故障(比如：环境自身问题-断链)，用例分析 人修正最终结果为重新调度，调度管理会定时重新调度。
汇总推送管理：该系统基于环境标签和版本标签自动汇总出各个测试环境在各个版本的测试进度数据后按需预警推送(比如：大屏实时展示、邮件定时推送)，同时透视同一环境下不同版本中失败测试条目的失败原因及成功测试条目的资源信息的对比。用户对当前测试进度和迭代演进中产品版本质量可精确感知，对风险可实时把控，能够大大降低在繁琐的数据整理、汇总、汇报中的人力投入。
实例三
本实例中测试进度的跟踪包括：测试条目池的建立、测试计划的设定、进度数据的更新、测试进度透视推送。
测试条目池的建立。第一阶段：用户按照已定义好的测试条目模板添加测试条目到测试条目池中。测试条目模板包含用例编号、用例标题、测试步骤、期望结果、测试场景、是否已自动化、自动化测试链接等字段。第二阶段：用户分析测试条目池中的某条测试条目是否可自动化，若经分析认定该条测试条目可自动化，就按照该测试条目的测试步骤进行自动化测试脚本的开发，每条自动化测试脚本除完成测试步骤的实现外还会增加对环境信息、版本信息、资源信息(如CPU、内存等)的采集。第三阶段：已完成自动化测试脚本开发的测试条目由用户更新测试条目池中该条测试条目的是否已自动化字段为是、将自动化测试脚本的路径添加到自动化测试链接字段。上述三个阶段多次迭代，测试条目池逐渐建立起来。测试条目池从是否已自动化这个维度上划分成两个子测试条目池：自动化测试条目池、手动测试条目池；从测试场景划分为多个子测试条目池：测试场景1测试条目池、测试场景2测试条目池、……、测试场景N测试条目池。整个测试条目池的全部测试条目和测试条目模板都存储到数据库中测试条目子数据库和测试条目模板子数据库，全部自动化测试脚本都存储到数据库中测试脚本子数据库。
测试计划的设定。根据测试环境的测试场景从测试条目池自适应地提取对应的待测试条目集合，再跟踪测试条目是否已自动化，将待测试条目集合归类成自动化测试计划和手动测试计划两个子集，之 后再依据测试环境的版本字段和环境字段，给两个测试计划子集打上环境标签和版本标签，最后周期性地将两个测试计划同步到数据库中测试计划子数据库，该子数据库每条测试条目包含环境标签、版本标签、用例编号、用例标题、测试步骤、测试结果、是否已自动化、自动化测试链接、最新结果、最终结果、失败原因、CPU资源、内存资源等字段，该子数据库中每条测试条目的最新结果、最终结果都初始化为未测试。
进度数据的更新。自动化测试条目可以多次编排调度并且可以和手动测试计划在同一个测试环境上混合执行。对于自动化测试计划，调度模块根据调度配置表中的执行策略(如：手工触发、实时触发、定时触发)、测试环境信息(比如：环境接入IP、环境标签、测试场景)在测试环境上调度该测试计划下的测试条目，每条测试条目依据自身的自动化测试链接字段检索到对应的自动化测试脚本，每条自动化测试脚本完成自身业务测试后自动采集测试环境的环境标签、版本标签、用例编号、用例标题、测试结果、执行时间、CPU资源、内存资源连同执行报告等信息更新到数据库中用例分析子数据库，如果首次调度的测试结果是失败，该测试结果更新到用例分析子数据库中最新结果字段，测试分析人结合对应时间点的执行报告来分析失败原因，确认失败原因(比如：故障、环境问题、用例设计问题、业务接口变更等)，若本次失败原因是非故障(比如：环境自身问题)，用例分析人更新最终结果为重新调度。调度管理会周期性检索用例分析子数据库中该环境标签和版本标签下最终结果为重新调度的全部测试条目，并对上述测试条目进行定时重新调度。对于手动测试计划，测试人通过环境标签和版本标签在系统中过滤出对应的测试条目，根据展示的测试步骤在测试环境进行手动测试，更新测试结果、执行时间、失败原因、CPU资源、内存资源信息到用例分析子数据库中。
测试进度透视推送。该系统基于环境标签和版本标签自动从用例分析子数据库中实时汇总出各个测试环境在各个版本的测试进度数据后按需预警推送(比如：大屏实时展示、邮件定时推送)，同时可透视同一环境下不同版本中失败测试条目的失败原因及成功测试 条目的资源信息的对比。用户对当前测试进度和迭代演进中产品版本质量可精确感知，对风险可实时把控，能够大大降低在繁琐的数据整理、汇总、汇报中的人力投入。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器(如中央处理器、数字信号处理器或微处理器)执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其它的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其它传输机制之类的调制数据信号中的其它数据，并且可包括任何信息递送介质。
本文已经公开了部分实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不是限制性的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则与特定实施例相结合描述的特征、特性和/或元素可单独使用，或可与结合其它实施例描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims (14)

  1. 一种测试进度的跟踪方法，包括：
    建立测试条目池，其中，所述测试条目池中包括多个测试条目；
    根据测试环境中的测试场景，从所述测试条目池中获取待测试条目集合，设定测试计划；
    在所述测试环境上调度所述测试计划中的测试条目，更新测试进度数据；以及
    根据所述测试进度数据推送测试进度的跟踪结果。
  2. 根据权利要求1所述的方法，其中，在所述测试环境上调度所述测试计划中的测试条目，更新测试进度数据包括：
    在所述测试环境上调度自动化测试计划中的测试条目，更新所述自动化测试计划的测试进度数据；
    在所述测试环境上调度手动测试计划中的测试条目，更新所述手动测试计划的测试进度数据；
    其中，所述待测试条目集合中的自动化测试条目归类为所述自动化测试计划，所述待测试条目集合中的手动测试条目归类为所述手动测试计划。
  3. 根据权利要求2所述的方法，其中，在所述测试环境上调度自动化测试计划中的测试条目，更新所述自动化测试计划的测试进度数据包括：
    根据调度配置表在所述测试环境上调度所述自动化测试计划中的测试条目，其中，所述调度配置表中配置有执行策略、测试环境信息；
    根据测试计划子数据库存储的所述自动化测试计划中的测试条目的自动化测试链接字段，检索所述测试条目的自动化测试脚本并执行；以及
    采集所述测试环境的环境标签、版本标签、用例编号、用例标 题、测试结果、执行时间、CPU资源信息、内存资源信息、执行报告，更新到用例分析子数据库。
  4. 根据权利要求3所述的方法，其中，在所述测试环境上调度自动化测试计划中的测试条目，更新所述自动化测试计划的测试进度数据还包括：
    当任意一个所述自动化测试计划中的测试条目的测试结果为失败、且失败原因为非故障时，更新所述用例分析子数据库中所述测试条目的最终结果字段为需要重新调度；
    根据环境标签和版本标签，周期性检索所述用例分析子数据库中最终结果字段为需要重新调度的测试条目；以及
    定时重新调度最终结果字段为需要重新调度的测试条目。
  5. 根据权利要求2所述的方法，其中，在所述测试环境上调度手动测试计划中的测试条目，更新所述手动测试计划的测试进度数据包括：
    根据环境标签和版本标签获取手动测试计划中的测试条目，以根据所述测试条目的测试步骤在所述测试环境上进行手动测试；以及
    根据手动测试结果，更新测试结果、执行时间、失败原因、CPU资源信息、内存资源信息到用例分析子数据库中。
  6. 根据权利要求1至5中任意一项所述的方法，其中，建立测试条目池包括：
    根据预先定义的测试条目模板向所述测试条目池中添加测试条目；获取所述测试条目的自动化测试脚本；以及
    更新所述测试条目的自动化标识，将所述自动化测试脚本的路径添加到所述测试条目中。
  7. 根据权利要求6所述的方法，其中，在测试条目子数据库中存储所述测试条目池中的测试条目，所述测试条目子数据库中存储的 测试条目包括：用例编号字段、用例标题字段、测试步骤字段、期望结果字段、测试场景字段、自动化标识字段、自动化测试链接字段。
  8. 根据权利要求1至5中任意一项所述的方法，其中，根据测试环境中的测试场景，从所述测试条目池中获取待测试条目集合，设定测试计划包括：
    从所述测试条目池中获取所述测试场景对应的测试条目，组成所述待测试条目集合；
    将所述待测试条目集合中的自动化测试条目归类为自动化测试计划，将所述待测试条目集合中的手动测试条目归类为手动测试计划；以及
    为所述自动化测试计划和所述手动测试计划中的测试条目添加环境标签和版本标签。
  9. 根据权利要求8所述的方法，其中，在测试计划子数据库中存储所述自动化测试计划和所述手动测试计划，所述测试计划子数据库存储的测试条目包括：环境标签字段、版本标签字段、用例编号字段、用例标题字段、测试步骤字段、测试结果字段、测试结果字段、自动化标识字段、自动化测试链接字段、最新结果字段、最终结果字段、失败原因字段、中央处理器(CPU)资源字段、内存资源字段。
  10. 根据权利要求1至5中任意一项所述的方法，其中，根据所述测试进度数据推送测试进度的跟踪结果包括：
    根据环境标签和版本标签从用例分析子数据库中汇总各个测试环境、各个测试版本的测试计划的测试进度数据；以及
    根据汇总结果推送各个测试环境、各个测试版本的测试计划的测试进度的跟踪结果。
  11. 根据权利要求10所述的方法，其中，根据汇总结果推送各个测试环境、各个测试版本的测试计划的测试进度的跟踪结果包括：
    根据所述汇总结果，对各个测试环境、各个测试版本的测试计划的实时的测试进度进行预警。
  12. 根据权利要求10所述的方法，其中，根据汇总结果推送各个测试环境、各个测试版本的测试计划的测试进度的跟踪结果包括：
    对比相同测试环境、不同测试版本中失败测试条目的失败原因、或成功测试条目的资源信息中的至少一者；以及
    推送对比结果。
  13. 一种电子设备，包括：
    至少一个处理器；以及
    存储器，其上存储有至少一个计算机程序，当所述至少一个计算机程序被所述至少一个处理器执行时，使得所述至少一个处理器实现根据权利要求1至12中任意一项所述的测试进度的跟踪方法。
  14. 一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求1至12中任意一项所述的测试进度的跟踪方法。
PCT/CN2023/098537 2022-07-28 2023-06-06 测试进度的跟踪方法、电子设备、计算机可读存储介质 WO2024021877A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210900624.3A CN117520137A (zh) 2022-07-28 2022-07-28 测试进度的跟踪方法、电子设备、计算机可读介质
CN202210900624.3 2022-07-28

Publications (1)

Publication Number Publication Date
WO2024021877A1 true WO2024021877A1 (zh) 2024-02-01

Family

ID=89705318

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/098537 WO2024021877A1 (zh) 2022-07-28 2023-06-06 测试进度的跟踪方法、电子设备、计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN117520137A (zh)
WO (1) WO2024021877A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103077109A (zh) * 2009-12-28 2013-05-01 中兴通讯股份有限公司 一种测试计划调度方法及系统
CN107273286A (zh) * 2017-06-02 2017-10-20 携程计算机技术（上海）有限公司 针对任务应用的场景自动化测试平台及方法
CN108984418A (zh) * 2018-08-22 2018-12-11 中国平安人寿保险股份有限公司 软件测试管理方法、装置、电子设备及存储介质
CN114328226A (zh) * 2021-12-28 2022-04-12 苏州浪潮智能科技有限公司 一种测试计划数据生成方法及相关装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103077109A (zh) * 2009-12-28 2013-05-01 中兴通讯股份有限公司 一种测试计划调度方法及系统
CN107273286A (zh) * 2017-06-02 2017-10-20 携程计算机技术（上海）有限公司 针对任务应用的场景自动化测试平台及方法
CN108984418A (zh) * 2018-08-22 2018-12-11 中国平安人寿保险股份有限公司 软件测试管理方法、装置、电子设备及存储介质
CN114328226A (zh) * 2021-12-28 2022-04-12 苏州浪潮智能科技有限公司 一种测试计划数据生成方法及相关装置

Also Published As

Publication number Publication date
CN117520137A (zh) 2024-02-06

Similar Documents

Publication Publication Date Title
US10255081B2 (en) Method and system for intelligent cloud planning and decommissioning
US8255899B2 (en) Techniques for upgrade dependency management
US8793660B2 (en) Automated testing of programming code for a web service
US8281187B1 (en) Unified and extensible meta-testing framework
US9292343B2 (en) Method and system for performing deployment management
US20080010535A1 (en) Automated and configurable system for tests to be picked up and executed
US8930772B2 (en) Method and system for implementing a test automation results importer
US9164759B2 (en) Test management domain asset discovery and analysis
US9819547B2 (en) Server provisioning based on job history analysis
US20150121155A1 (en) Performing customized deployment scenarios in shared environments
US10922216B1 (en) Intelligent automation test workflow
US10713070B2 (en) Systems and methods for capturing and visualizing user interactions across devices
US11954123B2 (en) Data processing method and device for data integration, computing device and medium
US10901984B2 (en) Enhanced batch updates on records and related records system and method
CN112650688A (zh) 自动化回归测试方法、关联设备以及计算机程序产品
CN110795332A (zh) 一种自动化测试方法和装置
CN110716804A (zh) 无用资源的自动删除方法、装置、存储介质及电子设备
WO2024021877A1 (zh) 测试进度的跟踪方法、电子设备、计算机可读存储介质
US9053084B1 (en) Self-service testing
CN111190817B (zh) 软件缺陷的处理方法及装置
CN110968511A (zh) 一种推荐引擎的测试方法、装置、计算设备和系统
CN113220592B (zh) 自动化测试资源的处理方法、装置、服务器及存储介质
CN112604295A (zh) 游戏更新失败的上报方法、装置及管理方法、服务器
US11762875B2 (en) Machine assisted data aggregation
CN113407445B (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: 23845090

Country of ref document: EP

Kind code of ref document: A1