• 1. Основы: определения, цели, принципы
• 2. V-модель, верификация/валидация
• 3. Модульное: драйверы, заглушки
• 4. Тест-кейсы и покрытие
• 5. Техники чёрного ящика
• 6. JUnit + Mockito
• 7. Интеграционное
• 8. Системное, CARAT, приёмка
• 9. Статическое: ревью, Фаган
• 10. Selenium + XPath
• 11. JMeter
• 12. Безопасность

115 слайдов · 48 минут озвучки · все 163 страницы лекций внутри — хватает одного внимательного прогона

Отказ может прилететь и от среды, не только от кода

public int countPositive(int[] data) {
    int count = 0;
    for (int i = 1; i < data.length; i++) {
        if (data[i] > 0) count++;
    }
    return count;
}

• Дефект: i = 1 — data[0] проёбан
• [−1, 5, 5] → ответ 2, верный. Дефект есть, отказа нет
• [5, −1, −1] → ответ 0 вместо 1. Вот это уже failure

Мораль: тест может пройти на дефектном коде — всё решает выбор данных

Это не страшилки — это аргумент за бюджет на тестирование

• Тестирование — поиск дефектов: реальное vs ожидаемое на конечном наборе тестов
• Отладка — локализация и устранение
• Кто путает — сидит на уровне зрелости ноль, и это хуёво

Дейкстра: «Тестирование может показать наличие дефектов, но НЕ, сука, их отсутствие»

×10 со стадией. Раннее тестирование — экономия бабла, а не занудство

SEI · Carnegie Mellon · CMU/SEI-96-HB-002

• Качество: функциональное + нефункциональное (надёжность, практичность, эффективность, сопровождаемость, переносимость) — ISO 9126, ISO/IEC 25010 (SQuaRE)
• Другие способы оценки качества: стандарты, обучение, анализ дефектов

Увеличить пользовательское доверие, что программа работает корректно во всех необходимых обстоятельствах.

• Уровень доверия: «меньше 10 критических дефектов за 7 дней»
• Корректное поведение: из требований и спецификаций
• Реальное окружение: 5000 студентов → тест на 5000-7000, а не на 10000, не выёбывайся

public long multiply(int A, int B)   // как протестировать?

• Полный перебор: 2³² × 2³² = 2⁶⁴ кейсов
• Хранить входы и выходы: ~300 эксабайт
• Прогнать на 3 ГГц CPU: ~200 лет

Полный перебор — дохлый номер даже для одной функции → классы эквивалентности и границы (блок 5)

1. Наличие дефектов, не отсутствие
2. Исчерпывающее недостижимо
3. Раннее тестирование (×10 со стадией)
4. Скопление: дефекты кучкуются
5. Парадокс пестицида: старые тесты слепнут
6. Зависит от контекста
7. Заблуждение об отсутствии ошибок: нет багов ≠ юзер доволен

Исполнять может любой; проектировать — нужна экспертиза

Поэтому исполнять может кто угодно, а проектировать — тест-дизайнер

Мониторинг смотрит, контроль рулит

Верификация — внутренний контроль · Валидация — про пользователя

• Статическое: без выполнения (ревью, инспекции, анализаторы). Можно до написания кода
• Динамическое: код запускается
• Чёрный ящик: по спецификациям, кода не видим
• Белый ящик: по исходникам — пути, условия, структура

Чёрный ящик = запуск и сравнение с эталоном · Белый = анализ путей и структуры

• Модуль: компонент минимального размера, тестируемый независимо (функция / класс / компилируемый элемент)
• Цель: изолировать кусок и показать работоспособность
• Бонусы: смелый рефакторинг, упрощение интеграции, живая документация

Нельзя тестировать заглушку, блять! 50 раз вернёт 42, на 51-й — IndexOutOfBounds

• Эмулирует вызываемый компонент: подпрограмму, прерывание, передачу данных
• Интерфейс совпадает, нутро — нет. Компилируется и линкуется как настоящая
• Простая, обычно 1 строка кода. Возможна доп. логика и чтение ответов из файла
• Настраивается драйвером перед выполнением

Тестировать заглушку нельзя! Её работа — прикидываться, а не работать

