Тестирование надежности (стабильности)

Тестирование стабильности или надежности (Stability / Reliability Testing) — проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.

Если не перезагружать компьютер, рано или поздно начнет даже ворд тупить. Потому что «ну хватит уже, месяц ап-тайма, дай мне почистить внутренние кеши!». Или браузер — открыли вы кучу вкладочек, работает нормально. А через день-два-три-неделю начинает тормозить, пока не перезапустите. Это и есть надежность приложения — сколько он проработает в нормальном режиме?

Особенно важно для мобильных телефонов — вы вообще часто закрываете приложение? Я обычно просто жму на домашнюю кнопку, сворачивая его. А потом снова открываю. Приложения, не тестировавшиеся на надежность, постоянно зависают / вылетают / теряют соединение с сетью. 

Цели тестирования надежности:

1) Выяснить, сколько времени сервис может проработать безотказно в конкретном окружении под конкретной нагрузкой. Не экстремальной нагрузкой, а простой.

2) Выявить утечки ресурсов. То есть в процессе теста тщательно мониторятся ресурсы системы (память, процессор, загрузка диска, файловые дескрипторы, сокеты)

И как раз из-за второго пункта приложения могут зависать после долгого ап-тайма (времени с момента запуска). Утечки ресурсов часто бывают на мобильниках — по крайней мере, в 2019 году я с этим постоянно сталкиваюсь, еще нет стандартных фреймворков, позволяющих этого избежать, видимо.

Играю на телефоне в игрушку «слово». Вот где надежности нет вообще, по крайней мере, на моем телефоне. Android, но не самсунг распространенный, а Vivo. 

Свернешь приложение на пару минут, чтобы принять звонок — оно уже потеряло сеть. Будь то улица с 4G или дом с вай-фаем, не важно. Открываю приложение и каждый раз вижу такой экран: 

 

 

Скачала игру на айпад — нет такой проблемы от слова вообще. Это при том, что телефон куплен год назад, а айпаду уже больше 4 лет, что старее? С другими приложениями такой проблемы нет, так что это не глюки сети. Это нестабильность приложения в конкретном окружении.

 

Также нужно внимательно следить за утечками на сервере приложений. Вот вы открываете интернет-магазин или тот же Testbase. Для вас это просто страничка в браузере. А на самом деле на сервере запущено приложение. И оно ОЧЕНЬ редко гасится. Поэтому, если приложение выжирает ресурсы, за этим нужно следить.

Когда я только запустила сайт Testbase — он через пару дней упал. База отвалилась. Перезапустили. Еще через пару дней опять упал. И опять. В итоге поставили костылик:

Разработчик: Запустил, поставил перезапуск каждый день на 3:55.

Но я не настолько админ, чтобы понять чего там не хватает )

Разработчик: Там, судя по логам, кончается память.

Разработчик: sql-сервер наверное что-то кеширует.

Разработчик: Проще всего ребутать, потому что настраивать опухнешь там

Ну, не выдерживало приложение даже небольшую, но постоянную нагрузку. Это, кстати, довольно типичная проблема — обычно в любом приложении есть кеш. В самом приложении или внутри базы. Он копится, копится, копится, а потом бах — и выжрал все место. Приложение зависает.

Что в этой истории забавного — пару месяцев назад я услышала ровно о таком же хотфиксе от знакомого со своим небольшим сайтом. Та же проблема, но нагрузка побольше, поэтому сайт падал чаще. Покопались, покопались, обнаружили, что проще всего лечить ребутом. Поставили на таймер каждую ночь рестартить = проблема решена! 

В принципе, это действительно лучше, чем тратить кучу времени на настройку, администрирование и докрутку. Иногда проще обойти баг, чем его фиксить =)

Правда, когда я написала об этом в блоге , тут же услышала кучу возмущений «Как так, не искать корень бага! Вы обязаны это делать, иначе будет куча мифических проблем». Но учтите, что у владельцев небольших сайтов просто нет ресурсов фиксить такие баги — потому что у них нет разработчиков. Фрилансер пришел-увидел-победил. Сделал сайт и свободен. А если падения начались спустя пару месяцев, поди найди того, кто это исправит.

Да и на реальной работе у вас будут такие ситуации, когда есть баг, о нем все знают, но исправлять некогда. Вместо этого делают обходной путь. Не очень хорошо, но чтож. В идеале костыль ставится временно, на релиз, а в следующем код заменяют нормальным. Не в идеале код остается унылым. Но бывает и такое.

Согласно википедии, тестирование надежности — один из видов автоматизированного тестирования ПО. Но это не так. Посмотрите на цели тестирования, посмотрите на мои примеры из жизни — эти баги ловятся без автоматизации. 

Так что да, в идеале это автоматизируется. Но если вы не умеете автоматизировать и автоматизации на проекте нет — это не значит, что надежность проверить нельзя. Можно, используя тур «чашки кофе» . Включили приложение и оставили его куковать. 

Для этого нужны специальные стенды — тестовые то обновляются каждый день, как разработчик сборку новую выкатит. Поэтому, если нет отдельного стенда, который обновляется РЕДКО, вы можете упустить проблемы с утечками памяти. Просто не успеете упереться в лимит. Учтите это!

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков