Тестирование ПО. Трек от Яндекса
Курс разделен на 4 блока:
- Требования и тестируемость
- Как спроектировать проверки
- Дефекты
- Автоматизация проверок
Лекция 1. Введение в тестирование
Соответствие требованиям чаще всего не означает, что продукт качествен. Продукт может соответствовать требованиям, оставаться стабильным и проходить все тесты, но может не решать нужную задачу или быть неустойчивым в эксплуатации
У качества есть 4 основные метрики:
- Поведение - делает ли система то, что от нее требуется?
- Характеристики качества - насколько она удобна, быстра, надежна и безопасна?
- Результат использования - может ли пользователь решить свою задачу?
- Эксплуатация - можно ли обнаружить сбой и после него восстановиться?
Ведь проблема с продуктом может появиться в: составлении требований, дизайне продукта, его разработке, конфигурации и эксплуатации. Поэтому работа с качеством включает предотвращение проблем, получение информации, управление рисками и обучение на результатах и инцидентах
Рассмотрим ключевые термины
- Тестирование - это деятельность по оценке продукта и связанных с ним артефактов, направленная на выявление проблем и получение информации о качестве
- Обеспечение качества (QA, от Quality Assurance) - область, которая изучает то, как изменить способ работы, чтобы проблемы с качеством возникали реже
- Контроль качества (QC, от Quality Control) - область, которая изучает, соответствует ли полученный результат установленным критериям
Важно заметить, что обеспечение качества направлено на предотвращение дефектов, а контроль качества - на их обнаружение
- Ошибка (error) - это ошибка человека, то есть непреднамеренное отклонение от правильных действий
- Дефект (defect) - это несоответствие продукта требования
- Сбой (failure) - это наблюдаемый отказ системы
Приведем пример: форма регистрации требует, чтобы возраст человека был не меньше 18. Если пользователь вводит 18, а система дает отказ, то это может быть:
- Ошибка, если пользователь ввел свою дату рождения неправильно
- Дефект, если требуется возраст
>= 18, а в коде стоит условие > 18
- Сбой, если явно подразумевалось аналитиками, что возраст должен быть больше 18
На практике симптом редко указывает на истинную причину. Корень проблемы может лежать глубже - в коде, данных, конфигурации или даже в исходных требованиях
- Верификация - это проверка соответствию наблюдаемого поведения продукта требованиям, спецификации, архитектурным решениям и установленным критериям. Верификацией может быть ревью требований
- Валидация - это проверка на то, решает ли продукт нужную задачу, подходит ли реальным пользователям и можно ли эффективно использовать его по назначению
Рассмотрим 7 важных принципов тестирования:
- Тесты показывают наличие дефектов, но никак не их отсутствие
- Из первого следует, что проверить все дефекты невозможно. Полное покрытие тестами всех возможных дефектов в сложной системе невозможно из-за того, что число возможных состояний чересчур огромно. Поэтому нужны приоритеты того, что проверять
- Тестировать нужно как можно раньше. На ранних этапах разработки исправить дефект, который возник из требований, проще, быстрее и дешевле
- Дефекты обычно концентрируются. Связано это может быть со сложными бизнес-правилами, частыми изменениями, количеством интеграций или накопленным техническим долгом
- Тесты имеют свойство устаревать. Изменения в продукте могут изменять условия, при которых тесты хорошо работали
- Тестирование зависит от контекста. Для разных продуктов приоритеты к тому, что тестировать, разные, так как ошибки в ПО в разных областях имеют разные риски. Контекст определяет приоритет проверок и допустимый риск совершения ошибки
- Продукт без дефектов может быть бесполезен. Продукт может соответствовать спецификации, не иметь дефектов, быть стабильным, но может не решать задачу пользователя
Однако после того, как все запланированные тесты успешно прошли, какой вывод можно сделать? Можно сделать вывод, что продукт соответствует запланированным критериям качества и требованиям, но это не гарантирует отсутствия скрытых дефектов и не доказывает его полезности для пользователей. Тестирование лишь дает информацию о качестве, но не является его абсолютной мерой
Рассмотрим, как тестирование работает в различных моделях разработки:
- В каскадной модели разработки тестирование происходит после разработки всего продукта. Большинство проблем может возникнуть на этапе проектирования, что выяснится на этапе тестирования и что приведет к пересмотру дизайна и реализации. Каскадная модель чаще всего применяется для стандартизированных продуктов
- В V-модели разработка разделена на два этапа - проектирование продукта и его реализация, поэтому можно проектировать проверки до готовой реализации
- В итеративной разработке применяют итеративное тестирование. В итерациях тестирование является частью цикла, поэтому оно происходит на всем протяжении разработки
Обычно цикл тестирования проводят параллельно циклу разработки и является обратной связью для разработки:
- При разработке требований происходит их анализ, на основе которого требования правятся
- При проектировании архитектуры планируются интеграционные проверки
- Реализация дополняется динамическими тестами
- При изменении компонентов происходит подтверждение того, что измененный компонент и все смежные с ним работают корректно
- При релизе учитываются возможные риски и готовность к ним
Тесты обычно делят по уровню:
- Тестирование отдельных компонентов, таких как функции, классы, модули и так далее
- Интеграционное тестирование того, как компоненты хорошо интегрируются друг с другом
- Системное тестирование того, как система работает как единое целое
- Приемочное тестирование - то, насколько пригодна система для использования и для принятия заказчиком
Также тесты делятся:
- По цели:
- Функциональные тесты проверяют требуемое поведение
- Нефункциональные тесты проверяют характеристики качества - удобство, совместимость с браузерами, производительность, надежность, безопасность
- По способу:
- Статическое тестирование - ревью требований, кода, статический анализ кода
- Динамическое тестирование - тестирование при выполнении программы или ее отдельных компонентов
- По тест-дизайну:
- “Черный ящик” (black box) - тестирование функции как черной коробки, когда известен лишь ее ввод и ожидаемое поведение
- “Белый ящик” (white box) - тестирование функции с известной реализации
- Основанное на опыте (experience-based) - тестирование, основанное на интуиции, знаниях и предыдущем опыте тестировщика
- По отношению к изменению:
- Подтверждающее тестирование, проверяющее работу нового или измененного функционала
- Регрессионное тестирование, проверяющее работоспособность остального функционала