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

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

 

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

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

[0002] Именно с учетом этих и других общих соображений были описаны примеры. Кроме того, хотя обсуждались относительно конкретные задачи, следует понимать, что примеры не должны ограничиваться решением конкретных задач, рассмотренных в разделе "Уровень техники".

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

[0008] Неограничивающие и неисчерпывающие примеры описываются со ссылкой на следующие чертежи.

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

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

[0011] Фиг. 3 показывает способ автоматического разрешения проблем, которые возникают в системе программного обеспечения, согласно примерам.

[0012] Фиг. 4 показывает способ приема обратной связи для обнаруженной проблемы согласно примерам.

[0013] Фиг. 5 является структурной схемой, показывающей иллюстративные физические компоненты вычислительного устройства, с помощью которого могут быть реализованы на практике аспекты настоящего раскрытия изобретения.

[0014] Фиг. 6А и 6B являются упрощенными структурными схемами мобильного вычислительного устройства, с помощью которого могут быть реализованы на практике аспекты настоящего раскрытия изобретения.

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

[0016] Фиг. 8 показывает планшетное вычислительное устройство для исполнения одного или нескольких аспектов настоящего раскрытия изобретения.

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

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

[0018] Автоматическое тестирование и контроль систем программного обеспечения являются неотъемлемой частью процесса разработки программного обеспечения. Данное раскрытие изобретения описывает систему и способ, которые определяют, является ли обнаруженная проблема либо отказ в системе программного обеспечения ошибкой, или это ложное срабатывание.

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

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

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

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

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

[0024] Как будет объяснено ниже, каждая модель в компоненте оценки может взаимодействовать с компонентом хранения и компонентом генерирования признаков, а также обновляться и обучаться по мере того, как становятся доступны новые данные. Например, после того как модель определила вероятность того, является ли проблема ошибкой, эта информация отправляется разработчику. Хотя в данном документе используется термин "вероятность", модели в компоненте оценки могут выполняться с возможностью ранжирования обнаруженных проблем или предоставления какого–либо другого указания, что было произведено определение того, является ли проблема ошибкой. Например, каждой из проблем может быть присвоен количественный показатель (например, количественный показатель достоверности или какой–то другой количественный показатель). Если количественный показатель выше (или ниже) порогового значения, он может указывать, является ли проблема ошибкой, внесенной разработчиком, или какой–то другой неустойчивой проблемой.

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

[0026] Эти и другие примеры будут более подробно описаны ниже со ссылкой на Фиг. 1–4.

[0027] Фиг. 1 показывает систему 100 для оценки и ранжирования проблем, которые возникают в системе программного обеспечения, согласно примеру. В примерах система программного обеспечения может включать в себя различные модули и компоненты, которые совместно работают над выполнением функции. Эти примеры включают в себя операционные системы, приложения (например, приложения для обработки текста, приложения для работы с электронными таблицами, обозреватели страниц в сети Интернет и тому подобное), облачные вычислительные среды и так далее.

[0028] С течением времени система программного обеспечения или различные компоненты системы программного обеспечения могут обновляться разработчиками. По мере выполнения обновлений различные компоненты системы программного обеспечения могут тестироваться (по отдельности или с другими программными и/или аппаратными компонентами), чтобы определить, будет ли обновление одного компонента негативно влиять на другой компонент системы программного обеспечения и/или систему программного обеспечения в целом.

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

[0030] В примерах лаборатория автоматизации включает в себя одно или несколько контрольных устройств 110. Контрольные устройства 110 обнаруживают, возникла ли проблема во время процесса тестирования. В некоторых случаях разные контрольные устройства 110 контролируют разные части системы программного обеспечения. Например, первое контрольное устройство может охватывать один или несколько компонентов программного обеспечения системы программного обеспечения, в то время как второе контрольное устройство охватывает один или несколько компонентов аппаратного обеспечения, которые соотнесены или иным образом взаимодействуют с системой программного обеспечения. Лаборатория 105 автоматизации может быть выполнена с возможностью непрерывного исполнения различных тестовых вариантов. В других реализациях лаборатория 105 автоматизации может быть выполнена с возможностью запуска тестовых вариантов по требованию.

[0031] Если одно или несколько контрольных устройств 110 в лаборатории автоматизации обнаруживают проблему, первичная информация о проблеме 115 передается компоненту 120 подачи данных. В примерах компонент 120 подачи данных выполняется с возможностью оперирования всеми проблемами 115, которые генерируются или иным образом обнаруживаются в лаборатории 105 автоматизации.

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

[0033] Из этой информации компонент 120 подачи данных может определить контекст, в котором возникла проблема 115. Например, компонент 120 подачи данных может определить номер сборки тестируемого исходного кода, текущие время и дату, какая версия операционной системы была запущена на главном вычислительном узле, и другую подобную информацию.

[0034] Компонент 120 подачи данных также может быть выполнен с возможностью генерирования характерной черты различных проблем 115 посредством статистической группировки функциональных возможностей. После установления характерной черты проблемы 115 она сравнивается с характерными чертами других проблем 115, о которых уже было сообщено компоненту 120 подачи данных. Если определено, что текущая проблема 115 является новой проблемой, информация о проблеме 115 вместе с ее характерной чертой сохраняются. В некоторых случаях статистическая группировка позволяет генерировать различные временные статистические данные (например, количество совпадений за неделю, за месяц и за все время работы) различных проблем 115, которые могут присутствовать в системе программного обеспечения.

[0035] Если определено, что проблема 115 является новой проблемой, компонент 120 подачи данных помещает информацию о проблеме 115 в компонент 125 анализа проблем. Компонент 125 анализа проблем анализирует информацию, определяет вероятность того, является ли проблема 115 ошибкой или ложным срабатыванием, и использует эту информацию для обучения своих моделей оценки.

[0036] В некоторых случаях компонент 125 анализа проблем включает в себя или иным образом соотнесен с уровнем 130 хранения. Уровень 130 хранения принимает информацию о проблеме 115 от компонента 120 подачи данных. В некоторых примерах уровень 130 хранения может быть расширяемым и редактируемым. Уровень 130 хранения также может быть выполнен с возможностью сохранения обратной связи от разработчика по различным обнаруженным проблемам, а также и любой принятой и соотнесенной обратной связи, предоставляемой разработчиком. Уровень 130 хранения также может позволить различным разработчикам и/или компонентам системы 100 исполнять зонные запросы (например, запросы по подмножеству) по сохраненным данным.

[0037] Компонент 125 анализа проблем также включает в себя компонент 140 генерирования признаков. Компонент 140 генерирования признаков включает в себя один или несколько генераторов 145 признаков. Каждый генератор 145 признаков выполняется с возможностью генерирования вектора 150 признаков, который соотносится с конкретной проблемой 115.

[0038] В некоторых случаях может быть много разных классов проблем, которые существуют в системе программного обеспечения. Например, одна или несколько ошибок могут быть связаны с разными компонентами программного обеспечения и/или с одной или несколькими разными группами разработчиков. Помимо этого, различные проблемы 115 могут проявлять разное поведение. Соответственно, каждый генератор 145 признаков в компоненте 140 генерирования признаков может быть выполнен специально для каждого типа проблемы. Таким образом, компонент генерирования признаков может включать в себя много разных генераторов 145 признаков.

[0039] Например, каждый генератор 145 признаков может быть выполнен с возможностью поиска информации, которая касается конкретной проблемы 115. Если информация, касающаяся конкретной проблемы, находится в информации 135 о проблеме, генерируется вектор признаков, соотнесенный с этой конкретной проблемой. Например, конкретный генератор признаков может быть выполнен с возможностью подсчета того, сколько раз слова "сбой" и "память" встречаются в трассировке стека. Таким образом, если генератор признаков принял трассировку стека "Сбой памяти в ячейке 1 памяти", то вектор признаков, сгенерированный генератором признаков, будет "[1,2]", поскольку слово "сбой" встречается один раз, а слово "память" встречается дважды. Однако если трассировка стека пуста или отсутствует, полученным в результате вектором признаков может быть "[0,0]". После того как вектор признаков сгенерирован, эта информация переправляется в компонент оценки.

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

[0041] Например, если генератор 145 признаков выполнен с возможностью поиска конкретного типа проблемы или ассоциирован с конкретным компонентом программного обеспечения или компонентом аппаратного обеспечения, генератор 145 признаков может выполнять преобразование определенного типа на данных. Примерами таких преобразований могут быть нормализация, подсчет вхождений некоторых ключевых слов из трассировки стека, статистическая группировка или извлечение либо генерирование признаков иным образом из первичных данных, доступных в уровне 130 хранения. Генератор 145 признаков использует преобразованную информацию для генерирования вектора 150 признаков.

[0042] После того как вектор 150 признаков был сгенерирован, вектор 150 признаков переправляется в компонент 155 оценки. Компонент 155 оценки включает в себя одну или несколько моделей 160. В некоторых примерах каждая модель 160 однозначно соответствует конкретному генератору 145 признаков.

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

[0044] Хотя и упоминается однозначное соответствие, генератор 145 признаков может предоставлять векторы 150 признаков для множества разных моделей 160. Аналогично, отдельная модель 160 может принимать векторы 150 признаков от различных генераторов 145 признаков.

[0045] В примерах, описанных в данном документе, компонент 155 оценки используется для определения вероятности или иного прогнозирования того, соотносится ли принятый вектор 150 признаков с ошибкой или он соотносится с ложным срабатыванием. Например, модель 160 может быть выполнена с возможностью определения вероятности того, что каждая проблема является ошибкой или неустойчивым шумом, прогнозируя, имеет ли эта проблема отношение к данной команде и так далее. В примерах это дает разработчикам, которые используют систему 100, возможность узнать, какие классы ошибок происходят из их лаборатории 105 автоматизации. Таким образом, разработчик может создавать и/или обновлять свои модели 160 и генераторы 145 признаков на основе собственной потребности.

[0046] В некоторых случаях может возникнуть проблема, по которой модель 160 в компоненте 155 оценки не приспособлена для оперирования прогнозом на основе информации, содержащейся в векторе 150 признаков. В таких случаях система 100 может уведомить разработчика и разрешить создание другой модели 160 и/или генератора 145 признаков.

