1.

Основные понятия ООП: Класс, объект, абстракция, полиморфизм, наследование,

инкапсуляция, идентичность;
Класс – это описание множества объектов программирования (объектов) и выполняемых над ними
действий.
Объект – это структурированная переменная, содержащая всю информацию о некотором
физическом предмете или реализуемом в программе понятии.
Абстракция в объектно-ориентированном программировании — это использование только тех
характеристик объекта, которые с достаточной точностью представляют его в данной системе.
Полиморфизм – это свойство, которое позволяет один и тот же идентификатор (одно и то же имя)
использовать для решения двух и более схожих, но технически разных задач.
Наследование. Новый, или производный класс может быть определен на основе уже
имеющегося, или базового класса.
При этом новый класс сохраняет все свойства старого: данные объекта базового класса
включаются в данные объекта производного, а методы базового класса могут быть вызваны для
объекта производного класса, причем они будут выполняться над данными включенного в него
объекта базового класса.
Иначе говоря, новый класс наследует как данные старого класса, так и методы их обработки.
Инкапсуляция данных (от «капсула») – это механизм, который объединяет данные и код,
манипулирующий с этими данными, а также защищает и то, и другое от внешнего вмешательства
или неправильного использования.
Идентичность (уникальность) – это такое свойство объекта, которое отличает его от всех других
объектов
2. Операции, совершаемые над объектом: модификатор, селектор, итератор,
конструктор, деструктор;
Модификаторы доступа позволяют задать допустимую область видимости для компонентов
класса. То есть модификаторы доступа определяют контекст, в котором можно употреблять
данную переменную или метод
Селектор - операция, дающая доступ для определения состояния объекта без его изменения
(операция чтения).
Итератор - операция доступа к содержанию объекта по частям (в определенной
последовательности).
Конструктор - операция создания и (или) инициализация объекта.
Деструктор - операция разрушения объекта и (или) освобождение занимаемой им памяти.

3. Отношения между классами и объектами: наследование, реализация, ассоциация,

