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