t.me/atinfo_chat Telegram группа по автоматизации тестирования

АПИ: нагрузочные тесты и тесты безопасности

#1

Хорошо, конечно, много читать теории, но очень хочется услышать практиков.

Вообщем, помогите :

Ситуация: Разрабатывается продукт, исключительно API и тестируется одним тестером, тоесть мной. У разрабочиков всё агильно. Код…унит…интегрейшн. Я мануально и немного автомат в Постман. И тут приходит идея, что надо организовать отдел тестирования, набрать людей в штат, чтобы разгрузить разработчиков.

  1. Читаю теорию и все пишут, что тесты безопасности и нагрузочные лучше всего, делать уже во время разработки, чем перед продакшн. И вот вопрос, кто-то на практике так реально делал или делает? Как это выглядит? Мой опыт был только, монолита и перед продакшн мы отдавали код фирме, получали рапорт и уже фиксили. А как с АПИ быть? Какие метрики нагрузки можно тестировать пока разработка в процессе? И что тестировать в безопасности?

  2. У продукта, есть Machine Learning. Кто-то сталкивался, как делать нагрузочное тестирование такой системы? Или может кто-то саму Machine Learning использовал для тестирования нагрузки в продукте?

Очень надеюсь, что сможете разьяснить.

#2

Интересно: что вы хотите тут услышать в ответах?
Тестировать можно все на любой стадии разработки, в нагрузке для начала измерять капасити по клиентам, в безопасности тестировать безопасность (ключи, токены, корсы, аутентификацию).
Нагрузочное тестирование для МЛ ничем не отличается от любого другого нагрузочного, это не божественная сущность, которой надо сначало жертву принести, а потом нагружать.
Нахрена создавать “отдел тестирования” для этого - непонятно, когда условные 2 человека могут описанные в топике задачи; если экспертизы не хватает у имеющихся кадров - они заменяются на подходящие (не мог я обойтись без колкостей, признаю)

#3

Почему фокусировка исключительно на нагрузке и секьюрити?
Я бы предложил использовать следующие подходы:

  1. Функциональное тестирование. Если unit и интеграционные тесты есть - то фокусироваться на end-to-end сценариях. Используемые инструменты: Java + RestAssured / Groovy + Spock (если не боимся кодить), Postman / SoapUI (если боимся).
  2. Нагрузочное тестирование. Scala + Gatling (если не боимся кодить), LoadUI (если боимся).
  3. Секьюрити тестирование. Java / Groovy (если не боимся кодить) / SoapUI с паттернами (если боимся).

Попробую ответить на вопросы.
Как тестировать во время разработки? Очень просто. Тесты должны иметь возможность смотреть на любое окружение. Таким образом, разработчики выкладывают новую версию на integration env, к примеру. У Вас есть метрики предыдущего прогона и контрольные метрики с предыдущего спринта. Вы запускаете тесты и смотрите на метрики текущего прогона. Если ухудшения или улучшения - отмечаете.
Метрики нагрузки? К примеру, время прохождения сценария под нагрузкой (1, 10, 100, …) пользователей, равномерность ответа сервисов при фиксированной нагрузке N времени (к примеру, час), метрики загруженности процессора / памяти во время прогона, да много чего можно придумать. Вопрос в том, какие из них будут полезны. Так я не подскажу, надо начинать с чего-то, дальше по мере получения метрик можно понять, какая информация оказалась полезной, какая - нет и чего не хватает, чтобы точнее понять состояние билда.

#4

у заказчика тестирования спросите, чего он вообще от вас, как от тестировщика, хочет? наверняка вскроются какие-то нюансы, несвязанные с теорией и практикой

#5

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

  1. Функциональные, да. Процесс: разработчик пишет код и юнит и интегрейшн тесты. Я в тестовой среде, используя Postman тестирую.
  2. Почему именно Gatling или LoadUI? Я тут нашёл, что есть K6. По описанию он типо крут в связке с Postman. Просто да, код это совсем не моё.
  3. Почему секьюрити через Soap?
    Просто у кого коллег не спрошу, то всё тоже в организациях, где на каждый вид тестирования свой отдел. А так как я один пока, то руководство ждёт от меня решения: KAK мы будем тестировать и КТО нам ещё нужен, чтобы было качество. И получается, что предложить можно только теорию.
    Вопрос: а как понять, какие метрики нужны? В прошлом проекте, всё было понятно, клиент сам говорил, что им важно.
#6

Вот, очень хорошо :slight_smile: Кто они-эти подходящие кадры?
Как я могу быть уверен, что они протестируют секьюрити? Искать отдельно пенетрейшн тестера? Или любой тестер может протестировать и всё? Или перед продакшн всё-таки, ещё кто-то независимый тестирует?

#7

Базовые вещи типа OWASP top10 может покрыть кто угодно, было бы желание разобраться, в большинстве случаев (но не во всех, см. ниже) этого будет достаточно.
Чтобы захайрить подходящие кадры - надо иметь хотя бы поверхностную экспертизу в вопросе, дабы отсеять мух от котлет; если опыта нет, то какие тут могут быть еще советы, можно перекреститься, плюнуть через левое плечо и хайрить наугад, авось проканает.
Перед продакшном отдают в 3и руки “на пере-пере-проверку”, имхо, в 2х случаях: когда проект очень дорогой, или сэкономили на собственных кадрах; в общем “умная голова” должна оценить риски и принять решение “надо ли”

#8

Ну и не надо. Займитесь теми видами тестов, которые понимаете. Разберётесь с ними, настроите процесс, будет свободное время - почитайте OWASP и займётесь пенетрацией и секурити. Лучше иметь работающие тесты, пусть и неполные, чем плохо работающие всех типов.

Потому что имел с ними опыт и могу точно сказать, что это - работает. Хотите юзать K6 - флаг Вам в руки :slight_smile: Может, оно работает даже лучше предложенных мной вариантов. Не забывайте, ответственность за принятые решения нести лично Вам :wink:

Опять-таки, потому что видел у них рабочий вариант. Есть решения, лучше подходящие под Ваш продукт и Вы в них уверены - вперёд :wink:

Оу… У Вас есть шанс нарваться на лекцию. Возможно, даже не на 1 :slight_smile:
Вообще неверно. Теория руководство не интересует от слова совсем. Вам необходимо сделать следующие штуки:

  1. Понять, что такое “качество” в глазах стейкхолдеров.
  2. Поняв, что необходимо - провести инвентаризацию того, что есть. Не исключено, что 99% того, что нужно - уже есть в той или иной форме, просто об этом никто не знает.
  3. Сгенерировать временнЫе оценки того, чего нет с учётом роста продукта.
  4. Рассчитать кол-во QA инженеров в команде, чтобы техдолг уменьшался. В идеале - рассчитать оптимистичный и пессимистичный сценарий с учётом рисков для инженеров соответствующей квалификации.
  5. Вывалить это всё на руководство.
  6. Получить карт-бланш на найм X людей в команду.
  7. Провести Y > X собесов, нанять необходимых людей. В процессе проведения собесов прокачать теорию, чтобы отличить балаболов от специалистов :wink:
  8. Нанять необходимых людей в команду.
  9. Научиться их лидить и настроить процессы.
  10. Профит :wink:
1 Симпатия
#9

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