[0047] Каждая модель 160, развернутая в компоненте 155 оценки, также способна взаимодействовать с уровнем 130 хранения и компонентом 140 генерирования признаков. Таким образом, каждая модель 160 может обновляться и переобучаться по мере предоставления различных обновлений и/или обратной связи и по мере поступления новых данных для обучения.

[0048] В некоторых случаях каждый генератор 145 признаков и каждая модель 160 в компоненте 155 оценки работают независимо друг от друга. Таким образом, каждый генератор 145 признаков и/или каждая модель 160 могут обучаться в любое время. Кроме того, каждая модель 160 может быть моделью своего типа. Например, одна модель может быть средством ранжирования для метода опорных векторов (SVM), которое обучается в пакетном режиме, тогда как другая модель может быть средством ранжирования для метода k ближайших соседей (KNN), обучаемым в режиме реального времени.

[0049] После того как одна или несколько моделей 160 компонента 155 оценки проанализировали вектор 150 признаков, прогноз 165 генерируется и предоставляется клиентскому компоненту 170. Клиентский компонент 170 может включать в себя один или несколько клиентов 175. Каждый из этих одного или нескольких клиентов 175 может взаимодействовать с различными другими компонентами, описанными выше.

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

[0051] Аналогично, второй клиент может быть выполнен с возможностью взаимодействия с уровнем 130 хранения и поиска ошибок или других проблем 115, которые еще ожидают обработки. Второй клиент может отправить запрос соотнесенному с ним генератору 145 признаков на создание вектора 150 признаков и предоставление этого вектора 150 признаков соотнесенной модели 160. Как описано выше, модель 160 определяет вероятность того, является ли обнаруженная проблема 115 ошибкой или она является ложным срабатыванием. Эта информация также может быть отправлена разработчику, как описано выше.

[0052] Когда разработчик получает доступ к системе 100, разработчик может выбрать одну или несколько ошибок для изучения. В ходе изучения разработчик может определить, что обнаруженная проблема 115 является ошибкой, и предоставить исправление для ошибки. Затем эта информация, показанная как обратная связь 180 на Фиг. 1, передается на уровень 130 хранения и сохраняется в нем. Обратная связь 180 также может быть предоставлена различным генераторам 145 признаков в компоненте 140 генерирования признаков и/или моделям 160 в компоненте оценки.

[0053] В некоторых случаях разработчик может определить, что зарегистрированная проблема 115 является ложным срабатыванием. В этих случаях обратная связь 180 о проблеме 115 (например, обратная связь, указывающая, что проблема 115 не была ошибкой, вызванной разработчиком) также предоставляется обратно на уровень 130 хранения.

[0054] В некоторых случаях клиент 175 также может предоставлять обратную связь непосредственно генератору 145 признаков и/или модели 160, с которыми соотнесена проблема. Например, и как описано выше, каждый генератор 145 признаков и/или модель 160 могут соотноситься с конкретной проблемой 115, или иным образом настраиваться для оперирования этой проблемой. Таким образом, когда позднее обнаруживается такая же проблема или аналогичная проблема, генератор 145 признаков и/или модель 160 могут быть лучше обучены тому, как оперировать проблемой 115, а также лучше производить определение того, является ли обнаруженная проблема 115 ошибкой или ложным срабатыванием. В других случаях информация о конкретной проблеме может сохраняться в уровне 130 хранения. Если возникает такая же или аналогичная проблема, информация о проблеме сравнивается с информацией о проблеме в уровне 130 хранения, а затем переправляется в поток генерирования признаков и оценки без сохранения состояния. В некоторых случаях поток генерирования признаков и оценки без сохранения состояния может быть аналогичен потоку операций, описанному в данном документе.

[0055] Ниже приводится пример того, как может использоваться описанная выше система 100. Хотя и описываются специфические особенности, они предназначены только для примеров, и система 100 может использоваться в ряде разных сценариев.

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

[0057] В этом примере команда разработки программного обеспечения использует описанную выше систему 100. Например, когда проблема обнаруживается в лаборатории автоматизации, информация о проблеме передается на уровень хранения (например, уровень 130 хранения). Генератор признаков (например, генератор 145 признаков компонента 140 генерирования признаков) извлекает данные из информации, которая считается эффективной для обнаружения ложных срабатываний. Например, генератор признаков может извлекать информацию, касающуюся общего количества случаев возникновения проблемы (например, совпадений за все время работы), общего количества случаев возникновения каждой проблемы в прошлом месяце (например, совпадений в прошлом месяце), количества случаев возникновения каждой проблемы на прошлой неделе (например, совпадений на прошлой неделе), номера сборки, в которой последний раз возникла проблема, и окончательного разрешения проблемы (например, была ли проблема исправлена, или определение того, что проблема не воспроизводится).

[0058] Хотя и упоминается определенная информация, это делается только с целью иллюстративного примера. Соответственно, генератор признаков может не извлекать столько информации, сколько заявлено, или может извлекать дополнительную информацию.

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

[0060] Компонент генерирования признаков использует эту информацию для генерирования вектора признаков и предоставляет ее модели (например, модели 160) в компоненте оценки (например, компоненте 155 оценки). Как обсуждалось выше, затем модель определяет вероятность того, является ли проблема ошибкой или ложным срабатыванием. В этом примере результат работы модели состоит в том, что каждой новой проблеме (например, проблемам, которые ранее не были идентифицированы, исследованы и/или исправлены разработчиком) назначается вероятность того, чтобы она является ложным срабатыванием. Затем модель представляет эти прогнозы клиенту (например, клиенту 175). Затем клиент может представить новые проблемы команде разработки программного обеспечения. В некоторых случаях проблемы могут быть упорядочены с использованием вероятности, которая была определена моделью.

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

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

[0063] Векторы признаков подаются в модели компонентов оценки, которые выдают вероятность того, что проблема является ложным срабатыванием или ошибкой. Проблемы могут быть упорядочены в зависимости от возможности того, что они являются реальными проблемами (или могут быть упорядочены каким–либо иным образом, таким, например, как наибольший промежуток времени, в течение которого проблема присутствовала, количество случаев возникновения проблемы и так далее).

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

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

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

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

[0068] Несмотря на то, что система была описана в отношении лаборатории автоматизации, описанная выше система 100 может быть интегрирована в любую другую систему. Аналогично, система 100 может вести наблюдение за другой системой извне. В еще одном примере несколько систем (например, интегрированная система и внешняя система) могут использоваться применительно к одной системе программного обеспечения.

[0069] Аналогично, система 100 может быть реализована с возможностью запуска в качестве толстого клиента, запускаемого на отдельном главном вычислительном узле, в качестве системы на стороне сервера (например, предложение в качестве интерфейса в среде обозреватели страниц в сети Интернет) или в любой комбинации из вышеуказанного (например, с сервером базы данных и внешним интерфейсом на более тонком клиенте).

[0070] Фиг. 2 показывает способ 200 для оценки и ранжирования проблем, которые возникают в системе программного обеспечения, согласно примеру. В некоторых примерах способ 200 может использоваться системой 100, такой как описанная выше со ссылкой на Фиг. 1.

[0071] Способ 200 начинается с операции 210, в ходе которой данные, соотнесенные с обнаруженной проблемой, обнаруживаются и предоставляются системе. В этом примере операция 210 также может использоваться для определения того, является ли проблема новой проблемой или же эта проблема обнаруживалась ранее. Информация о проблеме может быть предоставлена системе компонентом подачи данных, таким как описанный выше. Дополнительно, информация о проблеме может сохраняться в компоненте хранения данных.

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

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

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

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

[0076] В ходе операции 250 производится определение относительно того, была ли принята обратная связь для конкретной проблемы. Например, может производиться определение относительно того, выбрал ли разработчик конкретную проблему, проанализировал ли проблему, чтобы подтвердить, является ли проблема ошибкой или ложным срабатыванием, и, если проблема является ошибкой, предоставил ли исправление проблемы. Если обратная связь не была принята, последовательность операций может перейти обратно к операции 210, и операции повторяются.

[0077] Однако, если проблема была выбрана и либо исправлена, либо было определено, что проблема была ложным срабатыванием (например, разработчиком), и была предоставлена обратная связь, последовательность операций переходит к операции 260. В ходе операции 260 обратная связь может использоваться для обучения различных компонентов системы. Например, обратная связь может использоваться для обучения моделей в компоненте оценки и/или различных генераторов признаков в компоненте генерирования признаков. Обратная связь, наряду с информацией о проблеме, также может сохраняться в уровне хранения системы.

[0078] Фиг. 3 показывает способ 300 для автоматического разрешения проблем, которые возникают в системе программного обеспечения, согласно примерам. В некоторых случаях способ 300 может использоваться системой 100, описанной выше со ссылкой на Фиг. 1.

[0079] Способ 300 начинается с операции 310, в ходе которой принимается вероятность (или другой индикатор ранжирования и/или определения количественных показателей) относительно того, является ли обнаруженная проблема ошибкой. В других реализациях вероятность, принимаемая в ходе операции 310, может быть вероятностью того, что проблема является ложным срабатыванием. В любом случае вероятность может приниматься моделью, соотнесенной с компонентом оценки.

[0080] Затем последовательность операций переходит к операции 320, в ходе которой вероятность, которая была принята в ходе операции 310, сравнивается с пороговым значением вероятности. В некоторых случаях пороговое значение вероятности может устанавливаться разработчиком. В других случаях пороговое значение вероятности может автоматически регулироваться системой на основе, по меньшей мере, частично, обратной связи, предоставленной разработчиком. Например, если система определяет, что проблема является ошибкой, и разработчик позже подтверждает это определение, пороговое значение вероятности может быть соответственно изменено (например, повышено или понижено). Если разработчику приходится корректировать определение, пороговое значение вероятности также может быть изменено.

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

[0082] Затем последовательность операций переходит к операции 330, и производится определение относительно того, превышает ли вероятность пороговое значение вероятности. Если вероятность действительно превышает пороговое значение, последовательность операций переходит к операции 340, и о проблеме сообщают разработчику так, как описано выше со ссылкой на Фиг. 2. Затем последовательность операций переходит к операции 370, и любая обратная связь от разработчика предоставляется системе и используется для обучения моделей и/или генераторов признаков, таких как описанные выше.

[0083] Однако, если определяется, что вероятность не превышает пороговое значение (например, определяется, что обнаруженная проблема не является ошибкой), проблема автоматически разрешается системой в ходе операции 350. Затем последовательность операций переходит к операции 360, и проблема помечается или иным образом маркируется, что указывает на то, что разработчик может захотеть пересмотреть разрешение проблемы. Затем последовательность операций переходит к операции 370, и любая принятая обратная связь (например, положительная обратная связь и/или отрицательная обратная связь) от разработчика может быть предоставлена системе и использоваться для обучения различных компонентов системы, таких как описанные выше.

[0084] Фиг. 4 показывает способ 400 для приема обратной связи для обнаруженной проблемы. В некоторых случаях способ 400 может использоваться описанной выше системой 100. Кроме того, способ 400 может использоваться клиентским устройством, которое предоставляет информацию о проблеме разработчику.

[0085] Способ 400 начинается с операции 410, в ходе которой упорядоченный перечень информации о проблемах принимается клиентским устройством. В некоторых случаях упорядоченный перечень информации о проблемах принимается компонентом оценки, таким, например, как компонент 155 оценки. В других случаях перечень информации о проблемах может приниматься из информации о проблемах, хранящейся в устройстве хранения, соотнесенном с системой.

[0086] Перечень может быть упорядочен по любому количеству факторов. Например, перечень может быть упорядочен на основе вероятности того, что проблема является ошибкой, вероятности того, что проблема является ложным срабатыванием, даты обнаружения проблемы, частоты обнаружения и так далее. В других случаях перечень проблем может быть представлен в случайном порядке, в порядке "первым пришел – первым обслужен", в порядке "последним пришел – первым обслужен" и так далее.

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

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

[0089] После приема обратной связи последовательность операций переходит к операции 460, и обратная связь предоставляется системе. В некоторых случаях обратная связь используется для обучения различных компонентов системы. Например, обратная связь может использоваться для обучения или обновления одной или нескольких моделей компонента оценки, создания одной или нескольких моделей компонента оценки, обучения или обновления одного или нескольких генераторов признаков компонента генерирования признаков и/или создания одного или нескольких генераторов признаков компонента генерирования признаков. В некоторых случаях обратная связь также может сохраняться в устройстве хранения системы.

[0090] После того как обратная связь была принята, способ или части способа могут повторяться. Например, как продемонстрировано на Фиг. 4, после приема обратной связи последовательность операций может переходить обратно к операции 430, в ходе которой разработчик выбирает другую проблему в перечне, и процесс повторяется.

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

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

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

[0094] В базовой конфигурации электронное устройство 500 может включать в себя, по меньшей мере, один блок 510 обработки и системную память 515. В зависимости от конфигурации и типа электронного устройства, системная память 515 может содержать, но не ограничиваясь этим, энергозависимое хранилище (например, оперативное запоминающее устройство), энергонезависимое хранилище (например, постоянное запоминающее устройство), флэш–память или любую комбинацию таких запоминающих устройств. Системная память 515 может включать в себя операционную систему 525 и один или несколько программных модулей 520, подходящих для идентификации различных проблем, как описано в данном документе.

[0095] Операционная система 525, например, может быть подходящей для управления работой электронного устройства 500. Кроме того, примеры настоящего раскрытия изобретения могут быть реализованы на практике в сочетании с графической библиотекой, другими операционными системами, или любой другой прикладной программой, и не ограничиваются каким–то конкретным приложением или системой. Эта базовая конфигурация показана на Фиг. 5 теми компонентами, которые находятся в пределах пунктирной линии 530.

[0096] Электронное устройство 500 может иметь дополнительные признаки или функциональные возможности. Например, электронное устройство 500 также может включать в себя дополнительные устройства хранения данных (съемные и/или несъемные), такие, например, как магнитные диски, оптические диски или лента. Такое дополнительное хранилище показано на Фиг. 5 посредством съемного устройства 535 хранения и несъемного устройства 540 хранения.

[0097] Как указано выше, целый ряд программных модулей и файлов данных могут храниться в системной памяти 515. При исполнении в блоке 510 обработки программные модули 520 (например, модуль 505 или компонент генерирования признаков, модуль 507 или компонент оценки и т.д., которые могут содержать систему 100) могут выполнять процессы, включающие в себя, но не ограничиваясь этим, аспекты, которые описаны в данном документе.

[0098] Кроме того, примеры настоящего раскрытия изобретения могут быть реализованы на практике в электрической схеме, содержащей дискретные электронные элементы, в интегральных микросхемах или микросхемах в корпусе, содержащих в себе логические вентили, в схеме с использованием микропроцессора, или на однокристальной микросхеме, содержащей в себе электронные элементы или микропроцессоры. Например, примеры настоящего раскрытия изобретения могут быть реализованы на практике при помощи системы на микросхеме (SOC), где каждый или многие компоненты, показанные на Фиг. 5, могут быть интегрированы в единую интегральную схему. Такое SOC–устройство может включать в себя один или несколько блоков обработки, графических блоков, блоков связи, блоков виртуализации систем и различные функциональные возможности приложений, которые все интегрированы (или "выжжены") на подложке микросхемы в виде единой интегральной схемы.

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

