Методические указания. МУ К ПЗ ТРПО ПКС. Методические указания по выполнению практических работ учебной дисциплины мдк 03. 01 Технология разработки программного обеспечения
 Скачать 5.82 Mb.
|
|
Тема 1.4. Моделирование деятельности организации средствами UML Практическое занятие 7. Тема: Разработка диаграммы последовательностей. Цель работы: изучение основ создания диаграмм последовательности на языке UML, получение навыков построения диаграмм последовательности, применение приобретенных навыков для построения объектно-ориентированных моделей определенной предметной области. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия (Л1: р.2, гл.1, п.1.1-1.3 с. 74-87); изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Диаграммы последовательностей описывают взаимодействия множества объектов, включая сообщения, которыми они обмениваются. В отличие от диаграммы классов, на которой изображаются абстрактные элементы в виде классов, на диаграмме последовательностей используются конкретные экземпляры классов – объекты. Объекты отображаются прямоугольником без полей. Для того чтобы подчеркнуть, что это экземпляр абстрактной сущности, название объекта подчеркивается. При необходимости через двоеточие после названия можно указать сущность (класс) экземпляром которой является этот объект. Отметим, что объект может быть экземпляром не только класса, но и других абстракций, например, актера. Обратите внимание, что при указании в качестве классификатора актера изменится графическое обозначение объекта.  На диаграмме последовательностей у объекта может присутствовать линия жизни, на которой отмечаются происходящие с объектом события. Линия жизни отображается пунктирной линией. Между собой объекты могут быть связаны связями. Связь – это экземпляр отношения ассоциация, и имеет такое же графическое обозначение, что и ассоциация. На диаграмме последовательностей объекты обмениваются сообщениями. Сообщение – это спецификация передачи данных от одного объекта другому, который предполагает какое-то ответное действие. Графически сообщение обозначается сплошной линией со стрелкой. Часто операция вызывает какую-либо операцию в объекте. Очевидно, что класс, экземпляром которого является объект, должен иметь такую операцию. Привязка сообщения к операции класса объекта выполняется в свойствах сообщения.  При построении диаграммы классов обычно определяются только основные свойства сущностей, а такие детали, как операции, удобно создавать при построении диаграммы последовательности, для чего в свойствах сообщения UML есть кнопка создания операции. Диаграммы последовательностей, как и другие диаграммы для отображения динамических свойств системы, могут быть выполнены в контексте многих сущностей UML. Они могут описывать поведение системы в целом, подсистемы, класса или операции класса и др. К сожалению, Visio недостаточно гибка в плане поддержки раскрытия содержания отдельных элементов с помощью других диаграмм. Например, кликнув правой кнопкой мыши по классу можно обнаружить, что для его описания можно создать лишь диаграммы классов, состояний и деятельности. Поэтому возможность привязать диаграмму последовательностей к элементу, который она реализует, средствами Visio невозможно, эту связь нужно подразумевать. Диаграммы последовательностей будем делать в контексте прецедентов с диаграммы прецедентов, реализуя те функции, которые должна выполнять наша система. При построении динамических диаграмм используется уже разработанная структура информационной системы. Для диаграммы последовательностей не нужно придумывать объекты, а достаточно определить, экземпляры каких классов участвуют в этом действии. Определив необходимые объекты (как экземпляры классов, так и экземпляры актеров), вторым этапом построения диаграмм последовательностей определяются сообщения, пересылаемые между актерами. Фактически определяется последовательность шагов, для выполнения нужного действия. Порядок выполнения работы Построение диаграммы Последовательности 1. В проводнике по моделям должны отображаться все классы и диаграммы, созданные ранее. Построим диаграмму последовательности для варианта использования «Обеспечить покупателя информацией». Для этого добавим на диаграмму последовательности линии жизни и соотнесем объекты с актерами, инициирующими вариант использования «Обеспечить покупателя информацией», и с необходимыми классами. Для добавления диаграммы последовательности в проект MS Visio выполните следующие действия: 1. В проводнике по моделям найдите ветку «Основной пакет». 2. Нажмите по ней правой кнопкой мыши > Создать … 3. В контекстном меню выберите пункт «Схема последовательностей». Добавим сообщения, которыми обмениваются объекты для исполнения варианта использования. Если объект имеет операцию (посмотреть в практическом занятии №8 «Диаграммы классов» наличие операции у класса, которому принадлежит объект). 1. Из группы фигур «Последовательности UML» добавить три фигуры типа «Линия жизни объекта». Для изменения названия необходимо дважды щелкнуть левой кнопкой мыши по фигуре. Откроется окно свойств объекта и, если в данном файле нет ранее созданных классов, окно создания нового класса. В данном примере необходимо создать три класса «Товар», «Каталог товаров» и «Заказ» и соответственно три объекта с такими же названиями. 2. С помощью поиска фигур найти фигуру «Актер» и добавить ее в рабочую область. Двойным щелчком левой кнопки мыши задать имя «Клиент». 3. Добавить фигуру «Линия жизни» и соедините ее начало с фигурой «Клиент». 4. Протянуть все линии жизни вниз листа. 5. Добавить фигуры «Сообщение» и соединить, руководствуясь следующими принципами: 5.1. Соединить фигурой «Сообщение» линию жизни клиента с линией жизни объекта товар. Двойным щелчком по сообщению открыть окно свойств и выбрать операцию запросить товар. 5.2. Соединить фигурой «Сообщение» линию жизни клиента с линией жизни объекта заказ. Двойным щелчком по сообщению открыть окно свойств и выбрать операцию сформировать заказ. 5.3. Соединить фигурой «Сообщение» линию жизни объекта товар с линией жизни объекта каталог товаров. Двойным щелчком по сообщению открыть окно свойств и выбрать операцию проверить наличие. 5.4. Соединить фигурой «Сообщение (возврат)» линию жизни объекта товар и линию жизни клиента. Двойным щелчком по сообщению открыть окно свойств и задать текст сообщения «Предоставить информацию». 6. Добавить фигуры «Активация» и расположить их на диаграмме.  При построении диаграмм последовательностей можно вносить коррективы в диаграмму классов. Если объект класса получает новую операцию, то она добавляется в соответствующий класс на диаграмме классов как метод. Построим диаграмму последовательности для варианта использования «Согласовать условия оплаты». Действия по построению диаграммы аналогичны построению диаграммы последовательности для варианта использования «Обеспечить покупателя информацией».  Построим диаграмму последовательности для варианта использования «Заказать товар со склада». Действия по построению диаграммы аналогичны построению предыдущих диаграмм последовательностей.  Построим диаграмму последовательности для системы продажи товаров по каталогу.  В соответствии с индивидуальным вариантом, построить диаграммы последовательности. Перечень индивидуальных вариантов приведен в приложении А. Отчет по практическому занятию выполняется в формате MS Word, который содержит экранные формы моделей согласно заданию. Форма отчета: Диаграмма Последовательности с описанием процесса построения диаграммы. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО / Е. А. Черткова. —2-е изд., испр. и доп. — М.: Издательство Юрайт, 2017. — 168 с. — (Серия: Профессиональное образование). - URL://www.urait.ru Раздел 1. Технология разработки программного обеспечения Тема 1.4. Моделирование деятельности организации средствами UML Практическое занятие 8. Тема: Разработка диаграммы классов для автоматизации анализируемого бизнес-процесса организации. Цель работы: изучение основ создания диаграмм классов на языке UML, получение навыков построения диаграмм классов, применение приобретенных навыков для построения объектно-ориентированных моделей определенной предметной области. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы из лабораторной работы №6; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Порядок выполнения работы В соответствии с индивидуальным вариантом, построить диаграмму классов. Перечень индивидуальных вариантов приведен в приложении Б. Отчет по практическому занятию выполняется в формате MS Word, который содержит экранные формы моделей согласно заданию. Форма отчета: Диаграмма Классов с описанием процесса построения диаграммы. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО / Е. А. Черткова. —2-е изд., испр. и доп. — М.: Издательство Юрайт, 2017. — 168 с. — (Серия: Профессиональное образование). - URL://www.urait.ru Раздел 1. Технология разработки программного обеспечения Тема 1.5. Организация процесса тестирования программного обеспечения Практическое занятие 9. Тема: Тестирование и отладка программных модулей средствами MS Studio. Цель работы: ознакомится с методами и видами тестирования ПО и провести тестирование разрабатываемого программного продукта. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, Visual Studio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Тестирование программного обеспечения Тестирование (software testing) – деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах. Тестирование программных систем состоит из динамической верификации поведения программ на конечном (ограниченном) наборе тестов (set of test cases), выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия ожидаемому поведению системы. Сегодня тестирование рассматривается как деятельность, которую необходимо проводить на протяжении всего процесса разработки и сопровождения и является важной частью конструирования программных продуктов. В области знаний “Качество программного обеспечения” (Software Quality) техники управления качеством четко разделены на статические (без выполнения кода) и динамические (с выполнением кода). Обе эти категории важны. Данная область знаний - “Тестирование” – касается динамических техник. Тестирование тесно связано с областью знаний “Конструирование” (Software Construction). Более того, модульное (unit-) и интеграционное тестирование все чаще рассматривают как неотъемлемый элемент деятельности по конструированию. В литературе, посвященной программной инженерии, встречается множество терминов, описывающих нарушение функционирования программных систем – недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др. Соответствующая терминология описана в IEEE Std. 610-90 “Глоссарии терминов по программной инженерии”. Важно четко разделять причину нарушения работы прикладных систем, обычно описываемую терминами недостаток или дефект, и наблюдаемый нежелательный эффект, вызываемый этими причинами – сбой. Термин ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям. Необходимо понимать, что причина сбоя не всегда может быть однозначно определена. Не существует теоретических критериев, позволяющих гарантированно определить какой именно дефект приводит к наблюдаемому сбою. Ключевые вопросы (Key Issues) тестирования ПО: Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования. Эффективность тестирования/Цели тестирования. Тестирование – это наблюдение за выполнением программы, запущенной в целях тестирования с заданными параметрами, по заданному сценарию или с другими заданными начальными условиями или целями тестирования. Эффективность теста может быть определена только в контексте заданных условий. Тестирование для идентификации дефектов. Данный случай тестирования подразумевает успешность процедуры тестирования, если дефект найден. Это отличается от подхода в тестировании, когда тесты запускаются для демонстрации того, что программное обеспечение удовлетворяет предъявляемым требованиями и, соответственно, тест считается успешным, если не найдено дефектов. Проблема оракула. “Оракул”, в данном контексте, любой агент (человек или программа), оценивающий поведение программы, формулируя вердикт - тест пройден или нет. Теоретические и практические ограничения тестирования. Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов. Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения. Проблема неосуществимых путей. Эта сложнейшая проблема автоматизированного тестирования связана с тем, что путь, по которому выполняются потоки работ тестируемой программной системы, не могут быть заданы входными параметрами. Тестируемость. Это понятие может подразумевать две различных идеи. Первая описывает степень легкости описания критериев покрытия тестами для заданной программной системы. Вторая определяет возможность вероятность, возможность статистического измерения того, что при тестировании проявится сбой программной системы. Обе интерпретации этого понятия одинаково важны для тестирования. Уровни тестирования. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий. Модульное тестирование (Unit testing). Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию. Интеграционное тестирование (Integration testing). Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями. Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно- ориентированных архитектурах (SOA). Системное тестирование (System testing). Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п. На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д. Цели тестирования. Тестирование проводится в соответствии с определенными целями (могут быть заданы явно или неявно) и различным уровнем точности. Определение цели точным образом, выражаемым количественно, позволяет обеспечить контроль результатов тестирования. Тестовые сценарии могут разрабатываться как для проверки функциональных требований (известны как функциональные тесты), так и для оценки нефункциональных требований. При этом, существуют такие тесты, когда количественные параметры и результаты тестов могут лишь опосредованно говорить об удовлетворении целям тестирования (например, “usability” – легкость, простота использования, в большинстве случаев, не может быть явно описана количественными характеристиками). Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно, виды) тестирования: Приемочное тестирование. Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, как сторона “принимающая” программную систему, или специфицированы типовые задачи, успешная проверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика. Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них. Установочное тестирование. Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении. Альфа- и бета-тестирование. Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки. Данный вид тестирования не может быть заранее спланирован. Функциональные тесты/тесты соответствия. Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик. Достижение и оценка надежности. Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигаться при использовании моделей повышения надежности. Регрессионное тестирование. Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты. Тестирование производительности. Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения. Нагрузочное тестирование. Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы. Сравнительное тестирование. Единичный набор тестов, позволяющих сравнить две версии системы. Восстановительные тесты. Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster), влияющей на функционирование операционной среды, в которой выполняется система. Конфигурационное тестирование. В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях. Тестирование удобства и простоты использования. Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя. Разработка, управляемая тестированием. По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверке удовлетворения требований программной системой. Техники тестирования. Техники, базирующиеся на интуиции и опыте инженера Специализированное тестирование. Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий. Данный вид тестирования может быть полезен для идентификации тех тестов, которые не охватываются рассматривавшимеся выше более формализованными техниками. Исследовательское тестирование. Такое тестирование определяется как одновременное обучение, проектирование теста и его исполнение. Данный вид тестирования заранее не определяется в плане тестирования и такие тесты создаются, выполняются и модифицируются динамически, по мере необходимости. Эффективность исследовательских тестов напрямую зависит от знаний инженера, формируемых на основе поведения тестируемого продукта в процессе проведения тестирования, степени знакомства с приложением, платформой, типами возможных сбоев и дефектов, рисками, ассоциированными с конкретным продуктом и т.п. Техники, базирующиеся на спецификации Эквивалентное разделение <приложения>. Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор тестов (иногда – только один тест) формируется из тестов эквивалентных классов (или наборов классов). Анализ граничных значений. Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Расширением этой техники являются тесты оценки живучести (robustness testing) системы, проводимые с величинами, выходящими за рамки специфицированных пределов значений. Таблицы принятия решений. Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями (могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице. Тесты на основе конечного автомата. Строятся как комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели (переходов и состояний приложения). Тестирование на основе формальной спецификации. Для спецификации, определенных с использованием формального языка, возможно автоматически создавать и тесты для функциональных требований. В ряде случаев могут строится на основе модели, являющейся частью спецификации, не использующей формального языка описания. Случайное тестирование. В отличие от статистического тестирования, сами тесты генерируются случайным образом по списку заданного набора специфицированных характеристик. Техники, ориентированные на код Тесты, базирующиеся на блок-схеме. Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватность таких тестов оценивается как процент покрытия всех возможных путей блок-схемы. Тесты на основе потоков данных. В данных тестах отслеживается полный жизненный цикл величин (переменных) – с момента рождения (определения), на всем протяжении использования, вплоть до уничтожения (неопределенности). В реальной практике используются нестрогое тестирование такого вида, ориентированное, например, только на проверку задания начальных значений всех переменных или всех вхождений переменных в код, с точки зрения их использования. Ссылочные модели для тестирования, ориентированного на код. Является не только техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода). Тестирование, ориентированное на дефекты Предположение ошибок. Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, в результате анализа рисков. Тестирование мутаций. Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных синтаксических изменений кода (в частности, рефакторинга). Соответствующие тесты запускаются для оригинального и всех “мутировавших” вариантов тестируемой программы. Техники, базирующиеся на условиях использования Операционный профиль. Базируется на условиях использования системы. Тестирование для оценки надѐжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы. Результаты таких тестов позволяют оценить поведение системы в реальных условиях. Входные параметры тестов задаются на основе вероятностного распределения соответствующих параметров или их наборов при эксплуатации (входные данные могут прогнозироваться исходя из частоты возможных сценариев работы пользователей). Тестирование, базирующееся на надежности инженерного процесса. Базируется на условиях разработки системы. Соответствующие тесты (обозначаемые также аббревиатурой SRET) проектируются в контексте используемого процесса разработки и методик тестирования. Техники, базирующиеся на природе приложения Описанные выше техники могут применяться к любым типам программных систем. В то же время, в зависимости от технологической или архитектурной природы приложений, могут также применять специфические техники, важные именно для заданного типа приложения. Среди таких техник: Объектно-ориентированное тестирование Компонентно-ориентированное тестирование Web-ориентированное тестирование Тестирование на соответствие протоколам Тестирование систем реального времени Выбор и комбинация различных техник Функциональное и структурное. Техники тестирования, строящиеся на основе спецификаций или кода часто называют функциональными или структурными, соответственно. Оба подхода не должны противопоставляться, но дополнять друг друга. Определенное или случайное. Обычно тесты можно распределить по данным группам на основе используемой политики выбора или определения входных параметров тестов. Измерение результатов тестирования Часто техники тестирования путают с целями тестирования. Степень покрытия тестами - не то же самое, что высокое качество тестируемой системы. Однако, эти вопросы связаны. Чем выше степень покрытия, чем больше вероятность обнаружения скрытых дефектов. Когда говорят о результатах тестирования, должны подходить к их оценке, как оценке самой тестируемой системы. Измерения являются инструментом анализа качества. Измерение результатов тестирования касается оценки качества получаемого продукта – программной системы. История измерений демонстрирует прогресс достижения приемлемого качества. Такая история является инструментом менеджмента качества. Порядок выполнения работы Разработать чек-лист и тест-кейсы по шаблону, изображенному на рисунке, для тестирования разработанного ПС в соответствии с индивидуальным заданием в Приложении Б. Провести тестирование ПС средствами MS Studio. Оформить результаты тестирования.  Форма отчета: Отчет по практическому занятию в формате MS Word, содержащий тест-кейс и описание действий. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения |