Software & Systems

Тестирование является неотъемлемой частью разработки любого компонента программного изделия (ПИ), а системное тестирование – это завершающая фаза жизненного цикла разработки ПИ. Процесс тестирования в коллективах, занимающихся разработкой ПИ, может быть организован разными способами. Однако любой процесс тестирования должен быть направлен на выполнение главной цели, которая состоит в обнаружении дефектов в тестируемом объекте, выявлении расхождений между спецификациями проектирования и требованиями к ПИ и его реальным поведением. (Разделение обязанностей по осуществлению тестирования между разработчиками и тестировщиками описано на с. 30-33 наст. ном. журн). Авторы предлагают вниманию читателей описание процесса системного тестирования, принятое в ИДУ.

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

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

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

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

ГСТ начинает свою работу по созданию тестового комплекта для ПИ с составления плана системного тестирования сразу после утверждения требований заказчика к нему. Приведем перечень основных материалов, создаваемых в ходе разработки тестового комплекта и выполнения циклов системного тестирования, который принят в ИДУ в качестве обязательного. В перечень входят:

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

·     процедуры системного тестирования – документы, описывающие порядок выполнения тестов, обеспечивающие требуемую последовательность запуска системных тестов и критерии их успешного завершения (в процедурах системного тестирования необходимо также приводить подробные описания запуска неавтоматизированных тестов);

·     матрица покрытия требований, в которой каждому требованию заказчика поставлены в соответствие один или несколько тестов из тестового комплекта;

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

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

Разработка тестового комплекта. ГСТ занимается разработкой автоматизированного тестового комплекта для ПИ в соответствии с составленным для этого ПИ планом системного тестирования. Тестовый комплект должен покрывать все требования заказчика к ПИ. Для этого ответственный системный тестировщик должен работать совместно с разработчиками, чтобы удалить все нетестируемые требования и обеспечить возможность покрытия на 100 % всех требований заказчика к ПИ (пример нетестируемого требования: интерфейс должен быть дружественным).

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

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

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

Вехи системного тестирования. Ответственный системный тестировщик должен определить вехи системного тестирования ПИ, которые утверждаются руководителями проектной группы и ГСТ. Утвержденные вехи должны быть включены в соответствующий план системного тестирования. Обязательными вехами являются: окончание работ по разработке плана системного тестирования, разработке набора тестов для каждой функциональной компоненты, определенной в требованиях заказчика к ПИ; окончание составления тестовых процедур; завершение каждого из запланированных циклов системного тестирования.

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

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

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

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

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

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

Функциональное тестирование. Осуществление функционального тестирования обеспечивает проверку соответствия ПИ требованиям к нему. Для обеспечения эффективного выполнения операций регрессионного тестирования комплект функциональных тестов должен быть автоматизированным, покрывать 100 % функциональных требований к ПИ и не менее 75 % строк его кода. Для ПИ, предоставляющих пользователю большое разнообразие функциональных возможностей, целесообразно применение специфических разновидностей функциональных тестов, а именно: монокомпонентных, мультикомпонентных и конфигурационных.

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

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

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

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

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

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

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

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

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

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

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

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

Метрики системного тестирования. В соответствии с "Метрической программой", принятой в ИДУ (см. с. 24-29 наст. ном. журн.), во время фазы "Системное тестирование" осуществляется сбор и анализ установленных метрик. Руководитель ГСТ, как и все руководители проектных групп, подготавливает еженедельные, двухнедельные и месячные метрические отчеты, регулярно выступает на еженедельных семинарах и ежемесячных оперативных обзорах с докладами о прогрессе в системном тестировании ПИ и о том, что сделано по плану системного тестирования за прошедший месяц и о планах на следующий.

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

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

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

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

Различия метрических данных по группам проектов. A – системы обработки текстов, B – ядра ОС, C – системы моделирования

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

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