Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

364 Глава 7

Задача 9.2. Подготовка решений и рекомендаций по результатам тести-

рования.

Сформулировать рекомендации, касающиеся продукта и процесса тестирования, и

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

и ресурсы, требуемые для их осуществления.

Задача 9.3. Подготовка итогового отчета о результатах тестирования.

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

готовит итоговый отчет, отражающий степень достижения целей тестирования и включаю-

щий рекомендации, основанные на анализе результатов тестирования. Стандарты ДСТУ

требуют также подготовки протокола испытаний [53].

Этот отчет должен давать характеристику всех выполненных действий по тестирова-

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

Структура итогового отчета, рекомендуемая в [11], приведена ниже.

Идентификатор отчета

Введение

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

функционального и системного тестирования, ссылки на план (планы) тестирования, проек-

ты тестов, описания наборов тестов и процедур, сценарии тестирования, журналы тестиро-

вания, отчеты о проблемах. Перечисляют протестированные объекты (компоненты систе-

мы, процедуры). Описывают программно-аппаратную среду, в которой проводилось тести-

рование.

Отклонения от планов тестирования

Указывают любые отмеченные отклонения от планов и их причины, не выполненные

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

Оценка адекватности тестирования

Указывают степень соответствия процесса тестирования критериям, установленным в

планах тестирования. Отмечают любые характеристики и их комбинации, которые были

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

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

Подводят общий итог тестирования. Указывают все устраненные дефекты. Перечисляют

все не устраненные дефекты.

Оценивание

Дают общую оценку каждого протестированного объекта. Эта оценка должна основы-

ваться на результатах тестирования и критериях прохождения (не прохождения) тестов ка-

ждым объектом.

Заключение

Обобщают данные об использовании ресурсов, например, количество тестировщиков,

стоимость и продолжительность тестирования (включая время на планирование и разработ-

ку тестов), использованное машинное время.

Указывают рекомендации, сделанные по результатам тестирования, и ожидаемые пре-

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

Утверждения

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

резервируют место для их подписей и дат утверждения.

Задача 9.4. Проверка решений и отчета.

Выполняется в форме совместного просмотра отчета группой тестирования, разра-

ботки и представителями заказчика (при необходимости).

Примечание. Задачи проведения приемочных испытаний выполняются аналогично

задачам шагов 8-9 (согласно планам), но в реальной среде эксплуатации и с участием заказ-

чика (пользователя).

Глава 7 365

7.6. Методы анализа риска отказа программной системы

Для идентификации и оценки рисков отказов ПС и ее компонентов применя-

ются формальные и неформальные методы анализа. Выбор того или иного метода

определяется критичностью ПС относительно серьезности последствий отказов.

Наиболее известные формальные методы анализа риска отказа – анализ дере-

ва событий (ETA - Event Tree analysis), анализ дерева отказов (FTA - Fault Tree

analysis), анализ режимов и последствий отказов (FMEA - failure modes and effects

analysis) [54].

Все три метода широко применяются в мировой практике в качестве инстру-

ментов анализа сложных технических и программно-технических систем (особен-

но, критических по безопасности) на стадиях анализа требований, проектирования

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

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

В последнее время появились аналоги этих методов, специально предназна-

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

SFTA (software fault tree analysis), а аналог FMEA - SFMEA (software failure modes

and effects analysis).

Основные методы и их аналоги для ПО могут применяться совместно для

анализа отказов на уровне системы [40], поскольку многие отказы бывают вызваны

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

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

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

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

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

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

(а также для программных компонентов и отдельных модулей).

7.6.1. Анализ дерева событий

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

сценариев использования системы, которые могут привести к ее отказам. В нем ис-

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

и их последствий.

Дерево событий представляет логическую схему системы, которая определя-

ет при заданном исходном событии (корень дерева) множество возможных элемен-

тарных конечных событий (последствий), каждое из которых является реализацией

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

- успешное или неуспешное выполнение действий;

- работоспособные состояния или отказы компонентов системы;

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

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

и системные деревья событий.

В функциональных деревьях промежуточные события - это успешное или не

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

выявления возможных сценариев использования системы и выделения из них сце-

нариев, при которых возможны отказы в выполнении функций.

366 Глава 7

В системных деревьях промежуточные события – это успешные действия

