вторник, 29 марта 2011 г.

О пагинаторе, практиках тест-дизайна и развитии тестирования.

Всем начинающим тестировщикам посвящается!

Этот пост меня сподвигло написать несколько вещей.
Вещь первая. Наталья Руколь когда-то (кажется, что уже очень-очень давно) предложила развивать тестирование. Во что я с удовольствием ввязалась и ни разу не жалею. Развивать мне предстоит начинающих тестировщиков, поэтому этот пост специально для тех, кто на пути "жесткого обращения с багами"© только-только начинает осторожничать с тестированием программного обеспечения.
Вещь вторая. У Алексея Баранцева недавно закончился тренинг "Практикум по тест-дизайну", в котором одним из заданий было как раз-таки поэкспериментировать с поисковыми системами (по сути - с пагинатором). Когда я еще была самым что ни на есть начинающим тестировщиком и посещала разные тренинги и семинары, мне казалось, что тест-дизайн - это вообще непринципиальная вещь. Ведь зачем она нужна, если еще столько неизученного: тестирование безопасности, нагрузочное тестирование, автоматизация, юзабилити.... Я же и так пишу тест-кейсы, завожу баги... )))) И только после того, как появился некоторый опыт в тестировании, стало понятно, что без тест-дизайна вообще никуда.
Вещь третья. Буквально вчера на своем собственном проекте нашла при тестировании пагинатора довольно интересную ошибку. Интересную потому, что я уже тестировала на больших числах и все было хорошо. Но после мерджа ветки решила проверить еще раз. И случайно (наверное, какая-то тестерская интуиция) наткнулась на единственное число, на котором падает SQL. Но обо всем по порядку.

Предусловие.
Материал запоминается лучше всего тогда, когда все в нем ясно (до самого последнего словечка). Поэтому если что-то непонятно, то лучше это непонятное слово выписать и прояснить его значение (в гугле или комментариях к сообщению).

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

Вот тут и начинается самое интересное.
При выборе какой-нибудь страницы (кроме первой) адресная строка выглядит уже немного по-другому. Например, к ней может быть добавлено нечто вида:
?page=2
Вот с этим "нечтом" мы и будем работать. ))))

Сразу скажу по-секрету, что вводить вместо цифры "2" можно все, что угодно: положительные и отрицательные числа, нули, дробные и слишком большие числа, числа в шестнадцатиричной системе, строки вида "inf" или "infinity" и много еще чего.
Мое "любимое" число - это множество девяток (свыше 11) целым числом или после запятой. Но наша система это выдерживала. Как, впрочем, и ввод отрицательных чисел, и дробных значений.
Я решила модифицировать его и разбавить нулями. Получилось число 990909009090909999. И вот оно-то и принесло то, чего я добивалась: прекрасный эксепшен с ошибкой 500.

Error 500 - внутренняя ошибка сервера. Ошибка 500 означает, что сервер столкнулся с обстоятельствами, которые не дают ему выполнить запрос клиента. Обстоятельства эти могут быть очень разные.
 Самая большая "интересность" этой баги состоит не в том, что использовалось большое число (многие сайты падают при введении больших чисел), а в том, что система упала при введении именно этого числа. Уменьшение или увеличение его на пару девяток систему никак не трогало. А именно с этим числом происходило переполнение и вообще всякая мистика.
На некоторых сайтах введение такого числа приводит к следующему:

MySQL Error!
------------------------

The Error returned was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1.9818180181818E+19,20' at line 1

Error Number:
1064

 Почему это происходит?
Введенное число попадает в MySQL в экспоненциальной форме, что приводит к ошибке синтаксиса (SQL не понимает такие числа).

Зачем нам это нужно?
Издавна в мире добро борется со злом. Так, врачи борятся с вирусами, огородники борятся с сорняками, а создатели программ - с хакерами.
Есть хорошие "взломщики" - это тестировщики. Есть плохие "взломщики" - это хакеры и всякие школьники, которые в поисках драйва тянут везде свои мышки с клавиатурами. И мы - тестировщики - должны успеть предупредить те действия, которые в дальнейшем может сделать какой-нибудь недобросовестный элемент.

Чем это нам грозит?
Приведенный пример можно считать элементарной SQL-инъекцией. По появившейся ошибке сервера опытный хакер поймет что делать дальше и как получить из нашей системы требуемые ему данные. А мы должны ему в этом помешать.


Будь внимателен к SQL, юный падаван!



4 комментария:

  1. Удалось ли выяснить, почему именно такое число приводит к падению? А то рассказ окончен, а кто убийца - непонятно :)

    ОтветитьУдалить
  2. Почему другие сайты падают на больших числах - понятно. И я даже постаралась это немного объяснить.
    Почему именно это число свалило все у нас - до сих пор не выяснили. Зато все пофиксили ))) Как иногда и бывает )))

    ОтветитьУдалить
  3. Жаль, очень интересно почему именно такое, помогло бы при проектировании тестов. А так мораль басни получилась "пробуйте всяко-разно, авось свалится" (в подмножестве больших чисел, проблемы с которыми известны и понятны).

    И наверное это не совсем корректно называть SQL-инъекцией, а то развивающиеся тестировщики, которым отчасти этот пост адресован, могут так и запомнить и впоследствии называть SQL-инъекцией любые данные, которые приводят к ошибке в БД. Я могу ошибаться, но по-моему это не так.

    ОтветитьУдалить
  4. Ну, мораль была примерно: "доверяйте интуиции" )))
    Потому что любое другое большое число лично нашу систему не валило. )) Зато теперь программисты считают меня тестировщиком-колдуном )))
    По-поводу SQL-инъекции: старалась не делать упор именно на этот термин, а больше на то, какую ошибку вызывают такие данные и к чему это может привести. Думаю, это будет полезно хотя бы для того, чтобы привлечь внимание к адресной строке и ошибкам. )) Я вот первые несколько месяцев своей работы вообще на это внимания не обращала ))

    ОтветитьУдалить