Экзамен СТЭП 6 семестр


Ответы на вопросы к экзамену по предмету Современные технологии программирования.

Назовите и охарактеризуйте уровни оптимизации кода программ.

ОТВЕТ:

Оптимизацию кода программ можно разделить на несколько уровней:

Алгоритмическая оптимизация.

Параллельные вычисления.

Микро-оптимизации на уровне кода (уровень профайлеров и статических анализаторов).

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

Нет смысла заниматься оптимизацией низких уровней, пока не исчерпаны возможности оптимизации на верхних уровнях. Выбор правильного алгоритма и правильных структур данных, может повысить производительность приложения на 1000%, в то время как оптимизация кода на уровне команд, скорее всего, даст выигрыш в 10%.

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

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

ОТВЕТ:

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

Выделяют три способа проявления таких ошибок:

появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль»,

нарушении адресации и т.п.;

появление сообщения об ошибке, обнаруженной операционной системой, например, нарушении защиты памяти, попытке записи на устройства, защищенные от записи, отсутствии файла с заданным именем и т.п.;

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

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

неверное определение исходных данных

происходит, «если возникают любые ошибки при выполнении операций ввода-вывода: ошибки передачи, ошибки преобразования, ошибки перезаписи и ошибки данных

логические ошибки

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

накопление погрешностей результатов вычислений

Инициализация переменных, массивы, индексация, параметры функций, нарушение логики, неверное приближение, особенности ЯП и т.д.

Назовите особенности тестирования во всех фазах жизненного цикла программы.

ОТВЕТ:

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

Тестирование выполняется во всех фазах жизненного цикла программы.

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

Тестирование включает в себя следующие этапы:

1) планирование тестирования

2) проектирование тестов

3) выполнение тестирования

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

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда выполняется под отладчиком или с использованием окружения. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

Тестирование при приёмке — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

Тестирование новой функциональности.

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

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

Бета-тестирование

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию).

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

Объясните назначение сценария тестирования, приведите пример какого-либо сценария.

ОТВЕТ:

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

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

Пример:

Пример спецификации программы

На вход программа принимает два параметра: x — число, n – степень.

Результат вычисления выводится на консоль.

Значения числа и степени должны быть целыми.

Значения числа, возводимого в степень, должны лежать в диапазоне – [0..999].

Значения степени должны лежать в диапазоне – [1..100].

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

Набор тестов:

Каждый тест из набора охватывает различные области эквивалентности входных параметров.

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

1. x < 0 (ошибочное)

2. x > 999 (ошибочное)

3. x — не число (ошибочное)

4. 0 <= x <= 999 (корректное)

Для n – степени числа:

5. n < 1 (ошибочное)

6. n > 100 (ошибочное)

7. n — не число (ошибочное)

8. 1 <= n <= 100 (корректное)

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

1. Входные значения: (x = 2, n = 3) (покрывают классы 4, 8).

Ожидаемый результат: The power n of x is 8.

2. Входные значения: {(x = -1, n = 2),(x = 1000, n = 5)} (покрывают классы 1, 2).

Ожидаемый результат: Error : x must be in [0..999].

3. Входные значения: {(x = 100, n = 0),(x = 100, n = 200)} (покрывают классы 5,6).

Ожидаемый результат: Error : n must be in [1..100].

4. Входные значения: (x = ADS n = ASD) (покрывают классы эквивалентности 3, 7).

Ожидаемый результат: Error : Please enter a numeric argument.

5. Проверка на граничные значения:

1. Входные значения: (x = 999 n = 1).

Ожидаемый результат: The power n of x is 999.

2. Входные значения: x = 0 n = 100.

Ожидаемый результат: The power n of x is 0.

Объясните назначение тестирования производительности, перечислите его направления.

ОТВЕТ:

Тестирование производительности может служить разным целям:

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

С целью определения производительность какой из двух или нескольких систем лучше.

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

Цели могут различаться в зависимости от технологий, используемых приложением, или его

назначения, однако, они всегда включают что-то из нижеследующего:

Параллелизм / Пропускная способность

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

Если концепция приложения не заключается в работе с конкретными конечными пользователями, то преследуемая цель для производительности будет основана на максимальной пропускной способности или числе транзакций в единицу времени. Хорошим примером в данном случае будет являться просмотр веб-страниц, например, на портале Wikipedia.

Время ответа сервера

Эта концепция строится вокруг времени ответа одного узла приложения на запрос, посланный другим. Простым примером является HTTP ‘GET’ запрос из браузера рабочей станции на веб- сервер. Практически все приложения, разработанные для нагрузочного тестирования работают именно по этой схеме измерений. Иногда целесообразно ставить задачи по достижению производительности времени ответа сервера среди всех узлов приложения.

Время отображения

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

Объясните причины ошибок при разработке программ.

ОТВЕТ:

Причины ошибок

непреднамеренное отклонение разработчиков от рабочих стандартов или планов реализации;

спецификации функциональных и интерфейсных требований выполнены без соблюдения

стандартов разработки, что приводит к нарушению функционирования программ;



