Автоматизация тестирования программного обеспечения - Программирование, компьютеры и кибернетика курсовая работа
Главная
Программирование, компьютеры и кибернетика
Автоматизация тестирования программного обеспечения
Комплексное функциональное и структурное тестирование программного продукта - граф-программа решения квадратного уравнения. Постановка задачи структурного тестирования маршрутов. Заключение о типе и причине ошибки, предложение по ее исправлению.
посмотреть текст работы
скачать работу можно здесь
полная информация о работе
весь список подобных работ
Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Для заданного программного продукта (граф-программа решения квадратного уравнения, изображенная на рисунке 1) произвести комплексное фуцнкциональное и структурное тестирование.
Рисунок 1 - Алгоритм решения кубического уравнения
Рассмотрим основные особенности графа:
1. Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов (end if; end loop) рассматриваются как отдельные (фиктивные) операторы.
2. Узлы (вершины) графа соответствуют в самом простом случае линейным участкам программы, включают один или несколько операторов программы.
3. Дуги графа отображают поток управления в программе (передачи управления между вершинами). Дуга -- это ориентированное ребро.
4. Различают операторные и предикатные узлы. Из операторного узла выходит одна дуга, а из предикатного -- две дуги.
4. Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций (OR, AND).
Модульное тестирование, или юнит-тестирование (англ. unit testing) -- процесс, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. В данной работе мы будем использовать юнит-тесты для проверки функциональных требований программы.
Для модульного тестирования необходимо использовать драйверы и заглушки.
Unit (Элемент) -- наименьший компонент, который можно скомпилировать.
Драйверы -- модули тестов, которые запускают тестируемый элемент.
Заглушки -- заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:
- возвращаются к элементу, не выполняя никаких других действий;
- отображают трассировочное сообщение и иногда предлагают тестеру продолжить тестирование;
- возвращают постоянное значение или предлагают тестеру самому ввести возвращаемое значение;
- осуществляют упрощенную реализацию недостающей компоненты;
- имитируют исключительные или аварийные условия.
White-box testing (тестирование методом «белого ящика») - для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность, что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.
Black-box testing (тестирование методом «черного ящика») - для конструирования тестов используются требования и спецификации ПО.
Модели ошибок описывают классы ошибок, которые можно сделать при разработке целевой программы. Классификация ошибочных ситуаций представлена в таблице Таблица 1.
Таблица 1 - Описание ошибочных ситуаций
Ошибки способа обработки аргументов
Целевая операция имеет несколько вариантов работы, выбор которых зависит от значений аргументов. Ошибка состоит в отсутствии одного из вариантов работы или в выборе ошибочного для некоторых значений аргументов.
a. Операция вычисления абсолютной величины, работает по-разному для аргумента x >= 0 и для x < 0.
Ошибка может состоять в том, что случай x < 0 совсем забыли написать.
b. Операция вычисления произведения элементов массива.
Ошибка может состоять в том, что пустые массивы обрабатываются неправильно -- обычно произведение пустого множества чисел считают равным 1.
Ошибка состоит в неправильном переходе или в неправильном условии перехода по потоку управления.
Вычисление суммы элементов массива.
Ошибка в условии цикла может привести к неучету первого или последнего элементов.
Ошибки потока управления между подсистемами
Похожи на ошибки потока управления, но ориентировано на системное, а не компонентное тестирование.
- неправильные переходы между компонентами программы;
- забыли реализовать некоторую операцию;
- забыли вставить использование некоторого компонента.
Набор текста вместо числа в некотором поле может приводит к падению программы.
Неправильные зависимости между данными программы, пропущенные связи.
Ошибки обработки формальных текстов
Ошибки состоят в нераспознавании или неправильной обработке некорректных текстов, отнесении правильных тестов к некорректным, неправильной обработке корректных текстов.
Ошибки поведения, зависящего от состояния
Предполагается, что поведение программы существенно зависит ранее сделанных обращений к ней. Ошибки: переходы в неправильные состояния, неправильная работа в некотором состоянии.
Нажатие на кнопку «Возврат денег» в автомате для продажи газет может привести к выдаче денег, даже если человек до этого их не платил.
Базой для модульного тестирования служат отдельные модули исходного кода программы. Пошаговый план модульного тестирования представлен в таблице 2.
Таблица 2 - План модульного тестирования
Рассмотрим подробно тестирование вычислительного модуля dZ алгоритма решения кубического уравнения. Предположительно в данном модуле находится «редкая» ошибка. Задачей тестировщика является обнаружение этой ошибки.
Пр оцесс тестрования модуля начинается с локализации области, содержащей ошибку. Для этого проверим стандартную установку параметров тестирования, описанных выше: разрядность ЭВМ t=15, r=0; тестируемые параметры принадлежат диапазонам Х, Y.
Запустим процесс тестирования. Результат - пустой экран (Рисунок 2).
Рисунок 2 - Результат при t=15, r=0
Изменим параметры разрядной сетки - t=5, r=1. В результате появились ошибочные точки в исходных данных (Рисунок 3), часть из которых являются истинными ошибками, частично они могут быть «наведенными» мнимыми ошибками, связанными с ограничениями разрядной сетки.
В рамках исходного окна выделяем новую рамку для того фрагмента домена, который обещает большое количество ошибок.
Переопределяем параметры окна, например, для нашего случая: Х[900;1100], Y[0;200] и запустим расчет.
#define RbX 1100 //ПРАВАЯ ГРАНИЦА X
В результате получится картина, представленная на рисунке 4Рисунок 4.
Рисунок 4 - Результат при Х[900;1100], Y[0;200]
Полученную фигуру отцентрируем, для этого сместим окно по координате TF на 20 градусов.
#define RbX 1120 //ПРАВАЯ ГРАНИЦА X
Получим фазовый портрет, представленный на рисунке Рисунок 5.
Рисунок 5 - Результат при LbX=920, RbX=1120, LbY=0, RbY=200
Теперь увеличим разрядную сетку ЭВМ: t=6, r=0, проведем испытания. Результаты представлены на рисунке 6.
Теперь наведем окно поиска на перспективное скопление точек, представленных на рисунке 7Рисунок 7.
Эта процедура продолжается, пока параметр разрядности t не станет равен 15.
#define LbX 1021.954445715 //ЛЕВАЯ ГРАНИЦА X
#define RbX 1021.95444574 //ПРАВАЯ ГРАНИЦА X
#define RbY 0.001 //ПРАВАЯ ГРАНИЦА Y
Примечание. Для больших t, т.е., когда вектор ошибочных данных практически обнаружен, полезно распечатать координаты этой точки (Рисунок 8).
В ходе отладки вычислений в точке с координатами х=1021.95444572,у=0.0005 была обнаружена ошибка деления на ноль ( Рисунок 9).
Рисунок 9 - Исходный код программы. Подсвечена ошибка деления на ноль
В ходе выполнения лабораторной работы была выявлена ошибка деления на ноль, возникающая при значениях координаты X, близких к 1021.95444572.
Данная ошибка относится к классу ошибок способа обработки аргументов. Возможной причиной ошибки является недостаточная проработка алгоритма, в частности, упущена обработка исключительного случая. Исправление ошибки возможно с помощью удаления знаменателя из программного кода, либо написания проверочной ветки алгоритма с соотвтетствующей обработкой, то есть использования метода тестирования граничных значений.
Результаты тестирования по каждому из модулей сведем в таблицу:
Таблица 3 - Результаты модульного тестирования
Структурный подход в тестировании основан на анализе логики программы (стратегия «белого ящика»). Существо подхода - в проверке каждого пути, каждой ветви алгоритма.
Если отказаться полностью от тестирования всех путей, можно показать, что критерием покрытия является выполнение каждого оператора программы хотя бы один раз. Это необходимое, но недостаточное условие для приемлемого тестирования по принципу белого ящика.
2 Метод покрытия решений (покрытия переходов).
Согласно данному методу должно быть написано достаточное число тестов, такое, что каждое направление перехода должно быть реализовано, по крайней мере, один раз. Покрытие решений обычно удовлетворяет критерию покрытия операторов. Поскольку каждый оператор лежит на некотором пути, исходящем либо из оператора перехода, либо из точки входа программы, при выполнении каждого направления перехода каждый оператор должен быть выполнен.
Записывается число тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз.
Критерий покрытия решений/условий требует такого достаточного набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись, по крайней мере, один раз, все результаты каждого решения выполнялись, по крайней мере, один раз и, кроме того, каждой точке входа передавалось управление, по крайней мере, один раз.
5 Метод комбинаторного покрытия условий.
Критерием, который решает эти и некоторые другие проблемы, является комбинаторное покрытие условий. Он требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись, по крайней мере, один раз. Набор тестов, удовлетворяющих критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.
Структурное тестирование программы предполагает знание исходного текста программы, либо спецификации программы в виде потокового графа управления.
Рассмотрим основные особенности потокового графа:
1. Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов (end if; end loop) рассматриваются как отдельные (фиктивные) операторы.
2. Узлы (вершины) потокового графа соответствуют линейным участкам программы, включают один или несколько операторов программы.
3. Дуги потокового графа отображают поток управления в программе (передачи управления между операторами). Дуга -- это ориентированное ребро.
4. Различают операторные и предикатные узлы. Из операторного узла выходит одна дуга, а из предикатного -- две дуги.
4. Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций (OR, AND).
При структурном тестировании программы используются так называемые структурные критерии, которые базируются на основных элементах графа управления программы: операторах, ветвях и путях.
Пусть вершина управляющего графа (уграфа) имеет три исходящих дуги, помеченных предикатами P1(X), P2(X), P3(X), как на рисунке 10.
Таблица 4 -План структурного тестирования
Структурный анализ управляющих графов программ предполагает, что все объекты, из которых они составлены, прошли автономное тестирование и получили сертификат качества. Это означает, что каждый объект с заданной доверительной вероятностью не содержит ошибок в пределах своей области определения.
Существует два пути возникновения ошибок:
- Неверно организовано управление (неправильный граф программы).
Ошибки неверного употребления данных или организации межмодульного информационного интерфейса в технологии ГСП маловероятны, так как неправильное употребление данных должно быть установлено еще на этапе тестирования акторов, а при автоматической организации межмодульного информационного интерфейса ошибки такого рода исключены.
Значит, при тестировании в технологии ГСП необходимо проверять корректность графа управления вычислительным процессом, а также полноту и непротиворечивость используемых предикатов.
Рассмотрим условия ситуации естественного развития как частный случай некорректности графа управления.
Естественное развитие - запланированный режим работы вершины
ветвления. В данном случае производится проверка на существование
данных при которых управление переда?тся по одному из
перечисленных направлений. В данном случае это
Формальная модель анализа уграфа программы основывается на исчислении предикатов первого порядка с сигнатурой, включающей отношения порядка. Это означает, что при построении предикатов используются алгебраические выражения, содержащие отношения порядка (<, >, =, ><, <=, >=).
При переходе от логических функций к множествам логические функции естественным образом заменяются на теоретико-множественные операции пересечения, объединения и дополнения. Поскольку предлагаемая формальная модель анализа уграфов
основывается на теоретико-множественном анализе, то все логические выражения необходимо заменить на соответствующие операции на множествами.
Алгоритм метода структурного тестирования управляющих графов программы:
1. Записать исходное логическое выражение (проверяемый предикат).
2. Представить исходный предикат посредством базовых предикатов.
3. Заменить логические операции на теоретико-множественные.
5. Записать решающую функцию для заданного в пункте 3 множества.
6. Для нахождения значений истинности сложного логического выражения применяется алгоритм оптимизации функции многих переменных, а задачу тестирования структуры программы сводится к оптимизационной задаче поиска минимума.
7. Если минимум функции меньше единицы, то логическое выражение выполняется хотя бы на одном наборе данных.
Построим теперь решающую функцию. Пусть задана система линейных уравнений:
Необходимо проверить ситуацию естественного развития для первого направления
Ситуация естественного развития для первого направления описывается следующим логическим условием:
Предположим, существует такой Х, что вышеприведенная формула истинна, тогда истинны в отдельности предикаты и , т.е.:
Тогда условие естественного развития для первого направления будет иметь следующий вид:
Тогда, используя теоретико-множественные операции, можно представить данное условие в виде:
Построим решающую функцию для выражений , , введя индикаторные функции:
Рассчитаем данную модель в пакете Matlab. На рисунке 11 представлено изображение решающей функции в виде изолиний.
Рисунок 11 -- Изолинии решающей функции
Из рисунка 2 видно, что существует большое количество точек, для которых решающая функция меньше 1. Следовательно, запирания первого направления нет.
В результате тестирования была изучена формальная модель структурного тестирования с использованием решающей функции. Решающая функция обеспечивает возможность нахождения ошибочных ситуаций с использованием алгоритмов оптимизации. Это гарантирует эффективность данного подхода. Найден вектор значений, удовлетворяющий данной ситуации.
Аналогичным образом проводится исследование ситуаций естественного развития, тупика и конкуренции для каждой вершины графа. Результаты структурного тестирования сведены в таблицу ниже.
Таблица 5 -Результаты структурного тестирования
Для построения множества маршрутов в технологии ГСП применяется алгоритм частичного перебора маршрутов (АЧП). Проверка корректности схем маршрутов логически завершает структурное тестирование агрегатов ГСП и сводится к анализу всех его вычислительных маршрутов. Анализу вычислительных маршрутов предшествует проверка корректности организации ветвлений в вершинах уграфа агрегата. В целом о корректности агрегата судят исходя из полноты покрытия тестами проверяемых маршрутов, т.е. по количеству проверенных маршрутов. Отбор конечного числа тестов, используемых при тестировании ПП, обычно основывается на наборе правил, следуя которым производится анализ полноты тестирования. В целом набор правил формирует критерий полноты тестирования. Определение подходящего для тестируемой системы критерия полноты является одной из важнейших задач, которую необходимо решать при организации тестирования. Чаще всего критерий полноты использует разбиение всех ситуаций, в которых система должна работать, на классы эквивалентности, интуитивно предполагая, что в эквивалентных ситуациях система работает примерно одинаково. И как следствие, либо в обоих случаях присутствует ошибка, либо, наоборот - ошибки нет. Такие критерии полноты называются критериями тестового покрытия, а полнота тестирования с их помощью измеряется как достигнутое тестовое покрытие -- процент классов эквивалентных ситуаций, используемых в ходе тестирования, по отношению к числу всех классов. Данная метрика основана на простой эвристике -- чем больше неэквивалентных, «существенно различающихся» ситуаций проверено, тем полнее было тестирование, и тем лучше оно отражает реальное качество системы. Предположения, на основании которых выбираются критерии покрытия, могут иметь различную природу. Однако следует помнить, что основу структурного тестирования, ее базу, составляют методы проверки корректности выделенных маршрутов. Изучению этих методов и посвящена данная лабораторная работа.
Алгоритм частичного перебора схем маршрутов
Введем понятие свободных вершин графа. Свободными вершинами графа G относительно схемы маршрута S будем называть вершины графа, не содержащиеся в схеме маршрута S, т.е. L(S) = V(G)\V(S) , где V(G) и V(S) - соответственно вершины графа и схемы маршрута.
Алгоритм частичного перебора использует следующие правила:
1. Вершины графа кодируются символами упорядоченного множества любым способом, но так, чтобы корневая вершина имела наименьший код, а концевые - наибольшие значения.
2. На каждом шаге работы алгоритма для текущего состояния схемы маршрута Si ищется путь на орграфе перехода из последней вершины Si в любую свободную вершину схемы Si.
3. Если переход возможен, то схема маршрута Ї “расширяется” на один символ.
4. Если переход невозможен, то рассматривается следующая вершина списка свободных вершин и так до тех пор, пока не кончится список вершин.
5. Если переход из текущей вершины в любую из свободных вершин (не содержащихся в схеме маршрута) невозможен, то происходит Ї “откат” по схеме маршрута на один символ назад.
6. При достижении концевой вершины алгоритм Ї “откатывает” на один символ назад.
7. Алгоритм завершает свою работу, если список свободных вершин корневой вершины исчерпан.
Схемы маршрутов для данного агрегата
При использовании алгоритма ча стичного перебора были построено 8 схем маршрутов, на их основе составлен план структурного тестирования.Таблица 6 - План структурного тестирования маршрутов
Рассмотрим процесс тестирования маршрутов на примере маршрута 0,2,3,4,6,9,17.
Если учесть, что при проверке вершин ветвлений на стандартный набор ошибочных ситуаций (тупиков, конкуренций, естественного развития), была уже оттестирована каждая из вершин уграфа, то условие реализации маршрута можно записать в виде:
В дальнейшем исследование выражения (1) с технической точки зрения ничем не отличается от использования «решающей» функции для тестирования вершин ветвления уграфа. Для (1) строится «решающая» функция F(X) . Задача проверки маршрута M сводится к оптимизационной задаче Xmin = arg minX F(X).
Если F (Xmin) , то существуют такие сочетания данных предметной области, на которых реализуется тестируемый маршрут. Иначе маршрут не реализуем, и следует организовать поиск ошибки в тестируемой программе.
Следующий шаг - построение решающей функции.
Успешное прохождение по вышеприведенному маршруту выражается следующим предикатом:
Представим выражение через базовые предикаты:
Построим поэтапно решающую функцию для выражения (3):
Исследуем итоговую решающую функцию - для этого произведем оптимизацию этой функции методом деформированных многогранников. Ниже представлены минимальные значения функции с точками, в которых они найдены.
При нескольких экспериментах с различными начальными условиями получилось несколько точек, минимум функций в которых примерно равен единице, например:
В результате оптимизации решающей функции было найдено решение X* = (-1.0757, 1.5126, -0.7090, 0.1108), причем F(X*) = 1, что подтверждает работоспособность алгоритма. На рисунках 2 и 3 в окрестностях найденной точки построены графики решающей функции.
Рисунок 11 - График «решающей функции» F(X)
Рисунок 12 - Изолинии «решающей функции» F(X)
Аналогичным образом исследуется каждый из маршрутов предложенного алгоритма решения кубического уравнения. В результате исследований доказывается реализуемость или нереализуемость маршрутов.
«Решающая функция» обеспечивает возможность нахождения ошибочных ситуаций с использованием алгоритмов оптимизации. Это гарантирует эффективность данного подхода. Результаты тестирования маршрутов с использованием «решающей функции» сведены в таблицу.
Таблица 7 - Результаты структурного тестирования маршрутов
В целом, комплексное тестирование данной программы завершено с положительным результатом. В исследуемой программе обнаружены ошибки, однако их влияние на работу программы невелико, так как проявляются они приблизительно в 3-7% случаев.
В ходе выполнения первого этапа - модульного тестирования - в модуле dZ была выявлена ошибка деления на ноль, возникающая при значениях координаты X, близких к 1021.95444572. Данная ошибка относится к классу ошибок способа обработки аргументов. Возможной причиной ошибки является недостаточная проработка алгоритма, в частности, упущена обработка исключительного случая.
Вторым этапом было проведено структурное тестирование. При исследовании ситуаций тупика из вида изолиний решающих функций можно сделать вывод, что не существует точек, решающая функция для которых будет меньше 1, т.е. ситуация тупика не возникает ни для одного из вершин графа программы. Исследование ситуации естественного развития для вершин графа позволяет заключить, что она наблюдается для каждого модуля, прошедшего тестирование. Однако результаты исследования ситуации конкуренции оказались не такими радужными - для двух вершин был обнаружен конфликт. А значит, исходное предикативное предположение о наличии конкуренции в программе верно, то есть для заданных условий программа работает с ошибками в случаях, описанных указанным тестом.
В ходе выполнения структурного тестирования маршрутов было установлено, что для одного из исследуемых маршрутов существуют такие сочетания данных предметной области, на которых маршрут не реализуется.
Неразрешимость проблемы тестирования программного обеспечения. Виды и уровни тестирования. Стратегии восходящего и нисходящего тестирования. Методы "белого" и "черного" ящика. Автоматизированное и ручное тестирование. Разработка через тестирование. курсовая работа [112,2 K], добавлен 22.03.2015
История развития и виды тестирования программного обеспечения. Инсталляционное, регрессионное, конфигурационное, интеграционное, локализационное, модульное тестирование. Методы сокращения трудоемкости модульного тестирования разрабатываемого приложения. курсовая работа [309,5 K], добавлен 16.12.2015
История возникновения тестирования программного обеспечения, основные цели и особенности его проведения. Виды и типы тестирования, уровни его автоматизации. Использование и исследование необходимых технологий. Полный цикл прогона всей системы мониторинга. дипломная работа [1,7 M], добавлен 03.05.2018
Изучение различных видов тестирования программного обеспечения. Выявление в программной системе скрытых дефектов до того, как она будет сдана заказчику. Тестирование методом черного ящика. Требования, предъявляемые к процессу тестирования больших систем. курсовая работа [3,0 M], добавлен 19.11.2009
Тестирование как составляющая часть процесса отладки программного обеспечения, его роль для обеспечения качества продукта. Обнаружение ошибок в программах, выявление причин их возникновения. Подходы к формулированию критериев полноты тестирования. курсовая работа [1,6 M], добавлен 20.12.2012
Описание исходных текстов программного продукта. Системные требования и установка программного продукта. Тестирование пользователя по двадцати вопросам указанной темы и сохранение результатов тестирования. Форма отображения результатов тестирования. курсовая работа [2,8 M], добавлен 09.07.2013
Тестирование как процесс выполнения программы с намерением найти ошибки. Шаги программы при тестировании, его оценка и значение. Роль информационных потоков тестирования, оценивания и отладки. Особенности структурного и функционального тестирования. презентация [574,8 K], добавлен 22.03.2014
Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д. PPT, PPTX и PDF-файлы представлены только в архивах. Рекомендуем скачать работу .
© 2000 — 2021
Автоматизация тестирования программного обеспечения курсовая работа. Программирование, компьютеры и кибернетика.
Права И Свободы Реферат
Реферат На Тему Политические Взгляды Бердяева
Лабораторная Работа Строение Корневого Волоска
Дипломная работа: Ценообразование экспортных товаров
Реферат Витамины В Косметологии
Сочинение Я И Обломов Сходства И Различия
Реферат: Простые эфиры. Краун-эфиры. Представления о межфазном катализе. Реакции простых эфиров. Скачать бесплатно и без регистрации
Сочинение по теме Тамильская литература
Доклад: Чем чреват град из космоса
Курсовая работа по теме Гетьманування Івана Мазепи
Контрольная работа по теме Смертная казнь: за и против
Создание Нового Предприятия Реферат
Дипломная работа по теме Відображення завантаженості мережі
Реферат На Тему Инновационная Деятельность Как Объект Управления
Дипломная работа по теме Анализ ипотечного жилищного кредитования в Тверской области и основные направления его совершенствования
Маленькое Сочинение Про Весну
Реферат: Безопасность и теория риска. Скачать бесплатно и без регистрации
Курсовая работа: Устройство ввода информации
Статья На Тему Организационно-Управленческие Детерминанты Правонарушений В Органах Внутренних Дел Украины
Курсовая Техническое Обслуживание И Ремонт
Д.И. Менделеев и значение его деятельности - История и исторические личности реферат
Деформация правовой системы в Нацистской Германии - Государство и право реферат
Средства, влияющие на агрегацию тромбоцитов, свертывание крови и фибринолиз - Медицина презентация