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

Отладка и тестирование программ: основные подходы и ограничения

Содержание:

Введение

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

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

Разберем немного подробней каждый этап и немного определимся с терминологией:

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

Тестирование программного обеспечения — это процесс исследования программного обеспечения, в результате которого достигаются две цели:

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

Основным международным стандартом, определяющим качество программного обеспечения является стандарт ISO/IEC 25010:2011 (International Organization for Standardization ISO/IEC 25010:2011 [сайт] URL: https://www.iso.org/standard/35733.html ), в Российской Федерации эту функцию выполняет ГОСТ Р ИСО/МЭК 25010-2015, а функцию стандартизации тестирования программного обеспечения ГОСТ Р 56920-2016 (Федеральное агентство по техническому регулированию и метрологии ГОСТ Р 56920-2016 [сайт] URL: http://protect.gost.ru/document.aspx?control=7&id=203397).

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

Конечный поиск причин возникновения ошибки в программе
Устранение возникновения причин найденных ошибок

От надежного функционирования определенных типов программного обеспечения может зависеть успех бизнеса – работы финансовых и промышленных компаний – или даже… человеческая жизнь. Поэтому на его самое тщательное проектирование, разработку и тестирование не жалеют ни времени, ни денег. (Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Сэм Канер, Джек Фолк, Енг Кек Нгуен 2001. - 9с)

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

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

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

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

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

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

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

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

Так вот ответ на этот вопрос не так прост: качество программного обеспечения с точки зрения программиста и конечного пользователя сильно различается и несет в себе совсем различные критерии. Такие критерии делятся на два вида:

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

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

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

Корректность — отсутствие или наличие неточностей в спецификации, проекте и конечной реализации системы

Практичность — легкость обучения использованию системы и ее применение на практике

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

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

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

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

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

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

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

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

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

И так, к внутренним характеристикам программного обеспечения относятся:

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

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

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

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

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

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

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

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

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

Таблица взята из книги Совершенный код / Стив Макконнелл 2010. – 458 с.

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

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

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

Первый метод тестирования, который мы рассмотрим, это Black-Box Testing (Functional) или же тестирование методом Черного Ящика (Функциональное тестирование). Основной принцип данного метода заключается в том, что тестирующий не имеет доступа к внутренним составляющим программы (коду и базам данных), к которым имеют доступ программисты и операторы баз данных, а имеет лишь доступ к тому функционалу управления, к которому имеет доступ обычный пользователь. Соответственно в таком режиме, тестирующий может лишь подавать какие-то данные на вход и анализировать информацию на выходе программы, в данной ситуации программа как будто и является тем самым магическим черным ящиком (с одной стороны в ящик что-то кладут, с другой забирают результат и анализируют принцип работы ящика). Такой метод тестирования хорош, когда надо проверить программу на соответствие заявленным функциональным требованиям, то есть способность программы решать поставленные пользователем задачи при определенных условиях.

Второй метод тестирования, это White-Box Testing (Structural) или же тестирование методом Белого Ящика (Структурное тестирование). Принцип этого метода полностью противоположен методу Черного Ящика и подразумевает, в первую очередь, анализ внутренних составляющих программного продукта. Данный метод может осуществляться только тестирующим со знанием используемого языка программирования и способного анализировать внутреннюю структуру программы. Тестирование методом Белого Ящика подразумевает, что тестирующий имеет полный доступ к коду и всем данным программы. Данная методика тестирования отлично подходит для внутреннего анализа и проверки и улучшения внутренних характеристик качества программного обеспечения.

Также существует смешанная методика проведения тестирования, называется она 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) или «Интерфейс: новые направления в проектировании компьютерных систем» Автор Раскин Джефф.

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

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

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

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

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

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

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

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

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