организации процесса разработки — несовершенная или недостаточное управление руководителем проекта ресурсами (человеческими, техническими, программными и т.д.) и вопросами тестирования и интеграции элементов проекта.

Объясните, для чего проводят юзабилити-тестирование.

ОТВЕТ:

Юзабилити-тестирование — исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект (веб-страница, пользовательский интерфейс) для его предполагаемого применения. Таким образом, проверка эргономичности измеряет эргономичность объекта или системы.

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

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

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

Объясните, как проводится тестирование по стратегии белого ящика, назовите методы стратегии белого ящика.

ОТВЕТ:

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

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

Объясните, как проводится тестирование по стратегии черного ящика, назовите методы стратегии черного ящика.

ОТВЕТ:

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

Охарактеризуйте процесс проектирования тестов.

ОТВЕТ:

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

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

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

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

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

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

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

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

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

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

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

Охарактеризуйте содержание каждого этапа тестирования.

ОТВЕТ:

Тестирование включает в себя следующие этапы:

Планирование тестирования

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

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

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

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

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

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

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

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

ОТВЕТ:

Артефакты, необходимые для обеспечения процесса тестирования (имеется в виду разрабатываемые самим тестировщиком):

План тестирования (Test plan)

Есть как минимум два общепринятых понимания этого документа:

1. Документ, описывающий кто, что, когда и как будет тестироваться

2. Документ, описывающий все необходимые для проверки приложения тесты.

Тестовый сценарий (Test-case)

Тестовый сценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.

Сценарий тестирования — основной документ для поддержания качества продукта на определённом уровне.

Наборы тестовых сценариев (Test script or Test suite)

Набор тестовых сценариев для Smoke-test

Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.

План приёмосдаточных испытаний (ПСИ)

Описание дефектов

Отчет о тестировании

Перечислите и охарактеризуйте виды ошибок при разработке программ.

ОТВЕТ:

Ошибки при постановке задачи, при составлении ТЗ

Ошибки процесса разработки требований

Характерными ошибками этого процесса являются:

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

некорректность спецификации взаимодействия ПО со средой функционирования или с пользователями;

несоответствие требований заказчика к отдельным и общим свойствам ПО;

некорректность описания функциональных характеристик;

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

Ошибки проектирования

Ошибки в структуре ПО:

Ошибки функциональности отдельных модулей.

Ошибки программных интерфейсов.

Ошибки в спецификациях программ.

Недостатки программы и методики тестирования.

Ошибки при выборе средств разработки и управления проектом.

Ошибки кодирования

Бесконтрольность значений входных параметров, индексов массивов, параметров циклов, выходных результатов, деления на 0 и др.;

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

нарушение стандартов кодирования (плохие комментарии, нерациональное выделение модулей и компонент и др.);

использование одного имени для обозначения разных объектов или разных имен одного объекта, плохая мнемоника имен;

несогласованное внесение изменений в программу разными разработчиками и др.

опечатки при кодировании.

ошибки при реализации спецификаций.

не выполнение критериев добротности программы.

недостатки оформления и документирования исходных текстов.

Ошибки отладки и тестирования

не реализована полностью программа и методика тестирования.

не все ошибки отражены в отчете.

не все ошибки исправлены.

недостатки в документировании ошибок.

Ошибки и недочеты в документации на ПО

Ошибки на этапе сопровождения (эксплуатации и модернизации)

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

Перечислите и охарактеризуйте основные инструменты оптимизации программ.

ОТВЕТ:

Инициализация объектов данных – во многих программах какую-то часть объектов данных необходимо инициализировать, то есть присвоить им начальные значения. Такое присваивание выполняется либо в самом начале программы, либо, например, в конце цикла. Правильная инициализация объектов позволяет сэкономить драгоценное процессорное время. Так, например, если речь идет об инициализации массивов, использование цикла, скорее всего, будет менее эффективным, чем объявление этого массива прямым присвоением.

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

Циклы – различается и время выполнения циклов разного типа. Время выполнения цикла со счетчиком и цикла с постусловием при всех прочих равных условиях совпадает, цикл с предусловием выполняется несколько дольше (примерно на 20-30 %).

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

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

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

Использование функций – относительно много времени тратится на обращение к подпрограммам (передача параметров через стек, сохранение регистров и адреса возврата, вызов конструкторов копирования). Если подпрограмма содержит малое число действий, она может быть реализована подставляемой — все её операторы копируются в каждое новое место вызова (существует ряд ограничений на inline-подстановки: например, подпрограмма не должна быть рекурсивной). Это ликвидирует накладные расходы на обращение к подпрограмме, однако ведет к увеличению размера исполняемого файла. Само по себе увеличение размера исполняемого файла не является существенным, однако в некоторых случаях исполняемый код может выйти за пределы кэша команд, что повлечет значительное падение скорости исполнения программы. Поэтому современные оптимизирующие компиляторы обычно имеют настройки оптимизации по размеру кода и по скорости выполнения.



Страницы: 1 | 2 | Весь текст


Предыдущий:

Следующий: