Качество ПО

"Фобосом" навеянное

2012-01-31T07:12:00.000+04:00

ВЕРОЯТНАЯ ПРИЧИНА ПАДЕНИЯ аппарата "фобос-грунт" - ошибка в программировании. Версия с "происками Запада" , похоже, не состоятельна.
Многие, вцепившись , в версию "ошибка разработчиков" уже начали костерить деградацию образования, пресловутое снижение качества знаний выпускников, тут же пробежались по ЕГЭ, отдавая дань моде.. Да, деградация.. Да, снижение... Да, ЕГЭ, будь он неладен...
Но вот вспомнилась мне почему-то одна лекция по "Численным методам" в институте.. читал ее профессор Михайлов - человек с богатейшим опытом решения задач прикладной математики. Он поведал нам о подобном случае, который случился еще в СССР , когда был утерян очень дорогой спутник из-за ошибки программистов... Насколько я помню, тогда речь шла всего лишь о проблеме округления и накопления погрешности. В общем, из-за ошибки в вычислениях спутник улетел совсем не туда, куда планировалось и миллионы народных рублей сейчас возможно еще летают где-то в солнечной системе ).. Тогда не было ЕГЭ, не было "деградации" и "снижения" - все было, судя по всему, наоборот, но подобные ошибки случались и времена, которыми принято гордиться...

Internet Explorer на страже стандартов =)

2012-01-04T18:27:00.001+04:00

Броузер Internet Explorer хорошо известен тем, что старается уж очень четко следовать стандартам, разработанным ответственными комитетами типа W3C
Там, где остальные броузеры закрывают глаза на некоторые опечатки, небольшие огрехи вебмастеров, IE каленым железом выжигает всякую "крамолу" )) Вот несколько граблей, на которые пришлось наступить в последнее время:
1. <!DOCTYPE
Сегодня довольно долго бился над выяснением того, почему на одном из сайтов "слетает" верстка в IE , которая идеально выглядит в Chrome, Opera, Firefox.
Перелопатил все стили, исправил пару незначительных кроссброузерных различий, но в целом IE продолжал показывать мне совсем не то ,что остальные броузеры.
Причина оказалась банальна - в первой строке html-ответа не было директивы <!DOCTYPE ...>, после его добавления в базовый html-шаблон все сразу стало выглядеть так, как требовалось (с небольшими допустимыми для IE отличиями типа отсутствия теней у некоторых элементов).
Вот что пишет w3c об этой преамбуле: W3C-HTML5#DOCTYPE

2. js-движок и синтаксис записи словарей в js
Довольно много приходилось писать на perl и в последнее время на python. При записи структур типа:

my $dict = {
      'key1': 1,
      'key2': 2,
   }

давно выработалась привычка всегда ставить запятую после очередной записи в хеше, даже если она последняя - это позволяет избегать синтаксических ошибок при возможном будущем добавлении новых записей в этот словарь. Эта привычка меня недавно подвела при написании js-кода, содержащего в большом количестве структуры, подобные описанной выше.
Отладка кода проводилась в Chrome и Mozilla. Когда начал проверять работу в IE ошалел от кучи js-ошибок (при возникновении ошибок компилляции js - IE просто перестает рендерить страницу). Пришлось перелопатить все js исходники и повычищать последние запятые, которые оказались несоответствующими синтаксису описания словарей, к которому я так привык.
Теперь взял за правил ставить запятые ПЕРЕД элементами словаря ))

3. подчеркивания в именах хостов
На эти грабли наступал уже давно и , может быть, даже описывал на страницах этого блога. Но недавно, когда коллега начал в ярости постукивать по клавиатуре, я поинтересовался в чем у него проблема , понял, что он наступил на то же самое (спросил бы раньше))))
Пример: есть тестовый стенд одного веб-проекта. Тестируется в основном под Chrome, Mozilla. Начали проверять под IE. Полезли глюки в виде странной работы с куками. После ряда возгласов "мистика" стало ясным, что виноваты символы подчеркивания в имени тестового хоста, которые оказалиcь "не по стандарту".

4. зацикливание при редиректе из-за некорректного http-euiv
Вот такой вот код:

<meta http-equiv="Refresh" content="1; /" />

отлично понимается Chrome и Firefox - в результате выполняется редирект на главную страницу сайта.
В IE (например в 8.0) делается редирект на ту же самую страницу. В результате - ежесекундные бесконечные редиректы.
Чтобы сделать понятным для всех броузеров ,опять же обратимся к стандарту W3C-HTML5#PRAGMAS

Это далеко не полный список того, чему IE предельно жестко учит)) Буду пополнять эту коллекцию

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

2011-12-23T17:05:00.001+04:00

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

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

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

