Comments 18
Извините, но не понятно, для чего в описанной вами задаче нужна нейронная сеть? Приложение пишет логи и по сути сохраняет операцию и ее входящие данные (возможно, даже исходящие). И, как я понял, вы хотите выделять отдельно кейсы для последующего преобразования их в кейсы. Что мешает при логировании сохранять вместе с записью лога еще и сессию пользователя и потом просто разбивать логи по сессиям и паузам между действиями пользователя? Сами кейсы разделяются по "паттерну поведения", т.е. последовательности определенных действий или определенных входящих/исходящих данных, что можно задать заранее или преобразовывать все найденные таким образом кейсы, а потом группировать их по схожести "паттернов". Это достаточно простые шаги для простого перебора логов. Или я как-то неправильно понял цели или задачу? Поясните пожалуйста, потому что тема интересная.
>> Сами кейсы разделяются по «паттерну поведения», т.е. последовательности
>> определенных действий или определенных входящих/исходящих данных
Дело как раз в сопоставлении набора данных и паттерна. Эта классическая задача для программного синтеза — по набору данных найти программу. И с ней в общем сложно справиться:
а) потому что у нас очень много разных видов программ (паттернов), практически бесконечное количество.
б) потому что у нас очень большое количество фич, по которым нужно сопоставлять паттерн и данные.
То есть мы не можем завести таблицу в БД, в которой написать — елси входной параметр единица — то паттерн 1, если 0 — то паттерн 2. Потнециально, это будет таблица с огромным количеством столбцов (фич) и огромным количеством строк (паттернов).
Нейросеть облегчает этот случай программного синтеза именно в смысле поиска по фичам. Мы можем уже не запоминать и разбираться каким фичам соотвествует тот или иной параметр. Для программного синтеза нейросеть лучше ищет по ограниченному объему паттернов и большому объему фичей — тысячи и тысячи).
Проблему практически бесконечного количества вариантов программ(паттернов) это не решает. Я надеюсь на тот вопрос ответил))) Если что, буду рад уточнить.
Спасибо за разъяснение. Но это не совсем то, что я хотел узнать.
Есть несколько моментов:
- Кол-во кейсов все таки ограничено количеством функций системы, которые разрабатываются программистами (а значит, их конечное число).
- Если программа генерирует лог в определенном формате, не проще ли написать преобразователь этого формата в конечные кейсы (или хотя бы в транзакции, которые потом можно будет объединять)?
- Кейсы тестирования все таки должны подразумевать параметризацию — те же входящие данные могут различаться для одного и того же паттерна поведения, а какие-то данные различаться не должны (например, идентификатор открытой вкладки). Как планируете разрешать эти вопросы?
- Непонятно на счет Gerkin скрипта, т.к. для его работы должны быть расписана логика действия (что выполняется и при каких параметрах). Как я понял, генерацию этой части приведенное решение не включает?
Если вы решаете задачу генерации тест кейсов по логам приложения, то мне непонятна роль описанного классификатора на нейросети и не понятно, почему не справится предложенный мной в первом комментарии классификатор (тем более что и данные не с промышленной среды, а с тестовой, и их не много).
Тем более, что, если я правильно понял, вы предлагаете по сути "прокликать" функционал в системе, собрать лог, отправить его в нейросеть для распознавания уже известных паттернов? Или для генерации новых, но не понятно по каким данным?
Честно, я несколько раз перечитал статью. Примеры в статье немного синтетичные, из конкретики только два метода на стороне приложения, в которых обозначено логирование, а так же пример работы нейросети, которая обучается складывать числа. Как это транслировать на реальную системы, я вот никак не пойму.
Количество кейсов конечно в отдельной функции, в отдельном модуле или одной программе. Если мы хотим собрать все возможные кейсы которые в теории можно написать на Java то это конечно не будет бесконечное количество вариантов, но примерно как варианты ходов в шахматах.
> Если программа генерирует лог в определенном формате, не проще ли написать
> преобразователь этого формата в конечные кейсы (или хотя бы в транзакции,
> которые потом можно будет объединять)?
Тут в каком месте вручную не оптимизируй количество кейсов, это будет не очень качественно. Вообще тут ручная оптимизация не очень хорошо работает. Представьте обратную ситуацию — вам на основе спецификации Gherkin нужно сгенерировать программу. МОжно сделать распознователь ключевых слов в спецификации, какие то регулярки. Но руками это наоптимизироват невероятно сложно. Тут обратная задача, но не менее сложная.
Смотрите, чтобы проще было понять зачем нужна тут нейросеть, нужно сформулировать реальную задачу. Синтетический лог который я в статье привел конечно можно раскидать руками.
Но сформулируйте задачу для неизестного количества паттернов. Того, что мы накопили прогнав милион программ. Тогда это задача типа k-means, когда у вас есть векторное пространство паттернов, вам дают на вход кусок лога, и вам нужно найти вектор, который лучше всего подходит для этого куска лога. Здесь лучше никаких преобразователей самому не писать, а воспользоваться уже применяемыми для этой общей задачи методами.
Если можно, давайте на конкретном примере разберем.
Есть сайт Яндекс.Почта (или любая другая почта).
Возмем базовые кейсы:
- авторизация,
- просмотр списка писем,
- открытие любого письма для просмотра,
- открытие формы создания нового письма и отправка письма (это один кейс).
Что мне интересно:
- Как будут выглядеть (примерно) логи для этих действий?
- Какая информация и в каком виде из этих логов будет подаваться на нейронную сеть?
- Что будет отдавать нейронная сеть на выходе?
- Как будет выглядеть процесс создания кейсов тестирования?
When("^ user \"([^\"]*)\" and pin \"([^\"]*)\" in authenticate is valid")
public void user_and_pin_in_authenticate_is_valid(String arg1, String arg2) throws Throwable {
…
}
When("^ user \"([^\"]*)\" and pin \"([^\"]*)\" in authenticate is not valid")
public void user_and_pin_in_authenticate_is_not_valid(String arg1, String arg2) throws Throwable {
…
}
и для такого теста нам не нужна нейросеть, тут можно использовать то что вы называете преобразователем
НО
если мы представим что сама операция авторизации состоит из условных операций:
начать коннекшн к БД (просто логируем тип БД, Gherkin паттерн «Пытаемся приконнектится к БД», тест кейс — прокерка что установился коннект)
авторизоваться в БД
взять пароль из БД для пользователя
сверить пароль с паролем пользователя
если да, то прописать куку
для этих операция мы тоже можем собрать логи и тоже прописать кейсы с спецификацией Gherkin.
И
в другой программе у нас тоже есть коннекшн к БД. Тогда задача нашей нейросети в другой программе распознать по логам что это тоже коннекшн к БД, выдать нам соответствующий паттерн в Gherkin и тест кейс коннекшна. И елси мы натренировали нейросеть правильно, мы не пишем ей правил соотвествия между описанием лога коннекшна к БД в одной программе, и логом коннекшном в другой программе.
Теперь понятнее стало, спасибо. Решается, вероятно, задача генерации unit-тестов, т.е. тестирование непосредственно программных функций приложения, а не генерация комплексных функциональных и/или нагрузочных тестов, где каждый кейс — это реальный пользовательский кейс с определенной последовательностью вызовов функций приложения через доступные только пользователям каналы взаимодействия (например, трафик http) и связью между этими шагами (сохранение сессий, сквозная передача параметров и пр.)
Да сбывается мечта одних, моих, бывших сингапурских коллег индийского происхождения. Которым тесты писать, явно в антикарму шло и которые в попытке обойти минимальное покрытие в CI тупо засылали псевдотесты без assert блоков.
Может покажусь консерватором, но я бы машине не стал доверять это дело. Если вы напортачили с учебной выборкой в задаче классификации изображений, то это будет видно сразу при тестировании модели(террорист с калашом вверх распознаваемый как счастливый и веселый это конечно не в счет). Как вы можете гарантировать качество обучения в данном случае?
Качество работы тут может повышаться также, как и в случае с изображениями — постепенно начинаем с простых случаев и примитивных форм, постепенно набиваем руку и увеличиваем количество паттернов.
Я правильно понял, что в идеальном случаи программа должна логировать:
Значение каждогой переменной каждого объекта (даже временного, типа ретурна функции которая возвращает текущее время в качестве аргумента другой функции) в программе (нужного для теста) и при её инициализации, не только при прямом её измение?
Автоматическая генерация тестовых скриптов с помощью нейронных сетей