тестирование. Тестир. инф. систем Метод материалы. Сыркин Илья Сергеевич Тестирование информационных систем методические указания
 Скачать 2.91 Mb.
|
|
Контрольные вопросы 1. Как создать тест для нагрузочного тестирования? 2. Как анализировать данные нагрузочного тестирования? 3. Как запустить тест в облаке Azure? 70 9. Лабораторная работа №6. «Интеграционное тестирование» Целью работы является изучение интеграционного тестирова- ния ПО. Результатом работы является отчет, в котором должны быть приведены исходные коды программы, результаты инеграци- онного тестирования ПО. Для выполнения работы студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах. 9.1. Задачи и цели интеграционного тестирования Результатом тестирования и верификации отдельных модулей, составляющих программную систему, должно быть заключение о том, что эти модули являются внутренне непротиворечивыми и со- ответствуют требованиям. Однако отдельные модули редко функ- ционируют сами по себе, поэтому следующая задача после тестиро- вания отдельных модулей – тестирование корректности взаимодей- ствия нескольких модулей, объединенных в единое целое. Такое тестирование называют интеграционным. Его цель – удостоверить- ся в корректности совместной работы компонент системы. Интеграционное тестирование называют еще тестированием архитектуры системы. С одной стороны, это название обусловлено тем, что интеграционные тесты включают в себя проверки всех возможных видов взаимодействий между программными модулями и элементами, которые определяются в архитектуре системы – та- ким образом, интеграционные тесты проверяют полноту взаимодей- ствий в тестируемой реализации системы. С другой стороны, ре- зультаты выполнения интеграционных тестов – один из основных источников информации для процесса улучшения и уточнения ар- хитектуры системы, межмодульных и межкомпонентных интерфей- сов. То есть, с этой точки зрения, интеграционные тесты проверя- ют корректность взаимодействия компонент системы. Примером проверки корректности взаимодействия могут слу- жить два модуля, один из которых накапливает сообщения прото- кола о принятых файлах, а второй выводит этот протокол на экран. В функциональных требованиях к системе записано, что сообщения должны выводиться в обратном хронологическом порядке. Одна- ко, модуль хранения сообщений сохраняет их в прямом порядке, а модуль вывода использует стек для вывода в обратном порядке. Модульные тесты, затрагивающие каждый модуль по отдельности, 71 не дадут здесь никакого эффекта – вполне реальна обратная ситуа- ция, при которой сообщения хранятся в обратном порядке, а выво- дятся с использованием очереди. Обнаружить потенциальную про- блему можно только проверив взаимодействие модулей при помо- щи интеграционных тестов. Ключевым моментом здесь является то, что в обратном хронологическом порядке сообщения выводит сис- тема в целом, т. е., проверив модуль вывода и обнаружив, что он выводит сообщения в прямом порядке, мы не сможем гарантиро- вать, что мы обнаружили дефект. В результате проведения интеграционного тестирования и уст- ранения всех выявленных дефектов получается согласованная и це- лостная архитектура программной системы, т. е. можно считать, что интеграционное тестирование – это тестирование архитектуры и низкоуровневых функциональных требований. Интеграционное тестирование, как правило, представляет со- бой итеративный процесс, при котором проверяется функциональ- ной все более и более увеличивающейся в размерах совокупности модулей. 9.2. Организация интеграционного тестирования Структурная классификация методов интеграционного тестирования Как правило, интеграционное тестирование проводится уже по завершении модульного тестирования для всех интегрируемых мо- дулей. Однако это далеко не всегда так. Существует несколько ме- тодов проведения интеграционного тестирования: восходящее тестирование; монолитное тестирование; нисходящее тестирование. Все эти методики основываются на знаниях об архитектуре системы, которая часто изображается в виде структурных диаграмм или диаграмм вызовов функций. Каждый узел на такой диаграмме представляет собой программный модуль, а стрелки между ними представляют собой зависимость по вызовам между модулями. Ос- новное различие методик интеграционного тестирования заключа- ется в направлении движения по этим диаграммам и в широте охва- та за одну итерацию. Восходящее тестирование. При использовании этого метода подразумевается, что сначала тестируются все программные моду- 72 ли, входящие в состав системы и только затем они объединяются для интеграционного тестирования. При таком подходе значительно упрощается локализация ошибок: если модули протестированы по отдельности, то ошибка при их совместной работе есть проблема их интерфейса. При таком подходе область поиска проблем у тести- ровщика достаточно узка, и поэтому гораздо выше вероятность пра- вильно идентифицировать дефект. Рис. 1. Разработка драйверов и заглушек при восходящем интеграционном тестировании Однако, у восходящего метода тестирования есть существен- ный недостаток – необходимость в разработке драйвера и заглушек для модульного тестирования перед проведением интеграционного тестирования и необходимость в разработке драйвера и заглушек при интеграционном тестировании части модулей системы (рис. 1) С одной стороны драйверы и заглушки – мощный инструмент тестирования, с другой – их разработка требует значительных ре- сурсов, особенно при изменении состава интегрируемых модулей, иначе говоря, может потребоваться один набор драйверов для мо- дульного тестирования каждого модуля, отдельный драйвер и за- глушки для тестирования интеграции двух модулей из набора, от- 73 дельный – для тестирования интеграции трех модулей и т. п. В пер- вую очередь это связано с тем, что при интеграции модулей отпада- ет необходимость в некоторых заглушках, а также требуется изме- нение драйвера, которое поддерживает новые тесты, затрагивающие несколько модулей. Монолитное тестирование предполагает, что отдельные ком- поненты системы серьезного тестирования не проходили. Основное преимущество данного метода – отсутствие необходимости в разра- ботке тестового окружения, драйверов и заглушек. После разработ- ки всех модулей выполняется их интеграция, затем система прове- ряется вся в целом. Этот подход не следует путать с системным тес- тированием, которому посвящена следующая лекция. Несмотря на то, что при монолитном тестировании проверятся работа всей сис- темы в целом, основная задача этого тестирования – определить проблемы взаимодействия отдельных модулей системы. Задачей же системного тестирования является оценка качественных и количе- ственных характеристик системы с точки зрения их приемлемости для конечного пользователя. Монолитное тестирование имеет ряд серьезных недостатков. Очень трудно выявить источник ошибки (идентифициро- вать ошибочный фрагмент кода). В большинстве модулей следует предполагать наличие ошибки. Проблема сводится к определению того, какая из ошибок во всех вовлечѐнных модулях привела к по- лученному результату. При этом возможно наложение эффектов ошибок. Кроме того, ошибка в одном модуле может блокировать тестирование другого. Трудно организовать исправление ошибок. В результате тестирования тестировщиком фиксируется найденная проблема. Дефект в системе, вызвавший эту проблему, будет устранять разра- ботчик. Поскольку, как правило, тестируемые модули написаны разными людьми, возникает проблема – кто из них является ответ- ственным за поиск устранение дефекта? При такой «коллективной безответственности» скорость устранения дефектов может резко упасть. Процесс тестирования плохо автоматизируется. Преимуще- ство (нет дополнительного программного обеспечения, сопровож- дающего процесс тестирования) оборачивается недостатком. Каж- дое внесѐнное изменение требует повторения всех тестов. 74 Нисходящее тестирование предполагает, что процесс инте- грационного тестирования движется следом за разработкой. Снача- ла тестируют только самый верхний управляющий уровень систе- мы, без модулей более низкого уровня. Затем постепенно с более высокоуровневыми модулями интегрируются более низкоуровне- вые. В результате применения такого метода отпадает необходи- мость в драйверах (роль драйвера выполняет более высокоуровне- вый модуль системы), однако сохраняется нужда в заглушках (рис. 2). Рис. 2.Постепенная интеграция модулей при нисходящем методе тестирования У разных специалистов в области тестирования разные мнения по поводу того, какой из методов более удобен при реальном тести- ровании программных систем. Йордан доказывает, что нисходящее тестирование наиболее приемлемо в реальных ситуациях, а Майерс полагает, что каждый из подходов имеет свои достоинства и недос- татки, но в целом восходящий метод лучше. В литературе часто упоминается метод интеграционного тес- тирования объектно-ориентированных программных систем, кото- рый основан на выделении кластеров классов, имеющих вместе не- которую замкнутую и законченную функциональность. По своей сути такой подход не является новым типом интеграционного тес- тирования, просто меняется минимальный элемент, получаемый в результате интеграции. При интеграции модулей на процедурных языках программирования можно интегрировать любое количество модулей при условии разработки заглушек. При интеграции классов в кластеры существует достаточно нестрогое ограничение на закон- 75 ченность функциональности кластера. Однако, даже в случае объ- ектно-ориентированных систем возможно интегрировать любое ко- личество классов при помощи классов-заглушек. Вне зависимости от применяемого метода интеграционного тестирования, необходимо учитывать степень покрытия интеграци- онными тестами функциональности системы. Временная классификация методов интеграционного тес- тирования На практике чаще всего в различных частях проекта применя- ются все рассмотренные в предыдущем разделе методы в совокуп- ности. Каждый модуль тестируют по мере готовности отдельно, а потом включают в уже готовую композицию. Для одних частей тес- тирование получается нисходящим, для других – восходящим. В связи с этим представляется полезным рассмотреть еще один тип классификации типов интеграционного тестирования – классифика- цию по времени интеграции. В рамках этой классификации выделяют: тестирование с поздней интеграцией; тестирование с постоянной интеграцией; тестирование с регулярной или послойной интеграцией. Тестирование с поздней интеграцией – практически полный аналог монолитного тестирования. Интеграционное тестирование при такой схеме откладывается на как можно более поздние сроки проекта. Этот подход оправдан в том случае, если система является конгломератом слабо связанных между собой модулей, которые взаимодействуют по какому-либо стандартному интерфейсу, опре- деленному вне проекта (например, в случае, если система состоит из отдельных Web-сервисов). Схематично тестирование с поздней интеграцией может быть изображено в виде цепочки R-C-V-R-C-V- R-C-V-I-R-C-V-R-C-V-I, где R – разработка требований на отдель- ный модуль, C – разработка программного кода, V – тестирование модуля, I – интеграционное тестирование всего, что было сделано раньше. Тестирование с постоянной интеграцией подразумевает, что, как только разрабатывается новый модуль системы, он сразу же интегрируется со всей остальной системой. При этом тесты для это- го модуля проверяют как сугубо его внутреннюю функциональ- ность, так и его взаимодействие с остальными модулями системы. 76 Таким образом, этот подход совмещает в себе модульное тестиро- вание и интеграционное. Разработки заглушек при таком подходе не требуется, но может потребоваться разработка драйверов. В на- стоящее время именно этот подход называют unit testing, несмотря на то, что в отличие от классического модульного тестирования здесь не проверяется функциональность изолированного модуля. Локализация ошибок межмодульных интерфейсов при таком под- ходе несколько затруднена, но все же значительно ниже, чем при монолитном тестировании. Большая часть таких ошибок выявляется достаточно рано именно за счет частоты интеграции и за счет того, что за одну итерацию тестирования проверяется сравнительно не- большое число межмодульных интерфейсов. Схематично тестирование с постоянной интеграцией может быть изображено в виде цепочки R-C-I-R-C-I-R-C-I, в которой фаза тестирования модуля намеренно опущена и заменена на тестирова- ние интеграции. При тестировании с регулярной или послойной интеграци- ей интеграционному тестированию подлежат сильно связанные ме- жду собой группы модулей (слои), которые затем также интегриру- ются между собой. Такой вид интеграционного тестирования назы- вают также иерархическим интеграционным тестированием, по- скольку укрупнение интегрированных частей системы, как правило, происходит по иерархическому принципу. Однако, в отличие от нисходящего или восходящего тестирования, направление прохода по иерархии в этом подходе не задано. В табл. 1 приведены основные характеристики рассмотренных в данной лекции видов интеграционного тестирования. Время инте- грации характеризует момент, когда проводится первое интеграци- онное тестирование и все последующие. Частота интеграции – на- сколько часто при разработке выполняется интеграция. Необходи- мость в драйверах и заглушках определена в последних двух стро- ках таблицы. 77 Таблица 1 Основные характеристики различных видов интеграционного тестирования Свойство Вид интеграции Восходя- щее Нисходя- щее Монолит- ное Поздняя интегра- ция Постоян- ная инте- грация Регуляр- ная инте- грация Время интегра- ции Поздно (после тес- тирования модулей) Рано (па- раллельно с разра- боткой) Поздно (после разработки всех моду- лей) Поздно (после разработ- ки всех модулей) Рано (па- раллельно с разра- боткой) Рано (па- раллельно с разра- боткой) Частота интегра- ции Редко Часто Редко Редко Часто Часто Нужны ли драй- веры Да Нет Нет Нет Да Да Нужны ли за- глушки Да Да Нет Нет Нет Да Планирование интеграционного тестирования Процесс организации и планирования интеграционного тести- рования во многом схож с процессом организации модульного тес- тирования, рассмотренном в предыдущей лекции. Однако интегра- ционное тестирование имеет ряд организационных особенностей, перечисленных ниже. На этапе планирования разрабатывается концепция и страте- гия интеграции – документ, где описан общий подход к определе- нию последовательности, в которой должны интегрироваться моду- ли. Как правило, концепция основывается на одном из видов инте- грации, рассмотренных выше (например, на нисходящей), но учи- тывает особенности конкретной системы (например, вначале долж- ны интегрироваться компоненты работы с базой данных, затем пользовательского интерфейса; затем интерфейсные компоненты и компоненты работы с БД интегрируются вместе). Составляется интеграционный тест-план, например, кластер- ного типа, в котором для каждого кластера из интегрированных мо- дулей определяется следующее: кластеры, от которых зависит данный кластер; 78 кластеры, которые должны быть протестированы до тести- рования данного кластера; описание функциональности тестируемого кластера; список модулей в кластере; описание тестовых примеров для проверки кластера; Планирование интеграционного тестирования должно быть синхронизировано с общим планом проекта, причем выделяемые для интеграционного тестирования кластеры и сроки их тестирова- ния должны учитывать приоритеты важности частей системы. За- частую рассмотрение приоритетов связано с тем, что системы раз- рабатываются в несколько этапов, на каждом из которых в эксплуа- тацию вводится только часть новой системы. Интеграционное тес- тирование в данном случае должно укладываться в общий план- график проекта и учитывать затраты ресурсов на тестирование ин- теграции с уже работающими частями системы. Контрольные вопросы 1. Что такое интеграционное тестирование? 2. Какие виды интеграционного тестирования существуют? 3. Что такое «заглушка»? 79 10. Лабораторная работа №7. «Конфигурационное тестирование» Целью работы является изучение конфигурационного тестиро- вания ПО. Результатом работы является отчет, в котором должны быть приведены исходные коды программы, конфигурационного тестирования ПО. Для выполнения работы студент должен изучить приведенный ниже теоретический материал. Отчет сдается в распечатанном и электронном (файл Word) видах. Конфигурационное тестирование (Configuration Testing) – специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различ- ных конфигурациях компьютеров и т. д.). В зависимости от типа проекта конфигурационное тестирова- ние может иметь разные цели: 1. Проект по профилированию работы системы Цель Тестирования: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики произ- водительности и времени реакции тестируемой системы. 2. Проект по миграции системы с одной платформы на дру- гую Цель Тестирования: Проверить объект тестирования на со- вместимость с объявленным в спецификации оборудованием, опе- рационными системами и программными продуктами третьих фирм. Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости: configuration testing: See |