Может ли повысить надежность программы процесс тестирования

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

Обзор

Надежность программного обеспечения — это вероятность того, что программное обеспечение будет работать должным образом в определенной среде и в течение определенного периода времени. Используя следующую формулу, вероятность отказа рассчитывается путем тестирования выборки всех доступных входных состояний. Среднее время наработки на отказ (MTBF) = Среднее время наработки на отказ (MTTF) + Среднее время восстановления (MTTR)

Вероятность = Число случаев отказа / Общее количество рассматриваемых случаев

Набор всех возможных состояний входа называется входным пространством. Чтобы определить надежность программного обеспечения, нам нужно найти выходное пространство из заданного входного пространства и программного обеспечения.

Что влияет на качество и сроки тестирования ПО?

Для тестирования надежности данные собираются на различных этапах разработки, таких как этапы проектирования и эксплуатации. Тесты ограничены из-за ограничений, таких как ограничения по стоимости и времени. Статистические образцы получаются из программных продуктов для проверки надежности программного обеспечения.

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

1. время работы,
2. количество циклов включения / выключения,
3. и календарное время.

Если ограничения касаются времени работы или, если основное внимание уделяется первому моменту улучшения, то можно применить сжатые временные ускорения, чтобы сократить время тестирования. Если основное внимание уделяется календарному времени (т. Е. Если есть предопределенные сроки), то используется усиленное стресс-тестирование.

Измерение

Программное обеспечение доступность измеряется как среднее время наработки на отказ (MTBF).

MTBF состоит из среднего времени до отказа (MTTF) и среднего времени на ремонт (MTTR). MTTF — это разница во времени между двумя последовательными сбоями, а MTTR — это время, необходимое для устранения сбоя.

MTBF = MTTF + MTTR

Устойчивое состояние доступность представляет процент работоспособности программного обеспечения.

Как построить процесс тестирования с нуля?

Например, если MTTF = 1000 часов для программного обеспечения оно должно работать в течение 1000 часов непрерывной работы.

Для того же программного обеспечения, если MTTR = 2 часа, то MTBF = 1000 + 2 = 1002 .

Надежность программного обеспечения измеряется частотой отказов ( λ ).

Надежность программного обеспечения — это число от 0 до 1. Надежность повышается, когда ошибки или ошибки из программы удаляются. Существует множество моделей повышения надежности программного обеспечения (SRGM) (Список моделей надежности программного обеспечения ), включая логарифмические, полиномиальные, экспоненциальные, степенные и S-образные

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

Основная цель тестирования надежности — проверить производительность программного обеспечения в заданных условиях без каких-либо корректирующих мер с использованием известных фиксированных процедур с учетом его спецификаций.

Вторичные цели

Вторичные цели тестирования надежности:

1. Найти структуру восприятия повторяющихся отказов.
2. Найти количество отказов, возникающих в указанном количестве времени.
3. Чтобы узнать средний срок службы программного обеспечения.
4. Чтобы определить основную причину сбоя.
5. Проверка производительности различных модулей программного обеспечения после принятия превентивных действий.

Пункты для определения целей

Некоторые ограничения на создание целей включают:

1. Поведение программного обеспечения должно быть определено в данных условиях.
2. Цель должна быть достижимой.
3. Должны быть предусмотрены временные ограничения.

Важность тестирования надежности

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

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

Чтобы проверить надежность программного обеспечения посредством тестирования:

1. Необходимо выполнить достаточное количество тестовых примеров для достаточного количества тестов. время, чтобы получить разумную оценку того, как долго программа будет работать без сбоев. Необходимы длительные тесты для выявления дефектов (например, утечки памяти и переполнения буфера), которые требуют времени, чтобы вызвать сбой или сбой.
2. Распределение тестовых примеров должно соответствовать фактическому или запланированному рабочему профилю программного обеспечения. Чем чаще выполняется функция или подмножество программного обеспечения, тем больший процент тестовых примеров следует назначать этой функции или подмножеству.

Типы тестирования надежности

Тестирование надежности программного обеспечения включает тестирование функций, нагрузочное тестирование и регрессионное тестирование.

Тест функций

Тестирование функций проверяет функции, предоставляемые программным обеспечением, и проводится в следующие этапы:

• Каждая операция в программном обеспечении выполняется один раз.
• Взаимодействие между двумя операциями сокращается, и
• каждая операция проверяется на предмет ее правильного выполнения.

За функциональным тестом следует нагрузочный тест.

Нагрузочный тест

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

Регрессионный тест

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

Планирование тестирования

Тестирование надежности более затратно по сравнению с другими типами тестирования. Таким образом, при проведении тестирования надежности требуются надлежащее управление и планирование. Этот план включает в себя процесс тестирования, который должен быть реализован, данные о его среде, график тестирования, точки тестирования и т. Д.

Проблемы при разработке тестовых примеров

Некоторые общие проблемы, возникающие при разработке тестовых примеров, включают:

• Тестовые примеры можно разработать, просто выбрав только допустимые входные значения для каждого поля в программе. Когда в конкретный модуль вносятся изменения, предыдущие значения могут фактически не тестировать новые функции, представленные после более старой версии программного обеспечения.
• В программном обеспечении могут быть некоторые критические прогоны, которые не обрабатываются никаким существующим тестом кейс. Следовательно, необходимо обеспечить рассмотрение всех возможных типов тестовых примеров путем тщательного выбора тестовых примеров.

Повышение надежности за счет тестирования

Исследования во время разработки и проектирования программного обеспечения помогают повысить надежность продукта. Тестирование надежности в основном выполняется для исключения режима отказа программного обеспечения. Жизненные испытания продукта всегда следует проводить после завершения проектной части или, по крайней мере, после завершения всего проекта. Анализ отказов и улучшение конструкции достигается посредством испытаний.

Тестирование роста надежности

Это тестирование используется для проверки новых прототипов программного обеспечения, которые изначально должны часто выходить из строя. Выявляются причины неисправности и принимаются меры по их уменьшению. Предположим, T — общее время, накопленное для прототипа. n (T) — количество отказов от начала до момента времени T. График n (T) / T представляет собой прямую линию. Этот график называется графиком Дуэйна. Можно узнать, сколько надежности можно получить после всех остальных циклов тестирования, и исправить это.

l n [n (T) T] = — α l n (T) + b;. E q: 1 ln left [ > right] = — alpha ln left (T вправо) + b; . Уравнение: 1 end >>

решение уравнения 1 для n (T),

n (T) = KT 1 — α;. E q: 2 n left (T right) = KT ^ ; . Eq: 2 end >>

где K — e ^ b. Если значение альфа в уравнении равно нулю, надежность не может быть улучшена, как ожидалось, для данного количества отказов. Если альфа больше нуля, совокупное время T увеличивается. Это объясняет, что количество отказов не зависит от продолжительности теста.

Разработка тестовых примеров для текущего выпуска

Если в текущую версию программного обеспечения добавляются новые функции, то написание тестового примера для этой операции выполняется иначе.

• Сначала спланируйте, сколько новых тестовых примеров нужно написать для текущей версии.
• Если новая функция является частью какой-либо существующей функции, тогда поделитесь между ними тестовыми примерами новых и существующих функций.
• Наконец, объедините все тестовые примеры из текущей версии и предыдущей и запишите все результаты.

Существует предопределенное правило для подсчета количества новых тестовых примеров для программного обеспечения. Если N — вероятность появления новых операций для новой версии программного обеспечения, R — вероятность появления использованных операций в текущем выпуске, а T — количество всех ранее использованных тестовых примеров, тогда

Новые тестовые случаи ( currentrelease) = (NR) * T NewTestcases _ = left ( > right) * T end >>

Оценка надежности на основе эксплуатационного тестирования

Метод эксплуатационного тестирования используется для проверки надежности программного обеспечения.

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

Для тестирования надежности программного обеспечения используются два метода:

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

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

Оценка и прогноз роста надежности

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

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

Оценка надежности на основе безотказной работы

В этом случае надежность программного обеспечения оценивается с использованием следующих допущений:

• Если обнаружен дефект, значит, он исправлен? должны быть исправлены кем-либо.
• Исправление дефекта не повлияет на надежность программного обеспечения.
• Каждое исправление в программном обеспечении является точным.

См. также

• Программное обеспечение тестирование
• Нагрузочное тестирование
• Регрессионное тестирование
• Разработка надежности
• Список моделей надежности программного обеспечения

Ссылки

Внешние ссылки

• Среднее время наработки на отказ
• Тестирование срока службы программного обеспечения

Источник: alphapedia.ru

Тестирование

Тестирование — это процесс выполнения программы с целью обнаружения ошибок» [2]. Следует подчеркнуть, что цель тестирования — это именно обнаружение, выявление ошибок, а не демонстрация их отсутствия (к сожалению, данный подход к тестированию тоже имеет место).

В основе тестирования лежит процесс подачи на вход программной системы ряда совокупностей входных данных, называемых обычно тестовыми комбинациями, результаты обработки которых заранее известны. Сравнение полученных результатов с эталонными дает возможность сделать вывод о правильности работы ПО в конкретной ситуации. Существуют две стратегии тестирования [2]:

• • стратегия «черного ящика»;
• • стратегия «белого ящика».

Первая стратегия основана на рассмотрении тестируемого объекта с внешней точки зрения (как кибернетического «черного ящика») по входу-выходу, без учета внутренней структуры и логики проверяемой программы.

Стратегия «белого ящика» предполагает знание внутренней структуры тестируемой программы. Подбор тестовых комбинаций в этом случае ведется по определенным правилам с учетом строения программы.

«Таким образом, если мы хотим, чтобы тестирование программы обеспечило нас существенной информацией, то процедуру тестирования следует разрабатывать с определенной тщательностью. Наиболее очевидный метод повышения вероятности обнаружения ошибок в программе путем тестирования заключается в создании таких тестов, когда каждый оператор программы исполняется по крайней мере однажды и с такими полученными по наследству векторами состояния, что если намеченное преобразование описывается оператором с ошибкой, то его исполнение должно привести к наблюдаемому неверному результату» [16].

Однако в известной нам монографии [2] и в ряде других работ убедительно показано, что ни та, ни другая стратегии не обеспечивают на практике построение «полного теста», проверяющего все возможные ситуации и дающего гарантии отсутствия ошибок в ПО. Неадекватность тестирования как способа доказательства правильности программы сформулирована в следующем известном высказывании Э. Дейкстры: «Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия» [13].

Тем не менее, в реальной жизни без тестирования не обойтись. Без тестирования немыслимы никакие испытания. Мало того, несмотря на очевидную неадекватность тестирования как средства доказательства отсутствия ошибок на практике оно часто таковым признается, и с этим приходится считаться.

Источник: studref.com

Жизнь — это движение! А тестирование — это жизнь 🙂

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

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

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

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

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

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

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

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

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

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

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

Поэтому, если приложение выжирает ресурсы, за этим нужно следить.

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

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

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

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

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

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

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

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

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

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

А если падения начались спустя пару месяцев, поди найди того, кто это исправит.

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

Но бывает и такое.

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

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

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

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

Источник: okiseleva.blogspot.com