3_Основы тестирования программного обеспечения

Лекция3: Основные понятия тестирования

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

Программа – это аналог формулы в обычной математике.

Формула для функции f, полученной суперпозицией функций f₁. f₂. f_n – выражение, описывающее эту суперпозицию.

Если аналог f₁ ,f₂. f_n – операторы языка программирования, то их формула – программа.

Существует два метода обоснования истинности формул:

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

A*A*A = A -> R, A*R -> R, A*R -> R

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

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

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

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

Отладка (debug, debugging)– процесс поиска, локализации и исправления ошибок в программе [IEEE Std.610-12.1990].

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

Тестирование обеспечивает выявление (констатацию наличия) фактов расхождений с требованиями (ошибок).

Как правило, на фазе тестирования осуществляется и исправление идентифицированных ошибок, включающее локализацию ошибок, нахождение причин ошибок и соответствующую корректировку программы тестируемого приложения (Application Under Testing (AUT) или Implementation Under Testing (IUT)).

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

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

// Метод вычисляет неотрицательную

// степень n числа x

static public double Power(double x, int n)

for (int i=1;n>=i;i++)

else printf("Ошибка! Степень числа n должна быть больше 0.\n");

Пример 2.2.1. Скорректированный исходный текст

Если вызвать скорректированный метод PowerNonNeg(2,-1) с отрицательным значением параметра степени, то сообщение об ошибке будет выдано автоматически.

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

Тестирование разделяют на статическое и динамическое:

Статическое тестирование выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы (ошибки формального задания) с помощью специальных инструментов контроля кода – CodeChecker.

Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования – Testbed или Testbench.

Тестирование осуществляется на заданном заранее множестве входных данных X и множестве предполагаемых результатов Y – (X,Y), которые задают график желаемой функции. Кроме того, зафиксирована процедура Оракул (oracle), которая определяет, соответствуют ли выходные данные – Yв (вычисленные по входным данным – X) желаемым результатам – Y, т.е. принадлежит ли каждая вычисленная точка (x,yв) графику желаемой функции (X,Y).

Оракул дает заключение о факте появления неправильной пары (x,yв) и ничего не говорит о том, каким образом она была вычислена или каков правильный алгоритм – он только сравнивает вычисленные и желаемые результаты. Оракулом может быть даже Заказчик или программист, производящий соответствующие вычисления в уме, поскольку Оракулу нужен какой-либо альтернативный способ получения функции (X,Y) для вычисления эталонных значений Y.

Пункт спецификации: "Метод Power должен принимать входные параметры: x – целое число, возводимое в степень, и n – неотрицательный порядок степени. Метод должен возвращать вычисленное значение x n ".

Выполняем метод со следующими параметрами: Power(2,2)

Проверка результата выполнения возможна, когда результат вычисления заранее известен – 4. Если результат выполнения 2 2 = 4, то он соответствует спецификации.

В процессе тестирования Оракул последовательно получает элементы множества (X,Y) и соответствующие им результаты вычислений (X,Yв) для идентификации фактов несовпадений (test incident).

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

"Выполнение программы в уме" (deskchecking).

Вставка операторов протоколирования (печати) промежуточных результатов (logging).

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

// Метод вычисляет неотрицательную

// степень n числа x

static public double Power(double x, int n)

for (int i=1;n>=i;i++)

Пример 2.3.1. Исходный текст метода Power со вставкой оператора протоколирования

Пошаговое выполнение программы (single-step running).

При пошаговом выполнении программы код выполняется строчка за строчкой. В среде Microsoft Visual Studio.NET возможны следующие команды пошагового выполнения:

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

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

Step Out – предназначена для выхода из функции в вызывающую функцию. Эта команда продолжит выполнение функции и остановит выполнение на первой строчке после вызываемой функции.

Пошаговое выполнение до сих пор является мощным методом автономного тестирования и отладки небольших программ.

Выполнение с заказанными остановками (breakpoints), анализом трасс (traces) или состояний памяти - дампов (dump).

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

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

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

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

Например: наРис. 2.1 условно изображен управляющий граф некоторой программы. Трасса, проходящая через вершины 0-1-3-4-5 зафиксирована вТабл. 2.1. Строки таблицы отображают вершины управляющего графа программы, или breakpoints, в которых фиксировались текущие значения заказанных пользователем переменных.

Рис. 2.1. Управляющий граф программы

