пятница, 23 декабря 2011 г.

Oracle: небольшая помощь для отладки и тестирования

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

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

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

На случай , если Ваше приложение работает с СУБД Oracle, то наверняка при этом использует функцию sysdate этой самой СУБД (если , конечно, вы не изобрели свой "велосипед").
sysdate возвращает текущее дату-время на сервере, где запущен данный инстанс Oracle.
Создатели Oracle пошли на встречу разработчикам и тестировщикам , реализовав возможность активации режима, при котором sysdate будет возвращать фиксированную дату до тех пор, пока этот режим не будет деактивирован.

Вот как заставить sysdate возвращать фиксированную дату:
ALTER SYSTEM SET fixed_date = '2011-12-31 23:59:59';

А вот так все можно "вернуть вернуть на место":
ALTER SYSTEM SET fixed_date=NONE

Плюсы:

1. легко включается и отключается
2. не влияет на системное время ОС

Минусы:

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

среда, 30 ноября 2011 г.

Драйвер сидирома в интернете, драйвер модема на болванке (с)



Попалась на тестирование программка. Читаю , значит требования. Абстрактно если, то озвучить их можно так:

Требование 1: найти объект по номеру одного из его дочерних объектов и вернуть код ошибки 1, если дочерний объект с указанным номером не найден

Требование 2: если у найденного объекта список дочерних объектов пуст, то вернуть код ошибки 2

И ведь считается, что разработчик все закончил , система ДОЛЖНА соответствовать требованиям и остались "только баги" (вероятные) :)

Вот такие вот "дедлоки" )

воскресенье, 27 ноября 2011 г.

Эти страшные системные ограничения )

Несколько месяцев назад натолкнулся на один очень странный баг в linux-приложении, которое активно использует unix-сокеты для общения своих дрочерних процессов. На одной из инсталляций приложение работало очень странно: запускалось , фурычило, но отказывалось останавливаться , а после принудительной остановки, отказывалось повторно запускаться. После продолжительных копаний со словами "мистика!" выяснилась причина была найдена - приложение было установлено по слишком длинному пути и unix-сокеты (читай файлы) создавались тут же (по их полному пути в системе ) . По их обрезанным именам стало ясно, что уперлись в какой-то системный лимит. Это было странно, потому что помилось, что полное имя файла может быть более 4кб. В данном случае уперлись в странную цифру 108 - не степень двойки, не круглая - вообще черт знает что.
В общем, оказалось это длина буфера одного из поля структуры sockaddr_un, расширить которое нельзя. "Нельзя так нельзя" - подумали мы и больше длинных путей ко временным файлам приложения не создавали и заказчикам деплоили с учетом этой "системой" проблемы. Думать о том, как бы это пофиксить времени тогда не было, раз был неплохой воркэраунд.
Ну вот пару дней назад, когда описанная выше проблема почти стерлась из памяти опять на это напоролись на одной из автоматически создаваемых тестовых инсталляций. В этот раз матчасть перечитали повнимательнее и в код заглянули более въедливо ... в результате поняли , что никакого такого "системного" ограничения на самом деле нет (не считая 4кб на полный путь к файлу), ведь можно указывать относительное имя к файлу unix-сокета, вместо полного) Ну 108 байт на относительное имя хватит на китай..
Смотрели друг на друга с разработчиком и посмеялись сами над собой - "Эх, Семен семеныч!", как говорится))

суббота, 15 октября 2011 г.

Забавный секурити баг на досуге


Принимал я тут как-то на досуге участие в тестировании одного веб-проекта.
Функциональное тестирование. Работа с системой требует авторизации, капчи на каждом шагу, сесии и все такое.
В одном из сценариев пользователи аттачат файлы. По логике бизнес-процесса , скорее всего это будут в том числе и приватные документы. При аплоаде много чего проверяется, в том числе и допустимый размер аттача как на клиентской стороне , так и на сервере.
В общем , " как учили ". На залитый аттач пользователь потом может всегда найти ссылку для скачивания. Ссылка располагается в private-части. Вроде все вроде бы ок, если бы не тот факт, что в ссылке есть параметр file_id, который меня и заинтересовал.
Путем перебора от 1 до "пока не надоест" мне удалось вытянуть все аттачи, которые были зарегистрированы в БД всеми пользователями этого проекта.. К счастью заказчика тестирования - пока еще тестовыми пользователями. полный приват, в общем :) О баге, конечно же доложено.
Название проекта, конечно же , не сообщаю :)

"А король то голый.." (с) :)

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

среда, 5 октября 2011 г.

Автотесты: почему важно "не делать лишних движений"

Несколько слов о дизайне автоматических тестов.
Точнее о вопросе избыточности проверок. Существует подход к разработке модульных (Unit) автоматических тестов, который можно описать так "Проверяем одно условие за один тест" (Verify one condition per test). Применение такой стратегии дает множество плюсов: при провале тестов можно максимально быстро выявить узкое место, и, как следствие, максимально быстро устранить проблему. Пусть тестов станет больше, но плюсы, как правило перевешивают.
При автоматизации более громоздких регрессионных функциональных тестов подобная стратегия также применима. Только в роли единицы проверки должны выступать уже не "условия" , а конкретный вариант поведения. При этом, все что лишнее, и не влияющее на данный конкретный вариант поведения должно быть безжалостно ампутировано. Лишними могут быть: некоторые инициализирующие параметры объектов, а также проверки , которые уже делались или будут делаться в тестах, специально для этого предназначенных. В общем, не надо делать лишних движений, у которых нет конкретных целей.
Вот пример из реальной практике, иллюстрирующий вышесказанное:

1. есть автоматический функциональный тест, проверяющий некий вариант поведения системы
2. в ходе его инициализации создается объект "клиент", у которого есть как обязательные так и необязательные параметры, причем данному тесту ни один из них не важен - важен факт наличия объекта "клиент" и все..
3. тестировщик, который создавал тест, то ли копипастом, то ли для разнообразия решил заполнить поле email , причем указал там строку с емейлом "не по RFC" (на момент написания теста проверке необязательного email внимания не уделялось)
4. тест долгое время работал, проверял нужные варианты, давал результат
5. в какой-то момент проверке полей данного объекта уделили внимание, и ужесточили ее, создав соответствующие автотесты на эту новую "функциональность"
6. старый же тест начал проваливаться, причем, не доходя до своей целевой проверки - проваливаться на этапе инициализации. Причина, думаю, ясна - строка "отбалды" в поле email.

Тест пришлось править, тратить время. Пусть не много времени ушло данный конкретный тест, но в принципе - это лишняя трата времени, лишнее отвлечение внимания на провал теста. Причина - "лишние движения" и никому ненужная "кучерявость" теста. Всему свое место - фантазии и творчеству, в том числе :)

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

Анализ покрытия кода с помощью gcov+lcov





Сегодня наконец-то выделил время на то, чтобы наладить анализ покрытия кода. Пока только покрытие операторов и функций.
Тестируемое приложение написано на Си, ОС linux. Компиллятор gcc. Приложение должно быть собрано с флагами компиллятора : -ftest-coverage -fprofile-arcs.
Для анализа покрытия использовалась утилита gcov, которая помогает провести анализ того, какие строчки кода и сколько раз были задействованы в ходе выполнения приложения.
В результате выполнения приложения генерируются специальные файлы для каждого файла исходников , в которых и содержится собранная информация о покрытии. Дальше с помощью утилиты lcov полученные данные обрабатываются и генерируется , цветастый и веселый html-отчет . Я , как преимущественно визуалист, особенно был рад получившейся наглядности :) Даже в первом приближении мне стало понятно, что в плане автоматизации будут некоторые изменения :)
Упомянутые утилиты бесплатны, присутствуют в репозиториях всех популярных дистрибутивов linux, а также могут быть скачаны с sourceforge, например.
Итак, метод опробовал. Планирую проводить отдельный анализ покрытия для сеансов unit-тестирования и отдельно для сеансов автоматического регрессионного тестирования.
В более отдаленной перспективе постараюсь также наладить анализ покрытия путей выполнения и условий, а также освоить gcov в связке с gprof, для профилирования приложения.

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

лучше 1 раз увидеть, чем 100 раз предположить :)

UPD 05/10/2011
При анализе результатов ночного прогона обнаружил небольшой бонус - gcov умеет и условия анализировать (см. пример на картинке вверху статьи ) . Приятная неожиданность :)

суббота, 24 сентября 2011 г.

Стандарты именования объектов БД

Когда речь идет о написании кода, например на том или ином языке программирования , то в профессиональных командах разработчиков рано или поздно приходят к использованию единой нотации переменных , констант, классов , функций и так далее. Каждый разработчик понимает , для чего это нужно и следует принятым правилам и соглашениям о кодировании, делая "хорошо" прежде всего самому себе.
Но когда заходит речь о проектировании и создании схем БД, то зачастую необходимость применения унифицированных принципов именования не всеми осознается и тем более не всеми применяется. Хотя в этом направлении стандартизированность не менее важна и не менее нужна...Не знаю , как на этот вопрос смотрят разработчики, но попытаюсь изложить взгляд со стороны тестирования...

По своему личному опыту могу точно утверждать, что единообразие наименований объектов в БД очень часто существенно экономит время . Преимущественно речь идет о времени на написание SQL-запросов особенно, когда приходится их писать сотнями в день и когда имеешь дело с большой разветвленной БД, где десятки а иногда и сотни таблиц. В этом случае все названия запомнить , конечно же , нереально, но если ты заранее знаешь , что имеешь дело со словарной таблицей и у нее обязательно есть mnemonic , и description, то это существенно облегчает жизнь. Если же проектировщики и разработчики задумывали и создавали БД "кто в лес, кто по дрова", то ты заранее не знаешь, description там или же desc, а может descr или вообще поле с опечаткой.. В итоге запрос с первого раза не пишется, надо смотреть описание таблицы - в общем, делать лишние движения. Они небольшие, но их много и вообще , как в песне поется, "не думай о секундах свысока"...
С экономией времени на составлении запросов вроде бы все ясно, потому что явно. Есть и другие менее явные положительные эффекты от единой стратегии именования.
Буквально на днях сталкивался с конкретной задачей автоматизации, которая решалась бы гораздо меньшими усилиями и существенно меньшим количеством строк кода, если бы не винегрет в названии одинаковых по смыслу полей в разных таблицах. То есть и в направлении автоматизации тестирования возможна экономия сил , нервов и средств при минимально едином подходе.
Еще один положительный эффект - новички ( и разработчики , и тестировщики ) гораздо быстрее осваивают систему, если при ее проектировании и разработке применяются единые правила наименований объектов. Быстрее осваивают - читай, быстрее начинают приносить реальную пользу.

В общем, везет тем , кто везет. А что делать если приходится работать с тем, что есть? Если , к примеру, схема БД росла и множилась годами, накопила кучу болячек, пережила не одну текучку кадров и к стандартизации нотации объектов в этой БД относились "с прохладцей"? Конечно же, не надо посыпать себе и тем более другим голову пеплом , не надо искать виноватых и жаловаться всем на всех.. Просто старайтесь конструктивно доводить до ответственных лиц необходимость рефакторинга схемы БД , если такого осознания у них нет. Если же это осознание уже есть, то готовьте тесты , проверяющие, что в результате рефакторинга система дает конечному пользователю как минимум то же самое, что и до него ))

Полезная информация по теме:
[1] Форумы на sql.ru - искать по "правила именования объектов базы данных" - тут знающий народ, решающий реальные задачи. Много хороших и дельных советов и практик.
[2] Хорошая книга как раз о рефакторинге уже существующей БД: Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series)
Scott W. Ambler, Pramodkumar J. Sadalage

среда, 14 сентября 2011 г.

Результаты опроса: "Какую систему контроля версий Вы используете"..



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

Системы контроля версий
Небольшие комментарии по результатам:
Лидерство Subversion предсказуемо. Как говорится - "сложилось исторически". Для меня наиболее интересен был "спор" Git и Mercurial. Git действительно более раскручен (чего стоит только один github), хотя особых преимуществ в функциональном плане не дает. Остается интересным и открытым вопрос, что кроется за словом "Другая" - там точно есть TFS, bazaar и многие другие... Удивила CVS - судя по всему , эта система скоро станет экзотикой - мир не стоит на месте...

воскресенье, 11 сентября 2011 г.

Небольшой оффтоп: возвращаем в жизни роутер

Несколько дней назад внезапно из строя вышел мой домашний WiFi-роутер Asus Wl=500G Premium.   Симптомы: невозможно достучаться даже по проводу ни по одному из протоколов, горят все лампочки, выключение , сброс настроек ни к чему не приводят. Обращение к знакомым обладателям подобных устройств и поисковой выдаче гугла выявило, что "слабым" местом этого девайса является его блок питания. Симптомы при выходе его из строя похожи. Вскрываю БП и действительно вижу слегка вздутый конденсатор. Радуюсь, что как правило в двух местах сразу такие вещи не ломаются и причина скорее всего в этом. У меня полетел конденсатор на 1200микрофарад, 10 вольтовый. В "Чипидип"е , что на Проспекте Мира куплена замена : радиальный , 1000 микрофарад (на 1200 найти не удалость), 10 вольтовый. Старый выпаян, новый впаян и, ура, в каждом уголке моей квартиры снова появился его величество Интернет =)

Конечно же, можно было просто купить новый БП. Но как-то это не интересно, что ли.

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

среда, 17 августа 2011 г.

Загрузка файлов клиентом и Selenium

В целях автоматизации тестирования  некоторых сценариев точечно применяю Selenium-тесты на perl-е + Selenium RC.
До сих пор не приходилось сталкиваться с автоматизацией кейсов, связанных  с аплоадом файлов. И вот такая необходимость возникла.
Итак , запускаю Firefox + Selenium IDE , записываю действия по аплоаду и экспортирую в perl-виде.
Смотрю, какими же командами IDE мне сэмулировал нужную последовательность. Удивленно вижу, что для указания нужного файла используется всего навсего type с локатором файлового INPUT-поля и полным путем файла.
Отсекаю лишнее ,добавляю нужное , встраиваю в perl-фреймворк и вижу , что тест не проходит.
Копаю perl-библиотеку для работы с Selenium (WWW::Selenium) , радостно нахожу команду attach_file , пытаюсь ее применить и не получаю результата.
Гуглю, вижу всяческие рецепты,  как можно извратиться с помощью спец js-скриптов, дополнительных exe-утилит (для Windows).. Ни то ни то не подходит. Как раз в тот момент, когда хотелось "забить" на аплоад, в "буржнете" попался очень простой совет - принудительно установить фокус на поле с именем файла после его заполнения. НЕ веря в успех, попробовал и получилось...Работает (в *chrome - режиме) , аплоадит, тестируется =)

p.s.
По поводу Selenium 2.0 - слышал, что там проблема пользовательского аплоада стоит гораздо менее остро. Лишний повод познакомится и попробовать.

UPD 22/08/2011:
Перечитал пост и понял, что из него до конца неясно, какая же последовательность команд решает проблему? Ответ: focus +  type . attachfile можно вообще не использовать. По крайней мере, в моей ситуации со стандартными контролами пользы от этой команды  никакой.

пятница, 5 августа 2011 г.

Лень и кроссплатформенные баги

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

Вот пример: Разработчику поступила задача слобать некий cgi-скрипт. Веб-продукт, частью которого будет этот cgi-скрипт , заявлен как работающий под любой *nix - системой: Linux, FreeBSD, Solaris ..etc
По ходу дела девелопер сталкивается  с необходимостью работы с датами. В любом уважающем себя языке программирования, особенно в скриптовом, есть библиотеки для кроссплатформенной работы с датами. Но с ними надо разбираться, читать маны..разработчику ( кодящему , к примеру, в linux) неохота, ведь он знает быстрый способ - запустить из скрипта консольный date с нужными ему флагами и распарсить вывод этой команды. Сказано - сделано. date убран в обратные кавычки (если это,  к примеру perl), вывод распарсен, дата в нужном формате получена и в итоге скрипт написан и вроде как работает...У тестирования, к примеру, цейтнот и есть время на проверку в самой распространенной конфигурации, которой, к примеру является работа на  linux.... Или же тоже лень проверять во всех конфигурация... В общем ,  протестировали в linux - все ок. Релиз. В итоге находится пользователь, который ставит продукт на Solaris и получает 500-тки. Ругается и топает ногами "За что я заплатил деньги".. При разборе полета выясняется , что у GNU-той команды date  в SunOs совсем другие параметры, из-за чего скрипт ленивого разработчика аварийно завершается.

В общем лень лени рознь. Разработчикам советы давать не охота, а вот нам - тестировщикам , посоветовал бы не лениться ;)

четверг, 4 августа 2011 г.

Тестовый smtp-сервер в одну строчку

Недавно я делился советом о том, как быстро поднять тестовый http сервер в произвольной директории. Вот еще еще одна плюшка от python-a, которая может сэкономить немало времени в определенных ситуациях..
Например, вы разработчик и кодите нечто, что должно отправлять почтовые сообщения по smtp. Или же вы тестировщик, который должен проверить отправку неким приложением письма.
Вот практический совет, как поднять тестовый smtp-сервер, который будет принимать сообщения по указанному порту и дампить их на stdout:


python -m smtpd -n -c DebuggingServer localhost:1025


UPD 04.08.2011:
Да, эта "штука" может быть полезна при создании комплексных автоматических тестов, например систем регистрации новых пользователей и тому подобных вещей. В настоящее время как раз проводим ручное тестирование нового функционала , связанного рассылками писем пользователям и, возможно, описанная выше "фича" окажется полезной.

среда, 3 августа 2011 г.

grep по сетевым пакетам

