← Теория
📎 Доп. материалы Из шпаргалки
Темы из твоей шпаргалки, которых не было в основных блоках
🎯 1. Тест-дизайн — техники
Specification-based (чёрный ящик)
| Техника | Что делает | Пример |
|---|
| Классы эквивалентности | Делим входные данные на группы. Проверяем по 1 значению из каждой | Возраст 0-17, 18-65, 66+ → тестим 10, 30, 80 |
| Граничные значения | Проверяем на границах классов | Возраст 18: проверяем 17, 18, 19 |
| Таблицы решений | Все комбинации условий → да/нет | Скидка: VIP + >1000₽ + промокод → какие комбинации? |
| Переход состояний | Диаграмма: из какого состояния в какое можно перейти | Заказ: Created → Paid → Shipped → Delivered |
| Use-case тестирование | Проверяем сценарии использования | Пользователь логинится → ищет товар → кладёт в корзину → оплачивает |
Structure-based (белый ящик)
| Техника | Что делает |
|---|
| Statement coverage | Каждая строка кода выполнена хотя бы 1 раз |
| Branch coverage | Каждая ветка (if/else) выполнена — и «да», и «нет» |
Experience-based
| Техника | Что делает |
|---|
| Ad-hoc | Случайное тестирование без плана (monkey testing) |
| Error guessing | Угадывание ошибок на основе опыта |
| Exploratory | Одновременно изучаешь продукт, проектируешь и выполняешь тесты |
На собе: "Основные техники: классы эквивалентности (группируем данные), граничные значения (проверяем на границах), таблицы решений (все комбинации условий). В реальной работе комбинирую."
🔺 2. Severity vs Priority
| Severity (Серьёзность) | Priority (Приоритет) |
|---|
| Что означает | Насколько баг влияет на работу продукта | В каком порядке разработчик должен фиксить |
| Кто определяет | QA | Менеджер / Product Owner |
| Уровни | Blocker, Critical, Major, Minor, Trivial | High, Medium, Low |
Severity — уровни
| Уровень | Что значит | Пример |
|---|
| Blocker | Блокирует работу, прод не работает | Приложение не запускается |
| Critical | Краш, потеря данных | Оплата не проходит, деньги списались |
| Major | Значительная функция не работает | Не добавляется товар в корзину |
| Minor | Мелкая функция, есть обходной путь | Подсказка не показывается |
| Trivial | Косметическая проблема | Опечатка, текст смещён |
Может ли быть High Severity + Low Priority?
✅ Да! Например: опечатка в названии компании на экране «О программе». Severity = Trivial, но для бренда → Priority = High.
И наоборот: мелкий баг, но влияет на 80% пользователей → Priority High, Severity Minor.
На собе: "Severity — насколько баг влияет на продукт (определяет QA). Priority — в каком порядке фиксить (определяет PO). Могут не совпадать: мелкий визуальный баг для всех → Priority High."
🔐 3. CIA Triad — безопасность
| Буква | Принцип | Что значит | Пример |
|---|
| C | Confidentiality (Конфиденциальность) | Данные видны только тем, кому положено | Пароль не виден другим |
| I | Integrity (Целостность) | Данные не были изменены без разрешения | Сумма заказа не поменялась |
| A | Availability (Доступность) | Ресурс доступен авторизованным пользователям | Сайт не лежит |
На собе: "CIA — три принципа безопасности: Confidentiality (данные видны только своим), Integrity (данные не изменены), Availability (ресурс доступен)."
🕷 4. OWASP Top уязвимостей
| # | Уязвимость | Что значит | Как тестировать |
|---|
| 1 | Injection | Вставка вредоносного кода в запрос | Ввести `' OR 1=1` в поле логина |
| 2 | Broken Access Control | Обход авторизации, доступ к чужим данным | Зайти в чужой профиль без логина |
| 3 | Cryptographic Failures | Слабое шифрование, утечки данных | Пароль передаётся в открытом виде |
| 4 | Security Misconfiguration | Дефолтные пароли, открытые порты | admin/admin работает на проде |
| 5 | Security Logging Failures | Нет логов и алертов → атаки незаметны | 100 неудачных логинов — нет блокировки |
SQL Injection — пример
Поле логина: ' OR 1=1 --
Запрос к БД:
SELECT * FROM users
WHERE login = '' OR 1=1 --' AND password = '...'
-- 1=1 всегда true → логин без пароля!
На собе: "OWASP — топ уязвимостей. Самые важные: Injection (вредоносный код в запрос), Broken Access Control (обход авторизации). Проверяю: специальные символы в полях, доступ к чужим данным."
📋 5. STLC — жизненный цикл тестирования
STLC (Software Testing Life Cycle) — 6 фаз:
| # | Фаза | Что делаем |
|---|
| 1 | Requirements Analysis | Анализируем требования, выясняем что тестировать |
| 2 | Test Planning | Планируем: что, как, когда, кто тестирует |
| 3 | Test Case Development | Пишем тест-кейсы и чек-листы |
| 4 | Environment Setup | Настраиваем тестовое окружение (стенд, данные) |
| 5 | Test Execution | Выполняем тесты, заводим баги |
| 6 | Test Cycle Closure | Отчёт, ретроспектива, архiving |
На собе: "STLC — 6 фаз: анализ требований → планирование → написание тест-кейсов → настройка окружения → выполнение → завершение (отчёт)."
⚡ 6. Виды нагрузочного тестирования
| Тип | Что проверяет | Пример |
|---|
| Load | Как система ведёт себя при ожидаемой нагрузке | 1000 пользователей одновременно |
| Stress | Где предел системы (точка отказа) | Увеличиваем до падения |
| Spike | Резкий скачок нагрузки | Чёрная пятница: 10x за минуту |
| Recovery | Восстановление после падения | Сервер упал → как быстро вернулся? |
| Volume | Работа с большим объёмом данных | БД на 10 млн записей |
| Scalability | Масштабируется ли при добавлении ресурсов | 2 сервера → 4 → 8, производительность растёт? |
| Stability | Длительная работа без утечек памяти | 24 часа под нагрузкой |
На собе: "Load — ожидаемая нагрузка, Stress — поиск предела, Spike — резкий скачок (Чёрная пятница), Recovery — восстановление после сбоя."
📐 7. INVEST — критерии хорошей User Story
| Буква | Критерий | Что значит |
|---|
| I | Independent | Независима от других историй |
| N | Negotiable | Можно обсуждать и менять |
| V | Valuable | Приносит ценность пользователю |
| E | Estimable | Можно оценить по трудозатратам |
| S | Small | Достаточно мала для одного спринта |
| T | Testable | Можно протестировать (критерии приёмки) |
На собе: "INVEST — критерии хорошей User Story: Independent, Negotiable, Valuable, Estimable, Small, Testable."
✅ 8. Требования к требованиям (6 критериев)
| # | Критерий | Что значит | Нарушение |
|---|
| 1 | Корректность | Требование технически верное | "Скорость загрузки 0мс" (невозможно) |
| 2 | Недвусмысленность | Одно толкование | "Быстрая загрузка" (что значит быстрая?) |
| 3 | Полнота | Все случаи описаны | Не указано что делать при ошибке |
| 4 | Непротиворечивость | Не противоречит другим требованиям | "Обязательное поле" но "может быть пустым" |
| 5 | Тестируемость | Можно проверить | "Система должна быть удобной" (как проверить?) |
| 6 | Понимаемость | Понятно всем участникам | Текст с кучей терминов |
На собе: "Требования должны быть: корректные, недвусмысленные, полные, непротиворечивые, тестируемые, понятные."
🔄 9. Agile / Scrum / Kanban
Agile Manifesto — 4 ценности
- Люди и взаимодействие > процессы и инструменты
- Работающий продукт > исчерпывающая документация
- Сотрудничество с заказчиком
> переговоры по контракту
- Готовность к изменениям > следование плану
Scrum — роли
| Роль | Что делает |
|---|
| Product Owner | Знает продукт, приоритизирует backlog |
| Scrum Master | Создаёт условия для команды, убирает препятствия |
| Team | Самоорганизованная команда 7-10 человек |
Scrum — события
| Событие | Что происходит |
|---|
| Sprint Planning | Планируем что делаем в спринте (2-4 недели) |
| Daily Meeting | Ежедневная встреча: что сделал, что буду, блокеры |
| Demo | Показываем результат за спринт |
| Retrospective | Обсуждаем: что хорошо, что улучшить |
Kanban vs Scrum
| Scrum | Kanban |
|---|
| Спринты | Фиксированные (2-4 недели) | Нет спринтов, непрерывный поток |
| Доска | Обнуляется каждый спринт | Постоянная |
| Лимит задач | Определяется на планировании | WIP limit (максимум в работе) |
На собе: "Работаю по Scrum: спринты 2 недели, daily, demo, retro. Kanban — непрерывный поток с WIP лимитом."
🔑 10. Hash — что это
Hash (хэш) — алгоритм, который преобразует любые данные в строку фиксированной длины (буквы + цифры).
Свойства
- Одинаковые данные → одинаковый хэш
- Разные данные → разный хэш (почти всегда)
- Необратимый: из хэша нельзя восстановить исходные данные
Применение
- Пароли: хранится не пароль, а его хэш. При логине — хэшируется введённый пароль и сравнивается
- Целостность данных: скачать файл → посчитать хэш → сравнить с ожидаемым
- Git: каждый commit = хэш содержимого
На собе: "Hash — преобразование данных в строку фиксированной длины. Необратимый. Используется для хранения паролей, проверки целостности данных."
🗂 11. Stored Procedures (хранимые процедуры)
Stored Procedure — сохранённый SQL-код, который можно вызывать многократно.
-- Создать процедуру
CREATE PROCEDURE GetUsersByCity
AS SELECT * FROM users WHERE city = 'Moscow'
GO
-- Вызвать
EXEC GetUsersByCity
Зачем
- Переиспользование: написали 1 раз → вызываетете много раз
- Безопасность: доступ к данным через процедуру, а не напрямую
- Производительность: компилируется 1 раз, потом быстро выполняется
На собе: "Stored Procedure — сохранённый SQL-код для переиспользования. Безопаснее и быстрее, чем писать запрос каждый раз."
💬 Вопросы для самопроверки