---

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

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

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

Литература:

Software Testinga via Environmental Simulation (CONTESSE Report). Available until December 1998 from: Ray Browne, CI ID, DTI, 151 Buckingham Palace Road, London, SW1W 9SS, UK, 1994.

Validation of ultra high dependability for software based systems. B. Littlewood and L Strigini. Comm. ACM 36(11), 69-80, 1993.

Handbook of Software Reliability Engineering. M.R. Lyu (ed.). IEEE Computer Society Press, McGraw-Hill, 1995, ISBN 0-07-039400-8.

C.5.2 Регистрация и анализ данных

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы А.5 и А.8).

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

Описание: в процессе всего проектирования разрабатывается подробная документация, в которую входят:

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

- решения и их разумные обоснования;

- проблемы и их решения.

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

Литература:

Dependability of Critical Computer Systems 2. F.J. Redmill, Elsevier Applied Science, 1989, ISBN 1-85166-381-9.

C.5.3 Тестирование интерфейса

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица А.5).

Цель: обнаружение ошибок в интерфейсах подпрограмм.

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

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

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

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

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

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

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

С.5.4 Анализ граничных значений

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.2, В.3 и В.8).

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

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

- нулевой делитель;

- знаки пробела ASCII;

- пустой стек или элемент списка;

- заполненная матрица;

- ввод нулевой таблицы.

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

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

Литература:

The Art of Software Testing. G. Myers, Wiley & Sons, New York, 1979.

C.5.5 Предположение ошибок

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.2 и В.8).

Цель: исключение ошибки программирования.

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

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

Литература:

The Art of Software Testing. G. Myers, Wiley & Sons, New York, 1979.

C.5.6 Введение ошибок

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.2).

Цель: подтверждение адекватности набора тестовых примеров.

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

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

Литература:

Software Fault Injection, J. M. Voas и G. McGraw, Wiley 1998.

C.5.7 Разделение входных данных на классы эквивалентности

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблицы В.2 и В.3).

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

Описание: данный метод тестирования основывается на отношении эквивалентности входных данных, определяющем разбиение входных данных предметной области.

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

Существуют следующие основные возможности разбиения входных данных:

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

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

Литература:

The Art of Software Testing. G. Myers, Wiley & Sons, New York, 1979.

C.5.8 Структурное тестирование

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.2).

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

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

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

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

- составные условия - анализируется каждое условие в составной условной ветви (связанное оператором И/ИЛИ). См. MCDC (охват условного модифицированного решения, документ DO178B);

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

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

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

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

Литература:

Reliability of the Path Analysis Testing Strategy. W. Howden. IEEE Trans Software Engineering, Vol. SE-3, 1976.

Software considerations in airborne systems and equip certification, DO178B, RTCA, December 1992.

Structure testing, McCabe; NBS Special Publication 500-99, 1982.

A software reliability study, Walsh [USA] National Computer Conference, 1979.

C.5.9 Анализ потоков управления

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).

Цель: обнаружение низкокачественных и потенциально некорректных структур программ.

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

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

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

Литература:

Information Flow and Data Flow of While Programs. J. F. Bergeretti and B. A. Carre, ACM Trans, on Prog. Lang, and Syst., 1985.

C.5.10 Анализ потока данных

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).

Цель: обнаружение низкокачественных и потенциально некорректных структур программ.

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

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

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

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

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

Литература:

Information Flow and Data Flow of While Programs. J. F. Bergeretti and B. A. Carre, ACM Trans, on Prog. Lang, and Syst., 1985.

C.5.11 Выявление скрытых схем исполнения

Примечание - Ссылка на данный метод/средство приведена в МЭК 61508-3 (таблица В.8).

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

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

Паразитные схемы разделяют на следующие категории:

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

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

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

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