Имитаторы браузеров

Постоянно приходится тестировать веб-приложения под разными браузерами.

Для этих целей есть множество инструментов. Я перечислю только те, что я использовала.

1. Browser Sandbox. Позволяет запускать имитаторы различных браузеров и в них проверять работу приложения.
Одно время я пользовалась этим инструментом, но не долго. Мне не понравилась его медлительность.

2. Browsershots. Позволяет быстро проверить как выглядит страница во всех известных браузерах под Windows, Linux, MacOS, BSD. Но не позволяет проверить работу приложения. Он только снимает скриншоты страниц.

3. IETester. Совсем недавно открыла для себя это десктопное приложение. Позволяет запускать в отдельних вкладках имитаторы различных версий браузера Internet Explorer.
Примечание: не совсем корректно работает под WinXP SP3.

Хочу заметить, что не стоит полностью полагаться на эти или любые другие инструменты имитируюшие работу различных браузеров. Поскольку, они в некоторых случаях не ведут себя так, как настоящие браузеры. Это и понятно, имитаторы это ж тоже приложения, и тоже содержат баги. Например, тот же IETester выдает ошибки java script там, где настоящий браузер IE их не выдает.

Лучше всего установить на рабочем компьютере или сервере несколько виртуальных машин с различными операционными системами и браузерами. В таком случае мы тестируем приложения в реальном браузере и можем быть уверены в правильности результатов тестирования.

Mailinator - инструмент для создания мейлов

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

Пользователей понадобилось создавать очень много и скоро мои личные мейлы закончились.
Коллега подсказал инструмент, с помощью которого можно быстро и просто создавать тестовые мейлы.
Инструмент называется Mailinator. Находится в интернете по адресу http://mailinator.com/.
Для создания почтового акунта нужно всего лишь ввести имя (например, mytest1) и нажать "GO".


Все! Адрес mytest1@mailinator.com можно использовать в тестовых целях.

Осторожно, люди!

Вчера ехали к родителям в гости на маршрутке с вот такой надписью на заднем стекле.

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

В какой-то мере, я согласна со смыслом надписи на маршрутке. Людей стоит бояться даже больше, чем злых собак :) Но, думаю, автор хотел донести в ней несколько иной смысл. Тогда правильно было бы написать "Увага! Люди."

Тестировщик – профессия не для слабонервных

Наверное, никто не будет спорить, что работу тестировщика оценивают в большинстве случаев по количеству багов, пролезших в релиз. Причем никого не интересует, сколько этих багов было найдено, отслежено и надцать раз перепроверено, сколько противоречивых требований было проанализировано, сколько сил потрачено на добывание этих требований из кастомеров, сколько времени потрачено на консультирование разработчиков… Видно только одно - в релизе найдено N багов! И каким бы малым не было это число N или какими бы некритичными были эти баги, и даже то, что эти баги найдены в функционале, который был объявлен как «not to be tested» - на вас все равно смотрят с недовольством и грустью в глазах. Даже, если никто не говорит этого в голос.

Вообщем, к важным качествам тестировщика нужно причислить еще умение трезво оценить в чем ты виноват, а в чем нет. Где-то нужно честно и обьективно признаться себе – тут я действительно провтыкал, shame on me и стараться больше такого не допускать (хотя всем людям свойственно ошибаться, но вот тестировщикам этого не разрешается). А где-то нужно так же обьективно осознать - вот тут я ничего не мог поделать, и морально казнить себя за это не стоит.

Это очень-очень важное качество. Иначе развитие страшного комплекса неполноценности и в итоге погружение в депрессивное состояние – это только дело времени.

PS: Вспомнились замечательные слова Уинстона Черчилля

«Success is the ability to go from one failure to another with no loss of enthusiasm»

Хотят ли тестировщики быть программистами?

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

Из разговора я поняла, что в их небольшой команде разработчиков (кажется их там трое) имеется один тестировщик Вася. И что этот Вася (по их словам) непонятно чем занимается, поскольку все разработчики сами ж проверяют свой код :). А также, что Вася (тоже по их словам) давно метит в разработчики.

