CC BY
21
вых вех проекта (перечень плановых поставок заказчику) и дат фактического завершения этих вех; 3) процент повторного использования продуктов ИДУ в данном проекте; 4) развернутое описание выполняемого проекта (описание должно быть таким, чтобы любой представитель администрации или заказчика, взявший в руки одностраничный отчет и не знакомый с проектом, мог бы без посторонней помощи понять содержание его работ); 5) диаграмма хода выполнения работ (строится автоматически по данным из базы данных проекта так же, как и в случае одностраничного еженедельного отчета, только в этом случае график строится за весь предыдущий период, включая установленную дату отчета); 6) плановая и фактическая численность проектной группы; 7) стоимость проекта по отчетным месяцам (наличие этих данных позволяет обнаружить тенденцию к драматическому увеличению штата или стоимости проекта и вовремя предпринять необходимые меры); 8) статус проекта (состояние основных документов и поставок проекта) на дату отчета (дает представление администрации и заказчику, в каком состоянии находится проект в отчетный момент).
Операционный обзор
Краткое описание Что сделано за План работ на
проекта, состояние прошедший месяц, следующий месяц,
на огчегную дату, иллюстрации, иллюстрации
иллюстрации одностраничный
и месячный отчеты
Обязательные разделы материалов _операционного обзора_
В ИДУ используется еще одно мероприятие для отслеживания хода выполнения проектов - это операционный обзор проектов. В конце месяца на науч-но-организационном семинаре проводится такой обзор каждого выполняемого проекта, для чего руководители проектов готовят специальный материал с иллюстрациями, в который включается и ежемесячный одностраничный отчет о ходе выполнения проекта.
Материалы операционного обзора, принятого в ИДУ, представляют собой еще одну форму наглядного представления хода выполнения проекта за прошедший месяц. Эти материалы подготавливаются за-
ранее в среде программного пакета MS Power Point и во время выступления руководителя проекта проецируются с помощью компьютера и специального проекционного устройства на большой экран для всеобщего обозрения. Обязательными разделами в материалах операционного обзора являются разделы, показанные на рисунке.
Обычный объем материалов операционного обзора с текстом и иллюстрациями в соответствии с содержанием, представленным на рисунке, занимает 4-5 страниц формата А4. Доклад руководителя проекта на таком обзоре в ИДУ длится, как правило, не более 10 минут, а с ответами на возникающие вопросы в среднем 15 минут. На операционные обзоры полезно приглашать представителей заказчика. В ИДУ такое приглашение считается нормой.
Общеизвестно, что независимо от того, насколько хорошо все исполнители понимают методы работы над проектами, способы оформления предусмотренных стандартным процессом отчетов и полученных результатов среди исполнителей во взглядах на эти вопросы не будет до конца того единодушия, которое требуется для качественного выполнения каждого конкретного требования стандартного процесса.
Чтобы добиться единообразия, правильного и качественного выполнения требований стандартного процесса по оформлению материалов операционного обзора, в ИДУ для них были разработаны специальные стандартные формы, процедуры заполнения этих форм и их представления на операционном обзоре. Наличие и обязательное применение установленных стандартным процессом форм и процедур обеспечило качественное проведение операционных обзоров практически без превышения отведенного лимита времени.
В заключение отметим, что использование стандартного процесса (методологии модели СММ) в повседневной деятельности ИДУ зарекомендовало себя с хорошей стороны - все проекты ПИ заканчивались в установленные сроки, без превышения выделенного бюджета, с требуемым качеством выпускаемых продуктов. Недостаток стандартного процесса состоит в том, что он эффективно работает только при очень высокой организации труда в коллективах каждой проектной группы, в группах, вовлеченных в проекты, и в администрации.
КРИТЕРИИ ЗАВЕРШЕНИЯ ТЕСТИРОВАНИЯ ПРОГРАММНЫХ ИЗДЕЛИЙ
А.Н. Домарацкий, В.В. Никифоров
Тестирование (модульное, интеграционное и тестирование работоспособности) программных изделий (ПИ) разработчиками и в группе системного тестирования (системное тестирование) является не только средством верификации и валидации ПИ, но и средством обеспечения требуемого уровня его качества. В связи с этим процессу тестирования в организации, производящей ПИ, должно быть уделено особое внимание. Для этого в организации целесообразно разработать, доку-
ментировать и строго соблюдать специальный процесс тестирования (ПТ).
В документе ПТ должна быть разделена ответственность и определены обязанности по тестированию ПИ разработчиками в проектной группе (ПГ) и в группе системного тестирования, определены порядок и виды тестирования, уровни серьезности ошибок и дефектов, способы документирования результатов тестирования и виды отчетных документов, установлен перечень доку-
Поток данных при обращении к БДД в циклах тестирования разработчиков и системноого тестирования
-^ Поток программных кодов и
Г документов в циклах системного тестирования
База данных ошибок и дефектов (БДД)
Выходная версия ПИ
О
Поток программных кодов и документов при разработке ПИ в ПГ
Действия выполняются в ПГ
Действия выполняются группой системного тестирования
Системное тестирование
Разрешение на поставку ПИ
Рис. 1. Распределение обязанностей при тестировании в ИДУ
ментов и продуктов для передачи на системное тестирование ПИ в группу тестирования и т.п.
Разделение работ по тестированию между разработчиками и системными тестировщиками, принятое в АОЗТ ИДУ, показано на рисунке 1.
Как видно из рисунка, ПИ подвергается двум видам тестирования: тестированию, которое осуществляют сами разработчики (модульное, интеграционное и тестирование работоспособности - верификация ПИ), и системному тестированию, выполняемому системными тестировщиками (валидация ПИ).
Каждый вид тестирования совершается в несколько циклов.
Циклом тестирования называется деятельность тестировщика (или разработчика) по проверке ПИ (или отдельной его компоненты) между моментом, когда разработчик представляет (или берет) базовую версию ПИ (или его компоненты) для системного тестирования (или тестирования разработчиками), и моментом представления отчета о системном тестировании (или генерации отчета о тестировании разработчиком).
Циклы тестирования обязательно планируются в соответствии с вехами проектного плана разработки ПИ. Как правило, по каждому ПИ должно планироваться не менее трех циклов тестирования разработчиками и трех циклов системного тестирования, для того чтобы была возможность убедиться в достаточности тестирования и в обеспечении требуемого качества ПИ.
Тестирование разработчиками. Разработчики ПИ несут ответственность за тестирование кода разрабатываемого ими программного продукта. Тестирование кода включает три вида задач: модульное тестирование, интеграционное и тестирование работоспособности полной версии ПИ.
Элементами модульного тестирования являются: обзор кода, синтаксическая проверка, проверка граничных условий (работа модуля при граничных значениях входных данных).
Интеграционное тестирование. После проведения модульного тестирования разработчики приступают к интеграционному тестированию, заранее определив стратегию сборки модулей и тестирования. В ходе интеграционного тестирования разработчики выполняют следующие действия: контролируют соответствие реальной разбивки модулей на подсистемы спецификациям функционального проектирования; проверяют корректность реализации межмодульных интерфейсов; проводят обзор разработанных средств интеграционного тестирования; выполняют интеграционные тесты.
Тестирование работоспособности. После тестирования отдельных модулей и интеграционного тестирования разработчики должны выполнить сборку базовой версии ПИ и убедиться в ее работоспособности. Для этого составляется тест (серия тестов) проверки работоспособности, который должен подтверждать 100 % соответствия тестируемой версии ПИ спецификациям функционального проектирования, инсталлируе-мость ПИ с представленных инсталляционных дискет и устойчивость ПИ к неумелым (неправильным) действиям пользователя.
Системное тестирование в основном использует стратегию черного ящика, но не ограничивается только ею. При системном тестировании выполняются следующие виды тестирования: инсталляционное, на соответствие контрактной книге, на соответствие стандартам, функциональное, сценарное, производительности, граничное, на различных платформах, взаимодействия продукта со средой, документации, выходное.
Каждый вид тестирования завершается при выполнении критериев завершения тестирования. На основе модели возникновения и устранения ошибок и дефектов [1] в ИДУ разработаны критерии завершения тестирования, которые на практике показали надежность определения момента окончания тестирования ПИ с получением планируемого качества.
Распределение трудоемкостей фаз жизненного цикла ПИ, количества ошибок, допускаемых на них, построенное по реальным метрикам ИДУ, показано на рисунке 2. По оси абсцисс последовательно отложены трудоемкости (в %) всех фаз разработки ПИ (без учета фазы "Системное тестирование"). Отдельно выделена суммарная трудоемкость работ по нахождению и устранению ошибок и дефектов на фазах {1}, {2}, {3} и {4} (последний этап 3.4). Трудоемкость этапа 3.4 представляет собой сумму трудоемкостей по выявлению и устранению ошибок; по выявлению и устранению некоторого числа (не обязательно всех) дефектов на каждой из
Оценка допустимого числа ошибок и дефектов в проекге= Н*6.2
Фаза {1} 1.1. Планпртанне 1.2. Составление требований
Фаза {2} Проектирование
Фаза {3) 3.1. Кодиртанне
3.2. Модуцноелнтеграци-онное тестирование. тестирование работоспособности
3.3. Составление пользовательской документации
3.4. Нахождение!! устранение ошибок н дефектов на фазах {1},{2},{3}, {4}, выявление причин их возникновения
N - размер нового кода Оценка допустимого числа поставляемых дефектов в | ПИ в КАЕЬОС _ПИ = N^0.23__I
Рис. 2. Распределение трудоемкости фаз жизненного цикла ПИ
и количества ошибок, допускаемых на них, _построенное по реальным метрикам ПДУ_
фаз разработки ПИ (фазы {1}, {2}, {3}); выявлению и анализу причин возникновения ошибок в прошлом и выработке мер по устранению обнаруженных причин в будущем; по устранению всех дефектов, обнаруженных в процессе системного тестирования. Все обнаруженные во время разработки ПИ ошибки и дефекты в результате всех видов обзоров и тестирования должны быть занесены в базу данных ошибок и дефектов.
По оси ординат графика отложены значения оценок допустимого на различных фазах разработки ПИ числа ошибок (в % от величины оценки допустимого количества ошибок в проекте) - возрастающая часть графика, и оценка количества обнаруженных и устраненных ошибок и дефектов на тех же фазах - нисходящая часть графика. График представлен для случая разработки ПИ с качеством 5 сигма [2-3]. '
В организации с хорошо налаженным стандартным процессом величины этих оценок приближаются друг к другу, то есть в такой организации практически все допустимые ошибки и дефекты проекта находятся и устраняются во время обзоров продуктов и всех видов тестирования ПИ. Совпадение допустимого числа ошибок при разработке ПИ (возрастающая часть графика) и числа найденных и устраненных ошибок и дефектов в результате всех видов обзоров и тестирования (нисходящая часть графика) является главным критерием завершения тестирования.
Наш опыт показывает, что для выполнения главного критерия завершения тестирования необходимо и достаточно выполнять следующее.
1. Начиная с первой фазы, и в процессе всех последующих фаз разработки ПИ осуществлять поиск и устранение ошибок и дефектов во всех продуктах (в планах, требованиях заказчика к ПИ, в спецификациях проектирования, кодах и в других продуктах фаз) в результате обзоров и всех видов тестирования. Одновременно производить подсчет общего числа найденных, устраненных (закрытых) и неустраненных (открытых) оши-
бок и дефектов на момент измерения метрик проекта ПИ. По результатам подсчета строить график, аналогичный показанному на рисунке 3 (для примера представлен график на момент окончания проекта ПИ).
В ИДУ график отслеживается еженедельно с начала проекта ПИ (он является одним из компонентов еженедельного метрического отчета). Необходимо стремиться к тому, чтобы к окончанию любой фазы было найдено и устранено количество ошибок и дефектов, соответствующее метрикам стандартного процесса этой фазы (см. рис. 2).
Если в результате обзоров и тестирования в нескольких еженедельных метрических отчетах подряд указывается меньшее число ошибок и дефектов, чем определено метриками стандартного процесса, то это является свидетельством низкого качества обзоров или плохо продуманного тестирования (по опыту работы ИДУ - в случае представления трех и более подобных отчетов подряд), либо сигналам к необходимости повышения внимания к качеству выполнения обзоров и тестирования (по опыту работы ИДУ - при представлении двух подобных отчетов подряд).
2. Для каждого цикла всех видов тестирования необходима строить распределение найденных дефектов по уровням серьезности (пример показан на рис. 4).
В ИДУ принята классификация ошибок и дефектов по четырем уровням серьезности. Ошибки и дефекты первого и второго уровней серьезности не вызывают отклонений в логике работы ПИ и не приводят к зависанию или краху программной системы. Ошибки и дефекты третьего уровня могут вызывать зависание программной системы без ее разрушения. А к ошибкам и дефектам четвертого уровня серьезности относятся те, которые приводят к разрушению ПИ.
- — — - Устраненные (закрытые) ошибки II дефекты ~ " " — Неустраненные (открытые) ошибки II дефекты Оставшиеся дефекты в поставляемом ПИ с " " — качеством 5 сигма = !,23 (штук)
N - размер в КАЕЬОС нового кода ПИ
Рис. 3. График общего числа найденных, открытых и закрытых ошибок и дефектов при выполнении проекта ПИ
—Продолжтггельность цикла тестирования
Календарное время
Рис. 4. Распределение найденных в цикле тестирования дефектов по уровням серьезности
3, Далее следует производить сравнение распределений найденных дефектов в каждом цикле тестирования (рис. 5). При этом должна наблюдаться тенденция снижения количества и уровня серьезности найденных дефектов при продвижении к более поздним циклам тестирования.
4. При соблюдении условия (3) тестирование разработчиками продолжается до тех пор, пока не будут покрыты тестами 100 % спецификаций функционального проектирования и 100 % кода тестируемой сборки версии ПИ, а на текущем цикле тестирования работоспособности не обнаруживается дефектов выше второго уровня серьезности. Причем на последнем цикле тести-
рования обнаруженных дефектов должно быть не более пяти.
Если условие (4) (100 % покрытие спецификаций функционального проектирования и кода тестируемой сборки версии ПИ) выполняется на втором цикле тестирования разработчиками, то должен выполняться третий цикл тестирования, а при необходимости и последующие циклы с новыми тестами до подтверждения условия (3) (снижение количества и уровня серьезности найденных дефектов при продвижении к третьему и последующим циклам тестирования).
Все обнаруженные дефекты при тестировании разработчиками должны быть занесены в базу данных ошибок и дефектов и закрыты к моменту передачи сборки версии ПИ на системное тестирование.
5. При системном тестировании также проводится не менее трех циклов тестирования. При этом дополняется график (рис. 3), сроятся распределения найденных дефектов по уровням серьезности (см. рис. 4 и 5), кроме того должны выполняться условия системного тестирования. В ИДУ - это 100 % покрытия требований заказчика к ПИ, 75 % покрытия кода тестируемой сборки версии ПИ, а в последнем цикле системного тестирования не должно быть обнаружено более трех дефектов второго уровня серьезности.
По окончании системного тестирования прошедшая тестирование сборка версии ПИ должна быть возвращена в ПГ для устранения выявленных дефектов и подготовки ее к поставке заказчику.
Список литературы
1, Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при разработке ПИ. // Программные продукты и системы. - 1998. - №2. - С.2-6.
2. Paulk, М.С.', B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version LI. 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-17S. 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.
Количество найденных дефектов (штук)
Уровни серьезности найденных дефектов
Д 1 мшжм.
Календарное время
Рис. 5. Пример сравнения циклов тестирования
ПРИМЕНЕНИЕ МЕТОДА ПЛОСКИХ СХЕМ ДЛЯ РАЗРАБОТКИ ТЕСТОВЫХ КОМПЛЕКТОВ ДЛЯ ВСТРАИВАЕМЫХ ОПЕРАЦИОННЫХ СИСТЕМ
В.В. Никифоров, Я.А. Домарацкий
Факт наличия проблемы отладки и тестирования встраиваемых операционных систем (ОС) общеизвестен [1-6]. Качественное системное тестирование встраиваемой ОС представляет собой сложную и трудоемкую задачу. Разделяют два типа затрат на системное тестирование - затраты на создание тестового комплекта (составление плана и процедуры системного тестирования, разработка и отладка тестов и тестового комплекта в целом) и затраты на исполнение собственно тестов, входящих в состав тестового комплекта (исполнение тестов, регистрация дефектов и составление отчетов о системном тестировании).
Наибольшая трудоемкость в системном тестировании приходится на создание тестового комплект, по-
скольку трудоемкость исполнения можно снизить во много раз за счет создания высокоавтоматизированного тестового комплекта.
По опыту работы ИДУ, трудоемкость системного тестирования составляет 29 % от трудоемкости создания ОС в целом, а трудоемкость создания тестовых комплектов составляет до 70 % от трудоемкости системного тестирования [7]. Задача сокращения трудоемкости создания тестовых комплектов является актуальной, ее решение можно осуществить за счет применения специальных языков программирования и специализированных инструментальных средств, а также за счет создания и использования эффективных методов построения тестов.