(Отладка 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.1. Практика тестирования программного обеспечения

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

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

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

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

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

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

Раньше многие компании применяли различные примитивные методы обработки ошибок и их исправления – отчеты о проблемах передавались на бумажных носителях, а стадии их выполнения регистрировались в специальных журналах, но такие методы уже практически не используются в связи с быстрым ростом компьютеризации и появлением множества средств по автоматизации этого процесса. (Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Сэм Канер, Джек Фолк, Енг Кек Нгуен 2001. – 131-132с)

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

Одним из популярных багтрекеров на сегодняшний день является Bugzilla (URL: https://www.bugzilla.org/).

«Bugzilla - приложение для отслеживания ошибок. Приложения подобного рода позволяют разработчику или группам разработчиков отслеживать ошибки в приложениях и запросы на дополнение приложений новой функциональностью. Написанное на Perl, Bugzilla de-facto является стандартом для систем отслеживания ошибок в приложениях, служащая эталоном, с которой сравниваются другие системы со схожей функциональностью. Фактически, Bugzilla используется во многих корпорациях для разработки собственного программного обеспечения для корпоративных нужд.» пишут о Bugzilla ее разработчики. (Russian Mozilla Team URL: http://mozilla-russia.org/products/bugzilla/ )

Bugzilla используют многие крупные проекты, вот список самых известных из них:

Бесплатные проекты:

Веб-браузер Mozilla: https://bugzilla.mozilla.org/

Создатели ядра ОС Linux: http://bugzilla.kernel.org/

Рабочее окружение GNOME: http://bugzilla.gnome.org/

Рабочее окружение KDE: http://bugs.kde.org/

Веб-сервер Apache Project: https://bz.apache.org/bugzilla/

Офисный пакет LibreOffice: https://bugs.documentfoundation.org/

Офисный пакет Open Office: https://bz.apache.org/ooo/

Среда разработки Eclipse: http://bugs.eclipse.org/bugs/

Создатели следующих дистрибутивов ОС Linux:

Red Hat: https://bugzilla.redhat.com/

Gentoo: http://bugs.gentoo.org/

Novell: https://bugzilla.novell.com/

(Сайт Bugzilla URL: https://www.bugzilla.org/installation-list/ ).

Список отчетов об ошибках в Bugzilla

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

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

2.1.2 Основные инструменты тестировщика

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

Персональный компьютер, терминал или рабочая станция. В современном мире вообще что-либо редко делается без помощи компьютера, а у ж тем более разработка программного обеспечения. Для тестирования обязательно запаситесь одним таким, а лучше двумя, это резко повысит эффективность за счет того, что на одном будет запускаться тестируемая программа, а на втором система отслеживания ошибок, в которую вы будете прямо во время тестирования вносить информацию.
Текстовый редактор. Служит для вводы и редактирования руководств, планов тестирования, отчетов, записей, писем. Пользоваться текстовым редактором во время тестирования вы будете очень много, так что лучше позаботьтесь о выборе самого оптимального и удобного для вас варианта.
Процессор планов. Это программа, предназначенная для составления и редактирования информации в иерархическом структурированном виде с возможность сортировки, поиска и фильтрации. Удобна при составлении плана тестирования, списка функций, подробных отчетов и списков задач. Рекомендуется использовать отдельный специализированный процессор планов, а не те ограниченные версии, встроенные в текстовые редакторы.
Редактор электронных таблиц. Поможет вам составить необходимые таблицы для отчетов и прочей документации.
Утилиты для сравнения файлов. Выбор таких утилит достаточно богат. Их функция – сравнивать два файла и выводить список различий между ними, в случае обнаружения таковых. Самые лучшие образцы предлагают перечень действий, которые необходимо выполнить для получения из одного файла другого. Как правило такие программы поставляются вместе с операционными системами, например, в DOS это команда fc, а в Linux команда diff. Но функционал встроенных в операционную систему программ для сравнения файлов довольно скуден и если вы чувствуете его нехватку, то рекомендуется использовать программное обеспечение сторонних разработчиков. Также, стоит обратить внимание, что утилиты сравнения файлов бывают предназначены для сравнения разных типов файлов: двоичных файлов, изображений, текстовых файлов, архивов и других. От их назначения зависит формат вывода отчета после сравнения файлов, это нужно учитывать и использовать под каждую конкретную задачу утилиту, предназначенную для нее.
Просмотровики файлов. Это программы, предназначенные для просмотра информации внутри файлов самых разных форматов.
Конверторы файлов. Конверторы файлов предназначены для преобразования одного типа файлов в другой. Могут работать с различными видами файлов, будь то музыка, тексты, изображения, архивы и так далее. Например, можно с помощью такой программы конвертировать изображение из формата BMP в формат TIFF.
Утилиты для создания скриншотов. Это программы, предназначенные для создания копий экрана и сохранения их в файл на жесткий диск. Возможно на практике понадобится несколько таких программ, так как некоторые из них несовместимы с различными видами видеопотока. Эти средства очень удобны в работе, порой намного проще показать программисту снимок ошибки, нежели пытаться описать ее словами.
Утилиты поиска текста. Позволяют найти в исходном коде программы нужные строки. Простейшие варианты таких утилит встроены в текстовые редакторы.

10) Устройства и утилиты для видео-захвата. Данные средства помогут вам запечатлеть ошибку на видео. Видеозапись является хорошим способом рассказать программисту о увиденной вами ошибке и ваших действиях перед ее появлением.

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

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

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

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

(Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Сэм Канер, Джек Фолк, Енг Кек Нгуен 2001. – 265-266с)

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

2.1.3 Практические методы тестирования ПО

На практике, при тестировании программного обеспечения, необходимо понимать, что никакое разумное количество тестов не даст точной уверенности в том, что программа не имеет ошибок. Вызвано это тем, что тестирующий не в силах перебрать все возможные комбинации входных данных даже для маленькой программы. Например, для тестирования перебора всех входных данных для трех полей Фамилия (20 символов, 26 вариантов каждого символа), Адрес (20 символов, 26 вариантов каждого символа) и Номер телефона (10 символов, 10 вариантов каждой цифры) понадобится 10 в 66й степени тестов, что при переборе в триллион тестов в секунду с момента окончания Всемирного потопа, на данный было бы закончено на 1%. Поэтому стоит сконцентрировать свое внимание на самых эффективных тестах и самых слабых местах программы, куда скорее всего могли попасть ошибки. Для этого разработано и используются на практике несколько основных тестовых методик, каждая из которых применима в той или иной ситуации.

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

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

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

Стоит начать с единицы для последовательного пути выполнения метода
Необходимо прибавлять единицу для каждого из операторов if, while, repeat, for, and и or или их аналогов;

3) Необходимо прибавлять единицу для каждого блока case; если отсутствует блок по умолчанию, прибавляем еще единицу.

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

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

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

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

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

В заключение хочу сказать, что создавая тесты для программ, желательно придерживаться следующего правила: любой тест должен быть таким, чтобы его можно было проверить вручную и отбросить особенности работы ЭВМ, влияющие на качество выполнения теста в определенных условиях. (Совершенный код / Стив Макконнелл 2010. – 496-507 с)

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

В данной главе мы рассмотрим инструменты и методики отладки приложений.

2.2.1 Инструменты отладки программного обеспечения

Основным инструментом во время отладочного процесса является отладчик. Отладчик - это программа, позволяющая искать ошибки в других программах. К отладчикам, например, относится GNU Debugger, который позволяет отлаживать программы, написанные на языках программирования Ada, C, C++, Objective-C, Pascal и многих других языках. (URL: http://www.gnu.org/software/gdb/)

Но также, очень часто отладчики встроены непосредственно в среду разработки, например, в среды разработки Microsoft Visual Studio, Borland C++, Dev-C++, Android Studio, Atmel Studio и другие. Такой подход позволяет разработчикам не искать дополнительного отладочного программного обеспечения, а пользоваться уже встроенным.

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

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

На рисунке изображено типичное окно отладчика

2.2.2 Практические методы отладки программного обеспечения

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

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

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

Определение источника ошибки может занять много времени, если не подходить к нему систематически. Например, если работа осуществляется со списком входных данных и некоторые элементы вызывают ошибку, а некоторые нет – необходимо попытаться сгруппировать их и отсеять в один вид те, что вызывают ошибку. Также необходимо обратить внимание на ту часть кода, которая обрабатывает те или иные входные данные. Что происходит с данными? Чем они связаны? Какой тип данных? Чем похожи? Каков объем данных, их содержание? Ответив на эти вопросы станет намного проще понять причину возникновения ошибки. Составляя гипотезу о возникновении ошибки, необходимо использовать все имеющиеся данные. Если текущая гипотеза проваливается при очередной попытке отладки, необходимо ее улучшить, добавив нюансы новых полученных данных.

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

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

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

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

Чтобы точнее определить происхождение ошибки, необходимо вызывать ее разными способами (рисунок взять из книги Совершенный код / Стив Макконнелл 2010. – 534с)

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

Результаты отрицательных тестов – это тоже результаты, ведь зная, что НЕ ВЫЗЫВАЕТ ошибку, остается больше вариантов что ее ВЫЗЫВАЕТ.

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Сэм Канер, Джек Фолк, Енг Кек Нгуен Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений 2001

Стив Макконнелл Совершенный код 2010

Уильям Е. Левис Software Testing and Continuous Quality Improvement, Second Edition 2005

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

International Organization for Standardization ISO/IEC 25010:2011 [сайт] URL: https://www.iso.org/standard/35733.html

Федеральное агентство по техническому регулированию и метрологии ГОСТ Р 56920-2016 [сайт] URL: http://protect.gost.ru/document.aspx?control=7&id=203397

«Microsoft Windows User Experience» [сайт] URL: https://www.microsoft.com/mspress/books/index/2466a.aspx

Bugzilla [сайт] URL: https://www.bugzilla.org/

Russian Mozilla Team [сайт] URL: http://mozilla-russia.org/products/bugzilla/

GNU debugger homepage [сайт] URL: http://www.gnu.org/software/gdb/