Открытый семинар для студентов в компании CUSTIS (3 апреля 2014 года).
Лектор: Владислав Иофе, руководитель группы в отделе технологического развития.
Аннотация: Тестирование — один из самых важных процессов обеспечения качества ПО. На этом семинаре мы разберемся, что такое тесты, зачем они нужны и какими они бывают. Мы рассмотрим случаи, когда нужны автоматические тесты, поговорим о том, какие для этого есть инструменты, а также ответим на насущный вопрос, кто должен заниматься написанием тестов. А во второй, практической части семинара мы попробуем отловить дефекты небольшой программки при помощи тестов.
Видеозапись семинара: https://vimeo.com/91396326.
Собираем кубик Рубика: восстановление архитектурного описания корпоративной р...
Тестирование ПО: баг не пройдет!
1. 3 апреля 2014 года
Тестирование ПО:
баг не пройдет!
Владислав Иофе
Руководитель группы в отделе технологического развития
2. На сегодня
Что такое тестирование? Зачем нужно тестировать?
Классификация
«Ящик», уровни и назначения
Артефакты тестирования
Профессии тестировщика и QA
Автоматизированное тестирование
Тестирование через GUI и тестирование кода
XP, TDD
Болезни и best practices
Практика
2/95
4. О себе
В 2005 окончил мехмат
Ташкентского государственного университета
С 2004 занимаюсь корпоративным
программным обеспечением
Работал разработчиком, тимлидом
и техлидом
В 2008 пришел в CUSTIS
Сейчас руководитель группы в отделе
технологического развития
4/95
20. Качество ПО
Качество продукта – функция от того,
насколько он изменил мир в лучшую сторону
Том ДеМарко
20/95
Не очень конкретно?
Качество – отдельная большая тема.
Как минимум, можно говорить
о качестве с точки зрения пользователя
(удовлетворение потребностей),
с философской точки зрения
(достижение некоего идеала),
с точки зрения производства продукта
21. Качество ПО (продолжение)
Аспекты качества:
Надежность (Reliability)
Сопровождаемость (Maintainability)
Стоимость внесения изменений
(в т. ч. исправления дефектов)
Наблюдаемость системы
Эффективность (Efficiency)
Производительность
Удобство использования
Функциональность
Некоторые из этих
аспектов помогают
обеспечивать
тестирование
21/95
22. И снова: что такое тестирование?
Процесс формальной проверки
и подтверждения (верификация и валидация)
того, что ПО:
отвечает предъявляемым требованиям
удовлетворяет нуждам интересантов
работает, как ожидается,
или может быть сделано с заданными
характеристиками
22/95
28. Классификация:
статика vs. динамика
Статическое тестирование
(без исполнения программы) направлено
на верификацию
Проверка синтаксиса IDE
Code review
Статический анализ кода
…
Динамическое – может быть направлено
на валидацию
28/95
29. Классификация: принцип ящика
Метод тестирования белого ящика
проверяет внутренние структуры и логику
работы тестируемого фрагмента.
Необходим для:
Локализации сложных ошибок
Обеспечения требуемого покрытия кода
Метод черного ящика подразумевает
наличие информации только
о требованиях к тестируемому фрагменту
(например, входных и выходных данных)
29/95
33. Классификация: уровни и V-модель
Анализ
требований
Детальный
дизайн
Кодирование
Интеграционное
тестирование
Системное
тестирование
Приемочное
тестирование
Модульное
тестирование
Дизайн
системы
Архитектура
Тестирование
и интеграция
Детализация
проекта
Время
34/95
39. Артефакты тестирования:
пример с бронированием билетов
Пользователь находится
на последнем шаге –
подтверждении бронирования.
Нажимает кнопку, в ответ:
Бронь успешна,
маршрут-квитанция
в почте
Места по тарифу
закончились
Сессия истекла
…
40/95
45. Профессии тестировщика и QA
QA (Quality Assurance, обеспечение
качества) – это процесс формирования
и поддержания требуемых характеристик
качества ПО по мере его создания
и сопровождения. QA захватывает все
стороны создания ПО: сбор требований,
проектирование, тестирование,
интеграцию и т. д.
Тестировщик ≠ QA-инженер
49/95
47. Кто тестирует?
В разных командах и компаниях сильно
по-разному
Бывают выделенные тестировщики
В CUSTIS на трех разработчиков
приходится один инженер, который
занимается:
аналитикой
тестированием
внедрением и поддержкой
51/95
50. Автоматизированное тестирование
Для тестирования используется отдельное ПО
(не то, что тестируется)
Сложность
Требования
к квалификации
Тоже требуется отладка
Дорого в поддержке –
кодовая база вырастает
вдвое
Надежность
Повторяемость
Повторное использование
Контроль регрессии
Разные конфигурации
Скорость
Возможность одновременного
запуска на разных машинах
Рефакторинг безопаснее
54/95
51. Автоматизированное тестирование
через GUI
Тестировать вручную через GUI все равно
нужно!
Как минимум, приемочное тестирование
Но очень много повторяющихся рутинных
действий
Надо их автоматизировать!
Пример…
55/95
53. Extreme Programming (1999)
Методология разработки,
направленная на повышение доверия
заказчика и качества ПО
Среди практик:
Test First
Парное программирование
…
Кент Бек
58/95
56. Best practices
Не пытайтесь тестировать все
Тест должен быть простым
Интеграционных тестов не должно быть
очень много
Тесты не должны зависеть друг от друга
62/95
57. Best practices
Пишите тесты как для корректных,
так и для некорректных входных данных
Пишите тест как на положительные,
так и на отрицательные сценарии
Запускайте тесты как можно чаще.
Используйте Continuous integration
Пишите тест до кода. Или пусть тест
напишет хотя бы не автор тестируемого
кода
63/95
60. Анекдот: подход
Two software testers went into a diner and
ordered two drinks. Then they produced
sandwiches from their briefcases and started
to eat. The owner became quite concerned
and marched over and told them, “You cannot
eat your own sandwiches in here!”
The testers looked at each other, shrugged their
shoulders and then exchanged sandwiches.
66/95
61. Анекдот: тестирование с умом
У авиаторов был замечательный прибор для испытания
на прочность авиационных стекол. Прибор представлял
собой пистолет, выстреливающий «ножку Буша»
в лобовое стекло с крейсерской скоростью самолета.
Если стекло не трескалось, считалось, что настоящее
столкновение с живой птицей тоже пройдет успешно.
Железнодорожники решили позаимствовать опыт
при испытании лобового стекла локомотива.
Но у них почему-то цыпленок не только пробил лобовое
стекло, но повредил двигатель. Железнодорожники,
естественно, побежали к авиаторам выяснять,
все ли было сделано правильно.
Ответ был прост: «Разморозьте курицу».
67/95
62. Анекдот: об ответственности
На одной конференции участникам задали
неудобный вопрос: «Вы только что оказались
на борту самолета и вдруг узнали, что ваша
команда была ответственна за разработку
ПО самолета. Кто из вас немедленно сойдет
на землю?»
Среди леса поднятых рук только один человек
оставался спокоен. Он прокомментировал
это так: «С нашей программой самолет вряд
ли даже вырулит, не говоря уже о взлете».
68/95
67. Шаг 1
В автомобиль поставили новенькую
сигнализацию
Теперь водитель может поставить машину
на охрану
При постановке на охрану сирена «квакает»
и аварийка моргает один раз
73/95
71. Шаг 2
Водитель может снять машину с охраны
При снятии с охраны сирена «квакает»
и моргает фарами или аварийкой трижды
77/95
72. Шаг 2. У вас могло получиться
нечто похожее
78/95
73. Шаг 2. У вас могло получиться
нечто похожее
79/95
74. Шаг 3
Глубокой ночью сигнализация сработала
от датчика удара
Воет сирена
Заспанный хозяин может прекратить
безобразие при помощи брелока,
дав себе и соседям выспаться
80/95
75. Шаг 3. У вас могло получиться
нечто похожее
81/95
76. Шаг 3. У вас могло получиться
нечто похожее
82/95
77. Шаг 3. У вас могло получиться
нечто похожее
83/95
78. Шаг 4
Если ночью хозяин не проснулся,
то сирена срабатывает несколько раз
По таймеру сигнализация прекращает
шуметь и продолжает охранять машину
84/95
79. Шаг 4. У вас могло получиться
нечто похожее
85/95
80. Шаг 5
При сдаче машины в сервис хозяина
попросят отключить сигнализацию
86/95
81. Шаг 5. У вас могло получиться
нечто похожее
87/95
82. Шаг 5. У вас могло получиться
нечто похожее
88/95
84. Шаг 7
Найден баг №1. Душераздирающая история!
Сервисмен устанавливал сигнализацию в машину
Перед любыми работами с электрикой аккумулятор
отключается от бортовой сети
Ключи от машины сервисмен бросил на сиденье
Когда подключил аккумулятор, двери
заблокировались, сигнализация сработала,
ключ с брелоком – в салоне
Как такое могло
случиться?
90/95
85. Шаг 7. У вас могло получиться
нечто похожее
Если бы этот тест был
написан раньше,
бага бы не случилось
91/95
86. Шаг 8
Найден баг №2. Душераздирающая история!
Машина стояла в сервисе на ремонте
Сигнализация была, как полагается, выключена
Когда хозяин забирал машину, то по ошибке нажал
кнопку брелока вместо скрытой красной кнопки
в салоне
Сигнализация сработала
Как такое могло
случиться?
92/95
87. Шаг 8. У вас могло получиться
нечто похожее
И этот тест, будь он
написан раньше,
исключил бы ошибку
93/95
88. Краткие выводы
Тестов для простого класса – много
Но они – простые, легко читаются, легко
поддерживаются
Нужно писать тесты как для корректных,
так и для некорректных входных данных
Нужно писать тесты не только
для «прямых» случаев
Тесты полно описывают (специфицируют)
поведение тестируемого класса
94/95