Лекция 4. Тестирование ПО

Четвёртая лекция — про тестирование: зачем оно нужно, по каким принципам строится, на каких уровнях и какими методами проводится и какие документы после себя оставляет. Это теория к лабе по unit-тестам, а дальше — к лабе по CI/CD, где эти тесты будут запускаться автоматически на каждый push.

1. Что такое тестирование

Определение 1. Тестирование ПО — процесс проверки программы на соответствие требованиям.

Ключевое слово — требования. Тестировщик проверяет не «работает ли программа вообще», а делает ли она то, что от неё ожидают, и так, как ожидают. Если требований нет, непонятно, ошибка перед вами или так задумано.

2. Цели тестирования

• Оценить качество сопутствующих документов: требований, дизайна, кода.
• Убедиться в покрытии требований.
• Убедиться, что продукт завершён и работает так, как ожидает клиент.
• Предотвратить появление дефектов у пользователей.
• Найти ошибки.
• Дать клиенту и заказчику информацию о состоянии качества продукта.
• Уменьшить риск неадекватного ПО.
• Убедиться, что ПО соответствует требованиям государственных и юридических стандартов.

«Найти ошибки» — только одна цель из восьми. Тестирование отвечает на вопрос «насколько продукт готов», и отчёт «багов не найдено, вот что проверено» — тоже полезный результат.

3. Семь принципов тестирования

1. Тестирование показывает наличие дефектов, но не их отсутствие. Сто пройденных тестов доказывают только, что эти сто сценариев работают.
2. Исчерпывающее (exhaustive) тестирование невозможно. Даже у функции от двух 32-битных чисел $2^{64}$ вариантов входа. Поэтому тесты выбирают по рискам и приоритетам.
3. Тестирование на ранних этапах экономит время и ресурсы. Ошибку в требованиях дешевле найти на ревью документа, чем после релиза.
4. Дефекты скапливаются (defect clustering). Большая часть ошибок обычно сидит в небольшом числе модулей — туда и стоит направлять силы.
5. Парадокс пестицида (pesticide paradox). Если повторять одни и те же тесты, со временем они перестают находить новые дефекты — как насекомые привыкают к пестициду. Тесты нужно пересматривать и дополнять.
6. Тестирование зависит от контекста. Медицинское ПО и игру тестируют по-разному: разная цена ошибки, разные требования.
7. Найти и исправить все ошибки — ещё не значит обеспечить качество. Безупречная программа, которая решает не ту задачу, пользователю не нужна.

4. Уровни тестирования

Уровни рисуют пирамидой: в основании — много быстрых проверок маленьких кусков, к вершине — всё меньше проверок всё более крупных частей системы.

4.1. Модульное тестирование

Определение 2. Модульное тестирование (unit testing, компонентное тестирование) — тестирование отдельно взятого программного модуля или функции.

• Самая ранняя стадия тестирования.
• Unit-тесты — всегда автоматические.
• Покрывают отдельные функции, методы или их совокупность.
• Часто используют заглушки.
• Запускаются при сборке или компиляции программы.
• Как правило, пишутся разработчиками.

Дополнение. Заглушка подменяет то, от чего тестируемый код зависит: базу данных, сеть, текущее время. Тогда тест проверяет только сам модуль, работает за миллисекунды и не падает из-за того, что упал соседний сервис.

Пример в стиле четвёртой лабы — тесты на unittest для модуля circle.py с функциями area(r) и perimeter(r):

import math
import unittest
 
from circle import area, perimeter
 
 
class CircleTest(unittest.TestCase):
    def test_area_unit_radius(self):
        self.assertAlmostEqual(area(1), math.pi)
 
    def test_area_zero_radius(self):
        self.assertEqual(area(0), 0)
 
    def test_area_grows_as_square(self):
        self.assertAlmostEqual(area(3), 9 * area(1))
 
    def test_perimeter(self):
        self.assertAlmostEqual(perimeter(2), 4 * math.pi)
 
 
if __name__ == "__main__":
    unittest.main()

python -m unittest -v

Для дробных чисел — assertAlmostEqual, а не assertEqual: из-за округления 0.1 + 0.2 не равно 0.3 в точности.

4.2. Интеграционное тестирование

Определение 3. Интеграционное тестирование (integration testing) — тестирование, в котором программные или аппаратные компоненты собраны воедино для проверки их взаимодействия. Определение взято из стандарта IEEE 610.12-1990.

Модули по отдельности могут работать идеально и всё равно не стыковаться: один отдаёт дату строкой, другой ждёт число; один считает в рублях, другой в копейках.

4.3. Системное тестирование

Определение 4. Системное тестирование (system testing) — тестирование полной, интегрированной системы на соответствие поставленным требованиям. В нём собраны вместе все части системы.

4.4. Приёмочное тестирование

Определение 5. Приёмочное тестирование (acceptance testing) — формальная проверка, по результатам которой заказчик или другое уполномоченное лицо решает, принимать систему или нет.

5. Типы тестирования

5.1. Функциональное тестирование

Функциональное тестирование (functional testing) — тестирование функций, которые приложение должно выполнять. Бывает:

• позитивное — проверяет успешные сценарии и не подразумевает ошибок пользователя;
• негативное — проверяет ошибки, которые может совершить пользователь, и то, как система их обрабатывает.

Дополнение. Для формы входа позитивный тест — верные логин и пароль, пользователь попал в личный кабинет. Негативные — неверный пароль, пустое поле, пароль в 10 000 символов, пробел в конце логина. Негативных сценариев обычно намного больше, и именно в них прячется большинство дефектов.

В примере из раздела 4.1 нет теста на отрицательный радиус. Функция area(-1) вернёт $\pi$, как будто радиус равен единице. Ошибка это или нет — решают требования: если в них написано «радиус неотрицателен», нужен негативный тест, ожидающий исключение.

5.2. Нефункциональное тестирование

Нефункциональное тестирование (non-functional testing) — тестирование всего, что не входит в функциональное, но важно для качества системы.

6. Методы тестирования

1. Метод чёрного ящика — как система устроена внутри, неизвестно; проверяются интерфейсы: что подали на вход и что получили на выходе.
2. Метод белого ящика — устройство системы известно, и тесты строятся с учётом этой информации: по коду видно, какие ветки нужно пройти.
3. Метод серого ящика — комбинация первых двух: внутреннее устройство известно частично. Например, тестировщик проверяет через интерфейс, а результат дополнительно смотрит в базе данных.

7. Процесс тестирования

Ревью требований стоит первым не случайно — это третий принцип: ошибку в требованиях дешевле всего найти до того, как по ним написан код.

8. Требования

Определение 6. Требование (requirement) — описание того, какие функции и при соблюдении каких условий должно выполнять приложение, решая полезную для пользователя задачу.

Дополнение. Хорошее требование можно проверить. «Страница должна грузиться быстро» тестировщику ничего не говорит. «Страница загружается не дольше 2 секунд при 100 одновременных пользователях» — готовый нагрузочный тест.

9. Артефакты тестирования

Матрица соответствия — прямой ответ на вторую цель тестирования: «убедиться в покрытии требований».

10. Тест-кейс

Определение 7. Тестовый случай (test case) — пошаговое описание действий, необходимых для получения определённого результата.

Хороший тест удовлетворяет следующим критериям:

• существует обоснованная вероятность, что тест выявит ошибку;
• набор тестов не избыточен;
• тест — наилучший в своей категории;
• тест не слишком простой и не слишком сложный.

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

Дополнение. Пример тест-кейса для формы входа:

Частые ошибки

1. Считать, что тесты доказывают отсутствие ошибок. Они показывают только наличие дефектов (принцип 1).
2. Пытаться проверить всё. Исчерпывающее тестирование невозможно; тесты выбирают по рискам, классам эквивалентности и границам.
3. Гонять один и тот же набор тестов годами. Парадокс пестицида: тесты нужно обновлять.
4. Путать уровни. Модульное — одна функция или модуль, интеграционное — взаимодействие модулей, системное — вся система против требований, приёмочное — решение заказчика «принимаю или нет».
5. Считать unit-тест ручной проверкой. Unit-тесты всегда автоматические и пишутся, как правило, разработчиками.
6. Писать только позитивные тесты. Большинство дефектов — в ошибках пользователя и пограничных случаях.
7. Путать нагрузочное и стресс-тестирование. Нагрузочное — ожидаемая нагрузка, стресс — за её пределами.
8. Путать белый и чёрный ящик. Белый — устройство известно и используется, чёрный — проверяются только интерфейсы.
9. Сравнивать дроби через assertEqual. Для чисел с плавающей точкой — assertAlmostEqual.

Мини-тренажёр

1. Все 500 автотестов прошли. Можно ли утверждать, что в программе нет ошибок? Какой это принцип?
2. Команда третий год гоняет один и тот же набор регрессионных тестов, и он давно не находит дефектов. Какой принцип здесь работает и что делать?
3. 80 % найденных багов пришлись на модуль оплаты. Какой принцип и что из этого следует?
4. Проверяют, что модуль корзины правильно передаёт сумму в модуль оплаты. Какой это уровень?
5. Заказчик гоняет систему по своему сценарию и подписывает акт. Какой уровень?
6. Почему unit-тестов в проекте должно быть больше, чем системных?
7. Поле принимает целые числа от 1 до 100. Назовите граничные значения для проверки.
8. Для того же поля перечислите классы эквивалентности.
9. Сайт проверяют при 10 000 пользователей, хотя рассчитан он на 2 000. Какой это вид тестирования?
10. Тестировщик знает только API сервиса и проверяет ответы на запросы. Какой это метод?
11. Чем PRD отличается от технических требований?
12. Какой артефакт показывает, что у требования нет ни одного теста?
13. В примере тестов для circle.py нет теста на отрицательный радиус. Позитивный это тест или негативный, и что нужно знать, чтобы его написать?

Шпаргалка