Тем, кто знает , зачем может понадобиться сниффать сетевые пакеты, анализировать их содержимое хочу посоветовать GNU-утилиту ngrep, которая позволяет с легкостью проводить в реальном (!) времени grep по содержимому сетевых пакетов.
Утилита есть в репозиториях практически всех linux-дистрибутивов.
Подробно о ее возможностях можно узнать в ее man-е , а также на странице проекта.

Пример: "Поиск в HTTP-пакетах дефолтного интерфейса по строке 'login' "

sudo ngrep 'login' -W byline  port 80

Результат:


 T 10.33.4.105:46837 -> 10.33.4.106:80 [AP]
GET /cgi-bin/clients/STUB?login=type%20login%20here&psw=ecaae631e3e96de095a45d015c3b4e99&phones=74953222233&mes=messagetext.&charset=utf-8 HTTP/1.1.
TE: deflate,gzip;q=0.3.
Connection: TE, close.
Host: some.host.name.
User-Agent: libwww-perl/5.837.
.

##
T 10.33.4.106:80 -> 10.33.4.105:46837 [AP]
HTTP/1.1 200 OK.
Date: Wed, 03 Aug 2011 11:39:43 GMT.
Server: Apache/2.2.3 (CentOS).
Connection: close.
Transfer-Encoding: chunked.
Content-Type: text/html; charset=ISO-8859-1.
.
54.
$VAR1 = 'login';
$VAR2 = 'psw';
$VAR3 = 'phones';
$VAR4 = 'mes';
$VAR5 = 'charset';

среда, 27 июля 2011 г.

KDE как образец организации обратной связи

Некоторое время пользуюсь дистрибутивом Debian Squeeze со штатной графической оболочкой KDE4. Хочу вкратце описать как устроен фидбек по багам в этом софте и поделиться своим восхищением =)
На примере сбойнувшего приложения Blogilo. Это штатная для KDE утилита , позволяющая отправлять посты в блоги с декстопа. Сегодня я ей решил воспользоваться, ну и напоролся на аварийное завершение в одном из сценариев ее использования.
Поначалу ругнулся, но когда увидел, как система отреагировала на сбой , то все заскриншотил, специально повторив crash приложения для этого =)
Итак, сразу после сбоя, я увидел довольно функциональное окно с возможностью зарепортить баг, посмотреть причину сбоя и т.д.

Далее "окошко вежливости":

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


Потом окно со стектрейсом, который тут же можно сохранить в файл, скопировать в буфер обмена и т.д.:



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

Далее самое интересное..

До чего дошел прогресс (с)

Недавно открыл для себя очень полезную и простую фичу в python-e.
Буквально одной строчкой в консоли поднимается простенький веб-сервер:


python -m http.server 8000 (для 3-x версий питона)

python -m SlimpleHTTPServer (для 2.X версий питона)


Если явно не указать порт, то будет висеть на 8000.

В итоге при запросе http://:8000/ видим листинг директории, в которой он был запущен.

Как минимум умеет:
1. отображать статические страницы, подхватывает index.html
2. если нет индексной страницы, то показывает листинг текущей директории

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

четверг, 21 июля 2011 г.

Как быстро снять скриншот на гуглофоне

Недавно потребовалось оперативно снять скриншот на Android-смартфоне. Компьютера с SDK под рукой не было. Выручило приложение ShootMe. Доступно на маркете, бесплатно.
Чтобы снять скриншот надо запустить приложение и просто потрясти аппарат :)
Снимки получаются хорошего качества, можно выбрать формат jpg или png (по-умолчанию):

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

понедельник, 18 июля 2011 г.

Насколько может быть важен robots.txt

Сегодня позабавила новость о том, что в поисковой выдаче Яндекса и в его кеше появились смски, которые ничего не подозревающие пользователи одного из "большой тройки" отправляли с использованием веб-сервсиса отправки сообщений.

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


http://yandex.ru/yandsearch?p=6&text=url%3Awww.sendsms.megafon.ru*+|+url%3Asendsms.megafon.ru*&fyandex=1&lr=213

красовались сотни страниц выдачи с номерами телефонов и текстами сообщений - было забавно почитать некоторые)

В общем, кто хотел, информацию слил на совершенно законных основаниях с совершенно открытого источника.

А Вы пользовались этим сервисом этого оператора ? :)

p.s. утечка произошла из-за особенностей сервиса и невнимательного отношения к настройке robots.txt , а может незнания того, что для "паука" все разрешено, что не запрещено :)


UPD 21/07/2011:
"Оказались в паблике" потому , что:
1. либо не было файла robots.txt
2. либо в нем не было директив запрещающих индексацию "секретного" URL. Все что не запрещено явно - разрешено для индексации
3. возможно для user-agent 'Yandex' правила и были, только Яндекс , насколько я знаю при индексации иногда заходит на сайты с "левым" агентом. Делается это для борьбы с черными сеошниками (отдельная интересная , но объемная тема)

Вопрос 2: как поисковик узнал о секретном урле со временными смсками?
Тут все просто - для этого не обязательно наличие ссылки со страницы. Тут возможны по меньшей мере 2 варианта, откуда Яша узнал:

1. Кто-то сообщил , используя Яндексовскую-же форму "Сообщить о новом сайте" , где можно указывать произвольный URL, который поисковик попытается обойти при следующем обходе.
2. Поисковик "отреверсил" структуру ресурса. Это не очень сложная задача, а для Яндекса тем более.

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

понедельник, 20 июня 2011 г.

Откуда не ждешь...

Вот сидишь, бывает, тестируешь что-то очень важное и срочное, ищешь ошибки, недочеты в том, что скоро будет продавать твоя фирма. А баги вылезают там, откуда ты этого совсем не ждешь - в софте, который ты для этого используешь. Иногда даже в очень дорогом и "надежном" софте. Бывает, такие "сюрпризы" существенно осложняют жизнь и тормозят процесс... Например, сегодня требовалось организовать эскпорт данных для нагрузочного тестирования и одной СУБД Oracle в другую.
Как любая уважающая себя СУБД Oracle предоставляет собственный инструмент для этого : пара утилит expdp, impdp. Сложность оказалась лишь в том, что запуск expdp приводит к безнадежному Segmentation Fault:

Program terminated with signal 11, Segmentation fault.
#0 0x0000000000409b43 in udcTrace ()
(gdb) bt
#0 0x0000000000409b43 in udcTrace ()
#1 0x0000000000413558 in udcScrubParam ()
#2 0x0000000000407877 in udeProcessLMParam ()
#3 0x0000000000403918 in __libc_csu_init ()
#4 0x00007fff00009fc0 in ?? ()
#5 0x0000000000000000 in ?? ()


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

среда, 1 июня 2011 г.

08.06.2011 - день тестирования ipv6


Более 30 лет назад основоположники Интернета изобрели 32-битную адресацию - всем нам привычный ipv4-адрес. С самого начала можно было предположить, что рано или поздно свободные адреса закончатся. Но до этого момента было очень-очень далеко. И вот он уже вот-вот настанет. Адреса будут исчерпаны уже в этом году. Чем это грозит нам, как простым пользователям Интернета? Да , собственно, ничем. Все существующие ресурсы будут продолжать резолвиться по их ipv4-адресам.
А чем для нас , как тестировщиков, обернется переход на ipv6? Многим из нас предстоит приступить к тестированию поддержки ipv6 в ПО, потому что разработчики (и их менеджеры), которые не подумали об этом ранее , уже начали шевелиться, готовиться. Особо попотеть придется разработчикам и тестировщикам системного по, биллинговых систем, а также различного рода сетевых приложений. В любом случае будет интересно. Это в общем.

Так что же такого будет происходить 8-го июня? Ничего особенного. Просто те компании, которые заявили о своем участии в "дне тестирования ipv6" на 24 часа включат поддержку ipv6 на своих первичных ресурсах, а принимающие участие в эксперименте провайдеры (ISP) сделают соответствующие апгрейды софта на своем сетевом оборудовании.

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

Ждем 8-го)

Приятная неожиданность )

Все мы часто пользуемся личными кабинетами у своих интернет-провайдеров.
У каких-то операторов они удобные, функциональные, у каких-то не очень. Частой фичей этих самых кабинетов стала возможность подписки по SMS на различные типы событий. Например, о поступлении средств на счет или предупреждения о скорой блокировке аккаунта и т.д. и т.п.
Мой провайдер по слухам когда-то предоставлял такую функцию, но для некоторых групп абонентов почему-то ее заблокировал. Сегодня я узнал, что я тоже в этой группе, не найдя возможности подписаться на SMS в своем личном кабинете.
В общем, уж не знаю, что меня заставило открыть исходный код главной страницы личного кабинета, но факт в том, что в этом самом коде я заметил закомментированный пункт меню "Подписка на SMS оповещения". Я машинально скопировал я ссылочку из этого "заблокированного" пункта меню, вставил в адресную строку броузера и очень удивился , когда увидел соответствующую web-форму ) (очень надежный способ блокирования функционала =)
Ну и подписался, конечно. Еще более удивительным оказалось то, что подписка реально заработала и услуга эта оказалась бесплатна. Ничего не остается теперь, как пользоваться втихоря )))

четверг, 26 мая 2011 г.

ICQ для Linux: сделано для галочки



Вчера на в "ленте" промелькнула новость о том, что Mail.Ru group презентовала линуксовую версию одиозного клиента ICQ. Сегодня с утра решил попробовать "это" в деле, заранее ожидая кучу подвохов..)
Итак, захожу на офсайт ICQ, действительно нахожу в списке загрузок пунктик для linux-версии, открываю соответствующую страницу - ага , вот и кнопка "Скачать". Радостно ее жму.. ничего. Не работает закачка. Мозилловский броузер под Debian... Вот они, начались подвохи. Броузеров на свете много, решаю перебрать. Запускаю штатный KDE-шный Konqueror. Этот "гадкий утенок" благополучно качает мне на винт *.air - файл.
AIR? Всего-то? Видимо, глупо было ждать полноценного портирования в виде QT-приложения. Теперяшние хозяева ICQ пошли по пути наименьшего сопротивления , сделав кросплатформенную air-версию (тогда непонятно, причем тут Linux? Ах да, маркетинговый ход =)
Двигаемся дальше..
Так как ранее запуском AIR-приложений под Linux я никогда не занимался ни в исследовательских, ни в каких бы то ни было других целях, то пришлось поставить AIR-платформу от Adobe: sudo aptitude install adobeair .
В результате в директории /opt/Adobe\ AIR/Versions/1.0/ у меня завелся Adobe-овский инсталлер для air-приложений, которым и надо открывать *.air файлы. Название у инсталлера жутко неудобное 'Adobe AIR Application Installer' - делаем симлинк в /usr/bin: cd /usr/bin; sudo ln -s '/opt/Adobe\ AIR/Versions/1.0/Adobe AIR Application Installer' aaai
Далее вызываем aaai и открываем с его помощью скаченный асечный air-контейнер.
Начинается установка, соглашаемся со всем, что нам предложат.
Установка завершена. В трее висит знакомый до боле восьмилистник. Жмем...
Увы - всего лишь пустое окошко без единого элемента управления...
Как говорится , "не смешно". Такой UI - слишком сурово даже для beta-версии...

Разбраться в причинах такой "дружелюбности" интерфейса уже нет ни времени , ни желания =)

понедельник, 16 мая 2011 г.

Производительность и особенности индексирования таблиц в СУБД