• Эмулирует вызывающий модуль — сам дёргает тестируемый код
• Сложнее заглушки: устанавливает окружение, готовит входные данные
• Дополнительно: гоняет серии тестов, настраивает заглушки, ведёт журнал результатов
• XXXunit-фреймворки — это и есть промышленные драйверы

• Программисту для разбора нужны: входы и выходы, значения изменённых переменных
• Пройденные пути и принятые решения
• Симптомы сбоя

Главный вопрос: ошибка в тесте или в ПО? Тест — тоже код, и тоже с багами

Stub = «что вернулось» · Mock = «что вызвалось». Перепутаешь — пиздец

• Тест-кейс: входы + пред/постусловия + ожидаемый результат ДО запуска
• Сценарий: последовательность кейсов (типичный + ошибочный)
• Банкомат: 3 раза неверный PIN → блок карты
• Неправильные переходы → внятные сообщения об ошибках

Сценарий = последовательность кейсов, типичное использование системы

Сценарии обязаны покрывать и корректное поведение, и вариант ошибки

Сценарии можно брать прямо из документации проекта: use-case → test-case

Принцип №2: исчерпывающее недостижимо → техники выбора покрытия

• Кейс должен быть повторяемым и автоматизируемым
• Регрессионное: после изменений — не сломали ли рабочее
• Руками после каждого коммита = ёбаный сизифов труд → автоматизация
• Помни парадокс пестицида: тесты надо обновлять

• Разбить входы на классы, тестировать по одному представителю
• Классы: валидные и невалидные
• Банкомат: купюры $100, max $2000 за раз, $10000 в день, комиссия 1% но ≥$5

Number line: invalid | 100 … 2000 valid | invalid · границы каждого класса — отдельными тестами

Баги живут на границах. < vs <= — самый частый человеческий проёб

• Комбинации условий (T/F) → действия. По сути конечный автомат

Каждый столбец = тест-кейс. Невозможные комбинации вычёркиваем

• Таблица: состояние × событие → новое состояние + действие
• Позволяет выбрать состояния и комбинации, которые можно опустить (Рекс Блэк)
• Алгоритм: пока есть непокрытые строки → берём клетку «не определено» → пытаемся покрыть тестом
• «Не определено» — самые вкусные клетки: там и живут падения

• Прецедент: ID, описание, актёры, предусловия, основной поток
• Use-case → test-case: сценарии прямо из документации
• Основной поток + альтернативные + ошибочные ветки

ViewInformationAboutTheRoute · ID: 2

• Описание: пользователь просматривает информацию о маршруте
• Актёры: клиент или любой пользователь; второстепенных нет
• Предусловия: выведен список маршрутов; авторизация не обязательна
• Основной поток: выбрал маршрут → система показала подробную информацию
• Тест: выбираем сценарий → проверяем его. Дальше альтернативные и ошибочные ветки

Стрелка перевернулась — это и есть инверсия управления

public class WhaleTest {
  private Whale whale;

  @Before public void setUp() {
    whale = new Whale();
    whale.setLocation("где-то высоко");
  }

  @Test public void testDown() {
    whale.fallDown();
    assertEquals("Кит не упал", "на земле", whale.getLocation());
  }
}

setUp перед каждым тестом → тесты независимы · первый аргумент assertEquals — сообщение при провале

@Test                         // тест
@Before / @After              // до/после КАЖДОГО (JUnit5: @BeforeEach/@AfterEach)
@BeforeClass / @AfterClass    // один раз (JUnit5: @BeforeAll/@AfterAll)
@Ignore("причина")            // пропуск (JUnit5: @Disabled)
@Test(timeout = 10)           // упасть по таймауту
@Test(expected = ...Exception.class)  // ждём исключение

assertEquals/True/Null/Throws, fail(), assertAll (выполнит все, даже если один упал)

long sum(int a, int b) { ... }
assertEquals(4, sum(2, 2));
// FAIL: "expected: <4> but was: <4>"  — ЧТО ЗА ХУЙНЯ?!

• JUnit4: 4 → Integer, sum → Long. Integer(4) ≠ Long(4)
• Фикс: assertEquals(4L, sum(2,2))

// JUnit5:
@ParameterizedTest
@ValueSource(ints = {1, 2, 3})
@CsvFileSource(files = "data.csv")

Один тест × N наборов. Класс эквивалентности = строка данных

MyService m = mock(MyService.class);
when(m.getData()).thenReturn(42);
when(m.getData()).thenReturn(1).thenReturn(2);  // цепочка
when(m.find(anyInt())).thenReturn(x);            // матчеры
verify(m).getData();                              // проверка вызова

в.26-28: техника блока 5 + параметризация + ассерты. Пример готовь свой

when(i.next()).thenReturn("Mockito").thenReturn("rocks");
i.next() + " " + i.next();                      // "Mockito rocks"

when(c.compareTo("Mockito")).thenReturn(1);     // ответ зависит
when(c.compareTo("Eclipse")).thenReturn(2);     // от аргумента

when(c.compareTo(anyInt())).thenReturn(-1);     // любой int
when(c.compareTo(isA(Todo.class))).thenReturn(0); // любой Todo

Цепочка thenReturn — ответы по порядку вызовов. Матчеры: anyInt, anyString, isA

• Интерфейсы и взаимодействие: API, сообщения, БД, GUI, сеть
• Можно начинать с 2 готовых компонентов
• Сложные компоненты первыми, регрессия после каждого этапа

• Модули добавляются в сборки по готовности, заглушки выбывают
• На каждый интерфейс — короткий тест-план. Больше объём интеграции — больше сложность

Big bang — самая ебанутая: ошибку не локализовать

• Слоями вниз: UI → бизнес-логика → хранение; низ — заглушки
• + быстро появляется «осязаемое» приложение · − дохуя заглушек

• Начинаем с нижних модулей — вплоть до железа (HW, карты)
• Сверху вместо ещё не готовых модулей — драйверы
• Поднимаемся: драйверы по очереди заменяются реальным кодом
• + фундамент (библиотеки, железо, БД) проверен рано
• − целое приложение появляется в самом конце

1. Сложные компоненты — первыми: снижает риски, больше времени на фиксы
2. Порядок интеграции — с учётом порядка разработки
3. Регрессия после каждого этапа интеграции
4. Автоматизируй тесты
5. Можно гонять и нефункциональные характеристики

Методики практически одинаковые — различается строгость интерпретации результатов

• Тестирование — как научный эксперимент: нужно повторение → автоматизация, скриптинг
• Результаты — в журнал; на каждый дефект — инцидент; периодические отчёты
• Окружение максимально близко к боевому: железо, ОС, сеть, тайминги
• Тестеры исполняют роли реальных юзеров, скрипты — реальные сценарии
• Сначала верификация, потом валидация. В основном чёрный ящик

Идём от простых сценариев к сложным — нет смысла грузить систему, у которой не работают кнопки

• Работают ли основные функции системы вообще
• Один пользователь, одна транзакция
• Корректный ввод: от юзера, из файлов, из БД
• Нормальные переходы между состояниями, «среднее» железо
• Положительные проверки подсистем безопасности

• Реалистичнее: несколько юзеров одновременно, данные всё ещё валидные
• Реальные последовательности транзакций; несколько транзакций от одного юзера
• Длительный запуск: утечки памяти, переполнение диска

• Юзеры вводят хуйню — система обязана выжить и внятно ответить
• Сбой сети, испорченные файлы
• Неправильные переходы между состояниями, операции в неправильном порядке
• Аварийное отключение систем и подсистем
• Намеренные ошибки безопасности: плохие пароли, внешний взлом

• Функционирование в разных средах
• Взаимодействие с локальными и удалёнными системами
• Разные версии: библиотек, браузеров, операционных систем

• Системное: вся система, чёрный ящик, окружение как боевое
• Лестница: возможности → стабильность → отказоустойчивость («Let's break it!») → совместимость → производительность

• Альфа внутри · Бета внешние · Приёмка: юзер рулит, «платим или нахуй»

К_г = (MTBF − MTTR) / MTBF

• MTBF — среднее время между сбоями · MTTF — до сбоя · MTTR — восстановления
• Пять девяток 0,99999 = ≈5,3 минуты простоя в год. Посчитай сам: 525960 × 0,00001

• Throughput: транзакций в секунду; всегда баланс с временем отклика
• Response time: от «нажал» до «загрузилось»; мерить под минимальной, расчётной и пиковой нагрузкой
• Стресс-тест: последовательно грузим систему до неприемлемого времени отклика
• Capacity: максимум юзеров/записей/файлов одновременно, не нарушая остальных требований
• Accuracy: корректность алгоритмов и результатов — критична для целого класса систем

• Небольшая группа пользователей внутри организации, разработавшей ПО
• Может проводиться до окончания системного тестирования
• Цель: ранние отзывы об использовании системы в рабочем окружении

• Выбранная группа внешних юзеров в своём окружении. Windows Beta — весь мир
• Баги допустимы, функционал может быть неполный. Превью юзерам + отзывы разработчикам
• Неформально: нет сценариев и планов — тыкают что интересно, репортят что сломалось
• Фиксы не гарантированы сразу: в финальном релизе или в следующей бете

• Ключевой аспект: управляется пользователем, а не разработчиком
• Проверка «соответствия предназначению и практическому использованию». Формальное или нет
• Источник — документ «требования к системе» (в RUP — SRS); функциональные + нефункциональные
• Подготовка с ранних этапов, можно статически. Окружение полностью готово — может быть первый боевой запуск
• Юзеров выбирать ответственно и обязательно обучить

• Динамике нужен код; статику можно до первого коммита
• Цена ошибки растёт ×10 со стадией → ловим рано, экономим
• Объекты: политики, стратегии, планы; ТЗ и спецификации; артефакты проектирования, код; планы тестирования
• IEEE 1028: неформальное ревью («звонок другу»), технический анализ, management review, сквозной контроль, инспекции

Зачем: люди ошибаются, «вторые мозги» видят то, что автор уже не видит. Неформальное ревью малоэффективно — формальные методики лучше

Можно ДО написания кода (IEEE 1028)

• 1972, IBM, Michael Fagan. Систематическая peer evaluation
• Роли: менеджер, модератор, докладчик, автор, эксперты, секретарь. Ведущий — не автор, блять
• Шаги: вход → планирование → обзор → подготовка → обсуждение → переработка → follow-up → выход
• Встреча ≤ 2 ч. Max 2 проблемы. Решение: принят / переработка / отклонён

Повторяется, пока все участники, включая модератора, не удовлетворены

• Критерии входа проверяет ведущий — не тратить время неподготовленной встречей
• Примеры входных: чеклисты готовы; базовые документы вышли из инспекций с известным уровнем ошибок; ≤1 дефект за 10 минут пробной проверки; грамматика проверена
• Планирование: check rate (скорость проверки), разбиение на «куски», метрики (размер, дефекты, цена изменений, время), расписание
• Выходные критерии: документы согласованы → артефакт уходит в систему контроля версий

• Чеклист — проверка по списку
• Документы — целостность между доками
• Фокус — поиск выделенных проблем
• Перспектива — роль будущего юзера
• Процедура — следование особой процедуре
• Сценарий — заданный сценарий (специфичнее)
• Стандарт — соответствие стандартам
• Точка зрения — например, пользователя

Человек фокусируется максимум на двух проблемах одновременно — потому и роли

• Обсуждение — сердце инспекции. Протоколирование результатов подготовки даёт ещё 10-20% проблем
• Формат проблемы: id, severity (Major / minor), описание, документ, страница
• Ведущий: дипломатичен, краток, категоричен; глушит дискуссии; вправе удалить участника или остановить встречу
• ≤2 часа. Решение: принят / на переработку / отклонён
• Переработка: автор, редактор или другие. Инспекция не закрыта, пока не выполнены выходные критерии

• Код без запуска. Lint (C), FindBugs/SpotBugs (Java)
• Находит: неинициализированные переменные, fopen без fclose, переполнение буфера, копипаст
• Безопасность: Find Security Bugs. Базы: CWE Top 25, OWASP Top 10

• Интегрированная среда записи и исполнения тестов; родилась как расширение Firefox
• Запись тестов в виде Java, Ruby, HTML
• assert/verify добавляются правым кликом на элементе во время записи
• Ограничения: только Firefox; слабая логика (циклы, условия); запускает только свои сценарии; динамический контент — боль

• Действия: open, click, type, select, store
• verify упал → тест ЖИВЁТ. assert упал → тест СДОХ. Не проеби
• Синхронизация: waitForPageLoad, waitForAlert, waitForTitle

verifyTextPresent      текст есть на странице
verifyTitle            заголовок страницы
verifyElementPresent   элемент существует
verifyValue            значение поля

store   значение → переменная, дальше ${var}
echo    запись значения в лог selenium

assert-версии — те же проверки, но валят тест. wait*** — ожидание событий (page load по таймауту, alert, table, title)

driver = new FirefoxDriver();
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);

