Внедряйте автоматизированное тестирование

Блог Форсайт

12.04.2018

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

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

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

Но как?

Если бы все было так просто… Но, наверняка, есть какие-то подводные камни?! Конечно, есть, но тут-то мы и постараемся помочь не растеряться и с достоинством выйти из сложных ситуаций, ответив на вопросы, «что?», «где?» и «как лучше?».

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

Введение

В этой статье рассмотрим два вида тестирования:

1. Тестирование ядра.

2. Тестирование сервисов.

Поясним, чем один вид тестов отличается от другого.

Тест на ядро – это тест, который проверяет необходимые модули или классы на корректность работы. Например, есть класс SqlHelper, который упрощает выполнение SQL запросов. У данного класса есть метод Execute, который позволяет выполнить указанный SQL запрос. Тест, который создает экземпляр класса SqlHelper и проверяет работу метода Execute, – тест на ядро.

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

Инструменты автоматизации

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

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

2. С ростом числа тестов растет и время их выполнения. Появляется потребность в возможности распараллеливания выполнения тестов.

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

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

5. В платформе существуют собственные языки программирования (ЯП) Fore и Fore.NET, нужна возможность создания тестов на данных языках.

Теперь платформа предоставляет инструмент для автоматического тестирования – TestRunner.exe. Он позволяет выполнять тесты, написанные на Fore, Fore.NET, C#. Инструмент предоставляет следующий функционал:

1. Каждый тест выполняется в отдельном (дочернем) процессе. Для отладки есть возможность выполнения тестов в одном процессе.

2. Распараллеливание выполнение тестов.

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

4. Интеграция со сторонним .NET приложением. Во время выполнения тестов по мере появления результатов может отправлять их другому .NET приложению.

5. Формирование итогового отчета. По завершению тестирования формируется xml файл с результатами всех тестов. В дальнейшем этот файл можно использовать в стороннем приложении для визуализации данных.

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

Параметры командной строки для запуска TestRunner:

–pck=<путь до папки с тестами>. Указывает путь, где лежат тесты. Обязательный параметр.

–type=core|services. Указывает тип тестирования.

core – тесты на ядро.

services – тесты на сервисы. Для этого вида тестов TestRunner будет управлять процессом сервисов, перезапускать при необходимости.

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

–parallel=<число> – указывает необходимость выполнения тестов в параллельном режиме. Количество параллельных потоков будет равно количеству ядер в операционной системе, умноженной на указанное значение.

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

TestRunner в папке с пакетами тестов ищет все файлы с расширением *.test. В этих файлах содержатся метаданные тестов, пути до файлов с исходным кодом теста, его зависимостей и пр. Далее инструмент выполняет компиляцию исходных кодов и запускает тест на выполнение.

Создание теста

Каждый тест состоит минимум из двух частей:

1. Xml файл с расширением *.test, где хранятся метаданные теста.

2. Файл с кодом теста на одном из доступных ЯП.

Ниже пример файла с метаданными теста:

<Test Platform="X86" CrossPlatform="true"> <AreaPath>P7\Reporting</AreaPath> <Description>Описание теста </Description> <ActionList> <Frt Sub="MainEAX" Result="NoErrors" SysRef="Dimensions;Express " Src=".\TEST.p4m" Id="724BF157-8167-4919-9090-23B8828E2C0C" /> </ActionList> </Test>

Каждый тест начинается с тэга Test, который содержит атрибуты:

Platform – указывает разрядность процесса TestRunner, для которого можно выполнять тест. Допустимые значения: X86|X64|Any.

CrossPlatform – указывает, является ли тест кроссплатформенным. Если атрибут содержит значение false, значит, тест выполняется только для Windows, иначе можно выполнять и на Windows, и на Unix системах.

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

Test содержит следующие дочерние тэги:

AreaPath – название (путь) функционального блока, который покрывает тест.

Description – описание назначения теста, его особенностей.

ActionList – тэг-контейнер, в котором содержатся описания тестов для конкретного языка программирования. Название дочерних тэгов определяет язык программирования и вид тестирования.

Допустимые значения:

1. Frt – тест на ядро, написанный на Fore.

2. ForeNet – тест на ядро, написанный на Fore.NET.

3. CSharp – тест на ядро, написанный на C#.

4. CSharpSrv – тест на сервисы, написанный на C#.

Каждый из этих тэгов имеет атрибуты:

Result – ожидаемый результат теста. Допустимые значения:

1. RuntimeError – ожидается ошибка во время выполнения.

2. CompilationError – ожидается ошибка компиляции.

3. AssertFailed – ожидается, что будут ошибки при выполнении проверок через Debug.Assert.

4. NoErrors – тест должен выполниться без ошибок.

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

Src – путь до файла с исходным кодом теста. Путь задается относительно текущего размещения xml файла.

Id – уникальный идентификатор теста.

Точка входа в тест зависит от языка программирования, на котором он реализован.

1. Для Fore точка входа задается через дополнительный атрибут тэга Frt:

Sub – имя процедуры, которое нужно вызвать у Fore модуля.

2. Для тестов на Fore.NET и C# выполняется поиск классов, которые унаследованы от класса TestCase, чья реализация хранится в AutoTools.Sys.dll. Далее TestRunner вызывает метод DoExecute, который и должны реализовать тесты.

Ниже пример test файла и исходного кода теста на Fore.NET:

<?xml version="1.0" encoding="windows-1251"?> <Test CrossPlatform="true"> <AreaPath>P7\Development Tools\Fore.NET Language</AreaPath> <Description> Тест на дефекты 861740 и 783910 </Description> <ActionList> <ForeNet Src="Test.fn" SysRef="" Result="NoErrors" Id="973c7a29-c2bc-4ab0-a8a6-6e73b2bf753e" /> </ActionList> </Test>

Файл Test.fn

Imports System; Imports Prognoz.Platform.Interop.Metabase; Imports AutoTools.Sys; Public class Testsome : TestCase Protected m_bRes : boolean; Public Sub Main(); Begin m_bRes := true; // Код теста End Sub; Protected Override function DoExecute() : boolean; Begin main(); return m_bRes; End function; End Class;

На строке 3 выполняется подключение библиотеки AutoTools.Sys, в которой лежит реализация класса TestCase. Далее объявляется класс Testsome, который наследуется от TestCase. Внутри класса Testsome переопределяется метод DoExecute, который будет вызван TestRunner на выполнение.

И это все?

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