Будь умным!

У вас вопросы?
У нас ответы:) SamZan.net

законченных единиц ошибок проекта и кодирования

Работа добавлена на сайт samzan.net:

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 24.11.2024

10

PAGE  10

12 Аналитическая проверка корректности программ

 12.1 Верификация программ.

 Корректность является статическим свойством ПО, поскольку она:

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

 

Два свойства корректности ПО  ( с учётом  специфики проявления ошибок в ПО в процессе их выполнения на ПК ) :

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

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

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

  •  частичная корректность (при условии завершенности);
  •  завершенность программы;
  •  незавершенность программы;
  •  тотальная корректность (частичная корректность и завершенность);
  •  частичная некорректность (некорректность при условии завершенности);
  •  некорректность (незавершенность или частичная некорректность).

ВЫВОД. Эти шесть задач  направлены на уменьшение сложности верификации ПО..

12.2 Объекты тестирования

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

С точки зрения тестирования наиболее значимыми являются следующие объекты программного проекта: 

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

цикла.

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

Состояние теории и практики тестирования на рис.12.1 (нумерация объектов на рисунке соответствует списку объектов тестирования).

            1            2    3      4        5  6

Спецификации     Модули     Группы     Комплексы   Прогр.  Программный

                                               программ     программ     ср-ва         продукт

Рис.12.1.

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

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

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

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

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

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

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

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

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

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

12.3 Категории тестов для различных объектов тестирования

На разных этапах ЖЦ программного обеспечения для каждой категории объектов тестирования ставятся свои задачи тестирования и, соответственно, применяются свои виды тестирования и категории тестов.

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

Для описанных выше объектов тестирования выделяются следующие категории тестов:

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

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

Одним из общих принципов тестирования ПО является проведение работ по тестированию в течение всего ЖЦ.

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

Рассмотрим наиболее широко применяемые методы функционального тестирования, или тестирования по принципу "черного ящика".

1. Метод эквивалентного разбиения

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

Правильно выбранный тест этого подмножества должен обладать двумя свойствами:

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

Разработка тестов методом эквивалентного разбиения осуществляется в два этапа:

  1.  выделение классов эквивалентности;
  2.  построение тестов.

1.1. Выделение классов эквивалентности

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

Различают два типа классов эквивалентности:

  •  правильные классы эквивалентности, представляющие правильные входные данные программы;
  •  неправильные классы эквивалентности, представляющие ошибочные входные данные.

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

  1.  Если    входное  условие   описывает   область  значений  (например, 1  I  100), то задается один правильный класс эквивалениности (1  I  100) и два неправильных ( X < 1 и X>100).
  2.  Если входное условие описывает число значений (например, число элементов последовательности N не должно превышать 10), то определяется один правильный класс эквивалентности (N  10) и два неправильных (N<1 и N>10).
  3.  Если входное условие описывает множество входных значений и есть основание полагать, что каждое значение программа трактует особо (например, цвет может принимать значения: красный, желтый, зеленый),  то определяется правильный класс эквивалентности для каждого значения и один неправильный класс эквивалентности – значение, не принадлежащее множеству (например, белый).
  4.  Если входное условие описывает ситуацию “должно быть” (например, первым символом идентификатора должна быть буква), то определяется один правильный класс эквивалентности (первый символ – буква) и один неправильный класс эквивалентности (первый символ – не буква).
  5.  Если есть основание считать, что различные элементы класса эквивалентности трактуются программой неодинаково, то данный класс эквивалентности разбивается на меньшие классы эквивалентности.

1.2. Построение теста

  1.  Назначение каждому классу эквивалентности уникального номера.
  2.  Проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности, до тех пор пока все правильные классы эквивалентности не будут покрыты.
  3.  Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности, до тех пор пока все неправильные классы эквивалентности не будут покрыты. Причина покрытия неправильных классов эквивалентности индивидуальными тестами заключается в том, что определенные проверки с ошибочными входами скрывают или заменяют другие проверки с ошибочными входами.

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

Граничные условия – это ситуации, возникающие непосредственно на, выше или ниже границ входных и выходных классов эквивалентности.

Анализ граничных значений отличается от эквивалентного разбиения в двух отношениях:

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

Правила использования данного метода:

1)  Построить тесты для границ области и тесты с  неправильными входными данными для ситуаций незначительного выхода за границы области, если входное условие описывает область значений. Например, если правильное значение   -1.0  X  +1.0, то составить тесты для ситуаций: -1.0, 1.0, -1.001, 1.001.

  1.  Построить тесты для минимального и максимального значений условий и тесты, большие и меньшие этих значений,  если входное условие принимает значения из некоторого дискретного диапазона. Например, если входной файл может содержать от 1 до 256 записей, то необходимо составить тесты для 0, 1, 255 и 256 записей.
  2.  Использовать правило 1) для каждого выходного условия. Например, если программа вычисляет ежемесячный расход и если минимум расхода составляет 0.00 руб., а максимум – 100000.00 руб, то нужно построить тесты, которые вызывают следующие расходы: -1.00, 0.00, 100000.00 и 100000.25.
  3.  Использовать правило 2) для каждого выходного условия. Например, если система информационного поиска отображает на экране терминала не более 8 наиболее подходящих рефератов для входного запроса, то следует составить тесты, которые могли бы вызвать выполнение программы с отображением 0, 1, 8, >8 рефератов.
  4.  Если вход или выход программы – упорядоченное множество (например, линейный список, таблица, последовательный файл), то следует разработать тесты для обработки первого и последнего элементов этого множества.

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

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

3. Метод функциональных диаграмм

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

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

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

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

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

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

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

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

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

  •  Если обратная трасса прокладывается через узел ИЛИ, выход которого должен принимать значение 1, то одновременно не следует устанавливать в 1 более одного входа в этот узел. Цель данного правила – избежать пропуска определенных ошибок из-за того, что одна причина маскируется другой.
  •   Если обратная трасса прокладывается через узел ИЛИ, выход которого должен принимать значение 0, то все комбинации входов, приводящие выход в 0, должны быть в конечном счете перечислены. Однако, когда исследуется ситуация, где один вход есть 0, а один или более других входов есть 1, не обязательно перечислять все условия, при которых остальные входы могут быть 1.
  •  Если обратная трасса прокладывается через узел И, выход которого должен принимать значение 0, то необходимо указать лишь одно условие, согласно которому все входы являются нулями.

Каждый узел диаграммы может находиться в двух состояниях – 0 или 1; 0 обозначает состояние “отсутствует”, а 1 – “присутствует”.

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

    Если значение a  есть 1 , то и значение b  есть 1; в                        противном случае  значение b есть 0.

 Если значение a  есть 0 , то  значение b  есть 1; в                        противном случае  значение b есть 0.

 

 Функция ИЛИ устанавливает, что если a, или b,

или с есть 1, то d есть 1; в противном случае d есть 0.

 

Функция И устанавливает, что если и a, и b есть 1, то и с есть 1; в противном случае с есть 0.

 Пример

Рассмотрим диаграмму, отображающую спецификацию: Файл обновляется, если символ в колонке 1 является буквой “A” или “B”, а символ в колонке 2 – цифра. Если первый символ ошибочный, то выдается сообщение X1, а если второй символ не является цифрой – сообщение X2.

 Причины:

  1 – символ “A” в колонке 1

  2 – символ “B” в колонке 1

  3 – цифра в колонке 2

 Следствия:

  7 – файл обновляется

  6 – выдается сообщение X1

  8 – выдается сообщение X2

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

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

 

Ограничение Е устанавливает, что Е должно быть истинным, если хотя бы одна из причин – а или b – принимает значение 1 (a и b не могут принимать значение 1 одновременно).

      

Ограничение I устанавливает, что по крайней мере одна из величин a, b или c всегда должна быть равной 1 (a,  b и с не могут принимать значение 0 одновременно).

 Ограничение О устанавливает, что одна и только одна из величин а или b должна быть равна 1.

 

Ограничение R устанавливает, что если a принимает значение 1, то и b должна принимать значение 1, т.е. невозможно, чтобы a было равно 1, а  b – 0.

Ограничение М устанавливает, что если следствие a имеет значение 1, то следствие b должно принять значение 0.

Для рассмотренного выше примера физически невозможно, чтобы причины 1 и 2 присутствовали одновременно, но возможно, чтобы присутствовала одна из них. Следовательно, они связаны ограничением Е.

 

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

Выберем следствие 7 (файл обновляется). Следствие 7 имеет место, если узлы 3 и 11есть 1. В свою очередь узел 11 есть 1, если одна из причин 1 или 2 имеет  значений  1. Таким образом, возможны следующие состояния узлов 1 – 3:

1    0    1    и     0   1   0.

Следствие 6 имеет место, если значение узла 11 есть 0 (узлы  1 и 2 оба равны 0).

Следствие 8 имеет место, если значение узла 3 есть 0.

Таблица решений будет иметь следующий вид:

