Какой метод тестирования используется для определения возможности масштабируемости приложения

Обновлено: 06.01.2025

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

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

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функционтальности компонента или системы в целом.

1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

Преимущества функционального тестирования:

Недостатки функционального тестирования:

возможность упущения логических ошибок в программном обеспечении;
вероятность избыточного тестирования.

Достаточно распространенной является автоматизация функционального тестирования.

2. Тестирование безопасности (Security and Access Control Testing)

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

Конфиденциальность

Целостность

Существует два основных критерия при определении понятия целостности:

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

Доступность

Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть.

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

Нефункциональные виды тестирования

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

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

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

Стрессовое тестирование ( Stress Testing )

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

Объемное тестирование ( Volume Testing )

Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:

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

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

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

2. Тестирование Установки (Installation Testing)

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

3. Тестирование удобства пользования (Usability Testing)

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

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

Уровни проведения

Советы по улучшению удобства пользования:

Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример: если поле требует цифровое значение,то логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

Заблуждения о тестировании удобства пользования:

Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

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

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

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

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

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

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

Для наглядности, рассмотрим некоторые варианты подобного тестирования и общие методы их проведения. Объектом тестирования, в большинстве случаев, являются весьма вероятные эксплуатационные проблемы, такие как:

Отказ электричества на компьютере-сервере.
Отказ электричества на компьютере-клиенте.
Незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации).
Объявление или внесение в массивы данных невозможных или ошибочных элементов.
Отказ носителей данных.

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

Симулировать внезапный отказ электричества на компьютере (обесточить компьютер).
Симулировать потерю связи с сетью (выключить сетевой кабель, обесточить сетевое устройство).
Симулировать отказ носителей (обесточить внешний носитель данных).
Симулировать ситуацию наличия в системе неверных данных (специальный тестовый набор или база данных).

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

Потеря или порча данных в допустимых пределах.
Отчет или система отчетов, с указанием процессов или транзакций, которые не были завершены в результате сбоя.

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

5. Конфигурационное тестирование (Configuration Testing)

Конфигурационное тестирование(Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости(portability testing: The process of testing to determine the portability of a software product.).

Связанные с изменениями виды тестирования

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

1. Дымовое тестирование (Smoke Testing)

Понятие дымовое тестирование пошло из инженерной среды:

В области же программного обеспечения дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что, после сборки кода (нового или исправленного), устанавливаемое приложение стартует и выполняет основные функции.

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

Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.

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

2. Регрессионное тестирование (Regression Testing)

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

3. Тестирование сборки (Build Verification Test)

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

4. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

Наша система тестирования довольно рудиментарна; запустите браузер, посмотрите, работает ли он. Недавно мы столкнулись с проблемами, обнаруженными нашим клиентом, с нашим приложением, где количество пользователей создало замедление в приложении. Приложение в основном представляет собой огромный документ Word, в котором люди одновременно редактируют свои собственные версии. Часть проблемы возникла из-за незнания того, как тестировать несколько экземпляров одновременно. Мой партнер и я подумали о том, как проверить это; одна идея заключалась в том, чтобы нанять интернет-кафе и нанять студентов в течение часа, чтобы взломать приложение.

Какими другими способами люди пытались подражать concurrency при тестировании своего веб-приложения? Большинство рекомендаций здесь для конкретной методологии; Я спрашиваю, как вы тестируете его, чтобы убедиться, что он работает?

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

В идеале вы могли бы использовать тот же самый script и загружать его в кучу ящиков и запускать их все сразу, чтобы получить какое-то тестирование нагрузки прямо? К счастью для вас, кто-то уже понял это, хотя это платная услуга: Browser Mob. Но, похоже, вы были готовы потратить немного денег, чтобы сделать это в любом случае, и, вероятно, вы могли бы получить больше, более повторяемые результаты.

Я нахожу, что это помогает рассмотреть различать несколько различных типов тестирования; concurrency (что происходит, когда два события в системе сталкиваются), емкость (что происходит, когда есть много перекрывающихся запросов), том (что происходит, когда данные накапливаются в системе).

Огромное общее замедление, о чем свидетельствуют времена ответа, выходящие за пределы SLA, обычно связаны с проблемами пропускной способности (с утверждением как общей причиной) или объемом (многие пользователи, многие данные и система становятся медленнее с течением времени), Первый обычно требует своего рода многопоточного потока запросов; последнее вы обычно можете управлять путем предварительной загрузки тома, а затем измерения времени отклика, испытываемого одним пользователем.

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Тестирование функциональности может проводиться в двух аспектах:

2. Тестирование безопасности (Security and Access Control Testing)

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

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

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

Существует два основных критерия при определении понятия целостности:

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

3. Тестирование взаимодействия или Interoperability Testing

Тестирование производительности ( Performance testing ).

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

Определение количества пользователей, одновременно работающих с приложением.

Определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций).

Исследование производительности на высоких, предельных, стрессовых нагрузках.

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

Может производиться определение количества пользователей, одновременно работающих с приложением.

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

В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

В настоящий момент, наиболее распространена установка ПО при помощи инсталляторов (специальных программ,которые сами по себе так же требуют надлежащего тестирования, описание которого рассмотрено в разделе "Особенности тестирования инсталляторов").

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

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

3. Тестирование удобства пользования (Usability Testing)

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

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

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

Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (SanityTesting)

Тестирование сборки состоит из набора коротких тестов, которые и определяют готовность сборки.

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

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

Нет, выполнение любого вида тестирования требует специальных знаний и профессиональной подготовки.

Полная автоматизация невозможна. Необходимо использовать также и ручное тестирование.

Тестирование может быть очень непростым занятием. Проведение тестирования для проверки максимально возможного количества путей выполнения с использованием минимального числа тест-кейсов требует серьезных аналитических навыков.

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

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

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

Существует несколько основных видов автоматизированного тестирования:

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:

Неформальные. При неофициальном рассмотрении создатель документов показывает содержание документов аудитории. Каждый присутствующий высказывает свое мнение, что позволяет выявить недостатки на ранней стадии.
Сквозные просмотры (Walkthroughs). Выполняются опытным человеком или экспертом для проверки отсутствия дефектов, с целью предупреждения возникновения проблем на этапе разработки или тестирования.
Экспертная оценка. Означает проверку документов для выявления и исправления дефектов. В основном это делается в команде.
Инспектирование ПО. Это, в большинстве, проверка документа вышестоящим органом, например, проверка требований к программному обеспечению.

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

В рамках этого подхода тестированию могут подвергаться:

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

Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.

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

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

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

Понятие дымовое тестирование пошло из инженерной среды:

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

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

Регрессионное тестирование (по некоторым источникам) включает new bug-fix - проверка исправления найденного ранее дефекта, old bug-fix - проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect - проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.

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

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

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

Приемочное тестирование или Приемо-сдаточное испытание (User Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

продукт достиг необходимого уровня качества;
заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения.

V. Виды тестирования по доступу к коду (методы тестирования)

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

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

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

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

Зачем нужно тестирование масштабируемости

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

Что тестировать в тестировании масштабируемости

Вот несколько атрибутов тестирования масштабируемости:

Время отклика
Переход экрана
Пропускная способность
Время (время сеанса, время перезагрузки, время печати, время транзакции, время выполнения задачи)
Измерение производительности с количеством пользователей
Запрос в секунду, Транзакция в секунду, Хиты в секунду
Измерение производительности с количеством пользователей
Использование сети
Использование ЦП / памяти
Веб-сервер (запрос и ответ в секунду)
Измерение производительности под нагрузкой

Стратегия тестирования для тестирования масштабируемости

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

Предварительные условия для тестирования масштабируемости

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

Как проводить тестирование масштабируемости

Определите повторяемый процесс для выполнения тестов масштабируемости на протяжении всего жизненного цикла приложения.
Определите критерии масштабируемости
Составьте короткий список программных инструментов, необходимых для запуска нагрузочного теста.
Установите среду тестирования и настройте оборудование, необходимое для выполнения тестов масштабируемости.
Планируйте сценарии тестирования, а также тесты масштабируемости
Создать и проверить визуальный сценарий
Создание и проверка сценариев нагрузочного тестирования
Выполнить тесты
Оцените результаты
Создавать необходимые отчеты

План тестирования масштабируемости

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

Ниже приведены атрибуты для создания четко определенного плана тестирования для тестирования масштабируемости.

Читайте также: