Software & Systems

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

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

Разделение работ по тестированию между разработчиками и системными тестировщиками, принятое в АОЗТ ИДУ, показано на рисунке 1.

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

Каждый вид тестирования совершается в несколько циклов.

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

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

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

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

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

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

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

Каждый вид тестирования завершается при выполнении критериев завершения тестирования. На основе модели возникновения и устранения ошибок и дефектов [1] в ИДУ разработаны критерии завершения тестирования, которые на практике показали надежность определения момента окончания тестирования ПИ с получением планируемого качества.

Распределение трудоемкостей фаз жизненного цикла ПИ, количества ошибок, допускаемых на них, построенное по реальным метрикам ИДУ, показано на рисунке 2. По оси абсцисс последовательно отложены трудоемкости (в %) всех фаз разработки ПИ (без учета фазы "Системное тестирование"). Отдельно выделена суммарная трудоемкость работ по нахождению и устранению ошибок и дефектов на фазах {1}, {2}, {3} и {4} (последний этап 3.4). Трудоемкость этапа 3.4 представляет собой сумму трудоемкостей по выявлению и устранению ошибок; по выявлению и устранению некоторого числа (не обязательно всех) дефектов на каждой из фаз разработки ПИ (фазы {1}, {2}, {3}); выявлению и анализу причин возникновения ошибок в прошлом и выработке мер по устранению обнаруженных причин в будущем; по устранению всех дефектов, обнаруженных в процессе системного тестирования. Все обнаруженные во время разработки ПИ ошибки и дефекты в результате всех видов обзоров и тестирования должны быть занесены в базу данных ошибок и дефектов.

Рис. 2. Распределение трудоемкости фаз жизненного цикла ПИ и количества ошибок, допускаемых на них, построенное по реальным метрикам ИДУ

По оси ординат графика отложены значения оценок допустимого на различных фазах разработки ПИ числа ошибок (в % от величины оценки допустимого количества ошибок в проекте) – возрастающая часть графика, и оценка количества обнаруженных и устраненных ошибок и дефектов на тех же фазах – нисходящая часть графика. График представлен для случая разработки ПИ с качеством 5 сигма [2-3].

Рис. 3. График общего числа найденных, открытых и закрытых ошибок и дефектов при выполнении проекта ПИ

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

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

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

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

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

2. Для каждого цикла всех видов тестирования необходимо строить распределение найденных дефектов по уровням серьезности (пример показан на рис. 4).

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

3. Далее следует производить сравнение распределений найденных дефектов в каждом цикле тестирования (рис. 5). При этом должна наблюдаться тенденция снижения количества и уровня серьезности найденных дефектов при продвижении к более поздним циклам тестирования.

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

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

Если условие (4) (100 % покрытие спецификаций функционального проектирования и кода тестируемой сборки версии ПИ) выполняется на втором цикле тестирования разработчиками, то должен выполняться третий цикл тестирования, а при необходимости и последующие циклы с новыми тестами до подтверждения условия (3) (снижение количества и уровня серьезности найденных дефектов при продвижении к третьему и последующим циклам тестирования).

Все обнаруженные дефекты при тестировании разработчиками должны быть занесены в базу данных ошибок и дефектов и закрыты к моменту передачи сборки версии ПИ на системное тестирование.

Рис. 5. Пример сравнения циклов тестирования

5. При системном тестировании также проводится не менее трех циклов тестирования. При этом дополняется график (рис. 3), сроятся распределения найденных дефектов по уровням серьезности (см. рис. 4 и 5), кроме того должны выполняться условия системного тестирования. В ИДУ – это 100 % покрытия требований заказчика к ПИ, 75 % покрытия кода тестируемой сборки версии ПИ, а в последнем цикле системного тестирования не должно быть обнаружено более трех дефектов второго уровня серьезности.

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

Список литературы

1. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при разработке ПИ. // Программные продукты и системы. – 1998. - №2. - С.2-6.

2. Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software.

3. Baranoff S., Domaratsky A., Lastochkin N., Morozov V. An automated system for software project planning. International Conference on Informatics and Control (ICI&C'97 June 9-13, 1997 St.Petersburg). Proceedings. Volume 2 of 3. St.Petersburg. SPIIRAS, 1997 - P.785-795.