Тестирование ПО: баг не пройдет!

Открытый семинар для студентов в компании CUSTIS (3 апреля 2014 года).
Лектор: Владислав Иофе, руководитель группы в отделе технологического развития.

Transcript

1. 3 апреля 2014 года Тестирование ПО: баг не пройдет! Владислав Иофе Руководитель группы в отделе технологического развития
2. На сегодня  Что такое тестирование? Зачем нужно тестировать?  Классификация  «Ящик», уровни и назначения  Артефакты тестирования  Профессии тестировщика и QA  Автоматизированное тестирование  Тестирование через GUI и тестирование кода  XP, TDD  Болезни и best practices  Практика 2/95
3. О компании и о себе 3/95
4. О себе  В 2005 окончил мехмат Ташкентского государственного университета  С 2004 занимаюсь корпоративным программным обеспечением  Работал разработчиком, тимлидом и техлидом  В 2008 пришел в CUSTIS  Сейчас руководитель группы в отделе технологического развития 4/95
5. Наша компания занимается проектированием 5/95
6. …разработкой 6/95
7. …внедрением 7/95
8. …сопровождением 8/95
9. …и развитием ИТ-систем 9/95
10. Для Банков Торговых сетей Госкорпораций Предприятий ЖКХ 10/95
11. Структура компании 11/95
12. Профессиональная инфраструктура 12/95
13. «Техническая инфраструктура» 13/95
14. Отличники  14/95
15. Мальчики и девочки  15/95
16. Что такое тестирование? 16/95
17. Что такое тестирование? Ваши версии? Блог автора 17/95
18. Что такое тестирование? Это неполное, частное определение Тестирование – процесс исполнения программы с целью обнаружения ошибок Г. Майерс 18/95
19. Что такое тестирование? (продолжение)  Исследование программного обеспечения для обеспечения интересантов информацией о качестве тестируемой системы 19/95
20. Качество ПО Качество продукта – функция от того, насколько он изменил мир в лучшую сторону Том ДеМарко 20/95  Не очень конкретно?  Качество – отдельная большая тема. Как минимум, можно говорить о качестве с точки зрения пользователя (удовлетворение потребностей), с философской точки зрения (достижение некоего идеала), с точки зрения производства продукта
21. Качество ПО (продолжение) Аспекты качества:  Надежность (Reliability)  Сопровождаемость (Maintainability)  Стоимость внесения изменений (в т. ч. исправления дефектов)  Наблюдаемость системы  Эффективность (Efficiency)  Производительность  Удобство использования  Функциональность Некоторые из этих аспектов помогают обеспечивать тестирование 21/95
22. И снова: что такое тестирование?  Процесс формальной проверки и подтверждения (верификация и валидация) того, что ПО:  отвечает предъявляемым требованиям  удовлетворяет нуждам интересантов  работает, как ожидается, или может быть сделано с заданными характеристиками 22/95
23. Верификация и валидация 23/95
24. Верификация и валидация Покупка подержанного автомобиля:  Осмотреть  Тест-драйв  Пробить по базе ГАИ  Показать в сервисе  Купить  Поставить на учет www.gibdd.ru/check/auto 24/95
25. Что такое тестирование? Блог автора 25/95
26. Свойство Тестирование может показать наличие ошибок, но никогда не докажет их отсутствие Э. Дейкстра 26/95
27. Классификация 27/95
28. Классификация: статика vs. динамика  Статическое тестирование (без исполнения программы) направлено на верификацию  Проверка синтаксиса IDE  Code review  Статический анализ кода  …  Динамическое – может быть направлено на валидацию 28/95
29. Классификация: принцип ящика  Метод тестирования белого ящика проверяет внутренние структуры и логику работы тестируемого фрагмента. Необходим для:  Локализации сложных ошибок  Обеспечения требуемого покрытия кода  Метод черного ящика подразумевает наличие информации только о требованиях к тестируемому фрагменту (например, входных и выходных данных) 29/95
30. Классификация: принцип ящика 30/95
31. Классификация: уровни Уровни тестирования*:  Модульное / Unit  Интеграционное / Integration  Системное / System  Приемочное / (User) Acceptance * Под уровнем пока подразумевается крупность тестируемых «строительных» блоков приложения ** Иногда выделяют компонентное тестирование (Component) 31/95
32. Классификация: уровни 33/95
33. Классификация: уровни и V-модель Анализ требований Детальный дизайн Кодирование Интеграционное тестирование Системное тестирование Приемочное тестирование Модульное тестирование Дизайн системы Архитектура Тестирование и интеграция Детализация проекта Время 34/95
34. Классификация: по назначению  Регрессионное / Regression  Приемочное / Acceptance  Альфа, Бета  Функциональное / Functional  Тестирование производительности / Performance  Нагрузочное / Load  Стресс-тестирование / Stress  … 35/95
35. Классификация: по назначению (продолжение)  Юзабилити-тестирование / Usability  Тестирование безопасности / Security  Smoke-тестирование  … 36/95
36. Тестирование производительности Блог автора 37/95
37. Классификация: многомерное пространство 38/95
38. Артефакты тестирования 39/95
39. Артефакты тестирования: пример с бронированием билетов  Пользователь находится на последнем шаге – подтверждении бронирования. Нажимает кнопку, в ответ:  Бронь успешна, маршрут-квитанция в почте  Места по тарифу закончились  Сессия истекла  … 40/95
40. Артефакты тестирования 41/95
41. Артефакты тестирования 43/95
42. Артефакты тестирования 45/95
43. Профессии тестировщика и QA 47/95
44. Кто тестирует? Внедренцы и пользователи Бизнес- аналитики Системные аналитики Тестировщики Разработчики Анализ требований Детальный дизайн Кодирование Системное тестирование Приемочное тестирование Интеграционное тестирование Дизайн системы Архитектура Модульное тестирование 48/95
45. Профессии тестировщика и QA  QA (Quality Assurance, обеспечение качества) – это процесс формирования и поддержания требуемых характеристик качества ПО по мере его создания и сопровождения. QA захватывает все стороны создания ПО: сбор требований, проектирование, тестирование, интеграцию и т. д.  Тестировщик ≠ QA-инженер 49/95
46. Профессии тестировщика и QA Quality Control Quality Assurance Testing 50/95
47. Кто тестирует?  В разных командах и компаниях сильно по-разному  Бывают выделенные тестировщики  В CUSTIS на трех разработчиков приходится один инженер, который занимается:  аналитикой  тестированием  внедрением и поддержкой 51/95
48. Профессии тестировщика Блог автора 52/95
49. Автоматизированное тестирование 53/95
50. Автоматизированное тестирование Для тестирования используется отдельное ПО (не то, что тестируется)  Сложность  Требования к квалификации  Тоже требуется отладка  Дорого в поддержке – кодовая база вырастает вдвое  Надежность  Повторяемость  Повторное использование  Контроль регрессии  Разные конфигурации  Скорость  Возможность одновременного запуска на разных машинах  Рефакторинг безопаснее 54/95
51. Автоматизированное тестирование через GUI  Тестировать вручную через GUI все равно нужно!  Как минимум, приемочное тестирование  Но очень много повторяющихся рутинных действий  Надо их автоматизировать!  Пример… 55/95
52. Тестирование кода: юнит-тест 57/95
53. Extreme Programming (1999)  Методология разработки, направленная на повышение доверия заказчика и качества ПО  Среди практик:  Test First  Парное программирование  … Кент Бек 58/95
54. Test-Driven Development (2002) 59/95
55. Автоматизированное тестирование Блог автора 61/95
56. Best practices  Не пытайтесь тестировать все  Тест должен быть простым  Интеграционных тестов не должно быть очень много  Тесты не должны зависеть друг от друга 62/95
57. Best practices  Пишите тесты как для корректных, так и для некорректных входных данных  Пишите тест как на положительные, так и на отрицательные сценарии  Запускайте тесты как можно чаще. Используйте Continuous integration  Пишите тест до кода. Или пусть тест напишет хотя бы не автор тестируемого кода 63/95
58. Литература 64/95
59. Вопросы?  Перерыв 10 минут  А потом практика 65/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
63. Немного практики: автомобильная сигнализация  Кнопка 1 ставит на охрану  Кнопка 2 снимает  Есть датчик удара 69/95
64. Шаг 1 70/95
65. Диаграмма классов 71/95
66. 72/95
67. Шаг 1  В автомобиль поставили новенькую сигнализацию  Теперь водитель может поставить машину на охрану  При постановке на охрану сирена «квакает» и аварийка моргает один раз 73/95
68. Шаг 1 74/95
69. Шаг 1. Пример одного теста 75/95
70. Шаг 1. Тестовая заглушка для аварийки 76/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
83. Шаг 6 Ничего не забыли? 89/95
84. Шаг 7 Найден баг №1. Душераздирающая история!  Сервисмен устанавливал сигнализацию в машину  Перед любыми работами с электрикой аккумулятор отключается от бортовой сети  Ключи от машины сервисмен бросил на сиденье  Когда подключил аккумулятор, двери заблокировались, сигнализация сработала, ключ с брелоком – в салоне Как такое могло случиться? 90/95
85. Шаг 7. У вас могло получиться нечто похожее Если бы этот тест был написан раньше, бага бы не случилось 91/95
86. Шаг 8 Найден баг №2. Душераздирающая история!  Машина стояла в сервисе на ремонте  Сигнализация была, как полагается, выключена  Когда хозяин забирал машину, то по ошибке нажал кнопку брелока вместо скрытой красной кнопки в салоне  Сигнализация сработала Как такое могло случиться? 92/95
87. Шаг 8. У вас могло получиться нечто похожее И этот тест, будь он написан раньше, исключил бы ошибку 93/95
88. Краткие выводы  Тестов для простого класса – много  Но они – простые, легко читаются, легко поддерживаются  Нужно писать тесты как для корректных, так и для некорректных входных данных  Нужно писать тесты не только для «прямых» случаев  Тесты полно описывают (специфицируют) поведение тестируемого класса 94/95
89. Спасибо! Вопросы? Владислав Иофе viofe@custis.ru 95/95