Как то заинтересовала меня фраза, так уверенно и гордо произнесенная одним из парней - "Ну какой же тестировщик не хочет быть программистом!".

Я конечно не знакома в тестировщиком Васей и не могу сказать хочет или не хочет он быть программистом, также не могу судить о его отношении к тестированию и его тестерских способностях, но могу сказать с уверенностью на 100%, что я вот никогда, с тех пор как начала работать тестировщиком, не мечтала стать программистом. Более того, по образованию инженер-программист я осознанно пошла в тестировщики, поскольку мне эта профессия показалась намного интереснее. И ни разу не жалею о своем выборе.

Также, за вот уже более 4 года работы я ни разу не встречала настоящего тестировщика, который хотел бы быть программистом. Я не зря говорю "настоящего тестировщика", потому что попадаются иногда ненастоящие тестировщики, например:

• те, кто пытается пробраться в программисты через временную работу тестировщиком (типа поработаю, освоюсь в компании, наберусь знаний и опыта и постепенно...)
• те, кто вообще ни кем не хочет быть, а деньги нужны, кушать хочется - почему бы и тестировщиком не "работать".

Стало мне очень интересно, есть ли среди нас такие, что мечтают стать программистами.

Коллеги, если не трудно и не секрет, напишите в комменты. Хотите ли Вы перейти в программисты? Если да, то по каким причинам Вы хотите стать программистом? Если нет и никогда не хотели, тогда напишите что же Вам так нравится в профессии тестировщика? Почему она нравится вам больше чем профессия программиста?

Особенности формирования требований к производительности В2В систем

С точки зрения тестирования производительности все системы разделяются на:

Высоконагруженные. Сотни тысяч пользователей, десятки миллионов хитов в день, десятки гигабайт данных, терабайты трафика. Yandex.ru, например.

Низконагруженные. Например, системы В2В взаимодействия (системы межкорпоративного взаимодействия). Такую систему обычно используют около 100-500 сотрудников компании и 1000 – 5000 клиентов компании и, конечно же, не все одновременно.

Если в высоконагруженных системах производительность стоит на первом месте, то в В2В системах на первом месте - функциональность. Неотъемлемая характеристика В2В систем – сложная бизнес логика. И эта сложная логика должна работать без сбоев и глюков.

Поэтому, при тестировании В2В систем основная часть средств и времени отдается таким видам тестирования как: функциональное, юзабилити и интеграционное тестирование. На тестирование производительности остается очень мало времени.
Но его все равно проводить необходимо.

Только тут важно понять чего мы хотим от нашей системы в плане производительности.
Конечно, всегда хочется иметь самое лучшее, но как говорится «что для русского хорошо, для немца - смерть».

Мы можем потратить кучу времени и средств на обеспечение супер производительности нашей системы. Допустим, она будет чудесно работать под нагрузкой миллион хитов в день. Но в реальности максимальная нагрузка, которой подвергается наша система – 10 тысяч хитов в день. И, по прогнозам экспертов, до миллиона хитов ей еще расти и расти. Что мы сделали? Мы просто выбросили деньги на ветер и потратили силы зря. Не нужна нашей системе такая производительность, и еще много лет будет не нужна. Лучше бы мы разработали какую-то новую функциональность, которая действительно облегчила бы жизнь нашим пользователям.

То есть, мы должны честно ответить на примерно такие вопросы:

• Какое среднее количество пользователей будет одновременно работать с системой (Сколько сотрудников ежедневно пользуются системой?. Сколько клиентов в день заходят в нашу систему?);
• Какое максимальное количество пользователей будет одновременно работать с системой (Скольким людям понадобится достать или загрузить данные в системе в конце квартала, например?);
• Какой запас производительности мы хотим иметь (Что если произойдет что-то непредсказуемое и куча людей ломятся в систему, сколько их может быть? Или, что если мы банально ошиблись в наших расчетах средней нагруженности системы. Насколько мы могли ошибиться?);
• Границы приемлемой производительности системы (Какие показатели производительности мы будем считать хорошими/нормальными/плохими/очень плохими. Время выполнения операции 3 секунды это хороший или плохой показатель для нашей системы, а 10 секунд? Ну, 10 секунд это точно плохо, скажете вы. Ок. А если это операция формирования квартального отчета по результатам деятельности отдела? Вы все еще уверены, что 10 секунд это много для такой операции? Подсказка: тут нет общепринятых стандартов. Для каждой конкретной системы и даже для каждой конкретной операции хорошие и плохие показатели могут отличаться в разы).
  

