пятница, 4 апреля 2014 г.

Бесплатные курсы от MongoDB

Совсем недавно успешно прошел курс MongoDB For Developers. Соответственно, небольшая ретроспектива )

Перед началом обучения у меня имелись некоторые хаотичные навыки использования MongoDB и далеко не полное понимание механизмов работы этой NoSQL субд.

На портале https://university.mongodb.com/ есть набор бесплатных курсов для разработчиков и администраторов.  Я выбрал классический - "для разработчиков" (pymongo + mongodb).

О курсе

Курс разбит на 7 недель + финальный экзамен.

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

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

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

Был даже случай, что не работала инфраструктура онлайн-обучения целые сутки. Срок сдачи очередного домашнего задания, тем не менее,  сдвинут не был. А казалось бы, форс-мажор)

Задачки в домашних заданиях тоже не сложные, очень практичные, конкретные и поучительные. Придется и в mongo-консоли повозиться и даже немного поупражняться в pymongo. С первой и до последней недели домашние задания сопровождаются "учебным проектом" - приложение для blog-a. Приложение состоит из микрофреймворка bottle.py, pymongo и самой mongodb.

На домашние задания "забивать" нельзя. Так как , если ваш средний процент выполенного станет меньше 60% , вы будете отсеяны с наступлением очередной недели (это  я лично не проверял :)

Задачки и вопросы на экзамене посложнее , чем в домашних работах, но , по-моему, тоже не слишком сложные.

Впечатления

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

Ну и несколько советов:

  1. не ограничивайтесь видео-лекциями и обязательно "курите" официальную документацию по mongo. Благо, она почти что образцовая.
  2. не откладывайте домашние задания на последний день и час - берегите нервы. В последний момент что-то обязательно помешает засабмитить результат в срок. 
  3. сразу проверьте, что в установленной у вас версии mongodb есть поддержка aggregation framework. Лично на моем debiane поставленная из репозитория монга была уж очень древняя.
  4. пользуйтесь Discussion обучалки - большинство вопросов, которые у вас возникнут , наверняка возникнут еще у кого, то и в форуме будут обсуждены и решены.
  5. запаситесь терпением - сертификат об окончании придет далеко не сразу :)

воскресенье, 30 марта 2014 г.

Как легко получить JUnit-отчеты в Django

Хороший все-таки фреймворк Django, удобный,  постоянно улучшающийся и развивающийся, отлично документированный и так далее.
Но есть у него как минимум одно место, которое некоторых разработчиков и тестировщиков не очень устраивает - это фреймворк для написания автотестов.
Разработчикам автотестов Django предлагает свой wrapper стандартного питоновского фреймворка PyUnit ( unittest ). Причем до версии django 1.6 у этой надстройки был один недостаток - довольно неудобное обнаружение автотестов (test discovey).
В версии этот недостаток устранили и мы получили возможность гибкой организации автотестов за счет более продвинутого их обнаружения джанговским запускальщиком тестов (test runner).

Но остался нерешенным еще один "недостаток". А именно невозможность "из коробки" генерировать отчеты о прогонах автотестов  в JUnit xml-формате . Это довольно странно, особенно ввиду большого числа CI-решений, которым нужен такой формат: jenkins/hudson, bamboo etc...

Для предыдущих версий django cторонние django-разработчики успели реализовать несколько приложений для решения задачи получения xml-отчета. Большинство этих приложений не работают с 1.6 версией и должны быть соответствующим образом доработаны.

Мы ждать не хотим, писать свое нет времени и ресурсов. Поэтом нам на помощь приходит никто иной как pytest. С его помощью можно генерировать junit-отчеты безо всякого изменения настроек django-проекта и без изменений в имеющихся автотестах. 

Для этого надо:
  1. поставить pytest-django
  2. для запуска тестов использовать py.test вместо django-ского  manage.py test ...
pip install pytest-django
cd /path/to/django/project
py.test --ds=DJANGO_SETTINGS_MODULE --junitxml=/path/to/junit/xml/report
Получив xml-отчет мы можем уже отображать его в любом CI-решении, которому нужен junit-формат. Например,  в bamboo  - используем встроенный компонент JUnit Parser, указав  в его параметрах , где искать xml-отчет о прогоне автотестов. Таким образом, мы можем использовать всю мощь и гибкость py.test и продолжать при этом писать тесты с помощью встроенных в django механизмов.
К слову, можно и сами django-тесты  писать в py.test - стиле. Но лично мне формат PyUnit нравится больше.

Ссылки по теме:



воскресенье, 8 сентября 2013 г.

Первые 15 минут у нового провайдера )

Сегодня от "провайдера N" приходил ко мне мастер подключать интернет+ТВ.
У меня уже есть качественный доступ в интернет-услугам, но вот захотелось посмотреть , что у других - тем более предоставляется тестовый доступ на 1й месяц.
Схема подключения - через коаксиальный кабель, модем и ТВ-тюнер (для телека). Подключение заняло минут 15 , не больше. Мастер ушел. Начался тестовый период в прямом смысле слова =)

Интернет

Единственное, что можно сразу проверить  - это соответствует ли реальная скорость обмена данными.
В тарифном плане (ТП) заявленная скорость подключения - 15 мегабит . Ну хорошо, пусть "до 15 мегабит"... Несколько повторных тестов на разных онлайн-тестерах ни разу  не показали больше 7.5 Mbit/s


В сравнении с имеющимся текущим провайдером , с его "практически честными" 20 мегабитами , новый провайдер явно не впереди.

Телевидение

Пока это обычное IP-телевидение , никакое не HDTV. Три пакета каналов в том числе и все федеральные.

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

Личный кабинет

