Тестирование программного обеспечения. Уровни тестирования. Методы тестирования. Этапы тестирования. Виды тестирования

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

 

5. Модифицированный метод сандвича

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

 

6. Метод «белого ящика»

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

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

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

– Дают гарантию того, что все независимые пути в модуле проверены по крайней мере один раз.

– Проверяют все логические решения на предмет того, истины они или ложны.

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

– Исследуют структуры внутренних данных с целью проверки их достоверности.

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

На этом уровне тестирования проверяется управляющая логика, проявляющаяся на модульном уровне.

 

7. Метод «черного ящика»

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

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

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

– Неверная или пропущенная функциональность;

– Ошибки интерфейса;

– Проблемы удобства использования;

– Ошибки в структурах данных или ошибки доступа к внешним базам данных;

– Проблемы снижения производительности и другие ошибки производительности;

– Ошибки загрузки;

– Ошибки многопользовательского доступа;

–Ошибки инициализации и завершения;

–Проблемы сохранения резервных копий и способности к восстановлению работы;

–Проблемы безопасности.

 

4. Этапы тестирования программного обеспечения

 

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

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

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

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

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

– Определить критерии входа и выхода для каждой стадии тестирования, равно как и все точки контроля качества.

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

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

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

 

5. Виды тестирования

 

Различают следующие виды тестирования:

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

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

В тестировании производительности различают следующие направления:

– нагрузочное тестирование;

– стресс–тестирование;

– тестирование стабильности;

– конфигурационное тестирование.

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

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

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

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

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