LOLWUT

Вопрос на собеседовании-

Дано - есть 59 потоков данных которые в бинарном виде падают на ftp, специальная программа забирает, преобразовывает и сохраняет в 59 таблиц.
1 поток - это один тип услуги. Примеры: 1Смс, 2звонок в дом сети, 3в роуминге, 4заказ услуги по короткому номеру. Для каждого потока 1 таблица.

Задача - 1)описать, как ты будешь тестировать. Перечислить этапы, основные идеи, направления.
2)оценить время тестирования по разработанному тестовому плану.

Задача хорошая для собеседования автоматизатора.

Уложился в 45 минут во время обеда. Поскольку письменно - на реальном собеседовании бы успел описать концепцию куда четче, написать примеры тесткейсов для валидатора + нарисовать схемы системы.

Сначала.
1. Входящие данные - 59 типовых потоков, отличающихся только параметром услуги, несложные. Уточнить спецификацию протокола.
2. Система 3х компонентная. Компонента один - генератор контента (источник потока), компонента два - хранилище, куда падают данные и джоб, который выхватывает данные и ложит в таблицы бд, компонента 3 - сама бд и структура ее таблиц.
3. Варианты приложения - хайлоад(большие потоки данных) или мелкое приложение (раз в 10 сек по какому-то из каналов пролетает пакет из 3х полей вида "вася послал смс пете".

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

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

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

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

Расчеты времени.
1) Эмулятор для бинарного протокола. Если все самому писать + функционал нагрузочного тестирования + нет доков и писавший код программист уволился - 16 часов. Если спереть код и не надо хайлоада - часа 4. Если в итоге имелся ввиду не кастомный протокол, а протобаф какой-нибудь - это час. С учетом отладки, форсмажоров и использования моих наработок - берем 16 часов.
2) Валидатор данных, он же набор автотестов. Выполняет декодирование данных, валидацию данных, поход в таблицу, валидация данных из таблицы. Для хайлоада прибавляется система сохранения промежуточных данных (в память такие объемы лучше не совать), и рандомная проверка кусков в реалтайме (опционально). Плюс скрипт для сравнения логов эмулятора(лайв приложения) с данными в бд (заодно им же можно базу на лоад проверить, если его сделать многопоточным). Плдюс время на отладку(код ревью, если есть кому). Без хайлода - 32 часа. С хайлоадом - 48 часов.
3) Стенд. Все зависит от наличия железа, админа и их вменяемости. Моих работ там на 4 часа, админа и техников ДЦ - лимит у них 32 часа времени, пока я код пишу. Если не хайлоад - за денек админ сам все поднимет, я за час свое барахло настрою. Желательно 2 стенда - один для автовыкладки приложения и прогона автотестов на нем, второй куашный для полного цикла тестов включая полноценную нагрузку.
4) CI(далее СИ). Берем СИ конторы и прикручиваем к нему свои штуки. Нет СИ и приложение хайлоад? Заканчиваем собеседование, уровень вопроса не совпадает с уровнем компании-нанимателя. 4 часа если знакомая СИ. 8 плюс помощь зала если незнакомая. Без СИ придется самому из коммандной строки свое хозяйство запускать, смотреть логи и тп - потери времени.
5) Писанина и говорильня. Написать тестпланы, показать особо умному менеджеру, дописать доки, отписать всем письма, посетить кучу очень важных митингов и прочее. Также сюда включаем походы к программистам для выяснения данных и спецификаций. 8 часов (если контора нормальная), 4 часа(если все прекрасно).
6) Непосредственно тестирование. 8 часов функционального - пересекается с пунктами 1 и 2, так как процессе написания и отладки можно(и нужно) найти много багов, и продолжая отладку их уже будут фиксить.
Функциональное - 20 минут на билд(включая интерпретацию), тестируем покомпонентно. Интеграционное еще минут 20. Лоад (синтетический, сравниваем результаты с предыдущими билдами) - 30 минут. Округляем до полутора часов на полный цикл. Первые запуски будут дольше - отладка, вагон багов и тп.
Конкретно мое время после всех зависимостей - 8 часов(интерпретация результатов, фикс багов в тест системе, походы к програмистам, работа с багтреккерами и тп).
Нагрузочное(если надо) - все зависит от конкретных значений, инфраструктуры сети, статуса приложения (уже работает, или можно перед запуском на лайв площадке провести серию тестов), количества тестовых площадок и кучи всего. Наугад скажу 32 часа в среднем, но тут реально все очень зависит от системы и прочих факторов.
7) Анализ доков и спек. Если их нет - общение с погромистами на предмет "как ваша ботва работает". 8 часов (судя по предварительному описанию задачи).

Порядок выполнения работ:
1) Анализ приложения, документации и планов по развитию приложения. Уточнение технических деталей задачи
2) Тестплан, список тесткейсов, выбить железяки для сред.
3) Пишем код эмулятора и фреймворка для валидации. Попутно даем задание админам разворачивать тестовые среды
4) Запускаем прототипы на первой подготовленной тестовой среде(если все печально - на своем компе и демо среде разработчиков) и билде приложения. Записываем вагон ошибок приложения в треккер. Правим вагон ошибок в своем эмуляторе и валидаторе.
5) По мере разворачивания сред добавляем все это(прототипы, выкладку приложения) к СИ. Проводим первые запуски. Отлаживаем тесты.
6) Расширяем функционал тестов, переносим все из тестплана в код, допридумываем забытое. Автотесты по коммиту разработчиков уже работают, и чего то находят.
7) Завершаем работы с функциональными и интеграционными тестами, если надо - прикручиваем синтетический тест билда на нагрузку (сравниваем результаты нового билда с предыдущими).
8) Нагрузочное тестирование приложения в сборе на среде, максимально приближенной к лайву(желательно на лайве перед запуском приложения в коммерческую эксплуатацию).

Итого:
Максимум (сложное, высоконагруженное приложение, кривые доки, безумные менеджеры): 132 часа(хорошее качество продукта + проверка на нагрузку + налаженная система автотестов для работы с новыми билдами).
Минимум(поделие, отсылающее пару сотен сообщений в день об оказании услуг мелким интернет провайдером): 60 часов(некоторые активности идут параллельно (хорошее качество продукта + налаженная система автотестов для работы с новыми билдами).

Риски: +16 часов для минимума, +32 часа для максимума. В основном риски заключаются в наличии документации в необходимом объеме, оценке сложности системы, человеческом факторе (админ заболел, программист уехал на Аляску в отпуск и тп).

P.S. Секьюрити специально не трогал, так как текущая задача описывает внутреннюю систему-сервис компании, где безопасность реализуется в основном администраторами (аккаунты, фаерволлы). Почему? Если от клиента к вам идет нешифрованный, неподписанный бинарный поток, который молча укладывается в табличку в базе - у вас фэйл на уровне архитектуры системы.

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

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

Мой код:

Для задания прекондишенов есть всякие штуки типа @Before и @After вообще то. Что в Джюните, что в ТестНг. Алсо концепция страниц как объектов в таком исполнении меня всегда несколько удивляла.

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

Что вы скажете, как оно на практике удобней и "правильней"? Хочу просто сразу научиться правильно тесты писать...

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

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

З.Ы. Стоит меньше заморачиваться на "правильно". А делать исключительно из соображений баланса между скоростью тестирования, покрытием и сложностью саппорта и масштабирования.

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

Если база недоступна, то сайт тоже работать не будет. Они берут данные из одной и той же БД.

Есть странна сайта hotels24.ua/hotels/гостиницы-область/Киевская/ на которой реализован функционал - Сортировка.
Необходимо протестировать правильность работы сортировок "Рейтинг" и "Звезды"
По рейтингу - после нажатия на кнопку гостиницы должни отсортироватся так что бы изначально шли все гостиницы с максимальным рейтингом потом с меньшим сеще меньшим и так далее.
По звездам - то же самое - сначала гостиницы с найбольшим количеством звезд и вниз по спадающей.

Задаа усложняется тем что как рейтинг так и количество звезд могут идти не равномерно.
Например: изначально может быть 2 гостиницы с рейтингом 10, потом 5 гостиниц с рейтингом 9,9 и после 3 гостиницы с рейтингом 9,8, а после обновления сайта могут появится 3 гостиницы с рейтингом 10 и 1 с рейтингом 9,8 а гостиниц с рейтингом 9,9 может вообще не стать.

1. Получение из БД списка отелей с заданными критериями, сохранение их в какой либо список с последующей сортировкой по звездам или рейтингу. Далее поэлементное сравнение выдачи с сайта с выдачей из базы данных.
2. Если база по каким-либо причинам недоступна - тест идет по странице/ам, проверяя то, что у текущего элемента(отеля) параметр сортировки(звезды/рейтинг и тп) ниже(или выше), чем у предыдущего элемента. Метод плох тем, что при ошибке в самой выборке из базы это не будет замечено.