Комментарии 37
Спасибо за статью, довольно интересно.
А вообще, такой подход оправдан, если страницы очень разнородны и нет доступа к алгоритмам формирования страниц. У вас же есть код, который генерит страницы — пусть он сразу и модели генерит, а вы уже эти модели накладывайте на страницы. Есть конечно вероятность, что когда сломается генерация страниц, то сломается генерация моделей и тесты ничего не покажут :) Но для этого можно ведь модели брать из продакшена, а страницы из тестинга.
мимо-проходил-диванный-теоретик
Если бы я был роботом, выдавал бы ошибку на всех сайтах где нет слева блока «вверх страницы».
Постоянно, когда тыкаю слева и не попадаю вверх страницы говорю себе: «да как так можно то»?
Постоянно, когда тыкаю слева и не попадаю вверх страницы говорю себе: «да как так можно то»?
На самом деле все зависит от того, где робот обучается :)
Но да, это как раз пример того, что мы теперь умеем делать. Если в обучающей выборке такой блок всегда есть (даже с небольшими изменениями), то факт его наличия выделится как правило, и робот сможет сигнализировать про отсутствие такого блока.
Но да, это как раз пример того, что мы теперь умеем делать. Если в обучающей выборке такой блок всегда есть (даже с небольшими изменениями), то факт его наличия выделится как правило, и робот сможет сигнализировать про отсутствие такого блока.
Еще чуть добавлю, что Вас отсутствие этого блока расстраивает именно в результате работы механизма обучения, аналогичного описанному — Вы видели такой блок на многих сайтах, Вам он показался удобным и для Вас сформировалось правило «наличие такого блока — это хорошо».
А меня наоборот такие блоки раздражают: при чтении часто выделяю текст и снимаю выделение кликом по пустому месту.
Так что это дело вкуса.
Так что это дело вкуса.
В Яндекс.Браузере переход вверх страницы делается по клику на заголовок активной вкладки. :)
923 кб картинка до хабраката? Пожалейте простых смертных.
Не планируется ли оупен-сорс?
Не очень понял, вы формируете правила по имеющемуся коду, и затем проверяете его же этими же правилами? Т.е. ситуация: вы сформировали тесты на версии N. Далее вышла версия N+1, но она, предположим, содержит много ошибок. Можете ли вы применить к ней тесты, созданные на версии N? Думаю, нет, т.к. в версии N+1 наверняка много что поменялось. Можете ли вы сформировать корректные тесты для версии N+1? Нет, т.к. она работает нестабильно.
Т.е. получается, вы можете отловить только те ошибки, которые проявляются только на 3 страницах из 1000. Видимо я не очень понял суть вашего метода. Просьба пояснить этот момент.
В нашей конторе автотестировщики бьются головой о вот такую стену: функционал некоего модуля остается более-менее одним и тем же, однако с выходом новой версии внешний вид меняется довольно значительно, поэтому автотесты приходится переписывать на 100% (Поясню: у нас внешний вид стандартный на всю систему, а функционал пишется независимо от него. В новой версии может поменяться верстка страницы, вид стандартных кнопок и даже логика работы с формами ввода. При этом сам функционал может меняться незначительно.)
Вообще очень крутой у вас подход. Всегда хотел чем-то таким заниматься. Жаль, что я уже давно не старшекурсник.
Т.е. получается, вы можете отловить только те ошибки, которые проявляются только на 3 страницах из 1000. Видимо я не очень понял суть вашего метода. Просьба пояснить этот момент.
В нашей конторе автотестировщики бьются головой о вот такую стену: функционал некоего модуля остается более-менее одним и тем же, однако с выходом новой версии внешний вид меняется довольно значительно, поэтому автотесты приходится переписывать на 100% (Поясню: у нас внешний вид стандартный на всю систему, а функционал пишется независимо от него. В новой версии может поменяться верстка страницы, вид стандартных кнопок и даже логика работы с формами ввода. При этом сам функционал может меняться незначительно.)
Вообще очень крутой у вас подход. Всегда хотел чем-то таким заниматься. Жаль, что я уже давно не старшекурсник.
Конечно, при сильном изменении верстки значительное число тестов начинают выдавать очень много ошибок. Это проблема, она существует для стандартного подхода (когда тесты пишутся вручную) и, увы, сохраняется в ситуации, когда тесты автоматически генерятся, как у нас.
Мы делаем некоторые вещи, чтобы уменьшить этот эффект.
1. Мы перестраиваем модели при каждой итерации (при каждой выкладке на тестовую среду). Тогда мы можем поймать ошибки, которые возникли ровно при этой выкладке. Ведь часто бывает так — уже вроде все проверено, почти готовы выезжать на продакшн — и надо внести «небольшое исправление». Как понять, что оно ничего не сломало? У нас уже готовы тесты в такой ситуации.
2. У нас есть очень много настроек, какие теги, атрибуты и части страницы не учитываются при построении модели. Все это можно настраивать. Если функциональность не изменилась, а изменились только, я не знаю, стили, то их можно просто отключить и модель, основанная на остальных данных, будет хороша.
Но здесь, конечно, начинается уже ручная настройка, это не так просто.
В целом, конечно, идеальная ситуация для применения нашего тула — когда почти ничего не изменилось и надо это проверить.
Мы делаем некоторые вещи, чтобы уменьшить этот эффект.
1. Мы перестраиваем модели при каждой итерации (при каждой выкладке на тестовую среду). Тогда мы можем поймать ошибки, которые возникли ровно при этой выкладке. Ведь часто бывает так — уже вроде все проверено, почти готовы выезжать на продакшн — и надо внести «небольшое исправление». Как понять, что оно ничего не сломало? У нас уже готовы тесты в такой ситуации.
2. У нас есть очень много настроек, какие теги, атрибуты и части страницы не учитываются при построении модели. Все это можно настраивать. Если функциональность не изменилась, а изменились только, я не знаю, стили, то их можно просто отключить и модель, основанная на остальных данных, будет хороша.
Но здесь, конечно, начинается уже ручная настройка, это не так просто.
В целом, конечно, идеальная ситуация для применения нашего тула — когда почти ничего не изменилось и надо это проверить.
Этот подход про регрессионное тестирование, про то чтобы заменить или писать меньше регрессионных автотестов.
Когда много изменений неизбежно придется проверять иначе
Когда много изменений неизбежно придется проверять иначе
В свое время сделал парсер XML-файлов формата DDEX, который адаптировался к изменению схемы.
Проблема была в том, что при изменение версии в XML-ки может поменяться путь до определенного узла. При этом само содержимое узла почти не менялось. А если и менялось то в основном путем добавления новых подузлов.
Идея аналогичная, парсер знает как парсить определенные узлы и пути до этих узлов. Пути задаются в виде xpath правил. Правила, соответственно, хранятся в файле.
Когда парсеру поступает XML-файл для которого нет правил, парсер генерит новые правила на базе старых (анализируя пути и подбирая похожие). Так как правила сохраняются в файл, то всегда их можно подправить, если парсер немного ошибся.
Возможно, если предположить, что узлы — это блоки на странице, то подобное решение позволит автоматизировать процесс перехода тестирующего инструмента на другую версию верстки.
Проблема была в том, что при изменение версии в XML-ки может поменяться путь до определенного узла. При этом само содержимое узла почти не менялось. А если и менялось то в основном путем добавления новых подузлов.
Идея аналогичная, парсер знает как парсить определенные узлы и пути до этих узлов. Пути задаются в виде xpath правил. Правила, соответственно, хранятся в файле.
Когда парсеру поступает XML-файл для которого нет правил, парсер генерит новые правила на базе старых (анализируя пути и подбирая похожие). Так как правила сохраняются в файл, то всегда их можно подправить, если парсер немного ошибся.
Возможно, если предположить, что узлы — это блоки на странице, то подобное решение позволит автоматизировать процесс перехода тестирующего инструмента на другую версию верстки.
Компания Яндекс то еще гнилье, сами ратуют за то что не нарушают законы однако сами же и рекламируют то что запрещено законом) c2n.me/i5sx1p.png ну о чем можно дальше разговаривать )
Хреного вы тестируете, мне вот интересно вас забанят наконец то или нет?
Хреного вы тестируете, мне вот интересно вас забанят наконец то или нет?
Работа проделана проста огромная, читать было действительно интересно. Сори, может просто не увидела — какой процент ложных срабатываний теперь, с внедрением этой системы?
Мне трудно назвать число, все очень зависит от того, насколько правильно настроено все. То есть если модель построена по достаточно полной выборке, то ложных срабатываний нет, или почти нет. Однако, никогда заранее не ясно, что выборка полная. Например, когда мы только начали экспериментировать и настраивать на разных сервисах, я настраивал МТ на страницах карточек книг на Маркете. Построилась с виду хорошая модель, а потом при сверке она показала расхождение в поле ISBN для карточки одной книги. При внимательном изучении данной страницы выяснилось, что там белорусский ISBN, а во всех примерах для обучения, видимо, были русские коды. Мы добавили такой пример в обучающую выборку и все исправилось.
Так приходится делать часто — иногда трудно заранее понять, точно ли все случаи учтены. И при настройке ложных срабатываний может быть много. Но когда построена хорошая модель — их уже не должно быть.
Так приходится делать часто — иногда трудно заранее понять, точно ли все случаи учтены. И при настройке ложных срабатываний может быть много. Но когда построена хорошая модель — их уже не должно быть.
А цена на Note II в 195300 рублей не является ошибкой?
Интересный вопрос! У меня когда-то (когда я еще сам занимался Маркетом) была мысль, что можно так отлавливать ошибки, находя слишком большие цены. И там был какой-то телефон за 200 с чем-то тысяч. Однако, я пошел на сайт магазина и увидел, что никакой ошибки нет — это какое-то специальное исполнение телефона, под гжель, с инкрустациями и все такое :)
Так что все может быть!
На самом деле на Маркете есть фильтры по цене, чтобы, скажем, чехол для айфона случайно не «приклеился» к карточке айфона, но на 195300, почти уверен, они не сработают, по вышеописанной причине.
Так что все может быть!
На самом деле на Маркете есть фильтры по цене, чтобы, скажем, чехол для айфона случайно не «приклеился» к карточке айфона, но на 195300, почти уверен, они не сработают, по вышеописанной причине.
Можно и так, например
Например, роботу дается для анализа много страниц сервисов Яндекса, и он понимает, что на них на всех снизу есть ссылка «О компании»
…
/html/body/div/table/tbody/tr/td/div/ul/li/span/a вместо
верстка однотипных блоков может быть различной на разных сервисах (
<a>О компании</a>, <b>О компании</b>) — её делали разные люди, в разное время, используя разные фреймворки. или просто один и тот же блок находится в разных состояниях (ссылка на текущую страницу — не ссылка). как вы это учитываете?Тут все зависит от того, на каких страницах обучать робота. Это решает человек. В самом простом случае роботу для обучения дается одна страница. Он открывает ее несколько раз, запоминает, что где, а что меняется при открытии, и сохраняет себе такую модель.
Чуть более сложный случай — несколько схожих страниц. Например, выдача поиска по видео с разными запросами. Там разный контент, но структура страницы более-менее та же.
Наконец, можно пойти дальше и дать на вход уже принципиально разные страницы одного и того же сервиса. Тогда робот извлечет как правило только наличие шапки и футера, я думаю.
То есть создаются правила, которым удовлетворяет нужный процент страниц обучающей выборки. Если там везде ссылка «о компании» была сверстана одним и тем же образом — именно наличие точно такой же ссылки и будет проверяться. Если же в выборку попали разные страницы, то робот уже будет проверять наличие или блока А или блока Б, как-то так.
Чуть более сложный случай — несколько схожих страниц. Например, выдача поиска по видео с разными запросами. Там разный контент, но структура страницы более-менее та же.
Наконец, можно пойти дальше и дать на вход уже принципиально разные страницы одного и того же сервиса. Тогда робот извлечет как правило только наличие шапки и футера, я думаю.
То есть создаются правила, которым удовлетворяет нужный процент страниц обучающей выборки. Если там везде ссылка «о компании» была сверстана одним и тем же образом — именно наличие точно такой же ссылки и будет проверяться. Если же в выборку попали разные страницы, то робот уже будет проверять наличие или блока А или блока Б, как-то так.
Интересная у вас работа. Не так много мест, где можно разрабатывать алгоритмы, а затем видеть результат их работы (а также выгоду, которую принесли алгоритмы для бизнеса).
Спасибо за статью, было интересно читать.
Спасибо за статью, было интересно читать.
Условия формируются в виде регулярных выражений
Правильно ли я понимаю, что регулярки, в отличие от XPath, должен написать человек? Или же есть вспомогательный алгоритм генерации регулярок?
Нет, регулярки тоже генерятся автоматически, есть специальный алгоритм. Если интересно, могу сказать, что он выдаст для каких-нибудь наборов строк.
Было бы неплохо еще одной статьей. Главным образом из-за статистики использования.
Просто с тем же XPath все понятно. Само выражение имеет вполне себе заданную структуру и с ним удобно проводить предсказуемые операции. Я вот на регулярках в итоге завис. Не понятно, в каких случаях его нужно применять для анализа контента блока и построения выражений, а в каких нет. И какие атомарные единицы использовать. Пытался использовать «слова» (алфавит+цифры) и разделитель пробел, но результат получился плохой.
Просто с тем же XPath все понятно. Само выражение имеет вполне себе заданную структуру и с ним удобно проводить предсказуемые операции. Я вот на регулярках в итоге завис. Не понятно, в каких случаях его нужно применять для анализа контента блока и построения выражений, а в каких нет. И какие атомарные единицы использовать. Пытался использовать «слова» (алфавит+цифры) и разделитель пробел, но результат получился плохой.
что ключевое слово здесь — опыт
Опыт полученный через глаза. А к боту «глаза» случайно не пытались делать? Например, через PhantonJS+подлючаемый JS? Можно определить, какую часть страницы занимает блок, в какой части страницы он находится. Потому что визуально одинаковые блоки обычно находятся в примерно в одних и тех же местах, хотя по разметке от корня они могут быть совершенно не похожи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Magic Tester. Как неподготовленный человек замечает ошибки, и как научить тому же робота