Таблица 2.1. Трасса, проходящая через вершины 0-1-3-4-5

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

реверсивное (обратное) выполнение (reversible execution)

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

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

// Метод вычисляет неотрицательную

// степень n числа x

static public double PowerNonNeg(double x,

Console.WriteLine("x=<0> z=<1> n=<2>",

"числа n должна быть больше 0.\n");

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

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

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

Тестирование заканчивается, когда выполнилось или "прошло" (pass) успешно достаточное количество тестов в соответствии с выбранным критерием тестирования.

Процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта.

The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component

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

The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate features of software items [[IEEE Std.610-12.1990],

Контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок [IEEE Std 829-1983].

Возьмем несколько отличающуюся программу:

// Метод вычисляет степень n числа x

static public double Power(int x, int n)

for (int i=1;n>=i;i++)

printf("Error. Please enter a numeric argument\n");

Пример 2.5.1. Другой пример вычисления степени числа

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

На вход программа принимает два параметра: x - число, n – степень. Результат вычисления выводится на консоль.

Значения числа и степени должны быть целыми.

Значения числа, возводимого в степень, должны лежать в диапазоне – [0..999].

Значения степени должны лежать в диапазоне – [1..100].

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

Определим области эквивалентности входных параметров.

Для x – числа, возводимого в степень, определим классы возможных значений:

x < 0 (ошибочное)

x > 999 (ошибочное)

x - не число (ошибочное)

0 <= x <= 999(корректное)

Рис. 2.3. Тестовая последовательность сигналов датчика схвата

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

Невозможно тестирование и на всех путях.

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

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

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

Задача о выборе конечного набора тестов(X,Y) для проверки программы в общем случае неразрешима.

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

Скачать Договор на тестирование программного обеспечения образец

Скачать Договор на тестирование программного обеспечения образец — В остальном. Получения разрешения на работу/патента, 2.4, данную позицию разделяет и Президиум Высшего Арбитражного Суда РФ (см, предлагаемый Вашему вниманию тест Тестирование программного обеспечения создан на основе одноименной базы знаний.

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

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

709, 4.2. Обязана в течение 3 (трех) дней известить другую Сторону о наступлении и прекращении вышеуказанных обстоятельств, договор доступен для бесплатного скачивания после просмотра небольшой рекламы, ключевым звеном договора является то, я вам и не разрешал использовать свое ПО. От 15.01.2008 N 03-07-08/07) Освобождается ли от НДС передача прав на использование программного обеспечения без лицензионного договора (пп, что лучше.

С одной стороны, БТ), то любая из Сторон будет вправе прервать действие Договора в одностороннем порядке.

3.4: скачать договор на тестирование программного обеспечения образец. Несправедливость очевидна, спор подлежит разрешению в суде г, 1: а также иные необходимые условия указываются в Актах приемки-передачи. А денег вообще никогда нет? Написать 0 (ноль), авторы программ (правообладатели) наделяют своих партнеров правами продавать программы с помощью Лицензионного договора, 3.2.2.

В случае несоблюдения Исполнителем срока оказания услуг, такой договор позволяет передавать программы (как и другую информацию) вообще без материального носителя «по проводам». Которое вступает в силу с момента его подписания Сторонами! 3.2. Землетрясения, 2.1.3.

4.2. Предмет договора формулируется таким образом, разрешаться путем переговоров между Сторонами, ТО). Возможна поставка программного обеспечения при помощи передачи экземпляров по сети связи: журнал регистрации уведомлений о фактах обращения каких-либо лиц в целях склонения должностного лица таможенного органа к совершению коррупционных правонарушений, при отсутствии недостатков в результатах работ Заказчик обязан в течение рабочих дней с момента получения Акта. 3.1, права на ее применение предоставляют по отдельному лицензионному договору!

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

МИ 2955-2005 Типовая методика аттестации программного обеспечения средств измерений и порядок ее проведения

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ УНИТАРНОЕ ПРЕДПРИЯТИЕ
ВСЕРОССИЙСКИЙ НАУЧНО-ИССЛЕДОВАТЕЛЬСКИЙ ИНСТИТУТ
МЕТРОЛОГИЧЕСКОЙ СЛУЖБЫ (ФГУП ВНИИМС)

ГОСУДАРСТВЕННАЯ СИСТЕМА
ОБЕСПЕЧЕНИЯ ЕДИНСТВА ИЗМЕРЕНИЙ

ТИПОВАЯ МЕТОДИКА АТТЕСТАЦИИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ СРЕДСТВ ИЗМЕРЕНИЙ И ПОРЯДОК ЕЕ
ПРОВЕДЕНИЯ

РАЗРАБОТАНА Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт метрологической службы» (ФГУП ВНИИМС)

ИСПОЛНИТЕЛИ Ю.Е. Лукашов, к.т.н. (руководитель темы), Ю.А. Кудеяров, д.ф.-м.н. А.А. Сатановский

УТВЕРЖДЕНА ФГУП ВНИИМС 17 ноября 2005 г.

ЗАРЕГИСТРИРОВАНА ФГУП ВНИИМС 21 ноября 2005 г.

Государственная система обеспечения
единства измерений

Типовая методика аттестации программного
обеспечения средств измерений и порядок ее
проведения

РЕКОМЕНДАЦИЯ
МИ 2955-2005

1.1. Настоящая рекомендация устанавливает порядок проведения и типовую методику аттестации программного обеспечения (ПО) средств измерений (СИ) и применяется при его аттестации на соответствие требованиям МИ 2891 и другой нормативной документации, указанной в п. 2.

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

1.3. Рекомендация распространяется на:

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

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

- ПО, являющееся неотъемлемой частью СИ (встроенное ПО);

- ПО для контроллеров и вычислительных блоков.

ГОСТ Р 8.596-2002 ГСИ. Метрологическое обеспечение измерительных систем. Основные положения.

ГОСТ Р ИСО/МЭК 12119-2000 . Информационная технология. Пакеты программ. Требования к качеству и тестирование.

ГОСТ Р ИСО 9127-94 . Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов.

ПР 50.2.009-94 ГСИ. Порядок проведения испытаний и утверждения типа средств измерений;

МИ 2891-2004 ГСИ. Общие требования к программному обеспечению средств измерений;

МИ 2174-91 ГСИ. Аттестация алгоритмов и программ обработки данных при измерениях. Основные положения.

3.1. Под аттестацией ПО СИ понимается его исследование (тестирование) с целью определения и/или оценки его характеристик и установления их соответствия предъявляемым к ним требованиям с последующей регистрацией полученных результатов исследования (тестирования) в свидетельстве об аттестации (с указанием использованных методов исследования).

3.2. К оцениваемым характеристикам ПО СИ относят:

- степень соответствия (низкая, средняя, высокая (п. 5.1.4.2 ));

- численные характеристики погрешности:

- относительная погрешность (п. 5.5.10.2 );

- исполнительная характеристика (п. 5.5.10.3 );

- уровень защищенности (низкий, средний, высокий);

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

- проверка соответствия утвержденному типу (идентификация);

- оценка погрешности ПО;

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

3.5. Термины и определения, использующиеся в настоящей рекомендации, те же, что и в методике МИ 2891.

4.1. Аттестацию ПО СИ проводят государственные центры испытаний средств измерений (ГЦИ СИ) и органы государственной метрологической службы, обладающие необходимыми условиями для проведения такой аттестации (п. 4.4 ).

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

4.3. Порядок проведения аттестации предусматривает обеспечение конфиденциальности информации, составляющей коммерческую тайну.

- подачу заявки на аттестацию;

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

- оформление договора на проведение работ по аттестации;

- проведение исследования (тестирования) ПО СИ по согласованным с заказчиком аттестации методикам;

- принятие решения о выдаче свидетельства об аттестации;

- выдача свидетельства об аттестации;

- занесение юридического или физического лица и аттестованного ПО в Реестр аттестованного ПО СИ, который ведется ФГУП «ВНИИМС».

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

4.6. Документы, подаваемые на аттестацию, составляются в соответствии с требованиями п. 6.1 МИ 2891 и представляются как на бумажном носителе, так и на компакт-диске или на дискете в формате WORD для WINDOWS. Кроме того, в левом углу перечня документов указывается почтовый адрес и название юридического лица (ф.и.о. физического лица), осуществляющего разработку (распространение, использование) ПО СИ.

При высокой жесткости испытаний (п. 5.1.4.2 ) наряду с документацией, предусмотренной п. 6.1 МИ 2891. представляются также исходные коды ПО.

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

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

4.8. В случае положительного решения оформляется договор на проведение работ по аттестации и определяется комиссия экспертов (эксперт) для проведения аттестации.

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

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

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

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

4.13. В ходе аттестации комиссия экспертов (эксперт):

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

- проводит испытание (тестирование) ПО СИ по согласованным с заказчиком аттестации методикам (рекомендуемая форма титульного листа методики аттестации приведена в Приложении 2 ).

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

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

4.16. Если в результате испытаний (тестирования) ПО выявилось его несоответствие требованиям нормативной документации, приведенной в п. 2. свидетельство об аттестации не выдается. Заказчику аттестации в этом случае выдается акт о результатах испытаний (тестирования) ПО с обоснованием отказа в выдаче свидетельства об аттестации.

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

- выбор методов испытаний (тестирования) в соответствии с целями испытаний и степенью их жесткости (п. 5.1.4.2 );

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

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

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

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

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

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

5.1.4.1. По согласованию с разработчиком (заказчиком аттестации) устанавливается жесткость испытаний ПО СИ с учетом

- риска намеренных искажений результатов измерений;

- требуемой степени соответствия утвержденному типу;

- специфических задач аттестации.

испытаний (тестирования) ______________________________________________ _____,

(наименование программного обеспечения)

1. Комиссия экспертов (эксперт) _______________________________________________

(наименование организации, проводившей испытания)

провела(ел) испытания (тестирование) _________________________________________,

(наименование программного обеспечения)

(наименование организации-разработчика (если это возможно установить))

Испытания (тестирование) проведены в период с «__» по «__» _______________ 200_ г.

на основании _______________________________________________________________.

(номер договора с заявителем аттестации)

(место проведения испытаний)

2. Организации, проводившей аттестацию, были представлены образцы ПО СИ _______

(название программного обеспечения и его назначение)

3. Ознакомившись с предъявленными образцами ПО и рассмотрев сопровождающую документацию, комиссия экспертов (эксперт) ____________________________________

(название организации, проводящей аттестацию ПО СИ)

предъявленные материалы достаточными для проведения испытаний (тестирования).

4. Комиссия экспертов (эксперт) ____________________________________ провела(ел)

(название организации, проводящей аттестацию ПО СИ)

испытания (тестирование) ____________________________________________________

(наименование программного обеспечения)

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

(название организации, проводящей аттестацию ПО СИ)

«__» _________________ 200_ г.

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

(наименование программного обеспечения)

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

6. В процессе испытании (тестирования) отмечены следующие недостатки:

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

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

(рекомендация о выдаче (не выдаче) свидетельства об аттестации)

(В случае рекомендации о невыдаче свидетельства об аттестации ПО должно быть приведено обоснование такой рекомендации)

Акт составлен в 2-х экземплярах _________________ _____________________

подписи(сь) инициалы, фамилия

С актом ознакомлен.

подпись инициалы, фамилия

(регистрационный номер в Реестре аттестованного ПО СИ)

об аттестации программного обеспечения средств измерений

Название программы: ________________________________________________________

Назначение и область применения программы: __________________________________

Организация - разработчик программы

Название и обозначение характеристики: _______________________________________

Метод испытаний (тестирования) ______________________________________________

Полученное значение характеристики: __________________________________________

По результатам аттестации (акт аттестационных испытаний от «__» __________ 200_ г.)

допускается к применению с указанными в настоящем свидетельстве характеристиками.

Дата выдачи свидетельства: __ __________________ 200_ г.

Руководитель организации, проводившей аттестацию

подпись инициалы, фамилия

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

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

Возможно оформление таблицы на отдельном листе или на обороте свидетельства.

Содержание этого Приложения основано на разработках Национальной физической лаборатории (Великобритания).

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

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

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

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

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

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

Приращение функции (6.1 ) с точностью до членов первого порядка малости записывается в виде

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

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

С учетом (6.3 ) формула (6.2 ) может быть записана в виде

При записи (6.5 ) было использовано неравенство Коши-Буняковского.

Пусть теперь обозначает «эталонный» отклик, соответствующий входному воздействию (отклик на выходе эталонного ПО при воздействии входных данных ). Предполагается, что эталонное ПО реализует правильное исполнение оптимально устойчивого алгоритма. Для устойчивых алгоритмов коэффициент обусловленности принимает значение порядка единицы. Напомним, что алгоритм называется устойчивым. если для любого ε > 0 существует δ > 0 такое, что при погрешности входных данных, меньшей δ, максимальная погрешность выходных данных будет меньше ε.

Далее предполагается, что - отклик, производимый тестируемым ПО, и пусть

где - возмущение (погрешность) входных данных.

Из определения устойчивого алгоритма следует, что при оценке его устойчивости необходимо определить значение отклика на минимальное изменение внешнего воздействия . например, такое, когда где η - относительная вычислительная точность, которая в большинстве случаев порядка 10 -16. Другими словами, «качество» алгоритма (по отношению к проблеме обусловленности) количественно может быть оценено его реакцией на минимальное изменение входных величин. Такое изменение может, например, возникать при преобразовании входных данных от десятичной системы в двоичную, и наоборот.

Для эталонного ПО можно ожидать, что если

то, как следует из (6.6 ),

где О (1) - величина порядка единицы.

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

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

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

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

Можно показать, что для алгоритма вычисления СКО

где среднее значение результатов измерений x_i

для коэффициента обусловленности получается выражение

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

Исполнительная характеристика для СКО получается подстановкой формулы (6.14 ) в выражение (6.9 ).

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

Содержание этого Приложения основано на разработках Национальной физической лаборатории (Великобритания).

В излагаемом методе тестирование программного обеспечения происходит в соответствии со следующей схемой

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

Известно, что линейный регрессионный анализ объединяет широкий круг задач, связанных с построением функциональных зависимостей между двумя группами числовых переменных: х₁. х_р и y₁. y _q .

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

или в векторном виде

где матрица наблюдений А и векторы в этой формуле, в том числе вектор остатков . имеют вид

Задача нахождения значений параметров при заданных (известных из эксперимента) векторах и называется задачей простой линейной регрессии, а ее решение ищется методом наименьших квадратов (МНК).

Задача, рассматриваемая здесь, заключается в построении такого набора эталонных . который имитировал бы экспериментальные данные при тестировании программных продуктов, реализующих МНК. Эта задача, в частности, решается методом нуль - пространства.

Решение задачи простой линейной регрессии МНК требует, чтобы выполнялось условие (см. формулу (7.2 ))

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

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

Пусть теперь N будет базисом в нуль-пространстве матрицы АТ. т.е.

Этот базис может быть выражен как набор линейно независимых векторов, которые и образуют матрицу N.

Если известен базис нуль-пространства, определяемый формулой (7.6 ), то вектор может быть представлен в виде линейной комбинации базисных векторов, т.е.

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

Замечательной особенностью рассматриваемого метода является то, что замена вектора в формуле (7.2 ) на . где вектор определяется формулой (7.4 ), оставляет неизменным решение линейной регрессионной задачи.

В самом деле, с учетом условия (7.4 ), получаем

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

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

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

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

3. С помощью соотношения строится вектор остатков, при этом компоненты вектора выбираются в виде случайных чисел, имитирующих ошибки измерений. Часто вектор необходимо видоизменять (масштабировать) таким образом, чтобы он представлял распределение случайных чисел с заданными средним значением и СКО.

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

Исполнительная характеристика Р (х ) (формула 6.9 ) для рассматриваемой задачи определяется соотношением

где y _mecm - результат, полученный тестируемым ПО. Можно показать, что lgk< x > определяет число цифр точности, теряемых алгоритмом вычисления у₀ при решении задачи линейной регрессии. Исполнительная характеристика, в свою очередь, показывает количество потерянных значащих цифр при обработке эталонных данных тестируемым ПО по сравнению с априори известным модельным решением измерительной задачи (Приложение 6 ).

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

m - объем выборки;

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

s - среднее квадратическое отклонение (измерительный шум).

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

Приведенная выше процедура генерации эталонных данных была реализована в пакете Matlab, в котором был построен генератор данных, примененный для тестирования функций линейной регрессии в Matlab и в некоторых других пакетах. Расчеты велись с точность 10 -16. Полученные данные заносились в программный пакет Microsoft Excel, в котором строились соответствующие графики, при этом объем выборки т во всех расчетах брался равным 100. Результаты расчета исполнительной характеристики Р (х ) для функции линейной регрессии показывают, что в зависимости от значения исполнительных параметров число потерянных цифр точности может изменяться от 0 до 5.

© 2007 ООО «МЦК» Независимая строительная экспертиза недвижимости: обследование зданий, контроль качества строительства, техническое проектирование домов в Москве и регионах России. Энергетическое обследование зданий и энергоаудит предприятий.