«à 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) является оценка работоспособности системы в условиях повышенных и предельных нагрузок.

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

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

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

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