CodeFest 2012. Ивлиев Р. — Аккуратно переезжаем, или тестирование в проектах миграции
•Télécharger en tant que PPTX, PDF•
1 j'aime•774 vues
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à CodeFest 2012. Ивлиев Р. — Аккуратно переезжаем, или тестирование в проектах миграции
Similaire à CodeFest 2012. Ивлиев Р. — Аккуратно переезжаем, или тестирование в проектах миграции (20)
Plus de CodeFest
Plus de CodeFest (20)
CodeFest 2012. Ивлиев Р. — Аккуратно переезжаем, или тестирование в проектах миграции
- 1. Аккуратно переезжаем или тестирование в проектах миграции
- 2. О чем я хочу поговорить: • Миграция, что это? • Что же это за проекты такие? • Проблемы есть? • Что с этим делать? • Примеры есть?
- 4. Есть ли среди вас те, кто участвовал в проектах миграции?
- 5. Есть ли среди вас разработчики?
- 6. Есть ли среди вас Чак Норрис?
- 7. Сколько отжиманий может сделать Чак Норрис?
- 10. Миграция, что это? лат. migratio, от migro — перехожу, переселяюсь.
- 12. или так:
- 13. или даже так:
- 14. Узнаете?
- 15. Что же это за проекты такие?
- 16. Воссоздание и перенос данных:
- 17. Что характерно: • Потеря функционала
- 18. Что характерно: • Потеря функционала • Потеря данных
- 19. Что характерно: • Потеря функционала • Потеря данных • Изменение характеристик системы
- 21. Что характерно: • Потеря доступности
- 22. Что характерно: • Потеря доступности • Изменение окружения
- 23. Что характерно: • Потеря доступности • Изменение окружения • Изменение характеристик системы
- 24. Смена айпишника:
- 25. Виртуализация:
- 26. Проблемы?
- 27. Проблемы! Они есть всегда!
- 28. Время:
- 29. Не забыли ещё?
- 32. Стоимость:
- 33. Кадровый голод:
- 36. Маркетинг: • Часто обновляется • Локализации иногда радикально отличаются • Занудные владельцы • Приличные объемы • Куча функциональных костылей
- 37. Так разницы почти не видно:
- 38. Так разницы почти не видно:
- 39. А вот так уже очень видно...
- 40. Основной упор – контент:
- 41. Основной упор – контент: • Сравнивали с эталоном
- 42. Основной упор – контент: • Сравнивали с эталоном
- 43. Основной упор – контент: • Сравнивали с эталоном • Валидировали самостоятельно
- 44. Основной упор – контент: • Сравнивали с эталоном • Валидировали самостоятельно
- 45. Основной упор – контент: • Сравнивали с эталоном • Валидировали самостоятельно • Верифицировали самостоятельно
- 46. Основной упор – контент: • Сравнивали с эталоном • Валидировали самостоятельно • Верифицировали самостоятельно • Валидацию раздали заинтересованным лицам
- 47. Саппорт: • Плановая выкатка контента пачками • Межязыковое единообразие • Более сговорчивые владельцы • 7,5К статей на основные локализации
- 48. Основной упор – пользователи: • Бета-версия
- 49. Proof-pic
- 50. Основной упор – пользователи: • Бета-версия • Сбор фидбэков
- 51. Основной упор – пользователи: • Бета-версия • Сбор фидбэков • Привлечение сотрудников саппорта
- 52. Эталонное тестирование: • Сравниваем со старой системой
- 53. Эталонное тестирование: • Сравниваем со старой системой • Сравниваем локализации друг с другом
- 54. Очень agile:
- 55. Инструменты
- 56. Бета – тестеры:
- 64. Пользовательские сценарии: • Для разработчиков
- 65. Пользовательские сценарии: • Для разработчиков • Для миграторов
- 66. Пользовательские сценарии: • Для разработчиков • Для миграторов • Для UAT
- 67. Пользовательские сценарии: • Для разработчиков • Для миграторов • Для UAT • И...
- 68. Пользовательские сценарии: • Для разработчиков • Для миграторов • Для UAT • И... • Их сделали сами пользователи
- 69. В результате: • Штатных тестировщиков – 0
- 70. В результате: • Штатных тестировщиков – 0 • Внештатных – гораздо больше
- 71. В результате: • Штатных тестировщиков – 0 • Внештатных – гораздо больше • 25К страниц
- 72. В результате: • Штатных тестировщиков – 0 • Внештатных – гораздо больше • 25К страниц • С Фряхи на Винду
- 73. В результате: • Штатных тестировщиков – 0 • Внештатных – гораздо больше • 25К страниц • С Фряхи на Винду • С Perl’а на C#
- 74. В результате: • Штатных тестировщиков – 0 • Внештатных – гораздо больше • 25К страниц • С Фряхи на Винду • С Perl’а на C# • И мы ещѐ не закончили
- 75. Каждому свое: «Слова вы услышали, поиск пути за вами» Уильямс Деминг
- 76. Спасибо за внимание! • Я: Роман Ивлиев • Е-почта: roman.ivliev@mail.ru • @dumtest • dumtest.livejournal.com
Notes de l'éditeur
- Что с тестированием: какие тесты необходимо проводить сильно зависит, на сколько вы изуродовали железное окружение приложения. Вполне вероятно, что тестировать какие-то внутренние механизмы не имеет смысла, а вот понавешать стаберов на внешние интерфейсы и протыкать их выходит что обязательно. А если у вас их нет - значит надо их взлабать ещё до того, как начнете что-то двигать. Вообще факт присутствия например полного регрессионного тестирования сильно зависит от критичности сервиса и вашего внутреннего чутья. Ибо кто как не тестировщик знает все тонкости и нюансы своей системы. Ну и естественно нужен кто-то, кто сможет верхнеуровнево оценить, как этот переезд мог бы повлиять на потроха вашей системы.У меня есть хороший пример. Есть у нас сервис подписки. Через него мы раздаем Касперчега по абонентской плате за месяц. Так вот. Есть два сервера в Москве, стоят у разных провайдеров. А есть клиент. Так вот с одним сервером у него любовь и взаимопонимание, а с другим одни проблемы, то сессию не так закроет, но просто на связь не выходит. Долго ковырялись и выяснили что а какой-то момент пакеты от клиента перестают достигать нашего сервера и он рвет соединение по таймауту. Почему пока не докопались. Но, тем не менее - можно эту ситуацию рассматривать с той точки зрения, что мы перетащили сервер в другой датацентр.
- Что с тестированием: какие тесты необходимо проводить сильно зависит, на сколько вы изуродовали железное окружение приложения. Вполне вероятно, что тестировать какие-то внутренние механизмы не имеет смысла, а вот понавешать стаберов на внешние интерфейсы и протыкать их выходит что обязательно. А если у вас их нет - значит надо их взлабать ещё до того, как начнете что-то двигать. Вообще факт присутствия например полного регрессионного тестирования сильно зависит от критичности сервиса и вашего внутреннего чутья. Ибо кто как не тестировщик знает все тонкости и нюансы своей системы. Ну и естественно нужен кто-то, кто сможет верхнеуровнево оценить, как этот переезд мог бы повлиять на потроха вашей системы.У меня есть хороший пример. Есть у нас сервис подписки. Через него мы раздаем Касперчега по абонентской плате за месяц. Так вот. Есть два сервера в Москве, стоят у разных провайдеров. А есть клиент. Так вот с одним сервером у него любовь и взаимопонимание, а с другим одни проблемы, то сессию не так закроет, но просто на связь не выходит. Долго ковырялись и выяснили что а какой-то момент пакеты от клиента перестают достигать нашего сервера и он рвет соединение по таймауту. Почему пока не докопались. Но, тем не менее - можно эту ситуацию рассматривать с той точки зрения, что мы перетащили сервер в другой датацентр.
- Если сравнить и не брать в рассчет колонки, и что прыгает немного картинка, то отличие серьезное одно – вместо eshop Online Shop и в селекторе страна болдом. Хрен с ним с селектором. Но пункт меню отломал часть тестов на последовательность и состав меню.
- А вот теперь пробем стало гораздо больше. До свидания старая DOM-модель, здравствуй новая, очаровательная.
- Тестирование контента. К сожалению, к составу контента маркетологи очень требоваетельны. По их науке даже небольшое изменение в тексте роняет или возносит продажи на непомерные высоты. Т.к. все страницы разные, первой идеей было - "а давайте сравним то, что получилось с предыдущей версией сайта". Т.е. по сути воспользуемся подходом тестирования на базе эталонов и попробовать найти ответ на вопрос - "так ли новая кажет, как старая казала". По началу так и делали. В результате потратили кучу времени, т.к автоматически проверять контент оказалось еще сложнее. Дальше решили всех обмануть и проводить тестирование по принципу "работает ли новая система корректно". Т.е. по сути приватизировав право на валидацию. От этой идеи тоже очень быстро отказались, т.к. на русский и английский языки хватило, а вот испанский и итальянский подкачали. Не нашлось носителей языка среди команды миграции. По сути работа миграторов свелась к тому, что проверить, все ли компоненты (картинки, стили и т.д. ) присутствуют и корректно отображаются на странице. А роль читателей отдали носителям языка из группы контент-редакторов. С блоками продаж поступили немного не так: отдали валидацию сотрудникам региональных отделов продаж. Они проверяли корректность работы сайта с интернет-магазинами, настраивали свои трекеры и, заодно, вычитывали тексты и проверяли, что картинки соответвуют дейтсвительности.
- Ведь есть же старый сайт. Он то точно правильно работает. Тут же напоролись на то, что работает то он нормально, но вот контент битый. Где очепятка, где картинка не та. Это свойственно системам, где контент контролируется редакторами и не проходит достаточную проверку перед публикацией.
- Ведь есть же старый сайт. Он то точно правильно работает. Тут же напоролись на то, что работает то он нормально, но вот контент битый. Где очепятка, где картинка не та. Это свойственно системам, где контент контролируется редакторами и не проходит достаточную проверку перед публикацией.
- Не всегда это подходит.
- Большие объемы контента. Ребята из саппорта применили неведомый нам доселе прием и не стали сразу запускать новый сайт в продакш, а разрешили нам запустить его в так называемой "бете", чем сделали нам тестирование прогулкой под луной, а не забегом под метеоритным дождем. Что нам это дало - фактор суеты был уничтожен. В результате сейчас в паблике ворочаются оба сайта - старый и новый, не сильно отличающиеся по контенту. При этом новый вежливо просит с вас фидбек. Ура. Мы за бесплатно получили некоторое количество бета-тестеров. Люди пишут отзывы, люди находят баги. Но это баги в бете:) Даже те, кто не пишет баги - тыкают странички, контролы, формочки. А еще афигенная тема признавать свои ошибки - т.е. если пользователь натыкался на несуществующую страницу или на битый контрол (дя, мы иногда отдаем 40е и 50е, но под картинку с извинениями). А еще ниже картинки - письмо разрабу/тестеру, что что-то отвалолось и можно что-то откопать по горячим следам. Функциональное тестирование: ничего умнее не придумали, как сравнение с эталоном. Старый сайт в рабочем состоянии, вот с ним и сравнивали. Объекты для сравнения выковыривали заранее. Т.к. сайт саппорта не является чем-то высокотехнологичным - таких объектов нашлось не очень много. Были правда и те, которые были созданы с нуля. Их пинали по полной и по всем правилам науки.Контролы и прочий функциональный стаф. При условиях работы сайта под естественной нагрузкой - немного более агрессивное логгирование с нотификацией в почту о критических сбоях (да, оно тормозит время отклика, но мы в бете:)) в компонентах залог нахождения объяснения очень интересным эффектам, на получение которых в лабораторных условиях ушло бы очень много времени. Т.о. мы и тут не ушли от классической науки, применив так назывваемое "soak-тестирование" - тестирование системы в естественной среде обитания под естественными нагрузками. Что касается внутреннего тестирования, которое мы, естественно проводили, подход был выбран такой - чтобы не проверять глазками 7, 5К статей, отсортировали их по рейтингу (старая система исправно считала гвозди) и начали проверять сверху вниз. Плюс ребята из саппорта очень дисцеплинированные - привлекают свои локальные офисы, тыкают сами, пишут баги и т.д.
- Ребята из саппорта применили неведомый нам доселе прием и не стали сразу запускать новый сайт в продакш, а разрешили нам запустить его в так называемой "бете", чем сделали нам тестирование прогулкой под луной, а не забегом под метеоритным дождем. Что нам это дало - фактор суеты был уничтожен. В результате сейчас в паблике ворочаются оба сайта - старый и новый, не сильно отличающиеся по контенту.
- Не всегда это подходит.
- Не всегда это подходит.
- Все делаем на самом высоком уровне. Т.е. идем по одной – параллельно щупаем остальные. Не 200 – прокололись и не смигрировали.
- Все делаем на самом высоком уровне. Т.е. идем по одной – параллельно щупаем остальные. Не 200 – прокололись и не смигрировали.
- Группировка контента и постоянные демы. Использование ресурса заказчика на все проценты
- Дальше немного про то, что мы использовали, чтобы облегчит себе жизнь
- Да, это может снизить производительность системы, но, для этого есть следующий инструмент. Но все это ради следующего инструмента
- Уаля. Вопрос регрессии решен.
- Нагрузка. Использовали JMeter в распределенном исполнении и ab. Запаса по производительности у серверов прилично, поэтому в основном силы тратили на снижение ресурсоемкости операций. Плюс к этому нагло пользовались распределенной архитектуров системы. На серверах-балансерах включали и выключали ноды, предварительно настроив системы мониторинга (тут кстати стоит отметить, что сами системы мониторинга, особенно с включенным графическим модулем, сильно поедают ресурсы). Т.о. мы получали возможность наблюдать за поведением сервера при реальных нагрузках (имеетсч ввиду реальное поведение пользователя, который приходит на индекс, затем топает в поиск, потом переходит в продуктовые блоки и т.д.) При этом опять же усиливали логирование. Это конечно не очень правильно, но определенных успехов в поимке слабых мест в системе достичь удалось. Почему не достигали на берегу? Потому что система из коробки, с чрезвычайно нетипичным поведением в некоторых ситуациях. Кстати, вот эти чуваки https://browsermob.com/ абсолютно бесплатно предлагают померять время отдачи контента из разных точек, но и напихали на сайт много интересной информации. А еще можно зарегистрироваться и получить еще кучу плюшек.
- Нагрузка. Использовали JMeter в распределенном исполнении и ab. Запаса по производительности у серверов прилично, поэтому в основном силы тратили на снижение ресурсоемкости операций. Плюс к этому нагло пользовались распределенной архитектуров системы. На серверах-балансерах включали и выключали ноды, предварительно настроив системы мониторинга (тут кстати стоит отметить, что сами системы мониторинга, особенно с включенным графическим модулем, сильно поедают ресурсы). Т.о. мы получали возможность наблюдать за поведением сервера при реальных нагрузках (имеетсч ввиду реальное поведение пользователя, который приходит на индекс, затем топает в поиск, потом переходит в продуктовые блоки и т.д.) При этом опять же усиливали логирование. Это конечно не очень правильно, но определенных успехов в поимке слабых мест в системе достичь удалось. Почему не достигали на берегу? Потому что система из коробки, с чрезвычайно нетипичным поведением в некоторых ситуациях. Кстати, вот эти чуваки https://browsermob.com/ абсолютно бесплатно предлагают померять время отдачи контента из разных точек, но и напихали на сайт много интересной информации. А еще можно зарегистрироваться и получить еще кучу плюшек.
- Это было наверное самое ценное предложение из всех. Для всех участников процесса сценарии были сделаны одинаковыми. Составленные в наиболее удобоваримой форме – степ-бай-степ с привлечением маркетинга и саппорта, которые стопитсот лет назад построили эти сценарии на основе статистических данных, собранных на миллионах пользователей. С ними же собрали перечень критичексих для бизнеса страниц, на которые уделяли наибольшее внимание.
- Трекеры – очень интересная штука. Помимо всего ненужного, что они делают. Они ещё до кучи позволяют выковыривать много чего интересного – в частности наиболее полулярные страницы, переходы между ними и т.д. Соответственно, опираясь на эту статистику можно вырисовывать критические цепочки страниц и уделять им особое внимание.
- Трекеры – очень интересная штука. Помимо всего ненужного, что они делают. Они ещё до кучи позволяют выковыривать много чего интересного – в частности наиболее полулярные страницы, переходы между ними и т.д. Соответственно, опираясь на эту статистику можно вырисовывать критические цепочки страниц и уделять им особое внимание.
- На этом месте обычно слайд «Вопросы», но из-за него никогда не получается срисовать контакты выступающего. Поэтому я его упразднил. Большое спасибо за внимание, перезжайте аккуратно, и да прибудет с вами сила! Вопросы