|
|
@@ -0,0 +1,530 @@
|
|
|
+
Критерии оценивания:
|
|
|
+ oo Выполнены задание первого и второго уровня - удовлетворительно
|
|
|
+ oo Начато задание третьего уровня - хорошо
|
|
|
+ oo Выполнено задание третьего уровня - отлично
|
|
|
+Время выполнения задания - 90 минут
|
|
|
+
|
|
|
+ Примеры заданий первого уровня:
|
|
|
+1. Актуальность автоматизации бизнес-процессов.
|
|
|
+Бизнес-процессы - совокупность последовательных действий, направленных на производство и сбыт продукта, и поддержание нормального функционирования бизнеса.
|
|
|
+Автоматизация бизнес-процессов - это перевод типовых бизнес-задач и стандартных операций под контроль программно-аппаратного комплекса. В результате высвобождаются ресурсы, что позволяет увеличить эффективность компании.
|
|
|
+Преимущества автоматизации бизнес-процессов
|
|
|
+ oo Ускорение обработки информации и упрощение решения повторяющихся задач;
|
|
|
+ oo Автоматизация ручного труда;
|
|
|
+ oo Повышение прозрачности бизнеса;
|
|
|
+ oo Увеличение согласованности работы сотрудников, повышение качества работы;
|
|
|
+ oo Контроль больших объемов информации;
|
|
|
+ oo Уменьшение числа ошибок, повышение точности управления, возможность параллельного выполнения нескольких задач;
|
|
|
+ oo Оперативное принятие решений в типовых ситуациях.
|
|
|
+Этапы автоматизации бизнес-процессов
|
|
|
+1. Определение целей автоматизации
|
|
|
+Прежде чем начать действия по автоматизации процессов бизнеса, необходимо поставить перед собой конкретные стратегические цели. Обдумайте, чего вы хотите достичь, какие задачи вам должна помочь решить автоматизация управления бизнес-процессами. Например, автоматизация бизнес процессов управления снабжением отличается от автоматизации работы с клиентами. Если в первом случае вам надо заняться оптимизацией логистики, прием\отправка груза и т.д., то во втором случае вам необходимо отслеживать другие показатели: звонки, эффективность воронки продаж и т.д.
|
|
|
+2. Формализация бизнес-процессов
|
|
|
+Для описания бизнес-процессов требуется определить, какие в них присутствуют подпроцессы, как движется информация, в какой последовательности выполняются мероприятия, какие есть ограничения и какими ресурсами вы сможете воспользоваться.
|
|
|
+3. Оптимизация бизнес-процессов.
|
|
|
+После разработки модели специалисты анализируют их, чтобы затем перевести из желаемой в реальную. Затем составляется план по достижению заданных целей с использованием процессов. В итоге выстраивается бизнес-процесс, из которого исключены лишние операции и задержки.
|
|
|
+4. Разработка технического задания
|
|
|
+Определяются точные задачи, которые не могут быть решены без участия владельца.
|
|
|
+5. Кодирование информации, разработка должностных инструкций
|
|
|
+Организация, которая занимается внедрением автоматических решений, выполняет кодирование информации. На данном этапе рекомендуется также начать разработку служебных инструкций, чтобы упростить обучение персонала в будущем.
|
|
|
+6. Обучение сотрудников
|
|
|
+Этот этап требуется только тогда, когда структура рабочего процесса изменяется или планируется изменять состав сотрудников.
|
|
|
+7. Опытная эксплуатация
|
|
|
+Оценить продуктивность системы автоматизации можно только одним способом: применить ее на практике. Этот этап поможет отладить рабочий процесс и избежать ошибок.
|
|
|
+Актуальность автоматизации бизнес процессов
|
|
|
+Существует ряд симптомов, которые указывают на необходимость комплексной автоматизации бизнес-процессов (в их числе и процессов снабжения) компании:
|
|
|
+ oo Фирма работает с перебоями, сотрудники не могут координировать действия и выполнять их слаженно;
|
|
|
+ oo В компании имеют место регулярные задержки, искажения и потери информации;
|
|
|
+ oo При выполнении повседневной работы специалисты компании не могут отодвигать собственные интересы на второй план;
|
|
|
+ oo Задачи фирмы выполняются неэффективно, клиентоориентированность развита очень слабо;
|
|
|
+ oo У сотрудников нет четкого понимания того, как их деятельность сказывается на показателях организации;
|
|
|
+ oo Нет явного распределения, кто из сотрудников отвечает за конкретные цели и функции предприятия;
|
|
|
+ oo Отсутствуют временные рамки для выполнения задач;
|
|
|
+ oo Компания не всегда работает в интересах клиентов.
|
|
|
+
|
|
|
+Примеры систем для оптимизации бизнес-процессов:
|
|
|
+ oo Программные продукты 1С
|
|
|
+ oo CRM-системы (позволяют автоматизировать, оптимизировать и анализировать продажи, маркетинг, работу над проектам)
|
|
|
+ oo ERP-системы (позволяют автоматизировать основные процессы в компаниях с помощью одного инструмента: начиная от производства, заканчивая документооборотом и бухгалтерией) - SAP, Oracle, Microsoft
|
|
|
+ oo PM-системы (для автоматизации управления проектами) - Trello, Asana, WEEEK
|
|
|
+2. Инструментальные средства разработки программного обеспечения.
|
|
|
+Инструмента́льное програ́ммное обеспе́чение -- программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ, в отличие от прикладного и системного программного обеспечения.
|
|
|
+Системы программирования
|
|
|
+К этой категории относятся программы, предназначенные для разработки программного обеспечения:
|
|
|
+ oo ассемблеры -- компьютерные программы, осуществляющие преобразование программы в форме исходного текста на языке ассемблера в машинные команды в виде объектного кода.
|
|
|
+ oo трансляторы -- программы или технические средства, выполняющие трансляцию программы.
|
|
|
+ oo компиляторы -- Программы, переводящие текст программы на языке высокого уровня, в эквивалентную программу на машинном языке.
|
|
|
+ oo интерпретаторы -- Программы (иногда аппаратные средства), анализирующие команды или операторы программы и тут же выполняющие их
|
|
|
+ oo компоновщики (редакторы связей) -- программы, которые производят компоновку -- принимают на вход один или несколько объектных модулей и собирают по ним исполнимый модуль.
|
|
|
+ oo препроцессоры исходных текстов -- это компьютерные программы, принимающие данные на входе и выдающие данные, предназначенные для входа другой программы, например, такой, как компилятор
|
|
|
+ oo отла́дчик (debugger) является модулем среды разработки или отдельным приложением, предназначенным для поиска ошибок в программе.
|
|
|
+ oo текстовые редакторы -- компьютерные программы, предназначенные для создания и изменения текстовых файлов, а также их просмотра на экране, вывода на печать, поиска фрагментов текста и т. п.
|
|
|
+ oo специализированные редакторы исходных текстов -- текстовые редакторы для создания и редактирования исходного кода программ. Специализированный редактор исходных текстов может быть отдельным приложением, или быть встроен в интегрированную среду разработки (IDE).
|
|
|
+ oo библиотеки подпрограмм -- сборники подпрограмм или объектов, используемых для разработки программного обеспечения.
|
|
|
+ oo редакторы графического интерфейса.
|
|
|
+Перечисленные инструменты могут входить в состав интегрированных сред разработки
|
|
|
+Виды инструментального ПО
|
|
|
+ oo Текстовые редакторы
|
|
|
+ oo Интегрированные среды разработки
|
|
|
+ oo SDK
|
|
|
+ oo Компиляторы
|
|
|
+ oo Интерпретаторы
|
|
|
+ oo Линковщики
|
|
|
+ oo Парсеры и генераторы парсеров (см. Javacc)
|
|
|
+ oo Ассемблеры⁶
|
|
|
+ oo Отладчики
|
|
|
+ oo Профилировщики
|
|
|
+ oo Генераторы документации
|
|
|
+ oo Средства анализа покрытия кода
|
|
|
+ oo Средства непрерывной интеграции
|
|
|
+ oo Средства автоматизированного тестирования
|
|
|
+ oo Системы управления версиями
|
|
|
+ oo и др.
|
|
|
+Большинство вышеперечисленных средств объединяется в одну оболочку - интегрированную среду разработки (IDE), имеющую графический интерфейс.
|
|
|
+Примеры IDE - Microsoft Visual Studio, Visual Studio Code, DrPython, Eclipse, Intellij IDEA и др.
|
|
|
+3. Интегрированная среда разработки программного обеспечения. Назначение и основные возможности ИСР.
|
|
|
+Интегрированная среда разработки (IDE) - это программное приложение, которое помогает программистам эффективно разрабатывать программный код. Оно повышает производительность разработчиков, объединяя такие возможности, как редактирование, создание, тестирование и упаковка программного обеспечения в простом для использования приложении. Так же как писатели используют текстовые редакторы, а бухгалтеры - электронные таблицы, разработчики программного обеспечения применяют IDE, чтобы упростить свою работу.
|
|
|
+Возможности ИСР:
|
|
|
+ 1. Использование стандартного текстового редактора, предполагающего возможность обработки нескольких файлов различного расширения, созданного специально для работы с исходными кодами;
|
|
|
+ 2. Автоматизированная диагностика ошибок, которые были обнаружены при компиляции (исходный код, открытый для редактирования, выводится параллельно с диагностикой в смежных окнах);
|
|
|
+ 3. Одновременная работа с несколькими самостоятельными или объединяемыми воедино проектами. Менеджер проектов дает возможность использования любого проекта в качестве шаблона;
|
|
|
+ 4. Наименьший показатель перекомпиляции. Данному процессу подвергаются лишь те модули, которые были отредактированы;
|
|
|
+ 5. Загрузка проходящей испытания программы в средства отладки, а также возможность работы отладчика без выхода из оболочки;
|
|
|
+ 6. Широчайшие возможности подключения к оболочке любых совместимых программных средств.
|
|
|
+4. Понятие интеграции программного обеспечения. Цели и назначение интеграции.
|
|
|
+--------------------------------------------------------------------------------
|
|
|
+Интеграция - процесс разработки и внедрения программного обеспечения, с помощью которого отдельные компоненты могут быть связаны в единую систему. Такое объединение позволяет поддерживать бизнес-процессы и оперативно обмениваться информацией.
|
|
|
+--------------------------------------------------------------------------------
|
|
|
+Главная задача процесса - обеспечение безопасного и бесперебойного обмена информацией между программными продуктами, которые изначально не предназначены для совместной работы. Например, программное обеспечение для электронного документооборота между предприятием и его клиентами, организация цепей поставок, ERP-системы, облачные технологии, аналитические модули, системы самообслуживания и т. д.
|
|
|
+--------------------------------------------------------------------------------
|
|
|
+С помощью интеграции программных модулей обеспечивается не только оперативность и автоматизация работы с данными. Решается ряд более широких задач:
|
|
|
+ oo --------------------------------------------------------------------------------
|
|
|
+оперативное внедрение новых программных продуктов в работу предприятия;
|
|
|
+ oo --------------------------------------------------------------------------------
|
|
|
+улучшения качества работы с клиентами;
|
|
|
+ oo --------------------------------------------------------------------------------
|
|
|
+прозрачность процессов;
|
|
|
+ oo --------------------------------------------------------------------------------
|
|
|
+сокращения количества ошибок при обработке данных и т. д.
|
|
|
+5. Транспортные протоколы. Сериализация данных. Основные форматы представления данных для обмена между информационными системами.
|
|
|
+ Транспортные протоколы (коммуникационный протокол, отвечающий за трансляцию данных, передаваемых с помощью установленного соединения):
|
|
|
+ oo TCP;
|
|
|
+ oo UDP;
|
|
|
+ oo SCTP.
|
|
|
+Сериализация - процесс перевода структуры данных, то есть информации в объект удобный для хранения и передачи его, с учетом возможности переопределения кодирования, шифрования (декодирование, дешифрования).
|
|
|
+Стерилизация бывает:
|
|
|
+ oo Бинарная;
|
|
|
+ oo XML;
|
|
|
+ oo SOAP;
|
|
|
+ oo JSON;
|
|
|
+ oo Java serialization;
|
|
|
+6. Понятие репозитория проекта, структура проекта.
|
|
|
+Репозиторий - некоторое хранилище файлов (информации), связанная с некоторым проектом, который разрабатывают несколько людей, помогает организовать совместную работу.
|
|
|
+Именно репозиторий помогает вести учет того, кем и когда внесены изменения в конкретные файлы, помогает определить какие изменения были внесены, и в случае необходимости вернуться к более раннему состоянию продукта.
|
|
|
+Структура проекта представляет собой дерево ориентированных на продукт компонентов представленных оборудованием, работами, услугами и информацией, полученным в результате реализации проекта.
|
|
|
+Структура проекта призвана определить продукцию, которую необходимо разработать или произвести, и связать элементы работы, которую предстоит выполнить, как между собой, так и с конечной цель. проекта. Формирование структуры начинается с разделения целей проекта на значительно меньшие блоки работ, вплоть до достижения самых мелких позиций, подлежащих контролю.
|
|
|
+Структурирование проекта должно включать разделение проекта по следующим признакам:
|
|
|
+ oo Компоненты продукции проекта;
|
|
|
+ oo Этапы жизненного цикла;
|
|
|
+ oo Элементы организационной структуры.
|
|
|
+7. Подходы к управлению версиями программного обеспечения.
|
|
|
+Классификация по расположению репозитория:
|
|
|
+ oo Локальные (Local VCS) - всё находится на компьютере одного человека и он делает свои локальные копии;
|
|
|
+ oo Централизованные (клиент-серверные) (Centralized) - репозиторий проекта хранится на "сервере", к которому имеют доступ несколько компьютеров, пользователи могут отмечать свои изменения;
|
|
|
+ oo Распределённые (Distributed) - история хранится на каждом компьютере в локальном хранилище, и при необходимости отдельные компоненты синхронизируется с аналогичным хранилищем на другом компьютере.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+8. Основные понятия системы контроля версий.
|
|
|
+Система контроля версия (VCS - version control system) - ПО для облегчения работы с изменяющейся информацией, то есть это некоторая система которая фиксирует изменения в некоторый каталог файлов или файл.
|
|
|
+Возможности таких систем:
|
|
|
+ oo Обратимость - возможность вернуться к предыдущему состоянию
|
|
|
+ oo Согласованность - возможность совместной работы с одними и теми же данными в одно и то же время.
|
|
|
+ oo Аннотирование - возможность сохранять метаданные об изменениях, комментарии от автора изменений.
|
|
|
+Базовые операции:
|
|
|
+ oo Получение рабочей копии файлов из репозитория;
|
|
|
+ oo Запись изменений в репозиторий;
|
|
|
+ oo Просмотр истории файлов.
|
|
|
+Фундаментальные термины и понятия (git):
|
|
|
+ oo Рабочая директория - файловая система проекта (те файлы, с которыми совершаются изменения);
|
|
|
+ oo Индекс - список отслеживаемых git-ом файлов и директорий промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов). Ну то есть помеченные специальным идентификационным номером некоторые изменения (коммиты).
|
|
|
+ oo Директория .gti/ - все данные VSC (системы контроля версий) данного проекта, то есть все коммиты, ветки, теги и т.д.
|
|
|
+Указатели:
|
|
|
+::HEAD -- указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
|
|
|
+::ORIG_HEAD -- указатель на коммит, с которого вы только что переместили HEAD (командой git reset ..., например).
|
|
|
+::Ветка (master, develop etc.) -- указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
|
|
|
+::Теги -- простые указатели на коммиты. Не перемещаются.
|
|
|
+9. Совместная разработка ПО. Преимущество использования совместной разработки проектов.
|
|
|
+Участники проекта объединяются за счет технических средств (IDE, систем контроля версий), под общим руководством.
|
|
|
+Можно отследить следующие преимущества:
|
|
|
+ oo Делегирование обязанностей, то есть передача соответствующей работы соответствующим специалистам;
|
|
|
+ oo Экономия времени при разработки;
|
|
|
+ oo Использование нового персонала при необходимости, то есть с новыми персоналом могут внедряться новые технологии;
|
|
|
+ oo Меньшая нагрузка на человека при разработке;
|
|
|
+ oo Совместная деятельность, при которой обсуждаются и модифицируются процессы внутри программы, то есть каждый вносит свою часть уже в готовый код или новый.
|
|
|
+10. Модульный принцип программирования. Особенности, преимущества и недостатки модульной разработки ПО.
|
|
|
+Модульный принцип, подразумевает наличие модулей в программе - логически завершенные фрагменты кода имеющие конкретное функциональное назначение.
|
|
|
+Преимущества:
|
|
|
+ oo Повышение надежности, из-за раздробленности;
|
|
|
+ oo Упрощение тестирования;
|
|
|
+ oo Взаимозаменяемость;
|
|
|
+ oo Ускорение разработки, из-за присутствия конкретики, также можно делегировать разные модули среди персонала;
|
|
|
+ oo Создание библиотек наиболее часто употребляемых модулей;
|
|
|
+ oo Легко сопровождать и модифицировать.
|
|
|
+Недостатки:
|
|
|
+ oo Каждый модуль занимает большой объём памяти, что сказывается на весе программы в ОЗУ или на диске;
|
|
|
+ oo Большая требовательность к времениы ЦП, из-за большого числа модулей (подпрограмм);
|
|
|
+ oo Долгое время выполнения программ;
|
|
|
+ oo Сложная разработка межмодульных интерфейсов;
|
|
|
+ oo Требует тщательное проектирование и четкое представление о структуре программы.
|
|
|
+11. Возможные проблемы интеграции модулей в программный продукт
|
|
|
+К ним скорее всего можно приписать следующие пункты:
|
|
|
+ oo Внедряемый модуль, уже частично реализован в программе, поэтому стоит просто обратиться уже существующему а затем, дописать ту часть которую мы хотим внедрить;
|
|
|
+ oo Модуль может, вызывать баги при контакте с другими модулями;
|
|
|
+ oo Модуль может быть заменен используемыми библиотеками;
|
|
|
+ oo Модуль может потреблять много ресурсов (как времени так и количества памяти).
|
|
|
+12. Подходы к отладке программных продуктов.
|
|
|
+Всего существует несколько методов отладки ПО:
|
|
|
+ oo Ручное тестирование;
|
|
|
+ oo Индукция;
|
|
|
+ oo Дедукция;
|
|
|
+ oo Обратное прослеживание.
|
|
|
+Метод ручного тестирования - самый простой способ, вручную происходит выполнение программы и когда ошибка найдена, необходимо повторить все те же действия, используя тестовый набор.
|
|
|
+Метод индукции - анализ симптомов ошибки, которые могут привести к некорректному сценарию работы программы, и основываясь на предположениях программа подвергается тестированию. При обнаружении ошибок, происходит анализ того фрагмента кода, который скорее всего причастен к появлению данной ошибки. То есть используя этот метод, тэс тестировщик строит свои гипотезы и доказывает их.
|
|
|
+Метод дедукции - формирование множества причин, которые могут вызвать ошибку. Затем происходит анализ причин, исключая те которые противоречат данным, если все причины исключены необходимо провести повторный тест, в противном случае анализируют все гипотезы на наибольшую вероятность и доказывают её.
|
|
|
+В индукции мы имеем дело с ошибками уже, а также имеем дело с одной лишь гипотезой которую мы доказываем. В случае дедукции мы сами должны продумывать, что может пойти не так, строя множество гипотез и выявляя наиболее подходящую.
|
|
|
+Метод обратного прослеживания - эффективно для небольших программ. Начинают с точки вывода неправильного результата, на этом этапе строится гипотеза о том что пошло не так, какие переменные способствовали ошибке и происходит доказательство.
|
|
|
+
|
|
|
+13. Точки останова. Назначение и использование.
|
|
|
+Точка останова (breakpoint) - это специальный маркер, который сообщает отладчику остановить выполнение программы при работе в режиме отладки в точке останова.
|
|
|
+Точки останова нужны для выявления семантических ошибок, для контроля выполнения кода.
|
|
|
+Степпинг (англ. <<stepping>> ) -- это возможность отладчика выполнять код пошагово (строка за строкой). Есть три команды степпинга:
|
|
|
+ oo Команда "Шаг с заходом"
|
|
|
+ oo Команда "Шаг с обходом"
|
|
|
+ oo Команда "Шаг с выходом"
|
|
|
+14. Отладочные классы. Назначение и использование.
|
|
|
+В языке C#, чтобы использовать отладочные классы нужно подключить пространство имен "using System.Diagnostics;". После чего можно использовать методы из класса: "Debug", "Assert" и "Trace".
|
|
|
+Отладочные и трассировочные классы используются для предоставления сведений о производительности приложений во время разработки приложения или после развертывания в рабочей среде.
|
|
|
+То есть при использовании программы в "Debug" можно использовать некоторые методы класса для создания сообщений, помогающих отслеживать последовательность выполнения программы, обнаруживать сбои или предоставлять сведения об измерении производительности, отображается вся информация в специальной среде. Конечно же необходимо знать некоторые методы класса, учитывать прослушивателей и описывать их отображение, также уместно использовать данные классы для создания каких-либо логов и записывать информацию прямо в файл.
|
|
|
+Также возможен сценарий приостановления выполнения кода в нужном месте и изучения состояния приложения.
|
|
|
+15. Подходы к тестированию программных продуктов
|
|
|
+Существует несколько оснований, по которым принято производить классификацию видов тестирования.
|
|
|
+По объекту тестирования
|
|
|
+ oo Функциональное тестирование (functional testing)
|
|
|
+ oo Нагрузочное тестирование (performance/load/stress testing)
|
|
|
+ oo Тестирование удобства использования (usability testing)
|
|
|
+ oo Тестирование интерфейса пользователя (UI testing)
|
|
|
+ oo Тестирование безопасности (security testing)
|
|
|
+ oo Тестирование локализации (localization testing)
|
|
|
+ oo Тестирование совместимости (compatibility testing)
|
|
|
+По знаниям о тестируемой системе
|
|
|
+ oo Тестирование методом <<черного ящика>> (black box)
|
|
|
+ oo Тестирование методом <<белого ящика>> (white box)
|
|
|
+ oo Тестирование методом <<серого ящика>> (grey box)
|
|
|
+По уровню автоматизации
|
|
|
+ oo Ручное тестирование (manual testing)
|
|
|
+ oo Автоматизированное тестирование (automated testing)
|
|
|
+По степени изолированности
|
|
|
+ oo Тестирование методом <<черного ящика>> (black box)
|
|
|
+ oo Тестирование методом <<белого ящика>> (white box)
|
|
|
+ oo Тестирование методом <<серого ящика>> (grey box)
|
|
|
+ oo Модульное тестирование (unit testing)
|
|
|
+ oo Интеграционное тестирование (integration testing)
|
|
|
+ oo Системное тестирование (system testing)
|
|
|
+По уровню готовности
|
|
|
+ oo Альфа-тестирование (alpha testing)
|
|
|
+ oo Бета-тестирование (beta testing)
|
|
|
+ oo Приемосдаточные испытания (acceptance testing)
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+16. Модульное тестирование. Использование тестовых классов.
|
|
|
+--------------------------------------------------------------------------------
|
|
|
+Модульное тестирование (unit testing) -- тесты, задача которых проверить каждый модуль системы по отдельности. Желательно, чтобы это были минимально делимые кусочки системы, например, модули.
|
|
|
+Достоинства модульных тестов:
|
|
|
+ oo Модульные тесты значительно оптимизируют сам процесс тестирования.Тестовые случаи обрабатываются в автоматическом режиме.
|
|
|
+ oo Более высокий уровень контроля качества по сравнению с <<обычным>> ручным тестированием.При автоматизированном тестировании практически исключается возможность пропуска тех или иных тестов.Кроме того решается проблема с описанием тестовых случаев. При написании теста они естественным образом документируются в его коде.
|
|
|
+Недостатки модульного тестирования:
|
|
|
+ oo Модульные тесты это программные сценарии.Тесты являются программами, они не защищены от ошибок
|
|
|
+ oo Написание модульных тестов требует времени.затраты времени на написание тестов становятся сопоставимы с самим процессом разработки.
|
|
|
+ oo Модульные тесты не способны полностью заменить ручное тестирование, и тем более исключить необходимость владения теорией и технологиями тестирования.Модульные тесты не в состоянии заменить такие виды тестирования как, например, исследовательское или тестирование юзабилити.Поэтому, также как и при ручном тестировании, для правильно написания модульных тестов владение соответствующими знаниями и навыками в области тестирования обязательны.
|
|
|
+ oo Применение модульного тестирования требует не только определённой квалификации, но и высокой культуры разработки.Модульные тесты на самом деле довольно тонкий и сложный инструмент. При неправильном использовании, они могут не только оказаться бесполезны, но и навредить процессу разработки.
|
|
|
+В общих чертах модульное тестирование кода выглядит так:
|
|
|
+ 1. Разработчик пишет код конкретной функции -- юнита.
|
|
|
+ 2. Проверяет, чтобы функция была изолирована, то есть не вшита намертво в другие функции. Если вшита -- переписывает её, чтобы вынести.
|
|
|
+ 3. Если функции нужны реакции от других модулей, разработчик создает моки -- заглушки, которые имитируют другие модули и взаимодействие с ними. Например, передают данные, на которые тестируемый юнит должен отреагировать.
|
|
|
+ 4. После этого разработчик пишет тесты и исправляет ошибки.
|
|
|
+ 5. После запускает юнит-тест в режиме покрытия и смотрит, все ли строки функции покрыты, то есть протестированы.
|
|
|
+ 6. В итоге через пару итераций получается хороший протестированный код.
|
|
|
+17. Актуальность использования ручного тестирования программных продуктов.
|
|
|
+Ручное тестирование (manual testing) -- часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно проводится тестировщиками или обычными пользователи путем моделирования возможных сценариев действия пользователя.
|
|
|
+Процесс ручного тестирования:
|
|
|
+ oo Анализ требований. Первым этапом процесса ручного тестирования является анализ требований клиентов к приложению.
|
|
|
+ oo Планирование тестирования. Как только вы поймете требования, следующим шагом будет планирование того, как должны выполняться тесты.
|
|
|
+ oo Создание тестового набора. На этом этапе тестировщик должен придумать сценарии и создать тестовые наборы для требований.
|
|
|
+ oo Выполнение теста. Когда у тестировщика есть требования, он может начать выполнять тесты, чтобы проверить наличие ошибок в функциях.
|
|
|
+Виды тестирования:
|
|
|
+ oo Тестирование белого ящика (White box)
|
|
|
+При тестировании <<белого ящика>> тестировщик обеспокоен тем, что происходит в коде, написанном для этой конкретной функциональности.
|
|
|
+ oo Тестирование черного ящика (Black box)
|
|
|
+Обычно термин <<черный ящик>> используется, когда нет сведений о внутренней работе системы, и вы просто проверяете вывод на основе ввода.
|
|
|
+ oo Тестирование серого ящика
|
|
|
+Это стратегия отладки программного обеспечения, при которой тестировщик имеет ограниченные знания о внутренних деталях или реализациях программы.
|
|
|
+ oo Тестирование дыма
|
|
|
+тип метода анализа программного обеспечения, который обеспечивает работу всех жизненно важных функций приложения, не вдаваясь в подробности
|
|
|
+ oo Кроссбраузерное тестирование
|
|
|
+кроссбраузерное тестирование означает тестирование веб-сайтов или приложений в нескольких браузерах.
|
|
|
+ oo Приемочное тестирование
|
|
|
+Приемочное тестирование проводится для того, чтобы убедиться, что функциональность программного обеспечения соответствует потребностям и требованиям заказчика
|
|
|
+ oo Бета-тестирование
|
|
|
+Это тип пользовательского приемочного тестирования, при котором приложение отправляется группе конечных пользователей, которые используют его в реальных условиях и оставляют отзывы
|
|
|
+ oo Отрицательное (негативное) тестирование
|
|
|
+Отрицательное тестирование -- это тип тестирования, которое выполняется в системе путем ввода неверных данных
|
|
|
+Актуальность: данное тестирование, в отличие от других, проверяет человеческий фактор: соответствие желаниям заказчика, работа с некорректно введенными данными и т.д.
|
|
|
+18. Интеграционное тестирование. Особенности и актуальность применения
|
|
|
+Интеграционное тестирование - это тип тестирования, при котором программные модули объединяются логически и тестируются как группа. Как правило, программный продукт состоит из нескольких программных модулей, написанных разными программистами. Целью нашего тестирования является выявление багов при взаимодействии между этими программными модулями и в первую очередь направлен на проверку обмена данными между этими самими модулями.
|
|
|
+Зачем оно нужно:
|
|
|
+Каждый программный модуль проходит отдельные этапы тестирования (модульное тестирование), но не смотря на это, дефекты могут оставаться по ряду причин:
|
|
|
+ oo Поскольку, как правило, модули разрабатываются разными специалистами, их понимание и логика программирования могут отличаться. Тут интеграционное тестирование становится необходимым для проверки взаимодействия модулей между собой.
|
|
|
+ oo Во время разработки модуля заказчики часто меняют требования, и если у вас сжатые сроки требования могут попросту не успеть пройти модульное тестирование, и, следовательно, системная интеграция может пройти с помехами. Опять получается, что от интеграционного тестирования не убежать.
|
|
|
+ oo Интерфейсы программных модулей с базой данных могут быть ошибочными
|
|
|
+ oo Внешние аппаратные интерфейсы, если таковые имеются, могут быть ошибочными
|
|
|
+ oo Неправильная обработка исключений может вызвать проблемы.
|
|
|
+Стратегии интеграционного тестирования:
|
|
|
+ oo Подход Большого взрыва
|
|
|
+Здесь все компоненты собираются вместе, а затем тестируются.
|
|
|
+ oo Инкрементальный подход
|
|
|
+В данном подходе тестирование выполняется путем объединения двух или более логически связанных модулей. Затем добавляются другие связанные модули и проверяются на правильность функционирования. Процесс продолжается до тех пор, пока все модули не будут соединены и успешно протестированы.
|
|
|
+Поэтапный подход, в свою очередь, осуществляется двумя разными методами:
|
|
|
+ oo Снизу вверх
|
|
|
+ oo Сверху вниз
|
|
|
+Заглушка и драйвер:
|
|
|
+Инкрементальный подход осуществляется с помощью фиктивных программ, называемых заглушками и драйверами. Заглушки и драйверы не реализуют всю логику программного модуля, а только моделируют обмен данными с вызывающим модулем.
|
|
|
+Заглушка: вызывается тестируемым модулем.
|
|
|
+Драйвер: вызывает модуль для тестирования.
|
|
|
+ oo Интеграция <<снизу вверх>>
|
|
|
+В восходящей стратегии каждый модуль на более низких уровнях тестируется с модулями более высоких уровней, пока не будут протестированы все модули. Требуется помощь драйверов для тестирования
|
|
|
+ oo Интеграция <<сверху вниз>>
|
|
|
+При подходе <<сверху вниз>> тестирование, что логично, выполняется сверху вниз, следуя потоку управления программной системы. Используются заглушки для тестирования.
|
|
|
+ oo Сэндвич (гибридная интеграция)
|
|
|
+Эта стратегия представляет собой комбинацию подходов <<сверху вниз>> и <<снизу вверх>>. Здесь верхнеуровневые модули тестируются с нижнеуровневыми, а нижнеуровневые модули интегрируются с верхнеуровневыми, соответственно, и тестируются. Эта стратегия использует и заглушки, и драйверы.
|
|
|
+19. Виды и актуальность разработки тестовой документации.
|
|
|
+Виды документации:
|
|
|
+ oo Политика качества (Quality policy): отражает видение компании в отношении производства и поставки качественного продукта;
|
|
|
+ oo Политика тестирования (Test policy): документ высокого уровня, в котором описаны принципы, методы и все важные цели тестирования в организации;
|
|
|
+ oo Стратегия тестирования (Test strategy): статический документ документ высокого уровня (high-level), обычно разрабатываемый менеджером проекта (project manager). Это документ, который отражает подход к тестированию продукта и достижению целей. Обычно он выводится из Спецификации бизнес-требований (BRS - Business Requirement Specification). На основе стратегии тестирования готовится План тестирования;
|
|
|
+ oo План тестирования (Test plan): документ, который содержит план всех действий по тестированию, которые необходимо выполнить для получения качественного продукта. План тестирования является производным от описания продукта (Product Description), SRS (Software requirements specification) или сценариев использования (Use Case) для всех будущих действий проекта. Обычно его готовит руководитель тестирования или менеджер по тестированию (Test Lead or Test Manager);
|
|
|
+ oo Отчет об оценке усилий (Effort Estimation Report): в этом отчете группы тестирования оценивают усилия для завершения процесса тестирования;
|
|
|
+ oo Сценарий тестирования (Test Scenario): элемент или событие программной системы, которое может быть проверено одним или несколькими тестовыми случаями;
|
|
|
+ oo Тестовый набор/комплект (Test Suite): "Комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего." (ISTQB). Некоторый набор формализованных Test case, объединенных между собой по общему логическому признаку;
|
|
|
+ oo Тестовый случай/пример (Test case): набор положительных и отрицательных исполняемых шагов тестового сценария, который имеет набор предварительных условий, тестовых данных, ожидаемого результата, пост-условий и фактических результатов;
|
|
|
+ oo Чек-лист (Check List): перечень формализованных Test case в упрощенном виде удобном для проведения проверок, часто только список из заголовков кейсов;
|
|
|
+ oo Матрица прослеживаемости требований (Requirements Traceability Matrix): документ, который соотносит требования с тестовыми примерами;
|
|
|
+ oo Тестовые данные (Test Data): "данные, которые существуют (например, в базе данных) на начало выполнения теста и влияют на работу, или же испытывают влияние со стороны тестируемой системы или компонента." (ISTQB). "Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования." (ГОСТ 56920)
|
|
|
+ oo Отчет о дефектах (Defect Report): цель документа заключается в том, чтобы зафиксировать факт ошибки и передать разработчикам подробную информацию о ней;
|
|
|
+ oo Отчет о выполнении теста (Test Execution Report): содержит результаты тестирования и сводку действий по выполнению тестов;
|
|
|
+ oo Сводный отчет о тестировании (Test summary report): представляет собой документ высокого уровня, в котором резюмируются проведенные действия по тестированию, а также результаты тестирования;
|
|
|
+ oo Графики и метрики (Graphs and Metrics): предназначены для мониторинга и управления процессом и продуктом. Это помогает без отклонений вести проект к намеченным целям. Метрики отвечают на разные вопросы. Важно решить, на какие вопросы вы хотите получить ответы;
|
|
|
+ oo Отчет о тестовых инцидентах (Test incident report): содержит все инциденты, разрешенные или неразрешенные, обнаруженные во время тестирования;
|
|
|
+ oo Отчет о завершении тестирования (Test closure report): содержит подробный анализ обнаруженных ошибок, удаленных ошибок и несоответствий, обнаруженных в программном обеспечении;
|
|
|
+ oo Отчет о статусе тестирования (Test status report): предназначен для отслеживания статуса тестирования. Его готовят периодически или еженедельно. В нем указаны работы, выполненные до настоящего времени, и работы, которые еще не завершены;
|
|
|
+ oo Еженедельный отчет о статусе (менеджер проекта для клиента): Weekly status report похож на отчет о статусе тестирования, но генерируется еженедельно;
|
|
|
+ oo Отчет об улучшении (?Enhancement report): описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя;
|
|
|
+ oo Запрос на модификацию (Modification Request): запрос клиента на изменение существующей функциональности;
|
|
|
+ oo Примечания к выпуску (Release Note): примечания к выпуску будут отправлены клиенту, заказчику или заинтересованным сторонам вместе со сборкой. Он содержит список новых выпусков, исправления ошибок;
|
|
|
+ oo Руководство по установке / настройке (Installation/configuration guide): это руководство помогает установить или настроить компоненты, из которых состоит система, и ее аппаратные и программные требования;
|
|
|
+ oo Руководство пользователя (User guide): это руководство помогает конечному пользователю понять как пользоваться продуктом;
|
|
|
+ oo Различные документы требований
|
|
|
+Тестовая документация нужна, чтобы:
|
|
|
+ oo видеть уровень покрытия проекта тестами, не забывая про функционал;
|
|
|
+ oo быстро привлечь к работе новые кадры, если тестировщик внезапно покидает проект - временно или навсегда;
|
|
|
+ oo автоматизировать тестирование: писать скрипты по готовым тест-кейсам куда проще и быстрее.
|
|
|
+20. Исключительные ситуации в работе программы. Основные виды и причины возникновения.
|
|
|
+Исключительные ситуации (exceptions) - события, которые происходят в процессе выполнения программы и нарушают нормальное следование потока выполнения команд. Могут возникнуть во время выполнения программы, прервав ее обычный ход. К ним относится деление на нуль, отсутствие загружаемого файла, отрицательный или вышедший за верхний предел индекс массива, переполнение выделенной памяти и др.
|
|
|
+Виды исключительных ситуаций:
|
|
|
+Исключительные ситуации, возникающие при работе программы, можно разделить на два основных типа: синхронные и асинхронные, принципы реакции на которые существенно различаются.
|
|
|
+ oo Синхронные исключения могут возникнуть только в определенных, заранее известных точках программы. Так, ошибка чтения файла или коммуникационного канала, нехватка памяти -- типичные синхронные исключения, так как возникают они только в операции чтения или в операции выделения памяти соответственно.
|
|
|
+ oo Асинхронные исключения могут возникать в любой момент времени и не зависят от того, какую конкретно инструкцию программы выполняет система. Типичные примеры таких исключений: аварийный отказ питания или поступление новых данных.
|
|
|
+Некоторые типы исключений могут быть отнесены как к синхронным, так и к асинхронным. Например, инструкция деления на ноль формально должна приводить к синхронному исключению, так как логически оно возникает именно при выполнении данной команды, но на некоторых платформах за счет глубокой конвейеризации исключение может фактически оказаться асинхронным.
|
|
|
+21. Назначение и варианты применения исключений, генерируемых пользователем.
|
|
|
+Исключения, представляют собой некоторые сценарии программы, которые останавливают компиляцию программы (то есть, работу) или же не прекращать работу, при этом выдавать сообщения (как пользователю, так и программе).
|
|
|
+Варианты:
|
|
|
+ oo Исправление проблемы, которая вызвала исключение;
|
|
|
+ oo Предпринятие некоторых мер по нейтрализации исключения;
|
|
|
+ oo Поиска альтернативного результата;
|
|
|
+ oo Снова вызвать этот метод, сообщив что необходимо сделать, чтобы не вызвать исключения;
|
|
|
+ oo Завершить работу программы;
|
|
|
+ oo Запись в логи;
|
|
|
+ oo Добавление "безопасности", путем внедрения новых решений;
|
|
|
+ oo Вызвать другие исключения;
|
|
|
+ oo Обработка событий, которые не предусмотрены программой (при написании геометрических, физических, химических и других программ, где есть свои общепринятые правила и аксиомы, которые не стоит нарушать).
|
|
|
+22. Функционал ИСР по обработке исключительных ситуаций.
|
|
|
+IDE , то есть ИСР может обрабатывать следующие ошибки:
|
|
|
+ oo Syntax errors (Ошибки внутри синтаксиса программы);
|
|
|
+ oo Runtime errors (Ошибки выполнения), это так называемые исключения.
|
|
|
+ oo К примеру некорректное приведение типов данных;
|
|
|
+ oo Выход за пределы индекса при переборе данных, которые содержат в себе несколько значений (структуры, листы, enums, массивы и т.д.);
|
|
|
+ oo Часто возникающие исключения связанные с арифметикой;
|
|
|
+ oo И многие другие исключения.
|
|
|
+Многие IDE и синтаксис языка, позволяют нам "отлавливать" данные ошибки, тем самым манипулировать исходом при вызове исключения. В качестве примера во многих языках существует конструкции "try, catch, throw, throws, finally", которые представляют из себя блоки с собственным функционалом.
|
|
|
+Try - блок который, вероятно, может вызывать некоторое исключение.
|
|
|
+Catch - срабатывает в случае, если исключение было вызвано, и нужно выполнить некоторый фрагмент кода.
|
|
|
+Throw/Throws - когда необходимо вызывать собственные исключения.
|
|
|
+Finally - срабатывает в случае когда ошибок не было обнаружено или были обнаружены, грубо говорю в любом сценарии.
|
|
|
+23. Основные виды ошибок в программных продуктах
|
|
|
+Следующие ошибки:
|
|
|
+ oo Логические - ошибка в логической организации программы, то есть не корректный результат;
|
|
|
+ oo Синтаксические - нарушение правил грамматики языка;
|
|
|
+ oo Семантические (нарушается смысл языковых конструкций);
|
|
|
+ oo Взаимодействия - нарушение протокола, обращение к модулю, при передачи информации;
|
|
|
+ oo Компиляционные - ошибки вызванные при компиляции продукта;
|
|
|
+ oo Ресурсные - переполнение максимально допустимого значения, нарушение права доступа;
|
|
|
+ oo Арифметические - при выполнении арифметических операций;
|
|
|
+ oo Среды выполнения - нехватки системных ресурсов;
|
|
|
+24. Инспекция кода. Назначение и особенности применения.
|
|
|
+Инспекция - обсуждение разработчиками изменений в коде проекта. Является одним из наиболее эффективных методов поиска и устранения дефектов программы или разработка новых модификаций повышающая эффективность и т.д.
|
|
|
+Некоторые назначения:
|
|
|
+ oo Улучшение архитектуры кода;
|
|
|
+ oo Некоторое принуждение (психологические) писать код более качественно из-за инспекции своего участка кода;
|
|
|
+ oo Распространение знаний о проекте внутри команды (знакомство с составляющим);
|
|
|
+ oo Обмен опытом между сотрудниками;
|
|
|
+ oo Прорабатывание единственного стиля написания и документирования кода.
|
|
|
+Особенности применения инспекций:
|
|
|
+ oo Четко выраженная цель инспекций;
|
|
|
+ oo Уменьшение количества дефектов, которые были найдены в отделе QA (Quality assurance);
|
|
|
+ oo Удешевление сопровождения (из-за улучшения качества кода);
|
|
|
+ oo Проработка качества и количества тестов;
|
|
|
+ oo Обеспечение совместного владения кодом;
|
|
|
+ oo Обеспечение обмена опытом;
|
|
|
+ oo Совершенствования стиля написания;
|
|
|
+ oo Происходит набор людей, то есть этому мероприятию посвящается отдельное время, которое тратить время на разработку проекта:
|
|
|
+ oo Автор - разработчик кода;
|
|
|
+ oo Инспектор - разработчик ответственный за изменения в код, попадающие в определённый модуль или ветку.
|
|
|
+ oo Наблюдатель - эксперт.
|
|
|
+ oo Происходит изменение во время процесса разработки то есть:
|
|
|
+
|
|
|
+ oo Все время происходит перебор кадров, так как нужны люди для инспекции, которые разбираются в коде и знают о всех изменениях. Что провоцирует что эти люди не будут заниматься своим делом в течении определённого времени (влечёт потерю времени и сил).
|
|
|
+25. Понятие качества программного обеспечения.
|
|
|
+Качество программного обеспечения - это то насколько ПО удовлетворяет предъявляемым к нему требованиям. В качестве требованиях рассматривают стандарты качества (IEEE Standard for Software Quality Metrics Methodology или Quality management and quality assurance), а также ИСО, ГОСТ Р, МЭК.
|
|
|
+В качестве самых часто рассматриваемых характеристик рассматривают:
|
|
|
+ oo Функциональность (Functionality);
|
|
|
+ oo Понятность;
|
|
|
+ oo Тестируемость;
|
|
|
+ oo Надежность (Reliability);
|
|
|
+ oo Защищённость;
|
|
|
+ oo Удобство использования (Usability);
|
|
|
+ oo Эффективность (Efficiency);
|
|
|
+ oo Удобство сопровождения (Maintainability);
|
|
|
+ oo Портативность (Portability), также мобильность.
|
|
|
+26. Инструменты анализа качества программного продукта в среде разработки.
|
|
|
+Подвергать некоторым тестированиям наш продукт:
|
|
|
+ oo Модульное;
|
|
|
+ oo Исследовательское;
|
|
|
+ oo Функциональное;
|
|
|
+ oo Нагрузочное;
|
|
|
+ oo Регрессионное;
|
|
|
+ oo Комплексное;
|
|
|
+ oo Приемочное.
|
|
|
+К примеру использование некоторых собранных шаблонов тестовых проектов в Visual Studio, которые упрощают тестирование и составление тестов:
|
|
|
+
|
|
|
+Подвергать программу так называемому рефакторинга - процессу изменения программной системы таким образом, что ее внешнее поведение не изменяется, а внутренняя архитектура и структура улучшается.
|
|
|
+
|
|
|
+ Примеры заданий второго уровня:
|
|
|
+ 1.Создание репозитория git с использованием командной строки. Добавление файлов и фиксация изменений
|
|
|
+Сначала нужно установить имя и почту, открыв Git Bash в нужной папке:
|
|
|
+
|
|
|
+Затем нужно создать репозиторий с помощью определённой команды:
|
|
|
+
|
|
|
+Можно добавить файл с помощью команды "git add "the name of file" "затем сделать commit "git commit -m "Name Of commit" "
|
|
|
+
|
|
|
+Также есть команды git add *, которая добавляет всё и git commit -am.
|
|
|
+ 2.Добавление проекта программного продукта Visual Studio в систему контроля версий. Подключение проекта к удаленному репозиторию.
|
|
|
+Добавление в локальный репозиторий:
|
|
|
+
|
|
|
+Можно как в локальный:
|
|
|
+
|
|
|
+Так и в удаленный (GitHub):
|
|
|
+
|
|
|
+Так и на созданный вставляя ссылку:
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+ 3. Регистрация пользователя на сервере контроля версий. Настройки личного кабинета.
|
|
|
+Регистрация на Gogs NGK:
|
|
|
+
|
|
|
+ Нажать "Зарегистрируйтесь".
|
|
|
+
|
|
|
+
|
|
|
+Зарегистрироваться на GitHub:
|
|
|
+
|
|
|
+ Sign UP
|
|
|
+
|
|
|
+ Ввести пароль и логин
|
|
|
+ 4. Создание и настройка репозитория на сервере контроля версий
|
|
|
+Для Gogs:
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+На Git:
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+ 5.Создание фиксаций и ветвей в проекте, подключенном к СКВ. Отправка репозитория с проектом на удаленный сервер.
|
|
|
+Создали новый файл, зафиксировали его и отправили на удалённый репозиторий:
|
|
|
+
|
|
|
+Создали новую ветку, изменили файл, сделали коммит и отправили на удалённый репозиторий:
|
|
|
+
|
|
|
+ 6.Клонирование проекта Visual Studio из удаленного репозитория. Синхронизация данных в проектах, подключенных к одному репозиторию.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Или с помощью учетных записей Azure или Git, но первый вариант подходит под любой сценарий и СКВ:
|
|
|
+
|
|
|
+ 7.Создание и настройка организаций и команд разработчиков на сервере контроля версий.
|
|
|
+На GitHub это функция платная, зато можно добавлять в репозитории людей, которые будут участвовать в коллаборации:
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Gogs:
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+ 8.Создание проекта модульного теста. Синхронизация проекта модульного теста и рабочего проекта.
|
|
|
+Нажимаем ПКМ по нашему проекту, в обозревателе решения и делаем также:
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Создаём ссылку у тестового решения и соединяем его с нашим проектом.
|
|
|
+ 9.Добавление тестовых классов и тестовых методов в проект тестирования.
|
|
|
+
|
|
|
+ 10.Использование точек останова в проекте Visual Studio. Выполнение программного кода по шагам.
|
|
|
+
|
|
|
+
|
|
|
+ Если нажать ПКМ.
|
|
|
+
|
|
|
+Как именно можно взаимодействовать после срабатывания точки остановы
|
|
|
+ 11.Использование отладочных классов для вывода отладочной информации в окно отладки.
|
|
|
+
|
|
|
+
|
|
|
+ 12.Добавление консольного окна и текстового файла в слушатели отладочных сообщений.
|
|
|
+
|
|
|
+
|
|
|
+ 13.Вызов отладочных сообщений по условию. Вызов системного окна отладки.
|
|
|
+
|
|
|
+
|
|
|
+Либо помещать в блок If.
|
|
|
+
|
|
|
+ Пример задания третьего уровня:
|
|
|
+В среде разработки Visual Studio реализовать проект, отвечающий следующим требованиям:
|
|
|
+1. Корректная работа функционала поставленной задачи.
|
|
|
+
|
|
|
+2. Наличие отдельного пользовательского класса, содержащего функционал.
|
|
|
+
|
|
|
+3. Наличие проекта модульного теста, содержащего тестовые методы, проверяющие корректность работы функционала.
|
|
|
+
|
|
|
+4. Использование отладочных классов и наличие отладочной информации (с выводом в окно отладки и текстовый файл).
|
|
|
+
|
|
|
+5. Проект должен быть добавлен в систему контроля версий и загружен в удаленный репозиторий. В репозитории должны содержаться фиксации, отражающие процесс реализации функционала.
|
|
|
+
|
