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

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

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

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

2.2 Технические требования к тестированию

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

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

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

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

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

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

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

2.3 Методы тестирования

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

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

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

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

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

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

Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они передаются программе? Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост:

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

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

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

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

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

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

Модифицированный нисходящий метод

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

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

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

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

Метод большого скачка

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

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

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

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

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

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

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

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

Модифицированный метод сандвич

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

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

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

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

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

2.4 Тестирование файлов

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

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

2.5 Средства тестирования

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

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

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

Еще одно необходимое средство тестирования - это возможность хранения тестовых входных данных в целях их повторного использования.

2.6 Оценка полноты проверки программы