Столбец 1 представляет условие, где следствие 6 есть 1,  столбцы 2,3 –  следствие 7 есть 1, а столбец 4 соответствует условию, для которого следствие 8 есть 1.

Пробелы в таблице решений представляют “безразличные” ситуации (состояние причины несущественно).

Преобразуем таблицу решений в набор тестов:

Кол.1   Кол.2

  1.    1         1
  2.    A        2
  3.    B        2
  4.    A       A

4. Метод, основанный на предположении об ошибке

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

В качестве примера рассмотрим тестирование подпрограммы сортировки. Необходимо предусмотреть следующие специальные случаи, которые могут быть не учтены при проектировании программы:

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

Общая стратегия разработки тестов

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

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

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

Критерии завершения тестирования

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

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

ЛИТЕРАТУРА

Основная

1. Липаев В.В.  Качество программного обеспечения.  - М.:  Финансы  и    статистика, 1983. -263с.

2. Назаров С.В.,  Барсуков А.Г.  Измерительные средства и оптимизация вычислительных систем. - М.: Радио и связь, 1990. -248с.

3. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. - М.: Радио и связь, 1985. -512с.

4. Авен О.И.  и др. Оценка качества и оптимизация вычислительных систем. - М.: Наука, 1982. -485с.

5. Кузовлев В.И.,  Шкатов П.Н. Математические методы анализа производительности и надежности САПР, М.: Высшая школа, 1990.

6. Липаев В.В.  Надежность программного обеспечения.  - М.: Энергоиздат, 1981. -241с.

7. Липаев В.В. Проектирование программных средств. - М: Высшая школа, 1990. -301с.

8. Липаев В.В.  Тестирование программ.  - М.:  Радио и  связь,  1986. -294с.

9. Р.Калбертсон и др.  Быстрое тестирование. Пер. с англ.. -  М.:  Изд.дом  «Вильямс»,    2002-384с.

Дополнительная:

10.Коган Б.И.  Экспериментальные исследования программ.  - М.: Наука, 1988. -184с.

11.Боэм Б.  и др.  Характеристики качества программного  обеспечения. Пер. с англ. Е.К.Масловского. - М.: Мир, 1981. -208с.

12.Кожевникова Г.П. Структуры данных и проектирование эффективной вычислительной среды. - Львов: Вища школа, Изд. ЛГУ, 1986. -278с.

13.Холстед М.Х.  Начала науки о программах. - М.: Финансы и статистика,1981.-128с.

14.Бровин Н.Н.  и др. Оценка эффективности алгоритмов и программ. Ленинград.: ЛИАП 1983.-31с.

EMBED Word.Document.8 \s

EMBED Word.Picture.8  

EMBED Word.Picture.8  

EMBED Word.Picture.8  

EMBED Word.Picture.8  

EMBED Word.Picture.8  

  1.  ИЛИ

  1.      Не

b

a

  1.  Тождество

b

a

Объекты тестирования

Степень автоматизации

Уровень теоретической разработки

Сложность

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




1. тематическое планирование ’ п-п
2. Проектирование и расчет усилителя низкой частоты
3. Весь объем выпуска 2 Объем выпуска готовой продукции 3 Товары и услуги 4
4. по теме 17 ОСОБЕННОСТИ АГРАРНОГО СЕКТОРА ЭКОНОМИКИ Специальность 080105
5. Ядро заряжено положительно заряд ядра определяет химический элемент к которому относят атом
6. правового института банкротства
7. вариантом его элементов образующих внутреннюю структуру конфликта как целостного явления
8. Телевидение в системе средств массовой коммуникации.html
9. Клиническая и специальная психология Специальность Психология или Клиническая психология Квалиф
10. Организует и проводит рентгенологическое или флюорографическое обследование органов грудной клетки все
11. заочная форма обучения Вид учебной работы Всего часов зачетн
12. 84 Карт сборной команды страны модель 1984 года Необходимость этого материала продиктована ре
13. Статья- Финансовые ловушки- как их найти и обезвредить
14. Тема 8. Затраты на охрану окружающей среды и их обоснование
15. Задание А2. Биология ЕГЭ2013
16. Буль Boole Джордж
17. Отчет по лабораторной работе 2 Определение термодинамических параметров воды и водяного пара при модели
18. В религиозном представлении сущность человека имеет божественную природу и принадлежит Богу
19. сокращенную Идея RISC это тщательный подбор команд которые можно было бы выполнить за один такт
20. Об обеспечении санитарного и эпидемического благополучия населения от 24 февраля 1994 г

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