«В.В. Липаев ТЕСТИРОВАНИЕ КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ УЧЕБНИК СИНТЕГ® Москва - 2010 УДК 004.41(075.8) ББК 32.973.26-018я73 Л61 Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, ...»

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

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

Заказчики должны уделять особое внимание структуре, полноте и практичности документации в соответствии с планом-проспектом ее содержания. План документирования должен быть проверен и утвержден до начала работ над первым проектом документации.

При контроле изменений и сопровождение документации должны быть предусмотрены:

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

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

изменения программного продукта после публикации изменения конкретных требований и функций программного комплекса после издания документации;

изменения документа после публикации изменения в опубликованной документации, обусловленные изменениями комплекса программ или обнаружением дефектов и ошибок в данной документации.

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

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

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

При тестировании может быть использовано для оценки практичности определения характеристик качества в ISO 9126 и ISO 12119.

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

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

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

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

Простота использования: возможность пользователю удобно и комфортно эксплуатировать и управлять программным комплексом.

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

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

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

На значения изучаемости существенно влияют демонстрационные возможности справочных средств обучения, качество и объем Лекция 2.5. Тестирование программных комплексов на соответствие… эксплуатационной документации. Изучаемость можно отражать трудоемкостью и продолжительностью изучения пользователями соответствующей квалификации, методов и инструкций применения программного комплекса для полноценной эксплуатации. Эти атрибуты может характеризовать трудоемкость от единиц до сотен человекочасов и продолжительность от единиц до тысяч часов, необходимых для освоения квалифицированного применения особенно сложных программных комплексов. Естественно, для создания учебных пособий необходимы определенные затраты труда и времени разработчиков, которые в некоторой степени пропорциональны сложности функций продуктов. Эти требования могут влиять на функциональную пригодность и успех внедрения комплекса программ у пользователей, а также значительно различаться в зависимости от его функционального назначения и сферы применения.

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

Ряд документов (спецификации, тесты, тексты программ) разрабатывается в процессе создания комплекса программ и их трудно выделить и тестировать как самостоятельные работы. Только около половины работ можно достаточно четко регламентировать (редактирование, печать, нормоконтроль, утверждение и т.д.). Эти обстоятельства привели к большому различию суммарных удельных затрат на страницу эксплуата-ционных документов сложных программных комплексов. Затраты на создание достаточно полного комплекта достоверной эксплуатационной документации практически пропорциональны размеру комплекса программ. Эти затраты сопутствуют в некоторой степени всем этапам разработки, однако оформление эксплуатационных документов обычно локализуется в специальном этапе работ. Затраты на разработку комплекта эксплуатационной документации для сложных программных продуктов, подлежащих В.В. Липаев. Тестирование компонентов и комплексов программ длительному сопровождению, обычно определяются затратами на объем текста документов ориентировочно 5 – 10 страниц на тысячу строк программы.

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

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

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

Лекция 2.6. Испытания компонентов и комплексов программ

ИСПЫТАНИЯ КОМПОНЕНТОВ И

КОМПЛЕКСОВ ПРОГРАММ

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ Испытания компонентов и сложного комплекса программ - организацию и процессы испытаний компонентов и комплекса программ:

определение задач, процессов и методической достоверности испытаний компонентов и комплекса программ;

подготовку к интеграции компонентов, комплекса программ и аппаратуры системы;

- интеграцию и тестирование комплекса программ вне системы:

испытания интерфейсов, компонентов и комплекса программ на соответствие требованиям и эталонам;

оценка реализуемости и планирование испытаний комплекса программ в составе системы;

анализ полноты и корректности документации на комплекс программ;

- приемо-сдаточные испытания программного комплекса в составе системы:

испытания соответствия функций и характеристик качества программного продукта и системы требованиям и эталонам контракта;

удостоверение адекватности и качества технологической и эксплуатационной документации программного продукта требованиям на систему;

оформление акта о завершении работ и контракта на создание программного продукта и системы;

- опытную эксплуатацию – Альфа и Бета испытания программного продукта в системе и пользователями;

- завершение испытаний на соответствие требованиям и утверждение готовности программного продукта для предъявления заказчику и поставки пользователям;

- внедрение версии программного продукта для применения в системе и обучение пользователей;

