Файл: Отладка и тестирование программ: основные подходы и ограничения (Теоретические аспекты отладки и тестирования ПО).pdf

Также существует смешанная методика проведения тестирования, называется она Gray-Box Testing (Functional and Structural), она же тестирование методом Серого Ящика. При использовании данного метода, предыдущие два метода объединяются в один. Часто такой метод осуществляется посредством коммуникаций между тестировщиками и разработчиками. Данный метод подразумевает комбинированный анализ внешних и внутренних характеристик качества программного продукта. (Software Testing and Continuous Quality Improvement, Second Edition – Уильям Е. Левис 2005. – 29-31 с)

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

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

1.2.1 Виды ошибок в программном обеспечении

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

1) противоречивые интерфейсы пользователя;

2) несоответствие ожиданиям;

3) низкая производительность;

4) аварийные завершения или искажение (разрушение) данных.

Разберемся с каждым видом отдельно. Первый вид это противоречивые интерфейсы пользователя, ошибки такого вида подразумевают наличие в программе элементов интерфейса или логики взаимодействия пользователя с программой, грубо нарушающие человеческую логику восприятия процессов, происходящих в программе, или же резкое отклонение от общепринятых стандартов построения интерфейса в программном обеспечении подобного типа. Ярким примером подобной ошибки является то, что в почтовой программе Microsoft Outlook нажатие сочетания горячих клавиш <Ctrl>+<F> открывает сообщение, в то время как пользователь ожидает увидеть открытие окна поиска, как это происходит в подавляющем количестве остального программного обеспечения, а особенно от компании Microsoft. Типичным способом избежать ошибок такого рода является своевременное изучение материалов и литературы, посвященных стандартизации пользовательских интерфейсов, например, издание «Microsoft Windows User Experience» (URL: https://www.microsoft.com/mspress/books/index/2466a.aspx) или «Интерфейс: новые направления в проектировании компьютерных систем» Автор Раскин Джефф.

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

Третий вид ошибок в программном обеспечении - это низкая производительность. Название говорит само за себя, никто не любит, когда новая программа на его компьютере начинает «виснуть» и «тормозить», хотя характеристики вычислительной машины соответствуют заявленным в системных требованиях программного продукта. В первую очередь такая проблема появляется в следствии халатности тестировщиков: тестирование продукта осуществляется на системе, характеристики которой далеки от заявленных или же от типичных характеристик систем, на которых данная программа обычно функционирует. Так же бывают ситуации, при которых тестирующие не имеют возможности или не хотят тестировать программу с реальным объемом данных, с которым ей предстоит работать в производственных условиях. Для профилактики и устранения данной проблемы применяется три основные методики:

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

Четвертый и последний вид ошибок, возникающих в процессе создания программного продукта, это аварийные завершения или искажение (разрушение) данных. Большинство пользователей вычислительных систем, говоря об ошибках, подразумевают в первую очередь как раз этот вид ошибок. Данный вид ошибок характеризуется полной остановкой выполнения программы и невозможностью дальнейшего ее использования. Также при возникновении такой ошибки возможны повреждения обрабатываемых данных. О причинах возникновения подобного рода ошибок судить сложно, это может быть и деление на ноль и запрос программой информации из того места памяти, где такой информации нет, в любом случае причины возникновения данных ошибок разнообразны и пути их решения, соответственно, тоже. Некоторые из них легко устранить, другие же практически не представляется возможным. Типичной ошибкой аварийного завершения является всем знакомый BSoD, он же Blue Screen of Death или в простонародье Синий Экран Смерти, возникающий в операционной системе Windows по ряду причин. Его вы можете видеть на рисунке ниже.

Синий экран смерти

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

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

Среди ошибок процесса разработки выделяют следующие категории:

1. Короткие или недопустимые предельные сроки разработки (возникновение данной ошибки связано с непониманием руководством реальных сроков разработки программного обеспечения и, как следствие, продукт выходит в производственную стадию «сырым», недоделанным)
2. Необдуманное программирование (целый комплекс ошибок, возникающий, когда программист вначале пишет код, а потом уже думает, как этот код работает. Решается составлением четкой структуры проекта до начала его реализации)
3. Неправильное понимание требований (та или иная ситуация, в которой требования заказчика к программному продукты были поняты исполнителем неправильно/не полностью/частично или как-то иначе, что в корне подорвало использование получившегося продукта)
4. Недостаточная подготовленность разработчика (подразумевается, что разработчик не до конца понимает все те технологии, которые будут использованы в процессе разработки конечного продукта. Но не спешите винить программиста, довольно часто это просто связано с появлением огромного количества новых систем, технологий, модулей и прочих нюансов разработки программного обеспечения в короткие промежутки времени и просто неуспеваемостью сотрудников догонять сразу все области, необходимые для качественной работы. Проблема может быть решена отправкой разработчиков на курсы повышения квалификации и выделение большего количества ресурсов на обучение и развитие их навыков)
5. Недостаточные обязательства по качеству (сюда включены все факторы, что не дают разработчикам производить действительно качественный программный продукт, будь то недостаточное финансирование технической части, неправильное распределение бюджета компании при выборе тех или иных инструментов для разработки и так далее)

(Отладка Windows приложений – Дж. Роббинс 2009. ДМК Пресс – 29-35 с)

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

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

1) Осуществление повторяющихся экспериментов с целью сбора данных и составления статистики

2) Выдвижение гипотезы, объясняющей собранные данные

3) Постановка ряда экспериментов, призванных подтвердить или опровергнуть сформировавшуюся гипотезу

4) На основе экспериментов вынести решение о подтверждении или опровержении гипотезы

5) Повторение предыдущих шагов в случае необходимости

(Совершенный код / Стив Макконнелл 2010. – 529 с)

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

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

2) Знание языка программирования, на котором выполнен проект.

3) Знание используемых в проекте технологий. Имеется ввиду COM, MFC, различные другие базовые технологии написания программ. Их знание и понимание принципов их работы значительно упростит отладку и сократив время, затрачиваемое на нее.

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

5) Знание работы центрального процессора. И последнее, что необходимо знать, это логика работы центрального процессора. Любое приложение можно отлаживать на языке программирования Assembler, что в некоторых ситуациях очень даже удобно. Не пожалейте немного своего времени и выучите этот язык, это не раз поможет вам быстро и легко что-то поправить в коде и устранить проблему в работе программы.

(Отладка Windows приложений / Джон Роббинс 2009. – 36-38 с)

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

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

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

2. Практические аспекты отладки и тестирования ПО

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

2.1. Практика тестирования программного обеспечения

На практике при тестировании программного обеспечения ошибка проходит 3 стадии:

1. Обнаружение ошибки
2. Описание ошибки
3. Передача описания ошибки для дальнейшего ее исправления

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

2.1.1 Отчеты об ошибках и системы их обработки

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