Недавно столкнулся с проблемой производительности приложения, работающего с СУБД Oracle.
Есть таблица А, в ней есть строковый столбец B, для которого создан простой индекс. Есть несколько веб-форм, делающих различные запросы (в т.ч. и SELECT) к этой таблице.
Одна из этих форм, делающая простейший SELECT к указанной таблице, очень долго "откликается" на даже на единичный запрос при больших объемах данных. При этом есть и другие формы, отображающие данные из этой таблицы в том или ином виде - с этими формами проблем нет. Сравниваем запросы. В проблемной форме к индексируемому полю в секции WHERE применяется функция upper. Поле проиндексировано, но план выполнения показывает, что индекс не используется. Кто-то советует собрать статистику, кто-то советует прохинтовать запрос. А на самом деле, надо просто немножко углубиться в матчасть и понять, что при использовании функции результат становится непредсказуемым для оптимизатора, поэтому в данной ситуации необходимо либо отказаться от upper , либо создать дополнительный индекс по используемой функции.

воскресенье, 8 мая 2011 г.

Приносит ли тестирование деньги?



"Приносит ли тестирование ПО деньги?".
Часто приходится сталкиваться с мнением о том, что тестирование не приносит денег. Само по себе. При этом утверждается, что "сами по себе" приносят прибыль маркетологи, пресейлы и прочие, которые уполномочены ставить штампики и подписи в разного рода хитрых бумажках. Иногда к этой касте "кормильцев" в последнюю очередь ("Ах да, и , конечно, программисты") приплюсовывают разработчиков. Эдакий компромисс. Что же тестирование? Ему, тестированию, многие некоторые менеджеры разных уровней и некоторые авторы различных книг о разработке ПО отводят второстепенную роль. Далее я попытаюсь описать свой взгляд на проблематику.

1. Умирающие стереотипы
Долгое время тестирование программного обеспечения действительно имело второстепенную роль и зачастую этим видом деятельности (отдельной и целенаправленной) многие производители софта пренебрегали. Рынок не диктовал таких жестких требований к качеству как сегодня, конкуренция среди производителей не была столь высока, клиенты не были столь придирчивы и требовательны. То есть, чисто экономически , многие вендоры осознанно не тратили деньги на тестирование, потому, что их софт и так "уходил как горячие пирожки". С развитием рынка ПО эта ситуация стала меняться. И на Западе давно уже стереотипам о второстепенности тестирования нет места, они отжили и умерли. Изменилось и отношение к тестировщику , как представителю отдельной профессии, носителю специфических навыков и менталитета. В нашей стране еще перемены дошли не до всех, но ситуация меняется - доказательством этому является бурный рост коммьюнити, спрос на соответствующие образовательные курсы, рост зарплат и т.д. и т.п.

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

3. Если что-то нельзя пощупать оценить, значит этого просто нет
Часто приходится получать встречный и резонный вопрос "Хорошо, допустим, тестирование приносит прибыль. Какую конкретно ?( в процентах, рублях или любой другой количественной форме)" Действительно , вопрос на первый взгляд непростой и , как говорится , с подвохом. Пытаться на него ответить "конкретными" процентами, полагаю, просто невозможно. Такой вопрос можно смело считать провокационным и смело об этом заявлять задающему :) Таких вопросов, считаю, после достижения понимания по п.2 ("Само по себе") быть попросту не должно.

4. Тестирование - не гарантия прибыли
Да, тестирование ПО, как один из важнейших компонентов системы обеспечения качества, в современных условиях играет все более важную роль в процессе разработки. Это тенденция. Неверное понимание этой тенденции иногда рождает и другие, ранее неведомые проблемы. Поясню на абстрактном примере: компания N инвестирует немалые деньги в тестирование своего софта, успешно продает его. Тем не менее время от време у клиентов возникают проблемы с этим софтом. Компания, считая процесс тестирования одним из важнейших компонентов СМК, начинает инвестировать в тестирование еще больше (нанимают больше людей, автоматизируют функциональное тестирование, вкладывают деньги в обучение тестировщиков и т.д. и т.п.) - результате количество проблем снижается, но тем не менее проблемы все еще есть и, иногда , довольно серьезные. "В чем дело? Тестировщики, плохо работаете? Тратим на вас деньги зря?" . Да, вполне может быть , что тестировщики работают неэффективно, может быть, некоторые из них некомпетенты. Но зачастую проблемы кроются не там, куда менеджмент раз за разом направляет свое внимание, средства и претензии. Например, на предприятии отсутствует система управления требованиями и , как следствие, управление изменениями хаотично и плохо контролируемо, что заведомо влечет большой оверхед для программистов и тестировщиков. Или, например, сами программисты работают с использованием устаревших методологий и технологий. Проблемы могут быть везде - у архитекторов (или в связи с их отсутствием) , у разработчиков, аналитиков, маркетологов, технической поддержки. Поэтому, уделяя пристальное внимание развитию тестирования, не стоит забывать, что этому процессу нужен надежный "фундамент" и не менее надежная "крыша".

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

четверг, 5 мая 2011 г.

Баги , которые лучше не фиксить :)

Сегодня очень развеселил Майкрософт, вернее его продукт Outlook 2007.
Сегодня развернули внутреннюю ленту новостей с использованием Trac и его компонента Blog.
Заведомо знал , что у компонента есть Rss-лента,а у Outlook - Rss Reader.
Когда дело дошло до того, чтобы прикрутить эту ленту к outlook столкнулся с тем, что ему обязательно требовался url в формате: http://example.com/feed/main.xml - то есть линк на xml-файл.
Я расстроился, так как у Trac-a url следующий: http://trac.bm.in-line.local/blog?format=rss

Решение пришло через минуту : http://имя хоста с ,где установлен trac/blog?format=rss&blablabla.xml - и эврика! масдаевский софт на это клюнул, благополучно подгрузив в почтовик нужную мне ленту новостей)))

Уж не знаю , как это назвать - баг или не баг , или просто имитация серьезного контроля входных данных.

В общем, пользуйтесь ;)

суббота, 9 апреля 2011 г.

Визуализатор схемы БД "на коленке"

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

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

Под рукой был python с установленным модулем sqlalchemy, а также вспомогательная python-овская библиотека для визуализации графов, средствами GraphViz.

Простейший скрипт на python:


#script: visualize.py
from sqlalchemy import MetaData
from sqlalchemy_schemadisplay import create_schema_graph
graph = create_schema_graph(metadata=MetaData('sqllite:///database.db'),
show_datatypes=False,
show_indexes=False,
rankdir='LR',
concentrate=False
)
graph.write_png('database.png')


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

Итак, еще раз ингридиенты:

1. python 2.5 (2.6,2.7) (aptitude install python)
2. sqlalchemy (easy_install sqlalchemy)
3. библиотека-GraphViz (aptitude install graphviz)
4. sqlalchemy_schemadisplay (wget http://pypi.python.org/packages/source/s/sqlalchemy_schemadisplay/sqlalchemy_schemadisplay-1.0.zip#md5=14b8366bb27b6abef32df65710d4380f )
5. visualize.py (см. код выше)
6. создаем произвольную директорию и кидаем туда п.5 и п.4, а также sqlite-базу)
7. запускаем: python visualize.py и получаем database.png

Все это хозяйство точно работает и с mysql (проверял лично) , а также должно теоретически работать почти со всеми известными СУБД (oracle, ms sql server, access db, postgres ...)

Если кому понадобится - пишите, выложу куда-нибудь архив-пример. Вот так , например, выглядит результат визуализации более менее сложной схемы (картинка размыта по просьбе правообладателя =)):



p.s. на этот раз ограничений с ОС нет. Все это работает и под Windows. Надо только скачать инсталлеры pythongraphviz-а с соответствующих офсайтов.

вторник, 5 апреля 2011 г.

Миллиарды от багов не спасают )

В феврале 2007 года ВВС США решили впервые вывести F-22 за пределы страны, перегнав несколько истребителей на базу ВВС Кадена на Окинаве. Звено из шести F-22, вылетевших с Гаваев, после пересечения 180-го меридиана - международной линии перемены дат - полностью лишилось навигации и частично - связи. На базу ВВС на Гавайях истребители вернулись, визуально следуя за самолетами-заправщиками. Причиной неполадки стала ошибка в программном обеспечении, из-за которого произошел сбой в работе компьютера при смене времени.

четверг, 31 марта 2011 г.

Сказка о профессионализме... )

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

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

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

— Конечно, — говорит Недозайцев. Он директор, и всегда готов взвалить на себя проблему, которую придется нести кому-то из коллектива. Впрочем, он тут же уточняет: — Мы же это можем?

Начальник отдела рисования Сидоряхин торопливо кивает:

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

— Очень приятно, — говорит Морковьева. — Ну, меня вы все знаете. А это — Леночка, она специалист по дизайну в нашей организации.

Леночка покрывается краской и смущенно улыбается. Она недавно закончила экономический, и к дизайну имеет такое же отношение, как утконос к проектированию дирижаблей...........ЧИТАТЬ ДАЛЕЕ

Как говорится , сказка - ложь, да в ней намек... )

среда, 23 марта 2011 г.

Новый сотрудник



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

1. Неточности во всевозможных HOWTO для новых сотрудников. Как правило не всегда хватает времени , чтобы держать подобные мануалы в полностью актуальном состоянии - поэтому при работе нового тестировщика с этими документами появляется неплохой шанс привести инструкции в соответствие реальному положению дел. В данном вопросе можно пойти на дополнительную хитрость: обеспечить новичка документом, заведомо содержащим изъян и понаблюдать за тем, как человек будет решать возникшую проблему, заметит ли он ее вообще? Немного по-иезуитски, но это позволяет лишний раз убедиться в правильности решения после собеседования.
2. Порция некритичных ошибок в тестируемом ПО Незашоренность взгляда,а также отсутствие груза важной и срочной работы у нового сотрудника позволяет ему замечать множество мелких ошибок и недочетов в тестируемом ПО. Как правило это незначительные ошибки в GUI, ошибки эргономики , пропущенные более опытными коллегами, а также порция замечаний и предложений по улучшению. Многое из всего, что "замечает" новый тестировщик в итоге не приводит к изменениям и улучшениям, но какой-то процент действительно полезных замечаний обеспечен в любом случае.
3. Ошибки в документации к ПО Не знаю как у других, но в число обязанностей моей команды входит и тестирование пользовательской документации к ПО. В силу разных причин пользовательская документация неизбежно начинает накапливать неточности, несоответствия с реальным поведением системы. И новый тестировщик, априори внимательно относясь к пользовательской документации (ведь зачастую именно по ней он знакомится с системой ), неизбежно натыкается на эти несоответствия , а также на отсутствие необходимых ему сведений. Это позволяет повысить качество этой самой документации.
4. Повторение - мать учения. Во время помощи новому коллеге часто приходится вспоминать некоторые аспекты функционирования тестируемого софта, пояснять и уточнять последовательности настройки, развертывания тестовых стендов и т.д. и т.п. - все это может показаться скучным, но иногда это позволяет вспоминать уже подзабытые ньюансы, освежая и закрепляя таким образом собственное знание системы.
5. Новые техники. Новый сотрудник, особенно опытный, может привнести с собой новые техники тестирования. Например, когда-то давно пришел к нам тестировщик, хорошо знакомый с техниками пентеста. Его знания и умения пошли на пользу и успешно дополнили уже имевшиеся на тот момент наборы тестов безопасности системы. Сотрудник уже давно перешел в другую компанию, но его опыт продолжает приносить нам пользу.

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

среда, 16 марта 2011 г.

Требования: по ту сторону баррикад

На страницах блогов тестировщиков и других онлайн-ресурсов , посвященных тестированию ПО и вообще качеству ПО , часто затрагивается тема требований к ПО. Большинство специалистов по тестированию предпочитают работать с четкими требованиями к ПО для того, чтобы иметь возможность также четко организовывать свою деятельность и выдавать продукт максимально удовлетворяющий чаяниям заказчика. Но при этом познания многих тестировщиков о процессе составления требований заканчиваются содержимым соответствующей страницы в Wikipedia.
Желающим немного приоткрыть завесу того, что из себя представляет процесс создания требований к ПО и управления ими , могу посоветовать недавно перечитанную мной книгу, которая стала классикой для многих аналитиков и системных архитекторов
"ПРИНЦИПЫ РАБОТЫ С ТРЕБОВАНИЯМИ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ" (Дин Леффингуэлл, Дон Уидриг)

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

пятница, 11 марта 2011 г.

lsof+gdb - надежные помощники при "трудном" моделировании



Совсем недавно в ходе попыток моделирования очередного "мигающего" и трудновоспроизводимого бага потребовалось запустить очень продолжительную серию испытаний , в ходе которой требовалось эмулировать частую потерю соединения приложения с СУБД. Эмуляция активности приложения , естественно, автоматизирована. Продолжительность теста - минимум 30 минут, максимум - 2-3 часа. В общем, понятно, что вручную "дергать" витую пару - не вариант =) Первое, что пришло в голову использовать файер (iptables). Попробовали - и по ряду причин (здесь их не описываю) вынуждены были отказаться от этого способа.

Встала задача "узнать дескрипторы соединений с СУБД нужного процесса" и "извне процесса эти по этим самым дескрипторам закрыть соответствующие соединения".
На помощь пришел всесильный отладчик gdb, который умеет работать в так называемом "batch"-режиме.

С помощью lsof узнаем дескрипторы соединений (у ислледуемого нами их могло быть несколько), а с помощью gdb в "batch"-режиме закрываем сокеты по их дескрипторам.


#генерируем файл с командами на закрытие нужных нам дескрипторов (в данном случае дескрипторы соединения с СУБД висящей на фиксированном порту 1521)

lsof -p 5239 | grep ':1521' | awk '{print $4}' | sed 's/u//' | awk '{print "call shutdown("$1",2)"}' > commands

#скармливаем пакет команд gdb

gdb -p 5239 -batch -x commands



Указанные команды помещаем в цикл с произвольными задержками между итерациями и в результате приложение начинает работать в условиях периодичеких "проблем с сетью и соединением с СУБД".

Все это под linux, все это бесплатно , быстро и эффективно.

Возможно, кто-то спросит "Как сделать аналогичное под Windows?" - сразу не отвечу, но на досуге ничего не мешает выяснить, если это действительно кому-то понадобится =)

воскресенье, 6 марта 2011 г.

Небольшой совет покупающим e-book

Тем, кто надумал приобрести электронную книгу позволю себе дать небольшой совет.
Собираясь в магазин, прихватите с собой SD-карту, на которую предварительно запишите экземпляры книг/журналов в нужных вам электронных форматах. Особенно стоит уделить вниманиe "отсканированным" pdf и djvu - как правило именно с масштабированием таких книг могут возникать проблемы у девайсов для чтения с E-ink технологией.
С такой SD-картой вам не придется верить на слово продавцу о том, что то или иное устройство "отлично справится с любым форматом" - вы просто проверите это сами. Заодно "ПРОТЕСТИРУЕТЕ" usability устройства и гарантированно сможете подобрать то, что вам нужно с первого раза.
В общем, этот совет родился не на пустом месте - сам совсем недавно помучился с обменами и возвратами, не слишком въедливо исследовав первоначально купленный девайс.
Берегите свое время ;)

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

Повышаем стабильность запуска SeleniumRC по крону

В одном из предыдущих постов я описывал вариант использования SeleniumRC на Linux-машине с использованием cron и виртуального X-сервера Xvfb.

Некоторое время эта связка работала исправно. crond - обеспечивал то, что RC всегда запущен, сам RC прилежно "гонял" тесты. Но время от времени случались непонятные массовые провалы автотестов со следующими записями в STDERR:


10:23:50.037 INFO - Preparing Firefox profile...
Error: cannot open display: :1
10:24:16.152 ERROR - Failed to start new browser session, shutdown browser and clear all session data
java.lang.RuntimeException: Timed out waiting for profile to be created!
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.waitForFullProfileToBeCreated(FirefoxChromeLauncher.java:348)
....

После некоторого времени "копания" выяснил (по информации от syslog-а), что в Xvfb периодически случался SIGFAULT (причина пока не ясна и требует отдельного времени на анализ). Ну случался и случался - никто не мешает также по крону запускать и сам Xvfb. Да, только есть ньюанс. Эта утилита, как принято у *nix-демонов, при запуске создает лок-файл со своим pid-ом. Делается это для предотвращения попытки запуска нескольких виртуальных серверов на одном и том же виртуальном дисплее.

Все хорошо, только разработчики забыли сделать "джентльменскую" проверку "живости" того самого процесса, pid которого любезно указан в lock-файле. Соответственно, после аварийного завершения самогО процесса давно нет в живых, но его lock-файл все еще на диске и мешает запуску новых экземпляров Xvfb.

Рассуждая дальше, как говорится "нечего на зеркало пинять.." , ведь я при периодическом запуске Xvfb и RC не позаботился (подобно разработчикам самогО Xvfb) о проверке того, запустился ли виртуальный менеджер окон или нет , поэтому и получал запущенный SeleniumRC, не имеющий в своем распоряжении виртуального дисплея , где бы он мог корректно запустить Firefox. В итоге, простая проверка и принудительная чистка ненужных уже lock-ов позволили "закрыть" глаза на возможные ошибки в стороннем ПО, получая стабильный результат тестирования собственного.

"Мораль сей басни такова": если указываешь другим на их ошибки, старайся сам не допускать аналогичных =)

среда, 16 февраля 2011 г.

Дедлайны по проектам и полнота тестирования

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

1. Руководство идет на откладывание даты релиза и при этом достигается максимальное качество за счет выполнения всех запланированных тестов (по всем функциональным и нефункциональным возможностям)
2. руководство идет на дополнительные инвестиции в привлечение дополнительных ресурсов : временное расширение штата, аутсорс...
3. QA-менеджер , как Роден, "берет кусок гранита и отсекает все ненужное", оставляя в плане тестирования лишь задачи на тестирование наиболее критичных функций приложения

Я был вынужден остановиться на варианте 3.

А как Вы решаете подобные проблемы?