- изменения требований к комплексу программ, создание и сопровождение новых версий программного продукта.

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

составление плана и Программы проведения испытаний;

разработка тестовых сценариев и динамических моделей внешней среды для генерации тестов;

отладка тестовых сценариев и генераторов тестов;

верификация, проверка, выявление и исправление дефектов генераторов тестов;

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

пересмотр и корректировка пользовательской документации;

освоение специалистами по тестированию новых технологий и новых инструментальных средств.

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

В.В. Липаев. Тестирование компонентов и комплексов программ Факторы, которые следует учитывать перед испытаниями программного комплекса на соответствие требованиям, должны включать:

идентификатор версии испытываемого программного продукта;

результаты исправления дефектов, обнаруженных в предыдущей версии, если список дефектов приводится в спецификации, необходимо указать ссылку на требования, функции и характеристики;

описание внешней среды, используемой при применении программного продукта;

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

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

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

Внутренние испытания компонентов и программного комплекса (испытания менеджера проекта), которые зачастую совмещаются с завершением комплексной отладки, должны оформляться документально и могут являться основанием при предъявлении программного продукта заказчику на квалификационные испытания для завершающего оценивания функций и характеристик качества программного продукта (см. ISO 12207, ISO 15504, ISO 16326). РуковоЛекция 2.6. Испытания компонентов и комплексов программ дитель разработки должен оценить уровень реализацию проекта, состояние комплекса программ, тесты, результаты тестирования и документацию для пользователя, учитывая:

полноту охвата испытаниями всех требований и эталонов к функциональным компонентам и к комплексу в целом;

согласованность с требуемыми заказчиком результатами применения программного продукта;

возможность интеграции и тестирования комплекса программ в составе аппаратуры системы;

возможность функционирования и сопровождения версии программного продукта в соответствии с требованиями контракта.

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

Этапы и процессы квалификационного тестирования с целью формального удостоверения для заказчика достигнутых характеристик и реализации требований к комплексу программ и его компонентам в составе системы регламентированы в стандартах ISO 12207, ISO 15504. В них выделены основные, функциональные этапы реализации квалификационного тестирования и испытаний на соответствие требованиям заказчика (см. рис. 2.18):

квалификационное тестирование функциональных компонентов и комплекса в целом вне аппаратуры системы;

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

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

Квалификационное тестирование и предварительные испытания должны включать работы и объекты:

подготовка тестовой версии комплекса программ, содержащей, по крайней мере, два взаимодействующих сложных функциональных компонента, прошедших компонентное тестирование;

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

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

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

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

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

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

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

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

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

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

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

с имитаторами отдельных объектов внешней среды и с реальными воздействиями от операторов-пользователей;

в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов-пользователей на соответствие требованиям.

Процесс должен продолжаться до тех пор, пока интеграция и тестирование не будут выполнены для всех функциональных компонентов программ и аппаратуры. Тестовые варианты должны покрывать все требования системного уровня, требуемые функции и характеристики программного продукта.

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

2.18). Оно должно покрывать все требования в спецификациях системы и подсистем, а также требования к интерфейсу с внешней средой.

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

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

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

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

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

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

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

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

частота использования: сколько экземпляров данной конфигурации, скорее всего, будет использоваться;

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

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

Любые испытания ограничены допустимым количеством и объемом тестирования, а также длительностью работы комиссии Лекция 2.6. Испытания компонентов и комплексов программ испытателей, поэтому не могут гарантировать абсолютную проверку программного продукта, на соответствие требованиям к функциям и характеристикам. Для повышения достоверности определения и улучшения оценивания характеристик, после внутренних или квалификационных испытаний, некоторые экземпляры комплексов программ целесообразно передавать пользователям на опытную эксплуатацию в типовых условиях. Это позволяет более глубоко оценить эксплуатационные характеристики созданного комплекса и оперативно устранять некоторые дефекты и ошибки. Опытную эксплуатацию целесообразно проводить разработчиками с участием испытателей-заказчиков и некоторых пользователей, назначаемых заказчиком. Результаты и характеристики качества опытной эксплуатации после внутренних испытаний могут учитываться при проведении заказчиком квалификационных испытаний для их сокращения.

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

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

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

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

Программа и методики испытаний компонентов и Оценивание качества и соответствия требованиям программного продукта при квалификационных и/или приемо-сдаточных испытаниях проводится комиссией заказчика, в которой участвует руководитель (главный менеджер) разработки и некоторые ведущие разработчики, или аттестованной сертификационной лабораторией (cм. ISO 10006). Комиссия при испытаниях должна руководствоваться следующими документами (рис. 2.19):

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

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

Программой испытаний по всем требованиям контракта, технического задания и спецификаций;

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

комплектом адекватной эксплуатационной и технологической документации на программный комплекс.

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

используемые версии аппаратных средств;

интерфейсное оборудование;

дополнительные внешние устройства;

генераторы тестовых сценариев или динамических тестовых потоков данных.

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

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

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

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

объект испытаний, его назначение и перечень основных документов, определивших его разработку;

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ указания разделов методик в соответствии, с которыми проводились испытания, обработка и оценка результатов;

условия и сценарии проведения тестирования и характеристики исходных данных при динамическом тестировании;

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

описание отличий тестовой и реальной эксплуатационной среды;

описание обнаруженных дефектов и ошибок и рекомендуемых улучшений в испытываемом комплексе программ;

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

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

Завершение испытаний и внедрение версий Завершение испытаний программного комплекса в составе системы должно зафиксировать следующие процессы и результаты:

завершена разработка всех функций комплекса программ и исправление всех выявленных ошибок;

все функциональные компоненты размещены под формальный автоматизированный контроль системы управления конфигурацией компонентов проекта;

завершено компонентное тестирование всех функций и исправление всех выявленных дефектов, версии программного продукта;

подготовлена полная версия программного комплекса с контролируемыми изменениями после испытаний;

версия программного комплекса, переданная на испытания, сопровождается технологической и эксплуатационной документациЛекция 2.6. Испытания компонентов и комплексов программ ей, перечнем изменений, содержит список отчетов о дефектах, которые исправлены в версии;

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

проведены совещания менеджеров и специалистов, посвященные управлению незавершенными работами по устранению дефектов и оценки времени для исправления дефектов;

в предшествующие несколько недель не произошло ни одного сбоя, остановки, неожиданного прекращения процесса или другой аномалии функционирования комплекса программ на объектной ЭВМ в системе;

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

оценки покрытия требований допустимых рисков показали, что все риски сокращены до допустимых пределов;

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

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

Завершаются испытания предъявлением заказчику на утверждение комплекта документов, содержащих результаты комплексных испытаний версии программного продукта:

откорректированные тексты программ и данных на языке программирования и в объектном коде, а также полные спецификации требований на программные компоненты и комплекс в целом после полного завершения тестирования и испытаний;

Программу испытаний программного продукта по всем требованиям технического задания;

комплект методик испытаний и обработки результатов по всем разделам Программы испытаний;

В.В. Липаев. Тестирование компонентов и комплексов программ тесты, сценарии и генераторы тестовых данных, использованные для испытаний программных компонентов и версии продукта в целом;

результаты и протоколы квалификационного тестирования, функциональные и конструктивные характеристики программного продукта в реальной внешней среде;

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

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

комплект эксплуатационной документации, описание программного продукта и руководство пользователя в соответствии с условиями контракта;

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

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

отчет о технико-экономических показателях завершенного проекта версии программного продукта, выполнении планов и использованных ресурсах;

акт о завершении испытаний и готовности к поставке и/или предъявлению для сертификационных испытаний версии программного продукта.

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

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

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

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

завершены все запланированные циклы тестирования, и план проведения испытаний выполнен, тестовое покрытие лучше, чем в случае, когда просто не хватило времени для доведения тестирования до логического конца;

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

время, отведенное на тестирование и испытания, истекло, хотя неизвестно достигнутое качество программного продукта.

Принимая решение прекратить работы по испытаниям, следует В.В. Липаев. Тестирование компонентов и комплексов программ учитывать несколько факторов, которые играют важную роль при оценке неготовности программного продукта к поставкам:

количество дефектов, обнаруженных в процессе тестирования, которые остаются неисправленными;

общее количество возможных предсказуемых дефектов, которые не были исправлены;

процентное отношение количества тестов, которые завершились успешным исходом и устранением дефектов, к числу всех запланированных тестов;

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

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

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

Лекция 2.6. Испытания компонентов и комплексов программ После завершения испытаний новой версий программного продукта, обычно осуществляется процесс ее внедрение для применения (см. рис. 2.18). Это производится, как правило, в два этапа;

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

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

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

выявленные дефекты и ошибки в программном продукте;

предложения по совершенствованию функций и улучшению качества эксплуатируемых версий программного продукта;

В.В. Липаев. Тестирование компонентов и комплексов программ идеи и предполагаемая экономическая эффективность коренной модернизации, расширения функций и/или улучшения характеристик версии программного продукта.

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

отчет о квалификационном тестировании откорректированного программного продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекция 2.7. Управление конфигурацией и сертификация компонентов…

УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ И

СЕРТИФИКАЦИЯ КОМПОНЕНТОВ И

КОМПЛЕКСОВ ПРОГРАММ

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ Управление конфигурацией и сертификация компонентов и комплексов программ должны включать:

- задачи управления конфигурацией требований и тестов компонентов и комплексов программ:

организацию специалистов и процессов управления конигурацией компонентов и комплексов программ;

конфигурационную идентификацию и учет версий комнентов и комплексов программ;

управление запросами на изменения версий компонентов реализацию корректировок версий компонентов и комплексов программ;

- методы, процессы и средства управления конфигурацией требований и тестов компонентов и комплексов программ:

контроль корректности изменений конфигурации версий компонентов и комплексов программ;

сборку и формирование версий конфигурации программного продукта;

методику оформления отчетов о выявленных дефектах, ошибках и предложениях по корректировке требований;

создание отчетов о состоянии и изменениях конфигурации версий программного продукта;

утверждение и выпуск версий конфигурации программного продукта;

архивирование и тиражирование версий программного - управление качеством и сертификацией процессов производства программных продуктов;

- управление качеством и сертификацией программных продуктов;

- сертификацию руководителей и специалистов, управляющих конфигурацией компонентов и комплексов программ.

Такие дефекты обычно обусловлены одновременным, не скоординированным внесением групп изменений или потерей некоторых изменений требований в определенной версии. Это возможно при одновременной разработке или корректировке требований или тестов различных версий программных компонентов, предназначенных для Лекция 2.7. Управление конфигурацией и сертификация компонентов… использования в различных, но определенных версиях сложных комплексов программ.

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

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

подготовку процесса управления требованиями к программному комплексу, компонентам и тестам;

определение конфигурации требований, тестов и их изменений;

контроль изменения конфигурации требований и тестов к компонентам и комплексу программ;

учет состояния конфигурации требований и тестов комплекса программ.

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

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

обозначения, определения и установления состояния компонентов и версии программного комплекса;

управления изменениями и выпуском компонентов и версий программных продуктов;

описания и сообщения о состояниях компонентов и комплекса программ и заявок на внесение изменений в них;

обеспечения полноты, совместимости и правильности описания состояний комплекса программ;

управления хранением, обращением и поставкой программных продуктов.

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

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

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

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

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

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

подтверждение того, что идентифицированы затронутые изменениями компоненты конфигурации;

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

оценку дефектов или предлагаемых изменений требований и тестов, и решения о действиях, которые следует предпринять для их коррекции;

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

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

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

Методы, процессы и средства управления конфигурацией требований и тестов компонентов и Технической основой управления конфигурацией являются системы управления базами данных (СУБД), адекватные целям и функциям проектов, структурированные по целям, назначению и содержанию данных в выделенных подсистемах (рис. 2.21). Они должны обеспечивать возможность управления организационной и проектной деятельностью коллектива специалистов, универсальное хранилище в них необходимых данных, с инструментами наполнения, корректировки, поиска и контроля информации, соответствующей их профессиональной деятельности.

Лекция 2.7. Управление конфигурацией и сертификация компонентов… В.В. Липаев. Тестирование компонентов и комплексов программ Должны быть упорядочены деловые коммуникации между специалистами разных категорий, управление динамическими процессами выполнения изменений и транспортировки корректировок между подсистемами в соответствии с целями их использования специалистами.

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

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

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

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

откорректированные версии и набор изменений требований и тестов, выполненных в каждой из них – база данных утвержденных требований, тестов и реализаций версий программных комплексов и компонентов;

Лекция 2.7. Управление конфигурацией и сертификация компонентов… Эта информация в структурированных подсистемах базы данных управления конфигурацией должна быть защищена от случайных и преднамеренных искажений, путем организованного санкционирования, дублирования и контроля модификаций, истории их создания и изменения, в процессах жизненного цикла комплекса программ. Необходимо гарантировать сохранность версий изменений, с учетом их важности для результатов всего проекта. Особенно защищенным от искажений и разрушения, следует сохранять архив версий программных продуктов, прошедших успешные испытания, утвержденные заказчиком, и скрепленные его подписью. Для устранения дефектов, реализации корректировок и ошибок при развитии новых версий целесообразно выделять рабочую копию предшествовавшей версии и архив накопленных изменений, обеспечивающих возможность «отката» к предыдущей версии в случае разрушительных некорректных изменений в процессе разработки новой версии программного продукта.

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

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

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

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

обеспечивать целостность компонентов конфигурации и базовых версий комплекса, а также защиту их от некорректных изменений требований и тестов;

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

зарегистрированы, утверждены и прослежены изменения в базовых версиях и компонентах конфигурации требований и тестов, находящихся под контролем;

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

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

Руководство по документированию состояния конфигурационного управления требованиями и тестами конкретного сложного программного комплекса и его компонентов должно отражать:

общую структуру комплекта документов на конфигурацию требований и тестов к программному продукту;

номенклатуру и содержание каждого документа, отражающего требования и/или их изменения;

требования к качеству, оформлению и обозначению каждого документа;

регламент комплектования, корректировки и хранения документов;

правила обращения, процессов корректировки и сопровождения документов, отражающих требования и тесты;

графики подготовки, проверки, редактирования, согласования, утверждения и распространения документов.

Лекция 2.7. Управление конфигурацией и сертификация компонентов… Работы по созданию и применению документов конфигурационного управления должны гарантировать пользователям использование требований и тестов, только адекватных санкционированным версиям программных комплексов и компонентов, так чтобы официальные документы могли быть получены только из архива. Каждая единица конфигурации должна быть идентифицирована, документирована и выпущена ее официальная версия до того, как осуществляется производство программных продуктов для пользователей.

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

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

подробное описание сценария функционирования и тестирования программного продукта, и исходных данных, при которых выявлен отказ или дефект;

описание проявления отказовой ситуации или дефекта и документы результатов его регистрации;

предположение о причине, вызвавшей проявление отказа или дефекта;

предложение по корректировке требований к программному комплексу и его компонентам для устранения дефекта и/или совершенствования функциональной пригодности и применения проВ.В. Липаев. Тестирование компонентов и комплексов программ граммного продукта.

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

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

результаты анализа причины и источника выявленного отказа или дефекта;

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

оценки сложности, трудоемкости, эффективности и срочности корректировки программ;

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

Неожиданные или некорректные результаты тестов могут записываться в специальной подсистеме ведения отчетности по сбоям, обеспечивая формирование базы данных, используемой для отладки, устранения проблем и дальнейшего тестирования. Кроме того, аномалии, которые нельзя идентифицировать как сбои, также могут фиксироваться в системе ведения отчетности по сбоям. В любом случае, документирование таких аномалий снижает риски процесса тестирования и помогает решать вопросы повышения надежности тестируемой системы. Отчеты по тестам могут являться входом для процесса управления изменениями и генерации запросов на изменения при отслеживании дефектов. Все корректировки требований, утвержденные для введения в очередную версию, следует регистрировать в следующей подсистеме базы данных. Для каждого изменения должны документироваться содержательная аннотация, а также общие характериЛекция 2.7. Управление конфигурацией и сертификация компонентов… стики и достигнутое на испытаниях качество очередной версии программного продукта.

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

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

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

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

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

Подсистема базы данных подготовленных и утвержденных результатов корректировок требований, а также реализованных В.В. Липаев. Тестирование компонентов и комплексов программ изменений и обобщенных характеристик качества новой версии программного продукта должна содержать:

причина корректировки требований комплекса программ и базы данных (отказ, ошибка, дефект, совершенствование);

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

результаты тестирования версии программного продукта с предполагаемыми изменениями требований;

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

решение по распространению пользователям проведенной модификации требований и/или версии программного продукта;

адрес хранения корректировок, документов и квалификационных тестов новой версии программного продукта.