Тестирование и отладка программного обеспечения

2.4.3 Тесты регрессии на "закрытых" багах

Рассмотрим пример. Допустим, что тест № 3, выявивший баг, после  исправления этого бага разработчиком  был проведен повторно, при том  успешно. Тест был отмечен как pass, а баг - как Verified. Такой баг откладывается "на полочку", "дело" закрыто. Такой баг и будет "закрытым". Допустим теперь, что в ходе разработки, участок кода, где был исправлен этот баг был изменен, или сменился разработчик, который случайно удалил "нашлепку" в коде исправлявшую этот глюк и показавшуюся ему лишней и т.п. В этом случае баг проявится снова. Что бы не допустить подобного бета-тестеру время от времени необходимо проводить тесты, выявлявшие ранее баги в измененном участке кода, исправление которых уже было проверено ранее и зафиксировано в базе. Это и есть Тесты регрессии на "закрытых" багах. [2, c. 32-35]

2.5 Каскадное тестирование

Каскадная модель тестирования программных продуктов [Приложение А] предполагает выполнение процедур статического и динамического тестирования.

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

Статическое тестирование является первой частью каскадного тестирования программного обеспечения и включает в себя три этапа:

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

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

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

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

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

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

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

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

 

Заключение

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

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

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

 

 

Глоссарий

№ п/п	Новое понятие	Содержание
1	Аттестация (certification)	авторитетное подтверждение  правильности программы, аналогичное  аттестации электротехнического оборудования Underwriters Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.
2	Доказательство (proof)	попытка найти ошибки в программе безотносительно  к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений  о поведении программы, и затем  вывод, и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предполагают прямого выполнения программы. Многие исследователи считают доказательство альтернативой тестированию — взгляд во многом ошибочный.
3	Испытание (validation)	попытка найти ошибки, выполняя программу в заданной реальной среде.
4	Контроль (verification)	попытка найти ошибки, выполняя программу в тестовой, или  моделируемой, среде.
5	Комплексное тестирование (system testing)	контроль и/или испытание  системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.
6	Отладка (debugging)	не является разновидностью тестирования. Хотя слова «отладка»  и «тестирование» часто используются как синонимы, под ними подразумеваются  разные виды деятельности. Тестирование — деятельность, направленная на обнаружение  ошибок; отладка направлена на установление точной природы известной ошибки, а затем — на исправление этой ошибки. Эти два вида деятельности связаны — результаты тестирования являются исходными данными для отладки.
7	Тестирование (testing)	процесс выполнения программы (или части программы) с намерением (или целью) найти ошибки
8	Тестирование  модуля, или автономное тестирование (module testing, unit testing)	контроль отдельного программного модуля, обычно в изолированной  среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство.
9	Тестирование  настройки (installation testing)	проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
10	Тестирование  приемлемости (acceptance testing)	проверка соответствия программы требованиям пользователя.

 

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

1	Бейзер Б. Тестирование черного  ящика. Технологии функционального  тестирования программного обеспечения и систем [текст] / Б. Бейзер; - Питер, 2004, 320 с. - 5-94723-698-2.
2	Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; - Питер, 2004, 656 с. - 5-94723-663-X.
3	Винниченко И. В. Автоматизация  процессов тестирования [текст] / И. В. Винниченко; - Питер, 2005, 208 с. - 5-469-00798-7.
4	Калбертсон Р., Браун К., Кобб Г. Быстрое  тестирование [текст] / Р. Калбертсон, К. Браун, Г. Кобб; - Вильямс, 2002, 384 с. - 5-8459-0336-X.
5	Касперски К. Техника отладки программ без исходных текстов [текст] / К. Касперски; - БХВ-Петербург, 2005, 832 с. - 5-94157-229-8.
6	Плаксин М. Тестирование и отладка  программ - для профессионалов будущих  и настоящих [текст] / М. Пласкин; - Бином. Лаборатория знаний, 2007, - 168 с. - 978-5-94774-458-3.
7	Синицын С. В., Налютин Н. Ю. Верификация  программного обеспечения. Учебное  пособие [текст] / С. В. Синицын, Н. Ю. Налютин; - Бином, 2008, 368 с. - 5-94774-825-8.
8	Спольски Д. Лучшие примеры разработки ПО [текст] / Д. Спольски; - Питер, 2007, 455 с. - 5-469-01291-3.
9	Тамре Л. Введение в тестирование программного обеспечения [текст] / Л. Тамре; - Вильямс, 2003. - 368 с. - 5-8459-0394-7.
10	Википедия — свободная общедоступная многоязычная универсальная энциклопедия [Электронный ресурс] / www.ru.wikipedia.org

 

Приложение

А
Б

¹ Тестирование белого ящика – англ. white-box testing, также говорят — тестирование  прозрачного ящика)