ПМ.03 Ревьюирование программных продуктов

ОСКОЛЬСКИЙ ПОЛИТЕХНИЧЕСКИЙ КОЛЛЕДЖ

Утверждены: решением Учёного совета СТИ НИТУ «МИСиС» от «22» июня 2020 г. протокол № 23

                                                                                    

ПМ.03 Ревьюирование программных продуктов

УП 03. Учебная практика

 

Методические указания

для студентов очной формы обучения

По выполнению практических работ

 

 

(в редакции 2020 г.)

 

Наименование специальности: 09.02.07 Информационные системы и программирование

Год набора: 2018

Квалификация выпускника: специалист по информационным системам

Срок освоения: 3 года 10 месяцев

 

Методические указания составлены в соответствии с рабочей программой ПМ.03 Ревьюирование программных продуктов специальности 09.02.07 Информационные системы и программирование

 

 

Разработчик:

Артюхина Д.Д. – преподаватель ОПК СТИ НИТУ «МИСиС»

 

Рекомендованы:

П(Ц)К специальностей 09.02.04, 09.02.07

протокол № 09 от «20» мая 2020 г.

Председатель П(Ц)К ____________ Назарова О.И.

 

 

Согласованы:

на заседании НМС ОПК

протокол № 05 от «03» июня 2020 г.

Председатель НМС ___________ Дерикот О.В.

 

Содержание

Введение. 4

Практическая работа №1. 7

Ревьюирование части информационной системы для определённого рабочего места 7

Практическая работа №2. 11

Тестирование информационной системы различными способами. 11

Практическая работа №3. 14

Описание выявленных ошибок и способов их устранения. Разработка инструкции по устранению выявленных ошибок информационной системы. 14

Практическая работа №4. 17

Оценка качества и надежности системы по результатам ее исследования. 17

Практическая работа №5. 21

Проведение работ по оптимизации программного кода. 21

Практическая работа №6. 24

Формирование отчетной документации по результатам работ. 24

Список использованных источников. 28

 

 

 

Введение

 

ПМ.03 Ревьюирование программных продуктов является частью программы подготовки специалиста среднего звена в соответствии с ФГОС СПО по специальности 09.02.07 Информационные системы и программирование.

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

В результате освоения профессионального модуля обучающийся должен уметь:

- работать с проектной документацией, разработанной с использованием графических языков спецификаций;

- выполнять оптимизацию программного кода с использованием специализированных программных средств;

- использовать методы и технологии тестирования и ревьюирования кода и проектной документации;

- применять стандартные метрики по прогнозированию затрат, сроков и качества;

- распознавать задачу и/или проблему в профессиональном и/или социальном контексте;

- владеть актуальными методами работы в профессиональной и смежных сферах;

- определять задачи для поиска информации; определять необходимые источники информации;

- определять и выстраивать траектории профессионального развития и самообразования;

- взаимодействовать с коллегами, руководством, клиентами в ходе профессиональной деятельности;

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

- описывать значимость своей специальности;

- определять направления ресурсосбережения в рамках профессиональной деятельности по специальности;

- применять рациональные приемы двигательных функций в профессиональной деятельности;

- применять средства информационных технологий для решения профессиональных задач;

- строить простые высказывания о себе и о своей профессиональной деятельности.

В результате освоения профессионального модуля обучающийся должен знать:

- задачи планирования и контроля развития проекта;

- принципы построения системы деятельностей программного проекта;

- современные стандарты качества программного продукта и процессов его обеспечения;

- основные источники информации и ресурсы для решения задач и проблем в профессиональном и/или социальном контексте;

- алгоритмы выполнения работ в профессиональной и смежных областях; методы работы в профессиональной и смежных сферах;

- номенклатура информационных источников, применяемых в профессиональной деятельности;

- возможные траектории профессионального развития и самообразования;

- основы проектной деятельности;

- правила оформления документов и построения устных сообщений;

- значимость профессиональной деятельности по специальности;

- основные ресурсы, задействованные в профессиональной деятельности;

- условия профессиональной деятельности и зоны риска физического здоровья для

- специальности;

- порядок применения программного обеспечения в профессиональной деятельности;

- лексический минимум, относящийся к описанию предметов, средств и процессов профессиональной деятельности.

Методические указания по выполнению практических работ по ПМ.03 Ревьюирование программных продуктов УП 03 Учебная практика предназначены для обучающихся ­­3 курса специальности 09.02.07 Информационные системы и программирование.

Практические работы проводятся с целью получения практического опыта в области:

- в измерении характеристик программного проекта;

- использовании основных методологий процессов разработки программного обеспечения;

- оптимизации программного кода с использованием специализированных программных средств.

Выполнение обучающимися практических работ направлено на формирование элементов общих компетенций:

ОК 01.       Выбирать способы решения задач профессиональной деятельности, применительно к различным контекстам

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

ОК 03.       Планировать и реализовывать собственное профессиональное и личностное развитие.

ОК 04.       Работать в коллективе и команде, эффективно взаимодействовать с коллегами, руководством, клиентами.

ОК 05.       Осуществлять устную и письменную коммуникацию на государственном языке с учетом особенностей социального и культурного контекста.

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

ОК 07.       Содействовать сохранению окружающей среды, ресурсосбережению, эффективно действовать в чрезвычайных ситуациях.

ОК 08.       Использовать средства физической культуры для сохранения и укрепления здоровья в процессе профессиональной деятельности и поддержания необходимого уровня физической подготовленности

ОК 09.       Использовать информационные технологии в профессиональной деятельности.

ОК 10.       Пользоваться профессиональной документацией на государственном и иностранном языке

       Выполнение обучающимися практических работ направлено на формирование элементов профессиональных компетенций:

ПК 3.1       Осуществлять ревьюирование программного кода в соответствии с технической документацией

ПК 3.2       Выполнять измерение характеристик компонент программного продукта для определения соответствия заданным критериям

ПК 3.3       Производить исследование созданного программного кода с использованием специализированных программных средств, с целью выявления ошибок и отклонения от алгоритма

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

 

 

Практическая работа №1

Задание:

1. Изучить теоретическую часть.

2. Выполнить задание, следуя указаниям.

3. Ответить на контрольные вопросы (в устной форме).

4. Предъявить преподавателю результаты работы программы и исходные коды.

5. Оформить отчет в соответствии с ходом работы (тема, цель, условие задачи, программный код, результаты тестирования программы, выводы).

Теоретические сведения:

Не во всех случаях возможна разработка автоматических или хотя бы четко формализованных ручных тестов для проверки функциональности программной системы. В некоторых случаях выполнение программного кода, подвергаемого тестированию, невозможно в условиях, создаваемых тестовым окружением (например, во встроенных системах, если программный код предназначен для обработки исключительных ситуаций, создаваемых только при установке системы на реальное оборудование). В других случаях верифицируется не программный код, а проектная документация на систему, которую нельзя "выполнить" или создать для нее отдельные тестовые примеры. И в тех и в других случаях обычно прибегают к методу экспертных исследований программного кода или документации на корректность или непротиворечивость.

Такие экспертные исследования обычно называют инспекциями или просмотрами. Существует два типа инспекций – неформальные и формальные.

Формальная инспекция является четко управляемым процессом, структура которого обычно четко определяется соответствующим стандартом проекта. Таким образом, все формальные инспекции имеют одинаковую структуру и одинаковые выходные документы, которые затем используются при разработке.

Факт начала формальной инспекции четко фиксируется в общей базе данных проекта. Также фиксируются документы, подвергаемые инспекции, списки замечаний, отслеживаются внесенные по замечаниям изменения. Этим формальная инспекция похожа на автоматизированное тестирование – списки замечаний имеют много общего с отчетами о выполнении тестовых примеров.

В ходе формальной инспекции группой специалистов осуществляется независимая проверка соответствия инспектируемых документов исходным документам. Независимость проверки обеспечивается тем, что она осуществляется инспекторами, не участвовавшими в разработке инспектируемого документа. Входами процесса формальной инспекции являются инспектируемые документы и исходные документы, а выходами – материалы инспекции, включающие список обнаруженных несоответствий и решение об изменении статуса инспектируемых документов. рис. 1 иллюстрирует место формальной инспекции в процессе разработки программных систем.

Рис.1. Место формальной инспекции в процессе разработки программных систем

 

Выполнение работы:

Задание. Следуя указаниям, создайте программу, которая запрашивает у нового сотрудника имя, фамилию и дату рождения. Вы будете хранить эту информацию в свойствах нового класса с именем Person, и создадите метод класса, который будет вычислять текущий возраст нового сотрудника. Этот проект научит вас создавать собственные классы, экземпляры классов (объекты) а также как использовать эти классы в процедурах событий вашей программы.

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

