учебники, программирование, основы, введение в,

 

Разновидности тестирования: системное и регрессионное тестирование

Системное тестирование
Системное тестирование качественно отличается от интеграционного и модульного уровней. Системное тестирование рассматривает тестируемую систему в целом и оперирует на уровне пользовательских интерфейсов, в отличие от последних фаз интеграционного тестирования, которое оперирует на уровне интерфейсов модулей. Различны и цели этих уровней тестирования. На уровне системы часто сложно и малоэффективно анализировать прохождение тестовых траекторий внутри программы или отслеживать правильность работы конкретных функций. Основная задача системного тестирования" в выявлении дефектов, связанных с работой системы в целом, таких как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство в применении и тому подобное.
Системное тестирование производится над проектом в целом с помощью метода «черного ящика». Структура программы не имеет никакого значения, для проверки доступны только входы и выходы, видимые пользователю. Тестированию подлежат коды и пользовательская документация.
Категории тестов системного тестирования:

  1. Полнота решения функциональных задач.
  2. Стрессовое тестирование - на предельных объемах нагрузки входного потока.
  3. Корректность использования ресурсов (утечка памяти, возврат ресурсов).
  4. Оценка производительности.
  5. Эффективность защиты от искажения данных и некорректных действий.
  6. Проверка инсталляции и конфигурации на разных платформах.
  7. Корректность документации

Поскольку системное тестирование проводится на пользовательских интерфейсах, создается иллюзия того, что построение специальной системы автоматизации тестирования не всегда необходимо. Однако объемы данных на этом уровне таковы, что обычно более эффективным подходом является полная или частичная автоматизация тестирования, что приводит к созданию тестовой системы гораздо более сложной, чем система тестирования, применяемая на уровне тестирования модулей или их комбинаций. Обсуждению системной фазы тестирования, как наиболее сложной и критичной для процесса разработки, посвящен раздел 5.
Пример системного тестирования приложения «Поступление подшипника на склад»
В спецификации тестового случая задано состояние окружения (входные данные) и ожидаемая последовательность событий в системе (ожидаемый результат). После прогона тестового случая мы получаем реальную последовательность событий в системе при заданном состоянии окружения. Сравнивая фактический результат с ожидаемым, можно сделать вывод о том, прошла или не прошла тестируемая система испытание на заданном тестовом случае. В качестве ожидаемого результата будем использовать спецификацию тестового случая, поскольку она определяет, как, для заданного состояния окружения, система должна функционировать.
Спецификация тестового случая №1:
Состояние окружения (входные данные - X ):
Статус склада - 32. Пришел подшипник.
Статус обмена с терминалом подшипника (0 - есть подшипник) и его параметры - "Статус=0 Диаметр=12".
Статус обмена с терминалом оси (1 - нет оси) и ее параметры - "Статус=1 Диаметр=12".
"Статус=1 Диаметр=12".
Статус команды - 0. Команда успешно принята.
Сообщение от склада - 1. Команда успешно выполнена.
Ожидаемая последовательность событий (выходные данные – Y):
Система запрашивает статус склада (вызов функции GetStoreStat) и получает 32
Система запрашивает параметры подшипника (вызов функции GetRollerPar) и получает Статус = 0 Диаметр=12
Система запрашивает параметры оси (вызов функции GetAxlePar) и получает Статус = 1 Диаметр=0
Система добавляет в очередь команд склада на последнее место команду SendR (получить из приемника в ячейку) (вызов функции SendStoreCom) и получает сообщение о том, что команда успешно принята – статус = 0
Система запрашивает склад о результатах выполнения команды (вызов функции GetStoreMessage) и получает сообщение о том, что команда успешно выполнена - статус = 1
Выходные данные (результаты выполнения Yв) – зафиксированы в журнале теста
ВЫЗОВ: GetStoreStat                         
РЕЗУЛЬТАТ: 32
ВЫЗОВ: GetRollerPar
РЕЗУЛЬТАТ: Статус = 0 Диаметр = 12
ВЫЗОВ: GetAxlePar
РЕЗУЛЬТАТ: Статус = 1 Диаметр = 0
ВЫЗОВ: SendStoreCom
РЕЗУЛЬТАТ: 0
ВЫЗОВ: GetStoreMessage
РЕЗУЛЬТАТ: 1
Пример 7.1. Журнал теста
Приведенный натест был разработан в соответствии со спецификацией тестового случая №1. Детальная спецификация приведена в FS (Практикум, Приложение 1), результаты прогона показаны на.
Пример 7.2. Тест для системного тестирования
Пример 7.2.1. Тест для системного тестирования (C++)
После завершения теста следует просмотреть текстовый журнал теста, чтобы выяснить, какая последовательность событий в системе была реально зафиксирована (выходные данные) и сравнить их с ожидаемыми результатами, заданными в спецификации тестового случая1. Пример журнала теста :
Test started
CALL:GetStoreStat 0
RETURN:32
CALL:GetRollerPar
RETURN:0 NewUser Depot1 123456 1 12 1 1
CALL:GetAxlePar
RETURN:1 NewUser Depot1 123456 1 0 12 12
CALL:SendStoreCom 1 0 0 1 0 0 0
RETURN:0
CALL:GetStoreMessage
RETURN:1
Пример 7.3. Тестовый журнал для случая прогона системного теста
Регрессионное тестирование
Регрессионное тестирование- цикл тестирования, который производится при внесении изменений на фазе системного тестированияили сопровождения продукта. Главная проблема регрессионного тестирования- выбор между полным и частичным перетестированиеми пополнение тестовых наборов. При частичном перетестировании контролируются только те части проекта, которые связаны с измененными компонентами. На ГМП это пути, содержащие измененные узлы, и, как правило, это методы и классы, лежащие выше модифицированных по уровню, но содержащие их в своем контексте
Пропуск огромного объема тестов, характерного для этапа системного тестирования, удается осуществить без потери качественных показателей продукта только с помощью регрессионного подхода. В данном пособии регрессионному тестированию посвящен раздел 6.
Пример регрессионного тестирования
Получив отчет об ошибке, программист анализирует исходный код, находит ошибку, исправляет ее и модульно или интеграционно тестирует результат.
В свою очередь тестировщик, проверяя внесенные программистом изменения, должен:

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

Например, при тестировании класса TСommandQueue запускаем тесты :
// Тест проверяет, создается ли объект
// типа TCommand и  добавляется ли он
// в конец очереди.
private void TCommandQueueTest1()
// Тест проверяет добавление команд
// в очередь на указанную позицию.
// Также проверяется правильность
// удаления команд из очереди. 
private void TCommandQueueTest2()
Пример 7.4. Набор тестов класса TСommandQueue
// Тест проверяет, создается ли объект
// типа TCommand и добавляется ли он
// в конец очереди.
void TCommandQueueTest1()
// Тест проверяет добавление команд
// в очередь на указанную позицию.
// Также проверяется правильность
// удаления команд из очереди. 
void TCommandQueueTest2()
Пример 7.4.1. Набор тестов класса TСommandQueue (C++)
При этом первый тест выполняется успешно, а второй нет, т.е. команда добавляется в конец очереди команд успешно, а на указанную позицию - нет. Разработчик анализирует код, который реализует тестируемую функциональность:
...
if ((Position<-1)&&
(Position<=this.Items.Count))
{
this.Items.Insert(Position, Command);
}
else
{
if (Position==-1)
{
this.Items.Add(Command);
}
}
Пример 7.5. Фрагмент кода с зафиксированным при тестировании дефектом
if ((Position <-1)&&(Position<=this.Items.Count))
{
this.Items.Insert(Position, Command);
}
else
{
if (Position==-1)
{
this.Items.Add(Command);
}
}
Пример 7.5.1. Фрагмент кода с зафиксированным при тестировании дефектом
Анализ показывает, что ошибка заключается в использовании неверного знака сравнения в первой строке фрагмента (помечено светлым тоном). Далее программист исправляет ошибку, например следующим образом:
...
if ((Position>=-1)&&
(Position<=this.Items.Count))
{
this.Items.Insert(Position, Command);
}
else
{
if (Position==-1)
{
this.Items.Add(Command);
}
}
...
Пример 7.6. Исправленный фрагмент кода
if ((Position>=-1)&&
(Position<=this.Items.Count))
{
this.Items.Insert(Position, Command);
}
else
{
if (Position==-1)
{
this.Items.Add(Command);
}
}
Пример 7.6.1. Исправленный фрагмент кода
Для проверки скорректированного кода хочется пропустить только тест TCommandQueueTest2. Можно убедиться, что тест TCommandQueueTest2 будет выполняться успешно. Однако одной этой проверки недостаточно. Если мы повторим пропуск двух тестов, то при запуске первого теста, TCommandQueueTest1, будет обнаружен новый дефект. Повторный анализ кода показывает, что ветка else не выполняется. Таким образом, исправление в одном месте привело к ошибке в другом, что демонстрирует необходимость проведения полного перетестирования. Однако повторноеперетестирование требует значительных усилий и времени. Возникает задача – отобрать сокращенный набор тестов из исходного набора (может быть, пополнив его рядом дополнительных - вновь разработанных - тестов), которого, тем не менее, будет достаточно для исчерпывающей проверки функциональности в соответствии с выбранным критерием. Организация повторного тестирования в условиях сокращения ресурсов, необходимых для обеспечения заданного уровня качества продукта, обеспечиваетсярегрессионным тестированием.

http://localhost:3232/img/empty.gifhttp://localhost:3232/img/empty.gifКомбинирование уровней тестирования

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


Таблица 4.3. Характеристики модульного, интеграционного и системного тестирования

Модульное

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

Системное

Типы дефектов

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

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

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

Необходимость в системе тестирования

Да

Да

Нет (*)

Цена разработки системы тестирования

Низкая

Низкая до умеренной

Умеренная до высокой или неприемлемой

Цена процесса тестирования, то есть разработки, прогона и анализа тестов

Низкая

Низкая

Высокая

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика