Какой вид тестирования направлен на проверку взаимодействия между несколькими частями приложения
Тестирование можно классифицировать по очень большому количеству признаков, и практически в каждой серьёзной книге о тестировании автор показывает свой (безусловно имеющий право на существование) взгляд на этот вопрос.
Соответствующий материал достаточно объёмен и сложен, а глубокое понимание каждого пункта в классификации требует определённого опыта, потому мы разделим данную тему на две: сейчас мы рассмотрим самый простой, минимальный набор информации, необходимый начинающему тестировщику, а в следующей главе приведём подробную классификацию.
Используйте нижеприведённый список как очень краткую «шпаргалку для запоминания». Итак, тестирование можно классифицировать:
Рисунок 1 Упрощённая классификация тестирования.
По запуску кода на исполнение:
· Статическое тестирование — без запуска.
· Динамическое тестирование — с запуском.
По доступу к коду и архитектуре приложения:
· Метод белого ящика — доступ к коду есть.
· Метод чёрного ящика — доступа к коду нет.
· Метод серого ящика — к части кода доступ есть, к части — нет.
По степени автоматизации:
· Ручное тестирование — тест-кейсы выполняет человек.
· Автоматизированное тестирование — тест-кейсы частично или полностью выполняет специальное инструментальное средство.
По уровню детализации приложения (по уровню тестирования):
· Модульное (компонентное) тестирование — проверяются отдельные небольшие части приложения.
· Интеграционное тестирование — проверяется взаимодействие между несколькими частями приложения.
· Системное тестирование — приложение проверяется как единое целое.
По (убыванию) степени важности тестируемых функций (по уровню функционального тестирования):
· Дымовое тестирование — проверка самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной саму идею использования приложения.
· Тестирование критического пути — проверка функциональности, используемой типичными пользователями в типичной повседневной деятельности.
· Расширенное тестирование — проверка всей (остальной) функциональности, заявленной в требованиях.
По принципам работы с приложением:
· Позитивное тестирование — все действия с приложением выполняются строго по инструкции ни без каких недопустимых действий, некорректных данных и т.д. Можно образно сказать, что приложение исследуется в «тепличных условиях».
· Негативное тестирование — в работе с приложением выполняются (некорректные) операции и используются данные, потенциально приводящие к ошибкам (классика жанра — деление на ноль).
Часто возникает вопрос о том, чем различаются «тип тестирования», «вид тестирования», «способ тестирования», «подход к тестированию» и т.д. и т.п. Если вас интересует строгий формальный ответ, посмотрите в направлении таких вещей как «таксономия» и «таксон», т.к. сам вопрос выходит за рамки тестирования как такового и относится уже к области науки.
Но исторически так сложилось, что как минимум «тип тестирования» (testing type) и «вид тестирования» (testing kind) давно стали синонимами.
Тестирование на разных уровнях производится на протяжении всего жизненного цикла разработки и сопровождения программного обеспечения. Уровень тестирования определяет то, над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом. Проведение тестирования на всех уровнях системы - это залог успешной реализации и сдачи проекта.
Модульное тестирование ( Unit testing) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция, небольшие библиотеки, отдельные части приложения. Как правило их можно исследовать изолированно друг от друга.
Часто модульное тестирование осуществляется разработчиками программного обеспечения.
Интеграционное тестирование ( Integration testing) - тестируются интерфейсы между компонентами, подсистемами или системами.
Направлено на проверку взаимодействия между несколькими частями приложения (каждая из которых была проверена на модульной стадии тестирования). При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
Системное тестирование ( System testing) - тестируется интегрированная система на её соответствие требованиям.
Направлено на проверку всего приложения, как единого целого, собранного из частей, проверенных на модульном и интеграционном уровнях.
Приемочное тестирование (Acceptance Testing) - это формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится, с целью определения удовлетворяет ли система приемочным критериям и вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.
Приемочное тестирование выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению. Решение о проведении приемочного тестирования принимается, когда: - продукт достиг необходимого уровня качества; - заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или другим документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные. Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения.
Для каждого уровня тестирования могут использоваться различные виды тестирования, для каждого из которых, в свою очередь, могут использоваться различные типы тестовых испытаний.
Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы:
- Функциональные.
- Нефункциональные.
- Связанные с изменениями.
Далее мы постараемся более подробно рассказать о каждом отдельном виде тестирования, его назначении и использовании при тестировании программного обеспечения.
Функциональные виды тестирования
Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (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)
Тестирование программного обеспечения это процесс испытания программного продукта с целью проверки соответствия между реальным и ожидаемым поведением программы. Для достижения указанной цели существует несколько Видов тестирования.
Виды Тестирования ПО можно разделить на несколько групп:
- Функциональные.
- Нефункциональные.
- Связанные с изменениями.
![]()
Основные функциональные виды тестирования
Первым, непосредственно, является Функциональное тестирование (Functional testing).
- Функциональная пригодность.
- Точность.
- Способность к взаимодействию.
- Соответствие стандартам и правилам.
- Защищенность.
Преимуществом именно этого тестирования является имитация фактического пользования системой. Но при этом, не стоит забывать о риске упущения логических ошибок в ПО, а также вероятности избыточного тестирования.
Вторым из распространенных видов является Тестирование безопасности (Security and Access Control Testing).
Данная стратегия направлена на проверку безопасности системы, а также на анализ рисков, связанных с обеспечением защиты от различного вида атак.
Целостность подразумевает ожидание, что ресурс может получать изменения лишь определенным способом и от определенной группы пользователей. При этом, в случае повреждения данных, есть оценка насколько важной является процедура их восстановления.
Доступность же, представляет собой сами требования о том, насколько ресурсы должны быть доступны авторизованному пользователю/объекту/устройству. Соответственно, чем критичнее ресурс, тем выше установлен и уровень доступности.
Говоря о функциональном тестировании не стоит забывать и про Тестирование взаимодействия (Interoperability Testing).
Включая в себя Тестирование Совместимости (compatibility testing) и Интеграционное Тестирование (integration testing). Тестирование взаимодействия направлено на проверку способности приложения взаимодействовать с одним и более компонентами или системами.
ПО с хорошими показателями взаимодействия может быть легко интегрировано с другими системами, при этом, без необходимости в серьезных модификациях.Основные нефункциональные виды тестирования
В отличии от функционального тестирования, Нефункциональное направлено на проверку реализуемости нефункциональных требований.
- Производительность.
- Удобство пользования.
- Портируемость (установки).
- Надежность (отказ/восстановление).
Нефункциональное тестирование не проверяет систему на выполнение тех функций, которые хочет от него заказчик, зато оно позволяет контролировать более глобальные свойства:
- работоспособность системы под различными нагрузками;
- требования к масштабируемости приложения;
- адаптация приложения для различных платформ;
- гарантия продолжения работы приложения даже в случаях непредвиденных ситуаций.
Первым видом нефункционального тестирования мы выделим:
Тестирование производительности (Performance and Load Testing).
Данный вид подразумевает собой автоматизированное тестирование, имитирующее работу определенного количества пользователей на ресурсе.
У него также есть свои виды:Вторым видом нефункционального тестирования является Тестирование Установки (Installation testing).
Этот вид направлен на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.
Стоит учитывать, что полноценным тестированием в данном случае будет являться не проверка успешной работы инсталлятора, к которым мы успели привыкнуть. Тестированием Установки, в данном случае, будет написание плана установки, содержащего и шаги по инсталляции приложения, и шаги отката к предыдущей версии. Важно помнить, что и сам план установки должен проходить тестирование.
Тестирование Удобства Пользования (Usability Testing), будет следующим видом, который мы рассмотрим.
Тестирование на Отказ и Восстановление (Failover and Recovery Testing) проверяет продукт на возможность сопротивления и успешного восстановления в последствиях возможных сбоев возникших из-за ошибок ПО, оборудования или прерывания связи.
![]()
Связанные с изменениями виды тестирования
После исправления бага/дефекта необходимо повторное тестирование, с целью убедиться, что внесенные изменения действительно решили проблему. Также, для любого проекта, необходимо и подтверждение работоспособности приложения.
В таких случаях принято использовать:
Осуществляется оно на основе результатов поверхностного тестирования только важных модулей приложения, на предмет возможности выполнения требуемых задач и наличия быстро находимых критических и блокирующих дефектов.
Данный вид должен выполняться перед проведением Регрессионного Тестирования и, сравнительно, будет иметь меньший охват функционала при проверке.Регрессионное тестирование фиксирует и факт того, что ранее найденный дефект был исправлен, и отсутствие возникновения новых дефектов в системе.
Регрессионными могут быть оба вида тестов (как функциональные, так и нефункциональные).В заключении
Читайте также:
