RU2774659C1 - System for controlling software testing - Google Patents

Abstract

FIELD: computing technology.

SUBSTANCE: invention relates to the field of computer technology, in particular, to systems for testing control. The system for controlling software testing has a "client-server" architecture initiated by means of docker containerisation and containing at least one server configured to perform interaction between subsystems through requests of a distributed application in a REST API network, wherein the project subsystem is configured to store test documentation, the test library subsystem is configured to store test documentation and create a hierarchical structure of the project, the test plan subsystem is configured to schedule testing, determine the scope of scheduled testing, distribute testing tasks between performers, the configuration subsystem is configured to store and manage configurations, the automated test subsystem is configured to store information on the automated tests registered in the system, the request subsystem is configured to filter and search for test documentation.

EFFECT: increase in the quality of software testing.

18 cl, 1 tbl, 8 dwg

Description

FIELD OF TECHNOLOGY

[001] This technical solution relates in general to the field of computer technology, and in particular to test management systems designed for orderly storage of test documentation, test planning, as well as standardization and storage of information about the results of manual and automated testing in a single environment and reporting .

BACKGROUND OF THE INVENTION

[002] Currently, test management systems are used to store information on how to properly conduct testing, the implementation of the order of testing in accordance with its plan, and to obtain information in the form of reports on the stage of testing and the quality of the product under test, or in other words software. The tools have different approaches to testing and thus include different feature sets. They are usually used to plan manual testing, collect data on the results of passing checklists and test cases, as well as to obtain operational information in the form of reports. Test management systems help streamline the testing process and provide quick access to data analysis, collaboration tools, and better communication between multiple project teams. Many test management systems include the ability to work with requirements.

[003] The disadvantages of manual testing, which is very common throughout software analysis, are quite clear and obvious. Manual testing is much slower than automatic testing. Sometimes it can take a couple of weeks manually instead of one hour by script, in other cases the ratio may fluctuate within smaller limits. At the same time, a well-written script does not make mistakes and does not miss defects, tired of the monotonous routine day after day, unlike an engineer. Manually, it is almost impossible to execute scenarios that require high speed of action or extremely high accuracy in time.

[004] In the prior art, the method disclosed in CN106897217A "Testing Method and Testing Apparatus" (patent holder: BEIJING QUNAR SOFTWARE TECH CO LTD, publication date: 2017-06-27) is known. The invention claims a testing method and a testing apparatus, the method comprising the following steps: receiving at least one request message, wherein the request message is used to test the program, at least one request message is sent to the version check program to obtain the first test result and sending to the stable version of the program to obtain the second test result, while the stable version program is a query message, can return the result of the program, comparing the first test result and the second test result, obtaining a comparison result, while the comparison result is intended for determining the functional stability of the test version. The invention solves the problem that the test case tests the code in the prior art, thereby increasing the cost of maintaining the software in the prior art.

ESSENCE OF THE TECHNICAL SOLUTION

[005] The technical problem or technical problem solved in this technical solution is the creation of an automated software testing management system.

[006] The technical result achieved by solving the above technical problem is to improve the quality of automated software testing.

[007] An additional achievable technical result is the ordered storage of test documentation, taking into account all versions of the document with the ability to restore any version of the document if necessary.

[008] Also carried out

• use of a single point of obtaining information for making managerial decisions;

• the possibility of implementing a quality control process, provided by universal customizable user attributes in the system;

• distribution of access levels to test documentation and test results, which allows you to restrict access to the information contained in it, which may be a commercial secret.

[009] The specified technical result is achieved thanks to the software test management system, which contains at least one server configured to interact between subsystems through distributed application requests on the network; a subsystem of projects, made with the ability to store test documentation and manage testing for each individual project and generate reports in the context of projects; a test library subsystem configured to store test documentation and create a hierarchical project structure, develop and approve test documentation; a test plan subsystem configured to plan testing, determine the scope of planned testing, distribute tasks for testing between performers, in accordance with the user's workload level; a configuration subsystem configured to store configurations on which testing is carried out in the project, manage their settings; an automated test subsystem configured to store information about automated tests registered in the system, as well as view and analyze data on passing automated tests; a query subsystem configured to filter and search test documentation for projects and manage saved filters.

[0010] In some implementations of the technical solution, the test library subsystem has a structure for storing test cases, divided by functional areas of the product under test.

[0011] In some implementations of the technical solution, the test plan subsystem contains the results of testing.

[0012] In some embodiments of a technical solution, the test plan subsystem generates reports on individual testing iterations within the test plans.

[0013] In some implementations of the technical solution, the automated test subsystem contains information reflecting meta-information about the automated test and/or its name, and/or associated test cases, and/or attachment links.

[0014] In some embodiments of a technical solution in an automated test subsystem, an automated test is a program code that emulates the actions of users or a third-party system in the product being tested.

[0015] In some embodiments of a technical solution, an automated test is registered in the automated test subsystem.

[0016] In some embodiments of a technical solution in the automated test subsystem, the results of the automated test are recorded using the API.

[0017] In some embodiments of the technical solution, when registering the result, the outcome is indicated and supplemented with the passage time and / or attached files, and / or the results of each step.

[0018] In some embodiments of the technical solution in the automated test subsystem, in case of unsuccessful passing of the tests, messages about the detected errors and detailed reports about them that are generated when passing the automated test are applied to the result of passing the automated test.

[0019] In some embodiments of the technical solution in the automated test subsystem, after receiving the results of the automated test, when parsing the received data, the class and category of the problem are indicated.

[0020] In some embodiments of the technical solution, the query subsystem displays all test cases and checklists to which the user has access.

[0021] In some implementations of the technical solution in the query subsystem, the search is performed on the server using filters on user attributes and/or priorities and/or statuses.

[0022] In some implementations of the technical solution in the query subsystem, the search is performed on all test cases and checklists to which the user has read access.

[0023] In some implementations of the technical solution in the query subsystem, the query is stored filters.

[0024] In some implementations of a technical solution in the query subsystem, when a query is opened, a list of all test cases and checklists that match the saved filters is displayed.

[0025] In some implementations of the technical solution in the request subsystem, the request is private or public.

[0026] In some embodiments of the technical solution, the request is opened by a link or posted on an external resource.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The features and advantages of the present technical solution will become apparent from the following detailed description and the accompanying drawings, in which:

[0028] In FIG. 1 shows an example of the implementation of the scheme of interaction with external services of the software testing management system.

[0029] In FIG. 2 shows an example implementation of a software test management system.

[0030] In FIG. 3 shows an example of the implementation of the project subsystem.

[0031] In FIG. 4 shows an implementation of a software test management system.

[0032] In FIG. Figure 5 shows an example implementation of the test library subsystem designed to store test documentation.

[0033] In FIG. Figure 6 shows an example of the implementation of the test plan subsystem, which is designed for testing planning, determining the scope of planned testing, and distributing tasks for testing between performers.

[0034] In FIG. Figure 7 shows an example of the implementation of the configuration subsystem, which is designed to store configurations on which testing is carried out in the project, and manage their settings.

[0035] In FIG. Figure 8 shows a variant of the implementation of the autotest subsystem, which is designed to store information about automated tests registered in the test management system, as well as view and analyze data on passing automated tests.

DETAILED DESCRIPTION OF THE INVENTION

[0036] Below will be discussed in detail the terms and their definitions used in the description of the technical solution.

[0037] In this invention, the system refers to a computer system, a computer (electronic computer), CNC (numerical control), PLC (programmable logic controller), computerized control systems and any other devices capable of performing a given, well-defined sequence of operations (actions, instructions), centralized and distributed databases, smart contracts.

[0038] A command processing device means an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs), a smart contract, or the like. An instruction processing device reads and executes machine instructions (programs) from one or more data storage devices. The role of a storage device can be, but not limited to, hard disk drives (HDD), flash memory, ROM (read only memory), solid state drives (SSD), optical drives.

[0039] A program (sometimes "software") is a sequence of instructions intended to be executed by a computer control device or command processing device.

[0040] In FIG. Figure 1 shows an example of the implementation of a scheme for the interaction of a software testing management system with external services, which are described below.

[0041] Browser 130 is software for browsing web pages. The user's work with the technical solution is carried out through the user interface displayed in the browser 130. The user interface can be developed, for example, on the Angular framework, which is a cross-platform JavaScript framework that works with HTML using static and dynamic information received from the application server 100 via API (Application Programming Interface, Application Programming Interface).

[0042] REST (RESTful) is the general principles for organizing the interaction of an application/site with the server 100 via the HTTP protocol. The peculiarity of REST is that the server 100 does not remember the state of the user between requests - in each request, information is transmitted that identifies the user (for example, a token obtained through OAuth authorization) and all the parameters necessary to complete the operation.

[0043] A continuous integration system 140 (eg, Jenkins, Gitlab, etc.) is software designed for automated code building. In the field of testing, continuous integration systems are used to build code for automated tests. This system integrates with continuous integration systems 140 through Webhook technology, as well as API. Webhook is a system callback on the occurrence of some event in this system. For example, the system has the ability to create a Webhook for creating an autotest run. If a new run of Autotests is created in the system, the previously specified query is executed.

