Перейти к содержимому

Фотография

Тестирование на отказ и восстановление (Failover and Recovery Testing)

тест отказ восстановление для неопытных

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 8

#1 VladimirSunny

VladimirSunny

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Ходячих Владимир Владимирович

Отправлено 01 декабря 2016 - 09:10

Доброго времени суток всем) У меня возникла проблема с описанием Failover and Recovery Test веб-портала, дело в том, что по сути я являюсь web-разработчиком, который очень редко сталкивается с вопросами теста приложений, но на меня была повешана задача - написать статью с полным тестом ресурса, трудность заключается непосредственно в правильном составлении отчетной документации о прохождении теста на отказ и восстановление - все найденные мною данные и поисковых систем очень поверхностно описывают процесс реализации данного теста. Можете скинуть ссылку на более детальное описание, по которому можно составить план и протестить приложение по всем стандартам - или поделится собственным опытом в проведении подобного теста? Заранее очень благодарен за ответы.


  • 0

#2 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 01 декабря 2016 - 09:42

думаю стандарта нет, а всё зависит от архитектуры и вообще что тестируется
 
например:
есть веб-сервер(один или несколько, либо в облаке, тут же лоад-балансеры) на нём крутится веб-фронтенд, есть база данных (одна или несколько, либо в облаке, тут же лоад-балансеры), возможно есть и другие сервера и аппликации, например платёжные системы
 
значит надо понять что вообще из этого всего мы хотим протестировать: может если один веб-сервер упадёт то сессия клиента продолжится через другой веб-сервер? может если одна база данных упадёт то данные корректно восстанавливаются и реплицируются между базами (на это способен только высококвалифицированный специалист баз данных)?

  • 0

#3 VladimirSunny

VladimirSunny

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Ходячих Владимир Владимирович

Отправлено 01 декабря 2016 - 09:58

Думаю наиболее важным в отчете будет сохранение конфиденциальности клиентов системы и правильность сохраняемых данных операциями CRUD,  то-есть насколько я понимаю мне нужно имитировать наиболее стрессовые ситуации. например вырубить сервер в процессе заполнения формы на сайте. или в процессе произведения базовых CRUD операций и описать последствия вызванные данным действием, в моем случае проверить корректность произведенной операции если она была запущена в период отключения сервера, а также информацию, которая была помещена в базу и на основе этой инфы формировать поэтапно отчет?


  • 0

#4 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 01 декабря 2016 - 09:59

самый простой вид тестирования тут: поочерёдно отключать/включать под-системы одну за одной и смотреть: 
1. если есть резервная подсистема: система продолжает работать (например выключен один веб-сервер из двух)
2. если нет резервной подсистемы (например один веб-сервер), либо выключил и резервные тоже (выключены два веб-сервера из двух): функция прекращает работу, но работа правильно восстанавливается после включения хотя бы одной подсистемы

  • 1

#5 VladimirSunny

VladimirSunny

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Ходячих Владимир Владимирович

Отправлено 01 декабря 2016 - 10:06

Думаю Вы помогли мне пролить практическую ясность по данному вопросу, спасибо) 


  • 0

#6 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 01 декабря 2016 - 10:33

что будет если веб-сервер упадёт? надо смотреть различные действия - клиент переходит в другое меню, клиент сабмитит форму, клиент добавляет в корзину, клиент совершает покупку и т.п.
 
потом те же самые действия - только при упавшей базе
 
потом например действия с платежами - при упавшей системе платежей

  • 1

#7 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 01 декабря 2016 - 11:00

чуть не забыл что надо вырубать ещё и сервер(ы) аппликации :)


  • 0

#8 akaars

akaars

    Новый участник

  • Members
  • Pip
  • 64 сообщений


Отправлено 02 декабря 2016 - 11:08

Должен быть изначальный flow для различных HA events если это вообще предусмотрено. Иначе это будет очень грустно. Точек отказа в системе довольно много.

Мы у себя держим кучу тестов, часть состоит из одного фейла - например, пропадание электричества в стойке + поведение после восстановления оного. А другая часть - комплексные тесты, которые могут в себе содержать более простые. К примеру, апгрейд системы и в процессе апгрейда опять же пропало электричество в стойке.

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

Я к тому, что если подобные тесты у вас не проводились, то быстро-быстро на раз-два их выполнить ну, очевидно, никак :(


  • 0

#9 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 02 декабря 2016 - 11:31

 

 

Я к тому, что если подобные тесты у вас не проводились, то быстро-быстро на раз-два их выполнить ну, очевидно, никак :(

имеется ввиду что веб-девелопер может проверить "свою" зону ответственности - чтобы клиентская часть в браузере клиента корректно вела себя при основных типах отказов: отказ веб-сервера, отказ сервера приложений и отказ базы данных (третье конечно не так важно, так как фильтруется сервером приложений, но всё же попробовать можно)


  • 0



Темы с аналогичным тегами тест, отказ, восстановление, для неопытных

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных