суббота, 28 марта 2009 г.

Самые важные качества тестировщика. Часть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 на примере которого и буду рассказывать о моделировании разных видов нагрузки для разных целей тестирования.

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

суббота, 21 марта 2009 г.

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

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

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

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

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

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

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

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

четверг, 19 марта 2009 г.

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

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

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

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

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

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!

среда, 4 марта 2009 г.

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

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

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

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

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

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