[0044] Issue tracking system 160 (eg, Jira) is software designed for project management in the IT field. Integrates with this system through a plugin and / or API. This system creates duplicate test cases in the 160 issue tracking system, obtains information about the status of issues and their priorities, and creates defects / errors (jar. "bugs") in the 160 issue tracking system. Integration is two-way, any links created in the system , are created as external links in the issue tracker 160.

[0045] AD/LDAP 150 is a directory service that provides authentication functions, management of users and their groups, permissions. It integrates with the system in terms of obtaining 150 users and groups from AD/LDAP for further issuing roles and permissions in the system. The software test management system obtains a list of users and groups from AD/LDAP 150, also strips them of their roles, and removes them from the system if they lose access on the AD/LDAP 150 side.

[0046] OpenID Connect provider 160 is a service implemented using the OpenID Connect protocol designed to authenticate users in a system based on the Oauth 2.0 protocol. Integration with the software testing management system is implemented using the OpenID Connect protocol and is configured in the admin panel. Settings on the system side allow you to integrate with any service that supports the OpenID Connect protocol in terms of creating users and authenticating them in the system. Users get the opportunity to log in through a single authentication service. Some implementations may use biometric authentication algorithms, two-factor authentication, access key authentication, token authentication, etc., but are not limited to.

[0047] This technical solution is a software test management system that is used to store test documentation (test plans, test suites, test cases and checklists with functionality checks, test results in accordance with its plan, as well as reports about the testing stage in the form of a document that provides information about the tests performed, their results, testers who participated in testing, defects found, etc., without limitation) and the implementation of automated software testing management. Based on this information, conclusions can be drawn about the quality of the tested product or, in other words, software.

[0048] A test case (hereinafter referred to as a “test case”) is a document that describes a sequence of steps, specific conditions and parameters necessary to verify the implementation of a tested software function or part of it, as well as the expected results of passing these steps. The test case is formed on the basis of functional and non-functional requirements for the developed software.

[0049] The quality of the product in this context refers to the quality of the software under test, namely the degree to which the implemented software meets the requirements and suitability for use.

[0050] The test documentation describes how to use the software, in accordance with the requirements for the system. Any inconsistencies of the software under test with the original requirements are regarded as defects (jar. "bugs").

[0051] The presence of defects (slang. "bugs") is regarded as a lack of quality. In addition to the initial requirements for the software being developed, the suitability of the software for use, i.e. alignment of use cases with end user expectations.

[0052] A test plan (hereinafter referred to as the “test plan”) is a document describing the scope of testing work, containing information about the test object, testing strategy, testing deadlines, criteria for starting and completing testing, as well as a list of checks that should be passed.

[0053] A test execution report is a document that summarizes the results of testing work and contains information sufficient to correlate the current quality of the software being developed with the test plan and make management decisions.

[0054] Test documentation is any artifacts obtained during the planning, execution and recording of test results. At the stage of preparation for testing, test cases and checklists for them are formed (a document regulating what constitutes the success of passing a test case). At the test planning stage, a test plan is formed. Based on the results of testing, a report on the results of testing is generated. All this is a test documentation in the aggregate.

[0055] The test management system has a client-server architecture. "Client - server" (English client-server) - a computing or network architecture in which tasks or network load are distributed between service providers, called servers, and service customers, called clients.

[0056] The client in this case is a browser 130, which opens a graphical user interface (eng. "GUI"), designed to interact with the user of the system with the server 100 through the use of interface components.

[0057] The server 100 in this case are the components of the system that receive and process requests from the client (i.e., from the browser), as well as send requests to the client and other external systems to obtain information.

[0058] Docker containerization tools are used to deploy and run the system. Docker containerization is a technology that allows you to programmatically configure the environment in isolation in a certain area of memory, as well as install operating systems and software products inside various containers. Containerization allows you to flexibly configure environment settings inside containers without changing the settings of the global server. The system is deployed and launched using docker compose, which allows you to run several containers interconnected, a separate service is deployed in each container, the links are configured in accordance with the specified parameters. Docker Compose is a tool included with Docker. It is designed to solve problems related to the deployment of projects. Docker is a software for automating the deployment and management of applications in containerized environments, an application containerizer.

