АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ НА ЯЗЫКЕ ПРОГРАММИРОВАНИЯ C# В ИНТЕГРИРОВАННОЙ СРЕДЕ РАЗРАБОТКИ MICROSOFT VISUAL STUDIO

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

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

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

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

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

Как правило, для автоматизированного тестирования строят отдельные программные модули, которые в последующем не включаются в комплект поставки программного продукта и являются внутренним инструментом для компании – разработчика. Разберем на практическом примере разработку автоматизированных тестов в среде Visual Studio.

Тем самым модулем или инструментом, о котором говорилось выше, в Visual Studio является проект модульного тестирования – UnitTestProject (см. Рис. 1).

Рисунок 1 Создание проекта модульного тестирования

Предположим, что стоит задача протестировать реализацию алгоритма бинарного поиска. Алгоритм в качестве входных данных получает массив отсортированных по возрастанию целых чисел int[] и число, которое необходимо найти. В ответ возвращает индекс наqденного элемента массива, либо -1, если число отсутствует в массиве. В первую очередь составим реализацию данного алгоритма (см. Рис. 2).

Рисунок 2 Листинг кода реализации алгоритма бинарного поиска

Известно, что необходимо реализовать следующие проверки:

1. Поиск одного элемента в массиве из 5 элементов;
2. Поиск среди отрицательных чисел;
3. Поиск отсутствующего в массиве элемента;
4. Поиск элемента, повторяющегося несколько раз;
5. Поиск в пустом массиве (содержащем 0 элементов);
6. Поиск в массиве из 100001 элементов.

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

Для того, чтобы автоматически протестировать, код написанный на C#, как уже говорилось, в первую очередь необходимо создать проект модульного теста. Для этого следует выполнить ряд команд, а именно: меню «Файл» - «Добавить» - «Новый проект» - «Установленные» - «Тест». В списке шаблонов выберите проект модульного теста, назначьте наименование, выберите папку для сохранения. После нажатия кнопки «ОК» будет создан проект и развернут шаблон тестового класса с соответствующими членами. Затем необходимо с помощью ссылок и дериктивы using связать два проекта между собой в рамках одного решения. После чего с данным шаблоном можно начать работу, реализовывая в нем необходимые проверки.

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

Приведем созданный тестовый класс и разберем его члены. Листинг кода данного класса (с комментариями и пояснениями) приведен ниже на Рис. 3:

Рисунок 3 Листинг кода тестового класса

Ключевыми для тестового класса являются следующие атрибуты:

1. Атрибут [TestClass] является обязательным для всех тестовых классов, содержащих соответствующие методы, результат работы которых будет доступен в обозревателе тестов;
2. Атрибут [TestMethod] – этим атрибутом помечаются все методы, которые должны быть выполнены в обозревателе тестов.

Кроме этого, еще одной особенностью является использование классов Assert, докладывающих о корректности поведения тестируемого кода. Например, в нашем примере использовался метод Assert.AreEqual(int, int), принимающий, очевидно 2 параметра – expected result - ожидаемый, заведомо верный результат, actual result – результат, сгенерированный тестируемым кодом.

После сборки и выполнения проекта модульных тестов будет запущен обозреватель тестов (см. Рис. 4). В котором будет отображено, какие тесты были пройдены – помечены зеленым, а какие провалены – помечены красным.

Рисунок 4. Обозреватель тестов

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

Список литературы:

1. Савин Р. Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах. – М.: Дело, 2007. —312 с.;
2. Кент Бек. Экстремальное программирование: разработка через тестирование: учеб. пособие. С-П.: Питер, 2005. — 224 с.;
3. Пошаговое руководство. Создание и запуск модульных тестов для управляемого кода// MSDN Library. — 2016. [электронный ресурс] — Режим доступа. — URL: https://msdn.microsoft.com/ru-ru/library/ms182532.aspx (дата обращения 8.11.2017).