WO2022240310A1 - Система управления тестированием программного обеспечения - Google Patents

Система управления тестированием программного обеспечения Download PDF

Info

Publication number
WO2022240310A1
WO2022240310A1 PCT/RU2021/000474 RU2021000474W WO2022240310A1 WO 2022240310 A1 WO2022240310 A1 WO 2022240310A1 RU 2021000474 W RU2021000474 W RU 2021000474W WO 2022240310 A1 WO2022240310 A1 WO 2022240310A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
subsystem
automated
testing
project
Prior art date
Application number
PCT/RU2021/000474
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
Priority claimed from RU2021113580A external-priority patent/RU2774659C1/ru
Application filed by Евгений Уралович ХАФИЗОВ filed Critical Евгений Уралович ХАФИЗОВ
Publication of WO2022240310A1 publication Critical patent/WO2022240310A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software

Definitions

  • 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 .
  • 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 also to receive 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.
  • 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.
  • the technical problem or technical problem solved in this technical solution is the creation of an automated software testing management system.
  • 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.
  • 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 among performers, in accordance with the user's workload level; configuration subsystem configured to
  • 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.
  • the test library subsystem has a structure for storing test cases, divided by functional areas of the product under test.
  • the test plan subsystem contains the results of testing.
  • the test plan subsystem generates reports on individual testing iterations within the test plans.
  • 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.
  • an automated test is a program code that emulates the actions of users or a third-party system in the product being tested.
  • an automated test is registered in the automated test subsystem.
  • the results of the automated test are recorded using the API.
  • the query subsystem displays all test cases and checklists to which the user has access.
  • the search is performed on the server using filters on user attributes and/or priorities and/or statuses.
  • the search is performed on all test cases and checklists to which the user has read access.
  • the query is stored filters.
  • the request is private or public.
  • the request is opened by a link or posted on an external resource.
  • FIG. 1 shows an example of the implementation of the scheme of interaction with external services of the software testing management system.
  • FIG. 2 shows an example implementation of a software test management system.
  • FIG. 3 shows an example of the implementation of the project subsystem.
  • FIG. 4 shows an implementation of a software test management system.
  • FIG. Figure 5 shows an example implementation of the test library subsystem designed to store test documentation.
  • 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.
  • 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.
  • 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.
  • the system refers to a computer system, a computer (electronic computer), a CNC (computer numerical control), a PLC (programmable logic controller),
  • 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.
  • a program (sometimes "software") is a sequence of instructions intended to be executed by a computer control device or command processing device.
  • 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.
  • 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).
  • API Application Programming Interface, Application Programming Interface
  • 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
  • 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.
  • 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.
  • 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.
  • OpenlD Connect provider 160 is a service implemented using the OpenlD 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 OpenlD protocol
  • 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.
  • 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.
  • 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.
  • 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]
  • the test plan (hereinafter referred to as the “test plan”) is a document describing the scope of work on testing, 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.
  • 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.
  • 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.
  • 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.
  • the client in this case is a browser 130, which opens a graphical user interface ("GUI"),
  • GUI graphical user interface
  • 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.
  • 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.
  • a common step is an entity that allows you to store and reuse repeated steps across different test cases.
  • it includes individual test steps that are repeated for several test cases.
  • 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 necessary to enter the website and
  • 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.
  • 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 passed automatically or manually.
  • autotests automated tests
  • 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.
  • autotests automated tests
  • 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:
  • 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.
  • 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.
  • 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.
  • project 310.1 contains such submodules as a test library, configurations, test parameters, autotests, requirements, defects (shown in Fig. 3).
  • the test library subsystem 510 shown in FIG. 5, designed to store test documentation, is a section in which a hierarchical structure of the project 310.1 is created, test documentation is developed and agreed upon. Inside project 310.1, a folder structure is created to store test cases, divided by functional areas of the tested product. 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.
  • 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 cases 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. test
  • Test plan 620 is a set of tests to pass, tied to specific configurations, and makes it possible to run both manual and automated testing within the test plan 620.
  • 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.
  • Test planning is the test phase 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 test needs, and the test performers are 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 passage time
  • 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.
  • the configuration subsystem 710 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 configuration module is used in test-
  • 16 plans 620 in conjunction with tests to create test tasks, namely the representation of which test on which configuration should be performed.
  • the configuration is applied to the test cases of the test plan 620.
  • the configurations stored in the project 310.1 are used to generate automated test runs (called test runs).
  • 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.
  • 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.
  • API 820 application programming interface, API
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 carried out on all test cases and checklists to which the user has access by
  • the request is a saved filters.
  • 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.
  • 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.
  • 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.
  • the dashboard subsystem is connected with all other functional areas of the system. reporting in widgets can have as data sources any data stored within projects, test libraries, configurations, test parameters, autotests, requirements, and
  • Requirements reporting capabilities include requirements tracing, a requirements test coverage matrix, and an indirect link between requirements and defects found as a result of the execution of tests associated with them.
  • the software test management system interacts with the issue tracking system 160, such as Jira, through a plugin installed in Jira version 7.2.13 and higher.
  • 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.
  • the system supports an event notification mechanism that accesses the API of third-party systems (continuous integration systems, instant messengers, etc.).
  • 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.
  • 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.
  • 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 issue/defect tracking tools,
  • twenty 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 possibility of obtaining additional information about defects/tasks from an external tool.
  • 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
  • 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.
  • the processing component 401 may include one or more modules for convenient interaction between other processing modules 401 and other modules.
  • the processing component 401 may include a multimedia module for convenient, lightweight interaction between the multimedia component 405 and the processing component 401.
  • the memory 403 is configured to store various types of data to support the operation of the system 400, such as a database with
  • 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.
  • 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.
  • 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.
  • the audio component 406 is configured to output and/or input an audio signal.
  • 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 .
  • the audio component 406 also includes a single speaker capable of outputting an audio signal.
  • 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.
  • the touch component 408 includes one or more sensors and is configured to provide various aspects of estimating the state of the system 400.
  • 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.
  • the sensor component 408 includes an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.
  • 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.
  • the communication component 409 receives a broadcast signal or broadcast related information from an external broadcast control system via a broadcast channel.
  • communication component 409 includes a Near Field Communication (NFC) module to facilitate near field communications.
  • NFC Near Field Communication
  • 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.
  • RFID radio frequency identification
  • IrDA infrared data association
  • UWB ultra-wideband
  • Bluetooth Bluetooth
  • 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.
  • ASICs Application-Specific Integrated Circuits
  • DSP Digital Signal Processor
  • DSP Digital Signal Processor
  • PLU Programmable Logic Unit
  • FPGA logic chip programmable in operating conditions
  • 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.
  • 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.
  • 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 can 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 can interact with the user's mobile communication device, such as accessing and interacting with with applications running on the device.
  • GUI graphical user interface
  • 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 can be used, the logic of which is determined during manufacture, or programmable logic integrated circuits (FPGAs), the logic of which is set by programming. For programming, programmers and debugging environments are used that allow 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.
  • FPGAs programmable logic controllers
  • BMCs basic matrix crystals
  • ASICs are specialized custom large integrated circuits (LSI), which are significantly more expensive in small-scale and single-piece production.
  • the FPGA chip itself consists of the following components:
  • Blocks can also be implemented using read-only memories.
  • 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. Computer readable medium
  • the storage may 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.
  • 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.
  • 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.
  • 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 can be connected to the user's computer through any type of network, including a local area network.
  • LAN local area network
  • WAN wide area network
  • Internet Service Providers for example, via the Internet using Internet Service Providers.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Решение относится к области вычислительной техники, в частности, к системам управления тестированием. Система управления тестированием программного обеспечения содержит, по меньшей мере, один сервер, выполненный с возможностью осуществления взаимодействие между подсистемами посредством запросов распределенного приложения в сети; подсистему проектов, выполненную с возможностью хранения тестовой документации и управления тестированием по каждому отдельному проекту и формирования отчетности в разрезе проектов; подсистему библиотеки тестов, выполненную с возможностью хранения и создания иерархической структуры проекта, разработки и согласования тестовой документации; подсистему тест-планов, распределения задач на тестирование между исполнителями, в соответствии с уровнем нагрузки пользователя; подсистему конфигурации, выполненную с возможностью хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками; подсистему автоматизированных тестов и просмотра и анализа данных о прохождениях автоматизированных тестов; подсистему запросов, выполненную с возможностью фильтрации и поиска тестовой документации по проектам и управления сохраненными фильтрами.