Класс, определенный пользователем, позволяет определить в программе ваши собственные объекты, которые имеют свойства, методы и события, точно так же, как объекты, создаваемые на формах Windows с помощью элементов управления из Области элементов. Чтобы добавить в ваш проект новый класс, щелкните в меню Проект (Project) на команде Добавить класс (AddClass), а затем определите этот класс с помощью кода программы и нескольких новых ключевых слов VisualBasic.

Создание свойств

1. Под объявлением переменных введите следующий оператор программы и нажмите клавишу (Enter):

Этот оператор создает свойство вашего класса с именем FirstName, которое имеет тип String. Когда вы нажмете (Enter), VisualStudio немедленно создаст структуру кода для остальных элементов объявления свойства. Требуемыми элементами являются: блок Get, который определяет, что программисты увидят, когда будут проверять свойство FirstName, блок Set, который определяет, что произойдет, когда свойство FirstName будет установлено или изменено, и оператор EndProperty, который отмечает конец процедуры свойства.

2. Заполните структуру процедуры свойства так, чтобы она выглядела, как показано ниже.

Ключевое слово Return указывает, что при обращении к свойству FirstName будет возвращена строковая переменная Name1. При установке значения свойства блок Set присваивает переменной Name1 строковое значение. Обратите особое внимание на переменную Value, используемую в процедурах свойств для обозначения значения, которое присваивается свойству класса при его установке. Хотя этот синтаксис может выглядеть странно, просто поверьте мне - именно так создаются свойства в элементах управления, хотя более сложные свойства будут иметь здесь дополнительную программную логику, которая будет проверять значения и производить вычисления.

3. Под оператором EndProperty введите для свойства LastName вашего класса вторую процедуру свойства. Она должна выглядеть так, как показано ниже.

Эта процедура свойства аналогична первой, за исключением того, что она использует вторую строковую переменную (Name2), которую вы объявили в верхней части кода класса. Вы закончили определять два свойства вашего класса. Теперь перейдем к методу с именем Age, который будет определять текущий возраст нового сотрудника на основе даты рождения.

Создание метода

· Под процедурой свойства LastName введите следующее определение функции:

Чтобы создать метод класса, который выполняет некое действие, добавьте в ваш класс процедуру Sub. Хотя многие методы не требуют для выполнения своей работы аргументов, метод Age, определенный мной, требует для своих вычислений аргумент Birthday типа Date. Это метод использует для вычитания даты рождения нового сотрудника из текущей системной даты метод Subtract, и возвращает значение, выраженное в днях, деленных на 365.25 - примерную длину одного года в днях. Функция Int преобразует это значение в целое, и это число с помощью оператора Return возвращается в вызывающую процедуру - как и в случае с обычной функцией.

Определение класса закончено! Вернитесь к форме Form1 и используйте новый класс в процедуре события.

Совет. Хотя в данном примере это и не делалось, в реальном проекте полезно добавить в модуль класса логику для проверки типов данных. Это делается для того, чтобы неправильное использование свойств или методов, не приводило к возникновению ошибок времени исполнения, из-за которых выполнение программы может прерваться.

Практическая работа №2

Задание:

1. Определить предметную область и сферу применения программного продукта.

2. Определить целевую аудиторию.

3. Построить описательную модель пользователя (профиль). При необходимости — выделить группы пользователей.

4. Сформировать множество сценариев поведения пользователей на основании составленной модели.

5. Выделить функциональные блоки приложения и схему навигации между ними (структуру диалога).

6. Провести тестирование интерфейса пользователя.

 

Теоретические сведения:

Тео Мандел в своей работе выделяет четыре этапа разработки пользовательского интерфейса, а именно:

· Сбор и анализ информации от пользователей;

· Разработка пользовательского интерфейса;

· Построение пользовательского интерфейса;

· Подтверждение качества пользовательского интерфейса.

Первый шаг – определение профиля пользователя. Профиль пользователя отвечает на вопрос: «Что представляет наш пользователь?». Он позволяет нам составить представление о возрасте, образовании, предпочтениях пользователей.

Второй шаг – анализ стоящих перед пользователями задач.

Анализ стоящих перед пользователями задач – это определение того, чего хотят пользователи и каким образом они собираются решать свои задачи.

Концептуальное проектирование есть определение общей структуры и взаимодействия продукта. По определению Алана Купера, концептуальные принципы проектирования «помогают определить сущность продукта и его место в более широком контексте использования, который требуется пользователям».

Концептуальное проектирование включает:

· Определение типа интерфейса будущего приложения (монопольный, временный, фоновый);

· Организацию инфраструктуры взаимодействия;

Согласно определению Алана Купера, тип интерфейса определяет поведенческую сущность продукта, то есть то, как он предъявляет себя пользователю. Тип интерфейса – это способ описать то, как много внимания пользователь будет уделять взаимодействию c продуктом, и каким образом продукт будет реагировать на это внимание.

Следует отметить зависимость типа интерфейса от используемой технической платформы: персонального компьютера, Интернет, информационный киоск, мобильное устройство, бытовая техника.

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

Интерфейс настольных приложений можно отнести к одному из трёх типов: монопольный, временный и фоновый.

К приложениям монопольного типа относятся программы, которые полностью завладевают вниманием пользователя на длительные периоды времени. Для продуктов с монопольным интерфейсом характерна длительная работа в течение длительных отрезков времени. В процессе работа пользователя монопольный продукт является его основным инструментом и преобладает над остальными.

Приложение временного типа приходит и уходит, предлагая одну функцию и ограниченный набор связанных с этой функцией элементов управления. Приложение этого типа вызывается при необходимости, делает свою работу и быстро исчезает, позволяя пользователю продолжить прерванную (как правило, в окне монопольного приложения) деятельность. Типичный пример сценария работы с временным приложением – вызов Проводника Windows для поиска и открытия другого файла в то время, когда пользователь уже редактирует один файл в MS Word. 

Фоновыми называют приложения, которые в нормальном «рабочем» состоянии не взаимодействуют с пользователем. Такие программы выполняют задачи, которые в целом важны, но не требуют вмешательства пользователя. Примеры: драйвер принтера, подключение к сети.

Инфраструктура взаимодействия включает варианты поведения приложения. Создание инфраструктуры взаимодействия предполагает выполнение шести шагов:

Шаг 1. Определение форм-фактора, типа приложения и способов управления.

Шаг 2. Определение функциональных и информационных элементов.

Шаг 3. Определение функциональных групп и иерархических связей между ними.

Шаг 4. Макетирование общей инфраструктуры взаимодействия.

Шаг 5. Создание ключевых сценариев.

Шаг 6. Выполнение проверочных сценариев для верификации решений.

Форм-фактор – это зависимость вида пользовательского интерфейса от используемой технической платформы.

Функциональные и информационные элементы – это зримые представления функций и данных, доступные пользователю посредством интерфейса. Это конкретные проявления функциональных и информационных потребностей, выявленных на стадии выработки требований.

Информационные элементы – это, как правило, фундаментальные объекты интерактивных продуктов.

Функциональные элементы – это операции, которые могут выполняться над информационными объектами и представляющими эти объекты элементами интерфейса. В большинстве случаев функциональные элементы представляют собой инструменты, работающие с информационными элементами, а также контейнеры, содержащие информационные элементы. 

Макетирование общей инфраструктуры взаимодействия Аланом Купером охарактеризовано как «фаза прямоугольников», поскольку эскизы будущего интерфейса начинаются с разделения каждого представления на прямоугольные области, соответствующие панелям, элементам управления и другим высокоуровневым контейнерам. При этом каждому прямоугольнику даётся своё название и показывается, каким образом одна группа элементов может влиять на другие. Содержательно этот шаг предназначен для исследования различных вариантов представления информации и функциональности в интерфейсе, при этом затраты на внесение изменений должны быть минимальны.

Известны два вида макетов: с жёсткой компоновкой и без компоновки.

При этом макет с жёсткой компоновкой:

· содержит взаимное расположение элементов и визуальную информацию о приоритетах;

· ограничивает работу графического дизайнера.

Для макета без компоновки характерно то, что он:

· не содержит графического представления элементов;

· содержит текстовое описание элементов и их приоритетов;

· не ограничивает работу графического дизайнера.

Сценарий определяется Аланом Купером как средство описания идеального для пользователя взаимодействия. Истоки этого понятия восходят к публикациям сообщества HCI (Human-Computer Interaction – взаимодействие человека и компьютера), где оно увязывалось с указанием на метод решения задач проектирования через конкретизацию, которая понималась как использование специально составленного рассказа, чтобы одновременно конструировать и иллюстрировать проектные решения. Применение сценарного подхода к проектированию, как показано в книге Кэрролла «Making Use» (Carroll, 2000), сосредоточено на описании того, как пользователи решают задачи. Такое описание включает характеристику обстановки рабочей среды, а также агентов, или действующих лиц, которые являются абстрактными представителями пользователей.

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

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

Шаг 1. Постановка задач и определение образа продукта.

Шаг 2. Мозговой штурм.

Шаг 3. Выявление ожиданий персонажей.

Шаг 4. Разработка контекстных сценариев.

Шаг 5. Выявление требований.

Ключевой сценарий описывает взаимодействие персонажа с системой в терминах лексикона инфраструктуры взаимодействия. Он отражает магистральные пути внутри интерфейса, используемые персонажем чаще всего (например, ежедневно). Ключевые сценарии сосредоточены на задачах. Например, в случае приложения для работы с электронной почтой ключевые действия – это просмотр и создание новых сообщений, а не настройка нового почтового сервера.

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

Контекстные сценарии сосредоточены на целях, же ключевые сценарии больше сосредоточены на задачах, намеки на которые или описания которых содержатся в контекстных сценариях.

Выполнение работы:

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

Предметная область и сфера применения. Правильное определение этих аспектов является основой для разработки UI в частности и всего приложения в целом. Определение целевой аудитории, направлен на выделение из общей массы группы (или групп) потенциальных пользователей разрабатываемой программы. Естественно, что цели, задачи, способности и возможности групп пользователей будут существенно различаться.

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

· Социальные и демографические характеристики (возраст, пол, основной язык, род занятий, потребности, привычки и т.п.).

· Уровень компьютерной грамотности.

· Цель и задачи, решаемые пользователем.

· Окружение (рабочее место, конфигурация оборудования, используемая операционная система и т.п.)

· Требования, специфичные для конкретной целевой группы.

После выделения одного или нескольких основных профилей пользователей и определения задач, стоящих перед ними, переходят к следующему этапу проектирования. Он связан с составлением пользовательских сценариев. Сценарий — это описание действий, выполняемых пользователем в рамках решения конкретной задачи на пути достижения его цели. Очевидно, что достигнуть некоторой цели можно, решая ряд задач. Каждую их них пользователь может решать несколькими способами, следовательно, должно быть сформировано несколько сценариев. Чем больше их будет, тем ниже вероятность того, что некоторые ключевые объекты и операции будут упущены.

 

Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке.

Контрольные вопросы:

1. Что такое интерфейс?

2. Какие типы пользовательских интерфейсов существуют?

3. Перечислите этапы разработки пользовательских интерфейсов?

4. К какому типу интерфейсов будет относиться интерфейс, разработанный в данной лабораторной работе?

5. Какие модели интерфейсов существуют?

6. Какая модель интерфейса будет использована в данной работе?

7. Что такое диалог?

8. Какие типы диалогов существуют?

9. Какие формы диалога Вы знаете?

10. Какой тип диалога и какая форма диалога будет использована в данной работе?

 

Практическая работа №3

Задание:

1)    Ознакомиться с лекционным материалом по теме «Тестирование, отладка и ПО»

2)    Провести функциональное тестирование разработанного программного обеспечения

Теоретические сведения:

Процесс тестирования состоит из трёх этапов:

1. Проектирование тестов.

2. Исполнение тестов.

3. Анализ полученных результатов.

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

Виды тестов

Функциональные тесты составляются на уровне спецификации, до решения задачи. Будущий алгоритм рассматривается как «черный ящик» - функция с неизвестной (или не рассматриваемой) структурой, преобразующая входы в выходы. Суть функциональных тестов: каким бы способом ни решалась задача, при заданных входных значениях должны получиться соответствующие выходные значения.

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

Чаще всего совокупность тщательно составленных функциональных тестов покрывает множество структурных тестов.

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

Общая последовательность разработки тестов

Наиболее рациональная процедура заключается в том, что сначала разрабатываются функциональные тесты, а затем – структурные.

Функциональное тестирование (тестирование «черного ящика»)

При функциональном тестировании выявляются следующие категории ошибок:

· некорректность или отсутствие функций;

· ошибки интерфейса;

· ошибки в структурах данных;

· ошибки машинных характеристик (нехватка памяти и др.);

· ошибки инициализации и завершения.

Техника тестирования ориентирована:

· на сокращение необходимого количества тестовых вариантов;

· на выявление классов ошибок, а не отдельных ошибок.

Способы функционального тестирования