Личный кабинет (ЛК) - это самое приятное для тестирование. Это , как обычно, веб-портальчик для управления своим сотрудничеством с провайдером.

Управление услугами

Баг вылез еще до того , как успел  толком оценить функциональность и удобство .
На скрине видим, что получается, если несколько раз кликнуть на развернутом пункте в списке меню:


Хорошо, что такие клики не приводят к реальному изменению списка услуг :) и обновление страницы восстанавливает dom.

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

Обратная связь

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

Тут же решил проверить форму "дополнить сообщение" - и там ошибки. Сабмит формы завершается следующим:
...хотя дополнительные сообщения при этом добавляются ...

Навигация с формы обратной связи тоже оставляет желать лучшего. При переходе в "обратную связь" пропадает левый сайдбар с основной навигацией ЛК. Если посмотреть на шапку, где есть хоть какие-то навигационные линки  :

то видно , что попасть отсюда можно только на главный сайт провайдера или явно выйти из ЛК. Как попасть на главную страницу ЛК - непонятно.
Пробую урезать url до корневого: https://office.operanorN.ru/ - и вижу форму с логином - то есть надо опять логиниться, хотя сессия от старого жива и продолжает жрать ресурсы сервера (бд, очистка старых сессий и так далее)... "Удобно" , ничего не скажешь.

Справедливости ради скажу, что саппорт отвечает очень шустро )

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

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

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

масдай

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

вторник, 12 марта 2013 г.

Автотесты на автотесты ?

Зачастую процесс автоматизации тестирования со временем обрастает набором своих собственных вспомогательных библиотек, надстроек, эмуляторов, заглушек и т.д., которые используются в конечных автотестах. Эти "библиотеки" могут решать совершенно разные задачи , но все их объединяет одна банальная вещь - это код, а код очень часто содержит баги.

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

Попробуем разобраться, почему так происходит...

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

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

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

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

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

среда, 6 марта 2013 г.

uml для описания тест-кейсов

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

Вот код для картинки, которая помещена выше:
@startuml
title 
Тест-кейс "Неверный пароль"
end title

participant User
participant NAS
participant Radiusd
participant DB

User    -> NAS: Start internet session with username = 'ivan' and password='007'
NAS     -> Radiusd: Access Request 
Radiusd -> DB: User authentication (check username and password)
DB      -> Radiusd: Incorrect password
Radiusd -> NAS: Access Reject
NAS     -> User: failed to establish internet connection

@enduml
 
Код успешно компиллируется plantuml-ем, о возможностях и особенностях которого расскажу в отдельной статье...

вторник, 26 февраля 2013 г.

Неплохой фаззер


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

Фаззер: uniofuzz



Написан на python. Довольно прост и в то же время универсален -  умеет генерировать рандомные файлы, фаззить tcp-соединения, пайпы и т.д.(см -help)

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

"Почти" - потому что пришлось научить ее фаззить udp вместо tcp и немного "поиграться" с длиной содержимого пакета.

Патч прост:
 
235c235
<               sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
---
>               sock=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)


Пример фаззинга (2 пакета в секунду) в сетевом соединении:

./uniofuzz.py -n -i 0.5 -ip 127.0.0.1 -port 12345 -s 9999

Утилита проста и эффективна, код открыт и прямолинеен - допилить под свои нужды - не проблема.


пятница, 15 февраля 2013 г.

Кому нужен ISO или история обесценивания

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

Водительские права? Пожалуйста - полиционер сам за тебя все кнопки нажмет при сдаче теории, разыграв спектакль "самостоятельная сдача экзамена в гибдд".
Талон техосмотра - пожалуйста! Гарантирует ли эта бумаженция то, то твое корыто не развалится по среди мкад и не пришибет кого-нибудь отвалившимся на ходу колесом? Нет. Это лишь повод заработать.

И так везде. В том числе и в сфере сертификации систем качества производства ПО.
Есть такие замечательные международный стандарты ISO 900x , в которых даны исчерпывающие рецепты того, какой должна быть идеальная СМК - расписаны ее компоненты, документы, процессы, роли. Есть и родной наш ГОСТ, в котором не меньше полезной информации для тех, кто действительно хочет вывести качество своего продукта на высокий и даже международный уровень. В общем, все есть - изучай, инвестируй, внедряй и получай результат. Но что получается на практике? Как грибы после дождя расплодились сертифицирующие органы, направо и налево раздающие красивые "сертификаты соответствия", за круглые суммы и в сжатые сроки, даже не ступая ногой на территорию предприятия. Эти разноцветные бумажки попадают в стеклянные рамочки топ-манагеров, на главные страницы сайтов софтверных фирм - вот , дескать, смотрите все ! Вот почему наш софт на 200% дроже остальных! А на деле -  в лучшем случае вся СМК состоит из одного лишь выходного контроля  в виде отдельчика или группки тестирования, которые с переменным успехом сдерживают лавину проблем, которые уходят корнями во все отделы и даже в кабинет  в топ-манеджеру , у которого на стене красивая рамочка.

Обесценивание повсюду -  во всех , за микроскопическми исключениями сферах.

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

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

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

Верю , однако, что здоровый прагматизм победит нездоровый. И это уже местами начинает прорастать и побеждать...

Показательный пример -  на собеседованиях (по крайней мере ИТ-специалистов ) все реже смотрят на диплом (если , конечно, это не диплом физтеха или мехмата МГУ :),  а все больше на опыт, на способность мыслить...  Заказчиков все сложнее заманить "бумажкой в рамке" им нужно реальное качество... Мы обесценили все эти лейблы, мы перестаем их замечать.. Проблема лишь в том, что весь остальной мир на полном серьезе учится, получает честные дипломы и сертифицируется не понарошку ...