[00100] Электронное устройство 500 также может иметь одно или несколько устройств 545 ввода, таких как клавиатура, сенсорная панель, манипулятор "мышь", перо, устройство звукового или голосового ввода, устройство ввода с помощью касания, нажатия и/или жеста и т.д. Устройство(а) 550 вывода, такое как устройство отображения, динамики, печатающее устройство и т.д., тоже может входить в состав. Вышеупомянутые устройства являются примерами, а могут использоваться и другие. Электронное устройство 500 может включать в себя одно или несколько соединений 555 связи, позволяющих осуществлять связь с другими электронными устройствами 560. Примеры подходящих соединений 555 связи включают в себя, но не ограничиваются этим, радиочастотную (РЧ) передающую, принимающую и/или приемопередающую схему; универсальную последовательную шину (USB), параллельные и/или последовательные порты.

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

[00102] Системная память 515, съемное устройство 535 хранения и несъемное устройство 540 хранения являются примерами компьютерных сред хранения (например, хранилище памяти). Компьютерные среды хранения могут включать в себя ОЗУ, ПЗУ, электрически стираемое программируемое постоянное запоминающее устройство (ЭСППЗУ), флэш–память или другую технологию памяти, CD–ROM, цифровые универсальные диски (DVD) или другое оптическое хранилище, магнитные кассеты, магнитную ленту, хранилище на магнитных дисках или другие магнитные устройства хранения, или любое другое изделие, которое может использоваться для хранения информации, и к которому может получить доступ электронное устройство 500. Любые такие компьютерные среды хранения могут быть частью электронного устройства 500. Компьютерные среды хранения не включают в себя несущую волну или другой распространяемый или модулированный сигнал данных.

[00103] Среды связи могут быть воплощены посредством машиночитаемых инструкций, структур данных, программных модулей или других данных в модулированном сигнале данных, таком как несущая волна или другой транспортный механизм, и включают в себя любые среды доставки информации. Термин "модулированный сигнал данных" может описывать сигнал, который имеет одну или несколько характеристик, установленных или измененных таким образом, чтобы кодировать информацию в сигнале. В качестве примера, а не ограничения, среды связи могут включать в себя проводные среды, такие как проводная сеть или прямое проводное соединение, и беспроводные среды, такие как акустические, радиочастотные (РЧ), инфракрасные и другие беспроводные среды.

[00104] Фиг. 6А и 6B показывают мобильное электронное устройство 600, например, мобильный телефон, смартфон, носимый компьютер (такой как умные часы), планшетный компьютер, дорожный компьютер и тому подобное, с помощью которого могут быть реализованы на практике примеры настоящего раскрытия изобретения. Что касается Фиг. 6A, показан один аспект мобильного электронного устройства 600 для реализации аспектов.

[00105] В базовой конфигурации мобильное электронное устройство 600 представляет собой переносной компьютер, имеющий как элементы ввода, так и элементы вывода. Мобильное электронное устройство 600 обычно включает в себя устройство 605 отображения и одну или несколько кнопок 610 ввода, которые позволяют пользователю вводить информацию в мобильное электронное устройство 600. Устройство 605 отображения из состава мобильного электронного устройства 600 тоже может функционировать в качестве устройства ввода (например, устройство отображения, которое воспринимает ввод посредством касания и/или нажатия).

[00106] Если входит в состав, дополнительный элемент 615 побочного ввода обеспечивает возможность добавочного пользовательского ввода. Элемент 615 побочного ввода может представлять собой поворотный переключатель, кнопку или элемент ручного ввода любого другого типа. В альтернативных аспектах мобильное электронное устройство 600 может вмещать в себя больше или меньше элементов ввода. Например, устройство 605 отображения может не быть сенсорным экраном в некоторых примерах. В еще одном альтернативном варианте осуществления мобильное электронное устройство 600 представляет собой портативную телефонную систему, такую как сотовый телефон. Мобильное электронное устройство 600 также может включать в себя дополнительную клавиатуру 635. Дополнительная клавиатура 635 может быть физической клавиатурой или "программной" клавиатурой, генерируемой на устройстве отображения с сенсорным экраном.

[00107] В различных примерах элементы вывода включают в себя устройство 605 отображения для демонстрации графического интерфейса пользователя (ГИП), визуальный индикатор 620 (например, светоизлучающий диод) и/или звуковой преобразователь 625 (например, динамик). В некоторых аспектах мобильное электронное устройство 600 вмещает в себя датчик вибрации для предоставления пользователю тактильной обратной связи. В еще одном аспекте мобильное электронное устройство 600 вмещает в себя порты ввода и/или вывода, такие как звуковой вход (например, разъем для микрофона), звуковой выход (например, разъем для наушников), и видеовыход (например, порт HDMI) для отправки сигналов на внешнее устройство или приема сигналов от него.

[00108] Фиг. 6B является структурной схемой, показывающей архитектуру одного аспекта мобильного электронного устройства 600. А именно, мобильное электронное устройство 600 может вмещать в себя систему (например, архитектуру) 640 для реализации некоторых аспектов. В одном варианте осуществления система 640 реализуется в виде " смартфона", способного запускать одно или несколько приложений (например, обозреватель, электронная почта, календарное планирование, диспетчеры контактов, клиенты обмена сообщениями, игры, мультимедийные клиенты/проигрыватели, приложения выбора и совместного использования содержимого и так далее). В некоторых аспектах система 640 интегрирована в виде электронного устройства, такого как интегрированный карманный персональный компьютер (КПК) и беспроводной телефон.