driver.get(baseUrl);
driver.findElement(By.id("search-field")).clear();
driver.findElement(By.id("search-field")).sendKeys("селениум");
driver.findElement(By.id("search-button")).click();

Локаторы: By.id, By.name, By.xpath, By.cssSelector · implicitlyWait — неявное ожидание элементов

• Сервер на Java, работает как прокси для web-запросов совместно с WebDriver каждого браузера
• Кросс-браузерное тестирование, много языков; плагины к NetBeans и Eclipse; запуск через maven и ant
• jar-ы в проект: junit, selenium-java-client-driver, selenium-server, testng
• Grid: масштабирование на разные ОС и браузеры, параллельный запуск экономит время

/   от корня        //  где угодно
.   текущий          ..  родитель
@   атрибут          []  предикат         |  объединение

• Оси: child::, parent::, self::, following::
• Динамический ID — зло: //div[contains(@class,'heading')]

• Множества: count, position, last, text
• Строки: contains, starts-with, string-length, matches
• Логика: true, false, not, boolean
• Числа: sum, round, number, ceiling, floor
• Системные: document, format-number, generate-id

Пример: //tr[position() > 1]/td[2] — вторая ячейка всех строк кроме заголовка

• HP LoadRunner
• LoadComplete
• IBM Rational Performance Tester
• LoadUI Pro
• Apache JMeter
• The Grinder, Tsung

Почему JMeter: бесплатный, кроссплатформенный, GUI с графиками, распределённая нагрузка, эмуляция юзеров, метрики, плагины

Планы в XML → нормально живут в системе контроля версий

НЕ БРАУЗЕР, БЛЯТЬ! Протокольный генератор: 1 поток = 1 юзер, планы в XML

Config → Pre → Timers → Sampler → Post → Assertions → Listeners · Распределёнка: jmeter-server + remote_hosts

• Thread Group: пул виртуальных юзеров — количество, возрастание (ramp-up), длительность
• Семплеры: формируют запросы, генерируют результаты
• Протоколы из коробки: TCP, HTTP(S), FTP, JDBC, SOAP, JMS, SMTP…
• Умеет записывать запросы (прокси-рекордер): функциональный тест → нагрузочный в том же плане

• Слушатели: получают ответы, пишут и показывают. Данные НЕ обрабатывают в CLI — графики только в GUI
• Таймеры: задержки между запросами — постоянные или по законам распределения
• Assertions: проверяют результаты (код ответа, текст, длительность — SLA)
• Конфиг-элементы: предустановки для семплеров · Пре/пост-процессоры: например, HTML Link Parser

• Автоматическая генерация CSV с результатами
• Bandwidth throttling: ограничение полосы — статически (CPS) или динамически (по error rate)
• IP spoofing: подмена src IP для разделения клиентов — проверка балансировщиков нагрузки
• TPC-C: стандартный тест OLTP-нагрузки

ЛР4: SLA p90 ≤ 700 мс → конфиг №2 ($1800, p90 = 576) · стресс: SLA пробит на 16 юзерах, массовые 503 при ≈149

• Фокус: безопасность функциональности, политики, поведение атакующего, известные уязвимости
• Цифровые активы: данные, код, ключи, репутация
• Экспозиция риска = f(вероятность, ущерб)

• Что воруют: данные юзеров, бизнес-планы, код и документация, торговые секреты, финансы, переписка, прототипы, репутация и доверие
• Как лезут: корпоративный LAN и WiFi, VPN из публичных сетей, физика (DVD, USB), почта и мессенджеры
• Защита: шифрование (криптостойкость, алгоритмы), аутентификация и токены (сертификаты, политики паролей), авторизация и права доступа

• Устанавливаются административно. Примеры:
• Приемлемое использование, минимальный уровень доступа, управление аккаунтами
• Классификация информации: публичная / ДСП / секретная / частная
• Безопасность серверов и мобильных устройств, физический доступ
• Реакция на инциденты, мониторинг, защита от «закладок»

• Методы: статанализ + фаззинг + пентест
• Стандарты: SEI CERT, OWASP, Microsoft. Базы: CWE, OWASP Top 10
• CERT Top 10: проверяй входы · слушай компилятор · политики · KISS · default deny · мин. привилегии · санитизируй · defense in depth · тестируй · стандарты

char hostname[64];
validate_addr_form(user_supplied_addr);  // формат ок, но...
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr(addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);  // 💥 h_name длиннее 64 байт

• CWE-119: запись за границей буфера → перезапись стека → выполнение чужого кода
• Бонус-дефект там же: gethostbyaddr может вернуть NULL → CWE-476 NULL pointer dereference

// PHP
$username = $_GET['username'];
echo '<div>Welcome, ' . $username . '</div>';

// атака:
welcome.php?username=<script>alert("You've been attacked!")</script>

• Вывод юзерского ввода без экранирования → скрипт исполняется в браузере жертвы
• Лечение: экранирование вывода (htmlspecialchars), CSP. Тренажёр: alf.nu/alert1

query = "SELECT * FROM items WHERE owner = '" + userName +
        "' AND itemname = '" + ItemName.Text + "'";

// ввод: name' OR 'a'='a
SELECT * FROM items WHERE owner = 'wiley'
  AND itemname = 'name' OR 'a'='a';   // весь WHERE по пизде

Лечение: параметризованные запросы / prepared statements. Конкатенация SQL со вводом — преступление

Пентест = легальный хакинг. Без договора это статья, а не пентест!

DAST: OWASP ZAP, Burp Suite, Nikto, w3af · Гибрид = IAST

• Важны на стадии продакшена для известных движков: WordPress, Joomla, Drupal
• Ищут только известные уязвимости
• Чужое сканировать незаконно — только с письменным разрешением!
• Коммерческие: Rapid7 Nexpose, Paessler PRTG… Open source: OpenVAS, OWASP-набор, WAVSEP

• Процесс обычный: планирование (сфера по рискам) → анализ и проектирование (угрозы из аудита требований и известных уязвимостей) → выполнение (взгляд внутренних и внешних юзеров, взломщиков) → отчёты → интеграция в разработку
• Waterfall, боль: требования безопасности меняются, но не отражаются в доках; тесты в конце проекта; чинить найденное дорого
• Agile: потребности возникают прямо в спринте; подходы могут меняться полностью; тесты идут весь проект; стратегия избегания риска может не успеть за один релизный цикл

• Hardening: убрать лишнее, добавить защитное ПО. Аудит: пароли по умолчанию, лишняя конфигурация, дыры в библиотеках
• Аутентификация и авторизация — самый ломаемый модуль: брутфорс паролей, фильтры ввода (XSS, injection), доступность URL. Шифрование: дизайн, код, конфигурация

• Брандмауэры и зоны: сканирование портов, битые пакеты, dos/ddos, фрагментация
• Обнаружение взлома (IDS): инвазивные изменения данных и сообщений
• Антивирус: реальные вирусы не нужны — тестовый файл EICAR
• Обфускация данных: реверс-инжиниринг, брутфорс (unXOR)

• Mistake→Fault→Failure→Error + Дейкстра
• 7 принципов · V-модель
• Драйвер vs заглушка
• stub=state, mock=behavior
• assertEquals(4,...) → 4L
• Фаган (роли, ≤2ч)
• verify живёт, assert дохнет
• XPath оси + 5 групп
• CARAT + (MTBF−MTTR)/MTBF
• 3 вида фаззинга · XSS/SQLi

Вопросы 21-40 — с примерами!