Отладка и тестирование программ: основные подходы и ограничения (ПОНЯТИЕ ТЕСТИРОВАНИЯ И ОТЛАДКИ)

Содержание:

ВВЕДЕНИЕ

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

Тестирование программного продукта отражает циклы разработки самого программного обеспечения. Ранее тестовые сценарии записывались на бумагу, а разработка программного обеспечения делала основной упор на крупномасштабные научные программы, а также на программы министерства обороны, которые проектировались на универсальной ЭВМ и миникомпьютера. В этом случае тестирование начиналось только после завершения плана-графика проекта и выполнялось одним и тем же персоналом.

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

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

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

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

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

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

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

Целью работы является анализ видов тестирования.

Для реализации поставленной цели необходимо решение следующих задач:

1. Дать основные понятия тестированию и отладки.
2. Рассмотреть уровни тестирования.
3. Охарактеризовать процесс тестирования
4. Разработать программу.
5. Провести анализ литературы по избранной теме.

Основные авторы, в научных работах которых рассматривалась проблема исследования: П.В. Котляров, В. Н. Цыганенко.

1. ПОНЯТИЕ ТЕСТИРОВАНИЯ И ОТЛАДКИ

1.1. История развития

Раньше тестирование представляло собой довольно примитивный процесс и не справлялось с задачами, которые были на него возложены:

1. Повышения качества за счет покрытия максимальной функциональности продукта.
2. Уменьшение времени тестирования.
3. Снижение денежных затрат на тестирование.

Развитие тестирования происходило в два больших этапа.

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

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

1. Организацию и финансирование тестирования.
2. Определение правильного направления.

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

Среди моментов эволюции тестирования, можно выделить два наиболее значимых моментов. Во-первых, это халатное отношения руководства, которое не понимала важность и значимость тестирования, его место в процессе разработки и понимания результата, которое дает тестирование. Связи с этим развитие тестирования тормозилось и могло быть обречено. Во-вторых, концепция «тестирование ради тестирования» и выбор инструмента. Важно четно определить определенную стратегию, тестирование и выбор инструмента, иначе все усилия будут безрезультатные [1].

В результате первых двух этапов началась разработка программ тестирования, которые стали соответствовать требованиям и программное обеспечение стало разрабатываться намного быстрее и более дешевым методом [1].

В книге Глендфорда Майерса: “Искусство тестирования ПО” приводится следующий пример: ВВС США при разработке программного обеспечения ввели в практику заключение отдельных контрактов с компанией-разработчиком и компанией-тестером. Впоследствии ВВС создала отдельную компанию для проведения тестирования и испытаний программного обеспечения. Такой подход получил высокую оценку и был признан единственно верным при разработке критически важных приложений” [4].

В начале 90-х годов расцветает объектно-ориентированных подход к разработке программного обеспечения. Начинают набирать популярность такие стандарты как ISO и CMM. Разработчики стараются обходиться без независимых тестовых агентств и возлагают надежды на передовые средства разработки и методы управления. Качество программного продукта действительно повышается. Но возникает новая проблема – это высокий темп разработки, быстрые изменения требований к продукту, нехватка ресурсов, сложность систем возрастает многократно. Начинается поиск новых решений, набирается сила глобализации разработки программного обеспечения. Тестирование адаптируется и получает новые формы [2].

1.2. Основные определения

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

Тестирование программного обеспечения (Software Testing) – это проверка на соответствие между ожидаемым поведением программы и реальным. Как правило, осуществляется на конечном наборе тестов. Также тестирование представляет собой контроль качества, который включает:

1. активность по планированию работ (Test Management).
2. проектирование тестов (Test Design).
3. выполнение тестирования (Test Execution).
4. анализ полученных результатов (Test Analysis).

Верификация (Verification) – является процессом оценки системы, а также ее компонентов с целью определения удовлетворения текущего этапа разработки заявленным условиям на первом этапе. Другими словами проверка целей, сроков и задач по разработке проекта с предыдущей фазой [6].

Валидация (Validation) – это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [10].

Немаловажной частью является план тестирования. План Тестирования (Test Plan) – это документ, который описывает весь объем работы по тестированию. В него включается описание объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Тест дизайн (Test Design). На этом этапе процесса тестирования программного продукта проектируются и создаются тестовые случаи (кейсы), в соответствии с ранними критериями качества и целями тестирования [17].

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

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

Как в любой программе, возникают ошибки и необходимо дать определением этим ошибкам. Как правило, их называют баг или дефект репорт.

Баг/Дефект Репорт (Bug Report) – это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата [22].

Тестовое Покрытие (Test Coverage) – является мерой оценки качества тестирования [15].

Детализация Тест Кейсов (Test Case Specification) – насколько детализировано, описаны тестовые шаги и конечный результат, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию.

Время Прохождения Тест Кейса (Test Case Pass Time) – время, которое затрачивается от начала прохождения шагов тест кейса и до получения результата теста [3].

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

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

1. Синтаксические ошибки – неверное употребление синтаксических конструкций.
2. Семантические ошибки – нарушение семантики конструкции
3. Логические ошибки – нарушение логики программы, обычно кроются в алгоритмах программы [4].

1.3. Уровни тестирования

Уровни тестирования можно разделить на следующие виды:

1. Модульное
2. Комплексное
3. Системное
4. Приемочное
5. Операционное

Модульное тестирование.

Его иногда называют автономное или unit-тестирование. На этом уровне тестируются незначительные/небольшие элементы системы, которые максимально отдалены от других элементов. Это тестирование проводится сразу после разработки каждого из элементов и направлена на оценку соответствия функциональности компонента.

Входными требованиями является архитектура компонентов или модель «нижнего уровня» системы Component Design.

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

Комплексное тестирование.

Комплексное тестирование называют иногда сборочным тестированием. На этом уровне тестированию подвергаются объединенные элементы общей системы, наиболее часто некоторая группа элементов. Направлено на проверку взаимодействия компонентов в соответствии с «Архитектурой системы». Тесты проверяют все интерфейсы взаимодействие между компонентами до тех пор, пока все компоненты не будут разработаны, отлажены и проинтегрированы друг с другом в единую систему [13].

Входными требованиями является архитектура системы или модель «верхнего уровня» системы System Design.

Объектом тестирования выступает собранная из компонентов система.

Затем следует системное тестирование. После сборки системы из составляющих компонентов, она тестируется на соответствие «Системным спецификациям».

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

Входными требованиями является системная спецификация.

Объектом тестирования является разработанная система.

Приемочное тестирование.

Оно также называют приемо-сдаточное тестирование. Приложение или система тестируется заказчиком, конечными пользователями или соответствующими уполномоченными с целью определения соответствия системы “Требованиям Заказчика” и готовности системы к внедрению. Приемосдаточные испытания оформляют процесс передачи продукта от Разработчика Заказчику [12].

В зависимости от особенностей продукта и от требований Заказчика они могут проводиться в различной форме. Например, в виде альфа-тестирования или бета-тестирования. Это тестирование похоже на системное тестирование, но имеет ряд различий, одно из которых: приемочное тестирование проверяет, что разработанная система удовлетворяет запрошенным Заказчиком требованиям с упором на нужды конечных пользователей в данной предметной области.

Входными требованиями являются сами требования.

Объектом тестирования является разработанная система.

Операционное тестирование.

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

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

Нахождение подобных ошибок на стадии внедрения достаточно дорогостоящая проблема. Поэтому проведение не только верификации и валидации необходимо проводить на ранних этапах разработки программного обеспечения [8].

Входными требованиями является бизнес модель.

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

Разделение тестов на виды по объектам тестирования, а также на уровни тестирования производится при определении обобщённой модели жизненного цикла. Стоит отметить, что для каждого уровня тестирования, можно использовать довольно разные виды тестирования, а для каждого тестирования можно использовать различные типы тестовых испытаний [5].

2. ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММ

2.1. Виды тестирования

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

1. Функциональные тесты.
2. Нефункциональные тесты.
3. Тесты, связанные с изменениями.

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

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

1. Функциональную пригодность.
2. Точность.
3. Способность к взаимодействию.
4. Соответствие стандартам и правилам.
5. Защищённость.

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

1. Тестирование производительности.
   1. нагрузочное тестирование.
   2. стрессовое тестирование.
   3. тестирование стабильности или надежности.
   4. объемное тестирование.
2. Тестирование установки.
3. Тестирования для удобства пользования.
4. Тестирование на отказ и восстановление.
5. Конфигурационное тестирование.

Также существуют виды тестирования, которые связаны с изменениями. После обнаружения бага или дефекта производятся необходимые изменения, затем программное обеспечение тестируется заново, чтобы выявить, проблема была решена или нет. После установки программного обеспечения, для подтверждения правильной работы программного приложения применяют следующие виды тестирования [24]:

1. Регрессионное тестирование.
2. Дымовое тестирование.
3. Тестирование сборки.
4. Санитарное тестирование (проверка согласованности или исправности).

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

Основные принципы безопасности программного обеспечения. Стратегия безопасности базируется на трех принципах:

1. Целостность.
2. Доступность.
3. Конфиденциальность.

Для определения целостности существует два основных понятия:

1. Доверие – ресурс будет изменен только соответствующим способом определенной группой пользователей.
2. Повреждение и восстановление – данные повреждаются или меняются авторизованными и неавторизованными пользователями. Необходимо определить, насколько важна процедура восстановления информации [13].

Доступность. Это требование о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс, тем выше уровень доступности должен быть.

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

Тестирование взаимодействия. Взаимодействие различных системе, сервисов и приложений друг с другом приобрело значительную актуальность при развитии сетевых технологий и интернета. Любые связанные с этим проблемы могут привести к паданию авторитета компании, вследствие чего произойдут финансовые потери. Эта является одной из самых главных стадий и необходимо подходить к тестированию со всей серьезностью [9].

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

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

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

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

Тестирование производительности. При тестировании производительности главной задачей является определение критериев под нагрузкой, при этом происходит:

1. измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций;
2. определение количества пользователей, одновременно работающих с приложением;
3. определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций);
4. исследование производительности на высоких, предельных, стрессовых нагрузках [19].

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

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

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

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

Тестирование стабильности. Главной задачей тестирования надежности (стабильности) является проверка на работоспособность приложения при долговременном (многочасовом) тестировании со средним уровнем нагрузки. При этом время выполнения операций играет в этом тестировании не главную роль. На первом месте стоит утечка памяти, перезапуск сервера под нагрузкой, а также другие немаловажные аспекты, влияющие на стабильность работы [10].

Дымовое тестирование, также называется Smoke Test, это минимальный набор тестов, который выявляет явные ошибки. Такой тест выполняется самим программистом и если программа не проходит этот тест, то дальнейшее, более глубокое тестирование уже не имеет смысла.

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

Это тестирование можно проще автоматизировать, нежели глубокое или интеллектуальное тестирование. При автоматизации снижается количество ручного труда, за счет этого можно проводить тести намного чаще. При этом чем чаще выполняются тесты, то тем быстрее становится известно о проблемах, выявляемых этими тестами. Чем быстрее найдена проблема, тем легче ее устранить, а автоматизация тестирования зачастую выполняется с помощью непрерывной интеграции [11].

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

Регрессионное тестирование. Это тестирование рекомендуется проводить после исправления программы, а именно исправление бага, объединение кода, интеграция на другую операционную систему [5].

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

Основные преимущества этого тестирования:

1. Значительное сокращение количества дефектов в системе к моменту выпуска программы осуществляется за счет регулярного проведения регрессионного тестирования.
2. Деградация качества системе при росте функциональности полностью исключается.
3. Вероятность критических ошибок в опытно-промышленной эксплуатации значительно уменьшается.

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

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

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

1. Невозможность установки программного обеспечения.
2. Потерю данных после установки более новой версии программы.
3. Невозможность отката до предыдущей версии.

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

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

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

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

Сам процесс тестирования фиксируется в протоколе, иногда на аудиоустройства и или видео устройства, для более детального анализа. Если выявляются какие-либо трудности, то разработчики дорабатывают продукт и повторяют тестирование. При наблюдении взаимодействия пользователей с продуктом можно найти для него оптимальное решение. Одна из трудностей после проведения проверки эргономичности является большие потоки информации, которые не упорядочены [15].

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

Конфигурационное тестирование тестирует эффект влияния на производительность изменений в конфигурации [17].

2.2. Организация процесса тестирования

При тестировании программного продукта одновременно проводится в трех направлениях:

1. Проверка кода.
2. Тестирование высокого уровня.
3. Тестирование низкого уровня.

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

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

Тестирование низкого уровня: Тестер проверяет, на сколько логически полно исходный код покрывает всё возможные варианты работы системы, для которой он разрабатывается [18].

3. РАЗРАБОТКА ПРОГРАММЫ

3.1. Средства разработки программы

Для разработки программы выбран объектно-ориентированный язык программирования C# (си шарп). Выбор сделан в пользу этого языка программирования по ряду причин:

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

1. Управление памятью происходит через сборку мусора. Именно по этой причине в Си шарп не требуется указывать ключевое слово delete.
2. Поддержка программирования, основанная на использовании интерфейсов.
3. Возможность построения общих типов и членов с использованием синтаксиса, похожего на Си ++.
4. Поддержка технологии аспектно-ориентированного программирования через атрибуты.

Язык С# актуален в первую очередь потому, что позволяет более рационально создавать популярные на сегодня Интернет-приложения. Язык C# тесно интегрирован с языком XML, различными веб-технологиями. Язык C# интегрировал в себе преимущества языка Java и С++, что и обуславливает популярность данного языка среди разработчиков. При этом в объединенном языке исключены некоторые спорные директивы, макросы, отменены глобальные переменные [19].

Среда разработки выбрана – Visual Studio. Visual Studio это интегрированная среда разработки с широкими возможностями для создания потрясающих приложений для Windows, Android и iOS, а также современных веб-приложений и облачных служб [20].

Visual Studio является мощным инструментом для разработки и в отличии от своих конкурентов имеет ряд преимуществ.

Преимущества среды разработки Visual Studio:

• 1. Использование вычислительной мощи локального компьютера и облака.
  2. Реализация общих задач и индивидуальных подход.
  3. Создание за короткий срок высококачественного продукта (программы).
  4. Поддержка нескольких мониторов.
  5. Реализация идей для широкого спектра платформ.

3.2. Разработка программы

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

При разработке программы применялась отладка, посредством процедуры отладки – пошаговым выполнением. При этом выполнении код выполняется по одной строчке за раз. Выполнялся «шаг с обходом» по клавише F10.

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

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

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

Пользователь вводит ряд значений:

1. данные первого тела:
   1. начальные координаты;
   2. скорость;
   3. массу;
   4. радиус.
2. данные второго тела:
   1. координату по x;
   2. радиус;
   3. массу.
3. угол между телами (от -90 до 90 желательно);
4. шаг по времени.

Теоретическая часть задачи: Абсолютно упругий удар (идеальный удар) – соударение твердых тел, после которого их форма полностью восстанавливается.

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

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

Расчет производится в два этапа: до соударения тел и после соударения тел.

Для начала нужно рассчитать координату второго тела по y. Известны радиусы тел, положение первого тела и угол между телами.

По этим данным можно вычислить координату второго тела по y:

(1)

Условие, которое проверяет, произошло ли соударение тел:

(2)

Пока выполняется это условие, координаты равны:

, ,

, (3)

Где x_a ,y_a, x_b,y_b – положение первого и второго шара соответственно.

После того, как шары столкнулись, то запоминается положение тел во время столкновения и записываются координаты X, Y для каждого из тел.

Новые координаты равны:

, ,

, (4)

Скорости по Vbx, Vax, Vay, Vby, необходимо рассчитать по формулам, которые приведены ниже:

(5)

Где значение рассчитывается как отношение:

(6)

После того, как рассчитаны формулы, выводим новые координаты шаров на экран.

Ход работы: Пользователь вводит начальные значения первого тела (начальные координаты, скорость, массу и радиус), второго тела (координату по x, радиус, массу), угол между телами, шаг по времени.

Сначала вычисляется координата y второго тела по формуле (1). По нажатию клавиши «Начать» отображается на форме положение двух тел. Прорисовка происходит через компонент pictureBox. По желанию можно изменить шаг по времени, но для наглядной прорисовки лучше использовать шаг равный единице.

После нажатия «Старт» изменяются координаты первого шара. Пока условие истинно формуле (2), координаты тел равны формуле (3). По нажатию клавиши «Стоп», появляется ранее неактивная кнопка «Продолжить».

Чтобы корректно работала программа, делается засечка, когда пользователь нажимает кнопку «Стоп». Следует отметить, что при нажатии на кнопку «Стоп», время тоже останавливается, как и прорисовка фигур.

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

Для того, чтобы реализовать эту программу, использовался дополнительный таймер (один таймер работает до соударения тел, другой работает после соударения тел), происходит засечка по времени, чтобы реализовать клавиши «Стоп» и «Продолжение». При этом, эти клавиши активны только когда тела начали свое движение.

Вычислительный эксперимент

Пользователь вводит начальные значения (рис. 1). Важно отметить, что значение второго шара рассчитывается по формуле, поэтому не следует вводить данные.

Рисунок 1 – Начальные значения

Значение y₂ рассчитывается по формуле (1), для получения значения необходимо нажать кнопку «Начало». Напротив, значения y₂ в пустом поле появится значения, а на форме появятся два шара, в указанном месте, с указанными пользователем массой и углом между ними.

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

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

Начальное движение шаров показано на рисунке 2.

Рисунок 2 – Начально движение тел

Как было сказано раннее, для остановки движения тел нужно нажать на кнопку стоп. Для демонстрации правильного функционирования программы, остановим тела на 82 секунде (рис. 3).

Рисунок 3 – Остановка времени

Важно отметить, что при остановке времени, исчезает копка «Старт» и остаются только три копки: «Стоп», «Продолжить», «Начало». Это удобно для пользователя, чтобы он не запутался в назначении кнопок. Для продолжения движения тел, необходимо нажать на кнопку «Продолжить», а для построения новых расчётов ввести новые координаты для тел и нажать на кнопку «Начало». Продолжение движения тел после абсолютно упругого соударения показано на рисунке 4.

Рисунок 4 – Движение тел после соударения

Можно смоделировать ситуацию, когда шары не столкнуться и не произойдет идеальное соударение двух тел. Для этого необходимо ввести угол alfa, равный 90 градусов (рис. 5).

Рисунок 5 – Движение тел без соударения

ЗАКЛЮЧЕНИЕ

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

Ф. Брукс правильно оценил важность тестирования и исправление ошибок: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20 – 50 %) влечет появление новой. Поэтому весь процесс идет по принципу «два шага вперед, шаг назад»». Безусловно, в этом кроется истина. Возникает вопрос, почему нельзя устранять ошибки более аккуратно.

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

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

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

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

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

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

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

Данная задача решена с помощью законов физики при идеальном соударении двух тел. Использованы графические возможности Visual Studio Express 2013.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. А. Лукутин. Аутсорсинг тестирования программного обеспечения // Инфраструктурные изменения, 2015.
2. Г. Майерс. Искусство тестирования программ. – М.: «Финансы и статистика», 2016.
3. В.Н. Цыганенко. Конструирование и тестирование программного обеспечения, 20146
4. Л. Криспин, Д. Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. – М.: «Вильямс», 2015.
5. Cem Kaner, James Bach, Bret Pettichord, Lessons learned in software testing: a context-driven approach. Wiley, 2015
6. Аппаратное обеспечение вычислительных систем. - М.: Маркет ДС, 2016. - 184 c.
7. Вендров, А. М. Практикум по проектированию программного обеспечения экономических информационных систем / А.М. Вендров. - М.: Финансы и статистика, 2014. - 192 c.
8. Гецци, Карло Основы инженерии программного обеспечения / Карло Гецци , Мехди Джазайери , Дино Мандриоли. - М.: БХВ-Петербург, 2016. - 832 c.
9. Гроувер, Д. Защита программного обеспечения / Д. Гроувер, Р. Сатер, и др.. - М.: Мир, 2017. - 283 c.
10. Денисов, Д. В. Аппаратное обеспечение вычислительных систем / Д.В. Денисов, В.В. Артюхин, М.Ф. Седненков. - М.: Маркет ДС, 2015. - 184 c.
11. Дюваль Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска / Дюваль, М. Поль. - М.: Вильямс, 2016. - 240 c.
12. Информатика и ИКТ. Методическое пособие для учителей. Часть 2. Программное обеспечение информационных технологий / Под редакцией Н.В. Макаровой. - М.: Питер, 2015. - 432 c.
13. Котляров, В. П. Основы тестирования программного обеспечения / В.П. Котляров, Т.В. Коликова. - М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2017. - 288 c.
14. Котляров, В. П. Основы тестирования программного обеспечения / В.П. Котляров, Т.В. Коликова. - М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2015. - 288 c.
15. Кузнецова, Т.В. Делопроизводство (документационное обеспечение управления) / Т.В. Кузнецова. - М.: Управление персоналом, 2014. - 200 c.
16. Кузнецова, Т.В. Делопроизводство. Организация и технологии документационного обеспечения управления / Т.В. Кузнецова, Л.В. Санкина, Т.А. Быкова, и др.. - М.: Юнити-Дана, 2017. - 359 c.
17. Левенталь, Л. Введение в микропроцессоры: Программное обеспечение, аппаратные средства, программирование / Л. Левенталь. - М.: Энергоатомиздат, 2016. - 464 c.
18. Мартин, Дж. Вычислительные сети и распределенная обработка данных: программное обеспечение, методы и архитектура / Дж. Мартин. - М.: Финансы и статистика, 2015. - 525 c.
19. Першина, Эльвира Сабировна Деловая Игра «Выбор Программного И Аппаратного Обеспечения Компьютерной Системы» / Першина Эльвира Сабировна. - Москва: СИНТЕГ, 2017. - 226 c.
20. Пшенко, А.В. Делопроизводство. Документальное обеспечение работы офиса / А.В. Пшенко. - М.: Академия, 2016. - 176 c.
21. Пшенко, А.В. Документационное обеспечение управления (Делопроизводство): Учебное пособие / А.В. Пшенко. - М.: Форум, 2016. - 256 c.
22. Регрессионное тестирование. URL: http://aplana.ru/services/ testing/functionalnoe-testirovanie/regressionnoe-testirovanie (дата обращения 25.08.2019).
23. Тестирование установки. URL: http://aplana.ru/services/ testing/functionalnoe-testirovanie/testirovanie-ustanovki (дата обращения 25.08.2019).
24. Конфигурационное тестирование. URL: https://www.testlab2. com/ru/configurational-testing.html (дата обращения 22.08.2019).
25. Этапы тестирования. URL: http://testingworld.ru/category/этапы-тестирования/ (дата обращения 13.08.2019).
26. А. Ибрагимов. С #. URL: http://megaobzor.com/yazyk-C-si-sharp---novyy-lider-v-srede-programmirovaniya-.html (дата обращения 14.08.2019).
27. Microsoft Visual Studio. URL: https://www.microsoft.com/rus/business/smb/products-list/visualstudio2010/ (дата обращения 18.08.2019).