Какие объекты следует проверить в ходе тестирования интерактивной справки программного продукта

Обновлено: 07.07.2024

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

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

Уровни тестирования

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

Интеграционное тестирование – это процесс исследования ПО, при котором тестируется интерфейсы между компонентами или подсистемами.

Системное тестирование – это процесс исследования ПО, при котором тестируется интегрированная система на её соответствие требованиям заказчика. Альфа и Бета тестирование относятся к подкатегориям системного тестирования.

Классификация видов тестирования

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

По объекту тестирования

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

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

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

Стресс-тестирование (stress testing) – тестирование ПО, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Это проверка программы в таких стрессовых ситуациях как наличие большого объёма входных параметров, нехватка дискового пространства или маломощный процессор.

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

Тестирование стабильности (stability/endurance/soak testing) – тестирование ПО, при котором проверяется работоспособность ПО при длительном тестировании со среднем уровнем нагрузки.

Тестирование безопасности (security testing) – тестирование ПО, которое проверяет фактическую реакцию защитных механизмов, встроенных в систему на проникновение злоумышленников.

Тестирование совместимости (compatibility testing) - тестирование ПО, которое проверяет работоспособность ПО в определенном окружении.

По знанию системы

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

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

По времени проведения тестирования

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

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

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

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

По степени автоматизации

Ручное тестирование (manual testing) – тестирование при котором не используются программные средства для выполнения тестов и проверки результатов выполнения.

Автоматизированное тестирование (automated testing) – тестирование, при котором используются программные средства для выполнения тестов и проверки результатов выполнения. Автоматизированное тестирование, несомненно, приносит пользу и экономит время и ресурсы компании.

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

Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них: HP LoadRunner, HP QuickTest Professional, HP Quality Center, TestComplete.

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

Динамический и статический анализ кода

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

Динамический анализ кода (runtime analysis) – способ анализа программы непосредственно при ее выполнении. При динамическом анализе проблемы в исходном коде находятся по мере их возникновения. Процесс анализа можно разбить на несколько этапов - подготовка исходных данных, проведение тестового запуска программы, сбор необходимых параметров и анализ полученных данных.

Статический анализ кода (static analysis) - анализ программы, производимый без реального выполнения исследуемых программ. Статический анализ кода позволяет обнаружить дефекты в исходном коде до того, как код будет готов для запуска.

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

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

3.1. Задачи и цели тестирования программного кода

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2. Методы тестирования

3.2.1. Черный ящик

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

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

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

Несоответствие поведения системы требованиям
Неадекватное поведение системы в ситуациях, не предусмотренных требованиями.

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

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

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

3.2.2. Стеклянный (белый) ящик

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

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

3.2.3. Тестирование моделей

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

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

3.2.4. Анализ программного кода (инспекции)

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

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

3.3. Тестовое окружение

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

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

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

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

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

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

Уровень тестирования Для каждого уровня тестирования может быть определено: Цель Объекты тестирования Прослеживание связи с базисом тестирования (при наличии) Критерии входа и выхода Артефакты процесса тестирования, которые будет поставлять отдел тестирования - тестовые сценарии, протоколы тестирования, отчетность о результатах и другие Тестовые методики Измерения и метрики Инструментарий

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

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

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

ПРИЕМЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ Ручной (экспертный анализ) Статически анализ безопасности (по шаблону) Динамический анализ безопасности

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

Используются средства автоматизированного поиска уязвимостей кода PREfix, FlawFinder, RATS, UCA, ITS4, АК-ВС и другие. Каждая испытательная лаборатория или даже отдельный департамент тестирования используют свои собственные базы сигнатур. Можно воспользоваться положительной практикой уже существующей в международных проектах CWE, либо известным ресурсом для Web-приложений OWASP .

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

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Уровни тестирования: Модульное тестирование (Unit testing) Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008–87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Уровни тестирования: Интеграционное тестирование (Integration testing) Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями. Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно-ориентированных архитектурах (SOA).

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Уровни тестирования: Системное тестирование (System testing) Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Приёмочное тестирование (Acceptance/qualification testing) Проверяет поведение системы на предмет удовлетворения требований заказчика.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Установочное тестирование (Installation testing) Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Альфа- и бета-тестирование (Alpha and beta testing) Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing) Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Достижение и оценка надежности (Reliability achievement and evaluation) Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Регрессионное тестирование (Regression testing) Определение успешности регрессионных тестов (IEEE 610–90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Тестирование производительности (Performance testing) Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Нагрузочное тестирование (Stress testing) Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Сравнительное тестирование (Back-to-back testing) Единичный набор тестов, позволяющих сравнить две версии системы.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Восстановительные тесты (Recovery testing) Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster), влияющей на функционирование операционной среды, в которой выполняется система.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Конфигурационное тестирование (Configuration testing) В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Виды тестирования: Тестирование удобства и простоты использования (Usability testing) Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Техники, ориентированные на код (Code-based techniques): Тесты, базирующиеся на блок-схеме (Control-flow-based criteria) Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватность таких тестов оценивается как процент покрытия всех возможных путей блок-схемы.

ТРАДИЦИОННЫЕ МЕТОДЫ И ПОДХОДЫ ТЕСТИРОВАНИЯ Техники, ориентированные на код (Code-based techniques): Тесты на основе потоков данных (Data-flow-based criteria) В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования.

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

Что за уровни тестирования? Что тестируется на каждом из них? Какие у них цели? Разберем в статье.

Чтобы было проще разбираться во всех терминах, давайте упростим изучение и разобьем виды тестирования на две составляющие:
1. Уровни тестирования
2. Типы тестирования

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

Схематичное разделение уровней и типов тестирования

В первую очередь рассмотрим уровни тестирования. Выделяют 4 основных уровня тестирования:
1. Компонентное/модульное тестирование (Component/Unit Testing).
2. Интеграционное тестирование (Integration Testing).
3. Системное тестирование (System Testing).
4. Приемочное тестирование (Acceptance Testing).

Каждый уровень тестирования направлен на определенную часть программы и выполняет свои цели.

Компонентное/модульное тестирование

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

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

Модульное тестирование

Для этого уровня тестирования характерно несколько целей:
1. Проверка компонента на соответствие требованиям,
2. Обнаружение ошибок в компоненте,
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

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

Интеграционное тестирование

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

В общем случае различают два вида интеграционного тестирования:

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

Компонентное интеграционное тестирование

— Системноеинтеграционное тестирование. Если с предыдущим уровнем тестирования все понятно, то с системным интеграционным тестирование все несколько сложнее. Этот уровень необходим для тестирования систем друг с другом.

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

Системное интеграционное тестирование

Для этого уровня тестирования также характерно несколько целей:
1. Проверка интерфейсов на соответствие требованиям.
2. Обнаружение ошибок в интерфейсах.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

С помощью интеграционного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.

Системное тестирование

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

Системное тестирование

Для этого уровня тестирования также характерно несколькоцелей:
1. Проверка системы на соответствие требованиям.
2. Обнаружение ошибок в системе.
3. Предотвращение пропуска ошибок на более высокие уровни тестирования.

С помощью системного тестирования мы снижаем риски и укрепляем свою уверенность в качестве продукта.

Приемочное тестирование

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

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

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

У приемочного тестирования есть также несколько целей:
1. Показать, что программа завершена и готова к использованию так, как от нее ожидалось.
2. Проверить, что работа программы соответствует установленному ТЗ или требованиям.

Также, на этом уровне тестирования мы показываем уверенность в качестве системы.

По версии ISTQB существует несколько форм приемочного тестирования:
1. Пользовательское приемочное тестирование.
2. Эксплуатационное приемочное тестирование.
3. Контрактное и нормативное приемочное тестирование.
4. Альфа- и Бета-тестирование.

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

С другой стороны стоит эксплуатационное приемочное тестирование. Его отличие заключается в том, что мы проводим тестирование не с позиции пользователей, а с позиции тех, кто будет поддерживать работу программы. Наша задача — убедиться в работоспособности таких аспектов, как:
1. Возможность резервного копирования и восстановления данных.
2. Установка, удаление и обновление программы.
3. Восстановление после полного падения системы.
4. Управление пользователями.
5. Возможность сопровождения (обслуживания).
6. Возможность загрузки и миграции данных.
7. Отсутствия уязвимостей.
8. Хорошая производительность.

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

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

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

Уровни тестирования

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

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