СИСТЕМА УПРАВЛЕНИЯ ТЕСТИРОВАНИЕМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Российский патент 2022 года по МПК G06F11/36 G06F11/25 G06F9/44 

ОБЛАСТЬ ТЕХНИКИ

[001] Данное техническое решение относится в общем к области вычислительной техники, а в частности к системам управления тестированием, предназначенным для упорядоченного хранения тестовой документации, планирования тестирования, а также стандартизации и хранения информации о результатах ручного и автоматизированного тестирования в единой среде и построения отчетности.

УРОВЕНЬ ТЕХНИКИ

[002] В настоящее время системы управления тестированием используются для хранения информации о том, как должным образом проводить тестирование, осуществление очередности проведения тестирования в соответствии с его планом, а также для получения информации в виде отчетов о стадии тестирования и качестве тестируемого продукта или другими словами программного обеспечения. Инструменты имеют различные подходы к тестированию и, таким образом, включают в себя различные наборы функций. Обычно они используются для планирования ручного тестирования, сбора данных о результатах прохождения чек-листов и тест-кейсов, а также для получения оперативной информации в виде отчетов. Системы управления тестированием помогают оптимизировать процесс тестирования и обеспечивают быстрый доступ к анализу данных, средствам совместной работы и более качественному взаимодействию между несколькими проектными группами. Многие системы управления тестированием включают в себя возможность работы с требованиями.

[003] Недостатки ручного тестирования, которое очень распространено повсеместно при анализе программного обеспечения, вполне понятны и очевидны. Ручное тестирование выполняется значительно медленнее автоматического. Порой это может занять пару недель вручную вместо одного часа скриптом, в других случаях может соотношение может колебаться в меньших пределах. При этом хорошо написанный скрипт не ошибается и не пропускает дефекты, устав от однообразной рутины день за днем, в отличие от инженера. Вручную практически невозможно выполнять сценарии, требующие большой скорости действий или крайне высокой точности по времени.

[004] Из уровня техники известен способ, раскрытый в CN106897217A «Способ тестирования и устройство для тестирования» (патентообладатель: BEIJING QUNAR SOFTWARE TECH СО LTD, дата публикации: 2017-06-27). В изобретении заявлены метод тестирования и устройство для тестирования, причем способ включает следующие этапы: получение по меньшей мере одного сообщения с запросом, при этом сообщение с запросом используется для тестирования программы, по меньшей мере одно сообщение с запросом отправляется в программу для проверки версии для получения первого результата тестирования и отправка в стабильную версию программы для получения второго результата тестирования, при этом программа стабильной версии представляет собой сообщение с запросом, может возвращать результат программы, сравнивая первый результат теста и второй результат теста, получая результат сравнения, при этом результат сравнения предназначен для определения функциональной стабильности тестовой версии. Изобретение решает проблему, заключающуюся в том, что тестируемый пример тестирует код в предшествующем уровне техники, тем самым увеличивая стоимость поддержки программного обеспечения в уровне техники.

СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ

[005] Технической проблемой или технической задачей, решаемой в данном техническом решении, является создание автоматизированной системы управления тестированием программного обеспечения.

[006] Техническим результатом, достигаемым при решении вышеуказанной технической проблемы, является повышение качества автоматизированного тестирования программного обеспечения.

[007] Дополнительно достигаемым техническим результатом является упорядоченное хранение тестовой документации с учетом всех версий документа с возможностью восстановления любой версии документа при необходимости.

[008] Также осуществляется

• использование единой точки получения информации для принятия управленческих решений;

• возможность внедрения процесса контроля качества, обеспеченная универсальными настраиваемыми пользовательскими атрибутами в системе;

• распределение уровней доступа к тестовой документации и результатам выполнения тестирования, которое позволяет ограничивать доступ к содержащейся в ней информации, которая может являться коммерческой тайной.

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

[0010] В некоторых вариантах реализации технического решения подсистема библиотеки тестов имеет структуру для хранения тест-кейсов, разделенных по функциональным областям тестируемого продукта.

[0011] В некоторых вариантах реализации технического решения подсистема тест-планов содержит результаты выполнения тестирования.

[0012] В некоторых вариантах реализации технического решения в подсистеме тест-планов формируется отчетность по отдельным итерациям тестирования в рамках тест-планов.

[0013] В некоторых вариантах реализации технического решения подсистема автоматизированных тестов содержит информацию, отражающую метаинформацию об автоматизированном тесте и/или его название, и/или связанные тест-кейсы, и/или ссылки вложения.

[0014] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов автоматизированный тест представляет из себя программный код, эмулирующий действия пользователей или сторонней системы в тестируемом продукте.

[0015] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов регистрируют автоматизированный тест.

[0016] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов результаты выполнения автоматизированного теста фиксируются с помощью API.

[0017] В некоторых вариантах реализации технического решения при регистрации результата указывают исход и дополняют временем прохождения и/или приложенными файлами, и/или результатами прохождения каждого шага.

[0018] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов в случае неуспешного прохождения тестов прикладывают к результату прохождения автоматизированного теста сообщения об обнаруженных ошибках и детальные отчеты о них, которые формируются при прохождении автоматизированного теста.

[0019] В некоторых вариантах реализации технического решения в подсистеме автоматизированных тестов после получения результатов автоматизированного теста, при разборе полученных данных, указывают класс и категорию проблемы.

[0020] В некоторых вариантах реализации технического решения в подсистеме запросов выводятся все тест-кейсы и чек-листы, к которым у пользователя есть доступ.

[0021] В некоторых вариантах реализации технического решения в подсистеме запросов поиск выполняется на сервере с использованием фильтров по пользовательским атрибутам и/или приоритетам, и/или статусам.

[0022] В некоторых вариантах реализации технического решения в подсистеме запросов поиск выполняется по всем тест-кейсам и чек-листам, на которые у пользователя есть доступ на чтение.

[0023] В некоторых вариантах реализации технического решения в подсистеме запросов запрос представляет из себя сохраненные фильтры.

[0024] В некоторых вариантах реализации технического решения в подсистеме запросов при открытии запроса выводится список всех тест-кейсов и чек-листов, которые подходят под сохраненные фильтры.

[0025] В некоторых вариантах реализации технического решения в подсистеме запросов запрос является приватны или публичными.

[0026] В некоторых вариантах реализации технического решения запрос открывают по ссылке или размещают на внешнем ресурсе.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0027] Признаки и преимущества настоящего технического решения станут очевидными из приведенного ниже подробного описания и прилагаемых чертежей, на которых:

[0028] На Фиг. 1 показан пример реализации схемы взаимодействия с внешними сервисами системы управления тестированием программного обеспечения.

[0029] На Фиг. 2 показан пример реализации системы управления тестированием программного обеспечения.

[0030] На Фиг. 3 показан пример реализации подсистемы проектов.

[0031] На Фиг. 4 показан вариант реализации системы управления тестированием программного обеспечения.

[0032] На Фиг. 5 показан пример реализации подсистемы библиотеки тестов, предназначенная для хранения тестовой документации.

[0033] На Фиг. 6 показан пример реализации подсистемы тест-планов, которая предназначена для планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями.

[0034] На Фиг. 7 показан пример реализации подсистемы конфигурации, которая предназначена для хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками.

[0035] На Фиг. 8 показан вариант реализации подсистемы автотестов, которая предназначена для хранения информации об автоматизированных тестах, зарегистрированных в системе управления тестированием, а также просмотра и анализа данных о прохождениях автоматизированных тестов

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0036] Ниже будут подробно рассмотрены термины и их определения, используемые в описании технического решения.

[0037] В данном изобретении под системой подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций), централизованные и распределенные базы данных, смарт-контракты.

[0038] Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы), смарт-контракт или подобное. Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.

[0039] Программа (иногда - «ПО») - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.

[0040] На Фиг. 1 показан пример реализации схемы взаимодействия системы управления тестированием программного обеспечения с внешними сервисами, которые описаны ниже.

[0041] Браузер 130 - программное обеспечение, предназначенное для просмотра веб-страниц. Работа пользователя с техническим решением проводится через пользовательский интерфейс, отображаемый в браузере 130. Пользовательский интерфейс может быть разработан, например, на фреймворке Angular, который является кроссплатформенным JavaScript-фреймворком, который работает с HTML, используя статическую и динамическую информацию, получаемую от сервера 100 приложения через API (программный интерфейс приложения, интерфейс прикладного программирования).

[0042] REST (RESTful) - это общие принципы организации взаимодействия приложения/сайта с сервером 100 посредством протокола HTTP. Особенность REST в том, что сервер 100 не запоминает состояние пользователя между запросами - в каждом запросе передается информация, идентифицирующая пользователя (например, 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] OpenID Connect провайдер 160 - сервис, реализованный по протоколу OpenID Connect предназначенный для аутентификации пользователей в системе на базе протокола Oauth 2.0. Интеграция с системой управления тестированием программного обеспечения реализована по протоколу OpenID Connect и конфигурируется в панели администратора. Настройки на стороне системы позволяют интегрироваться с любым сервисом, поддерживающим протокол OpenID Connect в части создания пользователей и их аутентификации в системе. Пользователи получают возможность входа через единый сервис аутентификации. В некоторых вариантах реализации могут использоваться биометрические алгоритмы аутентификации, двухфакторная аутентификация, аутентификация по ключам доступа, аутентификация по токенам и т.д., не ограничиваясь.

[0047] Данное техническое решение представляет собой систему управления тестированием программного обеспечения, которая используются для хранения тестовой документации (тест-планов, тестовых наборов, тестовых случаев и чек-листов с проверками функциональности, результатов выполнения тестирования в соответствии с его планом, а также отчетов о стадии тестирования в виде документа, в котором представлена информация о выполненных тестах, их результатах, тестировщиках, которые участвовали в тестировании, найденных дефектах и т.д., не ограничиваясь) и осуществления автоматизированного управления тестированием программного обеспечения. На основании данной информации можно делать выводы о качестве тестируемого продукта или, иными словами, программного обеспечения.

[0048] Тестовый случай (далее - «тест-кейс») - это документ, описывающий последовательность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции программного обеспечения или его части, а также ожидаемые результаты прохождения этих шагов. Тестовый случай формируется на основе функциональных и нефункциональных требований к разрабатываемому ПО.

[0049] Под качеством продукта в данном контексте подразумевается качество тестируемого программного обеспечения, а именно степень соответствия реализованного программного обеспечения требованиям и пригодность его к использованию.

[0050] Тестовая документация описывает варианты использования ПО, в соответствии с требованиями к системе. Любые несоответствия тестируемого ПО первоначальным требованиям расцениваются как дефекты (жарг. «баги»).

[0051] Наличие дефектов (жарг. «багов») расценивается как отсутствие качества. Помимо первоначальных требований к разрабатываемому ПО, на качество влияет пригодность программного обеспечения к использованию, т.е. соответствие вариантов использования ожиданиям конечного пользователя.