или отказы системы и ее компонентов (а также ошибки пользователей, которые мо-

гут привести к отказам). Разработка этих деревьев проводится с целью детализации

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

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

Затем, для каждого сценария возникновения отказа могут разрабатываться

деревья отказов и ошибок пользователей (методами FTA и SFTA).

Порядок применения метода можно представить в виде последовательности

следующих шагов:

Шаг 1. Определить границы анализируемой системы и границы анализа. Рас-

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

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

системами, требования к надежности и производительности.

Шаг 2. Идентифицировать возможные начальные события. Выполнить

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

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

мы или некоторое внешнее событие (например, ошибочные действия пользователя,

неправильные входные данные).

Шаг 3. Идентифицировать возможные последствия. Для каждого начально-

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

ность событий и последствий в виде дерева событий. Над деревом перечисляются

события (начальное и промежуточные). Дерево событий представляет собой би-

нарный граф, вершина которого (корень дерева) – начальное событие. Две дуги,

исходящие из корня дерева – представляют два возможных исхода события (успех

или неуспех). Процедура повторяется до тех пор, пока не будет «достигнуто» эле-

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

лизируется. Общая структура дерева представлена на рисунке 7.19.

Начальное

событие

Успех

1- P2

Отказ

Успех

1- P3

Отказ

Успех

1- P4

Успех

Отказ

1- P4

Успех

1-P5

Отказ

P1*P5

P1*P4

P1*P2

P1*P3*P4

P1*P3

Pi - вероятности событий

События

Нач.

событие

Промежуточные события

2 3 4 5

Рис. 7.19. Общий вид дерева событий

Глава 7 367

Шаг 4. Определить сценарии возникновения отказов (отрицательных собы-

тий). Для каждого начального события определить сценарии (цепочки распростра-

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

ве: от начального до конечного элементарного события).

Шаг 5. Проанализировать сценарии отказов. Для каждого конечного эле-

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

с ним связаны. Назначить вероятности последствий событий (Pi) исходя из часто-

ты. Для этого, возвращаясь от листьев дерева к его корню, вычислить вероятности

каждого последствия события.

Шаг 6. Оценить потери из-за отказов.

Серьезность последствий отказов рассматривается в контексте ожидаемых

потерь из-за отказов системы при ее эксплуатации.

Шаг 7. Принять решение о том, как снизить возможные потери в резуль-

тате цепи отказов. Оценить ожидаемый эффект (пользу) направленного или до-

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

ским показателем - величиной снижения финансовых потерь заказчика.

7.6.2. Анализ дерева отказов

Метод анализа дерева отказов был разработан в начале 60-х годов, на протя-

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

одним из основных методов анализа надежности и безопасности сложных и крити-

ческих систем.

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

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

Дерево отказов строится для каждого возможного отказа (или наиболее серь-

езных отказов). Начиная с исходного анализируемого события отказа (вершины

дерева), то есть отказа системы или ее компонента (по существу, конечного собы-

тия), для каждого рассматриваемого события выявляются события-предше-

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

ние дерева заканчивается выявлением элементарных событий, которые далее не

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

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

мах или компонентах, и не могут быть промоделированы экспериментально. Гра-

фически дерево отказов изображается в форме графа (рисунок 7.20).

Примерами исходных событий для ПО могут быть: потеря данных и наруше-

ние их целостности, отказы при выполнении компонентов (функциональные отка-

зы), несанкционированный доступ к системе и данным и другое.

Примерами элементарных событий могут быть: аппаратные сбои, ошибки во

входных данных, ошибки в программных модулях.

Порядок применения метода можно представить в виде последовательности

следующих шагов.

Шаг 1. Определение границ анализируемой системы и уровня вложенности,

до которого отказы будут рассматриваться. Это делается для упрощения струк-

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

компонентов).

368 Глава 7

Начальное

событие

Событие 1.1 Событие NСобытие 2

...

Событие N.1 Событие N2

Событие 1.2

Обозначения

анализируемое событие (всегда требующее дальнейшего анализа)

элементарное событие (далее не анализируются)

cвязь "

ИЛИ

Рис. 7.20. Общий вид дерева отказов

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

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

ревьев событий. Из всех возможных отказов выбираются наиболее важные, для ка-

