Contents

1. Этапы жизненного цикла программного обеспечения 2

2. Agile-манифест 2
3. Scrum Framework (Роли, артефакты, мероприятия) 3
4. Kanban Method 4
5. Системы управления версиями. Subversion и Git 5
6. Модели ветвления в Git 5
7. Заинтересованные лица / Стейкхолдеры 7
8. Способы спецификации требований 7
9. Пользовательские истории (User Story) 8
10. Очки истории (Story Points) 9
11. Диаграмма сценариев использования (Use case diagram) в UML 9
12. Диаграмма деятельности (Activity diagram) в UML 10
13. Структурный анализ 10
14. Принципы объектно-ориентированной методологии проектирования 11
15. Принципы объектно-ориентированного программирования 11
16. Принципы SOLID 12
17. Диаграмма классов (Class diagram) в UML 12
18. Порождающие шаблоны проектирования 13
19. Поведенческие шаблоны проектирования 14
20. Структурные шаблоны проектирования 14
21. Шаблон Model - View - Presenter (MVP) 14
22. Внедрение зависимостей 15
23. Типы данных в языке C# 15
24. Конструкторы 15
25. Деструкторы 16
26. Методы 16
27. Модификаторы доступа 16
28. Наследование 16
29. Перегрузка методов (конструкторов) 16
30. Перегрузка операторов 16
31. Переопределение методов 16
 32. Свойства 16
33. Интерфейсы 16
34. Абстрактные классы 16
35. Класс object 16
36. Обобщения 16
37. Интерфейс IEnumerable 16
38. События и делегаты 17
39. Рефлексия 17
40. Исключения 17
41. Среда, безопасная к к несоответствию типов данных 17
42. Пространства имен 17
43. Компиляция исходного кода в .NET 17
44. Качество программного обеспечения 17
45. Оценка и контроль качества ПО 18
46. Тестирование программного обеспечения 19
47. Mock & Stub 19
48. Критерии полноты тестирования 19
49. Техника разработки через тестирование 19

1. Этапы жизненного цикла программного обеспечения

• Анализ требований
• Проектирование
• Разработка
• Тестирование
• Эксплуатация и сопровождение

2. Agile-манифест
Мы постоянно открываем для себя более совершенные методы разработки программного
обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря
проделанной работе мы смогли осознать, что:

• Люди и взаимодействие важнее процессов и инструментов.

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
 3. Scrum Framework (Роли, артефакты, мероприятия)
Роли:

• Владелец продукта (Product Owner)

o Определяет функциональность продукта
o Определяет даты релиза и содержимое
o Приоритизирует задачи
o Регулярно общается с пользователями
o Анализирует обратную связь и меняет направление разработки при
необходимости
o Принимает или отклоняет результаты работы
o Ответственнен за прибыль продукта
• Scrum мастер
o Следит за корректным применением принципов Agile и процессов (ритуалов)
Scrum
o Организует работу команды и обеспечивает её всем необходимым
o Защищает команду, несёт ответственность за её эффективность
o Только один человек
• Команда
o Обычно 6-9 человек.
o Кросс-функциональная: разработчики, тестироващики, дезайнеры, etc.
o Взаимозаменяемая
o Самоорганизующаяся
o Фиксированный состав (в ходе спринта)

Артефакты:

• Product Backlog — это приоритезированный список имеющихся на данный момент

бизнес требований и технических требований к системе. 
• Sprint Backlog — содержит функциональность, выбранную Product Owner из Product
Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. 
• Increment — сумма всех выполненных задач из Product Backlog в рамках спринта и
значение инкрементов всех предыдущих спринтов.

Мероприятия:

• Планирование спринта (Sprint planning)

• Ежедневное Scrum-совещание (Daily Scrum) — 3 вопроса за 15 минут:
o Что я сделал с момента прошлой встречи?
o Что я сделаю сегодня?
o Вижу ли я препятствия для себя и команды, которые могли бы затруднить
достижение цели спринта?
• Обзор итогов спринта (Sprint Review)
• Ретроспективное совещание (Sprint Retrospective)
• Обсуждение беклога (Baclog refinement meeting)
 4. Kanban Method

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

Диаграмма выполнения работ в Kanban Method отображает Cycle Time (время на выполнение
одной карточки) и Work In Progress (количество незавершённой работы в момент времени).
 5. Системы управления версиями. Subversion и Git
SVN – централизованная VCS

Git – распределённая VCS

Базовые знания о процессе работы SVN: edit file -> svn add file -> svn commit

Базовые знания о процессе работы Git: edit file -> git add file -> git commit file -> git push

Способы перетащить изменения из отдной ветки в другую в Git:

• git merge
• git rebase
• git cherry-pick

6. Модели ветвления в Git

Git flow

• Ветка develop для полной истории

• Ветка master для урезанной истории
• Каждая новая функциональность разрабатывается в своей feature ветке
 GitHub flow

• Никих develop, release и hotfix веток

• Любая работа (новая функциональность или исправление ошибок) выполняется в
отдельной ветке, порождённая от master

GitLab flow

• Любая работа (новая функциональность или исправление ошибок) выполняется в

отдельной ветке
• Дополнительные ветки для среды тестирования (если нужно)
• Дополнительные ветки для стабильнцх версий (если нужно)
 7. Заинтересованные лица / Стейкхолдеры
Stakeholdet – англ. держатель доли, заинтересованное лицо в проекте.

• Те, кто активно вовлечен в проект и работает в нем.

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

RACI матрица разделения полномочий:

• Responsible – ответственный непосредственно за выполнение работы

• Accountable – подотчетный, такую роль может занимать только один человек на одной
задаче
• Consulted – один сотрудник или группа, с которыми проводятся консультации
касательно задачи и мнения которых должно учитываться
• Informed – сотрудники, уведомляемые о выполнении конкретной задачи

8. Способы спецификации требований

Списки требований:
Достоинства

• Обеспечивает контрольный список требований.

• Обеспечивает договор между заказчиками и разработчиками.
• Для большой системы может обеспечить описание высокого уровня.

Недостатки

• Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие
документы в целом и получить чёткое понимание системы.
• Такие списки требований перечисляют отдельные требования абстрактно, оторванно
друг от друга и от контекста использования (и возможно с противоречиями)
• Эти списки создают ложное чувство взаимопонимания между заинтересованными
лицами и разработчиками.
• Эти списки дают заинтересованным лицам ложное чувство защищённости, что
разработчики должны достигнуть определённых вещей. Однако, из-за природы этих
списков, они неизбежно упускают важные требования, которые будут выявлены позже
в процессе. Разработчики могут использовать новые требования для пересмотра
сроков и условий в их пользу.

Прототипы (Опытные образцы):

Достоинства

• Позволяют представить на что будет похожа система

• Облегчают пользователям принятие проектных решений
• Отлично подходят для пользовательских интерфейсов

Недостатки
 • Сложно объяснить почему нужно время на разработку окончательного продукта
• Зачастую приходится использовать прототип в реальной системе из-за нежелания
начинать всё сначала
• Риск потратить слишком много времени дизайн не оставив запаса на разработку
системы
• Мало полезны для сложной обработки данных

Сценарии использования: см. вопросы «Пользовательские истории» и «Диаграмма сценариев

использования в UML»

9. Пользовательские истории (User Story)

Запись, содержащая

• Один пользователь
• Одно действие
• Одна ценность

Примеры:

• Как, <роль пользователя>,

я бы хотел <что-то сделать>,
<с такой-то целью>
• Для достижения <цель>,
в качечтве <роль пользователя>,
Я бы хотел <функциональность>

Мнемоника INVEST (какой должна быть хорошая история):

• Independent Независимая
• Negotiable Обсуждаемая
• Valuable Ценная
• Estimable Оцениваемая
• Small Маленькая
• Testable Тестируемая
 10. Очки истории (Story Points)
Очки истории это еденица измерения задач, позволяющая сравнить две задачи по сложности
выполнения. Эта оценка не привязана ко времени (если набор задач на 100SP занимает 1000
часов это вовсе не значит что 1SP = 10 ч.) и к конкретному участнику команды

Идея в том, что бы от предсказаний «мы угадаем мелодию за 10 часов» перейти к статистике «мы
угадываем мелодии на 20-25SP каждые 2 недели, давайте построим прогноз из соображений
лучшего и худшего сценариев»:

11. Диаграмма сценариев использования (Use case diagram) в UML

Ключ

евые элементы: актёр / актор (actor) и сценарий использования (use case).

Актёр / Актор — роль, исполняемая внешней сущностью, взаимодействующей с системой.

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

Сценарий использования — еденица функциональности, выполняемой системой в

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

Отношения между акторами: обобщение (generalization)

Отношения между сценариями использования: включение (include), расширение (extend)
 12.

Диаграмма деятельности (Activity diagram) в UML

13. Структурный анализ

Ключевые элементы: принципы и диаграммы построения модели

Методология SADT (Structured  Analysis  and  Design  Technique) является наиболее известной

методикой структурно-функционального моделирования сложных систем (разработана в 1973 г.
Дугласом Россом (D.Ross).
Представляет собой совокупность методов, правил и процедур, предназначенных для построения
функциональной модели системы.

Модель SADT представляет собой серию диаграмм с сопроводительной документацией,

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

Принципы структурного анализа:

● Принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения

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

Диаграммы SADT:

● Диаграмма потоков данных DFD (Data Flow Diagram)

● Диаграмма сущность-связб ERD (Entity-Relationship Diagram)
● Диаграмма переходов состояний STD (State Transition Diagrams)

14. Принципы объектно-ориентированной методологии проектирования

● Абстрагирование — Выделение таких существенных характеристик объектов, которые
отличают его ото всех других объектов и которые четко определяют особенности данного
объекта с точки зрения дальнейшего рассмотрения и анализа. Только существенное для
данной задачи и ничего более. Минимальной единицей абстракции в ООМ является класс.
● Ограничение доступа — Процесс защиты отдельных элементов объекта, не
затрагивающий существенных характеристик объекта, как целого.
● Модульность — Свойство системы, связанное с возможностью декомпозиции на ряд тесно
связанных частей (модулей). Модульность опирается на дискретное программирование
объектов, которые можно модернизировать или заменять, не воздействуя на другие
объекты и систему в целом.
● Существование иерархий — Ранжирование, упорядочивание по некоторым правилам
объектов системы.

15. Принципы объектно-ориентированного программирования

● Абстракция
● Инкапсуляция
● Наследование
 ● Полиморфизм

16. Принципы SOLID

● S - Принцип единственной ответственности (The Single Responsibility Principle)
«Каждый класс выполняет лишь одну задачу.»
● O - Принцип открытости/закрытости (The Open Closed Principle)
«Программные сущности должны быть открыты для расширения, но закрыты для
модификации.»
● L - Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«Объекты в программе должны быть заменяемыми на экземпляры их подтипов без
изменения правильности выполнения программы.»
● I - Принцип разделения интерфейса (The Interface Segregation Principle)
«Много интерфейсов, специально предназначенных для клиентов, лучше, чем один
интерфейс общего назначения.»
● D - Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»

17. Диаграмма классов (Class diagram) в UML

Виды отношений:

Различие между композицией и агрегацией: Приведём наглядный пример. Комната является

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

Пример диаграммы:
 18. Порождающие шаблоны проектирования
Порождающие шаблоны проектирования абстрагируют процесс создания объектов и скрывают
детали создания конкретных объектов.

В данном вопросе рассматриваются:

● Одиночка (Singleton)
● Фабричный метод
● Абстрактная фабрика

Достоинства шаблонов проектирования:

● Готовые конструкции для решения проблем

● Общая номенклатура для одинаковых решений

Недостатки шаблонов проектирования:

● Нарушение принципа DRY: отказ от повторного использования в пользу дублирования

● Соблазн подогнать проблему под шаблон проектирования
● Соблазн попробовать шаблон там, где он не нужен

Недостатки шаблона проектирования Одиночка (Singleton):

● Нарушение принципа Single Responsibility (класс отвечает за какое-то дело и за

собственное время жизни)
o Проблемы с расширяемостью
o Копипаста при создании других синглтонов
● Скрытые зависимости
● Проблемы тестируемостью

19. Поведенческие шаблоны проектирования

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

В данном вопросе рассматриваются:

● Итератор
● Наблюдатель
● Команда
● Состояние

Достоинства шаблонов проектирования:

● Готовые конструкции для решения проблем

● Общая номенклатура для одинаковых решений

Недостатки шаблонов проектирования:

● Нарушение принципа DRY: отказ от повторного использования в пользу дублирования

● Соблазн подогнать проблему под шаблон проектирования
● Соблазн попробовать шаблон там, где он не нужен

20. Структурные шаблоны проектирования

Структурные шаблоны проектирования отвечают на вопрос «как из классов и объектов образуются
более крупные архитектуры».

В данном вопросе рассматриваются:

● Заместитель (Proxy)
● Адаптер (Wrapper)
● Фасад (Facade)

Достоинства шаблонов проектирования:

● Готовые конструкции для решения проблем

● Общая номенклатура для одинаковых решений

Недостатки шаблонов проектирования:

● Нарушение принципа DRY: отказ от повторного использования в пользу дублирования

● Соблазн подогнать проблему под шаблон проектирования
● Соблазн попробовать шаблон там, где он не нужен

21. Шаблон Model - View - Presenter (MVP)

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

Существует несколько подходов реализации MVP, однако здесь и далее речь идёт о подходе
Passive View.
 ● Представление (View) — Отображение данных от модели.
● Модель — бизнес-логика приложения.
● Представитель (Presenter) — Изменение модели и обновление отображения данных.

22. Внедрение зависимостей

Внедрение зависимостей — это способ обработки зависимостей вне зависимого класса, когда
зависимому классу не нужно ничего делать.

23. Типы данных в языке C#

Типы значений:

 Целочисленные типы (byte, sbyte, short, ushort, int, uint, long, ulong)

 Типы с плавающей запятой (float, double)

 Тип decimal

 Тип bool
  Тип char

 Перечисления enum

 Структуры (struct)

Ссылочные типы:

 Тип object

 Тип string

 Классы (class)

 Интерфейсы (interface)

 Делегаты (delegate)

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

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

c. Передача параметров в конструктор наследуемого класса

Дочерний класс наследует все те же свойства, методы, поля, которые
есть в классе-родителе. Единственное, что не передается при
наследовании, это конструкторы базового класса.
d. Статический конструктор
Статический конструктор – это специальный метод статического или нестатического класса.
Необходим для инициализации статических полей. Также используется для вызова статических
методов и однократного выполнения инструкций.
Программист не может вызвать статический конструктор, его вызывает среда выполнения (CLR)
автоматически в двух случаях:
  обращение к статическому члену;
 создание экземпляра нестатического типа со статическими членами.
Программист может лишь изменить реализацию статического конструктора, определив его в
области действия типа.

25. Деструкторы
e. Интерфейс Idisposable
Интерфейс IDisposable объявляет один единственный метод Dispose, в
котором при реализации интерфейса в классе должно происходить
освобождение неуправляемых ресурсов.

f. Конструкция using

Конструкция using оформляет блок кода и создает объект некоторого класса,

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

g. «сборка мусора»
При использовании же ссылочных типов, например, объектов классов, для
них также будет отводиться место в стеке, только там будет храниться не
значение, а адрес на участок памяти в хипе или куче, в котором и будут
находиться сами значения данного объекта. И если объект класса
перестает использоваться, то при очистке стека ссылка на участок памяти
также очищается, однако это не приводит к немедленной очистке самого
участка памяти в куче. Впоследствии сборщик мусора (garbage collector)
увидит, что на данный участок памяти больше нет ссылок, и очистит его.

26. Методы
h. Вызов методов
Если переменные хранят некоторые значения, то методы содержат собой
набор инструкций, которые выполняют определенные действия. По сути
метод - это именованный блок кода, который выполняет некоторые
действия.
i. Передача параметров / аргументов в методы
По умолчанию, в языке программирования C#, аргументы в методы передаются
по значению! Но большинство типов, используемых программистами, являются
всё-таки ссылочными типами, и в результате, в метод попадает копия ссылки,
j. Использование параметров с модификаторами ref и out
Модификатор ref предназначен для указания того, что параметр метода
должен передаваться по ссылке а не по значению. Другими словами, если у
методу нужно принудительно передать аргумент по ссылке, то при
 объявлении метода перед соответствующим формальным параметром
нужно указать модификатор ref.

Модификатор параметра out используется, если необходимо

выполнение двух условий:
 методу не нужно передавать значение;
 метод обязательно должен возвращать значение с помощью параметра.
Модификатор out для параметра с именем param типа type указывается в начале
его объявления

k. Использование переменного количества аргументов

Модификатор params используется для объявления параметра-массива, который
сможет получить некоторое количество аргументов (в том числе и нулевое).
Количество элементов в массиве будет равно числу аргументов, переданных
методу.
l. Возвращение методом значений
Метод может возвращать значение, какой-либо результат. В примере
выше были определены два метода, которые имели тип void. Методы с
таким типом не возвращают никакого значения. Они просто выполняют
некоторые действия.
m. Методы расширения
Методы расширения (extension methods) позволяют добавлять новые
методы в уже существующие типы без создания нового производного
класса. Эта функциональность бывает особенно полезна, когда нам
хочется добавить в некоторый тип новый метод, но сам тип (класс или
структуру) мы изменить не можем, поскольку у нас нет доступа к
исходному коду. 
n. Вызов методов базового класса

Ключевое слово base используется для доступа к членам базового из производного

класса в следующих случаях:

 Вызов метода базового класса, который был переопределен другим методом.

 Определение конструктора базового класса, который должен вызываться при
создании экземпляров производного класса.

Доступ к базовому классу разрешен только в конструкторе, методе экземпляра или

методе доступа к свойству экземпляра.

Использование ключевого слова base в статическом методе является

недопустимым.

o. Ключевое слово this

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

27. Модификаторы доступа

 private: закрытый или приватный компонент класса или структуры. Приватный

компонент доступен только в рамках своего класса или структуры.
 private protected: компонент класса доступен из любого места в своем
классе или в производных классах, которые определены в той же сборке.
 protected: такой компонент класса доступен из любого места в своем классе
или в производных классах. При этом производные классы могут располагаться
в других сборках.
 internal: компоненты класса или структуры доступен из любого места кода в
той же сборке, однако он недоступен для других программ и сборок.
 protected internal: совмещает функционал двух
модификаторов protected и internal. Такой компонент класса доступен из
любого места в текущей сборке и из производных классов, которые могут
располагаться в других сборках.
 public: публичный, общедоступный компонент класса или структуры. Такой
компонент доступен из любого места в коде, а также из других программ и
сборок.

28. Наследование
Предотвращение наследования
Предотвращение наследования с помощью ключевого слова sealed

Проблемы, решаемые наследованием

Проблема круга и элипса

 Как с точки зрения объектно-ориентированного подхода правильно объединить в
единую иерархию два класса - класс Эллипс и класс Окружность:

Унаследовав Эллипс от Окружности?

Или унаследовав Окружность от Эллипса?

Без разницы. Приверженцы обоих подходов рассматривают различные атрибуты

объектов, которых пытаются классифицировать. Но они не рассматривают самого
главного - назначения объектов и цели классификации.

Проблема мноественного наследования

Наиболее очевидная проблема связана с переопределением функций.

Допустим , есть два класса A и B, оба из которых определяют метод doSomething .

Теперь вы определяете третий класс C , который наследуется как от A , так и от B, но
вы не переопределяете метод doSomething .

29. Перегрузка методов (конструкторов)

30. Перегрузка операторов
p. Ограничения при перегрузке операторов
q. Индексаторы
31. Переопределение методов
32. Свойства
33. Интерфейсы
r. Использование интерфейсных ссылок
s. Явная реализация интерфейсов
34. Абстрактные классы
35. Класс object
t. Упаковка и распаковка
36. Обобщения
37. Интерфейс IEnumerable
u. foreach
v. Конструкции yield return и yield break.

38. События и делегаты

39. Рефлексия
w. Класс System.Type и оператор typeof
x. Атрибуты
 40. Исключения
y. Генерация исплючений
z. Обработка исключений
aa. Часто используемые исключения
41. Среда, безопасная к к несоответствию типов данных
42. Пространства имен
bb. Псевдонимы
43. Компиляция исходного кода в .NET

44. Качество программного обеспечения

Качество программного обеспечения это способность программного продукта при
заданных условиях удовлетворять установленным или предполагаемым потребностям
[ISO/IEC 25000:2014].
Основные аспекты:

Характеристики качества:

● Функциональная пригодность
● Уровень производительности
● Совместимость
● Удобство использования
● Надёжность
● Защищённость
● Сопровождаемость
● Переносимость (мобильность)

45. Оценка и контроль качества ПО

Верификация (лат. verum «истинный», facere «делать») обозначает проверку того, что ПО
разработано в соответствии со всеми установленными требованиями к нему или что
очередной этап разработки выполнен в соответствии с ограничениями,
сформулированными на предшествующих этапах. 
Соответствует ли продукт требованиям?

Валидация (лат. validus «здоровый, крепкий, сильный»)— это проверка того, что сам

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

Методы контроля качества:

● Методы и техники, связанные с выяснением свойств ПО во время его работы.

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

46. Тестирование программного обеспечения

Схема процесса тестирования

Уровни тестирования:

● System tests
● Integration tests
● Unit tests

Стратегии тестирования:

● Black box
● White box
● Gray box

47. Mock & Stub

48. Критерии полноты тестирования
● Покрытие операторов
● Покрытие условий
● Покрытие входных данных
● Покрытие требований

49. Техника разработки через тестирование

● Добавить тест
● Запустить тест (убедится, что тест не бесполезен)
● Написать кода чтобы пройти тест
● Запустить тест (убедиться, что тест пройден)
● Рефакторинг кода
● ???
● PROFIT!!!