Файл: Понятие о программном обеспечении.pdf

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

Два упомянутых правила определяют порядок этапов при программировании на практике:

1. Красный – создать небольшой тест, что не работает, и даже не компилируется.[17]
2. Зеленый – заставить тест работать так, как можно быстрее.
3. Рефакторинг – удаление из написанного кода любое дублирование.

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

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

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

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

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

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

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

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

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

Модульные тесты на практике покрывают нетривиальные и критические участки кода.

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

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

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

Таким образом, все детали интерфейса появляются до окончательной версии решения.

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

3.2.Цикл практической разработки через тестирование

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

Рисунок 6 – Блок-схема тестирования

Приведенная последовательность действий базируется на книге К. Бека [4]

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

3.3. Описание преимуществ практического применения разработки ПО с помощью тестирования

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

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

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

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

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

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

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

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

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

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

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

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

Тесты также позволяют выполнять рефакторинг кода сводя риска его испортить к нулю.

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

При исследовании были выполнены такие задачи:

– охарактеризованы основные понятия о программных средствах;

– рассмотрена архитектура программных систем;

– рассмотрены основы теории тестирования ПО;

• описаны основные методики и ограничения тестирования;
• на практике рассмотрена последовательность тестирования конкретного ПО выбранным методом.

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

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

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

1. Агальцов В.П. Тестирование ПО. В 2-х томах. Т.1. / В.П. Агальцов.– М.: ИД ФОРУМ,НИЦ ИНФРА-М,2017.–352 c.
2. Агальцов В.П. Тестирование ПО. В 2-х томах. Т.2..–М.: ИД ФОРУМ,НИЦ ИНФРА-М, 2017.–272 c.
3. Бейзер. Б. Тестирование черного ящика. Технологии функционального тестирования ПО и систем. СПб: Питер, 2014. – 318 с, ил.
4. Бек К. Экстремальное программирование. – СПб.: Питер, 2015. – 224 с., ил.
5. Вигерс К. Разработка требований к программному обеспечению / Пер, с англ. — М.: Издательско-торговый дом «Русская Редакция», 2014. —576с.: ил.
6. Виноградова М.С. Математические методы хранения данных. – М.: МГТУ им. Н.Э. Баумана, 2015. – 125 с.
7. Глухих М.И., Ицыксон В.М. Программная инженерия. Обеспечение качества программных средств методами статического анализа. Учебное пособие. СПб: Изд-во Политехн. ун-та. 2017, 150 с.
8. Голицына О.Л. Тестистрирование. Практикум / О.Л. Голицына, Н.В. Максимов, И.И. Попов. – М.: ФОРУМ: ИНФРА-М, 2017. – 452 с.
9. Голицына О.Л. Тестистрирование БД: Учебное пособие/О.Л.Голицына. - М.:Форум, 2015.– 400 c.
10. Гущин А.Н. Безопасность тестирвоания. М.-Берлин: Директ-Медиа, 2015. – 311 с.
11. Диго С.М. Программные системы. Проектирование и создание. – УМК: ЕАОИ, 2015. – 171 с.
12. Калбертсон Р, Браун К., Кобб Г. Быстрое тестирование: Пер. с англ.. – М.: Издательский дом «Вильямс», 2014.– 384 с.: ил.
13. Коберн А. Современные методы описания функциональных требований к системам. М: Издательство «Лори», 2015. 263 с.: ил.
14. Макарова Н.В. Информатика: Учебник для вузов / Н.В. Макарова, В.Б. Волков. – СПб.: Питер, 2015. – 576 с.
15. Мезенцев К.Н. Автоматизированные информационные системы: учебник для студ. учреждений сред.проф. образования - 4-е изд., стер. - М.: Издательский центр "Академия", 2017. - 176 с.
16. Парников П.А. Тесты ПО и работа с ними. М.: Наука.–2015.–200 с.
17. Савин Роман Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах. М.: Наука.–2017.–324 с.
18. Тамре Л. Введение в тестирование программного обеспечения. СПб: Символ-Плюс, 2015. – 332 с., ил.
19. Фаулер М. Рефакторинг. Улучшение существующего кода. – Пер СПб: Символ-Плюс, 2017. – 432 с., ил.. с англ. –
20. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.: Питер, 2015. – 496 с.: ил.