Файл: Отладка и тестирование программ: основные подходы и ограничения (Применение отладки при разработке программного обеспечения).pdf

Основные методы тестирования для объектно-ориентированных программ – это модульное тестирование (выполняет тестировщик классов); интеграционное тестирование (выполняет тестировщик целостности); системное тестирование (выполняет системный тестировщик)^[41]. Модульное и интеграционное тестирования – это особые формы внутреннего базового тестирования, в которых применяют средства автоматизации.

Модульное тестирование – это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование проводится по принципу «белого ящика», т.е. основывается на знании внутренней структуры программы и часто включает те или иные методы анализа покрытия кода. В ходе данного тестирования разрабатываются тестовые драйверы для проверки функциональности, входящие в класс методов. При тестировании классов тестовый драйвер создаёт один или большее число экземпляров тестируемого класса и осуществляет прогон тестовых случаев. Пример оформления результатов модульного тестирования приведён в таблице 1^[42].

Таблица 1

Результаты модульного тестирования

Интеграционное тестирование – тестирование корректного взаимодействия классов, входящих в различные модули. Тестирование основано на принципе «белого ящика». Тестировщик целостности должен быть специалистом как в области разработки программных продуктов, так и в области тестирования. Взаимодействие объектов представляет собой запрос одного объекта на выполнение другим объектом одной из операций получателя и всех видов обработки, необходимых для завершения этого запроса^[43].

Наиболее часто используют два направления интеграции объектно-ориентированных систем: тестирование, основанное на потоках, и тестирование, основанное на использовании^[44]. Для первого направления объектом интеграции является набор классов, обслуживающий единичный ввод данных в систему. Иными словами, средства обслуживания каждого потока интегрируют и тестируют отдельно. Согласно второму вначале интегрируют и тестируют независимые классы. Далее работают с первым слоем зависимых классов (которые используют независимые классы), со вторым слоем и т.д. Выбор одного из способов тестирования зависит от особенностей конкретного ПО, например, первое направление хорошо работает для тестирования систем управления базами данных (СУБД), а второе – для тестирования задач математического моделирования. Достаточность количества тестов для первого направления определяется просмотром потоков данных из всех классов эквивалентности. Для второго направления реализованы методики, позволяющие писать тестовые драйверы на основе тестирования разбиений или состояний^[45].

Необходимой документацией для проведения тестирования на основе состояний также служит диаграмма схем состояний, которая фиксирует динамику поведения класса. Этот способ предоставляет возможность получить набор тестов, проверяющих поведение класса и некоторых других классов, которые сотрудничают с ним. Разработанные тесты должны обеспечить покрытие всех состояний. То есть эти тесты должны пройти через всевозможные переходы через все состояния объекта. Для каждого такого перехода следует написать тестовый драйвер. Остальные состояния тестируются по аналогичной схеме^[46].

Пример оформления результатов интеграционного тестирования представлен в таблице 2.

Таблица 2

Результаты интеграционного тестирования^[47]

Системное тестирование – это тестирование по принципу «чёрного ящика» правильности функционирования системы в целом. Системный тестировщик рассматривает ПО с точки зрения пользователя. Особую роль системное тестирование приобретает для тестирования распространённых в настоящее время веб-приложений и распределённых систем^[48].

В процессе построения набора тестов при функциональном (системном) тестировании необходимо проверить^[49]:

− полноту реализации функциональных возможностей системы;

− эффективность защиты от искажения данных и некорректных действий;

− качество пользовательского интерфейса программы;

− тестирование практичности; тестирование баз данных;

− тестирование надёжности и доступности;

− корректность документации.

Системное тестирование также включает оценочное тестирование:

− тестирование удобства пользования;

− стрессовое тестирование, тестирование безопасности;

− тестирование производительности на разной аппаратуре;

− тестирование удобства установки и обслуживания, совместимости.

