У каждого тестировщика рано или поздно наступает неловкий момент. Обнаружился вредный баг и его необходимо локализовать. По закону подлости баг воспроизводится нестабильно, при непонятных шагах и только на некоторых устройствах. Есть логи, но они не информативны. Разработчик занимается новой функциональностью, он не может отвлечься от текущих задач, пока не будут найдены четкие шаги воспроизведения. Менеджер ждет исправления (надо быстрее, заказчик переживает).

Как внести ясность в такой ситуации? Некуда деваться, пора разбираться, что же там происходит «под капотом» приложения.

Когда-то я был тестировщиком. Помню, как в те далекие времена порой был крайне недоволен программистами:

Эти вечные сомнительные доводы «это не баг, это фича» или «если это и баг, то незначительный, пусть остается».

Да как же остается, если система колом встает!?

Потом я стал программистом. И всё изменилось – меня начали жутко бесить эти бесконечные возвраты на доработку:

То им это не нравится, то тут не работает! Да нафига было вообще в этом окне контекстное меню вызывать и вставлять нечитабельные символы!? Как они вообще до этого додумались!? Бред же, в боевом режиме так ни один пользователь не сделает!

Не буду править, пусть остается!

В общем, классика – вражда программистов и тестировщиков.

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

Не секрет, что большинство крупных сервисов на серверной стороне используют какой-либо API (Application Programming Interface) для взаимодействия с различными клиентами.

На «очной ставке» NeoQUEST-2016 Максим Хазов рассказал о различных подходах к определению и использованию скрытого серверного API-функционала на примере таких популярных сервисов, как ВКонтакте, Instagram, Facebook.

В данной статье остановимся на основных моментах доклада и поделимся всеми электронными материалами: видеозаписью выступления, презентацией, а также демонстрациями атак для каждой рассматриваемой социальной сети (всё под катом).

Намекнём: «прогулки» по социальным сетям ещё предстоят участникам NeoQUEST-2017, регистрация на online-этап которого идет полным ходом!

Для поиска уязвимостей все средства хороши, а чем хорош фаззинг? Ответ прост: тем, что он дает возможность проверить, как себя поведёт программа, получившая на вход заведомо некорректные (а зачастую и вообще случайные) данные, которые не всегда входят во множество тестов разработчика.

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

В этой статье мы:

• продемонстрируем, как фаззить обработчик JSON-запросов;
• используя фаззинг, найдём уязвимость переполнения буфера;
• напишем шеллкод на Ассемблере для эксплуатации найденной уязвимости.

Разбирать будем на примере исходных данных задания прошлого NeoQUEST. Известно, что 64-хбитный Linux-сервер обрабатывает запросы в формате JSON, которые заканчиваются нуль-терминатором (символом с кодом 0). Для получения ключа требуется отправить запрос с верным паролем, при этом доступа к исходным кодам и к бинарнику серверного процесса нет, даны только IP-адрес и порт. В легенде к заданию также было указано, что MD5-хеш правильного пароля содержится где-то в памяти процесса после следующих 5 символов: «hash:». А для того, чтобы вытащить пароль из памяти процесса, необходима возможность удалённого исполнения кода.

Часто у нас стоит задача протестировать какую нагрузку выдерживает сайт наших клиентов. Для себя, в качестве инструмента тестирования, мы выбрали yandex-tank. Это будет краткая заметка о том как быстро начать работать с этим инструментом.

Данная статья является лиш исследованием на тему и не должна использоваться как инструкция к действию.

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

Я поставил на Firefox плагин RequestPolicy и обнаружил в HTTP хедерах на сайте.

X-Squid-Error:"403 Access Denied"

Это значит что соединение к сайту проходит через прозрачный прокси.

В этой статье я попробую пройти при помощи локального прокси написанного на Lua (Вики)

Скачав LuaSocket 2.0.2 я написал небольшой скрипт локального прокси.

Приветствую, Хабравчане! Сегодня Slack выпустили свой клиент для Windows. Но еще совсем недавно такого клиента не было и необходимость получать нормальные уведомления была необходимостью. Slack предлагал использовать приложение Chrome. У данного подхода было два минуса:

1. Отсутствие возможности настроить, сколько времени будет показываться уведомление
2. Если уведомление пропало, то пользователь никак об этом не узнает.

К примеру, ты ушел налить себе кофе, а тут кто-то написал в чат. Возвращаешься на рабочее место и… тишина! Ничего не происходило. Ты работаешь дальше, а человек всё ждет и ждёт, пока кто-нибудь ему ответит. Непорядок! Skype вежливо уведомляет тебя всплывающим окошком и нагло сигнализирует в таскбаре о том, что тебе пришло сообщение. Быстрее прочти, а то твой таскбар так и будем мигать желтым светом. Даже если ты ушел на весь день.

Что мы будем делать: настроим отправку сообщений от имени конкретного пользователя в несколько чатов и другим пользователям используя HTTP запрос средствами PHP, с минимальными усилиями.

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

Сообщения рассматриваем именно по той причине, что с ними можно работать только в standalone-приложениях.

План действий:
1. Создаем приложение
2. Получаем access_token
3. отправляем сообщения

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

В этой статье я хочу поведать о том, что такое юзерскрипты, c чем их едят и, главное, как их готовят!

Внимание: предполагается минимальное знание javascript.
На практике доказано: юзерскрипты может писать человек, не знакомый с программированием, но обладающий усидчивостью и желанием изучить javascript!
О том, что такое javascript и как с ним обращаться, можно узнать на javascript.ru.