[00109] Одна или несколько прикладных программ 650 могут быть загружены в память 645 и запущены в операционной системе 655, или совместно с ней. Примеры прикладных программ включают в себя программы набора телефонного номера, программы электронной почты, программы управления личной информацией (PIM), программы для обработки текста, программы для работы с электронными таблицами, программы обозревателей страниц в сети Интернет, программы для обмена сообщениями и так далее.

[00110] Система 640 также включает в себя энергонезависимую область 660 хранения в памяти 645. Энергонезависимая область 660 хранения может использоваться для хранения постоянной информации, которая не должна быть потеряна при выключении системы 640.

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

[00112] Система 640 имеет блок 665 питания, который может быть реализован в виде одной или нескольких батарей. Блок 665 питания может дополнительно включать в себя внешний источник питания, такой как адаптер переменного тока или снабжаемая питанием док–станция, который дополняет или подзаряжает батареи.

[00113] Система 640 также может включать в себя уровень 670 радиоинтерфейса, который выполняет функцию передачи и приема радиочастотной связи. Уровень 670 радиоинтерфейса обеспечивает возможность беспроводного соединения между системой 640 и "внешним миром" через оператора связи или поставщика услуг. Передачи на уровень 670 радиоинтерфейса и от него проводятся под управлением операционной системы 655. Другими словами, элементы обмена данными, принимаемые уровнем 670 радиоинтерфейса, могут распространяться в прикладные программы 650 через операционную систему 655, и наоборот.

[00114] Визуальный индикатор 620 может использоваться для предоставления визуальных уведомлений, и/или звуковой интерфейс 675 может использоваться для производства слышимых уведомлений через звуковой преобразователь (например, звуковой преобразователь 625, показанный на Фиг. 6A). В показанном варианте осуществления визуальный индикатор 620 представляет собой светоизлучающий диод (СИД), а звуковой преобразователь 625 может представлять собой динамик. Эти устройства могут подключаться непосредственно к блоку 665 питания, так что при активации они остаются включенными в течение срока, обусловленного механизмом уведомлений, даже при том, что обрабатывающее устройство 685 и другие компоненты могут отключаться для сохранения заряда батареи. СИД может быть запрограммирован так, чтобы оставаться включенным неопределенное время, пока пользователь не предпримет действие, чтобы указать статус "включен" для устройства.

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

[00116] Система 640 может дополнительно включать в себя видеоинтерфейс 680, который позволяет работать с периферийным устройством 630 (например, встроенной камерой) для записи неподвижных изображений, видеопотока и тому подобного.

[00117] Мобильное электронное устройство 600, реализующее систему 640, может иметь дополнительные признаки или функциональные возможности. Например, мобильное электронное устройство 600 может также включать в себя дополнительные устройства хранения данных (съемные и/или несъемные), такие как магнитные диски, оптические диски или лента. Такое дополнительное хранилище показано на Фиг. 6B посредством энергонезависимой области 660 хранения.

[00118] Данные/информация, генерируемые или захваченные мобильным электронным устройством 600 и сохраненные через посредство системы 640, могут храниться локально на мобильном электронном устройстве 600, как описано выше, или эти данные могут храниться в любом количестве сред хранения, к которым может получить доступ устройство через уровень 670 радиоинтерфейса или через проводное соединение между мобильным электронным устройством 600 и отдельным электронным устройством, соотнесенным с мобильным электронным устройством 600, например, серверным компьютером в распределенной вычислительной сети, такой как сеть Интернет. Как следует понимать, такие данные/информация могут быть доступны через мобильное электронное устройство 600 через посредство уровня 670 радиоинтерфейса, либо через распределенную вычислительную сеть. Аналогично, такие данные/информация легко могут передаваться между электронными устройствами для хранения и использования в соответствии с хорошо известными средствами передачи и хранения данных/информации, включающих в себя электронную почту и системы совместного использования коллективных данных/информации.

[00119] Как следует понимать, Фиг. 6A и Фиг. 6B описаны, чтобы проиллюстрировать настоящие способы и системы, и не предназначены для ограничения настоящего раскрытия изобретения конкретной последовательностью этапов или конкретной комбинацией компонентов аппаратного или программного обеспечения.

[00120] Фиг. 7 показывает один аспект архитектуры системы 700 для автоматической регистрации обнаруженных проблем системами программного обеспечения, такими как описанные в данном документе. Система 700 может включать в себя универсальное электронное устройство 710 (например, персональный компьютер), планшетное электронное устройство 715 или мобильное электронное устройство 720, как описано выше. Каждое из этих устройств может предусматривать использование для приема зарегистрированных проблем и/или предоставление обратной связи 725, такой как описано.

[00121] В некоторых аспектах каждое универсальное электронное устройство 710 (например, персональный компьютер), планшетное электронное устройство 715 или мобильное электронное устройство 720 может принимать различные другие типы информации или содержимого, которые хранятся службой 745 каталогов, сетевым порталом 750, службами 755 почтовых ящиков, средствами 760 хранения мгновенных сообщений или службами 765 социальных сетей, или передаются от них.

[00122] В аспектах, проблемы и/или обратная связь 725 могут быть предоставлены, через сеть 730, системе 735 идентификации проблем (или компонентам системы идентификации проблем) на сервере 705 (хотя система 735 идентификации проблем также может быть и локальной системой).

[00123] В качестве примера, описанные выше аспекты могут быть воплощены в универсальном электронном устройстве 710 (например, персональном компьютере), планшетном электронном устройстве 715 и/или мобильном электронном устройстве 720 (например, интеллектуальном телефоне). Любой из этих примеров электронных устройств может получать содержимое из средства 740 хранения или предоставлять туда данные.

[00124] Как следует понимать, Фиг. 7 описана, чтобы проиллюстрировать настоящие способы и системы, и не предназначена для ограничения настоящего раскрытия изобретения конкретной последовательностью этапов или конкретной комбинацией компонентов аппаратного или программного обеспечения.

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

[00126] Как следует понимать, приведенные на Фиг. 8 чертежи описаны, чтобы проиллюстрировать настоящие способы и системы, и не предназначены для ограничения настоящего раскрытия изобретения конкретной последовательностью этапов или конкретной комбинацией компонентов аппаратного или программного обеспечения.

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

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

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

[00130] Описание и иллюстрация одного или нескольких аспектов, предоставленных в этой заявке, не предназначаются для ограничения или сокращения каким–либо образом объема настоящего раскрытия изобретения, который заявлен. Аспекты, примеры и детали, предоставленные в этой заявке, считаются достаточными для передачи владения и дают другим лицам возможность производить и использовать наилучший вариант заявленного раскрытия изобретения. Заявленное раскрытие изобретения не должно истолковываться как ограниченное каким–либо аспектом, примером или деталью, предоставленным в данной заявке. Независимо от того, продемонстрированы ли они и описаны в комбинации или по отдельности, различные признаки (как структурные, так и методологические) предназначены для выборочного включения в состав или исключения, чтобы представить вариант осуществления с конкретным набором признаков. Будучи обеспечен описанием и иллюстрацией настоящей заявки, специалист в данной области техники может представить себе вариации, модификации и альтернативные аспекты, соответствующие сущности более широких аспектов общей идеи изобретения, воплощенной в данной заявке, которые не выходят за пределы более широкого объема заявленного изобретения.

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

принимают информацию об обнаруженной проблеме;

сохраняют информацию об обнаруженной проблеме в устройстве хранения данных;

генерируют вектор признаков для обнаруженной проблемы;

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

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

принимают ввод, соответствующий обнаруженной проблеме, каковой ввод указывает, является ли обнаруженная проблема ошибкой;

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

предоставляют обновленную информацию в систему, которая идентифицирует обнаруженную проблему для автоматического обучения этой системы.

2. Способ по п.1, в котором упомянутый ввод содержит решение обнаруженной проблемы.

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

4. Способ по п.2, дополнительно содержащий этапы, на которых:

связывают упомянутое решение с обнаруженной проблемой; и

сохраняют данное решение в устройстве хранения данных.

5. Способ по п.1, дополнительно содержащий этап, на котором определяют приоритетность обнаруженной проблемы относительно одной или более дополнительных обнаруженных проблем.

6. Способ по п.1, в котором упомянутое генерирование вектора признаков содержит этап, на котором выполняют одно или более преобразований в отношении информации об обнаруженной проблеме.

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

8. Вычислительная система, сконфигурированная для автоматического определения того, является ли обнаруженная проблема в вычислительной системе ошибкой, при этом вычислительная система содержит:

по меньшей мере один блок обработки данных; и

память, хранящую машиноисполняемые инструкции, которые при их исполнении по меньшей мере одним блоком обработки данных предписывают вычислительной системе:

принимать информацию об обнаруженной проблеме;

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

когда определено, что обнаруженная проблема является новой:

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

генерировать вектор признаков для обнаруженной проблемы;

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

предоставлять упорядоченный перечень обнаруженных проблем в клиентское устройство;

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

использовать этот ввод для обновления информации об обнаруженной проблеме.

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

10. Система по п.8, дополнительно содержащая инструкции для приема решения обнаруженной проблемы.

11. Система по п.10, дополнительно содержащая инструкции для связывания упомянутого решения с обнаруженной проблемой.

12. Система по п.10, дополнительно содержащая инструкции для обновления одной или более моделей на основе, по меньшей мере отчасти, упомянутого решения.

13. Система по п.8, при этом порядок в упорядоченном перечне основывается на упомянутой определенной вероятности.

14. Система по п.8, дополнительно содержащая инструкции для назначения приоритета обнаруженной проблеме с учетом ранее обнаруженных проблем.

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

16. Машиночитаемый носитель информации, хранящий машиноисполняемые инструкции, которые при их исполнении блоком обработки данных предписывают блоку обработки данных выполнять способ, содержащий:

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

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

сообщение о возникновении обнаруженной проблемы;

прием ввода, который указывает, является ли обнаруженная проблема ошибкой или ложным срабатыванием;

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

обновление по меньшей мере одной из упомянутых одной или более моделей с использованием упомянутого решения обнаруженной проблемы.

17. Машиночитаемый носитель информации по п.16, дополнительно содержащий инструкции для сохранения упомянутого решения в устройстве хранения данных.

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

19. Машиночитаемый носитель информации по п.16, дополнительно содержащий инструкции для сохранения информации об обнаруженной проблеме.

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