[0052] План тестирования (далее - «тест-план») - это документ, описывающий объем работ по тестированию, содержащий информацию об объекте тестирования, стратегии тестирования, сроках тестирования, критериях начала и завершения тестирования, а также перечень проверок, которые должны быть пройдены.

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

[0054] Тестовая документация - это любые артефакты, полученные в ходе планирования, выполнения и фиксации результатов тестирования. На этапе подготовки к тестированию формируются тест-кейсы и чек-листы для них (документ, регламентирующий, что является успехом прохождения тест-кейса). На этапе планирования тестирования формируется тест-план. По результатам выполнения тестирования формируется отчет о результатах тестирования. Все это представляет из себя тестовую документацию в совокупности.

[0055] Система управления тестированием имеет архитектуру «клиент-сервер». «Клиент - сервер» (англ. client-server) - вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами.

[0056] Клиент в данном случае представляет собой браузер 130, в котором открывается графический интерфейс пользователя (англ. «GUI»), предназначенный для взаимодействия пользователя системы с сервером 100 посредством использования компонентов интерфейса.

[0057] Сервером 100 в данном случае являются компоненты системы, осуществляющие получение и обработку запросов от клиента (т.е. из браузера), а также отправку запросов на клиент и иные внешние системы для получения информации.

[0058] Для развертывания и запуска системы используются средства docker - контейнеризации. Docker-контейнеризация - это технология, позволяющая программно на определенном участке памяти изолированно настраивать окружение, а также устанавливать операционные системы и программные продукты внутри различных контейнеров. Контейнеризация позволяет гибко настраивать параметры окружения внутри контейнеров, не меняя при этом настройки глобального сервера. Развертывание и запуск системы происходит с помощью docker compose, что позволяет запускать несколько контейнеров, связанных между собой, в каждом контейнере разворачивается отдельный сервис, настройка связей происходит в соответствии с указанными параметрами. Docker Compose - это инструментальное средство, входящее в состав Docker. Оно предназначено для решения задач, связанных с развертыванием проектов. Docker - программное обеспечение для автоматизации развертывания и управления приложениями в средах с поддержкой контейнеризации, контейнеризатор приложений.

[0059] Одной из отличительных особенностей данного технического решения является наличие общих шагов. Общий шаг - это сущность, которая позволяет хранить и повторно использовать повторяющиеся шаги в разных тестовых случаях. При создании общего шага в него включаются отдельные шаги проверок, повторяющиеся для нескольких тестовых случаев. В качестве примера реализации можно привести авторизацию на тестируемом сайте. Для выполнения большинства проверок нужно сначала выполнить вход под пользователем. Этот шаг будет повторяться во многих тестовых случаях при тестировании работы веб-сайта. Система позволяет создать общий шаг, содержащий в себе необходимые для входа на веб-сайт действия и использовать его во всех проверках. При этом изменение общего шага влечет за собой его изменение во всех тестовых случаях, где он используется. Таким образом, нужно менять только один общий шаг, а не все тестовые случаи, где он упоминается, что экономит время осуществления тестирования.

[0060] В данном решении также реализовано версионирование тест-кейсов, которое подразумевает под собой возможность просматривать предыдущие версии документов после их изменений, «откатываться» на предыдущие версии, причем при просмотре подсвечиваются отличия между версиями.

[0061] Одной из отличительных особенностей данного решения является возможность совместного анализа результатов ручного и автоматизированного тестирования, причем по результатам выполнения тестирования формируется единый отчет в рамках всего тест-плана, где можно увидеть автоматизировано или вручную был пройден тест. В рамках одного тест-плана можно выполнять автоматизированные тесты (далее - автотесты) и ручные тесты, при этом на экране выполнения можно увидеть какие тест-кейсы автоматизированы, т.е. имеют привязанные автотесты, а какие проходятся только вручную. Выбрав автоматизированные тесты, можно запустить прогон автотестов, выполнить запуск автотестов. Параллельно можно выполнять ручные тесты, отмечая их результаты. При прохождении всех тестов на вкладке «Отчет» в режиме реального времени можно увидеть результаты как ручных, так и автоматизированных тестов, с деталями результата. При открытии прогона тестов, можно также увидеть все автотесты, которые пройдены.

[0062] Система управления тестированием предназначена для комплексного информационно-аналитического обеспечения процессов на предприятиях, занимающихся разработкой программного обеспечения в части исполнения следующих процессов:

• создание тестовой документации (тест-кейсы, чек-листы);

• хранение тестовой документации в иерархической структуре, обеспечивающей удобство поиска и навигации по разделам;

• согласование тестовой документации;

• формирование списков тест-кейсов к прохождению, объединенных общими признаками (релиз, задача и т.д.);

• планирование тестирования;

• регистрация результатов выполнения тестирования и хранение истории результатов;

• построения отчетности по тестированию и тестовой документации в проектах;

• мониторинга выполнения автоматизированного тестирования.

