Сообщений в теме: 5

[Status]

Доброго времени суток.

Делаю парсер html страниц.

Данные будут переноситься с сайта в базу данных. Видов страниц - 5. Всего необходимо будет обработать от 20000 до 100000 страниц, точное количество будет определяться в процессе работы.

Из-за большого объема данных, парсинг будет проходить в 2 этапа: сначала страницы сохранятся на жесткий диск, потом уже осуществляется их парсинг. Данные из html извлекаются при помощи xpath запросов.

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

Хотелось бы 100%-ной надежности переноса данных с сайта в базу без искажений, и протестировать свой парсер на способность обеспечить это.

Пока вижу следующие способы:

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

//td[@class="myclass"]

делать что-то вроде:

//ul[@class="class1"]/li[@class="class2"]/table[@class="class3"]//td[@class="myclass"]

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

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

[Status]

Пока ответов нет - понятно, почему - случай весьма нестандартный. Потому продолжаю искать сам. После пролистывания книг по тестированию и чтения форумов - удалось придумать следующее:

3) Тестирование самих html страниц. Этот способ в чем-то перекликается с вышеприведенном способом (1), фактически являсь его развитием.

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

Например, если на странице должен быть список названий, и находится он по такому адресу xpath:

//body/div[@class='myclass']/ul[@class='myclass2']/li/text()

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

4) Тестирование данных, полученных из парсера, преимущественно - сырых, (в строковом виде) до их записи в базу. Здесь возможны:

а) Проверка форматов, например:
- если полученная строка должна быть дробным числом, - очевидно, эта строка должна состоять из нескольких цифр с точкой где-то между ними;
- если это - имя или фамилия - строка должна состоять из буквенных символов, и быть длиной от трех до тридцати знаков

б) Тестирование логики, например:
- если есть таблица, где в каждой строке приводятся числовые значения, а в самой последней строке - их сумма, то эта сумма, извлеченная парсером должна примерно совпадать с суммой, вычисленной программным способом из значений в остальных строках.

Ну вот пока как-то так. Кажется, что применение способов 1, 3 и 4 даст вполне достаточную гарантию надежной работы. Что касается способа 2 (создание второго парсера и сверка данных, полученных разными парсерами) - уж очень он трудоемок, пока оставлю его в запасе, реализую, если будет время.

[checo]

Смотрите.

Здесь решается 2 задачи.

 

Первая - протестировать парсер на надежность. При этом Вы хотите опираться на тестовые оракулы, которые не содержат четких проверок (только формат данных). А если, к примеру, парсер считывает не все данные? Должны быть образцы страниц с известным содержимым, с моделированием разных граничных случаев, и четкий образец, с которым сравниваются результаты парсинга 1 в 1.

 

Вторая - дополнительная проверка надежности работы в реальных условиях. То есть, если реальная страница не проходит проверки 3 и 4, мы не кладем данные в базу, а громко кричим об ошибке. А дальше, скорее всего, придется фиксить и модифицировать локаторы вручную.

Если парсится одна и та же версия сайта, то необходимость такой правки - косяк разработчика. А если сайт развивается, никто не может дать гарантию 100% надежной работы. Собственно, зачем тестировщики и прибегают к созданию page object'ов. Если структура страницы сильно меняется, можно всегда подправить локаторы, не прибегая к изменению тестов.

[Little_CJIOH]

Добро пожаловать в чудный мир BigData.
Задачи вижу 2:
1) чекать, что количество добытых данных соответсвует количеству обработанных страниц.
2) на каждый кусочек данных извлеченный со страницы смотрят валидаторы, все страницы не прошедшие валидацию вместо БД попадают в отдельный список на изучение и повторную обработку.

Для более качественного дизайна валидаторов рекомендую покопать тему property based testing

[baxatob]

Не понимаю, зачем сохранять страницы на жесткий диск? 

Если вам нужны данные с сайта для переноса в стороннюю БД, то в подавляющем большинстве случаев эта задача решается на уровне запросов/ответов сервера. 

На многих современных сайтах разметка страницы подается отдельно, а данные отдельно (например, в виде json), и гораздо надежнее забирать данные напрмяую с сервера, чем парсить html.

[Little_CJIOH]

Не понимаю, зачем сохранять страницы на жесткий диск? 
Если вам нужны данные с сайта для переноса в стороннюю БД, то в подавляющем большинстве случаев эта задача решается на уровне запросов/ответов сервера. 
На многих современных сайтах разметка страницы подается отдельно, а данные отдельно (например, в виде json), и гораздо надежнее забирать данные напрмяую с сервера, чем парсить html.

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