[ «В.В. Липаев ТЕСТИРОВАНИЕ КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ УЧЕБНИК СИНТЕГ® Москва - 2010 УДК 004.41(075.8) ББК 32.973.26-018я73 Л61 Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, ...»
Институт системного программирования
Российской академии наук
В.В. Липаев
ТЕСТИРОВАНИЕ
КОМПОНЕНТОВ
И КОМПЛЕКСОВ
ПРОГРАММ
УЧЕБНИК
СИНТЕГ®
Москва - 2010
УДК 004.41(075.8)
ББК 32.973.26-018я73
Л61
Липаев В.В.
Тестирование компонентов и комплексов программ. Учебник.
– М.: СИНТЕГ, 2010. – 400 с.
ISBN 978-5-89638-115-0 Учебник состоит из двух частей.
В первой части (7 лекций) рассматриваются системные основы разработки требований к сложным комплексам программ, эталоны при их проектировании и производстве, декомпозиция функций и архитектуры комплексов программ для формирования требований к компонентам и модулям. Изложены требования к характеристикам качества, к тестам и допустимым рискам комплексов программ (КП).
Во второй части (7 лекций) представлены методы тестирования потоков управления и потоков данных программных модулей. Рассмотрено планирование тестирования модулей и компонентов для КП, нисходящая – восходящая сборка и тестирование программных компонентов, подготовка и применение графиков разработки и исполнения тестов для компонентов и комплексов программ. Изложены организация и процессы испытаний, Программа и методики тестирования компонентов и сложных комплексов программ.
Учебник ориентирован на специалистов, студентов и аспирантов для обучения тестированию модулей и программных компонентов, а также крупных программных комплексов высокого качества Рецензенты:
А.К. Петренко – д.ф.-м.н, зав.отделом технологии программирования
ИСП РАН
Б.М. Позднеев – д.т.н., профессор, проректор по информатизации МГТУ «СТАНКИН»В.В. Липаев, автор, ООО «НПО СИНТЕГ», издательство,
ОГЛАВЛЕНИЕ
Введение …………………………………………………………...Часть 1. РАЗРАБОТКА ТРЕБОВАНИЙ К КОМПЛЕКСАМ ПРОГРАММ И КОМПОНЕНТАМ
Лекция 1.1. Организация тестирования компонентов и комплексов программ …………………………..................
Уровни организации тестирования комплексов программ (ТММ).
Модель организации процессов тестирования модулей, компонентов и комплексов программ. Организация и руководители коллектива специалистов для тестирования компонентов и программных комплексов. Установление источников и типов дефектов и ошибок в компонентах и сложных комплексах программ.
Лекция 1.2. Эталоны и требования при проектировании и производстве комплексов и компонентов программ … Системные основы разработки требований к сложным комплексам программ. Формализация эталонов требований и характеристик комплекса программ. Формирование требований компонентов и модулей путем декомпозиции функций комплексов программ.
Лекция 1.3. Требования к функциям и характеристикам качества комплексов программ ………………………… Особенности требований заинтересованных лиц к функциям и характеристикам комплексов программ. Формирование функциональных требований к сложным комплексам программ. Общие требования к качеству функционирования сложных программных комплексов. Требования к характеристикам качества сложных программных комплексов. Требования к эффективности использования ресурсов ЭВМ программным комплексом в реальном времени. Проверка корректности функциональных требований к сложным комплексам программ.
Лекция 1.4. Требования к повторному использованию готовых компонентов при производстве программных комплексов ………………………………………………… Повторное использование компонентов в комплексах программ.
Требования к подготовке компонентов для повторного использования в программных комплексах. Оценки эффективности повторного использования компонентов при производстве программных комплексов. Применение стандартов интерфейсов Открытых систем при производстве компонентов для повторного использования в программных комплексах.
Лекция 1.5. Требования к допустимым рискам и к документированию требований к комплексам программ … Риски при формировании требований к характеристикам компонентов и программных комплексов. Требования к допустимым рискам применения сложных программных комплексов. Документирование требований к программным компонентам и комплексам. Документирование требований к функциям и характеристикам комплексов программ.
Лекция 1.6. Эталоны типов тестов и изменения требований к комплексам программ ………………………………….
Формализация эталонов типов тестов программного комплекса и компонентов. Формализация документов как эталонов тестов комплексов программ. Управление изменениями требований к комплексам программ. Организация изменений и сопровождения требований к комплексам программ.
Лекция 1.7. Верификация, трассирование и обеспечение баланса требований к комплексам программ ………… Верификация качества требований к комплексам программ. Трассирование требований к сложным комплексам программ. Обеспечение баланса требований к качеству комплексов программ.
Часть 2. ТЕСТИРОВАНИЕ МОДУЛЕЙ, КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ …………………… Лекция 2.1. Тестирование потоков управления программных модулей и компонентов ……………………………..
Стратегии выбора тестов для программных модулей. Сложность тестирования ациклических программных модулей. Сложность тестирования модулей, содержащих циклы. Корректность результатов тестирования графов модулей. Примеры оценки сложности тестирования модулей. Проектирование тестирования потоков управления модулей.
Лекция 2.2. Тестирование потоков данных программных модулей …………………………………
Свойства и тестирование потоков данных программных модулей.
Тестирование графов модулей программ с учетом значений переменных и констант. Документы при тестировании программных модулей. Затраты на производство программных модулей и компонентов.
Лекция 2.3. Планирование тестирования модулей и компонентов для комплекса программ ……………………….
Нисходящая – восходящая сборка и тестирование модулей и программных компонентов. Планирование тестирования модулей и компонентов для комплекса программ. Подготовка графиков разработки и выполнения тестов для модулей и компонентов комплекса программ. Применение графиков для планирования производства компонентов и комплексов программ.
Лекция 2.4. Подготовка средств тестирования комплексов программ на соответствие требованиям ………………….
Методы подготовки тестов для тестирования комплексов программ. Требования к генерации динамических тестов внешней среды в реальном времени. Компоненты генераторов динамических тестов внешней среды в реальном времени. Обработка результатов динамического тестирования комплексов программ в реальном времени.
Лекция 2.5. Тестирование программных комплексов на соответствие требованиям к характеристикам и документам ……………………………………………………… Тестирование надежности функционирования программных комплексов. Особенности тестирования функциональной безопасности программных комплексов. Тестирование характеристик производительности и использования ресурсов ЭВМ программными комплексами. Тестирование документации на соответствие требованиям к программным комплексам.
Лекция 2.6. Испытания компонентов и комплексов программ ……………………………………………………….
Организация и процессы испытаний компонентов и комплексов программ. Программа и методики испытаний компонентов и комплексов программ. Завершение испытаний и внедрение версий программных продуктов.
Лекция 2.7. Управление конфигурацией и сертификация компонентов и комплексов программ ………………… Задачи управления конфигурацией требований и тестов компонентов и комплексов программ. Методы, процессы и средства управления конфигурацией требований и тестов компонентов и комплексов программ. Управление сертификацией программных продуктов.
Приложение 1. Международные и государственные стандарты, регламентирующие требования и тестирование компонентов и комплексов программ
Приложение 2. Основы построения и применения графов потоков управления и потоков данных программных модулей и компонентов для тестирования …………… Литература ………………………………………………………..
ВВЕДЕНИЕ
В стране быстро увеличивается общий объем производства программных продуктов и сложность отдельных проектов. Это является одной из причин, возникновения проблем при их разработке, как и то, что многие предприятия, занимающиеся их производством, не уделяют должного внимания автоматизации и обеспечению всего жизненного цикла крупных программных комплексов, а также эффективному применению современных методов управления такими проектами и международным стандартам. Ориентация на программные продукты, поступающие на рынок с Запада, не может решить многие специфические проблемы конкретного создания и применения программных продуктов в стране. Для многих заказчиков и пользователей систем возникла острая необходимость поиска и выбора квалифицированных и надежных отечественных специалистовподрядчиков, способных создавать сложные программные средства и базы данных высокого качества в разумные сроки, с учетом ограничений на затраты труда и другие ресурсы. Обострилась проблема собственных, отечественных разработок оригинальных крупных программных продуктов для ряда отраслей государственного управления, народного хозяйства и оборонной техники. Эти проблемы негативно отражаются на экономике, качестве и конкурентоспособности отечественных информационных систем.Крупные комплексы программ являются важнейшими, интеллектуальными компонентами систем, реализующими обычно их основные, функциональные свойства. Методология управления и развития программных комплексов зависит от многих факторов, от квалификации специалистов, технических, организационных и договорных требований и сложности проектов. Множество текущих состояний и модификаций компонентов в жизненном цикле крупных программных комплексов, менеджерам необходимо упорядочивать, контролировать их развитие и реализацию участниками проекта. Организованное, контролируемое и методичное отслеживание динамики изменений программ и данных, их разработка при строгом учете и контроле каждого изменения, является базовой проблемой эффективного, поступательного развития каждой крупной информационной системы. Накопление в мире знаний, опыта разработки и применения большого количества различных компонентов и сложных комплексов программ способствовало систематизации и обобщению методов и технологий их разработки, сокращению дефектов и неопределенностей в характеристиках и качестве поставляемых и применяемых программных продуктов. В результате сформировалась современная методология и инженерная дисциплина обеспечения процессов жизненного цикла сложных программных продуктов – программная инженерия для различных областей применения.
Основная проблема управления созданием крупных программных комплексов сводить воедино усилия многих исполнителей специалистов разной квалификации, чтобы они выступали при производстве компонентов и всего комплекса как «команда», а не как разрозненная группа независимых, функциональных специалистов. В результате должны обеспечиваться концептуальная целостность систем и высокое качество решения главных задач и функций при сбалансированном использовании ресурсов.
Программные продукты все чаще встраиваются в различные сложные системы реального времени. Работа над такими проектами требует от руководителей и программных инженеров, широкого взгляда и освоения общих методов проектирования и применения систем определенного назначения и сферы использования. Проблему рационального сочетания целей, стратегии действий, конкретных процедур и доступных ресурсов, необходимо решать для достижения основной цели получения программного комплекса с заданными функциональными характеристиками и качеством. Базой эффективного управления производством сложного программного комплекса является план, в котором задачи исполнителей частных работ и компонентов должны быть согласованы между собой по результатам и срокам их достижения, а также с выделяемыми для них ресурсами. Планирование проектирования и производства комплекса программ должно обеспечивать компромисс между требующимися функциями и характеристиками создаваемой системы и ограниченными ресурсами, необходимыми на ее разработку и применение.
Возросла роль регламентирования производства и интеграции модулей и компонентов, применения соответствующих методов и инструментария программной инженерии. Для обеспечения высокого качества программных продуктов особенно важно упорядоченное, планируемое тестирование их модулей, компонентов и комплекВведение сов программ в целом. Руководителям тестирования необходимо участвовать в разработке требований для всей системы, а также осваивать прикладную область применения создаваемого комплекса программ до начала тестирования и обдумывания функций компонентов, их характеристик и тестов, требованиям которых должен отвечать программный продукт. Однако вследствие принципиальной новизны и сложности этих задач, они трудно воспринимаются традиционными программистами и тестировщиками модулей и небольших компонентов и множеством преподавателей отечественной высшей школы.
Коренные отличия между методами и инструментарием индивидуального программирования и тестирования небольших программ и технологией планомерной, инженерной разработки и тестирования модулей, компонентов и сложных программных комплексов приводят к тому, что последние медленно осваиваются и входят в практику работы над крупными проектами больших коллективов специалистов.
Тестирование программ основной метод, способный обеспечивать и удостоверять необходимое качество компонентов и комплексов программ, выявлять и устранять в них дефекты и ошибки при проектировании и производстве. Технологически тестирование имеет две цели: первая состоит в поиске, обнаружении и устранении дефектов и ошибок в программах и в применении покрытия тестами требований к программному комплексу; вторая определяется возможностью статистической оценки того, что при тестировании не проявится дефект или ошибка компонента или комплекса программ.
Обе интерпретации этих целей одинаково важны для тестирования и достижения высокого качества программ. Тестирование для поиска, идентификации и устранения дефектов подразумевает успешность процедуры тестирования, если дефект найден. Это отличается от подхода в тестировании, когда тесты исполняются для демонстрации того, что компонент или программный комплекс полностью удовлетворяет предъявляемым требованиями и, соответственно, тест считается успешным, если не найдено дефектов. Тестирование программ может использоваться для демонстрации наличия дефектов, но никогда не гарантирует их отсутствие. Основная причина этого в том, что полное, всеобъемлющее тестирование недостижимо для реальных сложных программных комплексов. Когда оцениваются и применяются методы тестирования, надо четко определять, что подразумевается под их эффективностью, желательно, в количественных величинах. Только обладая такого рода данными можно говорить о корректности сравнения и оценки эффективности разных методов тестирования.
Основная цель тестирования комплекса программ и его функциональных компонентов состоит в том, чтобы обнаруживать, регистрировать и устранять дефекты и ошибки, которые внесены во время последовательной разработки и реализации требований к его функциям и характеристикам. Тестированию программных модулей и компонентов посвящена обширная литература, однако в ней мало внимания уделяется тестированию сложных комплексов программ на соответствие исходным требованиям к их функциям. Учебник ориентирован на освоение специалистами методов последовательного тестирования модулей, компонентов и программных комплексов, которые совместно должны подготавливать и обеспечивать высокое качество сложных программных продуктов. Общая структура учебника построена по традиционной V – схеме, в которой левая часть буквы отражает процессы разработки и конкретизации требований к комплексу, компонентам и модулям программ сверху вниз, а правая часть представляет процессы последовательного тестирования снизу вверх, начиная от модулей и до полного комплекса программ. Соответственно, весь цикл лекций представлен в виде двух частей:
проектирование и разработка требований к функциям и характеристикам программных комплексов, компонентов и модулей – часть 1;
тестирование и обеспечение корректного функционирования модулей, компонентов и комплексов программ – часть 2.
Реализация частных требований при разработке модулей и компонентов комплексов программ, а также их тестирование считаются исходными для сборки программных комплексов, в соответствии с исходными требованиями к их функциям и характеристикам. Для идентификации, локализации и устранения основной массы дефектов и ошибок, необходимо применять последовательное тестирование и корректировку модулей, компонентов и комплексов программ с использованием соответствующих методов и средств. Организованное, контролируемое и методичное отслеживание изменений компонентов в комплексах программ, их разработка при строгом учете и контроле каждого изменения, является базовой задачей эффективного, поступательного развития сложных программных продуктов высокого каВведение чества. Исходными для этого развития всегда являются: цели, функции, характеристики и допустимые риски реализации требований, которые в цикле лекций иерархически представляются для объектов трех уровней: комплексов программ, компонентов и модулей.
Внутренняя структура процессов тестирования для этих объектов в основном подобны и включают: формирование требований к функциям и характеристикам; тестирование на соответствие требованиям к объекту; обнаружение и идентификацию дефектов и ошибок; корректировку и устранение дефектов; испытания и удостоверении корректности объектов, и документирование результатов тестирования.
Они имеют следующие особенности:
комплексы программ зависят от сложности функциональных задач системы, могут содержать сотни и более компонентов и входить, как составные части, в более сложные комплексы, что повышает трудности формализации требований и определяет необходимость наиболее высокой квалификации уникальных руководителей, аналитиков и специалистов для их тестирования;
компоненты могут состоять из десятков и сотен модулей, для разработки и тестирования которых необходимы высококвалифицированные специалисты аналитики, программисты, тестировщики и интеграторы, чья квалификация и деятельность трудно формализуются, сильно зависят от взаимодействия множества разных специалистов в «командах» для создания программных компонентов;
модули наиболее многочисленные элементы комплексов программ, которые разрабатываются наименее квалифицированными специалистами тестировщиками и программистами, чьи результаты в совокупности характеризуются наибольшим количеством относительно простых дефектов и ошибок, вследствие чего формализации их тестирования в лекциях уделено значительное внимание.
Требования к квалификации специалистов для создания этих объектов высокого качества значительно различаются. Практически во всех лекциях приходится касаться особенностей необходимой их квалификации для решения соответствующих функциональных задач. Основное внимание сосредоточено на методах и формализации полноты и качества процессов тестирования для всех трех типов объектов. В лекциях представленные объекты не всегда четко разделены и формализованы, некоторые процессы, особенно связанные с тестированием модулей и компонентов, рассматриваются совместно. Они использованы в учебнике как базовые элементы при анализе методов тестирования в жизненном цикле комплексов программ. Это определило следующие основные допущения и особенности изложения тестирования программных комплексов на соответствие эталонам и требованиям:
объектами тестирования являются сложные комплексы программ (сотни тысяч строк) для систем обработки информации и управления в реальном времени, разрабатываемые большими коллективами – «командами» специалистов, создающими программные компоненты и модули высокого качества;
в результате тестирования программные комплексы должны соответствовать целостному комплексу требований (первому эталону) – к функциям, характеристикам, архитектуре и качеству, утвержденному заказчиком и согласованному с разработчиками;
наборы применяемых совокупностей тестов рассматриваются как второй эталон функций и характеристик модулей, компонентов и программных комплексов, которые должны адекватно отражать и покрывать весь набор требований к конкретному программному эталону соответствующего уровня;
в качестве третьего эталона для ряда комплексов программ используется эксплуатационная документация, которая должна обеспечивать эффективное применение программного продукта пользователями в соответствии с исходными требованиями к функциям, характеристикам и допустимым рискам;
разработка требований и тестирование модулей, компонентов и комплексов программ осуществляется методами программной инженерии в условиях регулярного планирования и управления обнаружением и устранением дефектов и ошибок (отладкой), а также при ограниченных ресурсах, выделяемых заказчиком на весь их жизненный цикл;
для тестирования модулей, компонентов и комплексов программ применяются сценарии и процедуры детерминированных и некоторых типов динамических тестов, на основе аттестованных моделей внешней среды и/или систем реального времени;
процессы и результаты формирования требований и реализации тестирования модулей, компонентов и комплексов программ должны быть снабжены глубоким, детальным документированием, архивированием и конфигурационным управлением исходными, промежуточными и отчетными документами.
Требования к программному продукту должны быть зафиксированы в соглашении (договоре и техническом задании) между заказчиком и выполняющими проект руководителями и специалистами, отражающем потребности заказчика и пользователей в таком виде, чтобы разработчики могли построить удовлетворяющий их комплекс программ, его компоненты и модули. Требования должны являться, конкретным исходным эталоном при разработке комплекса программ, чтобы можно было при тестировании и заключительных испытаниях установить, когда они удовлетворены полностью или в какой степени. Эти данные должны устанавливать состав, содержание и значения результатов исполнения программ, которые следует получать системе или пользователям при определенных условиях и исходных данных.
Тесты и спецификации требований к ним являются вторыми эталонами представления требований к модулям, компонентам и комплексу программ. При разработке необходимо иметь пригодные для применения тестирования исходные эталоны требования и/или сценарии использования функций системы. Их необходимо анализировать и определять в терминах адекватных требований к функциям и характеристикам программного комплекса, а также к тестам, устанавливающим их содержание и корректность. Такая вторая форма описаний содержания программного комплекса, компонентов и модулей должна формироваться и использоваться для сквозной верификации спецификаций требований к тестам сверху вниз, а также подвергаться верификации на корректность соответствия исходным требованиям к комплексу, компонентам и модулям программ разного уровня.
Особенности деятельности специалистов при разработке требований к функциям, процедурам и характеристикам исполнения программ, а также описания и реализация программистами требований к модулям, компонентам и комплексам программ, существенно отличаются от представлений и методов описания тех же функций программ тестировщиками – создателями сценариев и процедур тестирования результатов их исполнения. Они акцентируют свою деятельность на конкретных требованиях к процедурам проверки функционирования, возможных результатах и взаимодействии компонентов программных комплексов. Это позволяет выявлять дефекты, и повышать качество путем сопоставления двух методов и результатов описания одних и тех же функций и характеристик определенных программ. При этом существенно, что мала вероятность одинаковых ошибок в требованиях к сценариям и результатам исполнения тестов и в требованиях к функциям и характеристикам исполнения модулей, компонентов и комплексов программ. Кроме того, параллельная и независимая разработка спецификаций требований к функциям программ и спецификаций требований к адекватным тестам позволяет распараллеливать по разным специалистам производственные работы, что ведет к сокращению сроков создания модулей, компонентов и комплексов программ необходимого качества.
По существу, требования к комплексу (модулю или компоненту) программ и тесты для проверки их адекватности и полноты отражают один и тот же объект, но в разной форме. Поэтому сложность представительного описания тестов соизмерима со сложностью описания полной совокупности требований к функциям, характеристикам и соответствующего текста программ. Вследствие этого трудоемкость и другие ресурсы для разработки адекватных тестов должны соответствовать ресурсам и трудоемкости при создании и реализации программистами корректных требований, определяющих полностью тестируемый объект. Таким образом, программной (процедурной) форме представления текстов программ должно полностью соответствовать его равноправное содержание в форме сценариев и значений тестов для проверки их взаимного соответствия. При этом дефекты и ошибки возможны в обеих формах описания комплекса программ (не только в текстах программного комплекса, но и в содержании тестов), определение их места и устранение является основной задачей тестирования. Однако на практике обычно это не учитывается, и выделяемые на тестирование ресурсы бывают значительно меньше и недостаточными для полноценного тестирования требований к модулям, компонентам и сложным комплексам программ, что определяет их не полное соответствие требованиям и недостаточное качество.
Основная цель создания программного комплекса состоит в обеспечении его применения пользователями или в системе, в соответствии с назначением и эксплуатационной документацией или документами, необходимыми для корректного функционирования системы. Эта документация должна быть адекватна требованиям к функциям и характеристикам программного продукта, однако она разрабатывается обычно независимыми специалистами на основе исходных требований и их представлений о способах применения продукта. В результате документация может не полностью соответствовать исходным требованиям заказчика и функциям, которые проверены при тестировании, однако эксплуатационные характеристики, доступные для пользователей должны рассматриваться как конечная цель всего проекта. С этой позиции эксплуатационные документы являются еще одним, третьим эталоном для тестирования, которому должен соответствовать программный комплекс. В процессе такого тестирования могут выявляться дефекты, ошибки и противоречия: в требованиях заказчика, в программном комплексе и компонентах, в результатах их тестирования, а также в эксплуатационных процедурах и документах. Эти недостатки должны устраняться в процессах системного анализа для достижения взаимной адекватности всех трех представлений необходимых функций и характеристик программного продукта.
Понятие «тестирование» далее используется в широком смысле этого слова, включая (не явно) устранение обнаруженных дефектов и ошибок. При этом внимание акцентируется на методах и процессах выявления дефектов и ошибок при тестировании. Особые специалисты и работы требуются для «отладки» комплексов программ, корректировки, устранения ошибок и обеспечения их соответствия исходным требованиям к заданным функциям и качеству. Для этого необходима локализация ошибок, их диагностика, разработка корректировок программ, контроль выполненных изменений и регрессионное тестирование для регистрации результатов устранения обнаруженных ошибок. Процессы корректировки являются особенно сложными и требуют участия в них соответствующих программистов модулей, иногда не только тех, где обнаружены ошибки, а также возможно руководителей разработки компонентов и может быть всего комплекса программ. Тем самым процессы выходят из сферы тестирования в область разработки текстов программ, для чего необходимы специалисты, участвующие в создании всего комплекса программ. Эти процессы определяются функциональными и специфическими особенностями всего производства комплексов программ и в учебнике не рассматриваются. После того, как проведены корректировки программ, приходится возвращаться к деятельности тестировщиков для регрессионного их тестирования и удостоверения, что действительно устранены обнаруженные ошибки и при этом не проявились новые.
Современные программные продукты, поставляемые заказчикам или на рынок, должны иметь конкретные, гарантированные и документированные цели, функции и характеристики. В то же время в жизненном цикле сложных комплексов программ невозможно в начале проекта предусмотреть все требования к функциям, характеристикам и качеству абсолютно точно, без дефектов и ошибок. Кроме того, программные комплексы обычно имеют длительный жизненный цикл с рядом версий, в течение которого они совершенствуются, расширяются, и повышается их качество. Поэтому процессы формирования изменений и реализации требований должны организовываться на основе регулируемых итераций версий, в которых периоды поставляемых стабильных, испытанных версий применения программных продуктов чередуются с интервалами пошагового расширения функций, совершенствования качества и оперативного адаптирования к характеристикам внешней среды у конкретных пользователей или в системах. Для этого в сложных проектах целесообразно применять международные стандарты, регламентирующие жизненный цикл комплексов программ (см. Приложение 1), и жесткую дисциплину координируемой деятельности коллектива специалистов для производства модулей, компонентов и комплексов программ, и документируемого конфигурационного управления версиями требований и тестов для обеспечения качества реализации изменяющихся требований.
Для решения важнейших проблем развития и применения современных систем требуется подготовка и воспитание квалифицированных специалистов в области индустрии производства сложных программных продуктов высокого качества. Необходимо их обучение методам и современной программистской культуре промышленного создания высококачественных продуктов. Они должны уметь формализовать требования и достигать при тестировании необходимые значения качества функционирования и применения сложных комплексов программ, с учетом ограниченных ресурсов, которые доступны для получения и совершенствования этого качества.
В жизненном цикле сложных программных средств для обеспечения их высокого качества целесообразно выделять специалистов, ответственных за соблюдение регламентированной технологии проектирования и производства, за измерение и контроль качества комплексов программ в целом и их компонентов. Необходимо обучать этих специалистов анализу и оцениванию конкретных факторов, влияющих на качество функционирования программных продуктов со стороны реально существующих и потенциально возможных дефектов и ошибок в программах.
Учебник ориентирован на специалистов, студентов и аспирантов, имеющих знания и опыт программирования, тестирования модулей и программных компонентов, пригодных для использования в сложных комплексах программ. Он может служить методической базой для учебного курса, способствующего подготовке специалистов для разработки и тестирования сложных программных комплексов с учетом рекомендаций международных стандартов. Учебник полезно использовать при создании инструкций и практических руководств на предприятиях, реализующих сложные программные продукты, требующие применения методов программной инженерии.
Основные рисунки учебника подготовлены в форме таблиц, отражающих структуру и содержание лекций, которые на практике при их чтении целесообразно использовать путем предварительного формирования слайдов, например, с помощью системы «Презентация – Microsoft Power Point».
В.В. Липаев. Тестирование компонентов и комплексов программ
РАЗРАБОТКА ТРЕБОВАНИЙ К КОМПЛЕКСАМ
ПРОГРАММ И КОМПОНЕНТАМ
ОРГАНИЗАЦИЯ ТЕСТИРОВАНИЯ КОМПОНЕНТОВ И
КОМПЛЕКСОВ ПРОГРАММ
Уровни организации тестирования комплексов программ Эффективность процессов тестирования в значительной степени зависят от уровня организации, применяемых методов и технологических средств разработки и тестирования модулей, компонентов и комплексов программ – рис. 1.1. Их можно отражать моделью зрелости тестирования (ТММ) (Test Maturity Model), разработанной Институтом технологии программного обеспечения США. Она содержит набор уровней зрелости организации, через которые проходит предприятие с целью усовершенствования процессов тестирования.Это способствует повышению профессионализма при тестировании программных комплексов по аналогии с моделью технологической зрелости (СММI) для жизненного цикла сложных комплексов программ, которая разработана Институтом программной инженерии США (SEI). Предприятия, заинтересованные в оценке и улучшении своих возможностей по тестированию, включаются в общее усовершенствование процесса разработки программ. Наличие однозначно соответствующих уровней в обеих моделях зрелости логически упростит параллельное усовершенствование процессов. Тестирование – это часть всего процесса разработки программных комплексов, следовательно, рост его зрелости нуждается в поддержке областей ключевых процессов, связанных с ростом эффективности основных процессов производства. Любая организация, желающая усовершенствовать свой процесс тестирования с помощью внедрения ТММ, Лекция 1.1. Организация тестирования компонентов и комплексов прогр. должна, прежде всего, заняться усовершенствованием процессов жизненного цикла программ в целом, определив основные направления СММI.
Организация тестирования компонентов и комплексов - определение уровня организации тестирования комплексов программ (ТММ);
- модель организации процессов тестирования модулей, компонентов и комплексов программ;
- организацию и руководителей коллектива специалистов для тестирования программных комплексов;
- установление источников дефектов и ошибок в компонентах и комплексах программ:
понятие дефекта или ошибки в программе;
статистика и характеристики ошибок и дефектов в компонентах и комплексах программ;
устранение первичных ошибок, на основе их вторичных - типы системных дефектов и ошибок в сложных комплексах организационные дефекты требований и эталонов к программному комплексу;
системные ошибки и недостатки определения требований к программному комплексу;
ошибки определения характеристик системы и внешней дефекты и ошибки программных комплексов, которые ошибки комплексов программ по сложности обнаружения и масштабу корректировок;
сложность проявления, обнаружения и устранения ошибок;
ошибки проектирования и разработки архитектуры программного комплекса;
ошибки корректности формирования и выполнения требований к компонентам и программному комплексу;
ошибки проектирования и разработки модулей и компонентов комплексов программ.
В.В. Липаев. Тестирование компонентов и комплексов программ Исследования показывают, что предприятия, пытающиеся достичь определенного уровня ТММ, должны обладать, по крайней мере, тем же уровнем модели СММI. Модель ТММ хорошо подходит для автоматизированного тестирования программных комплексов потому, что эффективные программы проверки и оценки проистекают из программ производства, которые спланированы, выполняются, управляются и отслеживаются надлежащим образом. Хорошая программа тестирования не существует в вакууме; она должна быть составной частью всего процесса разработки программного комплекса.
Представленный ниже перечень отражает уровни зрелости, которые имеют непосредственное отношение к организованному, автоматизированному тестированию программ, в учебнике внимание сосредоточено на четвертом и пятом уровнях.
Уровень 1 ТММ– начальный. Тестирование носит хаотический характер; оно плохо определено и не отличается от отладки. Тесты разрабатываются специальным образом после завершения кодирования. Тестирование и отладка сочетаются с целью устранения ошибок программ. Целью тестирования является демонстрация того, что разработанные программы работают. Программные продукты внедряются без обеспечения качества. Ресурсы, средства и надлежащим образом подготовленный персонал отсутствуют. На этом уровне не существует цель достижения зрелости.
Уровень 2 ТММ – фаза определения, тестирование отделено от отладки и определено как фаза, следующая за кодированием. Это планируемая работа, однако планирование тестирования на уровне может происходить непосредственно после кодирования по причинам, касающимся незрелости процесса тестирования. Задача тестирования на этом уровне – показать, что программы соответствуют своей спецификации. Определены основные приемы и методы тестирования. На этом уровне ТММ, многие проблемы качества возникают изза того, что планирование тестирования производится на позднем этапе жизненного цикла разработки программного комплекса. Кроме того, дефекты переходят в код из фазы требований и проектирования, поскольку никакие программы критического просмотра не касаются этой важной проблемы. Тестирование после кодирования, основанное на исполнении программ, все еще считается главной работой по тестированию.
Лекция 1.1. Организация тестирования компонентов и комплексов прогр. Уровень 3 ТММ – интеграция. Тестирование больше не является фазой, следующей за кодированием, оно интегрировано в полный жизненный цикл разработки программного комплекса. Предприятия могут использовать навыки по планированию тестирования. Уровень 3 начинается с фазы разработки требований, продолжается на протяжении всего жизненного цикла и поддерживается версией V – модели. Цели тестирования устанавливаются с учетом требований, основанных на нуждах пользователя, и используются для проектирования сценариев тестирования и критерия успешного прохождения тестов. Существует подразделение по тестированию, и тестирование признано профессиональной деятельностью. Тестирование находится в центре организации технического производства комплекса программ. Основные инструментальные средства поддерживают главные работы по тестированию.
На этом уровне предприятие начинает осознавать важную роль критического просмотра при контроле качества, но просмотры еще не проводятся в ходе всего жизненного цикла. Программа измерения тестирования еще не применяется к атрибутам качества процессов и продукта.
Уровень 4 ТММ – управление и измерение. Тестирование – измеряемый и выражаемый в количественной форме процесс. Проверки на всех фазах процесса разработки признаны работами по тестированию и контролю качества. Программные продукты тестируются по таким атрибутам качества, как корректность, надежность, удобство использования и возможность сопровождения. Тестовые сценарии из всех компонентов собираются и записываются в базу данных конфигурационного управления тестовых сценариев для повторного использования и регрессионного тестирования. Дефекты фиксируются, и им присваивается уровень серьезности. Ошибки в процессе тестирования возникают из-за отсутствия философии предотвращения дефектов, автоматизированной поддержки сбора, анализа и распространения метрик ошибок, относящихся к тестированию.
Уровень 5 ТММ – оптимизация, предупреждение дефектов и управление качеством. Поскольку в результате достижения зрелости на предыдущих уровнях получена некоторая инфраструктура, теперь процесс тестирования определен и управляем, а его стоимость и эффективность могут контролироваться. Механизмы уровня 5 способствуют повышению гибкости и постоянному совершенствованию тестирования. Практикуются предотвращение дефектов и управление качеВ.В. Липаев. Тестирование компонентов и комплексов программ ством. Процесс тестирования определяется статистическими выборками и измерениями уровней доверия, достоверности и надежности компонентов и комплекса программ. Утверждается процедура выбора и оценки средств тестирования. Автоматизированные средства поддерживают выполнение и повторное использование тестовых сценариев, обеспечивают поддержку элементов, относящихся к тестированию, сбору и анализу дефектов, а также к сбору, анализу и применению метрик качества.
Модель организации процессов тестирования модулей, компонентов и комплексов программ В учебнике в качестве основой используется традиционная V – модель организации, взаимодействия процессов формирования и декомпозиции требований к функциям, характеристикам и структуре комплексов программ и последовательного комплексирования и тестирования для удовлетворения этих требований – рис. 1.2. Анализ, проектирование и производство отражаются сверху вниз левой стороной V – модели, а сборка, тестирование и испытания снизу вверх – правой стороной схемы. Эта модель иллюстрирует естественные потоки и взаимодействие процессов разработки требований и тестирования при последовательной реализации основных базовых элементов сложных программных комплексов, компонентов и модулей. При этом важную роль играет организация коллектива специалистов, реализующих процессы тестирования.
Основой процессов организации тестирования являются требования к функциям и характеристикам системы управления и обработки информации, использующей комплекс программ. Системные, функциональные требования должны отражать потребности к задачам и функциям программного комплекса, содержащего взаимосвязанные компоненты и модули. При этом система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть оперативный персонал, выполняющий определенные функции системы. Программные комплексы все больше встраиваются в различные системы.
Работа над такими проектами требует от коллектива квалифицированных программных специалистов широкого взгляда на общие задачи проектирования систем.
Лекция 1.1. Организация тестирования компонентов и комплексов прогр. В.В. Липаев. Тестирование компонентов и комплексов программ Программным менеджерам и аналитикам необходимо участвовать в выработке требований для всей системы, а также освоить прикладную область, требованиям которой должен будет отвечать программный продукт.
Спецификации требований к системе являются результатом системных решений и источником для соглашений о создании или приобретении функциональных программных компонентов и критерия их приемки. Они также являются основой для принятия решений по производству или приобретению и повторному использованию компонентов для их верификации и для установления стратегии комплексирования этих компонентов в сложный комплекс программ.
Порядок проектирования архитектуры должен позволять проводить анализ изменений требований в течение жизненного цикла системы, а также является источником информации для последующего повторного использования архитектуры и компонентов. Также это источник информации, при помощи которой определяются необходимые тесты в ходе комплексирования компонентов системы, которые ниже представлены процессами V – модели с краткими комментариями (см. рис. 1.2).
Требования к функциям, характеристикам и структуре программного комплекса формируются на основе заданных функций, свойств и характеристик системы и должны удовлетворить возможность его применения по основному назначению с требуемым качеством. Они должны решать весь комплекс задач системы с учетом ограниченных ресурсов.
Декомпозиция требований и структуры программного комплекса на программные компоненты необходима для снижения сложности и реструктуризации компонентов комплекса, позволяющей вести разработку и тестирование программ относительно небольшими группами специалистов, которым представляются корректные требования к функциям, характеристикам и качеству определенных компонентов.
Декомпозиция требований и структуры программных компонентов на программные модули должна обеспечивать возможность корректной формализации требований к функциям и характеристикам каждого модуля, тестируемого определенным тестировщиком, гарантирующим его качество и возможность применения в определенных программных компонентах.
Лекция 1.1. Организация тестирования компонентов и комплексов прогр. Разработка и/или выбор готовых и тестирование программных модулей на соответствие с требованиям должны гарантировать их качество и обеспечивать возможности включения в программные компоненты. Модули являются наиболее массовыми элементами комплексов программ, в их создании участвуют наименее квалифицированные специалисты и при тестировании выявляется наибольшее количество дефектов и ошибок.
Сборка, комплексирование модулей и тестирование компонентов на соответствие требованиям должны сформировать и подтвердить реализацию функций достаточно крупными функциональными компонентами высокого качества, готовыми к встраиванию в комплекс программ.
Сборка, комплексирование компонентов и тестирование комплекса программ на соответствие требованиям должны завершить тестирование комплекса с полным набором компонентов, соответствующих требованиям, и реализацию всех функций программного комплекса.
Испытания программного комплекса на соответствие требованиям к функциям, характеристикам и структуре должны обеспечить корректное решение и контроль всех функциональных задач в соответствие с требованиями к системе, пригодность для поставки и внедрению в систему заказчика и пользователям.
Организация и руководители коллектива специалистов для тестирования компонентов и программных Коллективам – командам тестировщиков должны быть присущи свойства всех производственных коллективов. Создание коллектива специалистов представляет собой процесс планируемого и хорошо продуманного стимулирования к эффективному труду при одновременном сведении к минимуму трудностей и препятствий, мешающих проявлению навыков и изобретательности членов коллектива. На эффективность результатов коллективной работы влияют следующие основные факторы:
команда должна иметь правильное соотношение навыков, опыта и личностных качеств членов группы;
члены группы должны воспринимать себя как единую коВ.В. Липаев. Тестирование компонентов и комплексов программ манду, а не как простую совокупность индивидуумов, работающих над одной проблемой;
между членами команды должны быть дружеские отношения;
необходимо организовать команду таким образом, чтобы каждый чувствовал свою ценность и был удовлетворен своей ролью в результатах.
Организация команды, которая могла бы эффективно работать над комплексом программ, является сложной задачей для руководителя. Необходимо, чтобы в команде было равное соотношение технических навыков, опыта и выражения индивидуальности. Наилучший способ воспитать дух команды – дать возможность каждому почувствовать, что он несет определенную долю ответственности за результаты и что ему доверяют, а также гарантировать доступ к проектной информации для всех членов коллектива. Регулярный обмен информацией – самый дешевый и эффективный способ дать людям почувствовать себя частью команды.
Формирование команды, которая могла бы эффективно работать над компонентом, функцией или комплексом программ, является достаточно сложной задачей. Необходимо обучать подчиненных справляться с большим напряжением и поощрять профессиональную работу во взаимодействии и по графику. Для обеспечения приверженности подчиненных выполняемой работе следует нанимать людей, цели которых совпадают с целями предприятия, а также людей, высоко ценящих конкретную работу в целом. Полезно как можно раньше поставить перед сотрудниками интересные задачи и обеспечить условия для их удовлетворенности результатами собственного труда.
Для создания благоприятной, здоровой и безопасной рабочей обстановки в коллективе целесообразно давать подчиненным разнообразные, интересные задачи, обеспечить социальные гарантии, подбирать сотрудников, с которыми приятно работать, добиваться положительных откликов заказчиков, заручиться доверием сотрудников, уделять внимание к работе других рабочих групп. Необходимо также вовлекать сотрудников в процесс принятия решений и поощрять хорошую работу продвижением по службе и предоставлением особых прав. Для эффективного выполнения проектных работ следует предоставить все необходимые ресурсы и обеспечить безопасность работ. Для поддержания производительности труда на должном уровне Лекция 1.1. Организация тестирования компонентов и комплексов прогр. полезно разработать программу оценки и контроля сроков и качества выполненных работ, а также обучения персонала. Следует создать у подчиненных уверенность в том, что администрация готова решать их проблемы, справедливо распределять премии, выдвигать сотрудников только по их деловым качествам, продвигать новые идеи, сохранять лояльность к работникам, предоставлять возможности для роста кадров, а также доступ к информации.
Большую роль в деле стабилизации коллектива играет социально-психологический климат. Это психологическое состояние коллектива, характер ценностных ориентаций, межличностных отношений и взаимных ожиданий в нем. Оно зависит от среды и уровня развития коллектива и непосредственно влияет на эффективность деятельности его членов, на осуществление основных его функций.
Благоприятным является климат такого коллектива, ценности и отношения в котором отвечают задачам развития коллектива: у членов достаточно развита потребность в труде как сфере актуализации личности; в межличностных отношениях развиты взаимное доверие и уважение друг к другу, взаимная информированность по значимым вопросам, взаимовыручка и взаимная ответственность.
Основная цель квалифицированных руководителей тестирования обеспечить функционирование программного продукта в соответствии с установленными и утвержденными требованиями при любых заданных условиях и данных. Комплекс должен удовлетворять требованиям тест-менеджера и конечных пользователей, при этом должно быть выявлено и устранено как можно больше его дефектов. Кроме того, тестирование должно обеспечивать характеристики качества, достаточные для принятия решения о готовности программного компонента для комплексирования с другими компонентами системы и его применения по назначению в целом.
Существенным для сложных проектов является участие профессиональных руководителей по тестированию в разработке требований к программным компонентам и комплексу. На этапе определения требований руководители тестирования должны способствовать созданию ясных и непротиворечивых требований, рассматривать конфликтующие пожелания, поступающие от различных участников проекта комплекса программ и находить компромиссы, необходимые для определения приоритетов набора функций, представляющих наибольшую ценность тестирования для максимального чисВ.В. Липаев. Тестирование компонентов и комплексов программ ла участников проекта, прежде всего, пользователей. Руководители должны вести переговоры с заказчиком, руководством системы, пользователями и разработчиками и поддерживать равновесие между тем, чего хочет руководитель производства комплекса программ, и тем, что может предоставить команда разработчиков программ и тестировщиков за ресурсы и время, отведенные для их реализации. Участие тестировщиков на этом этапе нужно еще и для того, чтобы обеспечить формулировку свойств совокупности требований в пригодных для тестирования терминах. При определенном исходном состоянии системы и множестве входных параметров тестировщики должны иметь возможность предсказать состав и содержание выходных эталонных данных тестирования комплекса программ.
Руководство тестированием компонентов и комплекса программ могут осуществлять один или два лидера – менеджера с различными функциями. Менеджер проекта программного продукта этот специалист обеспечивает коммуникацию между заказчиком и проектной командой, его задача определить и обеспечить удовлетворение требований заказчика с учетом доступных ресурсов. Менеджер проекта является высшим должностным лицом, принимающим важнейшие решения по внесению изменений и корректировке требований и конфигурации сложных комплексов программ. Он взаимодействует с заказчиком и пользователями, определяющими модификации, для согласования изменений требований к системе. Заказчик системы должен оценивать и утверждать наиболее крупные изменения, заметно влияющие на условия контракта, технические требования или стоимость программного продукта.
Менеджер системный архитектор программного продукта управляет коммуникациями и взаимоотношениями в проектном коллективе, является координатором тестирования компонентов и комплекса программ, разрабатывает базовые, функциональные спецификации требований и управляет ими, ведет график управления тестированием проекта и отчитывается за его состояние, инициирует принятие критичных для хода проекта модификаций. Он должен организовывать структуру и состав коллектива квалифицированных специалистов для тестирования, выделять и учитывать личные свойства и психологические характеристики специалистов при организации «команд» для эффективного тестирования модулей, компонентов и комплексов программ.
Лекция 1.1. Организация тестирования компонентов и комплексов прогр. В стратегии тестирования следует учитывать характеристики системы: количество компонентов программного продукта, типы, размер, критичность и безопасность создаваемых и применяемых компонентов и документов. Необходимо осуществлять проверку спецификаций требований к компонентам программного комплекса, чтобы удостовериться, что они соответствуют базовой концепции проекта и функций программного продукта, осуществлять управление изменением приоритетов тестирования задач, функций и компонентов, а также добавлением или исключением новых функций компонентов комплекса программ.
Руководители, контролирующие и управляющие обеспечением качества программных продуктов, должны овладеть стандартами и методиками предприятия, поддерживающими регистрацию, контроль, документирование и воздействия на показатели качества на этапах тестирования комплексов программ. Они должны обеспечивать эксплуатацию системы качества проекта, выявление всех отклонений от заданных показателей качества объектов и процессов, а также от предписанной технологии на этапах сопровождения и управления конфигурацией. Осуществлять выбор, организацию и упорядочение рентабельных стратегий, процессов и методов тестирования компонентов и комплексов программ, анализировать и выбирать приоритеты сценариев и значений тестов для эффективного тестирования компонентов и комплексов программ. Эти же специалисты должны анализировать возможные последствия выявленных отклонений от требований технического задания или спецификации на изменения. В результате должны приниматься меры либо по устранению отклонений, либо по корректировке требований, если устранение отклонений требует чрезвычайно больших ресурсов.
Разработке тестовых процедур должны предшествовать работы руководителей по настройке и установке тестовой среды, по подготовке документации необходимой для регламентирования тестирования. Руководитель тестирования должен обеспечивать инструкции по разработке тестовых процедур и применению генераторов динамических тестов, которые будут использоваться тестировщиками. Сложность необходимых тестов для контроля функции программного комплекса, обычно такая же, как сложность разработки и программирования соответствующей функции. Покрытие их тестами для устранения дефектов и обеспечения качества это последоваВ.В. Липаев. Тестирование компонентов и комплексов программ тельное покрытие модулей, компонентов или комплексов программ из пространства применяющихся тестов для их контроля, которое должно соответствовать пространству требований к функциям и характеристикам программного продукта.
Прогнозирование руководителями затрат ресурсов на тестирование компонентов и комплексов программ, возможно более или менее корректно, на основе обобщения статистических данных ряда предшествующих проектов. Обычно наиболее важным для реализации проекта и зависящим от большинства его особенностей и факторов является трудоемкость, непосредственно определяющая стоимость и длительность тестирования создаваемого комплекса программ и его компонентов. Следует оценивать рентабельные, допустимые сроки и ресурсы для завершения плана тестирования программного комплекса. Ограничения реальных ресурсов на верификацию и тестирование определяют достижимое качество версий программных продуктов.
Анализ и мониторинг характеристик, последствий и частости появления при тестировании выявленных дефектов конкретных модулей программы может служить ориентиром руководителям для оценки индивидуальной профессиональной квалификации и качества работы определенных программистов, разработчиков компонентов и комплексов программ. Следствием такого анализа может быть выделение некоторых специалистов – разработчиков программ, отличающихся большим числом обнаруживаемых тестировщиками дефектов, для их замены или дополнительного обучения с целью сокращения в компонентах числа первичных ошибок соответствующего типа. Накопление, классификация и обобщение характеристик дефектов определенных классов позволяет прогнозировать при тестировании обнаружение ошибок определенных программистов, а также необходимое распределение состава и квалификации специалистов тестировщиков по компонентам и функциям в составе комплекса программ.
Организационная структура коллектива специалистов при производстве сложных комплексов программ должна учитывать: цели и функции тестирования; взаимодействующие организации; службы проектирования; систему обеспечения качества и средства, которые могут быть привлечены, учитывать, если необходимо, субподрядчиков и поставщиков. В процессах разработки и тестирования Лекция 1.1. Организация тестирования компонентов и комплексов прогр. сложного программного комплекса может участвовать большое число специалистов различных направлений и квалификации, которых целесообразно объединять в единый коллектив службу «команду»
тестирования на соответствие требованиям и управления конфигурацией программного продукта. Организационная структура тестирования представляет наибольшее значение с точки зрения постоянного повышения зрелости процессов и возможностей тестирования и может включать следующие основные службы и группы.
Служба тестирования – поиск ошибок и недостатков программы, их описание и предоставление этой информации всем, кому она необходима. Решений относительно выпуска продукта руководитель службы тестирования не принимает, он только предоставляет руководству информацию о том, насколько продукт протестирован и каково его качество. В некоторых предприятиях основными тестировщиками считаются сами программисты, а служба тестирования им только помогает, она отвечает за техническую сторону этой работы: анализ объекта тестирования, проектирование и подготовку тестов, их выполнение и документирование. Все это требует определенной профессиональной квалификации.
Как известно, многим людям свойственно избегать ответственности и по возможности перекладывать ее на других. Именно поэтому руководители проекта часто пытаются переложить ответственность за качество продукта на службу тестирования. За качество продукта отвечает руководитель проекта. Служба тестирования только снабжает его технической информацией, сопровождая данные собственной интерпретацией. Все это вовсе не означает, что служба тестирования вообще ни за что не отвечает. Она отвечает за качественное тестирование, интерпретацию его результатов и их своевременное предоставление руководству, документирование своей работы. Участие службы тестирования в управлении проектом скорее косвенное, чем непосредственное. Ее сила заключается в собираемых данных и умении правильно их представить.
Служба поддержки разработки является расширением концепции службы тестирования. Обе они являются службами, а значит, предоставляют чисто технические услуги – это не административные, не контролирующие и, как правило, аполитичные группы. Они помогают улучшить продукт, созданный другими сотрудниками (программистами), используя для этого профессиональные навыки, которых у В.В. Липаев. Тестирование компонентов и комплексов программ программистов нет. Если служба тестирования только тестирует продукт, то у службы поддержки разработки есть и другие задачи. Ее сотрудники принимают в разработке гораздо большее участие, а значит, имеют и больше возможностей для профессионального роста. Основной задачей службы поддержки разработки остается тестирование, но в зависимости от нужд конкретного предприятия могут выполняться следующие задачи. Отладка, техническая поддержка пользователей, особенно после выпуска продукта, редактирование документов руководства пользователей, анализ эксплуатационных характеристик продукта, изучение откликов пользователей.
Группа обеспечения качества – она обеспечивает качество продукта. Для этого она участвует в разработке от первого до последнего дня, устанавливая стандарты, определяя процедуры контроля и обучая людей тому, как лучше проектировать и разрабатывать программные комплексы и компоненты. Таким образом, недостатки программ не просто устраняются, а предотвращаются. Чтобы справиться со своей задачей, группа обеспечения качества должна обладать большими полномочиями, а ее сотрудники – высочайшей квалификацией в целом ряде профессий. Они должны быть высококлассными программистами, техническими писателями, руководителями, проектировщиками и аналитиками. В любом предприятии должна быть группа, отвечающая за определение стандартов, обучение персонала, управление работой и повышение ее эффективности. Именно она обеспечивает качество выпускаемых продуктов. С политической точки зрения создание в компании отдельной группы обеспечения качества – это палка о двух концах. Ведь за качество продукта должен отвечать каждый, кто, так или иначе, участвует в разработке, и особенно руководство предприятия. Если же у людей появляется хоть малейшая возможность переложить эту ответственность на когото другого, они немедленно ею пользуются.
Группа контроля качества – это очень влиятельное подразделение. Инспектор группы контроля качества может задержать выпуск продукта до тех пор, пока не будут соблюдены все стандарты, процедуры тестирования и исправлены все ошибки. Руководство предприятия реагирует на такие события немедленно и может запросто отменить решение группы контроля качества и распорядиться выпускать продукт, каким бы ни было его качество. Группа тестирования помогает руководству предприятия, предоставляя информацию о текущих Лекция 1.1. Организация тестирования компонентов и комплексов прогр. проблемах разработки и степени их серьезности. Однако предоставление информации это одно, а принятие решений – совсем другое.
Здесь группа контроля качества обладает несколько более высокими полномочиями, чем обычная группа тестирования, поскольку может задержать выпуск продукта, не удовлетворяющего определенным требованиям.
При производстве сложных комплексов программ большими коллективами значительно повышается роль квалификации лидеров руководителей проекта, что непосредственно отражается на производительности и результатах труда всего коллектива. Известны случаи, когда вследствие квалификации руководителей сложных программных комплексов, суммарные затраты на разработку изменялись в несколько раз как в лучшую, так и в худшую сторону.
Некоторые методы учета характеристик лидеров, организации, структуры коллектива и процессов производства, позволяют сокращать негативное влияние человеческого фактора.
Во всякой иерархии каждый сотрудник имеет тенденцию достигать своего уровня некомпетентности. Если человек успешно справляется со своими обязанностями, его считают подходящей кандидатурой для повышения статуса. После ряда выдвижений он достигает уровня, где обнаруживается его некомпетентность, так как его новые обязанности оказываются ему не по силам. Больше его не повышают, но он остается на том месте, куда попал, хотя с обязанностями своими по-прежнему справиться не в состоянии. Каждая разновидность способностей по-своему вполне реальна, но трудно сравнима с компетентностью, предполагаемой у претендентов на руководящую должность. Этот процесс приводит к тому, что многие, особенно руководящие, должности заняты некомпетентными людьми, долго остающимися на своих постах. Целесообразно отказываться от всякого повышения в должности, пока специалист еще находится на уровне своей компетентности. Большинство повышений определяются компетентностью кандидата, обнаруженной им на низшей ступени деловой лестницы.
В.В. Липаев. Тестирование компонентов и комплексов программ Установление источников и типов дефектов и ошибок в компонентах и сложных комплексах программ Для эффективной организации процесса тестирования руководителям и специалистам полезно знать основные источники и типы дефектов и ошибок, которые допускаются на начальных этапах проектирования сложных комплексов программ и комментируются ниже. Понятие дефекта или ошибки в программе, в общем случае, подразумевает неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба – риска при функционировании и применении программного продукта. При этом должно быть известно или задано требование или правильное, эталонное состояние объекта или процесса, по отношению к которому может быть определено наличие отклонения – ошибка или дефект (см. лекцию 1.2). Исходным эталоном обычно является спецификация требований заказчика или потенциального пользователя, предъявляемая к программному компоненту или комплексу. Подобный документ устанавливает состав, содержание и значения результатов применения программы, которые должен получать тестировщик или пользователь при определенных условиях и исходных данных. Любое отклонение результатов функционирования программы от предъявляемых к ней требований и сформированных по ним эталонов-тестов, следует квалифицировать как ошибку – дефект в программе, наносящий некоторый ущерб при ее применении. Различие между ожидаемыми и полученными результатами функционирования комплекса программ могут быть следствием ошибок не только в созданных программах, но и ошибок в первичных требованиях спецификаций, явившихся базой при создании эталонов. Тем самым проявляется объективная реальность, заключающаяся в невозможности абсолютной корректности и полноты исходных требований и эталонов для программных компонентов и комплексов.
Источниками ошибок в комплексах программ являются специалисты – конкретные люди с их индивидуальными особенностями, квалификацией, талантом и опытом. При этом можно выделить предсказуемые дефекты требований, расширения или совершенствования компонентов и комплексов программ, и необходимые изменения, обусловливающие выявление случайных, непредсказуемых дефектов и ошибок. Вследствие этого плотность потоков и размеры необЛекция 1.1. Организация тестирования компонентов и комплексов прогр. ходимых корректировок в требованиях к комплексу и компонентам программ могут различаться в десятки раз. Однако в сложных комплексах программ статистика и распределение типов ошибок и выполняемых изменений для коллективов разных специалистов нивелируются и проявляются достаточно общие закономерности, которые могут использоваться как ориентиры при их выявлении. Каждому типу необходимых корректировок соответствует более или менее определенная категория специалистов, являющихся источником дефектов данного типа (таблица 1). Такую корреляцию целесообразно учитывать как общую качественную тенденцию при анализе и поиске их причин ошибок. Этому могут помогать оценки типовых дефектов и корректировок, путем их накопления и обобщения по опыту разработки определенных классов комплексов программ в конкретных предприятиях.
В процессе жизненного цикла комплекса программ его требования подвергаются декомпозиции на спецификации модулей, программных и информационных компонентов. Эти спецификации рассматриваются как частные эталоны для составных частей комплекса, однако они редко бывают абсолютно полными и корректными. В процессе декомпозиции и верификации исходных требований возможно появление ошибок в спецификациях на группы программ и на отдельные компоненты. Это способствует расширению спектра возможных дефектов и вызывает необходимость создания гаммы методов и средств тестирования для выявления некорректностей в спецификациях и компонентах разных уровней детализации комплексов программ.
Статистика ошибок и дефектов в компонентах и комплексах программ и их характеристики в конкретных типах проектов могут служить ориентирами для разработчиков при распределении ресурсов в жизненном цикле комплексов программ и предохранять их от излишнего оптимизма при оценке достигнутого качества программных комплексов. Характеристики дефектов и ошибок представлены в ряде монографий, посвященных тестированию и экономике производства комплексов программ. Эти публикации целесообразно изучать и использовать как ориентиры в реальных проектах (см. рис.
1.1).
В.В. Липаев. Тестирование компонентов и комплексов программ Лекция 1.1. Организация тестирования компонентов и комплексов прогр. Изучение и прогнозирование характеристик дефектов и ошибок в программах непосредственно связано с достигаемой корректностью, безопасностью и надежностью функционирования комплексов программ и помогает:
оценивать реальное состояние проекта и планировать необходимую трудоемкость и длительность для его завершения и устранения доступных ошибок;
выбирать методы и средства автоматизации тестирования компонентов комплекса программ, адекватные текущему состоянию производства, наиболее эффективные для устранения определенных видов дефектов;
рассчитывать необходимую эффективность контрмер и дополнительных средств оперативной защиты от потенциальных дефектов и не выявленных ошибок;
оценивать требующиеся ресурсы, с учетом затрат на реализацию контрмер при модификации программ для устранения дефектов и ошибок.
На практике исходные требования – эталоны поэтапно уточняются, модифицируются, расширяются и детализируются по согласованию между заказчиком и разработчиками. Базой таких уточнений являются неформализованные представления и знания специалистов-заказчиков и разработчиков, а также результаты промежуточных этапов проектирования и тестирования. Однако установить не корректность таких эталонов еще труднее, чем обнаружить дефекты в программах, так как принципиально отсутствуют точные, формализованные данные, которые можно использовать как исходные. В процессе декомпозиции и верификации исходной спецификации требований, возможно появление ошибок в спецификациях на компоненты программ и на отдельные модули. Это способствует расширению спектра возможных дефектов и вызывает необходимость создания гаммы методов и средств тестирования для выявления некорректностей в спецификациях на компоненты разных уровней.
Важной особенностью процесса выявления ошибок в программах обычно является отсутствие полностью определенной программы-эталона, которой должны соответствовать текст и результаты функционирования разрабатываемой программы. Поэтому установить наличие и локализовать дефект непосредственным сравнением с программой без ошибок в большинстве случаев невозможно. При В.В. Липаев. Тестирование компонентов и комплексов программ тестировании обычно сначала обнаруживаются вторичные ошибки и риски, т.е. последствия и результаты проявления некоторых внутренних дефектов или некорректностей программ (рис. 1.3).
Эти внутренние дефекты следует квалифицировать как первичные ошибки или причины обнаруженных аномалий результатов.
Последующая локализация и корректировка таких первичных ошибок должна приводить к устранению ошибок, первоначально обнаруживаемых в результатах функционирования программ.
Потери эффективности и риски программ за счет неполной корректности в первом приближении можно считать прямо пропорциональными (с коэффициентом) вторичным ошибкам в выходных результатах. Типичным является случай, когда одинаковые по величине и виду вторичные ошибки в различных результирующих данных существенно различаются по своему воздействию на общую эффективность и риски применения комплекса программ. Это влияние вторичЛекция 1.1. Организация тестирования компонентов и комплексов прогр. ных ошибок, в лучшем случае, можно оценивать методами экспертного анализа при условии предварительной, четкой классификации видов возможных первичных ошибок в программах и выходных величин. Таким образом, оценка последствий, отражающихся на вторичных ошибках и функционировании программ, может, в принципе, производиться по значениям ущерба – риска вследствие не устраненных их причин – первичных ошибок в программе. Вторичные ошибки являются определяющими для эффективности функционирования программ, однако не каждая первичная ошибка вносит заметный вклад в выходные результаты. Вследствие этого ряд первичных ошибок может оставаться не обнаруженным и, по существу, не влияет на функциональные характеристики компонента или комплекса программ.
Ошибкам в программах, естественно, соответствует их обнаружение и устранение на основе вторичных проявлений. Наибольшее число первичных ошибок вносится на этапах системного анализа, программирования, разработки или модификаций текстов программ.
При этом на долю системного анализа приходятся наиболее сложные для обнаружения и устранения дефекты. Общие тенденции состоят в быстром росте затрат на выполнение каждого устранения ошибки на последовательных этапах процессов разработки компонентов и комплекса программ. При системном анализе интенсивность обнаружения ошибок относительно не велика и ее трудно выделить из процесса проектирования компонента или комплекса программ. Интенсивность проявления и обнаружения вторичных ошибок наиболее велика на этапе активного тестирования и автономной отладки программных компонентов. Затем она снижается приблизительно экспоненциально.
Различия интенсивностей устранения первичных ошибок на основе их вторичных проявлений и внесения первичных ошибок при корректировках программ определяют скорость достижения заданного качества компонентов и комплексов программ.
Первичные ошибки в программах можно анализировать с разной степенью детализации и в зависимости от различных факторов.
Практический опыт показал, что наиболее существенными факторами, влияющими на характеристики обнаруживаемых ошибок, являются:
В.В. Липаев. Тестирование компонентов и комплексов программ методология, технология и уровень автоматизации системного и структурного проектирования компонентов и комплекса программ, а также непосредственного программирования компонентов;
длительность с начала процесса тестирования компонентов и комплекса и текущий этап разработки или сопровождения комплекса программ;
класс комплекса программ, масштаб (размер) и типы компонентов, в которых обнаруживаются ошибки;
методы, виды и уровень автоматизации верификации и тестирования, их адекватность характеристикам компонентов и потенциально возможным в программах ошибкам;
виды и достоверность эталонов-тестов, которые используются для обнаружения ошибок.
Одной из основных причин ошибок в сложных комплексах программ являются организационные дефекты требований и эталонов к программному продукту, которые отличаются от остальных типов и могут быть выделены как самостоятельные. Ошибки и дефекты данного типа появляются из-за недостаточного понимания руководителями и коллективом специалистов целей и функций комплекса программ, а также вследствие отсутствия четкой его организации и поэтапного контроля требований качества компонентов и продуктов.
Это порождается пренебрежением руководителей к организации всего технологического процесса формализации требований сложных программных продуктов и приводит к серьезной недооценке их дефектов, а также трудоемкости и сложности их выявления. При отсутствии планомерной и методичной разработки и тестирования требований и эталонов может оставаться не выявленным значительное количество ошибок и, прежде всего, дефекты требований к взаимодействию отдельных функциональных компонентов между собой и с внешней средой. Для сокращения этого типа массовых ошибок активную роль должны играть лидеры – менеджеры и аналитикисистемотехники, способные вести контроль и конфигурационное управление требованиями, изменениями и развитием версий и компонентов комплексов программ.
Системные ошибки и недостатки определения требований к программному продукту характеризуются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. Кроме того, эти процессы зачастую завиЛекция 1.1. Организация тестирования компонентов и комплексов прогр. сят от самих алгоритмов и поэтому не могут быть достаточно определены и описаны заранее без исследования функционирования комплекса программ во взаимодействии с внешней средой. На начальных этапах разработки не всегда удается точно и полно сформулировать целевую задачу всей системы, а также целевые задачи основных функциональных групп программ, и эти задачи уточняются в процессе проектирования. В соответствии с этим уточняются и конкретизируются спецификации на функциональные компоненты и выявляются отклонения от уточненного задания требований, которые могут квалифицироваться как системные ошибки.
Во многих случаях отсутствует полная адекватность условий получения предполагаемых и реальных характеристик внешней среды, что может являться причиной сложных и трудно обнаруживаемых ошибок. Это усугубляется тем, что часто невозможно заранее предусмотреть все разнообразие возможных внешних условий и реальных вариантов сценариев функционирования и применения версий программных продуктов. При автономной и в начале комплексной отладки версий компонентов относительная доля системных ошибок может быть невелика (около 10%), но она существенно возрастает (до 35 – 40%) на завершающих этапах комплексной отладки новых версий программного продукта. В процессе сопровождения системные ошибки обычно являются преобладающими (около 60 – 80% от всех ошибок).
Ошибки определения характеристик системы и внешней среды, принятых в процессе разработки комплекса программ за исходные, могут быть результатом аналитических расчетов, моделирования или исследования аналогичных систем. В ряде случаев может отсутствовать полная адекватность предполагаемых и реальных характеристик, что является причиной сложных и трудно обнаруживаемых системных ошибок и дефектов развития проекта. Ситуация с такими ошибками дополнительно усложняется тем, что эксперименты по проверке взаимодействия программного продукта с реальной внешней средой во всей области изменения характеристик зачастую сложны и дороги, а в отдельных случаях, при создании опасных ситуаций, недопустимы. В этих случаях приходится использовать моделирование и имитацию внешней среды с заведомым упрощением ее отдельных элементов и характеристик, хотя степень упрощения не всегда можно оценить с необходимой точностью. Однако В.В. Липаев. Тестирование компонентов и комплексов программ полной адекватности моделей внешней среды и реальной системы добиться трудно, а во многих случаях и невозможно, что может являться причиной значительного числа дефектов.
Дефекты и ошибки программных комплексов, которые проявляются как риски – прямой ущерб при применении системы. Основными источниками рисковых ситуаций могут быть некорректные исходные требования, дефекты или ошибки в программах и данных функциональных задач, проявляющиеся при их исполнении в соответствии с назначением. При таких воздействиях функциональная работоспособность систем может разрушаться не полностью, однако невозможно полноценное выполнение заданных функций и требований к качеству информации для потребителей. Риски могут быть обусловлены нарушениями и дефектами технологий или ограничениями при использовании ресурсов – бюджета, планов, коллектива специалистов, инструментальных средств, выделенных на разработку компонентов и комплекса программ. Результирующий ущерб в совокупности зависит от величины и вероятности проявления каждого дефекта и негативного воздействия. Одним из косвенных методов определения величины риска может быть оценка совокупных затрат, необходимых для ликвидации негативных последствий дефектов и ошибок в программах, системе или внешней среде, проявившихся в виде конкретного рискового события. В жизненном цикле программных комплексов ущерб – риски могут проявляться вследствие:
искажений, дефектов или ошибок не полной реализации требуемого назначения, функций или взаимодействия комплекса программ с компонентами системы или внешней среды – недостатков и дефектов функциональной пригодности комплексов программ;
недостаточных и не соответствующих требованиям конструктивных характеристик качества компонентов и комплекса программ при его функционировании и применении по прямому назначению;
ошибок и нарушений ограничений на использование экономических, временных или технических ресурсов при создании и применении компонентов и комплексов программ.
В зависимости от сложности проекта окончательным результатом работ при проектировании должны быть детализированные и утвержденные требования к номенклатуре, свойствам и значениям качества и допустимым рискам программного продукта, которые Лекция 1.1. Организация тестирования компонентов и комплексов прогр. достаточны для его полноценного рабочего проектирования, производства и последующей эффективной эксплуатации. На этапах жизненного цикла и при конфигурационном управлении требования могут изменяться по согласованию между заказчиком и разработчиком, которые чаще всего приурочиваются к подготовке новой версии. Для этого необходим мониторинг масштаба проекта, требований и реализаций характеристик и допустимых рисков. После определения назначения и функций комплекса программ подготовка исходных данных и концепции проекта должны завершаться выделением номенклатуры конструктивных характеристик, имеющих достаточно сильное влияние на функциональную пригодность и сокращающих риски до допустимых значений.
Принципиальные и технические возможности, точность реализации свойств и измерения значений характеристик комплекса, а также общие ресурсы конкретного проекта всегда ограничены в соответствии с их содержанием и возможностями заказчика и разработчиков.
Это определяет рациональные диапазоны значений каждого типа допустимого риска, которые могут быть выбраны на основе требований заказчика, здравого смысла, а также путем анализа пилотных проектов и прецедентов в спецификациях требований реализованных проектов. В результате формируется полный набор требуемых функциональных и конструктивных характеристик, свойств и допустимых рисков комплекса программ.
Ошибки комплексов программ по сложности обнаружения и масштабу корректировок можно разделить на следующие группы:
ошибки, обусловленные сложностью компонентов и комплекса в целом, наиболее сильно влияющие на размеры модификаций;
ошибки вследствие большого масштаба – размера комплекса программ, а также высоких требований к его качеству;
ошибки планирования и корректности требований модификаций часто могут быть наиболее критичными для общего успеха комплекса программ и системы;
ошибки проектирования, разработки структуры и функций комплекса программ в более полные и точные технические описания сценариев того, как комплекс - система будут функционировать.
Сложность обнаружения и устранения ошибок значительно конкретизируются и становятся измеримой, когда устанавливается В.В. Липаев. Тестирование компонентов и комплексов программ связь этого понятия с конкретными ресурсами, необходимыми для решения соответствующей задачи и возможными проявлениями дефектов. При разработке и сопровождении программ основным лимитирующим ресурсом обычно являются допустимые трудозатраты специалистов, а также ограничения на сроки разработки, технологию проектирования корректировок комплекса. Показатели сложности при анализе можно разделить на две большие группы:
сложность ошибок при создании корректировок компонентов и комплекса программ статическая сложность, когда реализуются его требуемые функции, вносятся основные дефекты и ошибки;
сложность проявления ошибок функционирования и получения результатов программных компонентов и комплекса динамическая сложность, когда проявляются дефекты и ошибки, отражающиеся на функциональном назначении, рисках и качестве применения комплекса программ.
К группе факторов, влияющих на сложность ошибок комплексов программ, относятся:
величина – размер создаваемой или модифицируемой программы, выраженная числом строк текста, функциональных точек или количеством программных модулей и компонентов в комплексе;
количество обрабатываемых переменных или размер и структура памяти, используемой для размещения базы данных корректировок;
трудоемкость разработки изменений компонентов и комплекса программ;
длительность разработки и реализации корректировок;
число специалистов, участвующих в производстве компонентов и комплекса программ.
Некоторые из перечисленных параметров коррелированны между собой, причем, определяющими часто являются размер изменений программы и объем базы данных. Остальные характеристики можно рассматривать как вторичные, однако они могут представлять самостоятельный интерес при анализе сложности и прогнозировании вероятного числа дефектов в измененной программе.
Масштаб – размер комплексов программ и их изменяемой Лекция 1.1. Организация тестирования компонентов и комплексов прогр. части наиболее сильно влияет на количество ошибок, а также на требования к качеству. По мере увеличения размера и повышения требований к качеству комплекса программ и его корректировкам затраты на обнаружение и устранение ошибок увеличиваются все более высокими темпами. Одновременно расширяется диапазон неопределенности достигаемого качества. В зоне высокого качества программ возрастают трудности измерения этих характеристик, что может приводить к необходимости изменения затрат в несколько раз в зависимости от применяемых методов и результатов оценки качества компонентов и комплекса программ. Вследствие этого в сложных комплексах всегда велика вероятность проявления не устраненных ошибок и недостаточная достоверность оценок достигнутого качества.
Ошибки проектирования и разработки архитектуры программного комплекса определяются процессами перевода неопределенных и общих положений, сделанных на этапе первичных спецификаций требований, в более точные технические описания сценариев того, как программный продукт и система должны работать.
Ошибки структуры инспекциями легче обнаружить, чем ошибки требований, но они в конечном итоге могут оказаться при корректировках такими же дорогостоящими. Главная причина того, что ошибки структуры дорого исправлять, состоит в том, что они могут влиять на систему в целом. Если разработчик структуры либо неверно прочитает требования, либо не увидит содержание требования так же, как заказчик или конечный пользователь, появится ошибка разработки структуры данного компонента или комплекса программ.
Системные ошибки корректности выполнения требований к программным компонентам считаются наиболее критичными для общего успеха его версий и системы в целом. Ошибки требований являются наиболее трудными для обнаружения и наиболее сложными для исправления. Вот почему исправление ошибок выполнения требований может быть в десятки раз дороже, чем ошибок программирования. Требование может быть пропущено в спецификации к системе, комплексу и компонентам программ. Это ведет к неудовлетворенности пользователя, и комплекс программ считается заказчиком и пользователем дефектным. Пропуск части требований – наиболее обычная проблема среди ошибок требований. Ошибки требований могут также представлять собой конфликтующие требования в спецификации. Может проявляться неопределенность требований – В.В. Липаев. Тестирование компонентов и комплексов программ такой способ формулирования требования, что даже если и не конфликтует с другим требованием, оно выражено недостаточно ясно, чтобы привести к единственному, конструктивному решению при разработке комплекса программ. Конечный пользователь часто называет это ошибкой, хотя на самом деле это выбор конструктивного решения на основе неполного или неопределенного требования. Многочисленные исследования показали, что ошибки требований труднее всего обнаруживать и дороже всего исправлять.
Ошибки проектирования и разработки модулей и компонентов комплекса программ определяются процессами перевода зачастую неопределенных и общих положений, сделанных на стадии спецификаций требований, в более точные технические описания сценариев того, как компоненты программы должны работать, к ним относятся:
системные ошибки в модулях и компонентах программ;
алгоритмические ошибки модулей и программных компонентов;
ошибки реализации спецификаций модулей и компонентов;
программные ошибки модулей и компонентов комплекса программ;
ошибки в эксплуатационной и технологической документации модулей, компонентов и комплекса программ.
Убывание ошибок в компонентах и комплексе программ и интенсивности их обнаружения в процессе разработки не беспредельно.
После тестирования и отладки в течение некоторого времени интенсивность обнаружения дефектов при самых жестких внешних условиях испытаний снижается настолько, что коллектив, ведущий разработку и тестирование, попадает в зону нечувствительности к ошибкам и возможным отказам функционирования. При такой интенсивности отказов вследствие их редкого проявления трудно прогнозировать затраты времени, необходимые для обнаружения очередной ошибки. Создается представление о полном отсутствии случайных проявлений дефектов, о невозможности и бесцельности их поиска, поэтому усилия на тестирование сокращаются, и интенсивность обнаружения ошибок еще больше снижается. Этой предельной интенсивности обнаружения отказов соответствует наработка на обнаруженную ошибку, при которой прекращается улучшение характеристик программного комплекса на этапах отладки или испытаний.
Лекция 1.1. Организация тестирования компонентов и комплексов прогр. При серийном выпуске программного продукта, благодаря значительному расширению вариантов исходных данных и условий эксплуатации, возможно в течение некоторого времени возрастание суммарной (по всем экземплярам системы) интенсивности обнаружения дефектов и ошибок. Это позволяет дополнительно устранять ряд дефектов и тем самым увеличивать длительность между проявлениями ошибок в процессе эксплуатации. Для оценки этих показателей качества необходимы объективные данные о динамике выявления ошибок, а также об усилиях, затрачиваемых на их обнаружение и устранение с учетом объема, тиража и других параметров создаваемого программного продукта.
В.В. Липаев. Тестирование компонентов и комплексов программ
ЭТАЛОНЫ И ТРЕБОВАНИЯ
ПРИ ПРОЕКТИРОВАНИИ И ПРОИЗВОДСТВЕ
КОМПЛЕКСОВ И КОМПОНЕНТОВ ПРОГРАММ
Системные основы разработки требований к сложным комплексам программ Специалисты по созданию программного продукта должны понимать функции, задачи и методы создания сложных систем, поскольку возникающие проблемы часто являются результатом решений, принятых руководителями и разработчиками проекта всей системы. Технологии программной инженерии часто являются критическим фактором при разработке сложных вычислительных систем. В этом состоит сложность прогнозирования и оценки их свойств, поскольку иногда можно измерить характеристики только подсистем, из которых состоит комплексная система. Высокие темпы роста основных ресурсов аппаратных средств (приблизительно на порядок каждые пять лет) и сохраняющаяся потребность в увеличении их использования со стороны различных пользователей и сфер применения приводят к необходимости адекватного совершенствования технологий создания сложных комплексов программ.Основы процессов, составляющих жизненной цикл сложных технических систем, создаваемых и применяемых человеком, отражает стандарт ISO 15288:2002 (см. Приложение 1). Процессы в данном стандарте образуют полное множество, из которого предприятия могут конструировать модели систем, соответствующие их продукции.
Стандарт может быть использован для выбора, структуризации и применения установленной среды в интересах производства продукции при оценке проекта на соответствие заявленной и сформированной внешней среде. Этот стандарт устанавливает основы для описания требований к функциям, процессам и свойствам жизненного цикла сложных систем, определяет множество детально определенных процессов, требований и соответствующей терминологии. ВыбранЛекция 1.2. Эталоны и требования при проектировании и производстве… ные из них множества процессов могут быть использованы для управления и осуществления жизненного цикла систем. Стандарт относится к искусственным техническим системам, которые созданы или разрабатываются человеком и состоят из следующих компонентов: аппаратное обеспечение, программные продукты, люди, процессы, процедуры, внешняя среда и природные ресурсы. Основные положения стандарта целесообразно учитывать при формировании функциональных требований к комплексам программ, используемым в системах – рис. 1.4.
Требования к системе должны определять совокупность работ, которая позволяет в рамках предприятия и/или проекта оптимизировать прибыль и уменьшать риски, возникающие вследствие принятия проектных решений и осуществления соответствующих действий.
Эти работы обеспечивают условия для того, чтобы продукция была нужной и полезной, экономически выгодной, функциональной, надежной, пригодной к обслуживанию, производству и использованию, и обладала другими качествами, необходимыми для того, чтобы удовлетворить требования как заказчика, так и пользователя. Они также обеспечивают условия для того, чтобы продукция соответствовала ожиданиям или законным требованиям общества, включая общие факторы обеспечения здоровья, безопасности, надежности и экологии.
«