Тестирование весна 2013 лекция 5

396 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
396
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Тестирование весна 2013 лекция 5

  1. 1. Тестирование для разработчиков Лекция 5. CI&CD Взаимодействие с тестировщиками. Развенская Ксения
  2. 2. План лекции • Идеальный процесс разработки • Взаимодействие с командой тестирования • Итоги курса
  3. 3. В предыдущих сериях • Автоматизированные системные (функциональные) тесты • Юнит-тесты • Интеграционные тесты • Тесты производительности
  4. 4. Как теперь будет выглядеть процесс разработки?
  5. 5. Введение Разработка на локальной машине Локальная сборка Локальный прогон Юнит-тестов Интеграция с общей веткой Функциональное тестирование
  6. 6. Welcome to Integration Hell
  7. 7. Что такое идеальный процесс?
  8. 8. Идеальный процесс разработки • Удобный • Способствует повышению качества • Снижает риски • Ускоряет разработку • Прозрачен для всей команды • Максимально автоматизирован • ?
  9. 9. Continuous Integration. Непрерывная интеграция. Непрерывная интеграция — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Википедия
  10. 10. Continuous Integration. Непрерывная интеграция. "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible." M. Fowler
  11. 11. Непрерывная интеграция. Идея • Как можно более частая интеграция кода • Непрерывное тестирование изменений
  12. 12. Требования к проекту • исходный код и все, что необходимо для сборки и тестирования проекта, хранится в репозитории системы контроля версий • чекаут из репозитория, сборка и тестирование проекта автоматизированы
  13. 13. CI процесс Code-review (opt.)
  14. 14. Continuous Integration. Преимущества использования • Проблемы интеграции выявляются и исправляются быстро, что оказывается дешевле • Немедленный прогон модульных тестов для свежих изменений • Постоянное наличие текущей стабильной версии вместе с продуктами сборок — для тестирования, демонстрации, и т. п.
  15. 15. CI процесс Code-review (opt.)
  16. 16. Система контроля версий. Version control system Система контроля версий – инструмент, облегчающий работу с изменяющимися данными. Предоставляет возможность хранить несколько версий одного документа, при необходимости вернуться к более ранней версии, определить кто и когда внес то или иное изменение, etc.
  17. 17. Система контроля версий. Преимущества использования • Легкий доступ к коду • Обеспечивает версионность • Облегчает совместную разработку • Возможность автоматизировать процессы сборки, ревью, запуска тестов
  18. 18. Система контроля версий. Антипаттерны 1. Редкие коммиты -> рискуем потерять часть изменений, реже интегрируемся Решение: Частые коммиты в течение дня 2. Массовые коммиты перед уходом с работы -> рискуем задержать коллег из-за сломанной сборки Решение: Не коммитить после N часов
  19. 19. Система контроля версий. Инструменты • Git • Subversion • CVS • ClearCase • ... http://en.wikipedia.org/wiki/Comparison_of_revisio n_control_software
  20. 20. CI процесс Code-review (opt.)
  21. 21. Код-ревью. Code-review Код-ревью – систематический просмотр кода с целью найти и исправить ошибки, допущенные на начальном этапе разработки. Цель - повышение качества кода и обмен опытом между разработчиками. Виды • Pre-commit review (email/over-the-shoulder) • Post factum • Выборочное ревью
  22. 22. Код-ревью. Плюсы и минусы Плюсы: • Способствует обнаружению ошибок • Возможность получить фидбек о стиле программирования и выборе алгоритмов • Обмен опытом • Развивает командность • Единообразность кода Минусы: • Требует инвестиций на начальном этапе
  23. 23. Код-ревью. Типы ошибок • Ошибки обращения к данным • Ошибки логических и арифметических операций • Использование сложных конструкций • Ошибки в логике программы • Стилевые ошибки • Опечатки
  24. 24. Ошибки обращения К данным • Проблемы адресации • Индексы массивов • Объявление переменных • Размер и тип • Именование переменных • …
  25. 25. Ошибки вычислений • Переполнения • Потеря точности • Деление на ноль • Ошибки в операторах сравнения • …
  26. 26. Стилевые ошибки • Именование переменных • Форматирование • Документирование кода • …
  27. 27. А также.. • Бесконечные циклы • Race conditions • Утечки памяти • …
  28. 28. Код-ревью. Основные принципы Хорошо • Быстро • Конструктивно • Объективно • Позитивно Плохо • Навязывание личных предпочтений • Переход на личности
  29. 29. Код-ревью. Антипаттерны Код-ревью тормозит процесс разработки -> негативное отношение к процессу ревью Решение: Проводить параллельно с тестированием, у задач на код-ревью – 1 приоритет
  30. 30. Код-ревью. Инструменты • VCS plug-ins • E-mail http://en.wikipedia.org/wiki/List_of_tools_for_code_review
  31. 31. CI процесс Code-review (opt.)
  32. 32. Автоматическая сборка • Компиляция • Сборка • Выполнение модульных тестов • Формирование документации и release notes
  33. 33. Автосборка. Антипаттерны Редкие сборки -> поздно обнаруживаем баги Решение: В идеале - сборка после каждого коммита Допускается сборка по расписанию несколько раз в день, если сборка+прогон модульных тестов занимает много времени NB! Возможно, это проблема и с ней надо разобраться отдельно
  34. 34. Автосборка. Антипаттерны Сборка на машине разработчика -> проблема WOMM Решение: Сборка должна производиться в целевой среде
  35. 35. Автосборка. Инструменты • Maven • Ant • Make • Gant • MSBuild • … http://en.wikipedia.org/wiki/List_of_build_automation_softw are
  36. 36. CI процесс Code-review (opt.)
  37. 37. Непрерывное тестирование • Выполнение модульных тестов при сборке • Прогон функциональных/нагрузочных/etc автотестов для каждой сборки
  38. 38. CI процесс Code-review (opt.)
  39. 39. Непрерывная обратная связь. Continuous Feedback Необходима автоматическая отправка информации о состоянии сборки разработчикам. Средства: Email, SMS, дашборды, нотификация в мессенджер
  40. 40. Обратная связь. Антипаттерны Слишком много сообщений о проваленной сборке -> Письма заносятся в спам-фильтр. Решение: Сообщения должны быть адресными – тому, кто сломал сборку.
  41. 41. Обратная связь Антипаттерны Неинформативные отчеты -> уходит много времени на понимание проблемы Решение: В сообщении должна содержаться необходимая и достаточная информация о проваленной сборке/тестах
  42. 42. Антипаттерны использования CI. Сборка всегда находится в сломанном состоянии, тесты не чинят. Решение: «Зеленая» сборка - приоритет №1, pre-commit hook, мотивация
  43. 43. Требования к CI серверу • Проверка наличия изменений в репозитории • Выполнение некоторых действий по триггеру (наличие изменений, расписание) • Поддержка нескольких инструментов сборки • Поддержка нескольких VCS • Предоставление отчетов, статистики, отправка нотификаций • Сохранение истории • Панель управления задачами
  44. 44. Инструменты CI • Jenkins (Hudson) • CruiseControl • TeamCity • Bamboo • …
  45. 45. Что дальше?
  46. 46. Непрерывная доставка. Continuous Delivery Непрерывная доставка изменений в среду, где будет тестироваться бизнес-логика.
  47. 47. Continuous Delivery& Continuous Deployment “Continuous Delivery is about keeping your application in a state where it is always able to deploy into production. Continuous Deployment is actually deploying every change into production, every day or more frequently.” M. Fowler
  48. 48. Непрерывное развертывание. Continuous Deployment Непрерывное развертывание – выпуск в продакшн-среду изменений сразу, как только они готовы к выкладке.
  49. 49. Непрерывное развертывание. Tips&Tricks. • Автоматизированная выкладка одной командой • Только полностью готовые к выкладке фичи в production-ветке • DevOps • Чистота среды • Маркировка каждой сборки • Прогон всех проверок • Использование обратной связи • Возможность быстро откатить изменения
  50. 50. Взаимодействие с командой тестирования
  51. 51. Основная идея – у нас общая цель!
  52. 52. Мифы о тестировании • Тестирование увеличивает время до выкладки в продакшн • Тестировщики любят находить много багов • Тестировщики обеспечивают качество • Тестировщики отвечают за качество продукта • Тестирование должно быть полностью автоматизировано
  53. 53. Эффективное взаимодействие • Тестировщики должны иметь возможность протестировать приложение • Процесс разработки должен быть прозрачен для тестировщика (и наоборот) • Работа с кодом • Работа с требованиями • Работа с багами
  54. 54. Тестопригодность. Testability Тестопригодность – степень легкости и удобства тестирования, а также возможность проведения тестирования с использованием определенного инструмента или подхода.
  55. 55. Тестопригодность. Testability Характеристики тестопригодного ПО: • управляемость: возможность перейти в любое состояние системы, подавая на вход разные стимулы • наблюдаемость: в каждый момент времени понимаем в каком состоянии находится система • изолируемость: тестируемый компонент может быть проверен в изоляции • разделение задач: тестируемый компонент имеет одно, вполне определенное назначение • понятность • автоматизируемость: возможность автоматизировать тестирование
  56. 56. Управление требованиями и процесс разработки Тестировщику необходим список изменений -> Все изменения должны быть отражены в ТЗ/Таск- трекере.
  57. 57. Работа с багами • Старайтесь относиться позитивно • Учитесь на ошибках • Все баги – через баг/таск-трекер • Не накапливайте технический долг
  58. 58. Баги в продакшне
  59. 59. Баги в продакшне: причины • Ошибка тестировщика • Невозможность протестировать все • Баг воспроизводится нестабильно (гейзенбаг) • Несоответствие тестовой среды продакшн-среде • Ошибка при выкладке
  60. 60. Баги в продакшне: действия • Фикс NB! Фикс должен быть протестирован перед выкладкой • Анализ причин • Меры по предотвращению багов в будущем
  61. 61. Резюме • Процесс важен для достижения результата • Процесс должен существовать не ради процесса • Процесс должен быть удобен всем и способствовать эффективной работе команды
  62. 62. Материалы 1. http://martinfowler.com/articles/continuousIntegration.html 2. http://www.thoughtworks.com/continuous-delivery 3. Непрерывное развертывание ПО, Джез Хамбл, Дейвид Фарли 4. http://refcardz.dzone.com/refcardz/continuous-integration#refcard-download- social-buttons-display 5. http://martinfowler.com/bliki/FeatureBranch.html 6. http://martinfowler.com/bliki/FeatureToggle.html 7. http://itrevolution.com/devops-culture-part-1/
  63. 63. Зачет
  64. 64. Спасибо за внимание Развенская Ксения, k.razvenskaya@corp.mail.ru

×