Стрессовое тестирование проводят при повышенных запросах на ресурсы системы (по количеству, частоте, размеру-объёму). Тестирование безопасности проверяет фактическую реакцию защитных механизмов, встроенных в систему, на проникновение. В ходе тестирования безопасности тестировщику разрешается найти ключ входа в систему, используя некоторые данные, и выполнить атаку системы с помощью специальных утилит, анализирующих защиты^[50].

Тестирование производительности проверяет скорость работы ПО в компьютерной системе.

Для системного тестирования ПО реализованы следующие методики формирования тестовых наборов^[51]: эквивалентное разбиение для входных данных; анализ граничных значений; предположение об ошибке, использование UML-диаграммы взаимодействия, UML-диаграммы деятельности, а также UML-диаграммы схем состояний разрабатываемого ПО. Пример оформления результатов системного тестирования приведён в таблице. 3.

Таблица 3

Результаты системного тестирования^[52]

Особое внимание стоит уделить методике системного тестирования ПО, предназначенного для работы в Интернете. Существует четыре основных отличия между локальными и распределёнными вычислениями, которые следует учитывать при тестировании веб-приложений: реактивность (время реакции системы), латентность (разница во времени доступа к удалённым и локальным объектам), возможный частичный отказ в сети и параллелизм операции с данными^[53].

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

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

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

Тестирование баз данных – важная составляющая тестирования веб-приложений, поскольку информация на веб-узлах обычно хранится в базах данных. В некоторых приложениях^[55] есть данные, вводимые пользователем, которые затем становятся частью баз данных.

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

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

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

Производительность веб-приложений оценивается по двум «меркам»: реактивность и расширяемость^[57]. Реактивность – это способность системы соответствовать требуемым значениям времени отклика системы. Расширяемость – это способность системы соответствовать значениям времени реакции при возрастающих требованиях к функциям программного обеспечения. Расширяемость не менее важна для поддержки реактивности при увеличении числа посетителей сайта. Стоит отметить, что значения этих параметров необходимо фиксировать и включать в документацию по тестированию.

Таким образом, были проведены анализ и оценка методов, которые необходимы для проведения тестирования для определённого программного обеспечения – в данном случае для объектно-ориентированных систем, веб-приложений и распределённых систем. Было отмечено соответствие каждого вида тестирования конкретному типу ПО и разделения между этими видами. В дальнейшем работа по анализу и оценке методов тестирования будет развиваться, затрагивая уже другие области ПО^[58].

3.2. Отличия и взаимосвязь ручного и автоматизированного тестирования ПО

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

Во избежание подобных ситуаций разработаны специальные автоматизированные тесты, при которых задействуются программные средства тестирования и проверки результатов его выполнения. Автоматизированное тестирование ПО позволяет упростить процесс и сократить время тестирования. К таким программным средствам относят различные тестовые фреймворки и инструменты на базе определенных языков программирования, позволяющие запрограммировать тестовые сценарии. Примерами таких фреймворков и инструментов являются Google testing framework, TestNG, Junit, Selenium, Selenide, Protractor и другие. Автотесты, написанные при их помощи различных позволят в короткие сроки проверить большой объем программного кода, конечно же, при условии, что реализовано должное покрытие кода^[60].

Казалось бы, если вдруг придется поставить выбор между трудоемким, трудозатратным и продолжительным по времени ручным тестированием и разработкой автоматизированных тестов, выбор очевиден в пользу автоматизации. Но, как показывает практика, такой выбор не всегда является верным. Автоматизированные тесты достаточно трудоемки, и их разработка требует длительного промежутка времени и, как правило, отдел тестирования не успевает дописать автоматизированный тест, так как за время его разработки часть программного кода тестируемого приложения может быть изменена и дополнена новыми частями. В результате чего стопроцентное покрытие программного кода осуществить практически невозможно. Как правило, автоматизированные тесты покрывают неизменную, постоянную часть программного кода. Это связано с тем, что исправление одной ошибки может повлечь за собой появление новой, отследить которую вручную весьма трудно^[61].