[0059] One of the distinguishing features of this technical solution is the presence of common steps. A common step is an entity that allows you to store and reuse repeated steps across different test cases. When you create a general step, it includes individual test steps that are repeated for several test cases. As an example of implementation, we can give authorization on the site under test. To perform most checks, you must first log in as a user. This step will be repeated in many test cases when testing the operation of the website. The system allows you to create a common step that contains the actions required to enter the website and use it in all checks. At the same time, changing the common step entails changing it in all test cases where it is used. Thus, only one general step needs to be changed, and not all test cases where it is mentioned, which saves testing time.

[0060] This solution also implements versioning of test cases, which implies the ability to view previous versions of documents after they have been changed, “roll back” to previous versions, and when viewing, differences between versions are highlighted.

[0061] One of the distinguishing features of this solution is the ability to jointly analyze the results of manual and automated testing, and based on the results of testing, a single report is generated within the entire test plan, where you can see whether the test was automated or manually passed. Within one test plan, you can run automated tests (hereinafter referred to as autotests) and manual tests, while on the execution screen you can see which test cases are automated, i.e. have attached autotests, and which ones are passed only manually. By selecting automated tests, you can run autotests, run autotests. In parallel, you can run manual tests, noting their results. As you run all the tests, you can see the real-time results of both manual and automated tests in the Report tab, with details of the result. When you open a test run, you can also see all the autotests that have passed.

[0062] The test management system is designed for complex information and analytical support of processes at enterprises engaged in software development in terms of the execution of the following processes:

• creation of test documentation (test cases, checklists);

• storage of test documentation in a hierarchical structure, providing easy search and navigation through sections;

• approval of test documentation;

• formation of lists of test cases for passing, united by common features (release, task, etc.);

• test planning;

• registration of test results and storage of results history;

• construction of reporting on testing and test documentation in projects;

• monitoring the execution of automated testing.

[0063] The software test management system consists of a number of subsystems that implement different functionality, which are all interconnected functionally and in hardware. Interaction between subsystems is provided on server 100 using REST API requests.

[0064] The following is a summary of the characteristics and description of each subsystem, as shown in FIG. 2, as well as the interaction between them.

[0065] The projects subsystem 310, as shown in FIG. 3 includes separate entities intended for storing test documentation and testing management, delimiting rights between them, as well as generating reports in the context of projects. Project 310.1 is an isolated repository for test documentation (test cases, checklists), test plans, test results. All data is stored in project 310.1, and access is limited, the contents of the project are visible only to those team members (user 320 in Fig. 3) who have explicitly received a role in project 310.1. Project roles are formed in the admin panel and represent a set of permissions and access levels for 320 users to sections of the project. These project roles are then assigned in the project to users 320, whereupon the users 320 gain access to sections of the project 310.1 according to their project role. On FIG. 2 shows a diagram of the system components and their connections in more detail. The system may store multiple projects 310.1 as shown in FIG. 3, with access distribution configured in the administration module. At the same time, project 310.1 contains such submodules as a test library, configurations, test parameters, autotests, requirements, defects (shown in Fig. 3).

[0066] The test library subsystem 510 shown in FIG. 5, designed to store test documentation, is a section in which the hierarchical structure of the project 310.1 is created, test documentation is developed and agreed upon. Within project 310.1, a folder structure is created to store test cases, divided by functional areas of the product being tested. This organized storage of documentation ensures that test documentation is easy to manage and searchable for users. The test library subsystem 510 acts as a repository for test documentation, the entities stored in it contain the test scripts used in planning and executing tests in test cases of test plans. Test cases and checklists are used to create test cases in test plans, and general steps are generated for use in test cases. The description of test scripts stored in the test library can be manual or automated based on autotests. Inside the subsystem of the test library, search, filtering, with the ability to save filters, sorting, as well as opening certain sections and tests by direct link, are implemented.

[0067] The test plan subsystem 610 shown in FIG. 6 is designed for planning testing, determining the scope of planned testing, distributing tasks for testing between performers, in accordance with the level of workload. This section also reflects the results of test execution and reports on individual test iterations within test plans 620. Test plans 620 include test suites consisting of test cases and checklists obtained from the test library subsystem 510. In addition, , it is possible to create test suites based on the library of tests from the subsystem 510, or on the saved filters in the library. A test suite is a folder with tests that must be performed, after creating a test suite, the configuration is applied to it, on which testing will be carried out. Configuration parameters are obtained from the configuration subsystem present in each project. Test plan 620 is a set of tests to pass, tied to certain configurations, and makes it possible to run both manual and automated testing within the test plan 620. When you start the execution of automated tests, a test run is formed. A test run is a run of some kind of test in accordance with a predetermined test plan. The results of manual tests are specified by users manually, with the ability to comment on steps, attach files and links to any external sources, including links to defects, requirements, code repositories and any other related resources. The results of automated tests when executed in a test plan can be obtained from an external automated testing tool or a continuous integration tool 140 and delivered via APIs, plug-ins or integration libraries.

[0068] Test planning is the stage of testing during which the purpose of the test is determined, the timing of the test is indicated, sets of checks are formed that must be performed during testing based on the needs of the test, and test performers are also designated. This test management system allows you to automate the test planning process by generating a test plan 620, automatically generating test sets for passing based on a test library from the test library subsystem 510, or manually at the discretion of the user. To distribute tasks between performers, both manual and automatic methods are used. With automatic distribution of tasks between executors, each executor is assigned a set of tasks to perform testing with equal estimates of the time for passing the test. The time for passing the test is set for each case automatically based on previous passes, or manually by the test executor or his supervisor.

[0069] For example, a simplified test would look as shown in Table 1 below.

[0070] The configuration subsystem 710, as shown in FIG. 7 is designed to store configurations on which testing is carried out in the project, to manage their settings. Configurations are used to store and communicate data about the environments that are being tested. The environment is a set of options that reproduce the conditions necessary for the software under test to work, such as operating systems, browsers, devices, etc. In configurations in the form of "key" - "value" these options are set. The configuration can be used in automated testing to prepare the desired environment by obtaining configuration parameters. The configurations module is used in test plans 620 in conjunction with tests to create test tasks, namely representing which test should be run on which configuration. The configuration is applied to the test cases of the test plan 620. In addition, the configurations stored in the project 310.1 are used to generate automated test runs (so-called test runs). These links provide the ability to build reporting in the dashboard subsystem (to be discussed below) grouped by configuration, i.e. viewing data on the results of manual and automated tests, test plans and test runs in the context of configurations.

[0071] Autotest subsystem 810 shown in FIG. 8 is intended for storing information about automated tests registered in the test management system, as well as viewing and analyzing data on passing automated tests. The test management system stores information that reflects meta-information about the autotest, its name, related test cases, specific steps, links, attachments, etc. To register an autotest in the test management system, API 820 (application programming interface, API) is used. After an autotest is registered in the system, it becomes possible to save and analyze data on its passage, evaluate its impact on the results of related tests. An automated test is a program code that emulates the actions of users or a third-party system in the product being tested. The results of an automated test are also recorded in the test management system using API 820. When registering the result of an automated test, you can specify the outcome, as well as supplement it with meta-information - the time of passing, additional data in the form of attached files (screenshots, logs), the results of passing each step . In case of unsuccessful passing of tests, you can attach to the result of passing an automated test messages about detected errors and detailed reports about them, which are generated during the passage of an automated test. Integration with automated tests using the API allows you to use any test automation tools. After receiving the results of an automated test, when parsing the received data, you can specify the class and category of the problem. This feature is used for automated analysis of problem categories. The autotest module allows you to register automated tests in the system, autotests are associated with manual tests in the library, as well as with test parameters stored in the 310.1 project, which provides the ability to perform manual and automated testing together within 620 test plans, as well as the ability to register execution results automated tests separate from manual tests within test plans 620. Information about autotests and the results of their execution is obtained from the continuous integration tool 140 and delivery, or from the automated testing tool, through API 820, plug-ins and client libraries. Autotests and their results can be displayed in dashboard widgets, in accordance with the widget settings.

[0072] The test run module is designed to collect information about the execution of automated tests in the external environment using an automated testing tool. Run data is received from automated testing tools and continuous integration tools 140 and delivery.

[0073] A query subsystem (not shown in the figures) that filters and searches test documentation for projects, with the ability to manage saved filters. The requests section displays all test cases and checklists to which the user has access. The search is performed on the server 100 using various filters. Filtering is available by all parameters and additional data, such as user attributes, priorities, statuses. The search is performed on all test cases and checklists to which the user has at least read access. You can create a set of filters and save the query. The request is a saved filters. When you open a query, a list of all test cases and checklists that match the saved filters is displayed. The result changes if the actual values of the parameters contained in the request change in some of the output cases. Requests can be made private (available only to the user) or public (available to all users of the system). The request can be opened by link, which allows you to transfer the link to other users, or place it somewhere on external resources. In queries, a search is performed on the data stored in the test libraries for all available projects, the data in the query subsystem comes from many projects, but taking into account access rights.

[0074] A dashboard subsystem (not shown in the figures) that generates project reporting. Dashboard is a data visualization and analysis tool. Simply put, infographics are one of the components of a dashboard. Each dashboard is a set of customizable widgets. A widget is a primitive graphical user interface that has a standard appearance and performs standard actions. When creating a widget, you can choose the type of information presentation, the data source for generating the report, and additionally group the received values by individual parameters depending on the data source. A flexible system for creating widgets allows you to display most of the necessary information stored in the system in a convenient presentation. Available views are trend chart, pie charts, bar charts, table view. Available data sources are tests, test results, test plans, automated test runs. Thus, the dashboard subsystem is connected with all other functional areas of the system. reporting in widgets can have any data stored within projects, test libraries, configurations, test parameters, autotests, requirements, and defects as data sources. Requirements reporting capabilities include requirements tracing, a requirements test coverage matrix, and an indirect relationship between requirements and defects found as a result of the execution of tests associated with them.

[0075] The software test management system interacts with a bug tracking system 160, such as Jira, through a plugin installed in Jira version 7.2.13 and higher.

[0076] The system may interact with AD/LDAP directory services 150 to obtain user and group data and authorize them in the system to provide resources.

[0077] Also, the system supports an event notification mechanism that accesses the API of third-party systems (continuous integration systems, instant messengers, etc.).

[0078] The test parameters module provides storage of test data that can be used to parameterize and manage tests, both manual and automated. This module is a stored list of variables with values. These variables can be called from test steps to select which parameters should be used within the test. Test parameters are also related to passing a test in a test plan or an autotest in a test run. The result of the test execution stores information with what parameters this test was launched and passed. Also, this module implies the possibility of automatic generation of test data.

[0079] The requirements module provides the ability to manage requirements, their establishment, storage and modification, specifying their links with tests for further reporting in the dashboard module.

[0080] The defect module provides the ability to manage defects and tasks, store defects and tasks, change their statuses, indicate links with requirements and tests, for further reporting on defects and tasks in the dashboard module. Defect module data can be integrated with external task/defect tracking tools, integration implies two-way communication of defects within the test management system and in an external tool, inheritance of the status model and workflows of defect and task entities, the ability to obtain additional information about defects/tasks from an external tool .

[0081] Referring to FIG. 4, this solution may be implemented as a software test management computer system 400 that includes one or more of the following components:

• a processing component 401 comprising at least one processor 402,

• memory 403,

• multimedia component 405,

• audio component 406,

• interface 407 input / output (I / O),

• sensor component 408,

• component 409 data.

[0082] The processing component 401 mainly manages all operations of the system 400, such as processing user data or testing request, and managing the display, phone call, data transmission, camera operation, and recording operation of the mobile communication device. Processing component 401 may include one or more processors 402 executing instructions for completing all or part of the steps from the above methods. In addition, the processing component 401 may include one or more modules for convenient interaction between other processing modules 401 and other modules. For example, the processing component 401 may include a multimedia module for convenient, lightweight interaction between the multimedia component 405 and the processing component 401.

[0083] The memory 403 is configured to store various types of data to support the operation of the system 400, such as a user profile database. Examples of such data include instructions from any application or method, contact data, address book data, messages, images, videos, etc., all of which run on system 400. Memory 403 may be implemented as any type of volatile memory, non-volatile memory, or combinations thereof, e.g., static random access memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory device (ROM), magnetic memory, flash memory, magnetic disk or optical disk, and others, without being limited.

[0084] The media component 405 includes a screen that provides an output interface between the system 400, which may be installed on the user's mobile communications device, and the user. In some implementations, the screen may be a liquid crystal display (LCD) or a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input from a user. The touchpad includes one or more touch sensors in terms of gestures, touching and sliding on the touchpad. The touch sensor can not only sense the subject's touch boundary or swipe gesture, but also determine the length of time and pressure associated with the touch and slide operation mode. In some embodiments, media component 405 includes one front camera and/or one rear camera. When the system 400 is in an operating mode, such as shooting mode or video mode, the front camera and/or rear camera can receive media data from outside. Each front camera and rear camera may have one fixed lens optics or may have focal length or optical zoom.

[0085] The audio component 406 is configured to output and/or input an audio signal. For example, the audio component 406 includes one microphone (MIC) that is configured to receive an external audio signal when the system 400 is in an operating mode, such as a call mode, a recording mode, and a speech recognition mode. The received audio signal may be further stored in the memory 403 or routed through the communication component 409 . In some embodiments, the audio component 406 also includes a single speaker configured to output an audio signal.

[0086] An input/output (I/O) interface 407 provides an interface between the processing component 401 and any peripheral interface module. The above peripheral interface module may be a keyboard, steering wheel, button, etc. These buttons may include, but are not limited to, a start button, a volume button, a home button, and a lock button.

[0087] The touch component 408 includes one or more sensors and is configured to provide various aspects of estimating the state of the system 400. For example, the touch component 408 can detect the on/off states of the system 400, the relative position of components, such as a display and a keypad, of a single component system 400, the presence or absence of contact between a subject and system 400, as well as the orientation or acceleration/deceleration and temperature change of system 400. Sensor component 408 includes a proximity sensor configured to detect the presence of a nearby object when there is no physical contact. The sensor component 408 includes an optical sensor (eg, CMOS or CCD image sensor) configured for use in rendering an application. In some embodiments, the sensor component 408 includes an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0088] The communication component 409 is configured to facilitate wired or wireless communication between the system 400 and other devices. System 400 may access a wireless network based on a communication standard such as WiFi, 2G, 3G, 5G, or combinations thereof. In one exemplary embodiment, the communication component 409 receives a broadcast signal or broadcast related information from an external broadcast control system via a broadcast channel. In one embodiment, communication component 409 includes a Near Field Communication (NFC) module to facilitate near field communication. For example, the NFC module may be based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0089] In an exemplary embodiment, system 400 may be implemented by one or more Application-Specific Integrated Circuits (ASICs), a Digital Signal Processor (DSP), a Digital Signal Processor (DSP), a Programmable Logic Unit (PLU), a logic chip programmable in operating conditions (FPGA), controller, microcontroller, microprocessor or other electronic components, and can be configured to implement a software test management method.

[0090] In an exemplary embodiment, the non-volatile computer-readable medium includes a memory 403 that includes instructions, where the instructions are executed by the processor 401 of the system 400 to implement the smart flight search methods described above. For example, a non-volatile computer-readable medium can be ROM, random access memory (RAM), compact disk, magnetic tape, floppy disks, optical storage devices, and the like.

[0091] Computing system 400 may include a display interface that transmits graphics, text, and other data from a communications infrastructure (or framebuffer, not shown) for display on media component 405. Computing system 400 further includes input devices or peripherals. Peripheral devices may include one or more devices for interacting with a user's mobile communications device, such as a keyboard, microphone, wearable device, camera, one or more audio speakers, and other sensors. Peripherals may be external or internal to the user's mobile communications device. The touch screen may display, typically, graphics and text, and also provides a user interface (such as, but not limited to, a graphical user interface (GUI)) through which a subject may interact with the user's mobile communications device, such as accessing and interacting with with applications running on the device.

[0092] The elements of the proposed technical solution are in a functional relationship, and their joint use leads to the creation of a new and unique technical solution. Thus, all blocks are functionally connected.

[0093] All blocks used in the system can be implemented using electronic components used to create digital integrated circuits, which is obvious to a person skilled in the art. Not limited to, microcircuits, the logic of which is determined during manufacture, or programmable logic integrated circuits (FPGA), the logic of which is set by programming, can be used. Programmers and debugging environments are used for programming, allowing you to set the desired structure of a digital device in the form of a circuit diagram or a program in special hardware description languages: Verilog, VHDL, AHDL, etc. An alternative to FPGAs can be programmable logic controllers (PLCs), basic matrix crystals ( BMK), requiring a factory production process for programming; ASIC - specialized custom-made large integrated circuits (LSI), which are significantly more expensive for small-scale and single-piece production.

[0094] Typically, the FPGA chip itself consists of the following components:

• configurable logical blocks that implement the required logical function;

• programmable electronic links between configurable logic blocks;

• programmable input/output blocks that provide communication between the external output of the microcircuit and the internal logic.

[0095] Blocks can also be implemented using read-only memories.

[0096] Thus, the implementation of all used blocks is achieved by standard means based on the classical principles of implementing the fundamentals of computer technology.

[0097] As one of skill in the art will appreciate, aspects of the present technical solution may be implemented as a system, method, or computer program product. Accordingly, various aspects of the present technical solution may be implemented solely as hardware, as software (including application software, etc.), or as an embodiment combining software and hardware aspects, which may be generally referred to as a "module" , "system" or "architecture". In addition, aspects of the present technical solution may take the form of a computer program product implemented on one or more computer-readable media having computer-readable program code embodied thereon.

[0098] Any combination of one or more computer-readable media can also be used. The computer-readable storage medium can be, without limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or any suitable combination thereof. More specifically, examples (non-exhaustive list) of a computer-readable storage medium include: an electrical connection using one or more wires, a portable computer diskette; hard disk, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or Flash memory), fiber optic connection, compact disc read only memory (CD-ROM), optical storage device, magnetic storage device or any combination of the above. As used herein, a computer-readable storage medium can be any flexible storage medium that can contain or store a program for use by or in connection with a system, device, apparatus.

[0099] The program code embedded in a computer-readable medium may be transmitted using any medium, including, without limitation, wireless, wired, fiber optic, infrared, and any other suitable network, or a combination of the foregoing.

[00100] The computer program code for performing the operations for the steps of the present technical solution may be written in any programming language or combinations of programming languages, including an object-oriented programming language such as Python, R, Java, Smalltalk, C++, and so on, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may be executed in whole, in part, on the user's computer, or as a separate software package, in part on the user's computer and in part on a remote computer, or entirely on a remote computer. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN), a wide area network (WAN), or a connection to an external computer (eg, via the Internet via ISPs).

[00101] Aspects of the present technical solution have been described in detail with reference to block diagrams, circuit diagrams and/or diagrams of methods, devices (systems), and computer program products in accordance with embodiments of the present technical solution. It should be appreciated that each block from the block diagram and/or diagrams, as well as combinations of blocks from the block diagram and/or diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, a special purpose computer, or other data processing device to create a procedure, such that the instructions executed by the computer processor or other programmable data processing device create the means to implement the functions/actions specified in block or blocks of a flowchart and/or diagram.

[00102] These computer program instructions may also be stored on a computer-readable medium that can control a computer other than a programmable data processing device or other than devices that operate in a particular manner such that the instructions stored on the computer-readable medium create a device including instructions that perform the functions/actions indicated in the block diagram and/or diagram.

Claims (25)

1. A software test management system that has a client-server architecture that runs through docker containerization and contains, • at least one server configured to communicate between subsystems via distributed application requests in the REST API network; • subsystem of projects, made with the ability to store test documentation and manage testing for each individual project and generate reports in the context of projects; • subsystem of the test library, which is a repository for test documentation and is designed to store test documentation and create a hierarchical structure of the project, develop and approve test documentation; • a subsystem of test plans, made with the possibility of planning testing, determining the scope of planned testing, distributing tasks for testing between executors, in accordance with the level of user workload; • a configuration subsystem configured to store configurations used for testing in the project and manage their settings. • a subsystem of automated tests, configured to store information about automated tests registered in the system, as well as view and analyze data on passing automated tests, and an API is used to register an automated test in the system; • a subsystem of requests made with the possibility of filtering and searching for test documentation on the server for projects and managing saved filters. 2. The system according to claim 1, characterized in that the test library subsystem has a structure for storing test cases divided by functional areas of the tested product. 3. The system according to claim 1, characterized in that the test plan subsystem contains the results of testing. 4. The system according to claim 1, characterized in that the test plan subsystem generates reports on individual testing iterations within the test plans. 5. The system according to claim 1, characterized in that the subsystem of automated tests contains information reflecting meta-information about the automated test and/or its name, and/or related test cases, and/or attachment links. 6. The system according to claim 1, characterized in that in the subsystem of automated tests, the automated test is a program code that emulates the actions of users or a third-party system in the product being tested. 7. The system according to claim 1, characterized in that an automated test is registered in the subsystem of automated tests. 8. The system according to claim 1, characterized in that in the subsystem of automated tests, the results of the automated test are recorded using the API. 9. The system according to claim 8, characterized in that when registering the result, the outcome is indicated and supplemented with the passage time and / or attached files, and / or the results of each step. 10. The system according to claim 1, characterized in that in the subsystem of automated tests, in case of unsuccessful passing of tests, messages about detected errors and detailed reports about them, which are generated when passing the automated test, are applied to the result of passing the automated test. 11. The system according to claim 1, characterized in that in the subsystem of automated tests, after receiving the results of the automated test, when parsing the received data, the class and category of the problem are indicated. 12. The system according to claim 1, characterized in that the query subsystem displays all test cases and checklists to which the user has access. 13. The system according to claim 1, characterized in that in the query subsystem, the search is performed on the server using filters by user attributes and/or priorities and/or statuses. 14. The system according to claim 1, characterized in that in the query subsystem, the search is performed on all test cases and checklists for which the user has read access. 15. The system according to claim 1, characterized in that in the query subsystem the query is stored filters. 16. The system according to claim 1, characterized in that in the query subsystem, when a query is opened, a list of all test cases and checklists that match the saved filters is displayed. 17. The system according to claim 1, characterized in that in the request subsystem the request is private or public. 18. The system according to claim 1, characterized in that the request is opened via a link or placed on an external resource.

Images