Description

СИСТЕМА УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ОБЛАСТЬ ТЕХНИКИ
[001] Данное техническое решение относится в общем к области вычислительной техники, а в частности к системам управления тестированием, предназначенным для упорядоченного хранения тестовой документации, планирования тестирования, а также стандартизации и хранения информации о результатах ручного и автоматизированного тестирования в единой среде и построения отчетности.
УРОВЕНЬ ТЕХНИКИ
[002] В настоящее время системы управления тестированием используются для хранения информации о том, как должным образом проводить тестирование, осуществление очередности проведения тестирования в соответствии с его планом, а также для получения информации в виде отчетов о стадии тестирования и качестве тестируемого продукта или другими словами программного обеспечения. Инструменты имеют различные подходы к тестированию и, таким образом, включают в себя различные наборы функций. Обычно они используются для планирования ручного тестирования, сбора данных о результатах прохождения чек-листов и тест-кейсов, а также для получения оперативной информации в виде отчетов. Системы управления тестированием помогают оптимизировать процесс тестирования и обеспечивают быстрый доступ к анализу данных, средствам совместной работы и более качественному взаимодействию между несколькими проектными группами. Многие системы управления тестированием включают в себя возможность работы с требованиями.
[003] Недостатки ручного тестирования, которое очень распространено повсеместно при анализе программного обеспечения, вполне понятны и очевидны. Ручное тестирование выполняется значительно медленнее автоматического. Порой это может занять пару недель вручную вместо одного
1 часа скриптом, в других случаях может соотношение может колебаться в меньших пределах. При этом хорошо написанный скрипт не ошибается и не пропускает дефекты, устав от однообразной рутины день за днём, в отличие от инженера. Вручную практически невозможно выполнять сценарии, требующие большой скорости действий или крайне высокой точности по времени.
[004] Из уровня техники известен способ, раскрытый в CN106897217А «Способ тестирования и устройство для тестирования» (патентообладатель: BEIJING QUNAR SOFTWARE TECH СО LTD, дата публикации: 2017-06-27). В изобретении заявлены метод тестирования и устройство для тестирования, причем способ включает следующие этапы: получение по меньшей мере одного сообщения с запросом, при этом сообщение с запросом используется для тестирования программы, по меньшей мере одно сообщение с запросом отправляется в программу для проверки версии для получения первого результата тестирования и отправка в стабильную версию программы для получения второго результата тестирования, при этом программа стабильной версии представляет собой сообщение с запросом, может возвращать результат программы, сравнивая первый результат теста и второй результат теста, получая результат сравнения, при этом результат сравнения предназначен для определения функциональной стабильности тестовой версии. Изобретение решает проблему, заключающуюся в том, что тестируемый пример тестирует код в предшествующем уровне техники, тем самым увеличивая стоимость поддержки программного обеспечения в уровне техники.
СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ
[005] Технической проблемой или технической задачей, решаемой в данном техническом решении, является создание автоматизированной системы управления тестированием программного обеспечения.
2 [006] Техническим результатом, достигаемым при решении вышеуказанной технической проблемы, является повышение качества автоматизированного тестирования программного обеспечения.
[007] Дополнительно достигаемым техническим результатом является упорядоченное хранение тестовой документации с учетом всех версий документа с возможностью восстановления любой версии документа при необходимости.
[008] Также осуществляется
• использование единой точки получения информации для принятия управленческих решений;
• возможность внедрения процесса контроля качества, обеспеченная универсальными настраиваемыми пользовательскими атрибутами в системе;
• распределение уровней доступа к тестовой документации и результатам выполнения тестирования, которое позволяет ограничивать доступ к содержащейся в ней информации, которая может являться коммерческой тайной.
[009] Указанный технический результат достигается благодаря системе управления тестированием программного обеспечения, которая содержит по меньшей мере один сервер, выполненный с возможностью осуществления взаимодействие между подсистемами посредством запросов распределённого приложения в сети; подсистему проектов, выполненную с возможностью хранения тестовой документации и управления тестированием по каждому отдельному проекту и формирования отчетности в разрезе проектов; подсистему библиотеки тестов, выполненную с возможностью хранения тестовой документации и создания иерархической структуры проекта, разработки и согласования тестовой документации; подсистему тест- планов, выполненную с возможностью планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями, в соответствии с уровнем нагрузки пользователя; подсистему конфигурации, выполненную с возможностью
3 хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками; подсистему автоматизированных тестов, выполненную с возможностью хранения информации об автоматизированных тестах, зарегистрированных в системе, а также просмотра и анализа данных о прохождениях автоматизированных тестов; подсистему запросов, выполненную с возможностью фильтрации и поиска тестовой документации по проектам и управления сохраненными фильтрами.
[0010] В некоторых вариантах реализации технического решения подсистема библиотеки тестов имеет структуру для хранения тест-кейсов, разделенных по функциональным областям тестируемого продукта.
[0011] В некоторых вариантах реализации технического решения подсистема тест-планов содержит результаты выполнения тестирования.
[0012] В некоторых вариантах реализации технического решения в подсистеме тест-планов формируется отчетность по отдельным итерациям тестирования в рамках тест-планов.
[0013] В некоторых вариантах реализации технического решения подсистема автоматизированных тестов содержит информацию, отражающую метаинформацию об автоматизированном тесте и/или его название, и/или связанные тест-кейсы, и/или ссылки вложения.
[0014] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов автоматизированный тест представляет из себя программный код, эмулирующий действия пользователей или сторонней системы в тестируемом продукте.
[0015] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов регистрируют автоматизированный тест.
[0016] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов результаты выполнения автоматизированного теста фиксируются с помощью API.
[0017] В некоторых вариантах реализации технического решения при регистрации результата указывают исход и дополняют временем прохождения
4 и/или приложенными файлами, и/или результатами прохождения каждого шага.
[0018] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов в случае неуспешного прохождения тестов прикладывают к результату прохождения автоматизированного теста сообщения об обнаруженных ошибках и детальные отчеты о них, которые формируются при прохождении автоматизированного теста.
[0019] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов после получения результатов автоматизированного теста, при разборе полученных данных, указывают класс и категорию проблемы.
[0020] В некоторых вариантах реализации технического решения в подсистеме запросов выводятся все тест-кейсы и чек-листы, к которым у пользователя есть доступ.
[0021] В некоторых вариантах реализации технического решения в подсистеме запросов поиск выполняется на сервере с использованием фильтров по пользовательским атрибутам и/или приоритетам, и/или статусам.
[0022] В некоторых вариантах реализации технического решения в подсистеме запросов поиск выполняется по всем тест-кейсам и чек-листам, на которые у пользователя есть доступ на чтение.
[0023] В некоторых вариантах реализации технического решения в подсистеме запросов запрос представляет из себя сохраненные фильтры.
[0024] В некоторых вариантах реализации технического решения в подсистеме запросов при открытии запроса выводится список всех тест-кейсов и чек- листов, которые подходят под сохраненные фильтры.
[0025] В некоторых вариантах реализации технического решения в подсистеме запросов запрос является приватны или публичными.
[0026] В некоторых вариантах реализации технического решения запрос открывают по ссылке или размещают на внешнем ресурсе.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
5 [0027] Признаки и преимущества настоящего технического решения станут очевидными из приведенного ниже подробного описания и прилагаемых чертежей, на которых:
[0028] На Фиг. 1 показан пример реализации схемы взаимодействия с внешними сервисами системы управления тестированием программного обеспечения.
[0029] На Фиг. 2 показан пример реализации системы управления тестированием программного обеспечения.
[0030] На Фиг. 3 показан пример реализации подсистемы проектов.
[0031] На Фиг. 4 показан вариант реализации системы управления тестированием программного обеспечения.
[0032] На Фиг. 5 показан пример реализации подсистемы библиотеки тестов, предназначенная для хранения тестовой документации.
[0033] На Фиг. 6 показан пример реализации подсистемы тест-планов, которая предназначена для планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями.
[0034] На Фиг. 7 показан пример реализации подсистемы конфигурации, которая предназначена для хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками.
[0035] На Фиг. 8 показан вариант реализации подсистемы автотестов, которая предназначена для хранения информации об автоматизированных тестах, зарегистрированных в системе управления тестированием, а также просмотра и анализа данных о прохождениях автоматизированных тестов
ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
[0036] Ниже будут подробно рассмотрены термины и их определения, используемые в описании технического решения.
[0037] В данном изобретении под системой подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер),
6 компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций), централизованные и распределенные базы данных, смарт-контракты.
[0038] Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы), смарт-контракт или подобное. Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.
[0039] Программа (иногда - «ПО») - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.
[0040] На Фиг. 1 показан пример реализации схемы взаимодействия системы управления тестированием программного обеспечения с внешними сервисами, которые описаны ниже.
[0041] Браузер 130 - программное обеспечение, предназначенное для просмотра веб-страниц. Работа пользователя с техническим решением проводится через пользовательский интерфейс, отображаемый в браузере 130. Пользовательский интерфейс может быть разработан, например, на фреймворке Angular, который является кроссплатформенным JavaScript- фреймворком, который работает с HTML, используя статическую и динамическую информацию, получаемую от сервера 100 приложения через API (программный интерфейс приложения, интерфейс прикладного программирования).
[0042] REST (RESTful) — это общие принципы организации взаимодействия приложения/сайта с сервером 100 посредством протокола HTTP. Особенность REST в том, что сервер 100 не запоминает состояние пользователя между запросами - в каждом запросе передаётся информация, идентифицирующая
7 пользователя (например, token, полученный через OAuth-авторизацию) и все параметры, необходимые для выполнения операции.
[0043] Система непрерывной интеграции 140 (например, Jenkins, Gitlab и т.д.) - программное обеспечение, предназначенное для автоматизированной сборки кода. В области тестирования системы непрерывной интеграции используются для сборки кода автотестов. Данная система интегрируется с системами непрерывной интеграции 140 посредством технологии Webhook, а также API. Webhook - это обратный вызов системы по наступлению какого- либо события в данной системе. Например, в системе реализована возможность создавать Webhook на создание запуска автотестов. Если в системе создается новый запуск автотестов, выполняется заданный ранее запрос.
[0044] Система отслеживания задач 160 (например, Jira) - программное обеспечение, предназначенное для управления проектами в IT - сфере. Интегрируется с данной системой посредством плагина и/или API. Данная система создает дубликаты тест-кейсов в системе отслеживания задач 160, получает информацию о статусе задач и их приоритетах, а также создает дефекты/ошибки (жарг. «баги») в системе отслеживания задач 160. Интеграция двусторонняя, любые связи, созданные в системе, создаются как внешние ссылки в системе отслеживания задач 160.
[0045] AD/LDAP 150 - служба каталогов, предоставляющая функции аутентификации, управление пользователями и их группами, разрешениями. Интегрируется с системой в части получения из AD/LDAP 150 пользователей и групп для дальнейшей выдачи ролей и разрешений в системе. Система управления тестированием программного обеспечения получает список пользователей и групп из AD/LDAP 150, также лишает их ролей и удаляет из системы, если на стороне AD/LDAP 150 они утратили доступ.
[0046] OpenlD Connect провайдер 160 - сервис, реализованный по протоколу OpenlD Connect предназначенный для аутентификации пользователей в системе на базе протокола Oauth 2.0. Интеграция с системой управления тестированием программного обеспечения реализована по протоколу OpenlD
8 Connect и конфигурируется в панели администратора. Настройки на стороне системы позволяют интегрироваться с любым сервисом, поддерживающим протокол OpenlD Connect в части создания пользователей и их аутентификации в системе. Пользователи получают возможность входа через единый сервис аутентификации. В некоторых вариантах реализации могут использоваться биометрические алгоритмы аутентификации, двухфакторная аутентификация, аутентификация по ключам доступа, аутентификация по токенам и т.д., не ограничиваясь.
[0047] Данное техническое решение представляет собой систему управления тестированием программного обеспечения, которая используются для хранения тестовой документации (тест-планов, тестовых наборов, тестовых случаев и чек-листов с проверками функциональности, результатов выполнения тестирования в соответствии с его планом, а также отчетов о стадии тестирования в виде документа, в котором представлена информация о выполненных тестах, их результатах, тестировщиках, которые участвовали в тестировании, найденных дефектах и т.д., не ограничиваясь) и осуществления автоматизированного управления тестированием программного обеспечения. На основании данной информации можно делать выводы о качестве тестируемого продукта или, иными словами, программного обеспечения.
[0048] Тестовый случай (далее - «тест-кейс») - это документ, описывающий последовательность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции программного обеспечения или его части, а также ожидаемые результаты прохождения этих шагов. Тестовый случай формируется на основе функциональных и нефункциональных требований к разрабатываемому ПО.
[0049] Под качеством продукта в данном контексте подразумевается качество тестируемого программного обеспечения, а именно степень соответствия реализованного программного обеспечения требованиям и пригодность его к использованию.
9 [0050] Тестовая документация описывает варианты использования ПО, в соответствии с требованиями к системе. Любые несоответствия тестируемого ПО первоначальным требованиям расцениваются как дефекты (жарг. «баги»). [0051] Наличие дефектов (жарг. «багов») расценивается как отсутствие качества. Помимо первоначальных требований к разрабатываемому ПО, на качество влияет пригодность программного обеспечения к использованию, т.е. соответствие вариантов использования ожиданиям конечного пользователя. [0052] План тестирования (далее - «тест-план») — это документ, описывающий объем работ по тестированию, содержащий информацию об объекте тестирования, стратегии тестирования, сроках тестирования, критериях начала и завершения тестирования, а также перечень проверок, которые должны быть пройдены.
[0053] Отчет о выполнении тестирования — это документ, обобщающий результаты работ по тестированию и содержащий информацию, достаточную для соотнесения текущего качества разрабатываемого программного обеспечения с планом тестирования и принятия управленческих решений. [0054] Тестовая документация - это любые артефакты, полученные в ходе планирования, выполнения и фиксации результатов тестирования. На этапе подготовки к тестированию формируются тест-кейсы и чек-листы для них (документ, регламентирующий что является успехом прохождения тест-кейса). На этапе планирования тестирования формируется тест-план. По результатам выполнения тестирования формируется отчет о результатах тестирования. Всё это представляет из себя тестовую документацию в совокупности.
[0055] Система управления тестированием имеет архитектуру «клиент- сервер». «Клиент — сервер» (англ client-server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами.
[0056] Клиент в данном случае представляет собой браузер 130, в котором открывается графический интерфейс пользователя (англ. «GUI»),
10 предназначенный для взаимодействия пользователя системы с сервером 100 посредством использования компонентов интерфейса.
[0057] Сервером 100 в данном случае являются компоненты системы, осуществляющие получение и обработку запросов от клиента (т.е. из браузера), а также отправку запросов на клиент и иные внешние системы для получения информации.
[0058] Для развертывания и запуска системы используются средства docker - контейнеризации. Docker-контейнеризация — это технология, позволяющая программно на определенном участке памяти изолированно настраивать окружение, а также устанавливать операционные системы и программные продукты внутри различных контейнеров. Контейнеризация позволяет гибко настраивать параметры окружения внутри контейнеров, не меняя при этом настройки глобального сервера. Развертывание и запуск системы происходит с помощью docker compose, что позволяет запускать несколько контейнеров, связанных между собой, в каждом контейнере разворачивается отдельный сервис, настройка связей происходит в соответствии с указанными параметрами. Docker Compose — это инструментальное средство, входящее в состав Docker. Оно предназначено для решения задач, связанных с развёртыванием проектов. Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации, контейнеризатор приложений.
[0059] Одной из отличительных особенностей данного технического решения является наличие общих шагов. Общий шаг — это сущность, которая позволяет хранить и повторно использовать повторяющиеся шаги в разных тестовых случаях. При создании общего шага в него включаются отдельные шаги проверок, повторяющиеся для нескольких тестовых случаев. В качестве примера реализации можно привести авторизацию на тестируемом сайте. Для выполнения большинства проверок нужно сначала выполнить вход под пользователем. Этот шаг будет повторяться во многих тестовых случаях при тестировании работы веб-сайта. Система позволяет создать общий шаг, содержащий в себе необходимые для входа на аеб-сайт действия и
11 использовать его во всех проверках. При этом изменение общего шага влечет за собой его изменение во всех тестовых случаях, где он используется. Таким образом нужно менять только один общий шаг, а не все тестовые случаи, где он упоминается, что экономит время осуществления тестирования.
[0060] В данном решении также реализовано версионирование тест-кейсов, которое подразумевает под собой возможность просматривать предыдущие версии документов после их изменений, «откатываться» на предыдущие версии, причем при просмотре подсвечиваются отличия между версиями. [0061] Одной из отличительных особенностей данного решения является возможность совместного анализа результатов ручного и автоматизированного тестирования, причем по результатам выполнения тестирования формируется единый отчёт в рамках всего тест-плана, где можно увидеть автоматизировано или вручную был пройден тест. В рамках одного тест-плана можно выполнять автоматизированные тесты (далее - автотесты) и ручные тесты, при этом на экране выполнения можно увидеть какие тест-кейсы автоматизированы, т.е. имеют привязанные автотесты, а какие проходятся только вручную. Выбрав автоматизированные тесты, можно запустить прогон автотестов, выполнить запуск автотестов. Параллельно можно выполнять ручные тесты, отмечая их результаты. При прохождении всех тестов на вкладке «Отчет» в режиме реального времени можно увидеть результаты как ручных, так и автоматизированных тестов, с деталями результата. При открытии прогона тестов, можно также увидеть все автотесты, которые пройдены.
[0062] Система управления тестированием предназначена для комплексного информационно-аналитического обеспечения процессов на предприятиях, занимающихся разработкой программного обеспечения в части исполнения следующих процессов:
• создание тестовой документации (тест-кейсы, чек-листы);
• хранение тестовой документации в иерархической структуре, обеспечивающей удобство поиска и навигации по разделам;
• согласование тестовой документации;
12 • формирование списков тест-кейсов к прохождению, объединенных общими признаками (релиз, задача и т. д );
• планирование тестирования;
• регистрация результатов выполнения тестирования и хранение истории результатов;
• построения отчетности по тестированию и тестовой документации в проектах;
• мониторинга выполнения автоматизированного тестирования.
[0063] Система управления тестированием программного обеспечения состоит из ряда подсистем, реализующих различную функциональность, которые между собой все связаны функционально и аппаратно. Взаимодействие между подсистемами обеспечивается на сервере 100, с помощью запросов REST API. [0064] Далее ниже представлены краткие характеристики и описание каждой подсистемы, как показано на Фиг. 2, а также взаимодействие между ними. [0065] Подсистема проектов 310, как показано на Фиг. 3, включает в себя отдельные сущности, предназначенные для хранения тестовой документации и управления тестированием, разграничения прав между ними, а также формирования отчетности в разрезе проектов. Проект 310.1 представляет из себя изолированное хранилище для тестовой документации (тест-кейсов, чек- листов), тест-планов, результатов выполнения тестирования. В проекте 310.1 хранятся все данные, а доступ при этом разграничен, содержимое проекта видят только те участники команды (пользователя 320 на Фиг. 3), которые явно получили роль в проекте 310.1. Проектные роли формируются в панели администратора и представляют из себя набор разрешений и уровней доступа пользователей 320 в разделы проекта. Затем эти проектные роли назначаются в проекте на пользователей 320, после чего пользователи 320 получают доступы к разделам проекта 310.1 в соответствии со своей проектной ролью. На Фиг. 2 отображена схема компонентов системы и их связей более подробно. Система может хранить в себе несколько проектов 310.1, как показано на Фиг. 3, с распределением доступа, настраиваемым в модуле администрирования.
13 При этом проект 310.1 содержит в себе такие подмодули как библиотека тестов, конфигурации, параметры тестов, автотесты, требования, дефекты (показаны на Фиг. 3).
[0066] Подсистема библиотеки тестов 510, показанная на Фиг. 5, предназначена для хранения тестовой документации, представляет из себя раздел, в котором создается иерархическая структура проекта 310.1 , разрабатывается и согласовывается тестовая документация. Внутри проекта 310.1 создаётся структура папок для хранения тест-кейсов, разделенных по функциональным областям тестируемого продукта. Такое упорядоченное хранение документации обеспечивает простоту управления тестовой документацией и удобство поиска для пользователей. Подсистема библиотеки тестов 510 выполняет функцию хранилища для тестовой документации, хранимые в ней сущности содержат сценарии проверок, используемых при планировании и выполнении тестирования в тестовых наборах тест-планов. Тест-кейсы и чек-листы используются для создания тестовых наборов в тест- планах, а общие шаги формируются для использования в тест-кейсах. Описание сценариев проверок, хранящихся в библиотеке тестов, может происходить вручную или автоматизировано на основе автотестов. Внутри подсистемы библиотеки тестов реализованы поиск, фильтрация, с возможностью сохранения фильтров, сортировка, а также открытие определенных секций и тестов по прямой ссылке.
[0067] Подсистема тест-планов 610, показанная на Фиг. 6, предназначена для планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями, в соответствии с уровнем нагрузки. Также в этом разделе отражаются результаты выполнения тестирования и формируется отчетность по отдельным итерациям тестирования в рамках тест-планов 620. Тестовые планы 620 включают в себя тестовые наборы, состоящие из тест-кейсов и чек- листов, полученные из подсистемы библиотеки тестов 510. Помимо этого, есть возможность создавать тестовые наборы на основе библиотеки тестов из подсистемы 510, либо по сохраненным фильтрам в библиотеке. Тестовый
14 набор представляет из себя папку с тестами, которые должны быть выполнены, после создания тестового набора к нему применяется конфигурация, на которой будет проводиться тестирование. Параметры конфигурации получают из подсистемы конфигураций, присутствующей в каждом проекте. Тест-план 620 представляет из себя наборы тестов к прохождению, привязанных к определенным конфигурациям, и даёт возможность запускать выполнение как ручного так и автоматизированного тестирования внутри тест-плана 620. При запуске выполнения автоматизированных тестов формируется тест-ран. Тест-ран — это прогон какого-то теста в соответствии с заранее определённым тест планом. Результаты ручных тестов указываются пользователями вручную, с возможностью комментирования шагов, прикладывания файлов и ссылок на любые внешние источники в том числе ссылки на дефекты, требования, репозитории кода и любые другие связанные ресурсы. Результаты автоматизированных тестов при выполнении в тест-плане могут быть получены от внешнего инструмента автоматизированного тестирования или инструмента непрерывной интеграции 140 и поставки посредством API, плагинов или библиотек для интеграции.
[0068] Планирование тестирования - это этап тестирования, во время которого определяются цель проведения тестирования, обозначаются сроки проведения тестирования, формируются наборы проверок, которые должны быть выполнены в ходе тестирования исходя из потребностей в тестировании, а также обозначены исполнители тестов. Данная система управления тестированием позволяет автоматизировать процесс планирования тестирования с помощью формирования тест-плана 620, автоматического формирования наборов тестов к прохождению на основе библиотеки тестов из подсистемы библиотеки тестов 510 или вручную на усмотрение пользователя. Для распределения задач между исполнителями используется как ручной способ, так и автоматический способ. При автоматическом распределении задач между исполнителями на каждого исполнителя назначается набор задач на выполнение тестирования с равными оценками времени прохождения
15 тестирования. Время прохождения тестирования задаётся у каждого кейса автоматически на основе предыдущих прохождений, или вручную исполнителем теста или его руководителем.
[0069] Например, тест в упрощённом виде будет выглядеть как показано в Таблице 1 ниже.
Таблица 1
Figure imgf000018_0001
[0070] Подсистема конфигурации 710, как показано на Фиг. 7, предназначена для хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками. Конфигурации используются для того, чтобы хранить и передавать данные об окружениях, на которых проводится тестирование. Окружение - это набор опций, воспроизводящих условия, необходимые для работы тестируемого программного обеспечения, например, операционные системы, браузеры, устройства и т.д. В конфигурациях в виде «ключ»-«значение» задаются эти опции. Конфигурацию можно использовать при автоматизированном тестировании для подготовки нужного окружения, получив параметры конфигурации. Модуль конфигураций используется в тест-
16 планах 620 в связке с тестами для создания задач на тестирование, а именно представления какой тест на какой конфигурации должен выполняться. Конфигурация применяется к тестовым наборам тест-плана 620. Помимо этого, конфигурации, хранимые в проекте 310.1 , используются для формирования прогонов автоматизированных тестов (так называемых тест- ранов). Эти связи обеспечивают возможность построения отчетности в подсистеме дашбордов (будет раскрыта ниже) с группировкой по конфигурации, т.е. просмотра данных о результатах ручных и автоматизированных тестов, тест-планах и тест-ранах в разрезе конфигураций.
[0071] Подсистема автотестов 810, показанная на Фиг. 8, предназначена для хранения информации об автоматизированных тестах, зарегистрированных в системе управления тестированием, а также просмотра и анализа данных о прохождениях автоматизированных тестов. В системе управления тестированием хранится информация, отражающая метаинформацию об автотесте, его название, связанные тест-кейсы, также конкретные шаги, ссылки, вложения и т.д. Для регистрации автотеста в системе управления тестированием используется API 820 (программный интерфейс приложения, интерфейс прикладного программирования) (англ application programming interface, API). После того как автотест зарегистрирован в системе, появляется возможность сохранять и анализировать данные о его прохождениях, оценивать его влияние на результаты связанных тестов. Автоматизированный тест представляет из себя программный код, эмулирующий действия пользователей или сторонней системы в тестируемом продукте. Результаты выполнения автоматизированного теста также фиксируются в системе управления тестированием с помощью API 820. При регистрации результата проведения автоматического тестирования можно указать исход, а также дополнить это метаинформацией - временем прохождения, дополнительными данными в виде приложенных файлов (скриншоты, логи), результатами прохождения каждого шага. В случае неуспешного прохождения тестов можно прикладывать к результату прохождения автоматизированного теста
17 сообщения об обнаруженных ошибках и детальные отчеты о них, которые формируются при прохождении автотеста. Интеграция с автоматизированными тестами с помощью API позволяет использовать любые средства автоматизации тестирования. После получения результатов автоматизированного теста, при разборе полученных данных, можно указывать класс и категорию проблемы. Данная возможность используется для автоматизированного анализа категорий проблем. Модуль автотестов позволяет регистрировать автоматизированные тесты в системе, автотесты связываются с ручными тестами в библиотеке, а также с параметрами тестов, хранимых в проекте 310.1, что обеспечивает возможность выполнения ручного и автоматизированного тестирования совместно в рамках тест-планов 620, а также возможность регистрации результатов выполнения автоматизированных тестов отдельно от ручных в рамках тест-планов 620. Информация об автотестах и результатах их выполнения получается от инструмента непрерывной интеграции 140 и поставки, либо от инструмента автоматизированного тестирования, посредством API 820, плагинов и клиентских библиотек. Автотесты и их результаты можно выводить в виджетах дашбордов, в соответствии с настройками виджетов.
[0072] Модуль тест-ранов предназначен для сбора информации о выполнении автоматизированных тестов во внешней среде с помощью инструмента автоматизированного тестирования. Данные о прохождениях принимаются от инструментов автоматизированного тестирования и инструментов непрерывной интеграции 140 и поставки.
[0073] Подсистема запросов (не показана на фигурах), в которой осуществляется фильтрация и поиск тестовой документации по проектам, с возможностью управления сохраненными фильтрами. В разделе запросов выводятся все тест-кейсы и чек-листы, к которым у пользователя есть доступ. Поиск выполняется на сервере 100, с использованием различных фильтров. Доступна фильтрация по всем параметрам и дополнительным данным, таким как пользовательские атрибуты, приоритеты, статусы. Поиск осуществляется по всем тест-кейсам и чек-листам, на которые у пользователя есть доступ по
18 меньшей мере на чтение. Можно составить набор фильтров и сохранить запрос. Запрос представляет из себя сохраненные фильтры. При открытии запроса выводится список всех тест-кейсов и чек-листов, которые подходят под сохраненные фильтры. Результат меняется, если в каких-то из выводимых кейсов сменятся актуальные значения параметров, содержащихся в запросе. Запросы можно делать приватными (доступными только пользователю) или публичными (доступными всем пользователям системы). Запрос можно открыть по ссылке, что позволяет передавать ссылку другим пользователям, либо размещать где-то на внешних ресурсах. В запросах выполняется поиск по данным, хранящимся в библиотеках тестов, всех доступных проектов, данные в подсистему запросов поступают из многих проектов, но с учетом разграничений прав доступа.
[0074] Подсистема дашбордов (не показана на фигурах), в которой осуществляется формирование отчетности по проектам. Дашборд — инструмент визуализации и анализа данных. Если говорить проще, то инфографика — одна из составляющих частей дашборда. Каждый дашборд представляет из себя набор настраиваемых виджетов. Виджет — примитив графического интерфейса пользователя, имеющий стандартный внешний вид и выполняющий стандартные действия. При создании виджета можно выбрать тип представления информации, источник данных для формирования отчета, а также дополнительно сгруппировать полученные значения по отдельным параметрам в зависимости от источника данных. Гибкая система создания виджетов позволяет выводить большинство необходимой информации, хранящейся в системе, в удобном представлении. Доступные представления — это график трендов, круговые диаграммы, линейчатые диаграммы, табличное представление. Доступные источники данных — это тесты, результаты выполнения тестов, тест-планы, прогоны автоматизированных тестов. Таким образом подсистема дашбордов связана со всеми остальными функциональными областями системы т.к. отчётность в виджетах может иметь в качестве источников данных любые данные, хранимые в рамках проектов, библиотек тестов, конфигураций, параметров тестов, автотесты, требования и
19 дефекты. Возможности построения отчетности по требованиям включают в себя трассировку требований, матрицу покрытия требований тестами, а также косвенную связь между требованиями и дефектами, обнаруженными в результате выполнения привязанных к ним тестов.
[0075] Система управления тестированием программного обеспечения взаимодействует с системой отслеживания ошибок 160, например, Jira, посредством плагина, устанавливаемого в Jira версии 7.2.13 и выше.
[0076] Система может взаимодействовать со службами каталогов AD/LDAP 150 для получения данных о пользователях и группах и авторизации их в системе для предоставления ресурсов.
[0077] Также, система поддерживает механизм уведомления о событиях, обращающийся к API сторонних систем (системы непрерывной интеграции, мессенджеры и т.д.).
[0078] Модуль параметров тестов обеспечивает хранение тестовых данных, которые могут быть использованы для параметризации тестов, как ручных, так и автоматизированных и управления ими. Этот модуль представляет из себя хранимый список переменных со значениями. Эти переменные могут вызываться из шагов теста чтобы выбирать какие параметры должны быть использованы в рамках теста. Параметры тестов также связаны с прохождением теста в тест-плане или автотеста в тест-ране. Результат выполнения теста хранит информацию с какими параметрами этот тест запускался и был пройден. Также этот модуль подразумевает возможность автоматической генерации тестовых данных.
[0079] Модуль требований обеспечивает возможности управления требованиями, их заведения, хранения и модификации, указания их связей с тестами для дальнейшего построения отчетности в модуле дашбордов.
[0080] Модуль дефектов обеспечивает возможности управления дефектами и задачами, хранение дефектов и задач, смену их статусов, указание связей с требованиями и тестами, для дальнейшего построения отчетности по дефектам и задачам в модуле дашбордов. Данные модуля дефекта могут быть интегрированы с внешними инструментами отслеживания задач/дефектов,
20 интеграция подразумевает двустороннюю связь дефектов внутри системы управления тестированием и во внешнем инструменте, наследование статусной модели и рабочих процессов сущностей дефектов и задач, возможность получения дополнительной информации о дефектах/задачах из внешнего инструмента.
[0081] Ссылаясь на Фиг. 4, данное техническое решение может быть реализовано в виде вычислительной системы 400 управления тестированием программного обеспечения, которая содержит один или более из следующих компонентов:
• компонент 401 обработки, содержащий по меньшей мере один процессор 402,
• память 403,
• компонент 405 мультимедиа,
• компонент 406 аудио,
• интерфейс 407 ввода / вывода (I / О),
• сенсорный компонент 408,
• компонент 409 передачи данных.
[0082] Компонент 401 обработки в основном управляет всеми операциями системы 400, например, осуществляет обработку данных о пользователе или его запросе на осуществление тестирования, а также управляет дисплеем, телефонным звонком, передачей данных, работой камеры и операцией записи мобильного устройства связи. Компонент 401 обработки может включать в себя один или более процессоров 402, реализующих инструкции для завершения всех или части шагов из указанных выше способов. Кроме того, компонент 401 обработки может включать в себя один или более модулей для удобного процесса взаимодействия между другими модулями 401 обработки и другими модулями. Например, компонент 401 обработки может включать в себя мультимедийный модуль для удобного облегченного взаимодействия между компонентом 405 мультимедиа и компонентом 401 обработки.
[0083] Память 403 выполнена с возможностью хранения различных типов данных для поддержки работы системы 400, например, базу данных с
21 профилями пользователей. Примеры таких данных включают в себя инструкции из любого приложения или способа, контактные данные, данные адресной книги, сообщения, изображения, видео, и т. д., и все они работают на системе 400. Память 403 может быть реализована в виде любого типа энергозависимого запоминающего устройства, энергонезависимого запоминающего устройства или их комбинации, например, статического оперативного запоминающего устройства (СОЗУ), Электрически-Стираемого Программируемого постоянного запоминающего устройства (ЭСППЗУ), Стираемого Программируемого постоянного запоминающего устройства (СППЗУ), Программируемого постоянного запоминающего устройства (ППЗУ), постоянного запоминающего устройства (ПЗУ), магнитной памяти, флэш- памяти, магнитного диска или оптического диска и другого, не ограничиваясь. [0084] Компонент 405 мультимедиа включает в себя экран, обеспечивающий выходной интерфейс между системой 400, которая может быть установлена на мобильном устройстве связи пользователя и пользователем. В некоторых вариантах реализации, экран может быть жидкокристаллическим дисплеем (ЖКД) или сенсорной панелью (СП). Если экран включает в себя сенсорную панель, экран может быть реализован в виде сенсорного экрана для приема входного сигнала от пользователя. Сенсорная панель включает один или более сенсорных датчиков в смысле жестов, прикосновения и скольжения по сенсорной панели. Сенсорный датчик может не только чувствовать границу прикосновения субъекта или жест перелистывания, но и определять длительность времени и давления, связанных с режимом работы на прикосновение и скольжение. В некоторых вариантах осуществления компонент 405 мультимедиа включает одну фронтальную камеру и/или одну заднюю камеру. Когда система 400 находится в режиме работы, например, режиме съемки или режиме видео, фронтальная камера и/или задняя камера могут получать данные мультимедиа извне. Каждая фронтальная камера и задняя камера, может быть, одной фиксированной оптической системой объектива или может иметь фокусное расстояние или оптический зум.
22 [0085] Компонент 406 аудио выполнен с возможностью выходного и/или входного аудио сигнала. Например, компонент 406 аудио включает один микрофон (MIC), который выполнен с возможностью получать внешний аудио сигнал, когда система 400 находится в режиме работы, например, режиме вызова, режима записи и режима распознавания речи. Полученный аудио сигнал может быть далее сохранен в памяти 403 или направлен по компоненту 409 передачи данных. В некоторых вариантах осуществления компонент 406 аудио также включает в себя один динамик выполненный с возможностью вывода аудио сигнала.
[0086] Интерфейс 407 ввода / вывода (I / О) обеспечивает интерфейс между компонентом 401 обработки и любым периферийным интерфейсным модулем. Вышеуказанным периферийным интерфейсным модулем может быть клавиатура, руль, кнопка, и т. д. Эти кнопки могут включать, но не ограничиваясь, кнопку запуска, кнопку регулировки громкости, начальную кнопку и кнопку блокировки.
[0087] Сенсорный компонент 408 содержит один или более сенсоров и выполнен с возможностью обеспечения различных аспектов оценки состояния системы 400. Например, сенсорный компонент 408 может обнаружить состояния вкл/выкл системы 400, относительное расположение компонентов, например, дисплея и кнопочной панели, одного компонента системы 400, наличие или отсутствие контакта между субъектом и системой 400, а также ориентацию или ускорение/замедление и изменение температуры системы 400. Сенсорный компонент 408 содержит бесконтактный датчик, выполненный с возможностью обнаружения присутствия объекта, находящегося поблизости, когда нет физического контакта. Сенсорный компонент 408 содержит оптический датчик (например, КМОП или ПЗС-датчик изображения) выполненный с возможностью использования в визуализации приложения. В некоторых вариантах сенсорный компонент 408 содержит датчик ускорения, датчик гироскопа, магнитный датчик, датчик давления или датчик температуры.
23 [0088] Компонент 409 передачи данных выполнен с возможностью облегчения проводной или беспроводной связи между системой 400 и другими устройствами. Система 400 может получить доступ к беспроводной сети на основе стандарта связи, таких как WiFi, 2G, 3G, 5G, или их комбинации. В одном примерном варианте компонент 409 передачи данных получает широковещательный сигнал или трансляцию, связанную с ними информацию из внешней широковещательной системы управления через широковещательный канал. В одном варианте осуществления компонент 409 передачи данных содержит модуль коммуникации ближнего поля (NFC), чтобы облегчить ближнюю связь. Например, модуль NFC может быть основан на технологии радиочастотной идентификации (RFID), технологии ассоциации передачи данных в инфракрасном диапазоне (IrDA), сверхширокополосных (UWB) технологии, Bluetooth (ВТ) технологии и других технологиях.
[0089] В примерном варианте осуществления система 400 может быть реализована посредством одной или более Специализированных Интегральных Схем (СИС), Цифрового Сигнального Процессора (ЦСП), Устройств Цифровой Обработки Сигнала (УЦОС), Программируемым Логическим Устройством (ПЛУ), логической микросхемой, программируемой в условиях эксплуатации (ППВМ), контроллера, микроконтроллера, микропроцессора или других электронных компонентов, и может быть сконфигурирован для реализации способа управления тестированием программного обеспечения.
[0090] В примерном варианте осуществления энергонезависимый машиночитаемый носитель содержит память 403, которая включает инструкции, где инструкции выполняются процессором 401 системы 400 для реализации описанных выше способов осуществления умного поиска авиабилетов. Например, энергонезависимым машиночитаемым носителем может быть ПЗУ, оперативное запоминающее устройство (ОЗУ), компакт-диск, магнитная лента, дискеты, оптические устройства хранения данных и тому подобное.
24 [0091] Вычислительная система 400 может включать в себя интерфейс дисплея, который передает графику, текст и другие данные из коммуникационной инфраструктуры (или из буфера кадра, не показан) для отображения на компоненте 405 мультимедиа. Вычислительная система 400 дополнительно включает в себя устройства ввода или периферийные устройства. Периферийные устройства могут включать в себя одно или несколько устройств для взаимодействия с мобильным устройством связи пользователя, такие как клавиатура, микрофон, носимое устройство, камера, один или более звуковых динамиков и другие датчики. Периферийные устройства могут быть внешними или внутренними по отношению к мобильному устройству связи пользователя. Сенсорный экран может отображать, как правило, графику и текст, а также предоставляет пользовательский интерфейс (например, но не ограничиваясь ими, графический пользовательский интерфейс (GUI)), через который субъект может взаимодействовать с мобильным устройством связи пользователя, например, получать доступ и взаимодействовать с приложениями, запущенными на устройстве.
[0092] Элементы заявляемого технического решения находятся в функциональной взаимосвязи, а их совместное использование приводит к созданию нового и уникального технического решения. Таким образом, все блоки функционально связаны.
[0093] Все блоки, используемые в системе, могут быть реализованы с помощью электронных компонент, используемых для создания цифровых интегральных схем, что очевидно для специалиста в данном уровне техники. Не ограничиваюсь, могут использоваться микросхемы, логика работы которых определяется при изготовлении, или программируемые логические интегральные схемы (ПЛИС), логика работы которых задаётся посредством программирования. Для программирования используются программаторы и отладочные среды, позволяющие задать желаемую структуру цифрового устройства в виде принципиальной электрической схемы или программы на специальных языках описания аппаратуры: Verilog, VHDL, AHDL и др.
25 Альтернативой ПЛИС могут быть программируемые логические контроллеры (ПЛК), базовые матричные кристаллы (БМК), требующие заводского производственного процесса для программирования; ASIC специализированные заказные большие интегральные схемы (БИС), которые при мелкосерийном и единичном производстве существенно дороже.
[0094] Обычно, сама микросхема ПЛИС состоит из следующих компонент:
• конфигурируемых логических блоков, реализующих требуемую логическую функцию;
• программируемых электронных связей между конфигурируемыми логическими блоками;
• программируемых блоков ввода/вывода, обеспечивающих связь внешнего вывода микросхемы с внутренней логикой.
[0095] Также блоки могут быть реализованы с помощью постоянных запоминающих устройств.
[0096] Таким образом, реализация всех используемых блоков достигается стандартными средствами, базирующимися на классических принципах реализации основ вычислительной техники.
[0097] Как будет понятно специалисту в данной области техники, аспекты настоящего технического решения могут быть выполнены в виде системы, способа или компьютерного программного продукта. Соответственно, различные аспекты настоящего технического решения могут быть реализованы исключительно как аппаратное обеспечение, как программное обеспечение (включая прикладное программное обеспечение и так далее) или как вариант осуществления, сочетающий в себе программные и аппаратные аспекты, которые в общем случае могут упоминаться как «модуль», «система» или «архитектура». Кроме того, аспекты настоящего технического решения могут принимать форму компьютерного программного продукта, реализованного на одном или нескольких машиночитаемых носителях, имеющих машиночитаемый программный код, который на них реализован. [0098] Также может быть использована любая комбинация одного или нескольких машиночитаемых носителей. Машиночитаемый носитель
26 хранилища может представлять собой, без ограничений, электронную, магнитную, оптическую, электромагнитную, инфракрасную или полупроводниковую систему, аппарат, устройство или любую подходящую их комбинацию. Конкретнее, примеры (неисчерпывающий список) машиночитаемого носителя хранилища включают в себя: электрическое соединение с помощью одного или нескольких проводов, портативную компьютерную дискету; жесткий диск, оперативную память (ОЗУ), постоянную память (ПЗУ), стираемую программируемую постоянную память (EPROM или Flash-память), оптоволоконное соединение, постоянную память на компакт- диске (CD-ROM), оптическое устройство хранения, магнитное устройство хранения или любую комбинацию вышеперечисленного. В контексте настоящего описания, машиночитаемый носитель хранилища может представлять собой любой гибкий носитель данных, который может содержать или хранить программу для использования самой системой, устройством, аппаратом или в соединении с ними.
[0099] Программный код, встроенный в машиночитаемый носитель, может быть передан с помощью любого носителя, включая, без ограничений, беспроводную, проводную, оптоволоконную, инфракрасную и любую другую подходящую сеть или комбинацию вышеперечисленного.
[00100] Компьютерный программный код для выполнения операций для шагов настоящего технического решения может быть написан на любом языке программирования или комбинаций языков программирования, включая объектно-ориентированный язык программирования, например Python, R, Java, Smalltalk, C++ и так далее, и обычные процедурные языки программирования, например язык программирования «С» или аналогичные языки программирования. Программный код может выполняться на компьютере пользователя полностью, частично, или же как отдельный пакет программного обеспечения, частично на компьютере пользователя и частично на удаленном компьютере, или же полностью на удаленном компьютере. В последнем случае, удаленный компьютер может быть соединен с компьютером пользователя через сеть любого типа, включая локальную сеть
27 (LAN), глобальную сеть (WAN) или соединение с внешним компьютером (например, через Интернет с помощью Интернет-провайдеров).
[00101] Аспекты настоящего технического решения были описаны подробно со ссылкой на блок-схемы, принципиальные схемы и/или диаграммы способов, устройств (систем) и компьютерных программных продуктов в соответствии с вариантами осуществления настоящего технического решения. Следует иметь в виду, что каждый блок из блок-схемы и/или диаграмм, а также комбинации блоков из блок-схемы и/или диаграмм, могут быть реализованы компьютерными программными инструкциями. Эти компьютерные программные инструкции могут быть предоставлены процессору компьютера общего назначения, компьютера специального назначения или другому устройству обработки данных для создания процедуры, таким образом, чтобы инструкции, выполняемые процессором компьютера или другим программируемым устройством обработки данных, создавали средства для реализации функций/действий, указанных в блоке или блоках блок-схемы и/или диаграммы.
[00102] Эти компьютерные программные инструкции также могут храниться на машиночитаемом носителе, который может управлять компьютером, отличным от программируемого устройства обработки данных или отличным от устройств, которые функционируют конкретным образом, таким образом, что инструкции, хранящиеся на машиночитаемом носителе, создают устройство, включающее инструкции, которые осуществляют функции/действия, указанные в блоке блок-схемы и/или диаграммы.
28

Claims

ФОРМУЛА Система управления тестированием программного обеспечения, содержащая,
• по меньшей мере один сервер, выполненный с возможностью осуществления взаимодействие между подсистемами посредством запросов распределённого приложения в сети;
• подсистему проектов, выполненную с возможностью хранения тестовой документации и управления тестированием по каждому отдельному проекту и формирования отчетности в разрезе проектов;
• подсистему библиотеки тестов, выполненную с возможностью хранения тестовой документации и создания иерархической структуры проекта, разработки и согласования тестовой документации;
• подсистему тест-планов, выполненную с возможностью планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями, в соответствии с уровнем нагрузки пользователя;
• подсистему конфигурации, выполненную с возможностью хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками.
• подсистему автоматизированных тестов, выполненную с возможностью хранения информации об автоматизированных тестах, зарегистрированных в системе, а также просмотра и анализа данных о прохождениях автоматизированных тестов;
• подсистему запросов, выполненную с возможностью фильтрации и поиска тестовой документации по проектам и управления сохраненными фильтрами.
29 Система по п. 1, характеризующаяся тем, что подсистема библиотеки тестов имеет структуру для хранения тест-кейсов, разделенных по функциональным областям тестируемого продукта. Система по п. 1 , характеризующаяся тем, что подсистема тест-планов содержит результаты выполнения тестирования. Система по п. 1 , характеризующаяся тем, что в подсистеме тест-планов формируется отчетность по отдельным итерациям тестирования в рамках тест-планов. Система по п. 1 , характеризующаяся тем, что подсистема автоматизированных тестов содержит информацию, отражающую метаинформацию об автоматизированном тесте и/или его название, и/или связанные тест-кейсы, и/или ссылки вложения. Система по п. 1 , характеризующаяся тем, что в подсистеме автоматизированных тестов автоматизированный тест представляет из себя программный код, эмулирующий действия пользователей или сторонней системы в тестируемом продукте. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов регистрируют автоматизированный тест. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов результаты выполнения автоматизированного теста фиксируются с помощью API. Система по п. 8, характеризующаяся тем, что при регистрации результата указывают исход и дополняют временем прохождения и/или приложенными файлами, и/или результатами прохождения каждого шага. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов в случае неуспешного прохождения тестов прикладывают к результату прохождения автоматизированного теста сообщения об обнаруженных ошибках и детальные отчеты о них, которые формируются при прохождении автоматизированного теста.
30
11. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов после получения результатов автоматизированного теста, при разборе полученных данных, указывают класс и категорию проблемы.
12. Система по п. 1 , характеризующаяся тем, что в подсистеме запросов выводятся все тест-кейсы и чек-листы, к которым у пользователя есть доступ.
13.Система по п. 1 , характеризующаяся тем, что в подсистеме запросов поиск выполняется на сервере с использованием фильтров по пользовательским атрибутам и/или приоритетам, и/или статусам.
14. Система по п. 1 , характеризующаяся тем, что в подсистеме запросов поиск выполняется по всем тест-кейсам и чек-листам, на которые у пользователя есть доступ на чтение.
15. Система по п. 1 , характеризующаяся тем, что в подсистеме запросов запрос представляет из себя сохраненные фильтры.
16. Система по п. ^ характеризующаяся тем, что в подсистеме запросов при открытии запроса выводится список всех тест-кейсов и чек-листов, которые подходят под сохраненные фильтры.
17. Система по п. 1 , характеризующаяся тем, что в подсистеме запросов запрос является приватны или публичными.
18. Система по п. 1 , характеризующаяся тем, что запрос открывают по ссылке или размещают на внешнем ресурсе.
31
PCT/RU2021/000474 2021-05-13 2021-10-29 Система управления тестированием программного обеспечения WO2022240310A1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2021113580 2021-05-13
RU2021113580A RU2774659C1 (ru) 2021-05-13 Система управления тестированием программного обеспечения

Publications (1)

Publication Number Publication Date
WO2022240310A1 true WO2022240310A1 (ru) 2022-11-17

Family

ID=84029722

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2021/000474 WO2022240310A1 (ru) 2021-05-13 2021-10-29 Система управления тестированием программного обеспечения

Country Status (1)

Country Link
WO (1) WO2022240310A1 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116304399A (zh) * 2023-05-19 2023-06-23 建信金融科技有限责任公司 测试案例的可视化处理方法、装置及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9389849B2 (en) * 2009-02-03 2016-07-12 Globalfoundries Inc. Test case pattern matching
CN106897217A (zh) * 2017-02-13 2017-06-27 北京趣拿软件科技有限公司 测试方法和测试装置
US20190278700A1 (en) * 2018-03-07 2019-09-12 Jpmorgan Chase Bank, N.A. System and method for automated service layer testing and regression
US20200111334A1 (en) * 2014-09-02 2020-04-09 Apple Inc. Semantic Framework for Variable Haptic Output

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9389849B2 (en) * 2009-02-03 2016-07-12 Globalfoundries Inc. Test case pattern matching
US20200111334A1 (en) * 2014-09-02 2020-04-09 Apple Inc. Semantic Framework for Variable Haptic Output
CN106897217A (zh) * 2017-02-13 2017-06-27 北京趣拿软件科技有限公司 测试方法和测试装置
US20190278700A1 (en) * 2018-03-07 2019-09-12 Jpmorgan Chase Bank, N.A. System and method for automated service layer testing and regression

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116304399A (zh) * 2023-05-19 2023-06-23 建信金融科技有限责任公司 测试案例的可视化处理方法、装置及系统
CN116304399B (zh) * 2023-05-19 2023-08-11 建信金融科技有限责任公司 测试案例的可视化处理方法、装置及系统

Similar Documents

Publication Publication Date Title
US10503493B2 (en) Distributed versioning of applications using cloud-based systems
RU2550520C1 (ru) Обеспечение возможностей конфигурируемого технологического процесса
US10310969B2 (en) Systems and methods for test prediction in continuous integration environments
US10628237B2 (en) Cloud service integration flow
US8707246B2 (en) Engineering project event-driven social networked collaboration
US11755461B2 (en) Asynchronous consumer-driven contract testing in micro service architecture
US20170068595A1 (en) Etl diagnostics
US20200125344A1 (en) Persistent context for reusable pipeline components
US10303461B2 (en) Composite instance patching
US20220092119A1 (en) Integrated views of multiple different computer program applications with action options
US20140123114A1 (en) Framework for integration and execution standardization (fiesta)
US11709759B2 (en) Contextual drill back to source code and other resources from log data
US11790224B2 (en) Machine learning from the integration flow metadata
US10452757B2 (en) Persistent user personalization
Rattanapoka et al. An MQTT-based IoT cloud platform with flow design by Node-RED
WO2022240310A1 (ru) Система управления тестированием программного обеспечения
US20190026260A1 (en) Difference tracker
RU2774659C1 (ru) Система управления тестированием программного обеспечения
Shrivastava Learning Salesforce Einstein
US20070028174A1 (en) Grid processing dynamic screensaver
Familiar et al. Data visualizations, alerts, and notifications with power BI
US20240220237A1 (en) Smart grouping of code packages
Ramsland et al. Develop a generic Rules Engine to quality control a CV database
Kumar et al. Customer-Vehicle Management System
Güntensperger et al. Sieve-Data Privacy Made Simple

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: 21942079

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21942079

Country of ref document: EP

Kind code of ref document: A1