Разбиение на классы эквивалентности

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

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

Классы эквивалентности определяются по спецификации программы. Тесты строятся в соответствии с классами эквивалентности, а именно: выбирается вариант исходных данных некоторого класса и определяются соответствующие выходные данные.

Самыми общими классами эквивалентности являются классы допустимых и недопустимых (аномальных) исходных данных. Описание класса строится как комбинация условий, описывающих каждое входное данное.

Условия допустимости или недопустимости данных задают возможные значения данных и могут описывать:

· некоторое конкретное значение; определяется один допустимый и два недопустимых класса эквивалентности: заданное значение, множество значений меньше заданного, множество значений больше заданного;

· диапазон значений; определяется один допустимый и два недопустимых класса эквивалентности: множество значений в границах диапазона; множество значений, выходящих за левую границу диапазона; множество значений, выходящих за правую границу диапазона;

· множество конкретных значений; определяется один допустимый и один недопустимый класс эквивалентности: заданное множество и множество значений, в него не входящих.

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

В примере, приводимом в вопросе 2 темы 3, при построении тестов неформально использовался описанный метод. В методических целях были выделены только основные класс тестов. Кроме того, исходя из условия задачи, были выделены классы эквивалентности внутри класса правильных данных.

Анализ граничных значений

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

Основные правила построения тестов:

· если условие правильности данных задает диапазон, то строятся тесты для левой и правой границы диапазона; для значений чуть левее левой и чуть правее правой границы;

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

· если используются структуры данных с переменными границами (массивы), то строятся тесты для минимального и максимального значения границ.

· Диаграммы причин-следствий

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

Выполнение работы:

1)    Разработать тестовые наборы для функционального тестирования.

2)    Провести тестирование программы и представить результаты в виде таблицы.

3)    Выработать рекомендации для корректировки тестируемой программы.

4)    Представить отчет по лабораторной работе для защиты.

Требования к отчету: Текст должен быть написан шрифтом Times New Roman, 12. Интервал между строками и абзацами – 1,5. Отступ слева 1,5. Ориентация текста – по ширине страницы. Скриншоты необходимо подписать. Название практической работы, цель работы, ход работы, вывод, ответы на контрольные вопросы, должны быть выделены жирным шрифтом, так же как в методичке.

Контрольные вопросы:

1.    Что такое тестирование ПС?

2.    Чем тестирование отличается от отладки ПС?

3.    Для чего проводится функциональное тестирование?

4.    Каковы правила тестирования программы «как черного ящика»?

5.    Как проводится тестирования программы по принципу «белого ящика»?

6.    Как осуществляется сборка программы при модульно тестировании?

Практическая работа №4

Практическая работа №5

Задание:

Разработать тестовые модулей проекта для тестирования отдельных модулей, провести оптимизацию программы по выбранному параметру.

Теоретические сведения:

Оптимизация – преобразование программы, сохраняющее ее семантику (конструкции языка программирования), но уменьшающие ее размер и время выполнения.

Виды оптимизация программы:

· глобальная (всей программы);

· локальная (нескольких соседних операторов, образующих линейный участок);

· квазилокальная (фрагментов программы фиксированной структуры, например, циклов).

Способы оптимизации:

1. Разгрузка участков повторяемости: вынесение вычислений из многократно проходимых исполняемых участков программы на участки программы, редко проходимые. Таким образом, это преобразование тела цикла или рекурсивных процедур.

2. Упрощение действий: улучшение программы за счет замены групп вычислений на группу вычислений, дающих тот же результат с точки зрения всей программы, но имеющих меньшую сложность.

а) упрощение действий происходит при замене сложных операций в выражениях более простыми: x / 0.4 -> x*0.25;

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

3. Реализация действия: действия над константами заменяются на константы; ликвидация константных распознавателей -замена условного оператора на одну из его ветвей, если его выбирающее условие-выражение имеет постоянное значение; удаление из программы ненужных пересылок вида:

Y=F(W), X=Y на X=F(W)

4. Чистка программы (удаление ненужных конструкций): недостижимых операторов, существенных операторов, неиспользуемых переменных, видов, операций.

5. Сокращение размера программы: вынесение одинаковых конструкций в начальную или конечную точку программы; поиск в программе похожих объектов и формирование их в виде процедуры.

6. Экономия памяти -уменьшение объема памяти, отводимые под информационные объекты программы (например, параметры процедуры).

 

Выполнение работы: