Файл: Тестирование производительности программ: подходы в зависимости от категорий приложений.pdf

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

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

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

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

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

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

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

Достоинствами такого подхода является отсутствие необходимости создания дополнительных скриптов. Поэтому многие разработчики пользуются этим способом для экономии времени. При этом разрабатываются необходимые тесты, с помощью которых проверяется вся система сразу. При этом возникает ряд трудностей[3]:

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

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

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

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

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

Мнения разработчиков об эффективности этих двух инкрементальных подходов тестирования разнятся[4, 9, 11]. Практически выбор стратегии тестирования производится следующим образом: все модули по возможности тестируется сразу после их создания, поэтому тестирование одних частей программы может происходить в восходящей последовательности, а других – в нисходящей.

2. РАЗЛИЧНЫЕ ПОДХОДЫ К ТЕСТИРОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

2.2 Метод «белого ящика»

Метод «белый ящик» состоит в том, что при создании тестовых случаев программисты используют все данные о внутренней структуре программы и её или коде. Технологии, которые применяются при тестировании методом «белого ящика» представляют собой технологии статического тестирования[8].

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

В тестовых испытаниях методом «белого ящика» применяют управляющую логику процедур. Они выполняют следующие функции:

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

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

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

2.3 Методы тестирования на основе стратегии «белого ящика»

2.3.1 Ввод неверных значений

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

2.3.2 Модульное тестирование

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

2.3.3 Тестирование обработки ошибок

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

2.3.4 Утечка памяти

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