Назначение и принципы тестирования. Виды тестирования.

 

Тест — это набор контрольных входных данных совместно с ожидаемыми результатами. В число входных данных времязависимых программ входят события и временные параметры. Ключевой вопрос — полнота тестирования: какое количество каких тестов гарантирует возможно более полную проверку программы? Исчерпывающая проверка на всем множестве входных данных недостижима. Пример: программа, вычисляющая функцию двух переменных: Y=f(X,Z). Если X, Y, Z — real, то полное число тестов (2³²)² = 2⁶⁴ = 10³¹.Если на каждый тест тратить 1мс, то 2⁶⁴ мс = 800 млн лет. Следовательно:

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

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

Детективностъ: тест должен с большой вероятностью обнаруживать возможные ошибки.

Покрывающая способность: один тест должен выявлять как можно больше ошибок.

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

Только на основании выбранного критерия можно определить тот момент времени, когда конечное множество тестов окажется достаточным для проверки программы с некоторой пол­нотой (степень полноты, впрочем, определяется экспериментально). Используются два вида критериев (табл. 5.2):

• функциональные тесты составляются исходя из спецификации программы;

• структурные тесты составляются исходя из текста программы.

На рис. 5.1, а видно отличие тестирования команд (достаточен один тест) от С1 (необходимы два теста, как минимум). Рис. 5.1, б иллюстрирует различие С1 (достаточно двух тестов, покрывающих пути 1, 4 или 2, 3) от С2 (необходимо четыре тес­та для всех четырех путей). С2 недостижим в реальных программах из-за их цикличности, поэтому ограничиваются тремя путями для каждого цикла: 0, 1 и N повторений цикла.

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

Таблица 5.2. Виды критериев и их функциональность

Вид критерия	Функциональность тестов
Функциональные
Тестирование классов входных данных	Содержать представителей всех классов входных или выходных классов и точки на границах классов
Тестирование классов выходных данных
Тестирование функций	Каждая функция внешнего интерфейса должна быть проверена 1 раз и более
Структурные
Тестирование команд	Каждая команда (оператор) должна быть выполнена 1 раз и более
Критерий С1 — тестирование ветвей	Каждая ветвь должна быть выполнена 1 раз и более
Критерий С2 — тестирование путей	Каждый путь в графе программы должен быть выполнен 1 раз и более

 

Рис. 5.1. Траектории вычислений при структурном тестировании: а — тестирование команд и ветвей; б — тестирование ветвей и путей

 

Рассмотрим пример. Найти минимальный набор тестов для программы нахождения вещественных корней квадратного уравнения ах² + bх + с = 0.

Решение представлено в табл. 5.3.

Таблица 5.3. Поиск численного решения минимального набора тестов

№	a	b	с	Ожидаемый результат	Что проверяется
		-5		Х1 = 2, х2 = 0,5	Случай вещественных корней
				Сообщение	Случай комплексных корней
		-12		х1 = 4, Х2 = 0	Нулевой корень
				Сообщение	Неразрешимое уравнение
				Сообщение	Неразрешимое уравнение
				Сообщение	Не квадратное уравнение (деление на 0)
				x1=x2=0	Корень из 0

 

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

По внешней спецификации разрабатываются тесты:

• для каждого класса входных данных;

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

Разрабатываются тесты для тех функций, которые не проверяются в п.1.

По тексту программы проверяется, все ли условные переходы выполнены в каждом направлении (С1). При необходимости добавляются новые тесты.

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

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

Функциональное тестирование дополняется здесь структурным. Классы входных/выходных данных должны быть определены в плане тестирования уже во внешней спецификации. Со­гласно статистике п. 1 и 2 обеспечивают степень охвата С1 в среднем 40—50 %. Проверка по С1 (п. 3) обычно выявляет 90 % всех ошибок, найденных при тестировании. (Все программное обеспечение ВВС США принимается с проверкой по С1).

Систематическое тестирование предполагает также ведение журнала отладки (BugBook), в котором фиксируется ошибка (описание, дата обнаружения, автор модуля) и в дальнейшем — исправление (дата, автор).

Приведем так называемые аксиомы тестирования.

1. Тест должен быть направлен на обнаружение ошибки, а не на подтверждение правильности программы.

2. Автор теста — не автор программы.

3. Тесты разрабатываются одновременно или до разработки программы.

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

5. Предыдущее тестирование необходимо повторять после каждого внесения исправлений в программу.

6. Следует повторять полное тестирование после внесения изменений в программу или после переноса ее в другую среду.

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

 

 

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

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

Одно из наиболее развитых средств автоматизированного тестирования приложений архитектуры “клиент-сервер” RationalTeamTest обеспечивает следующие возможности:

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

· создание многократно используемых тестовых скриптов для тестирования свойств всех объектов приложений;

· поддержка различных средств разработки приложений и языков программирования, в том числе MicrosoftVisualBasic и Visual C++, Java, OracleDeveloper, PowerBuilder;

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

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

NT. Объектное тестирование обеспечивает быстрое создание скриптов, которые в дальнейшем можно легко изменить, создать заново и воспроизвести.

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

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

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

Другое средство — PerformanceStudio предназначено для нагрузочного тестирования приложений архитектуры “клиент-сервер” (тестирования производительности, тестирования при подключении большого числа пользователей, стрессового тестирования и тестирования на больших объемах данных). PerformanceStudio тестирует работу системы, в точности имитируя работу реальных пользователей, оценивает и предсказывает поведение клиент-серверных систем в реальных условиях.

Дополнительную информацию по данным средствам можно получить на сайте Rational Software Corporation (http://www.rational.com).