Показаны сообщения с ярлыком Забавное. Показать все сообщения
Показаны сообщения с ярлыком Забавное. Показать все сообщения

пятница, 16 августа 2013 г.

масдай

Вчера утром windows-7 на домашнем компьютере в очередной самообновилась, после чего запуск любого невиндового приложения приводил к ошибке 0x000005 Так как сразу было ясно , что виной всему очередной непротестированный ms-патч, то удаление всех обновлений этого утра и последующая перезагрузка с запретом дальнейших апдетов решили проблему. Не первый раз уже подобные казусы случаются а масдаевскими патчами. Поэтому становится очень интересно, в чем именно состоит технология тестирования обновлений в Microsoft ? Тестируются ли они ? Ведь бывало даже так, что ось даже не загружалась после очередного обновления. Такое сложно им отловить ? Или быть может эдакое неявное краудсорсерское тестирование и есть технология тестирования апдейтов в MS? Эта организация славится своими спецами в области qa, красивыми и живыми докладами на эту тему, различными best practice по организации процесса контроля качества ПО, но ежедневные наблюдения почему-то подсказывают, что "не все в порядке в датском королевстве"... Ведь неслучайно хакеры/исследователи радостно потирают ручки , если вдруг им удается выяснить , что на исследуемом хосте крутится именно MS windows ?

среда, 13 февраля 2013 г.

Грабли от HTML5

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

Верстальщик в отображении корзины использовал типизацию "number" для поля "количество товара". Соответственно, современный брозуер, типа Chrome пририсовал свои стрелочки к стандартному инпуту для уменьшения и увеличения значения числового поля.

Баг такой:
  1. клиент положил  в корзину товар
  2. перешел в корзину
  3. и решил накрутить количество, зажав кнопку увеличения 
  4. накручивал-накручивал так несколько секунд, пока не надоело, и отпустил...
После этого значение в поле "само"  некоторое время начало прыгать, и  содержимое страницы тоже постоянно перерисовываться. Попросили разобраться с этой "мистикой".

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

К чему это все я?


  1. разработчикам - всяческие новые "плюшки" в стандартах не отменяют обдуманного их применения
  2. тестировщикам - применяя и осваивая навороченные техники тестирования иногда можно просто "взять и сломать" по-старинке :)

понедельник, 4 февраля 2013 г.

To resolve this problem, it is best to upgrade to newer version of Internet Explorer

Уже довольно продолжительное время говорится об ущербности IE 6.0 и о том, что учитывать его "особенности" при web-разработке не стОит.

Наверное , это правильно.

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

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

Проблема зафиксирована, разработчики думают, что дальше делать...

Не знаю кто меня дернул за руку, что я полез из этого тестового IE 6 на поисковую страницу google и даже попробовать что-то там найти.. Начинаю, значит, вводить критерий поиска и получаю Access Violation по нулевому адресу.

IE приучил не обращать внимания на такие вещи , если они не повторяются... А когда повторяются, то становится уже интересно.  Этот баг повторился. OllyDbg показал на mshtml.dll - либа, отвечающая за рендеринг страниц.

Покопался  в том, что же такого криминального  в простенькой на вид страничке google.com...

Выяснилось, что причиной падения является хитрый cookie вида "search?client=heirloom-hp&hl=ru&gs_rn....&q=t" , который поисковик создает при каждой попытке поиска. Прежде , чем копать дальше и думать, чем такой баг может реально грозить, решил поискать , не сталкивался ли кто с такой проблемой до меня ... и точно, нашел... Ответ google-a убил желание копать дальше... "Обновите броузер".

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

..но почему-то не написал :)

понедельник, 24 сентября 2012 г.

Игры со временем продолжаются

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

воскресенье, 13 мая 2012 г.

Вы уверены , что хотите выполнить операцию?

На тему о том, как делать удобные приложения написано немало статей, howto, "стандартов" и так далее. С каждым днем все больше действительно качественно продуманных приложений, по-настоящему дружественных и "обходительных" пользовательских интерфейсов. Развиваемся. Радует.
Но иногда встречаются просто умопомрачительные косяки.
Чтобы не быть голословным приведу пример.
Многие, наверное, знают о нашумевшей криптовалюте bitcoin. Одной из ее особенностью является принципиальная невозможность отмены транзакции. Например , если вы переводите монеты с одного кошелька на другой и при этом ошибаетесь в номере целевого кошелька , то отменить перевод невозможно. Вы можете ошибиться так, что укажете реально существующий кошелек и тогда, маловероятно, но есть шанс вернуть , уговорив его владельца сделать обратный перевод (найти владельца будет посложнее чем иголку в стоге сена). Если ошибетесь так , что такого кошелька просто нет - то монеты просто исчезают.
При всем при этом описанное именно особенность, связанная с изначальными архитектурными принципами этой по-настоящему безопасной криптовалюты. Зная об этой особенности , разработчикам стоит проектировать и реализовывать интерфейсы для работы с этой валютой, а тестировщикам , соответственно, тестировать. Но так ли думают разработчики авторы guiminer ? Это питоновский фронтенд над питоновским же майнером криптовалюты. Занимается он тем, что "добывает золото" . Кроме того , есть у него кнопочка "withdraw", по нажатию на которую все наработанное улетает на некий кошелек. Нет предложения ввести адрес перевода, нет предупреждения о том, что монеты уйдут на такой-то кошелек (чтобы юзер мог сверить лишний раз), нет предупреждения о невозможности отменить транзакцию. Есть только обработка сабмита кнопки в виде списания монет с баланса ))
Сколько же новичков майнинга тут "полегло" ! )) Наиболее распространенные сценарии потери с трудом намайненных монет такие:
  • пользователь недавно переставил винду и потерял свой кошелек, сгенерировал новый, а в настройки адресата переводов в учетной записи пула (например deepbit.net) новый адрес своего не внес, в итого withdraw на кошелек, который никогда нигде не увидеть больше
  • пользователь отправлял биткойны в биржу , где для получения средств каждый раз генерируется новый адрес..Соответственно, при очередном переводе, забывает указать новый адрес. Результат тот же - видеокарта жгла мазут зря.
В общем..если абстрагироваться от этого печального примера, то на ответ "выводить окно подтверждения или нет" можно так:
  1. если совершаемое действие может быть легко и без последствий отменено, то можно и не предупреждать
  2. если совершаемое действие не может быть отменено, то предупреждать
  3. если речь идет о финансах и клавиатура, которая может быть разбита, то ПРЕДУПРЕЖДАТЬ да еще и с описанием всех ньюансов)

четверг, 26 апреля 2012 г.

"Везет" мне на IE в последнее время..

Буквально за пару последних дней дважды наткнулся на сообщения типа "Ваш броузер не поддерживается. Используйте IE..". Причем в приложениях довольно нужных: одно - важный интранет-портал (сделан на asp), другое - банковская веб-ориентированная система (написанная на jsp).
Если в случае ASP-шного портала запуск IE действительно помог, то банкиры удивили не на шутку.. Дословно "Ошибка: работа возможна только в IE5 и выше".
Хорошо, думаю, будет вам IE. Windows 7, думаю, IE 9. Хватит? Запускаю. Вижу "Ошибка: работа возможна только в IE5 и выше" Не смешно. На этот раз я выступал в роли не тестировщика, а обычного пользователя. Мне нужен был этот софт!)
Вот так вот. В обоих случаях, наверняка, разработка стоила кучу денег. Живо представляю себе пункт в требованиях к программно-аппаратному "Допускается работа только в IE5 и выше")) Толстые дяди с умным видом месяц согласовывали, потом подписывали, потом денежки перечисляли, потом в конверте часть назад приносили... А на дворе 21 век, а сайт работает только в IE5 , и не никак выше )))
p.s. вот найду на досуге ie5 иль эмулятор и затестирую изделие до... )

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

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



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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

пятница, 10 декабря 2010 г.

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

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

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

:D