Тестируем IOPS на Linux

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

Недавно пришлось потестировать диски, проверить, сколько IOPS они выдают. Законспектирую результаты:

Используем утилиту fio — https://github.com/axboe/fio/releases

1) Скачать последнюю версию и распаковать и перейти в каталог

cd /tmp
wget https://github.com/axboe/fio/archive/fio-2.99.tar.gz
tar xvzf fio-2.99.tar.gz
rm fio-2.99.tar.gz
cd fio-fio-2.99

2) Должны стоять пакеты для сборки

apt-get install -y gcc make libaio-dev | yum install -y make gcc libaio-devel

3) Собираем

make

4) Тестируем

./fio -readonly -name iops -rw=randread -bs=512 -runtime=20 -iodepth 32 -filename /dev/sda -ioengine libaio -direct=1

Какие должны быть результаты:

• Средний SSD, выпущенный 2-3 года назад — 50 тысяч IOPS.
• Свежий Samsung 960 Pro, который стоит на одной из железок у нас в офисе — 350 тысяч IOPS.

Если должно быть 50 тысяч, а диск выдает сильно меньше, то:

— он не SSD;

— есть сетевые задержки;

— неправильно примонтирован;

— с ними что-то еще плохое случилось и стоит поднять алярм.

Панбагон. Период сегодня-вчера, если он длится 0 дней

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

В принципе, СДО позволяет настроить периоды выполнения тем. Ты настраиваешь так:

1. Дату начала курса (откроется первая тема)
2. Продолжительность каждой темы (2 дня, 3 дня, 4...)

Соответственно, в первый день открывается тема 1, через три дня тема 2 и так далее. Сижу, ковыряюсь, настраиваю периоды. А у нас еще есть нулевая тема, которая не идет N дней, она сразу открыта. Ну так и ставлю: duration = 0 дней. Результат позабавил 

Обратный отсчет!

Я ожидала, что дата начала будет равна дате окончания, но нет =) 

Это, кстати, классический пример теста на класс эквивалентности «Ноль-не ноль». Если у нас если числовой параметр для тестирования (период времени), обязательно стоит попробовать ноль. Что, если диапазон короче дня? 

Вот в результате теста на ноль и огребли бажик)) Давайте оформим по шаблону:

Как писать Release Notes, чтобы их читали (ВИДЕО)

Пашин доклад

Ссылка на доклад — ЛАФ, Vimeo

Мой коллега Павел Абдюшев выступил на ЛАФ 2017 с докладом о том, как у нас пишутся Release Notes. И с чего они начинались ツ

А начинались они довольно уныло. Мы осмотрелись — где что пишут? И стали писать также:

Что вы поняли из такого описания? Скорее всего — ничего. Что это? О чем речь? А главное — зачем это мне? Никто не понимал, зачем им читать этот унылый набор букв, да никто и не читал. А мы сильно удивлялись потом: как это вы не знаете, что у нас есть такая фича? Мы же писали о ней в Release Notes!

В итоге поняли, что писали заметки мы для себя. Ссылки давали на задачи — те, которые у Заказчика даже не откроются. Кратенько формулировали мысль. Нам то понятно, спору нет. А вот Заказчику эти фразы ни о чем не говорят.

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

Сейчас, пару лет спустя, наши Release Notes кажутся очевидным решением. Словно так всегда и было. Но ведь не было и мы даже не видели в этом проблемы. А ведь Release Notes — это такая же документация, как и все остальное. И мы, как тестировщики, должны их тестировать. В том числе и на понятность клиенту.

Если уж взялись писать, пишите интересно:

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

И тогда! Тогда ваши пользователи будут читать Release Notes вместо ленты котиков в фейсбуке! Аминь 

Как подключить нотификации от ТС в Telegram

У нас используется TeamCity в качестве CI — там гоняются автотесты после коммита. А еще все чаты компании переехали в Telegram.

Я как раз недавно жаловалась в чатиках: «Если назначаете меня ответственной за сборку, то лучше продублировать в личку, а то ТС спамит много». Он правда спамит, у нас есть некоторые сборки, которые запускаются редко. В итоге ты закоммитил тест в свой проект, а потом неделю получаешь оповещения на почту «Ой, тут свалился мега-редкий тест, где было 100500 коммитов, включая твой».

Оказалось, можно сделать так, чтобы тебе сам ТС писал. Да да, прямо в телеграмм 

Подготовка

Администратор ТС должен установить Telegram Notifier и создать чат-бота.

Подключение оповещений

1. Открываем телеграмм

2. Открываем меню — слева сверху кнопка

Меню

3. Пункт Contacts

Контакты

RegExp плагин в IDEA

Серия «полезные плагинчики для IDEA». IDEA — среда разработки, типа Eclipse.

Если у вас в коде есть регэксп, то как проверить, что под него подходит? Можно использовать онлайн сервисы — гуглим по «регэксп онлайн». Например, http://myregexp.com/.

Но если вы работаете в IDEA, то проще прямо в ней и проверять, поставив RegExp-плагин!

Установка

1. File — Settings

Настройки

2. Слева в общем списке выбрать Plugins. Начать вводить regexp — а вот и нужный плагин!
Справа под названием плагина будет кнопка Install, если он у вас еще не установлен

Установить RegExp плагин

Как отправить SOAP-запрос в Soap Ui

Если вы никогда раньше не слышали про SOAP-запросы, то вам сюда ツ

Давайте рассмотрим на примере, который вы можете прямо сейчас взять и повторить. Показывать я буду на системе Users, которая находится в открытом доступе. А запросы будем посылать через бесплатный инструмент Soap Ui.

Все то же самое, но в видео варианте

Отправить первый запроса с нуля

1. Запустить Soap Ui.

2. File — New SOAP Project

Создаем новый проект

3. В открывшемся окне нужно указать имя проекта и его WSDL.

• Имя — это то, что будет отображаться в левой части. Не стоит давать абстрактные имена типа "Test", иначе потом у вас будет десяток проектов с одним названием и поди угадай, где какой . Мы тестируем Users, так проект и назовем. Если было бы несколько стендов, давали бы более конкретные названия: «Users TEST», «Users PREPROD», «Users PROD»...
• WSDL — фактически это ссылка, по которой вы получаете доступ к методам. Если вам нужно проверить SOAP-запросы, просите дать вам WSDL. Получаем мы ее от разработчиков, для Users это http://users.bugred.ru/tasks/soap/WrapperSoapServer.php?wsdl

Указали название и WSDL

Отзывы на школу для начинающих — 1

В понедельник официально закончилась первая Школа для начинающих тестировщиков!

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

Но страхи были напрасны 
Абсолютно все группы справились со своими ДЗ, 16 из 20 «групповых» ребят выпустилось + половина из «индивидуалистов». Давайте посмотрим на их отзывы!

Частично отзывы есть даже в ретроспективах:

• Bug vs. Feature — первая ретроспектива
• Bug vs. Feature — вторая ретроспектива
• Russia vs USA — первая ретроспектива

А вот что пишут после всего курса (ретроспектива в середине):



Егупова Алена

Я на курсы шла с минимальными знаниями и представлениями. Нет, я конечно почитала  Савина и блоги всякие, в т.ч. и Ольги, но то что было до и после — совершенно разные вещи.
В общем-то с курсом я не ошиблась и получила все, что хотела. Вебинары сами по себе информативны, но кроме них еще даются ссылки на полезные материалы для дополнительного изучения, т.е. теории достаточно. Ну и практика после каждого вебинара, разумеется, на реальном проекте, который выбираете вы сами. Некоторые студенты отправляли баги, найденные в процессе обучения, разработчикам и их исправляли! Круто же :)
В общем для начинающих Школа — это то, что нужно, особенно если знаний теории не так много или же просто формат интенсива вам не подходит. И спасибо Ольге, Юле и Акси - вы классные :)


Анонимно

Шла на курс, думая, что будет легко, т.к. уже работала в тестировании. Но не тут то было) Первые две лекции да — известные мне вещи, ну а дальше... Узнала много нового, даже то, что казалось элементарным (регистрация багов) оказалось для меня самым сложным на курсе :) Но спасибо тренерам-терпеливо и доходчиво все объясняли :) Вообще, домашки лучше делать сразу и не откладывать, а то потом будет сложно подтянуть хвосты.
Сами лекции были очень понятны даже для человека который с разработкой ПО до этого и не был связан.


Анонимно

Мои ожидания до начала курса:

- я приобрету опыт и практические навыки тест-дизайна;
- улучшу уже имеющиеся навыки;
- узнаю больше о работе тестировщика «изнутри»;
- создам портфолио;
- доработаю резюме.

Реальность:

- навыков стало больше (было много практики);
- старые навыки "прокачались" (тренеры обращают  внимание на те детали, которые самостоятельно можно упустить по незнанию);
- "изнутри" мне понравилось, буду дальше углубляться в тестирование (у нас собралась отличная группа и сами задания было интересно делать);
- портфолио получилось достойное (оформлю красиво в Google Docs);
- резюме еще в процессе.

Не хватило:
- конкретики в формулировке заданий (но это не беда - все-таки 1й запуск курса, тренеры тоже люди)).


Александр Донсков (выпускник интенсива)