ждого из которых будет строиться дерево отказов.

Шаг 3. Построение дерева отказов. Изначально предполагается, что иден-

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

выявления возможных причин его возникновения. Это делается с помощью обра-

зования ветвей дерева, корень которого – отказ. Дерево строится вплоть до элемен-

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

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

основные из которых изображены на рисунке 7.20. Для более сложных деревьев

применяются дополнительные графические символы [40].

Шаг 4. Выявление непосредственных причин возможных событий в системе.

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

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

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

представляющих возможные причины отказа (и компоненты, отказ которых может

произойти). Процесс определения причин продолжается до тех пор, пока все при-

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

Шаг 5. Для каждого события идентифицировать все непересекающиеся

причины и определить минимальное их количество. Выполняется путем качествен-

ного (визуального) анализа дерева отказов.

Шаг 6. Назначить вероятностное распределение элементарных событий

(причин). Количественный анализ основан на вычислении условной вероятности

Глава 7 369

возникновения отказа (начального события) при известных вероятностях элемен-

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

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

ных, частота или интенсивность возникновения элементарных событий.

Шаг 7. Вычисление условной вероятности отказа. Выполняется по правилам

Булевской алгебры (сложения и умножения элементарных событий).

7.6.3. Анализ причин и последствий отказов

Метод анализа режимов и последствий отказов (FMEA – failure mode and ef-

fect analysis) и его расширение для ПО (SFMEA – software failure mode and effect

analysis) - табличные методы, которые применяются в качестве вспомогательных

для анализа и прогнозирования надежности технических и программно-

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

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

меняются для идентификации типов возможных отказов и механизмов их появле-

ния (режимов) в отдельных компонентах системы. Используют индуктивный ана-

лиз с целью определения условия возникновения отказов в компоненте (модуле) и

последствий этих отказов для всей системы [54].

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

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

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

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

или другие способы предотвращения отказа и контроля условий его появления (ри-

сунок 7.21).

Компонент Режим отказа

и причина

Последствия Серьезность Меры пре-

дотвращения

Рис. 7.21. Структура таблицы отказов

7.7. Инструменты тестирования

При современных темпах роста сложности ПС, их тестирование должно под-

держиваться автоматизированными инструментами. В последнее десятилетие ры-

нок инструментов тестирования бурно развивается. На смену анализаторам кода и

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

работающим на определенных программных и аппаратных платформах, а также

инструментам, поддерживающим отдельные методы тестирования, приходят про-

мышленные интегрированные инструменты поддержки разных методов тестирова-

ния, работающие практически на всех аппаратных и программных платформах.

7.7.1. Классификация инструментов тестирования

Единых подходов к классификации инструментов тестирования нет, посколь-

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

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

[55], представлена на рисунке 7.22 и кратко описана ниже.

370 Глава 7

Инструменты управления тестированием

Менеджеры конфигурации

Менеджеры проекта

Инструменты, поддерживающие анализ требований и проекта

Анализаторы планов, требований и проектов

Построители прототипов/эмуляторы системы

Инструменты трассировки требований

Планировщики тестов

Инструменты поддержки тестирования на этапе реализации и сопровождения

Статические анализаторы исходного кода:

Аудиторы

Измерители сложности

Инструменты генерации перекрестных ссылок

Измерители размера

Инструменты подготовки тестов:

Экстракторы данных

Генераторы тестов по спецификации требований

Генераторы тестовых данных (по разным методам)

Планировщики тестов

Инструменты выполнения тестов:

Динамические анализаторы покрытия

Инструменты Захвата/Проигрывания

Отладчики

Эмуляторы

Анализаторы сети

Анализаторы производительности

Анализаторы ошибок периода выполнения

Инструменты управления выполнением тестов

Тестовые оценщики

Компараторы (утилиты сравнения файлов)

Конверторы и анализаторы данных

Трассировщики дефектов/изменений

Рис.7.22. Виды инструментов тестирования

Инструменты управления тестированием

Менеджеры конфигурации – отслеживают и контролируют внесение измене-

ний в ПС на протяжении ее разработки и сопровождения и поддерживают целост-

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

рактеристики этого типа инструментов: отслеживание дефектов; управление запро-

сами на внесение изменений, отслеживание изменений в коде.

Менеджеры проекта - поддерживают функции планирования и отслежива-

ния на этапах разработки и сопровождения системы (оценивание сроков, ресурсов,

построение сетевых графиков и др.). Инструменты данного типа можно применять

и для поддержки планирования и отслеживания процесса тестирования, например,

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

Инструменты, поддерживающие анализ требований и проекта

Анализаторы планов, требований и проектов - оценивают спецификации на

полноту, непротиворечивость и соответствие установленным стандартам для спе-

цификаций.

Глава 7 371

Построители прототипов/эмуляторы системы – объединяют действия по

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

промоделировать требования и проектные решения.

Инструменты трассировки требований – позволяют установить связи тре-

бований с проектом, кодом и тестами.

Планировщики тестов – поддерживают процесс планирования тестирования

на всех его уровнях.

Инструменты поддержки тестирования на этапе реализации и сопро-

вождения

Статические анализаторы исходного кода. Исследуют исходный код без его

реального выполнения. Могут применяться в качестве вспомогательных инстру-

ментов при планировании и тестировании, но в большей степени – это инструмен-

ты измерения и оценивания качества кода.

Аудиторы – анализируют код на соответствие стандартам кодирования и ус-

тановленным правилам.

Измерители сложности – вычисляют метрики кода для определения атрибу-

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

операнды/операторы, данные, структура системы.

Инструменты генерации перекрестных ссылок – обеспечивают ссылки меж-

ду разными сущностями (переменными).

Измерители размера - вычисляют число строк исходного кода (SLOC).

Инструменты подготовки тестов. Включают группу инструментов, под-

держивающих подготовку тестовых данных или разработку тестов.

Экстракторы данных – строят тесты, извлекая информацию из существую-

щих баз данных или тестовых наборов.

Генераторы тестов по спецификации требований – строят тесты по требо-

ваниям, написанным на формальном языке спецификации.

Генераторы тестовых данных (по разным методам) – генерируют входные

данные для тестирования в соответствии с методом, реализованным в инструменте.

Некоторые генераторы создают данные с использованием датчиков случайных чи-

сел (для статистического тестирования).

Планировщики тестов – поддерживают разработку и ведение планов тести-

рования.

Инструменты выполнения тестов. Наиболее представительная группа инст-

рументов.

Динамические анализаторы покрытия – оценивают покрытие кода тестами

по отношению к операторам, путям или модулям. Основаны на встраивании в код

специальных операторов для отслеживания путей выполнения.

Инструменты Захвата/Проигрывания - автоматически записывают действия

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

дуры (скрипта захвата) и затем воспроизводят (проигрывают) эти скрипты.

Отладчики – непосредственно поддерживают автономное тестирование, хотя

их назначение – поиск и устранение ошибок (отладка). Некоторые отладчики име-

ют возможности анализа покрытия.

Эмуляторы – могут применяться вместо отсутствующих компонентов систе-

мы (обычно аппаратных, например эмуляторы терминалов).

372 Глава 7

Анализаторы сети – специальный класс инструментов тестирования, предна-

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

миналов.

Анализаторы производительности – отслеживают временные характеристи-

ки системы или ее компонентов.

Анализаторы ошибок периода выполнения – отслеживают работу программы

на наличие ошибок, связанных с заказом-освобождением памяти, нулевыми указа-

телями и т.п. Автоматически отслеживают использование стеков и очередей.

Инструменты управления выполнением тестов – общее наименование кате-

гории инструментов, которые автоматизируют разные функции настройки и вы-

полнения тестов, очистки системы после выполнения тестов. К этой категории от-

носят также тестовые драйверы и заглушки.

Тестовые оценщики. К этому классу относят инструменты, выполняющие

функции выявления подверженных ошибкам компонентов.

Компараторы (утилиты сравнения файлов) – сравнивают результаты тести-

рования и выявляют отклонения (например, сравнивают битовые образы экранов,

файлы). Инструменты Захвата/Проигрывания обычно имеют в своем составе такие

компоненты.

Конверторы и анализаторы данных – конвертируют данные в удобный для

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

данных.

Трассировщики дефектов/изменений – хранят информацию о дефектах и ге-

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

инструментов управления тестированием.

7.7.2. Выбор инструментов тестирования

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

зависит в первую очередь от их доступности, а также типа ПС и методологии раз-

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

представлен на рисунке 7.23.

Описывают

спецификации в

графическом или

текстовом виде и

генерируют тесты

Выполняют тесты и

процедуры ,

фиксируют отказы

Проверяют

ПО, тесты

и тестовые

процедуры

Генераторы тестовых данных по

спецификациям требований

Инструменты

выполнения тестов

Инструменты оценки

тестирования

Рис.7.23. Набор инструментов для поддержки выполнения тестирования

В работе [56] приведены общие требования к набору инструментов, необхо-

димых для тестирования клиент-серверных систем. Инструменты должны:

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

ских интерфейсов пользователя);

- обеспечивать управление тестированием;

Глава 7 373

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

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

- работать на всех требуемых платформах;

- поддерживать внешние языки (например, Visual Basic);

- поддерживать несколько методов тестирования;

- иметь систему контекстной помощи, удобную и полную документацию.

Литература к главе 7

1. IEEE Std. 610.12:1990. IEEE Standard Glossary of Software Engineering Terminology.

2. Майерс Г. Искусство тестирования программ.-M: Финансы и статистика, 1982. –196 с.

3. ДСТУ 2844-94. Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення.

4. ДСТУ 2853-94. Програмні засоби ЕОМ. Підготовлення і проведення випробувань.

5. Gelperin D., Hetzel B. The Growth of Software Testing // Commun. ACM, 1988.-V. 31.- №

6.- P. 687-695.

6. ISO/IEC 12207:1995. Information technologies. Software life cycle processes. – 61p.

7. Software Engineering Body of Knowledge (SWEBOK). // ISO/IEC JTC1/SC7 N2517, Soft-

ware & System Engineering Secretariat, Canada, 2004. – 202 p.

8. Тестирование программного обеспечения: Пер с англ. / Канер С., Фолк Д., Нгуен Е. // -

К. Издательство «DiaSoft», 2000. – 544 с.

9. Zhu H., May J.H.R. Software Unit Test Coverage and Adequacy // ACM Computing Sur-

veys.- 1997.- V. 29.- Dec.- P. 366-427.

10. Perry W. Effective Methods for Software Testing, John Wiley & Sons.- 1995.

11. IEEE Std 829:1998. Standard for Software Test Documentation. - 52 p.

12. IEEE Std. 1012:1998. IEEE Standard for Software Verification and Validation.

13. ДСТУ 2941-94. Розроблення систем. Терміни та визначення.

14. ANSI/IEEE Std. 1008:1987. IEEE Standard for Software Unit Testing. – 31p.

15. Developing a Testing Maturity Model: Part I. / Burnstein, I., T. Suwannasart and C. R. Carl-

son // Crosstalk, STSC.- 1996.- August.- P. 21-24.

16. ISO/IEC 13407:1999. Human-centred Design Processes for Interactive Systems.

17. Концепция профилей в инженерии надежности ПС / Г.Б. Мороз, Г.И.Коваль, Т.М.Коро-

тун // Математичні машини і системи”. – 2004.- №1.- C. 166-184.

18. Мороз Г.Б. Пуассоновские модели роста надежности программного обеспечения и их

приложение. Аналитический обзор // УCиМ.- 1996.- №. 1-2 - С. 69-85.

19. Страничка в электронной энциклопедии «Википедия» http://en.wikipedia.org/wiki/

Test_driven_development

20. Бабенко Л.П., Лаврищева К.М. Основи програмної інженерії. Навчальний посібник. –

К.: Знання, 2001. –269 с.

21. Майерс Г. Надежность программного обеспечения. - М.: Мир, 1980. - 360 с.

22. Zave P. An Operational Approach to Requirements Specification for Embedded Systems //

IEEE Trans. Software Eng..- 1982. -V.8. - № 3.

23. Weyuker E.J., Ostrand T.J. Theories of program testing and the application of revealing sub-

domains // IEEE Trans.Soft.Eng.- 1980.-V.6. - №.3. - P. 236-246.

24. Richardson D., Clarke L. A partition analysis method to increase program reliability. // in

proc. of yet 5th international Conf. Soft. Eng., San Diego, CA, mar.9-12, 1981, -P. 244-253.