Pull to refresh
19
-7
Константин Осипов @liderman

Технический руководитель разработки в Ситилинк

Send message
Это не имеет прямого отношения к инструментам семейства Selenium, задача запуска тестов как правило решается силами серверов сборки и непрерывной интеграции (Jenkins, TeamCity, TFS или ещё какого-нибудь). Поэтому вопрос к вашему серверу непрерывной интеграции — может ли он запускать тесты от лица разных пользователей?

С другой стороны, не так важно, под каким пользователем запускаются тесты. Гораздо важнее, от лица какого пользователя запускается браузер. Поэтому — строим Selenium Grid, а в его узлах запускаем сервера Selenium от лица нужных пользователей. Теперь стартуем тесты, и они выполняются в браузерах, которые работают под нужной учёткой.
Поделюсь и я своим опытом.

Во-первых, классов при классификации оказывается гораздо больше, чем 2. С точки зрения тональности, любой документ имеет определённое значение по 2-м шкалам: объективности-субъективности и позитивности-негативности. Одно только это приводит к 4 классам: субъективно-позитивный, субъективно-негативный, субъективно-нейтральный и объективный (информационный). Последние 2 категории могут быть не совсем понятны, поэтому поясню: субъективно-нейтральный документ выражает эмоции, но общая их сумма равна нулю (например, «с одной стороны, мне его жаль, а с другой — чего он ожидал?»); объективные (информативные) документы просто несут некоторую информацию («сегодня президент России встретился с японскими школьницами»). Кроме того, при работе с реальными источниками а-ля Твиттера добавляются ещё как минимум 2 класса: нерелевантные (случайно попали в результаты поиска, не относятся к исследуемой теме) и спам. Например, во время президентских выборов в России больше 95% твитов по запросам «Путин», «Медведев», «Навальный» и т.д. были именно спамом. Если количество таких «левых» записей не удаётся сократить вручную (мы, например, убирали все записи, начинающиеся с хеш-тега — спам практически исчез), то придётся строить дополнительный «входной» классификатор.

Во-вторых, для анализа тональности очень важную роль играет использование в качестве атрибутов тегов частей речи (part of speech, POS). В частности, теггер частей речи определяет время глаголов, что сильно влияет на классификацию. Сравните: «Франсуа Холланд планирует посетить Россию в октябре» (настоящее время, информативный текст) и «Франсуа Холланд планировал-планировал, да не выпланировал. Так всё и загнулось» (прошедшее время, субъективно-негативный текст). В последней инкорнации нашей системы мы использовали 2 последовательный классификатора — сначала проверяли на объективность с помощью классификатора по частям речи, затем подсчитывали собственно тональность с помощью униграм.

В-третьих, опять же, если речь идёт о соц. сетях, то имеет смысл использовать другие, нетекстовые признаки. Например, мы в твитах заменяли все ссылки просто на атрибут [LINK], таким образом он начинал учитываться как отдельный признак (очень помогает в поиске информативных твитов). Очистка user generated content тоже играет существенную роль. Для того же твиттера необходимо убирать имена пользователей (в большинстве случаев они не несут информации, но загрязняют список атрибутов). Исправление опечаток и стандартных «словозаменителей» (fuck -> f*ck, fck, etc.) также играет немаловажную роль.

В-четвёртых, использовние N-грамм зависит от языка. Для английского лучший результат показали биграммы, для французского и русского — триграммы. Это связано с разными моделями построения предложений: в английском много сочетаний вида глагол-предлог (e.g.: give up), во французском часто используются более длинные связки (Est-ce que… ?).

В-пятых, независимо от используемой модели N-грамм отрицательные конструкции необходимо слеплевать с соседними словами. Причём какие именно конструкции и как именно слеплевать — зависит от языка. Для русского обычного хватает склеивать «не» со впереди идущим глаголом («не люблю») и «нет» с впереди и позади идущими существительными («идиотизма нет», «нет идиотизма»). Для английского приходится учитывать модальные глаголы («not going», «don't go», «won't go», etc.) и некоторые обстоятельства, выполняюзие роль отрицания («never go»). Для французского, где отрицание строится частицей «ne» перед глаголом и частицей «pas» (или некоторыми наречиями типа «jamais») приходится придумывать ещё более сложные схемы.

В-шестых, выбор классификатора сильно зависит от источника информации. Так, мы заметили, что для блогов лучше себя ведёт SVM (с практически любым из нелинейных ядер), а для Твиттера — Naive Bayes. Лично я это связываю с близостью используемых моделей к реальным данным. Например, можно сказать, что для Твиттера выполняется основное допущение наивного Байеса — слова в предложениях практически не связаны лексически, а смысл мы понимаем из общего набора слов (пример из сегодняшнего Твиттера: «Hey Redditors: Who's in for an #AMA with an #MSL engineer or 2...or 3...or more? Thur Aug 16 8am PT (1500 UT) @Reddit» — практически нечитаемо с точки зрения граммотной речи).

В принципе, есть ещё много нюансов, но полный обзор занял бы несколько полноценных статей :)
а вкупе с class member access on instantiation и короткими синтаксисом массивов — вообще можно забавные вещи городить)
$x = (new Foo([1,2,3]))->bar()[0]
Короткий синтаксис объявления массива это ладно, мелочь, но вот array dereferencing это круто.

Поясню на всякий случай отдельно для тех кто будет читать камент. В общем теперь если функция возвращает массив массив и точно известен нужный ключ в тем, то можно обойтись без временной переменной. Было:
$temp = foo(); // array
$var = $temp['key'];

, стало:
$var = foo()['key'];

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Chief Technology Officer (CTO)
Lead
From 800,000 ₽
Golang
DevOps
Vue.js
JavaScript
Tarantool
PostgreSQL
Kubernetes
Docker
OOP
gRPC