Вы находитесь на странице: 1из 46

Основы объектно-

ориентированного
программирования

Чернойван Василий Александрович


vchernoivan@gmail.com
http://chernoivan.ru/oop/
Проекты
Cистема символьной математики
• Арифметика
• Математические функции
• Тождественные преобразования (раскрытие
скобок, разложение на множители, объединение
показателей степенных ф-й и т. п.)
• Интегрирование и дифференцирование
• Построение графиков
• Импорт/экспорт в TeX и MathML
Редактор анимированных картинок

• Анимация векторных рисунков


• Задание траектории и скорости движения
от времени
• Анимация растровых картинок
• достраивание анимации по “ключевым
кадрам”
Система тестирования
лабораторных работ по ООП
• Взаимодействие с преподавателем
• Написание тестов
• Просмотр работ “вручную” и оценка
• Взаимодействие со студентами
• Загрузка, сборка и прогон кода уведомление
о результатах, публикация результатов
• Тестирование
• функциональное тестирование
• контроль соглашений о кодировании
• контроль сложности кода
• …..
Библиотека ML.NET

• Векторизация входных данных


• Линейные и нелинейные методы ML
(решающие деревья, ближайшие соседи,
метод опорных векторов, логистическая
регрессия и т. п.)
• Нейронные сети
Тестирование
Определения
• Качество ПО — степень, в которой ПО соответствует
требованиям, предъявляемым к нему
• Валидация — определение соответствия работы
программной системы требованиям, предъявляемым к
ней.
• Тестирование – это процесс выполнения программы с
целью обнаружения дефектов
(дефект = невыполнение требования)
• Тест (TestCase, тестовый сценарий, ситуация)
— формальное описание шагов, условий и параметров
необходимых для проверки одного конкретного
требования
• Набор (пакет) тестов (TestSuite) — совокупность тестов
для проверки определенного аспекта поведения системы
Цели тестирования
• Оценка качества
– связь тестирования и качества —
отрицательная, следовательно, нужны
систематическая регистрация и анализ
результатов тестирования чтобы
делать предположения о качестве системы

• Устранение регрессии
– регрессия — свойство программной системы
обнаруживать ранее устраненные дефекты
Классификация
• По целям
– Приемочное (acceptance) — определяем, что новый
функционал/модуль уже работают
– Регрессионное (regression) — проверяем, что не
поломалось то, что работало раньше

• По способу выполнения
– Ручное — тест прочитывается и выполняется
человеком
– Автоматизированное — тест читается и
выполняется специальными инструментами
Классификация
• Системные тесты по типам требований
– Функциональные
– Нефункциональные
• Производительность
• Отказоустойчивость
• Удобство использования (usability)
• Безопасность
Классификация
• По уровню охвата
– Системное (end-to-end) — тестируется система как
таковая.
Источник тестов — спецификации требований к системе
(истории и варианты использования)
– Интеграционное — трестируется взаимодействие
модулей (в т.ч. внешних сервисов, например базы
данных)
Источник тестов — спецификации программных требований —
интерфейсы модулей
– Модульное — тестируется один отдельно взятый
модуль (взаимодействия с внешними подсистемами
заменяются “заглушками” или “эмуляторами”)
Источник тестов — спецификации программных требований —
интерфейс модуля
Принципы
1. Определение. Для того чтобы протестировать
программу, нужно попытаться заставить её
работать неверно

2. Предсказания. У каждого теста должно быть


четкий критерий успеха/неудачи.

3. Независимость тестов. Выполнение каждого


теста не должно зависеть от результатов
выполнения любого другого теста
Принципы
4. Регрессионное тестирование. Любое неудачное
выполнение должно порождать тестовый случай,
который навсегда становится частью тестового
пакета данного проекта.

5. Вручную или автоматически. Баланс между


дорогим и трудоемким ручным тестированием и
сложным автоматическим

6. Интеграционные или модульные. Баланс


между медленными и полнее отражающими
состояние дел интеграционными и быстрыми но
неглубокими модульными.
Практики
• Реактивная
– Сначала дефект, потом тест
– Регрессионные тесты

• TDD (Test-Driven-Development)
– Сначала модульный тест, затем код

• BDD (Behavior-Driven-Development)
– Сначала системный тест, затем разработка
Test-Driven-Development
• Определяем (часть) интерфейс тестируемого
класса
• Пишем тест на самый простой случай, ещё
не охваченный тестами
• Убеждаемся, что тест не проходит, по
причине того, что соответствующий код ещё
не написан
• Пишем код, до тех пор, пока весь пакет не
проходит
• Продолжаем с п. 2 или 1
Стратегии (техники) создания
тестов
Существует две большие группы стратегий
– «Черный ящик» — тестируемая подсистема
рассматривается как совокупность «входов» и
«выходов», прчем сведения о внутренней
структуре подсистемы не используются
– «Прозрачный (белый) ящик» — для создания
тестов используется внутренняя структура
системы
Техники создания тестов
– Exhaustive Testing — проверка всех возможных
вариантов входов-выходов

– Error Guessing — пытаемся догадаться, как можно


«сломать» систему

– Equivalence Partitioning — значения входов и


выходов группируются в классы эквивалентности,
внутри которых значения «принципиально не
различаются», с точки зрения логики работы

– Boundary Value Analysis — анализируются и


подвергаются тестированию граничные входные
значения
Техники создания тестов
– Cause/Effect graphing — для уменьшения
количества возможных вариантов строится
граф связей входных и выходных параметров
и используются эвристики для построения
тестов

– State-based — модуль рассматривается как


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

– Pairwise — уменьшаем количество сочетаний


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

– Тестирование это затраты


– Автоматические тесты это код, а значит его
нужно писать, наводить порядок,
поддерживать
Примеры
• Системные функциональное тестирование
https://youtu.be/7eHa6HRCSeg
• Системное нагрузочное тестирование
https://youtu.be/O98Q7ziZeu0
Пример: Рациональные числа
Рациональные числа: классы
эквивалентности

• Целые положительные числа


• Целые отрицательные числа
• Ноль
• Дробные положительные числа
• Дробные отрицательные числа
Test-Driven-Development
• Определяем (часть) интерфейс тестируемого
класса
• Пишем тест на самый простой случай, ещё
не охваченный тестами
• Убеждаемся, что тест не проходит, по
причине того, что соответствующий код ещё
не написан
• Пишем код, до тех пор, пока весь пакет не
проходит
• Продолжаем с п. 2 или 1 до тех пор, пока
удаётся написать тест, который не проходит
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: рациональные числа
Пример: интеграционные тесты
Пример: интеграционные тесты
Пример: интеграционные тесты
Пример: интеграционные тесты
Пример: использования Mock объектов
Пример: использования Mock объектов
Спасибо за внимание.
Вопросы?

Оценить