[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, с распределением доступа, настраиваемым в модуле администрирования. При этом проект 310.1 содержит в себе такие подмодули как библиотека тестов, конфигурации, параметры тестов, автотесты, требования, дефекты (показаны на Фиг. 3).

[0066] Подсистема библиотеки тестов 510, показанная на Фиг. 5, предназначена для хранения тестовой документации, представляет из себя раздел, в котором создается иерархическая структура проекта 310.1, разрабатывается и согласовывается тестовая документация. Внутри проекта 310.1 создается структура папок для хранения тест-кейсов, разделенных по функциональным областям тестируемого продукта. Такое упорядоченное хранение документации обеспечивает простоту управления тестовой документацией и удобство поиска для пользователей. Подсистема библиотеки тестов 510 выполняет функцию хранилища для тестовой документации, хранимые в ней сущности содержат сценарии проверок, используемых при планировании и выполнении тестирования в тестовых наборах тест-планов. Тест-кейсы и чек-листы используются для создания тестовых наборов в тест-планах, а общие шаги формируются для использования в тест-кейсах. Описание сценариев проверок, хранящихся в библиотеке тестов, может происходить вручную или автоматизировано на основе автотестов. Внутри подсистемы библиотеки тестов реализованы поиск, фильтрация, с возможностью сохранения фильтров, сортировка, а также открытие определенных секций и тестов по прямой ссылке.

[0067] Подсистема тест-планов 610, показанная на Фиг. 6, предназначена для планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями, в соответствии с уровнем нагрузки. Также в этом разделе отражаются результаты выполнения тестирования и формируется отчетность по отдельным итерациям тестирования в рамках тест-планов 620. Тестовые планы 620 включают в себя тестовые наборы, состоящие из тест-кейсов и чек-листов, полученные из подсистемы библиотеки тестов 510. Помимо этого, есть возможность создавать тестовые наборы на основе библиотеки тестов из подсистемы 510, либо по сохраненным фильтрам в библиотеке. Тестовый набор представляет из себя папку с тестами, которые должны быть выполнены, после создания тестового набора к нему применяется конфигурация, на которой будет проводиться тестирование. Параметры конфигурации получают из подсистемы конфигураций, присутствующей в каждом проекте. Тест-план 620 представляет из себя наборы тестов к прохождению, привязанных к определенным конфигурациям, и дает возможность запускать выполнение как ручного так и автоматизированного тестирования внутри тест-плана 620. При запуске выполнения автоматизированных тестов формируется тест-ран. Тест-ран - это прогон какого-то теста в соответствии с заранее определенным тест планом. Результаты ручных тестов указываются пользователями вручную, с возможностью комментирования шагов, прикладывания файлов и ссылок на любые внешние источники в том числе ссылки на дефекты, требования, репозитории кода и любые другие связанные ресурсы. Результаты автоматизированных тестов при выполнении в тест-плане могут быть получены от внешнего инструмента автоматизированного тестирования или инструмента непрерывной интеграции 140 и поставки посредством API, плагинов или библиотек для интеграции.

[0068] Планирование тестирования - это этап тестирования, во время которого определяются цель проведения тестирования, обозначаются сроки проведения тестирования, формируются наборы проверок, которые должны быть выполнены в ходе тестирования исходя из потребностей в тестировании, а также обозначены исполнители тестов. Данная система управления тестированием позволяет автоматизировать процесс планирования тестирования с помощью формирования тест-плана 620, автоматического формирования наборов тестов к прохождению на основе библиотеки тестов из подсистемы библиотеки тестов 510 или вручную на усмотрение пользователя. Для распределения задач между исполнителями используется как ручной способ, так и автоматический способ. При автоматическом распределении задач между исполнителями на каждого исполнителя назначается набор задач на выполнение тестирования с равными оценками времени прохождения тестирования. Время прохождения тестирования задается у каждого кейса автоматически на основе предыдущих прохождений, или вручную исполнителем теста или его руководителем.

[0069] Например, тест в упрощенном виде будет выглядеть, как показано в Таблице 1 ниже.

[0070] Подсистема конфигурации 710, как показано на Фиг. 7, предназначена для хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками. Конфигурации используются для того, чтобы хранить и передавать данные об окружениях, на которых проводится тестирование. Окружение - это набор опций, воспроизводящих условия, необходимые для работы тестируемого программного обеспечения, например, операционные системы, браузеры, устройства и т.д. В конфигурациях в виде «ключ»-«значение» задаются эти опции. Конфигурацию можно использовать при автоматизированном тестировании для подготовки нужного окружения, получив параметры конфигурации. Модуль конфигураций используется в тест-планах 620 в связке с тестами для создания задач на тестирование, а именно представления какой тест на какой конфигурации должен выполняться. Конфигурация применяется к тестовым наборам тест-плана 620. Помимо этого, конфигурации, хранимые в проекте 310.1, используются для формирования прогонов автоматизированных тестов (так называемых тест-ранов). Эти связи обеспечивают возможность построения отчетности в подсистеме дашбордов (будет раскрыта ниже) с группировкой по конфигурации, т.е. просмотра данных о результатах ручных и автоматизированных тестов, тест-планах и тест-ранах в разрезе конфигураций.

[0071] Подсистема автотестов 810, показанная на Фиг. 8, предназначена для хранения информации об автоматизированных тестах, зарегистрированных в системе управления тестированием, а также просмотра и анализа данных о прохождениях автоматизированных тестов. В системе управления тестированием хранится информация, отражающая метаинформацию об автотесте, его название, связанные тест-кейсы, также конкретные шаги, ссылки, вложения и т.д. Для регистрации автотеста в системе управления тестированием используется API 820 (программный интерфейс приложения, интерфейс прикладного программирования) (англ. application programming interface, API). После того как автотест зарегистрирован в системе, появляется возможность сохранять и анализировать данные о его прохождениях, оценивать его влияние на результаты связанных тестов. Автоматизированный тест представляет из себя программный код, эмулирующий действия пользователей или сторонней системы в тестируемом продукте. Результаты выполнения автоматизированного теста также фиксируются в системе управления тестированием с помощью API 820. При регистрации результата проведения автоматического тестирования можно указать исход, а также дополнить это метаинформацией - временем прохождения, дополнительными данными в виде приложенных файлов (скриншоты, логи), результатами прохождения каждого шага. В случае неуспешного прохождения тестов можно прикладывать к результату прохождения автоматизированного теста сообщения об обнаруженных ошибках и детальные отчеты о них, которые формируются при прохождении автотеста. Интеграция с автоматизированными тестами с помощью API позволяет использовать любые средства автоматизации тестирования. После получения результатов автоматизированного теста, при разборе полученных данных, можно указывать класс и категорию проблемы. Данная возможность используется для автоматизированного анализа категорий проблем. Модуль автотестов позволяет регистрировать автоматизированные тесты в системе, автотесты связываются с ручными тестами в библиотеке, а также с параметрами тестов, хранимых в проекте 310.1, что обеспечивает возможность выполнения ручного и автоматизированного тестирования совместно в рамках тест-планов 620, а также возможность регистрации результатов выполнения автоматизированных тестов отдельно от ручных в рамках тест-планов 620. Информация об автотестах и результатах их выполнения получается от инструмента непрерывной интеграции 140 и поставки, либо от инструмента автоматизированного тестирования, посредством API 820, плагинов и клиентских библиотек. Автотесты и их результаты можно выводить в виджетах дашбордов, в соответствии с настройками виджетов.

[0072] Модуль тест-ранов предназначен для сбора информации о выполнении автоматизированных тестов во внешней среде с помощью инструмента автоматизированного тестирования. Данные о прохождениях принимаются от инструментов автоматизированного тестирования и инструментов непрерывной интеграции 140 и поставки.

[0073] Подсистема запросов (не показана на фигурах), в которой осуществляется фильтрация и поиск тестовой документации по проектам, с возможностью управления сохраненными фильтрами. В разделе запросов выводятся все тест-кейсы и чек-листы, к которым у пользователя есть доступ. Поиск выполняется на сервере 100, с использованием различных фильтров. Доступна фильтрация по всем параметрам и дополнительным данным, таким как пользовательские атрибуты, приоритеты, статусы. Поиск осуществляется по всем тест-кейсам и чек-листам, на которые у пользователя есть доступ по меньшей мере на чтение. Можно составить набор фильтров и сохранить запрос. Запрос представляет из себя сохраненные фильтры. При открытии запроса выводится список всех тест-кейсов и чек-листов, которые подходят под сохраненные фильтры. Результат меняется, если в каких-то из выводимых кейсов сменятся актуальные значения параметров, содержащихся в запросе. Запросы можно делать приватными (доступными только пользователю) или публичными (доступными всем пользователям системы). Запрос можно открыть по ссылке, что позволяет передавать ссылку другим пользователям, либо размещать где-то на внешних ресурсах. В запросах выполняется поиск по данным, хранящимся в библиотеках тестов, всех доступных проектов, данные в подсистему запросов поступают из многих проектов, но с учетом разграничений прав доступа.

[0074] Подсистема дашбордов (не показана на фигурах), в которой осуществляется формирование отчетности по проектам. Дашборд - инструмент визуализации и анализа данных. Если говорить проще, то инфографика - одна из составляющих частей дашборда. Каждый дашборд представляет из себя набор настраиваемых виджетов. Виджет - примитив графического интерфейса пользователя, имеющий стандартный внешний вид и выполняющий стандартные действия. При создании виджета можно выбрать тип представления информации, источник данных для формирования отчета, а также дополнительно сгруппировать полученные значения по отдельным параметрам в зависимости от источника данных. Гибкая система создания виджетов позволяет выводить большинство необходимой информации, хранящейся в системе, в удобном представлении. Доступные представления - это график трендов, круговые диаграммы, линейчатые диаграммы, табличное представление. Доступные источники данных - это тесты, результаты выполнения тестов, тест-планы, прогоны автоматизированных тестов. Таким образом подсистема дашбордов связана со всеми остальными функциональными областями системы т.к. отчетность в виджетах может иметь в качестве источников данных любые данные, хранимые в рамках проектов, библиотек тестов, конфигураций, параметров тестов, автотесты, требования и дефекты. Возможности построения отчетности по требованиям включают в себя трассировку требований, матрицу покрытия требований тестами, а также косвенную связь между требованиями и дефектами, обнаруженными в результате выполнения привязанных к ним тестов.

[0075] Система управления тестированием программного обеспечения взаимодействуете системой отслеживания ошибок 160, например, Jira, посредством плагина, устанавливаемого в Jira версии 7.2.13 и выше.

[0076] Система может взаимодействовать со службами каталогов AD/LDAP 150 для получения данных о пользователях и группах и авторизации их в системе для предоставления ресурсов.

[0077] Также, система поддерживает механизм уведомления о событиях, обращающийся к API сторонних систем (системы непрерывной интеграции, мессенджеры и т.д.).

[0078] Модуль параметров тестов обеспечивает хранение тестовых данных, которые могут быть использованы для параметризации тестов, как ручных, так и автоматизированных и управления ими. Этот модуль представляет из себя хранимый список переменных со значениями. Эти переменные могут вызываться из шагов теста чтобы выбирать какие параметры должны быть использованы в рамках теста. Параметры тестов также связаны с прохождением теста в тест-плане или автотеста в тест-ране. Результат выполнения теста хранит информацию с какими параметрами этот тест запускался и был пройден. Также этот модуль подразумевает возможность автоматической генерации тестовых данных.

[0079] Модуль требований обеспечивает возможности управления требованиями, их заведения, хранения и модификации, указания их связей с тестами для дальнейшего построения отчетности в модуле дашбордов.

[0080] Модуль дефектов обеспечивает возможности управления дефектами и задачами, хранение дефектов и задач, смену их статусов, указание связей с требованиями и тестами, для дальнейшего построения отчетности по дефектам и задачам в модуле дашбордов. Данные модуля дефекта могут быть интегрированы с внешними инструментами отслеживания задач/дефектов, интеграция подразумевает двустороннюю связь дефектов внутри системы управления тестированием и во внешнем инструменте, наследование статусной модели и рабочих процессов сущностей дефектов и задач, возможность получения дополнительной информации о дефектах/задачах из внешнего инструмента.

[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, например, базу данных с профилями пользователей. Примеры таких данных включают в себя инструкции из любого приложения или способа, контактные данные, данные адресной книги, сообщения, изображения, видео, и т.д., и все они работают на системе 400. Память 403 может быть реализована в виде любого типа энергозависимого запоминающего устройства, энергонезависимого запоминающего устройства или их комбинации, например, статического оперативного запоминающего устройства (СОЗУ), Электрически-Стираемого Программируемого постоянного запоминающего устройства (ЭСППЗУ), Стираемого Программируемого постоянного запоминающего устройства (СППЗУ), Программируемого постоянного запоминающего устройства (ППЗУ), постоянного запоминающего устройства (ПЗУ), магнитной памяти, флэш-памяти, магнитного диска или оптического диска и другого, не ограничиваясь.

[0084] Компонент 405 мультимедиа включает в себя экран, обеспечивающий выходной интерфейс между системой 400, которая может быть установлена на мобильном устройстве связи пользователя и пользователем. В некоторых вариантах реализации, экран может быть жидкокристаллическим дисплеем (ЖКД) или сенсорной панелью (СП). Если экран включает в себя сенсорную панель, экран может быть реализован в виде сенсорного экрана для приема входного сигнала от пользователя. Сенсорная панель включает один или более сенсорных датчиков в смысле жестов, прикосновения и скольжения по сенсорной панели. Сенсорный датчик может не только чувствовать границу прикосновения субъекта или жест перелистывания, но и определять длительность времени и давления, связанных с режимом работы на прикосновение и скольжение. В некоторых вариантах осуществления компонент 405 мультимедиа включает одну фронтальную камеру и/или одну заднюю камеру. Когда система 400 находится в режиме работы, например, режиме съемки или режиме видео, фронтальная камера и/или задняя камера могут получать данные мультимедиа извне. Каждая фронтальная камера и задняя камера, может быть, одной фиксированной оптической системой объектива или может иметь фокусное расстояние или оптический зум.

[0085] Компонент 406 аудио выполнен с возможностью выходного и/или входного аудио сигнала. Например, компонент 406 аудио включает один микрофон (MIC), который выполнен с возможностью получать внешний аудио сигнал, когда система 400 находится в режиме работы, например, режиме вызова, режима записи и режима распознавания речи. Полученный аудио сигнал может быть далее сохранен в памяти 403 или направлен по компоненту 409 передачи данных. В некоторых вариантах осуществления компонент 406 аудио также включает в себя один динамик, выполненный с возможностью вывода аудио сигнала.

[0086] Интерфейс 407 ввода / вывода (I / О) обеспечивает интерфейс между компонентом 401 обработки и любым периферийным интерфейсным модулем. Вышеуказанным периферийным интерфейсным модулем может быть клавиатура, руль, кнопка, и т.д. Эти кнопки могут включать, но не ограничиваясь, кнопку запуска, кнопку регулировки громкости, начальную кнопку и кнопку блокировки.

[0087] Сенсорный компонент 408 содержит один или более сенсоров и выполнен с возможностью обеспечения различных аспектов оценки состояния системы 400. Например, сенсорный компонент 408 может обнаружить состояния вкл/выкл системы 400, относительное расположение компонентов, например, дисплея и кнопочной панели, одного компонента системы 400, наличие или отсутствие контакта между субъектом и системой 400, а также ориентацию или ускорение/замедление и изменение температуры системы 400. Сенсорный компонент 408 содержит бесконтактный датчик, выполненный с возможностью обнаружения присутствия объекта, находящегося поблизости, когда нет физического контакта. Сенсорный компонент 408 содержит оптический датчик (например, КМОП или ПЗС-датчик изображения) выполненный с возможностью использования в визуализации приложения. В некоторых вариантах сенсорный компонент 408 содержит датчик ускорения, датчик гироскопа, магнитный датчик, датчик давления или датчик температуры.

[0088] Компонент 409 передачи данных выполнен с возможностью облегчения проводной или беспроводной связи между системой 400 и другими устройствами. Система 400 может получить доступ к беспроводной сети на основе стандарта связи, таких как WiFi, 2G, 3G, 5G, или их комбинации. В одном примерном варианте компонент 409 передачи данных получает широковещательный сигнал или трансляцию, связанную с ними информацию из внешней широковещательной системы управления через широковещательный канал. В одном варианте осуществления компонент 409 передачи данных содержит модуль коммуникации ближнего поля (NFC), чтобы облегчить ближнюю связь. Например, модуль NFC может быть основан на технологии радиочастотной идентификации (RFID), технологии ассоциации передачи данных в инфракрасном диапазоне (IrDA), сверхширокополосных (UWB) технологии, Bluetooth (ВТ) технологии и других технологиях.

[0089] В примерном варианте осуществления система 400 может быть реализована посредством одной или более Специализированных Интегральных Схем (СИС), Цифрового Сигнального Процессора (ЦСП), Устройств Цифровой Обработки Сигнала (УЦОС), Программируемым Логическим Устройством (ПЛУ), логической микросхемой, программируемой в условиях эксплуатации (ППВМ), контроллера, микроконтроллера, микропроцессора или других электронных компонентов, и может быть сконфигурирован для реализации способа управления тестированием программного обеспечения.

[0090] В примерном варианте осуществления энергонезависимый машиночитаемый носитель содержит память 403, которая включает инструкции, где инструкции выполняются процессором 401 системы 400 для реализации описанных выше способов осуществления умного поиска авиабилетов. Например, энергонезависимым машиночитаемым носителем может быть ПЗУ, оперативное запоминающее устройство (ОЗУ), компакт-диск, магнитная лента, дискеты, оптические устройства хранения данных и тому подобное.

[0091] Вычислительная система 400 может включать в себя интерфейс дисплея, который передает графику, текст и другие данные из коммуникационной инфраструктуры (или из буфера кадра, не показан) для отображения на компоненте 405 мультимедиа. Вычислительная система 400 дополнительно включает в себя устройства ввода или периферийные устройства. Периферийные устройства могут включать в себя одно или несколько устройств для взаимодействия с мобильным устройством связи пользователя, такие как клавиатура, микрофон, носимое устройство, камера, один или более звуковых динамиков и другие датчики. Периферийные устройства могут быть внешними или внутренними по отношению к мобильному устройству связи пользователя. Сенсорный экран может отображать, как правило, графику и текст, а также предоставляет пользовательский интерфейс (например, но не ограничиваясь ими, графический пользовательский интерфейс (GUI)), через который субъект может взаимодействовать с мобильным устройством связи пользователя, например, получать доступ и взаимодействовать с приложениями, запущенными на устройстве.

[0092] Элементы заявляемого технического решения находятся в функциональной взаимосвязи, а их совместное использование приводит к созданию нового и уникального технического решения. Таким образом, все блоки функционально связаны.

[0093] Все блоки, используемые в системе, могут быть реализованы с помощью электронных компонент, используемых для создания цифровых интегральных схем, что очевидно для специалиста в данном уровне техники. Не ограничиваюсь, могут использоваться микросхемы, логика работы которых определяется при изготовлении, или программируемые логические интегральные схемы (ПЛИС), логика работы которых задается посредством программирования. Для программирования используются программаторы и отладочные среды, позволяющие задать желаемую структуру цифрового устройства в виде принципиальной электрической схемы или программы на специальных языках описания аппаратуры: Verilog, VHDL, AHDL и др. Альтернативой ПЛИС могут быть программируемые логические контроллеры (ПЛК), базовые матричные кристаллы (БМК), требующие заводского производственного процесса для программирования; ASIC - специализированные заказные большие интегральные схемы (БИС), которые при мелкосерийном и единичном производстве существенно дороже.

[0094] Обычно, сама микросхема ПЛИС состоит из следующих компонент:

• конфигурируемых логических блоков, реализующих требуемую логическую функцию;

• программируемых электронных связей между конфигурируемыми логическими блоками;

• программируемых блоков ввода/вывода, обеспечивающих связь внешнего вывода микросхемы с внутренней логикой.

[0095] Также блоки могут быть реализованы с помощью постоянных запоминающих устройств.

[0096] Таким образом, реализация всех используемых блоков достигается стандартными средствами, базирующимися на классических принципах реализации основ вычислительной техники.

[0097] Как будет понятно специалисту в данной области техники, аспекты настоящего технического решения могут быть выполнены в виде системы, способа или компьютерного программного продукта. Соответственно, различные аспекты настоящего технического решения могут быть реализованы исключительно как аппаратное обеспечение, как программное обеспечение (включая прикладное программное обеспечение и так далее) или как вариант осуществления, сочетающий в себе программные и аппаратные аспекты, которые в общем случае могут упоминаться как «модуль», «система» или «архитектура». Кроме того, аспекты настоящего технического решения могут принимать форму компьютерного программного продукта, реализованного на одном или нескольких машиночитаемых носителях, имеющих машиночитаемый программный код, который на них реализован.

[0098] Также может быть использована любая комбинация одного или нескольких машиночитаемых носителей. Машиночитаемый носитель хранилища может представлять собой, без ограничений, электронную, магнитную, оптическую, электромагнитную, инфракрасную или полупроводниковую систему, аппарат, устройство или любую подходящую их комбинацию. Конкретнее, примеры (неисчерпывающий список) машиночитаемого носителя хранилища включают в себя: электрическое соединение с помощью одного или нескольких проводов, портативную компьютерную дискету; жесткий диск, оперативную память (ОЗУ), постоянную память (ПЗУ), стираемую программируемую постоянную память (EPROM или Flash-память), оптоволоконное соединение, постоянную память на компакт-диске (CD-ROM), оптическое устройство хранения, магнитное устройство хранения или любую комбинацию вышеперечисленного. В контексте настоящего описания, машиночитаемый носитель хранилища может представлять собой любой гибкий носитель данных, который может содержать или хранить программу для использования самой системой, устройством, аппаратом или в соединении с ними.

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

[00100] Компьютерный программный код для выполнения операций для шагов настоящего технического решения может быть написан на любом языке программирования или комбинаций языков программирования, включая объектно-ориентированный язык программирования, например Python, R, Java, Smalltalk, С++ и так далее, и обычные процедурные языки программирования, например язык программирования «С» или аналогичные языки программирования. Программный код может выполняться на компьютере пользователя полностью, частично, или же как отдельный пакет программного обеспечения, частично на компьютере пользователя и частично на удаленном компьютере, или же полностью на удаленном компьютере. В последнем случае, удаленный компьютер может быть соединен с компьютером пользователя через сеть любого типа, включая локальную сеть (LAN), глобальную сеть (WAN) или соединение с внешним компьютером (например, через Интернет с помощью Интернет-провайдеров).

[00101] Аспекты настоящего технического решения были описаны подробно со ссылкой на блок-схемы, принципиальные схемы и/или диаграммы способов, устройств (систем) и компьютерных программных продуктов в соответствии с вариантами осуществления настоящего технического решения. Следует иметь в виду, что каждый блок из блок-схемы и/или диаграмм, а также комбинации блоков из блок-схемы и/или диаграмм, могут быть реализованы компьютерными программными инструкциями. Эти компьютерные программные инструкции могут быть предоставлены процессору компьютера общего назначения, компьютера специального назначения или другому устройству обработки данных для создания процедуры, таким образом, чтобы инструкции, выполняемые процессором компьютера или другим программируемым устройством обработки данных, создавали средства для реализации функций/действий, указанных в блоке или блоках блок-схемы и/или диаграммы.

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

Изобретение относится к области вычислительной техники, в частности к системам управления тестированием. Технический результат заключается в повышении качества тестирования программного обеспечения. Система управления тестированием программного обеспечения имеет архитектуру «клиент-сервер», которая запускается посредством docker- контейнеризации и содержит по меньшей мере один сервер, выполненный с возможностью осуществления взаимодействия между подсистемами посредством запросов распределённого приложения в сети REST API, при этом подсистема проектов выполнена с возможностью хранения тестовой документации, подсистема библиотеки тестов выполнена с возможностью хранения тестовой документации и создания иерархической структуры проекта, подсистема тест-планов выполнена с возможностью планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями, подсистема конфигурации выполнена с возможностью хранения и управления конфигурациями, подсистема автоматизированных тестов выполнена с возможностью хранения информации об автоматизированных тестах, зарегистрированных в системе, подсистема запросов выполнена с возможностью фильтрации и поиска тестовой документации. 17 з.п. ф-лы, 1 табл., 8 ил.

1. Система управления тестированием программного обеспечения, имеющая архитектуру «клиент-сервер», которая запускается посредством docker-контейнеризации и содержит,

• по меньшей мере один сервер, выполненный с возможностью осуществления взаимодействия между подсистемами посредством запросов распределённого приложения в сети REST API;

• подсистему проектов, выполненную с возможностью хранения тестовой документации и управления тестированием по каждому отдельному проекту и формирования отчетности в разрезе проектов;

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

• подсистему тест-планов, выполненную с возможностью планирования тестирования, определения объема запланированного тестирования, распределения задач на тестирование между исполнителями, в соответствии с уровнем нагрузки пользователя;

• подсистему конфигурации, выполненную с возможностью хранения конфигураций, на которых проводится тестирование в проекте, управления их настройками.

• подсистему автоматизированных тестов, выполненную с возможностью хранения информации об автоматизированных тестах, зарегистрированных в системе, а также просмотра и анализа данных о прохождениях автоматизированных тестов, причем для регистрации автоматизированного теста в системе используется API;

• подсистему запросов, выполненную с возможностью фильтрации и поиска тестовой документации на сервере по проектам и управления сохраненными фильтрами.

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

3. Система по п. 1, характеризующаяся тем, что подсистема тест-планов содержит результаты выполнения тестирования.

4. Система по п. 1, характеризующаяся тем, что в подсистеме тест-планов формируется отчетность по отдельным итерациям тестирования в рамках тест-планов.

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

6. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов автоматизированный тест представляет из себя программный код, эмулирующий действия пользователей или сторонней системы в тестируемом продукте.

7. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов регистрируют автоматизированный тест.

8. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов результаты выполнения автоматизированного теста фиксируются с помощью API.

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

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

11. Система по п. 1, характеризующаяся тем, что в подсистеме автоматизированных тестов после получения результатов автоматизированного теста, при разборе полученных данных, указывают класс и категорию проблемы.

12. Система по п. 1, характеризующаяся тем, что в подсистеме запросов выводятся все тест-кейсы и чек-листы, к которым у пользователя есть доступ.

13. Система по п. 1, характеризующаяся тем, что в подсистеме запросов поиск выполняется на сервере с использованием фильтров по пользовательским атрибутам и/или приоритетам, и/или статусам.

14. Система по п. 1, характеризующаяся тем, что в подсистеме запросов поиск выполняется по всем тест-кейсам и чек-листам, на которые у пользователя есть доступ на чтение.

15. Система по п. 1, характеризующаяся тем, что в подсистеме запросов запрос представляет из себя сохраненные фильтры.

16. Система по п. 1, характеризующаяся тем, что в подсистеме запросов при открытии запроса выводится список всех тест-кейсов и чек-листов, которые подходят под сохраненные фильтры.

17. Система по п. 1, характеризующаяся тем, что в подсистеме запросов запрос является приватным или публичным.

18. Система по п. 1, характеризующаяся тем, что запрос открывают по ссылке или размещают на внешнем ресурсе.