теория_8 (1035127)

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

Текст из файла

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

23.2.1. Задачи и цели интеграционного тестирования

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

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

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

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

23.2.2. Задачи и цели интеграционного тестирования

23.2.2.1. Структурная классификация методов интеграционного тестирования

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

• восходящее тестирование;

• монолитное тестирование;

• нисходящее тестирование;

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

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

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

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

Тем не менее, монолитное тестирование имеет ряд серьезных недостатков:

• очень трудно выявить источник ошибки (идентифицировать ошибочный фрагмент кода);

• трудно организовать исправление ошибок;

• процесс тестирования плохо автоматизируется.

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

23.2.2.2. Временная классификация методов интеграционного тестирования

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

• тестирование с поздней интеграцией;

• тестирование с постоянной интеграцией;

• тестирование с регулярной или послойной интеграцией.

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

Схематично тестирование с поздней интеграцией может быть изображено в виде цепочки R-C-V-R-C-V-R-C-V-I-R-C-V-R-C-V-I, где R – разработка требований на отдельный модуль, C – разработка программного кода, V – тестирование модуля, I – интеграционное тестирование всего, что было сделано раньше.

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

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

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

Таблица 23.1. Основные характеристики различных видов интеграционного тестирования

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

23.2.3. На примере "Калькулятора"

Как уже отмечалось, в MVSTE под unit-testing подразумевается именно интеграционное тестирование, а конкретно — тестирование с постоянной интеграцией. В семинаре 5 мы уже протестировали метод RunEstimate(), при интеграции классов AnalaizerClass и CalcClass. Аналогично, составив требования к этой подсистеме из двух классов (а это будут требования ко всем методам AnalaizerClass), можно провести следующий этап тестирования. В качестве примера протестируем все методы такой подсистемы, сделав по одному тестовому примеру на каждый метод:

/// <summary>

/// A test for RunEstimate ()

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

/// метод RunEstimate правильно посчитает это выражение

///</summary>

[DeploymentItem("BaseCalculator.exe")]

[TestMethod()]

public void RunEstimateTest()

{

string expected = "3";

string actual;

TestProjectCalculator.BaseCalculator_AnalaizerClassAccessor.opz =

new ArrayList();

ArrayList _opz =

TestProjectCalculator.BaseCalculator_AnalaizerClassAccessor.opz;

_opz.Add("7");

_opz.Add("8");

_opz.Add("+");

_opz.Add("5");

_opz.Add("/");

actual = TestProjectCalculator.BaseCalculator_AnalaizerClassAccessor.RunEstimate();

Assert.AreEqual(expected, actual,

"BaseCalculator.AnalaizerClass.RunEstimate did not return the expected value.");

}

/// <summary>

///A test for CheckCurrency ()

/// Проверяет, что, если в выражении нарушена скобочная структура, то метод возвращает false

///</summary>

[DeploymentItem("BaseCalculator.exe")]

[TestMethod()]

public void CheckCurrencyTest()

{

bool expected = false;

bool actual;

TestProjectCalculator.BaseCalculator_AnalaizerClassAccessor.expression =

"((5+3)*2-(3*10))-2)+((5+3)";

actual = TestProjectCalculator.BaseCalculator_AnalaizerClassAccessor.CheckCurrency();

Assert.AreEqual(expected, actual,

"BaseCalculator.AnalaizerClass.CheckCurrency did not return the expected value.");

Assert.AreEqual(18,

TestProjectCalculator.BaseCalculator_AnalaizerClassAccessor.erposition,

"BaseCalculator.AnalaizerClass.CheckCurrency did not return the expected value.");

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

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

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

Список файлов лабораторной работы