На случай , если Ваше приложение работает с СУБД 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 для всего инстанса. Соответственно, необходимо не забывать "возвращать на место" и вообще отдавать себе в этом отчет, если это инстанс может одновременно использоваться несколькими пользователями.

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

2011-11-30T19:28:00.003+04:00

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

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

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

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

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

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

2011-11-27T22:29:00.001+04:00

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

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

2011-10-15T17:27:00.000+04:00

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

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

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

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

2011-10-05T13:40:00.000+04:00

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

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

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

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

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

2011-10-05T02:10:00.006+04:00

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

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

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

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

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

2011-09-24T04:20:00.000+04:00

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

По своему личному опыту могу точно утверждать, что единообразие наименований объектов в БД очень часто существенно экономит время . Преимущественно речь идет о времени на написание 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

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

2011-09-14T19:27:00.001+04:00

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

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

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

2011-09-11T21:03:00.000+04:00

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

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

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

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

2011-08-17T18:11:00.003+04:00

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

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

2011-08-05T19:42:00.002+04:00

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

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

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

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

2011-08-04T09:51:00.003+04:00

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

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

UPD 04.08.2011:

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

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

2011-08-03T15:40:00.004+04:00

Тем, кто знает , зачем может понадобиться сниффать сетевые пакеты, анализировать их содержимое хочу посоветовать 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';

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

2011-07-27T18:50:00.003+04:00

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

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

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

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

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

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

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

По каждому багу можно посмотреть полную информацию , а при просмотре этих багов рядом отображаются данные текущей проблемы для сравнени:

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

p.s. Приходилось сталкиваться с различным софтом, в котором делались аналогичные попытки получить качественные сигналы о возникающих проблемах , но пока KDE лично в моих придирчивых глазах не превзойден. Еще бы сбоев поменьше, вообще цены не было бы! )))

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

2011-07-27T08:15:00.001+04:00

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


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

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

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

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

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

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

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

2011-07-21T00:46:00.002+04:00

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

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

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

2011-07-18T18:12:00.003+04:00

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

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


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. Поисковик "отреверсил" структуру ресурса. Это не очень сложная задача, а для Яндекса тем более.

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

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

2011-06-20T17:08:00.000+04:00

Вот сидишь, бывает, тестируешь что-то очень важное и срочное, ищешь ошибки, недочеты в том, что скоро будет продавать твоя фирма. А баги вылезают там, откуда ты этого совсем не ждешь - в софте, который ты для этого используешь. Иногда даже в очень дорогом и "надежном" софте. Бывает, такие "сюрпризы" существенно осложняют жизнь и тормозят процесс... Например, сегодня требовалось организовать эскпорт данных для нагрузочного тестирования и одной СУБД 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 ,но врмеени в обрез - пришлось генерировать данные заново, вместо того, чтобы их более быстро и легко смигрировать.

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

2011-06-01T21:49:00.002+04:00

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

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

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

Ждем 8-го)

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

2011-06-01T00:40:00.000+04:00

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

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

2011-05-26T07:02:00.000+04:00

Вчера на в "ленте" промелькнула новость о том, что 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-версии...

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

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

2011-05-16T20:22:00.000+04:00

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

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

2011-05-08T20:40:00.004+04:00

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

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

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

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

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

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

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

2011-05-05T15:07:00.003+04:00

Сегодня очень развеселил Майкрософт, вернее его продукт 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 - и эврика! масдаевский софт на это клюнул, благополучно подгрузив в почтовик нужную мне ленту новостей)))

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

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

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

2011-04-09T16:11:00.004+04:00

Недавно мне потребовалось проверить соответствие существующей схемы БД (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. Надо только скачать инсталлеры python-а graphviz-а с соответствующих офсайтов.

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

2011-04-05T14:55:00.003+04:00

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

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

2011-03-31T20:03:00.003+04:00

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

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

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

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

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

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

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

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

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

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

2011-03-23T07:23:00.003+03:00

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

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

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

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

2011-03-16T19:42:00.000+03:00

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

"ПРИНЦИПЫ РАБОТЫ С ТРЕБОВАНИЯМИ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ" (Дин Леффингуэлл, Дон Уидриг)

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

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

2011-03-11T19:21:00.002+03:00

Совсем недавно в ходе попыток моделирования очередного "мигающего" и трудновоспроизводимого бага потребовалось запустить очень продолжительную серию испытаний , в ходе которой требовалось эмулировать частую потерю соединения приложения с СУБД. Эмуляция активности приложения , естественно, автоматизирована. Продолжительность теста - минимум 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?" - сразу не отвечу, но на досуге ничего не мешает выяснить, если это действительно кому-то понадобится =)

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

2011-03-06T04:55:00.001+03:00

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

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

2011-03-01T20:22:00.002+03:00

В одном из предыдущих постов я описывал вариант использования 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-ов позволили "закрыть" глаза на возможные ошибки в стороннем ПО, получая стабильный результат тестирования собственного.

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

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

2011-02-16T18:30:00.001+03:00

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

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

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

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

Странный баг в VirtualBox и способ его решения

2010-12-14T12:53:00.002+03:00

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


Runtime error opening 'D:\Users\will\.VirtualBox\Machines\XP1\XP1.xml' for reading: -102 (File not found.).
D:\tinderbox\win-3.2\src\VBox\Main\MachineImpl.cpp[679] (Machine::registeredInit).
Код ошибки: 
E_FAIL (0x80004005)
Компонент: 
VirtualBox
Интерфейс: 
IVirtualBox {3f36e024-7fed-4f20-a02c-9158a82b44e6}

Если кто столкнется с подобным, не торопитесь удалять и пересоздавать виртуальную машину. Чтобы решить проблему надо перейти в директорию с настройками проблемной виртуалки. Там будет два файла: <имя машины>.xml-prev и <имя машины>.xml-tmp. То есть при сохранении состояния машины и завершении работы почему-то не был создан файл <имя машины>.xml и именно из-за его остутствия и возникала указанная выше проблема.
В общем, берем и переименовываем -prev Или -tmp в .xml и пользуемся созданной ранее машиной.

Башорг о тестировании

2010-12-10T15:22:00.001+03:00

Сегодня попалась забавная байка, которая должна понравиться любому тестировщику :)

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

Selenium RC + Firefox + crond

2010-12-08T17:28:00.006+03:00

Некоторое время назад потребовалось обеспечить бесперебойность работы selenium rc на одном из linux-серверов с установленной X-window.
До этого RC вручную запускался вручную либо непосредственно на сервере (DISPLAY :0) либо вручную же через vnc. После перезагрузки сервера или из-за пока неустановленных редких сбоев в самом RC процесс автоматического тестирования нарушался. Для решения проблемы было решено добавить запуск Selenium RC в cron.
В crontab была добавлена соответствующая строчка, запускающая RC-сервер. В этот момент не было учтено , что firefox оконное приложение и требует возможности работать на конкретном дисплее =) Соответственно по крону RC-сервер стартовать не мог. Вернее сам-то сервер стартовал, но запустить X-овое приложение (firefox) без дисплея уже не мог.
Возник вопрос о том, о каком вообще дисплее может идти речь, если приложение запускается в ситуации отсутствия каких-либо X-сессий? На некоторое (короткое) время возможность запуска X-программ из под cron была поставлена под сомнение, но довольно быстро было найдено решение.
В описанной ситуации можно использовать утилиту Xvfb, которая позволяет совершать графические операции в памяти и запускать "иксовые" приложения на виртуальных дисплеях.
Ниже привожу последовательность команд, решившая мою проблему:


Xvfb :1
export DISPLAY=:1
java -jar selenium-server.jar

Таким образом, если SeleniumRC будет запущен из-под cron описанным образом , то запускаемый им firefox будет запускаться на дисплее :1 и послушно выполнять все команды автотеста, с которого при желании можно даже снять скриншоты)

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

Тестирование требований

2010-12-07T14:02:00.002+03:00

Перечитываю старую добрую кингу Альфреда Дастина (Elfreide Dusting) "Автоматизированное тестирование программного обеспечения" (Automated Software Testing). Читал ее когда-то очень давно, не имея реального шанса проверить на практике советы и предположения, которые делает автор в своей книге. Сейчас, став чуть более опытным, многое из прочитанного становится более понятным, подтверждающим полученный опыт и "набитые шишки". Особенно понравилась следуюшая мысль (которая для кого-то может показаться банальной):
Программа, в основе которой лежат неточные требования, не будет удовлетворять заказчика или конечного пользователя независимо от качества описания архитектуры или программного кода, составляющего модули приложения (выделил жирным , по-моему , главную фразу предложения:)
Тысячу раз СОГЛАСЕН - так оно зачастую и происходит...
В качестве мер по предотвращению дефектов и проблем с конечным пользователем автор предлагает привлекать тестировщиков (высокой квалификации) с самых ранних стадий разработки ПО. В частности, со стадии составления спецификаций требований. Это мне также кажется верной стратегией, но ее соблюдение требует дополнительных трудозатрат со стороны тестирования. Кроме того, есть и психологический момент - не все разработчики, сисарки, менеджеры видят в тестировщиках людей, способных влиять на архитектурные решения до начала кодирования.
Интересно было бы узнать, насколько распространена практика привлечения сотрудников группы(сектора,отдела) тестирования к фазе составления требований к программному продукту и , соответственно, насколько она эффективна?
Если у кого есть желание поделиться своим опытом и мнением на этот счет, то буду признателен за соответствующие комментарии.

Ротация

2010-11-26T16:54:00.001+03:00

"На фронте я любил наблюдательного человека посылать. Старый ему видимую обстановку докладывал, а новый свежим взглядом проверял. И представляете, очень удачно это порой получалось. У старого наблюдателя от целого дня напряженного высматривания глаз, что называется, замылился. Он чего и не было замечал, а то что вновь появлялось не видел…». Володя Шарапов :)

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

Так что товарищ Шарапов все сказал правильно =)

Первый опыт непрерывной интеграции

2010-11-16T00:36:00.002+03:00

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

Для сборки проекта используется кроссплатформенная система сборки CMake (взамен устаревших и более сложных в использовании Autotools), а также две другие утилиты из CMake-семейства: CTest и CDash.
CTest используется для прогона модульных и комплексных автотестов.
CDash для обработки, хранения и отображения результатов автоматических сборок (результатов работы CTest-а).

Для проведения автосборок и сеансов автоматического тестирования выделен отдельный сервер.
cron-настроен на проведение автоматических ночных сборок.
Результаты каждого ночного сеанса тестирования автоматически экспортируются в CDash(в xml-формате) для обработки , архивирования и возможности отображения и анализа в любой момент времени.
Так "система" работает сейчас. Но, как говорится, всегда есть к чему стремиться. Проведение ночных сборок хоть и повышает скорость реакции на "поломки" в коде, но иногда и такая скорость недостаточна.
Сейчас есть желание и потребность прогона сборки после каждого коммита в репозиторий. Проблема в том, что коммиты могут быть многочисленны в течение одного дня и прогонять весь набор тестов (модульных и комплексных) после каждого изменения может стать трудновыполнимой задачей. В связи с этим вижу 2 варианта решения проблемы:

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

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

В общем, в ближайшее время задуманное будет реализовано.

Комментарии, вопросы, отзывы - милости прошу )

Установка TestLink

2010-11-13T16:10:00.002+03:00

Коллеги, отвечающие на мой предыдущий пост, помимо разных OpenSource TSS систем упомянули TestLink. Краем глаза мне удалось почитать документацию о нескольких из них, где-то даже попользоваться "демками".. В итоге из всего просмотренного решил более детально остановиться на TestLink. У этого проекта есть демо-версия, но она слишком медленно работает, заполнена кучей демо-данных со всех уголков мира ) и не дает реального представления о том, как система устроена изнутри. В общем, решил поставить и посмотреть. Забегая вперед, скажу , что процесс установки предельно прост и для многих его описание может показаться излишним, но , быть может, кому-то окажется полезным. Поэтому, опишу процесс инсталляции TestLink 1.9 на одном из имеющихся в моем распоряжении хостов:

OS: Debian Lenny9
web server: apache 2.0
php: 5.2.6 (требуется любая версия >= 5.2.0 )
mysql: Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2

1. Получение дистрибутива
Скачиваем дистрибутив с офсайта: прямая ссылка на архив
2. Виртуальный хост

создаем директорию для виртуального хоста. В моем случае: sudo -s mkdir /var/www/vhosts/testlink
распаковываем содержимое скачанного архива в созданную директорию
производим настройку виртуального хоста
... ServerName testlink:80 DocumentRoot /var/www/vhosts/testlink CustomLog /var/www/vhosts/testlink/logs/access_log combined ErrorLog /var/www/vhosts/testlink/logs/error_log DirectoryIndex index.html index.phtml index.php <ifmodule mod_php4.c> php_admin_flag engine on php_admin_flag safe_mode on </ifmodule> <ifmodule mod_php5.c> php_admin_flag engine on php_admin_flag safe_mode on </ifmodule> AllowOverride All Options +Indexes FollowSymLinks +ExecCGI </directory> <location ^/ > SetHandler mod_php5 order allow,deny allow from all </location> ...
В моем случае конфиги виртуальных хостов располагаются в отдельных файлах и включаются в главный файл настроек апача.
перезапускаем апач чтобы новые настройки вступили в силу
apache2ctl graceful

3. настраиваем /etc/hosts (для *nix машин) или %windows%\system32\drivers\etc\hosts (для виндовых машин) на клиентской машине для возможности указания teslink в url:
для этого достаточно в указанном файле достаточно прописать


 testlink

4. тест url
проверяем доступность инсталляции testlink:
http://testlink/index.php

Должны увидеть форму инсталляции:

Переходим по ссылке New Installation и принимаем лицензионное соглашение.
TestLink распространяется под Gnu GPL. Так что используем на здоровье )