Данная статья является лиш исследованием на тему и не должна использоваться как инструкция к действию.

В связи с разгулом банхамера по интернет просторам участились советы по использованию различных прокси, vpn, tor и анонимайзеров. Эти все способы отправляют трафик третей стороне которая его может перехватывать и модифицировать. Это не наш метод. Мы сейчас просто и легко научим браузер дурить DPI.

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

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

Исходные данные:
Сайт(Адрес изменён): http://rutracker.og


Страница заглушка(Адрес изменён): http://198.51.100.0/...

Адрес страницы заглушки которая появляется при попытке открытия сайта. У каждого провайдера адрес страницы заглушки наверно разный.

Время от времени случается, что ко мне обращаются пользователи с заглючившим Windows 7 или 8 (наверняка так же и с «десяткой» будут жертвы), у кого постоянно запускается «Восстановление системы» вместо нормальной загрузки, и автоматический механизм поиска и устранения проблем не справляется.



Мне удалось разобраться, почему возникает сообщение «Было предпринято несколько попыток, но причину проблемы определить не удалось» и как вернуть жизнь операционке без радикальной переустановки.

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

• На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
• Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
• Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
• За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

В ожидании чудес

Канун Нового Года — время чудес. В преддверии нового года мы все вспоминаем год уходящий и строим планы на следующий. И надеемся, что все проблемы останутся в прошлом, а в новом году случится чудо, и мы заживём по-новому.

Какой же Java разработчик не мечтает о чуде, которое осенит его и позволит стать Самым Крутым На Свете Java Программистом.

Хорошие новости: я хочу рассказать как раз о таком чуде.

Имя ему — автоматические тесты!

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

Почему бы не избежать этих неприятностей, прогнав нагрузочный тест?

Наверное, кого-то останавливает неверное представление о том, что нагрузочное тестирование — это очень сложное дело, требующее специальных знаний. Однако не боги горшки обжигают. Если выбор — тестировать не слишком профессионально, или не тестировать вовсе, я бы выбрал первое. Тем более, что организовать примитивный тест производительности очень даже просто. Можно воспользоваться онлайн-средствами (см., например, Нагрузочное тестирование по-быстренькому), а можно замутить все своими руками, это ненамного сложнее.

Под катом рассказываю, как с нуля организовать незамысловатый нагрузочный тест сайта при помощи Apache JMeter.

Тестирование является важной составляющей процесса разработки приложения. Для Android тестирование особенно важно, так как устройства сильно отличаются друг от друга:

• Размером и разрешением экрана.
• Версией Android.
• Форм-фактором.
• Системой команд процессора.
• Наличием фронтальной камеры, NFC, внешней клавиатуры, и т.д.

Поэтому тестировать приложение приходится на множестве устройств.
В процесс тестирования входят различные виды тестирования. Рассмотрим, как происходит процесс функционального тестирования приложения вручную. Тестировщик устанавливает на устройство приложение, вдумчиво проверяет всю функциональность, затем возвращает устройство в первоначальное состояние. И так для каждого приложения и каждого устройства. Очевидный недостаток такого способа – большие затраты времени для регулярного тестирования.
Очевидный плюс автоматизированного тестирования – его можно регулярно проводить без особых затрат. Например, каждую ночь тестировать свежий билд приложения на всем множестве имеющихся устройств, а утром анализировать результаты и исправлять ошибки.
В данной заметке будут рассмотрены средства реализации автоматического тестирования. Рассматриваются только инструменты, входящие в Android SDK или распространяющиеся под Open Source лицензией.

Источник изображения
В данной статье я хочу ознакомить вас с еще одним фреймворком для автоматизации тестирования мобильных приложений, а именно с Calabash – кроссплатформенным решением для приемочного тестирования Android и iOS приложений. Статья рассчитана на новичков, которые тестируют или хотели бы тестировать Android приложения.

Введение

Одной из проблем, на решение которой был направлен HTML5, было повышение логичности (и, следовательно, машиночитаемости) разметки, о чем свидетельствует введение стандартных семантических элементов, таких как <header>, <nav> и <figure>. Это все хорошо, но иногда возникает потребность добавить определенные машиночитаемые атрибуты для элементов контента, так чтобы их можно бы использовать в каком-либо скрипте предсказуемо, даже если разметка используемая для различного контента различается между собой. Эта потребность уже удовлетворена, в определенной степени, с помощью простых и обратно совместимых Микроформатов, и с помощью более эзотерического RDFa.

В связи с этим, нет ничего удивительного, что решение этой проблемы было добавлено в спецификацию HTML5 в виде спецификации микроданных(далее Microdata), включающей в себя набор атрибутов, которые могут быть добавлены к любому элементу и связанное DOM API для обработки/агрегирования микроданных на странице.

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

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

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

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

http://www.site.com/page.php?var=<script>alert('xss');</script>

Как-то не очень страшно :) Чем же действительно может быть опасной данная уязвимость?

В процессе разработки любого приложения наступает момент, когда в связи с ростом функциональности трудозатраты на регрессионное тестирование становятся непомерно велики. Другая причина значительной трудоемкости тестирования iOS-приложений (так же как и любых других мобильных приложений) — разнообразие линейки поддерживаемых устройств и версий ОС, необходимость тестирования в альбомном и портретном режимах, а также при различных условиях соединения с интернетом. Стремление оптимизировать процесс тестирования приводит нас к необходимости его полной или частичной автоматизации.

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