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

Часто для  свободного/открытого программного обеспечения стадия Альфа-тестирования характеризует функциональное наполнение кода, а Бета тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям. [6, c. 17-19]  
2 Методы тестирования программного обеспечения

2.1 Восходящее и нисходящее тестирование

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

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

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

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

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

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

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

При этом подходе немедленно возникает два вопроса: что делать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются «модули-заглушки», которые моделируют функции отсутствующих модулей. Фраза «просто напишите заглушку» часто встречается в описании этого подхода, но она способна ввести в заблуждение, поскольку задача написания «заглушки» может оказаться трудной. Ведь заглушка редко сводится просто к оператору RETURN, поскольку вызывающий модуль обычно ожидает от нее выходных параметров. В таких случаях в заглушку встраивают фиксированные выходные данные, которые она всегда и возвращает. Это иногда оказывается неприемлемым, так как вызывающий модуль может рассчитывать, что результат вызова зависит от входных данных. Поэтому в некоторых случаях заглушка должна быть довольно изощренной, приближаясь по сложности к модулю, который она пытается моделировать.

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

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

Нисходящий метод тестирования имеет, к сожалению, некоторые недостатки. Основным из них является тот, что  модуль редко тестируется досконально сразу после его подключения. Дело в том, что основательное тестирование некоторых модулей может потребовать крайне изощренных заглушек. Программист часто решает не тратить массу времени на их программирование, а вместо этого пишет простые заглушки и проверяет лишь часть условий в модуле. Такой план тестирования определенно не лучшее решение, поскольку об отложенных условиях часто забывают. Второй тонкий недостаток нисходящего подхода состоит в том, что он может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того, как вся программа будет полностью спроектирована. Эта идея на первый взгляд кажется экономичной, но обычно дело обстоит совсем наоборот. [8, c. 14-25]

2.2 Метод сандвича

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

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

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

Метод сандвича сохраняет  такое достоинство нисходящего и восходящего подходов, как начало интеграции системы на самом раннем этапе. Поскольку вершина программы вступает в строй рано, мы, как в нисходящем методе, уже на раннем этапе получаем работающий каркас программы. Поскольку нижние уровни программы создаются восходящим методом, снимаются те проблемы нисходящего метода, которые были связаны с невозможностью тестировать, некоторые условия в глубине программы. [7, c. 31-34]

2.3 Метод белого и черного ящика

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

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

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

Если «альфа-» и  «бета-тестирование» относятся к  стадиям до выпуска продукта (а  также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом  ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков  обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя программное обеспечение уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы/процесса). [1, c. 11-28]

2.4 Регрессионное тестирование

Одним из важных моментов качественного тестирования программного обеспечения является проведение так называемого регрессионного тестирования (тестов регрессии). Часто эта группа тестов проводится не в полном объеме или не проводится вообще.

Под регрессионным тестированием понимают те виды тестов, которые проводятся с каждой новой версией программы. Иными словами, тесты регрессии - это своего рода "старые песни о главном". Цель проведения этих тестов проста - убедиться, что новая версия программы не содержит ошибок в уже протестированных участках кода. По данным зарубежных авторов количество ошибок, возникающих в процессе изменения кода (исправления багов, внедрения новой функциональности и т.п.) колеблется от 50% до 80%. Выявить эти ошибки и помогают тесты регрессии. [2, c. 12-16]

Таким образом, регрессионное  тестирование - понятие комплексное.

2.4.1 Верификационные тесты

• Тесты верификации багов. Представляют собой тесты проверки исправления багов. Приведем пример. Допустим, что тест с номером 3 выявил баг, что было зафиксировано и передано разработчику для исправления. Через определенное время Вы получили от разработчика новую версию программы, с информацией о том, что описанный баг исправлен. Ваша задача - провести тест с номером 3 повторно - для того, чтобы убедиться, что баг действительно больше не проявляется. В случае успешного прохождения теста такой баг помечается как Verified, в противном случае - как re-do, о чем сообщается разработчику и передается на доработку. Проведение таких тестов является обязательным, так как причин из-за которых исправленный баг может сохраниться в программе - множество (от ошибочного описания, а, возможно, и понимания проблемы, до ошибочного утверждения о том, что исправление имело место). [2, c. 16-19]

• Тесты верификации. Представляют собой набор тестов для проверки сохранности основной функциональности в каждой новой версии программы. Иными словами - это краткое тестирование всех основных функций разрабатываемого программного обеспечения, цель которого - убедится, что программа "работает нормально", что основная функциональность программы не нарушена. Если хотя бы один из тестов верификации версии выявляет баг - то тестер возвращается к предыдущей (последней "рабочей"), дальнейшей тестирование новой версии не проводится, а информация об ошибке вносится в базу и отправляется разработчику. Тесты верификации версии представляют собой краткий набор основных тестов функциональности. [2, c. 21-27]

2.4.2 Тесты регрессии

Под этим понятием объединяют те тесты, которые уже проводились  с предыдущими версиями программы, притом успешно, т.е. не выявили багов и были отмечены (например, в TCM) как pass (passed). Необходимость проведения таких тестов очевидна. Приведем пример. Допустим, что ранее проведенный тест № 2, который обеспечивал проверку в программе участка кода (назовем его условно кодом-А) не выявил ошибок в программе, и был отмечен как pass. В ходе разработки возникла необходимость изменить участок кода-А (например, при исправлении какого либо иного бага или же придания программе новой функциональности). В результате этот участок кода требует дополнительной проверки, что и будет сделано при повторном проведении теста № 2. Среди Собственно Тестов Регрессии можно выделить две группы. Первая - тесты, входящие в набор (т.н. Regression Test Pass with Regression Test Suit), другие - тесты не входящие в набор (т.н. Regression Test Pass without Regression Test Suit). Существенные отличия между ними в следующем: первые - вносятся в базу и описываются, для них могут и должны быть созданы скрипты, которые позволяют автоматизировать процесс тестирования; вторые - существуют только "в голове" тестировщика и проводятся в ручную, причин этого может быть много - от малых сроков тестирования, до отсутствия необходимого ПО, для автоматизации процесса. [2, c. 28-31]