5. Проверка системных требований
После принятия соглашения открывается форма проверки сервера на соответствие требованиям TestLink
Если то или иное требование выполняется, то соответствующий пункт помечается зеленым цветом и магическим словом ОК. В противном случае, видим оранжевые сообщения о том, чего у нас нет и чем это чревато.
Двигаемся по порядку:

Системные требования:
Server Operating System (no constrains) Linux
PHP version OK ( 5.2.0 [minimum version] <= 5.2.6-1+lenny9 [your version] ) Здесь у меня все ок. Web and PHP configuration

Maximum Session Idle Time before Timeout 24 minutes and 0 seconds - (Short. Consider to extend.) - инсталлятор рекомендует мне увеличить пераметр Max Session Idle Timeout - пока не понятно для чего, потому пропускаем мимо ушей и смотрим дальше

Checking max. execution time (Parameter max_execution_time) 30 seconds - We suggest 120 seconds in order to manage hundred of test cases (edit php.ini) - эта рекомендация понятна, но пока некритична (нам еще далеко до "сотен" тест-кейсов ) - решаем проблемы по мере постуления и двигаемся дальше

Checking maximal allowed memory (Parameter memory_limit) OK (128 MegaBytes)
Checking if Register Globals is disabled OK
Checking MySQL Database OK
Checking Postgres Database Failed! Postgres Database cannot be used. - на моем сервере не установлен Postgres. Пока пропускаю этот ворнинг, надеясь, что MySql для корректной работы будет достаточно.

Checking GD Graphic library Failed! GD Graphic library not enabled.
Graph rendering requires it. This feature will be disabled. It's recommended to install it..

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


sudo aptitude install php5-gd

далее добавляем строку extenstion=gd.so в php.ini и перезапускаем Apache.
В результате должны увидеть:

Checking GD Graphic library OK

Checking LDAP library Failed! LDAP library not enabled. LDAP authentication cannot be used. (default internal authentication will works). - С этим предупредением поступаем как с предыдущим - ставим нужную библиотеку (для возможности ldap-аутентификации в будущем):


sudo aptitude install php5-gd

далее добавляем строку extenstion=ldap.so в php.ini и перезапускаем Apache.
В результате должны увидеть:
Checking LDAP library OK

Checking JSON library OK - тут изначально у меня все ок. Если , у кого соответствующая библиотека не установлена, то вы знаете теперь как поступить )

Read/write permissions

Checking if /var/www/vhosts/testlink/gui/templates_c directory exists OK
Checking if /var/www/vhosts/testlink/gui/templates_c directory is writable OK
Checking if /var/www/vhosts/testlink/logs directory exists OK
Checking if /var/www/vhosts/testlink/logs directory is writable OK
Checking if /var/www/vhosts/testlink/upload_area directory exists OK
Checking if /var/www/vhosts/testlink/upload_area directory is writable OK

В общем цель данной страницы визарда установщика: увидеть сообщение "Your system is prepared for TestLink configuration (no fatal problem found)." и нажать Continue. Что и делаем! (Если у кого возникли фатальные проблемы, пишите о них в комментариях, а также о том , как вы их обошли - буду признателен )
Двигаемся дальше...

6. Definition of DB access
О назначении этого шага нетрудно догадаться по его названию - на следующей странице визарда мы должны:

Выбрать тип бд - мой выбор "MySQL (5.0 and later)"
адрес сервера, где находится наша СУБД - я выбрал localhost (пока все на одном сервере)
Указать имя схемы бд (соответствующую схему надо будет создать) - оставляем "testlink"
Опционально указать префикс таблиц: оставляем незаполненным
В полях "Database admin login" и "Database admin password" указываем логин и пароль админа СУБД для того, чтобы инсталлятор смог автоматически создать нужную схему и все нужные объекты в ней
В полях "TestLink DB login" и "TestLink DB password" указываем логин и пароль пользователя схемы из-под которого будет вестись вся внутренняя работа с БД (полет фантазии в выборе логина и пароля =)

Далее убеждаемся что демон (служба) mysql запущена и жмем батон "Process TestLink Setup!"

После этого инсталлятор:

создает файл config_db.inc.php в DocumentRoot-дериктории сайта , поэтому убедитесь, что у пользователя, из-под которого у вас запущен apache есть w-права на соответствующую директорию
Удаляет все , что есть в бд testlink (внимание! на случай, если вы используете уже существующую бд)
Создает все нужные таблицы в бд заново

Видим два предупреждения, касающихся настройки почтовых уведомлений.
Пока пропускаем это.
Переходим по ссылке "Please Click Me" и радуемся тому, что все благополучно установилось.
Логинимся под учеткой admin/admin и приступаем к созданию первого проекта по тестированию.

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

Всем удачи.

Оптимизация повторного использования тестов

2010-11-03T13:04:00.001+03:00

Добрый день!

Все мы знаем , что повторно использовать тесты - хорошая практика, позволяющая экономить ресурсы. Для этого (в частности для этого) мы автоматизируем часть тестов, а остальное документируем и сохраняем для возможности ручной регрессионной проверки в будущем.
Есть идея в своей повседневной практике внедрить некую систему управления тестами, в которой тест - отдельно хранимая сущность, доступная для повторного использования в произвольном количестве тестовых сценариев. То есть, нужна возможность компоновать тестовые сценарии из уже заготовленных тестов , как из кирпичиков.
Сейчас в своей профессиональной деятельности использую *.odt и *.doc форматы для хранения тестовых сценариев. Зачастую сталкиваюсь с ситуацией, когда один и тот же тест приходится копировать в разные сценарии. А при необходимости актуализации теста (например, в связи с изменениями в тестируемой системе) приходится актуализировать целый ряд документов. Этот "мартышкин труд" уже порядком надоел. Тем более, на одной из конференций, посвященной QA , я познакомился с решением для поддержки тестирования из MS Team Foundation Server 2010 и был , признаться , печатлен той степенью автоматизации поддержки тестирования, которой удалось достичь разработчикам VS2010.
По ряду причин продукция Microsoft нам не подходит. В связи с этим нахожусь в поиске упрощенных openSource и , возможно, платных (неполных) аналогов TFS. Полнейшая автоматизация traceability требований, кода и тестов на данный момент не цель. Главное - возможность повторного использования описаний тестов ;)
Если кто-то сталкивался с похожими проблемами, буду признателен за совет, отзыв , мнение.

Слишком умная мозилла (к вопросу о кроссброузерности)

2010-06-22T15:06:00.001+04:00

Основным броузером для отладки и тестирования веб-интерфейса нашего продукта является Firefox. Недавно опытным путем выяснилась одна его особенность: дописывать закрывающие '>' для html-тегов.

Выявили так: была сделана доработка, протестирована вручную под Firefox. Написан Seleinum-автотест , который был прогнан на IE - тест провалился.
Причина - не был закрыт один из тегов td из-за чего не отобразился на форме один из ключевых контролов.
Этот же тест затем провалился и на Opera.

Вопрос, на что лучше - этот "искусственный интеллект" Мозиллы, позволяющий все-таки работать с формой, имеющей мелкие недоработки, или более четкое соблюдение стандартов в IE и Opera ?

Кроссброузерность selenium-автотестов

2010-06-04T20:15:00.001+04:00

С некоторых пор мы начали процесс автоматизации функционального тестирования нашего веб-интерфейса. Проводили разведку боем. Автоматизировали определенную часть функционала и временно приостановили работы по автоматизации, для того чтобы посмотреть как этот набор тестов поведет себя в реальной жизни. НАсколько будет устойчив к изменениям в интерфейсе, насколько продуктивен в диагностике проблем. В общем спустя времени , получив результат, поняли, что очень даже стоит продолжить начатое. Первоначально все тесты прогонялись под Firefox. Сейчас же решили включить аналогичные проверки на IE. Первый пробный запуск автотестов (без какой либо переделки и доводки) показал, что существенная часть тестов не прошла , причем большая часть - из-за особенностей IE (первый прогон был на v.6.0)... Радужное настроение немного померкло, перспектива затачивать скрипты отдельно под каждый броузер не слишком впечатляет) .. Ну что же, это небольшой вызов - будем разбираться, придумывать рецепты, которыми я обязательно поделюсь!

Дни Качества в Майкрософт)

2010-04-23T14:12:00.000+04:00

В конце марта месяца 2010 посетил конференцию MS QA Days в Москве в Крылатском. Не являясь активным пользователем технологий MS ни в быту ни в работе, тем не менее нашел 2 из 4х докладов несомненно полезными для себя: первый - "Стратегические соображения о тестировании и готовности программного обеспечения к эксплуатации” (Strategic thoughts on testing and software readiness)" (Григорий Мельник) и последний - "BDD или элегантные тесты на доменную модель" (Андрей Бибичев). Второй доклад был откровенно скучным и автор явно был не совсем к нему готов, что вызывало желание поскорее дотянуть до кофе-брейка , дабы не уснуть. Третий доклад был откровенной рекламой одного из продуктов MS представителем Quest Software - живенько, наглядненько, но "мне это не подходит" (с)

Программа и видео презентации можете найти на оф.сайте мероприятия...

http://msqadays.ru/program.shtml

IE и cookie

2010-04-09T14:22:00.003+04:00

В моей тестовой лабе имеется хост для тестирования веб-интерфейса,содержащий подчеркивания в имени... В код веб-интерфейса была добавлена поддержка куков.. проверяю... В мозилле все ок, в опере все ок, в хроме и сафари тоже все ок... Один IE 6,7,8 делает вид, что куков, которые ему отправляются просто нет.. ДЕлает вид, и молчит) Ковыряюсь в настройках безопасности, разрешаю ему все что можно разрешить броузеру.. Все равно, не работает....
В итоге, оказалось, что проблема в том, что в имени хоста были подчеркивания )... То есть, IE молча решил что раз имя хоста не соответствует стандартам, то с этим сайтом можно в принципе работать... но без кукисов)))
Уж не знаю, хвалить за такое молчаливое качество IE или ругать)

Selenium RC

2009-12-02T15:58:00.000+03:00

Selenium RC (remote control) - утилита , написанная на java, основное назначение которой запускать по требованию автотеста нужный броузер и эмулировать деятельность юзера, выполняя команды этого автотеста. Благодаря java этот продукт кросплатформенный. Правда до определенной степени. Как только запущенному на Linux RC автотест "скажет" запустить IE - возможна нецензурная брань в консоли ))

Запускается север просто: java -jar selenium-server.jar

Последняя (на декабрь 2009 г) версия RC требовала джаву версии не мололже 1.5

Необходимые настройки в автотесте

Рассмотрим на примере сгенерированного Selenium IDE perl-ового скрипта:

my $sel = Test::WWW::Selenium->new( host => "127.0.0.1",
port => "4444",
browser => "*chrome",
browser_url => "test1.ru" );

то есть надо указать ip-адрес хоста, на котором должен быть запущен RC, tcp-порт на этом же хосте, тип броузера (что-то типа мнемоники) и тестируемый url.

С ip-адресом все ясно.

Порт:
Если при запуске RC явно не указать порт, то будет выбран порт 4444 по-умолчанию.

Чтобы запустить на нужном вам порту необходимо к команде запуска добавить ключ -port

java -jar selenium-server.jar -port 5555

если он будет не занят, то все должно быть ок.

Тип броузера:
*chrome - mozilla firefox
*opera - опера
*iehta - IE

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

Итак, запустили сервер RC , прописали в автотесте нужные параметры и запускаем тест на выполнение.
Если все ок - RC сам запустит броузер, выполнит команды автотеста и завершит работу броузера.
Все просто и со вкусом.

Для своих повседневных "автоматических" целей я запускаю RC на виртуальной windows-машине - исключительно из необходимости тестирования под IE. Клиентская часть (набор автотестов) периодически запускается на Linux - машинах.

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

Selenium и Perl

2009-10-29T19:47:00.000+03:00

Selenium IDE позволяет экспортировать записанный автотест в несколько популярных языков программирования. Один из них perl, который я и использую в практической деятельности.
Экспорт производится из меню "Файл"->export test case as и далее выбирается нужный язык программирования. Для экспорта в perl выбираем "Perl-Selenium RC".

Что такое Selenium RC подробно буду описывать в последующих постах. Сейчас достаточно сказать лишь, что это отдельный продукт Селениума, который представляет из себя сервер, принимающий команды из, которых и состоит скриптовый автотест.

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


use strict;
use warnings;
use Time::HiRes qw(sleep);
use Test::WWW::Selenium;
use Test::More "no_plan";
use Test::Exception;

my $sel = Test::WWW::Selenium->new( host => "localhost",
                                    port => 4444,
                                    browser => "*chrome",
                                    browser_url => "http://www.google.ru/" );

$sel->open_ok("/");
$sel->click_ok("link=Gmail");
$sel->wait_for_page_to_load_ok("30000");
$sel->is_text_present_ok("Добро пожаловать в почту Gmail");

Для того, чтобы можно было выполнить этот скрипт необходим сам интерпретатор perl и модуль Test::WWW::Selenium, который можно взять с CPANа. Этот компонент представляет из себя perl-драйвер селениумовских автотестов. Для каждого языка программирования, в который возможен эскпорт автотестов есть свой драйвер.

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

Итак, perl у нас есть, все необходимые модули для запуска.

добавляем права на запуск и выполняем скрипт : perl gmail_test_01.pl

В результате видим сообщение: Error requesting http://localhost:4444/selenium-server/driver/:
500 Can't connect to localhost:4444

Это сообщение значит то, что у нас не запущен Selenium RC - сервер, который должен принимать команды нашего автотеста.

О том как настроить и запустить RC (Remote Control) и о том, как он работает, я напишу в следующем посте...

о Selenium IDE

2009-10-26T18:30:00.000+03:00

Знакомство с продуктами Selenium лучше начинать с Selenium IDE.
Для начала необходимо установить броузер Mozilla Firefox.

Далее в меню "Инструменты"->"Дополнения" необходимо найти аддон Selenium IDE и установить его. После установки и перезапуска броузера можно начинать записывать свой первый тест.

Для наглядности пусть наш первый автотест проверяет доступность сайта gmail.com и наличие на его стартовой странице тех или иных записей.

1. Меню "Инструменты"->"Selenium IDE" - должно появиться окошко с конструктором тестов
2. откройте новую вкладку и наберите в адресной строке http://google.com
3. перейдите в IDE и заполните поле "Базовый url" значени "http://google.com"
4. начните запись теста нажатием на красный кружок
5. перейдите на вкладку с гуглом и нажмите ссылку gmail - в результате IDE должна записать нам первые команды автотеста:

open /
click link=Gmail

6. критерием успешности теста для простоты выберем факт наличия на полученной странице надписи "Добро пожаловать в почту Gmail" . Чтобы записать в тест команду такой проверки нажмите правой кнопкой мыши на надписи "Добро пожаловать в почту Gmail" и щелкните по "verifyTextPresent (....)" - это действие добавит в сценарий вашего автотеста соответсвующую команду проверки. Для первого теста достаточно проверок!)
7. Останавливаем запись теста нажатием на красный кружок.
8. Проверяем работоспособность теста нажатием на кнопку с хинтом "Play current test case" (имейте ввиду, что IDE прогоняет тест в текущей активной вкладке:) - в результате скорее всего вы увидите, что тест не прошел (красная строка "false")
В чем же дело? Ведь мы прогнали тест той же утилитой, которой его и записали!
Причина в том, что IDE записала в сценарий теста команду click, выполняя ее драйвер тестов не должидается загрузки нового содержимого броузера, а сразу выполняет следующую команду (у нас это verifyTextPresent). Понятно, что моментально страницы не грузятся даже при очень быстром коннекте, и , следовательно, на момент проверки наличия текста, его еще нет в природе (то есть , в броузере) и тест проваливается. Чтобы данный тест прошел необходимо заменить команду click на clickAndWait. Сделать это нужно вручную. Щелкаете на команде и редактируете поле "Command", заменяя строку "click" на "clickAndWait". Бага это или фича IDE? Скорее "особенность реализации", ведь в некоторых случаях нужен действительно click.

9. Прогоняем еще раз записанный тест и видим , что на этот раз он "прошел" успешно.

Отмечу, что в IDE есть возможность настройки для таймаута на загрузку страницы. По-умолчанию этот таймаут равен 30000 милисекунд. То есть, данный тест провалится , если в течении 30 сек. от гугла не удастя получить страницу с искомой надписью.

Полученный тест можно сохранять в файл и даже экспортировать в некоторые наиболее популярные высокоуровневые языки программирования: java, c#, perl. В своей повседневной рабочей деятельности я имею дело с perl , поэтому в одном из следующих постов я опишу, как программно работать с selenium , используя perl.

Записывая тесты с помощью Selenium IDE время от времени вы будете сталкиваться с тем, что не все она умеет делать автоматически и не все автоматически делает так как нужно именно вам (см. пример выше). Скажу только, что всегда можно добавлять команды вручную и всегда можно искать нужные элементы html-страниц с помощью Xpath. Для получания корректного xpath пользуйтесь расширением дополнения Firebug. Ну и если какие трудности с этим, обращайтесь - постараюсь помочь.

Файлы:
Пример теста, который можно открыть в Selenium IDE для выполнения и модификации.

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

Опыт реального применения Selenium

2009-10-22T16:05:00.000+04:00

Есть одна софтверная контора N, в которой я трудоустроен на должности QA-lead.
Основным продуктом , кормящим сотрудников этой фирмы, является некая биллинговая система на perl+Си . Она имеет веб интерфейс оператора , реализованный также на perl.
За все время существования продукта делались несколько редких и робких попыток автоматизации лишь части рутинного ручного тестирования перлового gui. Но все заканчивалось ничем. Так происходило по большей части из-за того, что веб-интерфейс , так скажем, некритичная часть нашего продукта и тратить время на автоматизацию никто не хотел. До не давнего времени...
В связи с известными фин.трудностями по всему миру у нас прошла волна сокращений.. Фронт работ не уменьшился, но штат тестировщиков уполовинился. Так как несмотря ни на что лозунг остался тот же "Качество, качество и еще раз качество" было решено взять постепенный курс на автоматизацию.. в т.ч. и GUI (гром не грянет мужик не перекрестится).
Для автоматизации GUI были выбраны продукты Selenium.
В следующих постах я буду подробно останавливаться на всех стадиях внедрения Selenium - продуктов, вплоть до инструкций по инсталляции и примеров развертывания...