композиция, агрегация;
Наследование является базовым принципом ООП и позволяет одному классу (наследнику)
унаследовать функционал другого класса (родительского)
Ассоциация означает, что объекты двух классов могут ссылаться один на другой, иметь некоторую
связь между друг другом
Агрегация — отношение, когда один объект является частью другого. Например, Студент входит
в Группу любителей физики.
Композиция — еще более «жесткое отношение, когда объект не только является частью другого
объекта, но и вообще не может принадлежат еще кому-то. Например, Машина и Двигатель
4. Качество абстракции: зацепление, связность, полнота, достаточность, примитивность;
5. SOLID. Принцип единственной обязанности;
На каждом проекте люди играют разные роли (actor): Аналитик, Проектировщик
интерфейсов, Администратор баз данных. Естественно, один человек может играть сразу
несколько ролей. В этом принципе речь идет о том, что изменения в модуле может
запрашивать одна и только одна роль. Например, есть модуль, реализующий некую
бизнес-логику, запросить изменения в этом модуле может только Аналитик, но никак не
DBA или UX.
6. SOLID. Принцип открытости/закрытости;
Например, наше приложение должно отправлять уведомления. Используя dependency
inversion, наш модуль объявляет только интерфейс отправки уведомлений, но не
реализацию. Таким образом, логика нашего приложения содержится в одном dll файле, а
класс отправки уведомлений, реализующий интерфейс — в другом. Таким образом, мы
можем без изменения (перекомпиляции) модуля с логикой использовать различные
способы отправки уведомлений.
7. SOLID. Принцип подстановки Барбары Лисков;
Имеет сложное математическое определение, которое можно заменить
на: Функции, которые используют базовый тип, должны иметь возможность
использовать подтипы базового типа, не зная об этом.
Классический пример нарушения. Есть базовый класс Stack, реализующий
следующий интерфейс: length, push, pop. И есть потомок DoubleStack, который
дублирует добавляемые элементы. Естественно, класс DoubleStack нельзя
использовать вместо Stack.
У этого принципа есть забавное следствие: Объекты, моделирующие сущности,
не обязаны реализовывать отношения этих сущностей. Например, у нас есть
целые и вещественные числа, причем целые числа — подмножество
вещественных. Однако, double состоит из двух int: мантисы и экспоненты. Если бы
int наследовал от double, то получилась бы забавная картина: родитель содержит
2-х своих детей.
В качестве второго примера можно привести Generics. Допустим, есть базовый
класс Shape и его потомки Circle и Rectangle. И есть некая функция Foo(List<Shape>
list). Мы считаем, что List<Circle> можно привести к List<Shape>. Однако, это не
так. Допустим, это приведение возможно, но тогда в list можно добавить любую
фигуру, например rectangle. А изначально list должен содержать только объекты
класса Circle.
8. SOLID. Принцип разделения интерфейсов;
Под интерфейсом здесь понимается именно Java, C# интерфейс. Разделение
интерфейса облегчает использование и тестирование модулей.
9. SOLID. Принцип инверсии зависимостей;
• Модули верхних уровней не должны зависеть от модулей нижних уровней.
Оба типа модулей должны зависеть от абстракций.
• Абстракции не должны зависеть от деталей. Детали должны зависеть от
абстракций.
10. Что такое INVERSION OF CONTROL (IOC);
Inversion of Control, IoC) — важный принцип объектно-ориентированного
программирования, используемый для уменьшения зацепления (связанности) в
компьютерных программах.
11. Что такое DEPENDENCY INJECTION
Внедрение зависимости — процесс предоставления внешней зависимости программному
компоненту.
12. Что такое шаблон проектирования?
Идея, на которой основывается применение шаблонов проектирования, заключается в том, чтобы
выработать стандартизованный подход к представлению общих решений, пригодный для часто
встречающихся ситуаций при разработке ПО.
13. Типы шаблонов: Производящие шаблоны, Поведенческие шаблоны, Структурные
шаблоны
Производящие шаблоны (creational patterns):
o Factory Method (Фабричный метод) – интерфейс для различных
способов порождения объектов;
o Singleton (Одиночка) – единственный экземпляр класса;
 o Abstract Factory (Абстрактная фабрика) – различная реализация
порождения объектов;
o Prototype (Прототип) – класс, из которого создаются объекты
данного класса;
o Builder (Строитель) – способ настройки объекта при создании;
• Поведенческие шаблоны (behavioral patterns):
o Strategy (Стратегия) – способ различной реализации алгоритма;
o Iterator (Итератор) – способ обхода элементов без деталей
внутренней реализации;
o Command (Команда) – способ передачи функциональности в виде объекта; o
Observer (Наблюдатель) – способ реакции множества объектов на событие
в другом объекте;
o Template Method (Шаблонный метод) – способ изменения поведения;
o Visitor (Посетитель) – способ выполнения операции над
множеством объектов.
o State (Состояние) – способ изменения поведения объекта в зависимости
от состояния;
o Chain of responsibility (Цепочка обязанностей) – позволяет
обрабатывать запрос одному или нескольким объектам;
• Структурные шаблоны (structural patterns):
o Adapter (Адаптер) – преобразует интерфейс класса в другой интерфейс; o
Composite (Компоновщик) – группирует объекты в древовидные
системы представляя иерархию часть-целое;
o Facade (Фасад) - предоставляет унифицированный интерфейс к
множеству интерфейсов;
o Decorator (декоратор) – динамически возлагает на объект новые функции;
o Proxy (заместитель) – подменяет один объект другим;

14. Factory Method, Abstract Factory

15. Singleton

16. Builder
17. Prototype

18. Iterator
19. Command

20. Observer
21. Template Method

22. Visitor
23. Chain of responsibility

24. Mediator

25. Adapter
26. Composite

27. Decorator
28. Facade

29. Proxy
30. Что такое автономный тест?
Автономный тест – это часть кода (обычно метод), которая вызывает другую часть кода и затем
проверяет правильность некоторых предположений. Если предположения не подтверждаются,
считается, что автономный тест завершился неудачно. Автономной единицей (unit) является
метод или функция.
31. Что такое «единица работы»? Какие формы может иметь конечный результат
единицы работы?
Единица работы — это совокупность действий от момента вызова какого-то открытого метода в
системе до единственного конечного результата, заметного тесту системы.
Конечный результат может принимать следующие формы:
• Вызванный открытый метод возвращает значение (т. е. является функцией, возвращающей не
void);
• Существует видимое изменение состояния или поведения системы до и после вызова, которое
можно обнаружить, не опрашивая внутреннее состояние т.е. через открытые методы/свойства и
т.д. (примеры: в систему может войти ранее не существовавший пользователь или, если система
представляет собой конечный автомат, то изменились ее свойства). Данный подход называется
тестирование по состоянию;
• Имеет место обращение к сторонней системе (объекту), над которой у теста нет контроля, и эта
сторонняя система не возвращает никакого значения, либо возвращенное значение системой
игнорируется (пример: обращение к сторонней системе протоколирования, которая была
написана не вами и исходный код которой вам недоступен. Данный подход называется -
тестирование взаимодействий);
• Создано управляемое или неуправляемое исключение.
32. Шаблон arrange/act/assert
При написании тестов используется паттерн (шаблон) Arrange/Act/Assert (A/A/A):
• Arrange относится к созданию условий для теста или тестовых объектов;
• Act относится к выполнению теста – тестовые объекты задействуются;
• Assert относится к проверке того, что получен требуемый результат.
33. Преимущества и недостатки модульного тестирования
Модульное тестирование заключается в написании небольших тестов для каждой нетривиальной
функции или метода исходного кода программы в отдельности. Это дает следующие
преимущества:
• Уверенность в работоспособности модулей в отдельности;
• Проверка старой функциональности при внесении новой (регрессионное тестирование);
Регрессионное тестирование – тестирование ранее проверенных функций с целью проверки
отсутствия новых ошибок в программе (регрессии). Регрессией называют одну или несколько
единиц работы, которые когда-то работали, а теперь перестали.
• Спецификация по использованию классов и методов основной программы (косвенная
документация);
• Поощрение изменений и рефакторинга. Уверенность, что после внесения изменений код будет
продолжать работать;
• Архитектурная правильность. Специфика модульного тестирования приводит к тому, что
функции оказываются относительно маленькими (атомарными), а классы слабо зависимы от
других. Дизайн программы базируется на использовании множества сильно связанных
компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование упрощается
34. Что такое внешняя зависимость?
Внешней зависимостью называется объект в системе, с которым тестируемый код
взаимодействует, но над которым у него нет контроля (типичные примеры: файловая система,
потоки, память, время и т. д.).
35. Что такое заглушка в терминах автономного тестирования? Какие бывают виды
заглушек?
Заглушка - управляемая замена существующей зависимости в системе. Используя заглушку, мы
можем протестировать код, не взаимодействуя с зависимостью непосредственно.
Выделяются 3 разновидности заглушек:
• подставные объекты, или подставки (mocks), изменение состояние которых можно
контролировать. Они используются для того, чтобы определить, прошел тест или нет;
• заглушки (stubs) - класс, который мы можем контролировать. Используются, чтобы прошел тест.
Заглушки – вспомогательные объекты для выполнения теста;
• поддельные объекты, или подделки (fakes) – общее название объекта, который может
выступать в обеих ролях
36. Что такое рефакторинг? Примеры
Рефакторинг – изменение части кода, без изменения его функциональности. Как правило, с целью
улучшения. Примером улучшений может быть облегчение понимания кода, либо устранение
дублирования. В основе рефакторинга лежат небольшие эквивалентные изменения (например,
перенос кода в функцию или перенос метода в базовый класс).
37. Что такое каркас тестирования?
Каркас тестирования – набор библиотек, модулей и т.п. помогающий проводить тестирование
кода и обеспечивающий прогон тестов в составе автоматизированной сборки.
38. Что такое разработка через тестирование? Основные принципы, достоинства и
недостатки
Разработка через тестирование (TDD, test-driven development) — техника программирования, при
которой модульные тесты для программы или её фрагмента пишутся до самой программы
(testfirst development) и, по существу, управляют её разработкой.
Основной метод работы:
• Пишется новый код, когда автоматический тест не сработал;
• Удаляется дублирование.

Особенности разработки через тестирование

• Наличие списка тестов как плана разработки (Test List).
• Если в процессе разработки возникает новая идея, то она заносится в todo лист и оформляется в
виде теста (Another Test).
• В тестах используется минимально необходимый и максимально простой набор данных (Test
Data). Например, если для выполнения кода необходимы только 2 поля, то только их следует
инициализировать. При этом отношения между тестовыми данными и результатом должны быть
максимально понятными (Evident Data).
• Каждый тест должен соответствовать одному шагу в направлении к основной цели (One Step
Test).
• Не следует решать несколько задач одновременно. Необходимо первоначально выбирать такой
тест, который позволит решать только одну задачу, на время абстрагировавшись от других (Starter
Test).
• Использование дополнительных объясняющих тестов (Explanation Test).
• Написание тестов даже на сторонние библиотеки с целью проверки возможностей (Learning
Test).
• В случае обнаружения ошибок в уже существующем коде, сначала пишется тест, выявляющий
дефект, затем дефект устраняется (Regression Test).
• Операция над объектами коллекций отдельно реализуется над одним объектом, а затем над
остальными (One to Many).

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

• Существуют задачи, которые невозможно (по крайней мере, на текущий момент) решить только
при помощи тестов. Например, взаимодействие между процессами.
• Разработку через тестирование сложно применять в тех случаях, когда для тестирования
необходимо прохождение функциональных тестов. Требуется использование mockобъектов для
представления внешнего мира.
• Требуется больше времени на разработку и поддержку.
• Модульные тесты, создаваемые при разработке через тестирование, обычно пишутся теми же,
кто пишет тестируемый код. Если разработчик неправильно истолковал требования к
приложению, то и тест, и тестируемый модуль будут содержать ошибку.
• Большое количество используемых тестов могут создать ложное ощущение надежности,
приводящее к меньшему количеству действий по контролю качества.
• Тесты сами по себе являются источником накладных расходов. Плохо написанные тесты,
например, содержат жёстко вшитые строки с сообщениями об ошибках или подвержены
ошибкам, дороги при поддержке. Чтобы упростить поддержку тестов, следует повторно
использовать сообщения об ошибках из тестируемого кода.
• Уровень покрытия тестами, получаемый в результате разработки через тестирование, не может
быть легко получен впоследствии. Исходные тесты становятся всё более ценными с течением
времени. Если неудачные архитектура, дизайн или стратегия тестирования приводят к большому
количеству не пройдённых тестов, важно их все исправить в индивидуальном порядке. Простое
удаление, отключение или поспешное изменение их может привести к не обнаруживаемым
пробелам в покрытии тестами
39. Что такое тестирование? Что такое отладка?
Тестирование – выполнение программы с целью обнаружения факта наличия в программе
ошибок.
Отладка – определение местоположения ошибок и внесение исправлений в программу.
40. Принципы тестирования
• Ошибки в программе есть;
• Тест – это совокупность исходных данных и ожидаемых результатов;
• Тестовые данные должны быть достаточно просты для проверки;
• Тесты готовятся заранее, до выхода на машину;
• Тесты разрабатываются после задания на разработку программы, до написания программного
кода (первые тесты);
• Перед началом тестирования должны быть сформулированы цели, которые должны быть
достигнуты в результате тестирования;
• В процессе тестирования необходимо фиксировать выполненные тесты и реально полученные
результаты;
• Тесты должны быть одинаково тщательными как для правильных, так и для неправильных
входных данных;
• Необходимо проверить два момента: программа делает то, что должна, и не делает того, чего
не должна;
• Результаты теста необходимо изучать досконально и объяснять полностью;
• Недопустимо ради упрощения тестирования изменять программу;
• После исправления программы требуется повторное тестирование;
• Ошибки «кучкуются».
41. Критерии «Черного ящика»
Критерии «Черного ящика»
1. Тестирование функций (требуется подобрать такой набор тестов, чтобы был выполнен хотя бы
один тест для каждой из функций);
2. Тестирование классов входных данных (разделить их на классы таким образом, чтобы все
данные из одного класса были равнозначны с точки зрения проверки правильности программы);
3. Тестирование классов выходных данных (аналогично предыдущему); Три этих критерия хорошо
согласуются друг с другом.
4. Тестирование области допустимых значений;
a. если ОДЗ представляет собой простое перечисление, то проверяется правильность
обработки каждого из этих значений и невозможность ввести вместо них иные значения;
b. если ОДЗ – диапазон, то можно выделить три случая:
i. нормальное условие в середине класса;
ii. граничные экстремальные условия;
iii. исключительные условия выхода за границы класса.
5. Тестирование длинны набора данных (проверяется допустимое количество элементов в
наборе):
a. Пустой набор;
b. Единичный набор;
c. Если предусмотрена минимальная допустимая длина, то проверяется слишком короткий
набор;
d. Набор минимально возможной длины;
e. Нормальный набор;
f. Набор из нескольких частей;
g. Набор максимально возможной длины;
h. Слишком длинный набор;
6. Тестирование упорядоченности (сортировка и поиск);
a. данные не упорядочены;
b. упорядочены в прямом порядке;
c. упорядочены в обратном порядке;
d. существуют повторяющиеся значения;
e. экстремальные значения находятся в середине набора;
f. экстремальные значения находятся в начале набора;
g. экстремальные значения находятся в конце набора;
h. существует несколько совпадающих экстремальных значений.
42. Критерии «Белого ящика»
1. Критерий покрытия операторов (необходимо подобрать такой набор тестов, чтобы каждый
оператор был выполнен хотя бы один раз);
2. Критерий покрытия ветвей (подбирается такой набор тестов, чтобы каждая ветвь программы
была выполнена хотя бы один раз);
3. Критерий покрытия путей (подбирается такой набор тестов, чтобы каждый путь в программе
был выполнен хотя бы один раз); Ветвь – условие if, путь – дополнительный цикл.
 4. Критерий покрытия условий (подбирается такой набор тестов, чтобы каждое простое условие в
сложном, получило и значение true, и значение false хотя бы один раз);
5. Критерий покрытия решения условий (подбирается такой набор тестов, чтобы каждая ветвь в
программе была бы пройдена хотя бы один раз, и каждое простое условие получило бы и
значение true, и значение false хотя бы один раз);
6. Критерий комбинаторного покрытия условий (подбирается такой набор тестов, чтобы хотя бы
один раз выполнялась любая комбинация простых условий).
43. Виды тестирования
1. Модульное тестирование (тестируется отдельный модуль в отрыве от основной системы);
2. Интеграционное тестирование (две и более компоненты тестируются на совместимость);
3. Регрессионное тестирование (тестирование системы в процессе ее разработки и
сопровождении на не регресс-изменение системы не ухудшили уже существующую
функциональность. Создаются пакеты регрессионных тестов, которые запускаются с
определенной периодичностью, например в пакетном режиме, связанном с процедурой
постоянно интеграции);
4. Нагрузочное тестирование (тестирование системы на корректную работу с большими объемами
данных. Проверка баз данных на обработку большого объема записей);
5. Стрессовое тестирование (тестирование на устойчивость к непредвиденным ситуациям);
6. Приемочное тестирование (тестирование при приемки заказчиком)