Иногда слышу нарекания коллег тестировщиков, мол вот я выявил, что система падает при непрерывной работе 20-ти пользователей с таким-то модулем на протяжении 30 минут. Кошмар! Завел баг, сказал менеджерам, а они ничего с этим не делают. Ах они такие!

А менеджеры просто знают, что этим модулем пользуются от силы 1-2 пользователя в день и то не каждый день. То есть такая производительность модуля устраивает всех уже на протяжении нескольких лет. И еще несколько лет будет устраивать. Как только нарисуется тенденция к увеличению интереса пользователей к модулю, вот тогда найденная проблема станет действительно актуальной и ей уделят необходимое внимание.

То есть, перед тем как приступать к тестированию производительности какой либо системы, нужно четко понять что мы хотим (в реальности) от нашей системы. Иначе получится тестирование ради тестирования.

«à la desktop» интерфейс для веб-портала

Интерфейс сайта в виде рабочего стола. Видели? Нет. Тогда смотрите.

Получше рассмотреть, покликать можно здесь http://ibpro.com.ua/admin/ .
По-моему смотрится очень интересно.

Для сайтов контентного направления я бы не делала такой интерфейс. А вот, для корпоративного портала, основной целью которого является решение бизнес задач таких как:

• размещение и скачивание документов
• заполнение и просмотр отчетов
• отслеживание логистических операций
• размежение и подписка на мероприятия
• ...

способ предоставления информации в виде десктопа мне кажется целесообразным.

В основном информация на портале отображается табличной форме или в виде списков. Страницы укомплектованы набором фильтров для поиска данных, ну и стандартными кнопками «добавить», «удалить», «сохранить», «скачать», «просмотреть»…

Вид «à la desktop» для портала видится мне примерно вот так.

Возникают вопросы:

• Насколько удобен для пользователей такой интерфейс?
• Какие преимущества он имеет по сравнению со стандартным стилем отображения в вебе?
• Какие недостатки?
• Не испугает ли он пользователей, все-таки непривычно? :)

Хотелось бы узнать мнения как специалистов в ИТ так и обычных пользователей Интернета.
Скажем, если бы Вы попали на такой портал, какой бы была Ваша реакция?

Брутфорс атака

Брутфорс атаки являются самым легким но эфективным способом взлома. Суть атаки состоит в подборе паролей пользователей.

Эффективность такой атаки напрямую зависит от ленивости администраторов и пользователей.

Для проверки на наличие уязвимости к брутфорс атакам мы не будем перебирать пароли :) Это дело скучное, занимает много времени да и пользы нам от этого не много. Ведь подобрав пароль какого-то юзера, мы всего лишь докажем что это сделать возможно. А никто и не говорил, что это не возможно. Имея достаточное количество времени и ресурсов, можно подобрать всякий пароль.

Задача хорошо продуманной компьютерной системы - не дать пользователям создать пароль, который легко ломается. Например, Петя, 1234, pass.

Поетому, при тестировании нужно обратить внеимание на следующие моменты:

• не рекомендуется длина пароля меньше 8-ми символов;
• пароль должен содержать комбинацию букв, цифр и символов;
• должно быть ограничение на кол-во попыток аутентификации за промежуток времени (например, не более 4-х раз в течении 1 минуты);
  
• пароли должны храниться обязательно в зашифрованном виде;
• пароли не должны передаваться методом GET;
• при работе с важной информацией должна использоваться защищенная передача данных (https протокол).
  

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

Негативное тестирование

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

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

Во многих ресурсах по тестированию, при описании последовательности выполнения видов тестирования, негативное тестирование отделяют в отдельную процедуру и ставят на 4-е место.
При этом приводится следующий план тестирования:

1. Изучение документации (для того, чтобы понять что, собственно тестируем)
2. Дымовое тестирование или Smoke testing (первый прогон программы, чтобы понять работает ли она вообще)
3. Позитивное тестирование (для того, чтобы проверить работу программы при получении ею "правильных" входных данных)
4. Негативное тестирование

Но почему так?! Почему нужно негативное тестирование отделять от позитивного и выполнять потом? Как показывает практика, оставленное на потом почти всегда остается не выполненным.

А можем ли мы сказать что программа работает, если проверили ее реакцию только на правильные входные данные?

А главное, я вот представляю ситуацию. Сижу я тестирую формочку. Проверила все соответственно ТЗ, проверила как обрабатываются данные, которые ожидается, что пользователь будет вводить в поля (заметьте, ожидается совсем не значит, что так и будет) и тут же в моем тестерском уме возникает небезосновательное подозрение, что если ввести вот в это поле "0" - то произойдет что-то нехорошее :) И что? Я должна сказать себе "Нет. По плану у меня сейчас позитивное тестирование. Негативное на следующей неделе, вот тогда и проверю с нулем"?

По-моему, такой подход неправильный. Он не просто неправильный, он неэффективный.

Во-первых, проведение отдельно позитивного и негативного тестирования займет больше времени, чем если их совместить.

Во-вторых, есть риск, что негативное тестирование вообще не будет проведено или проведено кое-как в условиях страшного недостатка времени.

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

Самые важные качества тестировщика. Часть1.

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

Тестировщику важно иметь хорошо развитое не логическое, а, я бы сказала, антилогическое мышление. Тестировщик не должен думать стандартно, как все, типа: если А это Б, а Б это С, то А это С. Он должен смотреть шире и глубже, чем того требует логика. В тестируемых программах логически правильные пути содержат намного меньше ошибок, чем логически неправильные.

Столкнувшись с вышеприведенной задачкой, хороший тестировщик должен подумать примерно так: Если А это Б, а Б это С то
Чем еще может быть А, кроме как В?
Чем еще может быть В, кроме как С?
И вообще, что такое А, В и С?

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

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

Еще тестировщику важно иметь критическое мышление. Я бы сказала, что критическое мышление для тестировщика намного важнее, чем логическое. Перефразировав японскую мудрость, которая гласит «Во всем ищи красивое», получаем мудрость тестерскую – «Во всем ищи недостатки».

Приведу пример на себе. Если я получаю от программиста готовый функционал, тестирую его и не нахожу серьезных дефектов (несерьезных дефектов обычно достаточно и очень важно за этими несерьезными дефектами не забыть найти серьезные), я откладываю тестирование. Не прекращаю тестирование, не закрываю таск, даже если кажется что уже все перепробовала и все пути проверила. Я иду попить кофе, отвлечься… И потом, через некоторое время, возможно на второй день, опять сажусь тестировать этот функционал. И нахожу серьезные дефекты! Потому что всегда, повторюсь – ВСЕГДА в программе есть баги.

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

Итак, важные качества, которыми должен обладать тестировщик это:

• антилогическое мышление – умение мыслить глубже, шире и не так как того требует логика.
• внимательность - умение замечать неточности и противоречия
• критическое мышление – умение во всем находить недостатки
• не помешает и наличие логического мышления

Это далеко не все важные для тестировщика качества. Продолжение читайте в следующих постах.

Тестирование стабильности (stability testing)

Целью тестирования стабильности (stability testing) является оценка работоспособности системы при длительной нагрузке.

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

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

Хотя показатели времени выполнения операций тоже могут пригодиться. Они могут показать степень деградации системы. Если после многочасового тестирования Ваша система не упала, но время выполнения операций постоянно увеличивалось, то это говорит о том, что проблемы все же есть, просто для полного падения системе не хватило времени. Нужно погрузить систему дольше.

Обьемное тестирование (volume testing)

Целью обьемного тестирования (volume testing) является определение производительности системы при увеличении обьемов данных в базе данных.

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

В моей практике есть случай, когда система отчетности отлично работала на обьеме данных за пол года, но значительно хуже работала на уже даже годовых данных и совсем плохо работала на данных за 2 года.

Самые первые претенденты на обьемное тестирование, это те места, где выбираются большие обьемы данных из БД или выполняются сложные sql запросы для выборки данных. Хочу сказать что, если первые места более-менее очевидны (где много данных выводится, там много данных и выбирается из БД), то вторые - не всегда очевидные (вы можете увидеть пару строк, но для того чтобы эти пару строк показать программисту пришлось перерыть пол базы). Имея немного опыта в программировании и базах данных, а таже неотъемлемую для тестера интуицию можно постараться самостоятельно выявить в системе такие узкие места, но все же тут лучше обратиться за помощью к программистам, которые знают систему и все ее проблемные места изнутри.

Тоесть для проведения нагрузочного тестирования нужно:

1. выявить места, где выбираются большие обьемы данных из БД
2. выявить места, где выполняются сложные sql запросы
3. залить в БД много-много данных
4. выполнить тестирование производительности (читай здесь)
5. если нужно - выполнить стрессовое тестирование (читай здесь)

Стрессовое тестирование (stress testing)

Целью стрессового тестирования (stress testing) является оценка работоспособности системы в условиях повышенных и предельных нагрузок.

При проведении стрессового тестирования нас интересует:

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

как долго система может работать на предельной нагрузке. Для этого дают системе предельную нагрузку и смотрят через какое время она свалится (или не свалится).

Примечание: предельная нагрузка - это не нагрузка при которой система сваливается, а нагрузка, при которой система еще остается работоспособной, но если ее немного увеличить - то сваливается.

Тестирование производительности (performance testing)

Целью тестирования производительности (lerformance testing) является определение изменений в работе приложения в зависимости от интенсивности нагрузки.

Например, в первые 20 мин моделируем одновременную работу 10 пользователей (10 пользователей выполняют операции с интервалом в 5 сек). Потом следующие 20 мин увеличиваем кол-во пользователей до 20, следующие 20 мин - увеличиваем до 50 и.т.д пока приложение не свалится или пока не начнет работать так медленно, что работой это не назовешь.

Примечание: кол-во пользователей и интервал зависит от тестируемой системы. Некоторым системам для нормальной работы достаточно поддерживать одновременную работу 10-ти пользователей, а некоторым - 10 тысяч пользователей.

Можно также изменять интервал выполнения операций.
Чем больше пользователей - тем больше нагрузка на систему.
С интервалом все наоборот, чем меньше интервал выполнения операций - тем больше нагрузка на систему.

При тестировании производительности нас интересует:

• изменение времени выполнения операций в зависимости от интенсивности операций (где интенвисность операций = кол-во пользователей * кол-во операций на единицу времени)
• определение границы приемлемой производительности (где приемлемая производительность - это либо четко прописанное в ТЗ среднее время отклика системы, либо такая скорость работы,когда уже с приложением нормально работать невозможно) Кстати, для разных операций приемлемая производительность может быть разной. Например, если пользователю приложения нужно выполнять операцию 10 раз в час - то выполняться она должна быстро и не раздражать пользователя вечным ожиданием. Если пользователю нужно выполнить операцию раз в неделю или даже раз в день (например, сформировать сложный отчет), то такая операция может выполняться и дольше. Пользователь в это время может заниматься другими делами или просто пойти выпить кофе.
• определение количества пользователей, которые могут одновременно работать с приложением

Введение в нагрузочное тестирование (load testing)

Нагрузочное тестирование (load testing) - это автоматизированное тестирование, которое имитирует одновременную работу множества пользователей над тестируемым приложением.

Количество пользователей и частота их действий зависит от цели, которую ставят перед тестированием и уже исходя из целей, нагрузочное тестирование разделяют на несколько видов:

• тестирование производительности (performance testing)
• стрессовое тестирование (stress testing)
• обьемное тестирование (volume testing)
• тестирование стабильности (stability testing)

Есть множество инстументов для проведения нагрузочного тестирования, с помощью которых можно смоделировать необходимую модель нагрузки на приложение, провести тестирование и получить результаты. Каждый выбирает инструменты под себя, и если погуглить, то можно найти, то что нужно именно Вам и именно для Ваших целей. Для себя я выбрала WAPT на примере которого и буду рассказывать о моделировании разных видов нагрузки для разных целей тестирования.

В следующих постах я расскажу отдельно о каждом виде нагрузочного тестирования.

Указатель направления сортировки

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

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

А стрелка вверх или треугольник углом вверх должен показывать направление прямой сортировки.

Другие, утверждают, что все наоборот. Тоесть, стрелка (треугольник) вниз должен показывать прямую сортировку, в вверх – обратную.

Исследовав несколько примеров ПО, мы увидели что встречаются оба случая указания сортировки. Например, в почтовике Microsoft Outlook треугольник углом вниз указывает на обратное направление сортировки, а углом вверх – на прямое. А вот в почтовике The Bat! Все с точностью, до наоборот.

Получается, что в нашем споре победителя не оказалось. Интересно, правда, было бы узнать побольше мнений. Сколько людей считают правильным первый случай (треугольник носом вниз – это обратное направление сортировки)? Сколько людей считают правильным второй случай (треугольник носом вниз – это прямое направление сортировки)?

Ответы пишите в комменты.

Внимательность - важное качество тестировщика

Безусловно, внимательность - одно из самых важных качеств тестировщика.
Проверьте обладаете ли Вы этим качеством - решите задачи, приведенные в этом разделе.

* * *

Перед Вами поставлена задача - вставить в стену окно.
Какие вопросы вы зададите перед тем, как приступить к выполнению этой задачи?

* * *

Внимательно прочитайте условие, но только один раз, и попробуйте сразу же ответить на вопрос.

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

Security testing. Php-including.

Php-including это, казалось бы, самая изветсная "дыра" в безопасности сайта, но в то же время и самая распространенная. Возникает она, когда данные, переданные сценарию в виде параметров, используются без дополнительной проверки.

Стратегия обнаружения уязвимости следующая.

Например, на тестируемом сайте мы видим url - http://www.testsite.ru/index.php?file=file.php
Изменяем немного этот url, вот так - http://www.testsite.ru/index.php?file=[test] и выполняем.

Если уязвимость имеет место, то увидим что-то вроде этого:

«Warning: main([test].php): failed to open stream: No such file or directory in /home/user/www/file.php on line 3»

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

Пишем запрос вида http://www.testsite.ru/index.php?file=/etc/passwd. Если нам повезло, то мы получим содержимое файда passwd на сервере.

Это основные и самые простые примеры как можно протестировать на php-including уязвимость. Далее включаем фантазию и google!

Нестандартное мышление - без него не обойтись

Тестировщик должен видеть то, чего не видят другие, тоесть - смотреть на вещи нестандартно. Следующие задачки проверяют наличие нестандартного мышления.

* * *

Имеется одна в минуте и две в моменте, но только одна в миллион лет. Что это?

* * *

В каком случае 6 детей, 2 собаки, 4 взрослых, забравшись под один обычный зонтик, не намокнут?

* * *

Есть 15 копеек из двух монет, причём одна из монет - не пятачок. Какие это монеты?

* * *

Что общего между ежиком и молоком ?
(Задачку реально загадывали детям для поступления в первый клас в лицей. Бедные дети...)

Логическое мышление - полезно для всех

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

* * *

Есть 12 шариков. Один шарик отличается весом от остальных. Как за три взвешивания определить какой шарик отличается, если не известно тяжелее он или легче.

* * *

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

За одно взвешивание нужно определить, в каком мешке фальшивые монеты. На весы можно класть сколько угодно монет.

* * *

Марина сказала, что ей позавчера было 13 лет, а в будущем году она отметит 16 лет. Верно ли утверждение Марины?

Security testing. XSS атака.

В этой статье пойдет речь о том как найти на тестируемом сайте уязвимое место для XSS атаки. Вначале немного об этой атаке.

XSS атака - это атака на сайт, использующая уязвимость, когда некорректно работают фильтры входящей информации. Информация не проверяется должным образом или вообще не проверяется :) перед тем как вернуть результат пользователю. Это дает возможность атаки на пользователя.

Как проверить, есть ли на сайте подобные уязвимости?

1. Ищем на сайте места, где данные отправляются на сервер.Например, стандартная форма регистрации .
2. По очереди вставляем в поля следующий код

1. Сабмитим форму.

Если поле не фильтруется, то скрипт успешно отправится и выполнится. В результате вы увидите следующее окошко


Все! Уязвимость найдена :).Репортуем баг программистам.

Кстати, в пост пришлось скрипт вставлять как картинку, иначе он выпонялся :)
Вот тебе и XSS атака.

Что ж тут такого страшного, спросите Вы. Ну подумаешь, вывели сообщение.
Ну, вообще то, делать страшные вещи и реально ломать сайт – это не наша работа. Для этого есть хакеры :) Наша работа найти уязвимость и мы ее нашли.

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

Итак.
Первое. Для успешной атаки, пользователь должен быть залогинен (чтобы в его куках сохранилась информация о его авторизации в системе).
Второе. Хакер, должен подготовить XSS код, который будет указывать на уязвимую страницу.

Третье. Хакер должен заманить на данную страницу пользователя. Для этого он должен каким-то образом дать жертве ссылки на данную страницу (тоесть подготовленный URL) и заставить пользователя зайти на эту страницу.
Не буду вдаватся в подробности как он это сделает. В инете существует множество способов.

После того как жертва пойдет по ссылке, сработает XSS код и хакер получит куки жертвы (с авторизационной информацией). При этом жертва ничего даже не заметит.

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

Как защититься от sql injection

Думаю, самые любопытные тестеры (тоесть, настоящие тестеры) после прочтения предыдущего поста об sql injection задали себе вопрос "А как же защититься от sql injection ?"

Хотя над этим вопросом должны ломать голову не тестеры, а программисты, но тестерам, думаю, эта информация тоже будет полезной. Как минимум, ею можно поделиться с программистами. Ведь тестеры и программисты - друзья! Правда ?! :)

Так вот, существуют три простые правила, как защититься от sql injection:

• Самое главное - фильтровать кавычки.
• Если используется оператор сравнения строк LIKE фильтровать знаки “%” и “_”
• Не использовать при сравнении переменных без кавычек типа select …where id=$id а использовать так select ...where id='$id' и обратиться к пункту 1

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

Security testing. SQL injection.

Итак, начнем разбирать виды атак и методы тестирования подверженности сайта этим атакам.

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

Как проверить?
Ищем на сайте место, где в url передаются какие-то параметры.
Например, http://site/test.php?id=12
Немного изменяем значение параметра (самый элементарный способ – добавляем кавычку :) ), вот так
http://site/test.php?id=12’ и выполняем.

Если вы получили что-то вроде
«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 '' ORDER BY p.pid DESC LIMIT 0, 20' at line 12»

Радуйтесь! Вы нашли уязвимость на сайте :)

PS: «Радуйтесь» - это я для тестеров написала. Программисты тут, конечно, должны очень огорчаться :)

Вот, собственно и все. Для хакеров, которые будут ломать сайт, это, конечно, только начало. Дальше они начнут составлять всякие каверзные запросы, подбирать количество полей, имена колонок таблиц, потом сами названия таблиц … в конечном итоге – стырят логин и пароль админа :) И сделают с сайтом, все, что захотят.

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

Ведь столько всего еще нужно поломать... :)

Security testing. Введение.

Хочу рассказать о таком виде тестирования как тестирование безопасности или security testing. Речь пойдет о тестировании безопасности веб-сайтов. Кратко о том, что такое тестирование безопасности, какие его цели и как его проводят (что именно тестируют и как). Также, расскажу о том, какие инструменты используются для проведения тестирования безопасности сайта (по крайней мере, расскажу о тех, что я использовала).

Итак, что же это такое тестирование безопасности или security testing ?

Тестирование безопасности (Security testing) – это оценка уязвимости программного обеспечения к различным видам атак.

Виды атак бывают:

• sql injection атака
• xss атака
• php including атака
• подстановка параметров в url
• DoS атака
• брутфорс атака
  

Вообще-то атак больше :), но я расскажу только о тех, с которыми я сталкивалась и знаю, как проверить приложение на уязвимость к этим атакам.

Так что, читайте подробно о каждой атаке в следующих постах.
Надеюсь информация будет полезна.