Приведите пример нефункционального вида тестирования и его цель.

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

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

Пример задачи: А выдержит ли наш задротский API по поиску товаров, если его начнут дрочить по тысяче запросов в секунду, и так десять минут подряд? Не начнёт ли он в ответ плеваться пятисотыми ошибками и материться на древнеанглийском?

На что смотрим, пока система под нагрузкой стонет:

• Время отклика — сколько ждать, пока сервер выдаст ответ. Если по SLA должно быть меньше 200 миллисекунд, а он уже две секунды тупит — это пиздец, а не производительность.
• Сколько транзакций в секунду прожевывает — собственно, ту самую тысячу запросов он должен стабильно обрабатывать, а не падать на пятой сотне.
• Загрузка ресурсов — процессор не должен пылать, как сердце влюблённого подростка, память не должна течь, как сито, а сетевая карта — не захлёбываться.
• Процент ошибок — должен быть около нуля. Если каждая десятая операция — ошибка, то это не нагрузочное тестирование, а стресс-тестирование для тимлида, у него волосы выпадут.

Вот как это примерно выглядит в Apache JMeter, инструменте, который устроит твоей системе такую же встряску, как литр энергетика студенту перед сессией:

Thread Group:
  Number of Threads (users): 1000  # Тысяча виртуальных юзеров, которые будут ебашить
  Ramp-up period (seconds): 120    # Наращиваем толпу не сразу, а за две минуты, чтоб не спугнуть
  Loop Count: Forever
  Duration (seconds): 600          # И ебашим ровно десять минут, без передышки

HTTP Request Defaults:
  Server Name: api.example.com
  Protocol: https

HTTP Request:
  Method: GET
  Path: /api/v1/products/search?query=laptop  # Все дружно ищем ноуты, будто чёрная пятница

Listener: Summary Report / Graph Results  # Сюда будут сыпаться цифры, по которым мы поймём, герой наш API или говно

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

• Тестирование производительности — общая проверка, шустрая ли она вообще, или как пенсионер с тележкой в метро в час пик.
• Стресс-тестирование — это когда накидываем нагрузки больше, чем она может выдержать, и смотрим, как она красиво и с какими словами отказывает. Чтобы понять, где у неё слабое место.
• Тестирование масштабируемости — а что если добавить серверов? Станет ли лучше, или просто все они дружно сдохнут?
• Объемное тестирование — закидываем в базу данных столько информации, что она начинает поскрипывать, и смотрим, не развалится ли.
• Тестирование надежности (Soak Testing) — это длительный марафон под средней нагрузкой. Система должна работать часами, днями, не начиная течь памятью и не забывая, как её зовут. Если через сутки она потребляет оперативку, как пылесос, — дело дрянь.

Вот так вот, коротко и с матерком, о серьёзном.