CC BY
49
УДК 004.9 ББК 32.81 Т 19
Таран Виктория Николаевна
Кандидат технических наук, доцент кафедры информатики и информационных технологий гуманитарно-педагогической академии (филиал) ФГАОУ ВО «Крымский федеральный университет им. В.И. Вернадского» в г. Ялте, Ялта, тел. (879) 7611679, e-mail: victoriya_yalta@ukr.net Щербина Иван Олегович
Студент гуманитарно-педагогической академии (филиал) ФГАОУ ВО «Крымский федеральный университет им. В.И. Вернадского» в г. Ялте, Ялта, тел. (879) 7611679, e-mail: pshenishniyd@gmail.com
Технологии автоматизации тестирования и их внедрения в процесс создания игровых приложений
(Рецензирована)
Аннотация. Рассмотрены технологии тестирования программного обеспечения на примере разработки игровых приложений. Приводятся способы уменьшения трудоемкости за счет применения средств автоматизации, позволяющих увеличить скорость выполнения тест-кейсов, снизить влияние человеческого фактора в процессе их выполнения, минимизировать затраты при многократном выполнении тест-кейсов, выполнять тест-кейсы, непосильные человеку ввиду сложности, скорости и других причин, а также собирать, хранить и обрабатывать большие объемы данных. Разработана схема процесса внесения изменений во время непосредственной разработки программного решения. Рассмотрено статическое и динамическое тестирование и их варианты: локальное и тестирование на сервере. Были выделены три проблемы в данном подходе: обязательность установки хуков, «лишние» ошибки, время выполнения. Рассмотрены пути устранения данных проблем. Предложена схема процесса проверки работы хуков. Рассмотрены следующие методы динамического анализа программ: тесты с частичным покрытием или «дымные тесты», тесты производительности, специфичные для игр автоматизированные тесты, эмуляция действий пользователя. Приведены технические характеристики static-tests. Получена схема зависимости теста от ресурсов. Разработано ядро для запуска автоматизированного статического тестирования, за счет чего появилась возможность тестирования на ранних этапах разработки программного обеспечения.
Ключевые слова: статическое и динамическое тестирование, static-tests, тестирование программного обеспечения, «дымные» тесты, ядро для запуска автоматизированного статического тестирования.
Taran Viktoriya Nikolaevna
Candidate of Technical Sciences, Associate Professor of Department of Informatics and Information Technology, Humane-Pedagogical Academy (brunch) V.I. Vernadsky Crimean Federal University in Yalta, Yalta, ph. (879) 7611679, e-mail: victoriya_ualta@ukr.net Shcherbina Ivan Olegovich
Student, Humane-Pedagogical Academy (brunch) V.I. Vernadsky Crimean Federal University in Yalta, Yalta, ph. (879) 7611679, e-mail: pshenishniyd@gmail.com
Test automation and implementation technologies in the process of creating game applications
Abstract. Software testing technologies are considered using an example of game application development. The paper describes methods of reducing labour intensity through the use of automation tools, which increase the speed of test cases execution, reduce the influence of the human factor in the process of their execution, minimize the cost of multiple test cases execution, perform test cases that are not acceptable to a person due to complexity, speed and other reasons, as well as collect, store and process large volumes of data. A diagram is developed to show the process of making changes during the direct development of the software solution. The publication considers static and dynamic testing and their variants: local and server testing. Three problems in this approach are identified: mandatory installation of hooks, "extra" errors and execution time. Ways to resolve these problems are discussed. Proposed is a diagram of the process of checking hook operation. The following methods of dynamic program analysis are considered: partial coating tests or "smoke tests", performance tests, game-specific automated tests and emulation of user actions. Technical characteristics of static-tests are given. The test resource dependency scheme was obtained. A core was developed to run automated static testing, which made it possible to test on early software development sites.
Keywords: static and dynamic testing, static-tests, software testing, "smoke" tests, a core to start automated static testing.
Контроль качества является не менее важной составляющей процесса разработки программного продукта, чем сама разработка. Мало просто произвести некоторый продукт, нужно быть уверенным в его качестве прежде, чем предложить его пользователю. Испытания, направленные на определение недостатков в продукции, проводятся в каждой области.
Оценка и тестирование могут проводиться не только экспертами в процессе лицензирования, но и разработчиком (по время тестирования и верификации), а также и заказчиком (в процессе приема программного обеспечения (ПО) в эксплуатацию) [1]. Программные комплексы не отличаются в вопросах контроля качества от других продуктов или товаров, хотя на первый взгляд может показаться, что просчеты в их работе не столь критичны, как, например, ошибки при строительстве дома.
К процессам валидации и разработки ПО применяются международные стандарты, такие, как ISO/IEC 9126 или FDA-1997-D-0029. Выбор стандарта, в первую очередь, зависит от области применения данного программного продукта. Например, чтобы иметь право выпускать ПО для медицинского оборудования в США, разработчик должен пройти сертификацию FDA. Для авиационной отрасли широко применяется сертификация программного обеспечения на соответствие стандарту КТ-178В. Современное развитие любой отрасли связано с развитием информационных технологий. Ошибка в приложении может быть разной степени критичности - от небольшой задержки в компьютерной игре до существенных финансовых потерь. Соотношения частоты появления ошибки, уровня целостности системы и уровня риска при сбое системы приводятся, например, в стандарте ГОСТ Р ИСО/МЭК 15026-2002 [2].
Таким образом, тестирование является важнейшей частью разработки программного продукта. Оно позволяет не только сократить затраты на исправление ошибок, выявив их на ранних стадиях развития, но и снизить риск больших финансовых и репутационных потерь компаний в случае критических ошибок. Автоматизация тестирования - новая область, которая развивается в эпоху, когда классические научные конференции уступают место профильным: GDC, CppCon, White Nights.
Кроме того, обследования (тестирования) чаще всего проводятся с непосредственным участие человека на всех этапах, что повышает влияние человеческого фактора на точность и конечное заключение о состоянии [3] программного продукта.
Итак, пусть имеется программное обеспечение, в котором могут возникать ошибки, сбои. Для их выявления необходимо проводить всестороннее тестирование, которое может занимать большие человеческие, технические и временные ресурсы. Автоматизация процессов тестирования могла бы улучшить качество продукта, снизив затрачиваемые ресурсы.
Целью данного исследования является анализ технологий тестирования и формализация алгоритмов автоматизированного тестирования программного продукта.
1. Технологии тестирования программного продукта
Умение написать хороший тестовый код - показатель профессионализма программиста. Его поддержка занимает много времени и много сил, чтобы создать надежную и расширяемую систему. Так как тестовый код не поставляется заказчику, то существует большой соблазн отказаться от тестов из-за их дороговизны. Однако разработка тестов выгодна компании в перспективе: качество выпускаемого продукта становится выше, спрос на продукцию повышается. Но настоящая цель тестов - понизить стоимость разработки. Это означает, что использованное время на развитие и поддержку тестов должно окупаться сокращением ручного тестирования, дополнительной отладки и выявлением дефектов с одной стороны, и сокращением дефектов в готовом продукте с другой.
Для уменьшения трудоемкости тестирования разрабатываются и применяются средства автоматизации, позволяющие [4, 5]:
- увеличить скорость выполнения тест-кейсов;
- снизить влияние человеческого фактора в процессе их выполнения;
- минимизировать затраты при многократном выполнении тест-кейсов;
- выполнять тест-кейсы, непосильные человеку ввиду сложности, скорости и других причин;
- собирать, хранить и обрабатывать большие объемы данных [6].
Первой задачей при добавлении автоматических тестов в проект является задача сде-
лать их однозначными. Доверие - это полная уверенность разработчиков в результатах теста: если он «красный», то это должна быть проблема. Если это не так, за тестами перестанут следить и верить им.
Простой тест проверяет небольшой функционал, и можно четко сказать, что пошло не так. Также сложные тесты требуют больших затрат по их поддержке и развитию, и теряется сама идея автоматизации. Обеспечить доверие к тестам и их простоту - сложная задача. С точки зрения инженерии необходимо сделать их минимальное внедрение в код продукта и не усложнить эти конструкции, чтобы любой разработчик в будущем смог их дополнить. С точки зрения управления нужно выделить время на разработку тестов, перестроить процессы работы команды. На начальных этапах может быть ситуация, когда есть сигнал о проблеме, но его никто не разбирает. Возможно деление тестов на уровни проблемности: что-то критичное и его нужно чинить максимально быстро, что-то можно отложить.
После первичного добавления тестов нужно обеспечить их приемлемую скорость. В данной работе мы описывали статическое тестирование, происходящее локально - оно не должно занимать много времени, иначе это будет тормозить работу. Человек не должен ждать три часа для проверки небольшого файла. С другой стороны, полный набор тестов может занимать несколько часов или даже дней. Каждый уровень тестирования может разделяться на наборы. Это один из способов давать обратную инкрементальную связь. Юнит-тесты, «дымные» работают быстро, и разработчик узнает о возможной проблеме практически сразу после внесения изменений, находясь в контексте задачи. Тесты производительности и полный набор имеют большое время выполнения и тоже дадут обратную связь. В любом случае разработчик еще будет находиться в контексте задачи, так как даже работа всех тестов, затрагиваемых изменениями, не должна превышать одни сутки.
Процесс внесения изменений изображен на рисунке 1.
Рис. 1. Процесс внесения изменений
Расширяемость тестов является залогом их успешного применения на проекте. Если любой разработчик не сможет писать и расширять систему, то новый функционал останется не протестирован. Это нивелирует идею автоматизации - когда ручные проверки заменяются автоматическими. Возвращаясь к первому слою, следует заметить, что тесты должны быть простыми, и это требует высокой квалификации инженеров по внедрению автоматизации.
На последнем этапе внедрения тестов важным свойством является покрытие. Для высокого процента покрытия функционала необходима простота добавления новых тестов любым разработчиком. Если на предыдущем шаге не решена задача расширяемости, то этот процесс будет сильно затруднен.
Также важна и скорость выполнения - при выполнении набора несколько часов разработчики не будут писать новые.
Другое важное свойство - интеграция автоматических тестов в общий процесс тестирования. Мало сделать автоматический функционал, нужно, чтобы он заменял собой рутин-
ные ручные действия. Идеальная ситуация, к которой нужно стремиться, когда новый функционал не тестируется руками, а найденные ошибки в старом покрываются тестами и тоже никогда не проверяются повторно.
Внедрение автоматизированных тестов в процессы разработки ПО является комплексной и сложной задачей для всей команды. Обобщая все описанное выше, приходим к последовательности процессов, отображенных на рисунке 2.
Рис. 2. Процесс интеграции автоматизированных тестов в проект
Так как основной целью является сборка более качественного продукта, то все усилия направлены на то, чтобы большинство его функционала было покрыто автоматизированными тестами. Так можно гарантировать, что проект не уйдет в регрессию при внесении новых изменений. Все технические шаги выполняются командами разработчиков и специалистами из отдела непрерывной интеграции.
Менеджеры проектов должны содействовать и продвигать смену корпоративной культуры в сторону быстрой реакции на ошибки в тестах. Это включает в себя:
- планирование времени на создание и поддержку систем автоматизированного тестирования;
- помощь в создании нужных взаимосвязей между отделами.
Чтобы успевать сделать обновление в назначенный срок нужно, выделить необходимую функциональность на небольшой срок и выполнить ее с должным качеством. В качестве методологии процесса разработки используется Scrum. Для этого подхода тестирование является одним из центральных видов деятельности и частью процесса разработки, а не чем-то таким, что совершается уже после того, как разработчики завершат свою работу [7].
2. Статическое тестирование
Статическое тестирование позволяет найти ошибки, не запуская проект. Это значит, что можно перенести часть проверок на компьютер специалиста и выполнять их перед добавлением изменений в общий репозиторий. Поэтому данный вид разделяется на две части:
1) тестирование локально;
2) тестирование на сервере.
Рассмотрим локальный запуск. Большинство CVS предоставляет возможность вызова пользовательского кода как реакцию на определенные события. Такие действия называются хуками и разделяются на две группы: серверные и клиентские. Для локального запуска нас интересует клиентская группа. В случае с Git это набор файлов, которые хранятся в директории .git/hooks относительно корня проекта. Все изменения в CVS разделены на коммиты, в момент создания коммита - фиксации изменений - последовательно запускается последовательность хуков. Запуская проверку в одном из этих хуков, можно найти ошибки, которые сделал разработчик в конечном и зачастую небольшом наборе изменений. Это позволяет
экономить ресурсы сборочной системы и находится максимально близко по времени к внесению изменений. Видя сообщение об ошибке, разработчик находится в контексте задачи, и ему не составит огромного труда сразу ее исправить (в сравнении с ситуацией, когда ошибка была сделана несколько дней, а то и недель назад, и разработчику нужно заново погружаться в задачу, чтобы понять, в чем именно была допущена ошибка и как ее теперь устранить).
Можно выделить три проблемы в данном подходе:
- обязательность установки хуков: при загрузке репозитория нет обязательной или автоматической установки данных скриптов (любая программа, которая попробует поставить их, автоматически может расцениваться антивирусом как эксплойт, и вместо установки пользователь увидит системное предупреждение);
- «лишние» ошибки: могут быть ошибки, которые сделал другой разработчик, что является следствием первой проблемы, когда не у всех выполняются нужные скрипты;
- время выполнения: полная проверка может занимать от нескольких минут до часов. Учитывая, что разработчик делает много коммитов в день, это сильно замедлит его работу.
Пути устранения данных проблем.
Отсутствие прекомитных хуков. Первая проблема решается внешней системой и административными действиями. Мы предположили, что нет разработчиков, которые умышленно хотят сломать продукт, и все их действия направлены на его улучшение. Поэтому отсутствие запуска хуков - человеческий фактор. Это решается схемой, описанной на рисунке 3.
Рис. 3. Процесс проверки работы хуков
Если хуки установлены, то они подпишут коммит. Мы решили, что это будут символы [+] в конце сообщения-заметки. На серверной части будет проверено, что коммит содержит подпись. Если ее нет, тогда пользователь должен быть оповещен об этом. Процесс не регламентирует точного способа оповещения. Это может быть или задача в таск-трекере, или личное сообщение на почту, или одновременно оба способа.
Чужие ошибки. Возможна ситуация, когда у одного из работников отдела не будет запущена проверка, и в репозиторий попадут ломающие изменения. Тогда при коммите другим работником они будут найдены, и он не сможет добавить свои изменения в репозиторий, даже если в них нет его собственных ошибок. Это существенный минус системы, который решается только административным ресурсом: установка принудительно системы проверок всем, быстрое исправление допущенных ошибок, гранулирование работы.
Команда должна перейти от разработки всего функционала в одной ветке разработки к разработке каждого блока функциональности в отдельной ветке. В идеальном варианте над одной функцией работают несколько человек, которые могут быстро исправить возникшую проблему. Так как ветка отдельная, то ошибка в ней не затронет всех остальных сотрудников.
Время выполнения. В прекомитных хуках есть возможность узнать набор файлов, в которых произошли изменения. Если запускать верификацию только на них, то длительность проверки можно существенно снизить.
Рассмотрим серверный запуск. На сервере требование ко времени не столь критично,
как при запуске локально. Поэтому запускаться должны все проверки, которые необходимы для данной сборки. Однако стоит учитывать тот факт, что проектов, а, соответственно, и сборок может стать больше, поэтому оптимизацию нужно производить и на этапе формирования сборочных цепочек.
При хорошем планировании разноплановые тесты можно запускать параллельно. Например, статический анализ кода может длиться несколько часов, но он не блокирует статическую проверку ресурсов или запуск юнит-тестов.
Планирование и настройка сборок - это отдельная и большая тематика, в данной работе вскользь отметим, что при большом количестве сборок следует рассмотреть следующие сценарии оптимизации:
- декомпозиция большой сборки на более мелкие шаги, которые можно выполнять параллельно;
- инкрементальность в сборке кода и ресурсов;
- запуск длительных тестов отдельно.
Большое количество конфигураций позволяет выполнять параллельно разные части общей большой сборки и гибко настраивать все необходимые выходные версии (для разных платформ, внутреннюю и внешнюю и так далее).
Как видим, на схеме отображено множество разных конфигураций. Каждая отвечает за свой этап сборки: компиляция ресурсов, компиляция кода.
Эти этапы, в свою очередь, разделены на конфигурации по платформам, так как для разных платформ необходимы свои параметры и шаги по сборке. При чтении слева направо мы видим, что для успешного запуска сборки для iOS платформы необходимо выполнение не только сборочных этапов, но и конфигураций тестов - правая колонка.
Такое расслоение дает существенные преимущества:
- удобство поддержки: независимые конфигурации, как и в программировании классы, можно настраивать и перерабатывать, не затрагивая всю цепочку;
- параллельность: можно запускать параллельно сразу несколько частей сборки. Например, сборка ресурсов и кода не зависят друг от друга и могут происходить параллельно. Это дает большой потенциал в обработке очереди сборок и оптимизации их времени выполнения.
3. Динамическое тестирование
Методы динамического анализа программ позволяют с высокой точностью находить ошибочное поведение программ в связи с тем, что ошибки обнаруживаются в процессе исполнения программы и имеются входные данные, на которых возможно воспроизведение ошибочного поведения программы. В то же время методы динамического анализа программ обладают низкой производительностью обнаружения ошибок, связанной с проблемой взрывного роста количества путей для анализа при проведении исчерпывающего анализа программы [8].
Стадия динамических тестов приходит после успешного прохождения статических. Если ресурсы не валидны, то смысла запускать динамические проверки нет.
При разработке плана тестирования определяются устройства, на которых будет запускаться игра у пользователя. В случае с мобильной разработкой это будут iOS, Android, UWP. При разработке игр есть внутренние сборки для настольных платформ, таких как Windows или Mac OS. На первый взгляд может показаться, что десктопные сборки не нужно проверять. Но разработка - это длительный процесс, и нужно убедиться, что весь задуманный функционал и внутренние инструменты работают корректно. В случае отказа внутренних систем работа арт-отдела или дизайнера уровней может остановиться.
Для сборок, которые будут отправлены внешним потребителям, обязательна более детальная проверка всего функционала с разных сторон, в том числе тесты производительности.
Тесты с частичным покрытием или «дымные тесты»
В диаграмме динамического тестирования это первый шаг, который необходимо вы-
полнить, чтобы убедиться в работоспособности приложения.
Требования к набору тестов:
- максимально широкое покрытие функционала (нужно проверить все часто используемые вещи, убедиться, что приложение запускается);
- минимальное время выполнения (любое изменение может полностью сломать функционал или консистентность приложения, данных, поэтому этот набор должен быть запущен на каждый коммит, что приводит к временным ограничениям).
Успешное выполнение Бтоке-теста («дымного теста») является обязательным условием для попадания сборки во внешнее хранилище. Если нашлись ошибки, тогда сотрудник, который возьмет изменения со сломанной сборки, будет вынужден или выяснять причину поломки, или будет основывать свои изменения на ложных предположениях.
Предусловиями для запуска является устройство без сборки, процесс:
- удалить с устройства все данные приложения, если они есть;
- установить новое приложение;
- запустить приложение;
- собрать и подготовить отчет.
Тесты производительности
Для игровых приложений производительность является критичным показателем. Но так как каждое обновление игра становится сложнее, в ней появляется больше систем, то отслеживание показателей производительности становится важной целью.
Базовый показатель производительности игры - количество кадров в секунду. Оптимальным считается значение 60 кадров в секунду. Это означает, что на каждый кадр приходится 16 мс. Сложность заключается в замере этого времени. Рассмотрим два возможных варианта замеров:
- ручной;
- автоматизированный.
Очевидные плюсы ручного замера - нет вмешательства во внутренний код игры и, соответственно, все показатели «правдивые». Разработав сценарии проверки, можно из версии в версию делать эти замеры. Существенным же минусом является сам человеческий глаз и энтропия показателей. Игра - сложное сплетение множества систем, и даже проседание в нескольких кадрах на небольшое значение может скрывать за собой серьезный дефект. Профессия тестировщика требует предельной внимательности, но все же это не гарантирует точного замера. Более того, выделить время одного тестировщика полностью на тестирование производительности игры невозможно. Игра может быть в состоянии разработки, где возможны недоработки и лишние вычисления. Также монотонные действия притупляют внимательность, что ведет к некорректным результатам замеров.
Автоматизированный. Хочется обратить внимание, что это именно автоматизированный замер, так как невозможно точно определить удовлетворительное качество системы только в автоматическом режиме. В данном случае пришли к экспертной системе, которая имеет граничные значения, и если они не вышли из заданных рамок, тогда она не запускает дополнительных отчетов и не подключает людей. Нужно время человека, который будет периодически просматривать графики и принимать решения, есть или нет перекосы в каком-то из значений. Помимо общей проблемы автоматизации - уровня доверия, который рассмотрен ниже - присутствуют особенности замеров конкретно для тестов производительности.
Неопределенность модели устройства. Даже одна и та же модель может иметь разную историю и, соответственно, разную усталость батареи, жесткого диска, ОЗУ, и нельзя с точностью перенести замеры с одного устройства на другое и ожидать их полного совпадения.
Решением данной проблемы может быть только фиксирование устройств, на которых будет происходить запуск. При необходимости изменить устройство необходимо будет и изменение эталонных данных.
Неопределенность устройства. Даже одно и то же устройство может быть в разном состоянии, и его фоновые процессы, уровень заряда, перегрев будут влиять на итоговый
замер.
Убрать этот фактор невозможно, возможный вариант - создание пороговых значений для эталонов, отслеживание значений на протяжении нескольких запусков. Отсеивание перегретых устройств или с низким зарядом перед запуском.
Минимальность замера. Измерять показатели нужно только один промежуток игрового процесса в одном и том же состоянии игры, чего весьма сложно добиться из-за того, что игра - это сложная система, в которой постоянно возникают дополнительные окна, события, сущности. Для корректной работы необходимо заложить время разработчиков для настройки функционала для создания тестовых наборов, гибкой настройки точек замера, системы логи-рования. Если в Smoke тестах достаточно функционала для пропуска больших частей игры, то для бенчмарков необходима более точная настройка границ теста.
Одинаковость состояния игры. Современная игра - постоянно изменяющийся сервис, чтобы его поддерживать, множество изменений вносится в кодовую базу и в ресурсы каждый день. Однако для производительности важен контекст - нельзя допустить, чтобы на экране возникли дополнительные элементы или сущности, иначе это исказит результаты замера. Этот пункт сильно зависит от специфики игры. Если есть поддержка восстановления состояния из файла, то это может применяться в качестве отправной точки для старта теста производительности.
Специфичные для игр автоматизированные тесты
Все игры очень специфичны, и в каждой будет набор механик, уникальных для данной игры. Поэтому невозможно написать общий алгоритм проверки всех игр. Также написание подобных тестов зависит от выбранной технологии и целевой платформы.
Так как это изменение в коде, то отделу разработки нужно выделить время для написания функционала, который позволит в автоматическом режиме выполнять простые действия: открыть меню, перейти на другую вкладку, купить предмет. Эти действия должны быть гранулярными - то есть такими, чтобы из них можно было составить любое поведение, которые сможет воспроизвести реальный игрок. В идеальных условиях автоматизированные тесты должны полностью воспроизводить реального игрока. Обобщая эту рекомендацию, можно сказать, что автоматизированный сценарий должен быть максимально приближенным к действиям конечного потребителя.
Дробление на небольшие шаги-тесты позволит составить схему необходимого теста -«дымного», теста производительности или любого другого. Абстрактный алгоритм может выглядеть так:
1) дождаться конца первичной загрузки;
2) произвести нажатие кнопки «Играть», перейдя при этом на первый экран;
3) произвести нажатие на кнопку «Магазин»;
4) дождаться открытия магазина;
5) купить предмет.
Такими действиями можно составить как «дымный» тест, так и тест производительности. Однако не обязательно специфичные тесты будут гранулярными, они могут иметь и более сложную структуру. Это необходимо для проверки сложных взаимодействий в коде, но незаметных для игрока. Хорошим примером может быть простой искусственный интеллект, который пытается «играть» в игру, совершая простые и доступные на данный момент шаги. Он не является гранулярным, но позволяет проверить игру на явные дефекты: падения, отсутствия ресурсов, смену логики в важных системах интерфейса.
Эмуляция действий пользователя
Автоматизация функционалом из игрового кода позволяет эмулировать тап по экрану или клик манипулятора, клавиши. Но в реальности он передается из системных функций, к которым нет доступа в игровом коде. Для «дымного» теста автоматизации на уровне приложения будет достаточно, но при возможных сбоях игра может зависнуть в одном положении и не реагировать на действия игрока.
Для решения подобных задач используются механизмы вроде Appium - оболочки, которая может эмулировать тапы по экрану так, как будто это сделал человек.
Appium - это инструмент для автоматизации тестирования нативных, мобильных, веб-приложений для iOS, Android и Windows платформ. Важным его преимуществом является кросс-платформенность: он позволяет писать тесты на разные платформы, используя один и тот же API, что дает возможность повторно использовать один и тот же код. При разработке Appium философия складывалась из следующих пунктов:
1) разработчики не должны пересобирать или модифицировать приложения для автоматизации его тестирования;
2) разработчики не должны быть скованы одним языком или платформой для развертывания тестов.
Appium имеет клиент-серверную архитектуру. Он получает команды, которые необходимо исполнить и возвращает результат выполнения.
Клиент-серверная архитектура также позволяет писать сценарии для тестов на любом языке, у которого есть поддержка интерфейса для http. Запуск тестов всегда выполняется в контексте сеанса. Клиенты инициируют сеанс с сервером способами, специфичными для каждой библиотеки, но все они заканчивают отправкой запроса POST/session на сервер с помощью объекта JSON, называемого объектом «желаемые возможности». В этот момент сервер запускает сеанс автоматизации и отвечает идентификатором сеанса, который используется для отправки дальнейших команд.
«Желаемые возможности» - это набор ключей и значений (например, карта или хэш), отправляемых на сервер Appium, чтобы сообщить серверу, какой сеанс автоматизации хотим запустить. Существуют также различные возможности, которые могут изменить поведение сервера во время автоматизации. Например, можно установить функцию platform Name на iOS, чтобы сообщить Appium, что хотим сеанс iOS, а не Android или Windows. Или можно установить для функции safari Allow Popups значение true, чтобы гарантировать, что во время сеанса автоматизации Safari будет разрешено использовать JavaScript для открытия новых окон.
Данный инструмент позволяет настраивать сценарии, шагом в которых будет тап по определенной области или нажатие клавиши так, как будто это сделал человек. Это максимально близкий к реальному пользователю способ, но и максимально сложный в реализации. Его можно воспринимать, как UI-тестирование.
Технические характеристики static-tests
Выше описаны требования к статическим тестам (рис. 3). Как видно, требований много, и нужно их всех учесть таким образом, чтобы написание дополнительного нового теста было максимально простым. Воспользуемся языком программирования python. Для наших целей -простой и удобный интерфейс написания, простой запуск, он наиболее всего подходит. Также наш фреймворк должен быть очень гибким и встраиваться в любой проект.
4. Описание ядра системы статического тестирования
С целью скомпенсировать переход к ретроинжинирингу и индуцируемый им переход к технологической идеологии KISS («Keep It Short and Simple» = «Делай короче и проще»; принципы проектирования, при которых простота системы декларируется в качестве основной цели \ ценности разработки), среди разработчиков замещающих технологий и их потребителей, в частности, было целесообразно использовать повышение эвристической ценности конкретных измерений за счет комплексирования дескрипторов [9]. Согласно принципу KISS, система не усложнялась, и все требования сгруппированы в базовом классе тестирования. Ниже представлен основной код данного класса.
Во время инициализации класса все необходимые предусловия для запуска данного конкретного теста сохраняются и обрабатываются только в этом классе, а для создания нового достаточно будет только указать нужные параметры. Перед стартом каждого теста вызывается метод__check_run , который определит необходимость запуска, и, если вернет false
, то запуск не состоится, что снизит время выполнения всего набора.
classTestBase (object):
def_init__ (self, name, context, build_types= None ,
platforms= None , predicate= None , expected_resources= None , modified_resources= None ):
self._name = name
self._context = context
self._build_types = build_types
self._platforms = platforms
self._predicate = predicate
self._expected_resources = expected_resources
self._modified_resources = modified_resources
# Подходит ли тип сборки и платформы для запуска теста
# Изменились ли ресурсы, за которые отвечает предикат self._need_run = self._check_run()
self._need_resource_run = False
def_check_run (self):
build_success = self._build_types is None or
self._context.build_type in self._build_types
platform_success = self._platforms is None or
self._context.platform in self._platforms
hook_success = build_success
if build_success and self._context.is_build('hook')
and self._predicate:
hook_success = any (self._predicate(changed_file) for
changed_file in self._context.changed_files)
return build_success and platform_success and hook_success
Для создания отдельного теста необходимо указать имя теста, типы сборки, в которых необходим запуск (например, запускать для релизной сборки и в прекомитном хуке - то есть локально), платформу и ресурс, который обрабатывает данный тест. Предикатом в примере является условие, что измененный файл имеет расширение png, а прикрепленный ресурс -текстуры.
class VerifyTexture (TestBase): def_init__ (self, context):
super (VerifyTexture, self)._init__ ('VerifyTexture',
context, build_types=['production', 'hook'], platforms=['windows', 'ios'], expected_resources= None ,modified_resources=['Texture'], predicate= lambda file_path: os.path.splitext(file_path)[1] == '.png')
Другой важной сущностью является контекст. Перед запуском в него записываются необходимые для выполнения программы параметры: аргументы сборки, запуска, мета-информация, которую заполняют тесты. Мета-информация в данном случае - это данные любого вида, которые могут понадобиться для внешнего кода. Данный механизм позволяет обмениваться данными между разными частями программы и является своеобразным кешем. Наиболее очевидный способ применения - хранить список найденных ресурсов во время запуска.
Данная программа должна работать как в режиме полной проверки, так и частичной. Как описано выше, в режиме частичной проверки, который обычно происходит локально, необходимо выполнять минимальное количество тестов.
Эту задача решается, используя специальные метки: для каждого теста отмечается, какой ресурс он проверяет и какие ресурсы связаны с данными теста. Получается иерархическая структура, показанная на рисунке 4.
На диаграмме указаны зависимости между тестами и файлами. Тесты А, Б и Г отвечают за отдельные файлы ЗД-моделей, текстур (например, png) и файлов звука (например, ogg) соответственно. Тест В отвечает за описание сущности, которая представляет из себя соединение модели с текстурой. Тогда при изменении файла звука необходимо запустить только
один тест - Г, при изменении ЗД-модели или текстуры - запускать связанные тесты А и Б. Но так как они связаны с тестом В, то нужно запустить и его.
Рис. 4. Зависимость теста от ресурсов
С другой стороны, если изменяется файл-описание, в котором есть упоминания и текстуры, и ЗД-модели, то с запуском В нужно запустить и А, Б: необходимо убедиться, что все связанные ресурсы находятся в корректном состоянии.
Для создания таких связей используется метаинформация в контексте: тесты записывают те ресурсы, файлы которых были изменены. Все тесты, которые зависят от этих ресурсов, тоже нужно запускать.
Это позволяет при локальном запуске отсечь все ненужные тесты и существенно сократить время выполнения. В режиме полной проверки все ресурсы отмечаются как измененные и выполняются все тесты. В коде контекста достаточно хранить небольшое количество информации и после инициализации всех созданных сущностей и проверки на изменения ресурсов определить, какие именно тесты запускать.
Заключение
Таким образом, проведенный анализ современных процессов разработки программного обеспечения показал нехватку тестирования на ранних этапах разработки ПО.
Автоматизация процессов тестирования необходима при разработке любых современных систем. К выстраиванию стратегии и процессов валидации проекта необходимо подходить с таким же вниманием, как и к разработке самого проекта. Применение методов вали-дации и верификации проектов важно в любой отрасли современной разработки, начиная с игровых приложений, и заканчивая системами военно-промышленного комплекса [10].
Анализ используемых средств разработки и их возможной интеграции в рамках работы над игровыми проектами показал, что необходимо смещать усилия от проверки готового продукта на финальной стадии разработки к проведению всесторонней валидации на всех этапах работы. В процессе исследования статического тестирования для усовершенствования полноценной статической проверки было предложено разделить ее на два этапа: локальный и серверный этап. При анализе процессов тестирования было выявлено, что динамические тесты занимают большую часть времени, затрачиваемого на проверки, в связи с чем необходима сильная поддержка со стороны отдела непрерывной интеграции в разрезе поддержки и настройки сервера интеграции, поддержки тестовой фермы и корректно подобранных реальных устройств, на которых будут запускаться тесты.
Таким образом, выявлено, что общим может быть только ядро для запуска автоматизированного статического тестирования, так как невозможно обобщить динамическое тестирование (требует изменений в коде проекта, соответственно для каждого проекта оно будет своим), а также невозможно обобщить конкретные статические тесты (они будут отличаться в зависимости от области применения, и возможно обобщение только на уровне компании). Это позволит сделать процесс тестирования более сбалансированным и объективным, а также учитывать реальные возможности [11].
Итак, в системе должно быть организовано управление жизненными циклами тест-кейсов и отчетов о дефектах (на основе разработки имитационных моделей) с целью повышения эффективности нахождения и исправления ошибок в программном обеспечении [2].
Примечания:
1. Говорущенко Т. А. Процесс повторного тестирования в процессе экспертизы программного обеспечения // Системные исследования и информационные технологии. 2011. № 1. С. 71-86.
2. ГОСТ Р ИСО/МЭК 15026-2002 Информационная технология (ИТ). Уровни целостности систем и программных средств. Введ. 2003-07-01. Москва: ИПК изд-во стандартов, 2002. 19 с.
3. Мониторинг сложных объектов инфраструктуры / Д.А. Гура, Ю.В. Дубенко, П.Ю. Бучацкий, И.Г. Марковский, Н.И. Хушт // Вестник Адыгейского государственного университета. Сер.: Естественно-математические и технические науки. 2019. Вып. 4 (251). С. 74-80. URL: http://vestnik.adygnet.ru
4. Куликов С.С. Тестирование программного обеспечения. Базовый курс. Минск: Четыре четверти, 2017. 312 с.
5. Полевщиков И. С. Автоматизированная система управления процессом тестирования программного обеспечения в ходе промышленной разработки // Решение. 2018. Т. 1. С. 191-193.
6. Полевщиков И.С., Файзрахманов Р.А. Автоматизированное управление тестированием программных систем с применением нейронных сетей // Инженерный вестник Дона. 2018. № 4 (51). С. 94104.
7. Щербина И.О., Таран В.Н. Автоматизированные методы тестирования программного обеспечения // Образование в цифровую эпоху: сб. статей по материалам междунар. науч.-практ. конф. преподавателей, студентов, аспирантов, докторантов и заинтересованных лиц. Симферополь, 2019. С. 186-190.
8. Герасимов А.Ю. Направленное динамическое символьное исполнение программ для подтверждения ошибок в программах // Программирование. 2018. № 5. С. 31-42.
9. Орехов Ф.К. Границы применимости принципа KISS в практике молекулярной спектральной диагностики при квалиметрии пищевых продуктов и нутриентов // Рациональное питание, пищевые добавки и биостимуляторы. 2016. № 3. С. 41-43.
10. Shcherbina I.O., Taran V.N. Testing Processes Automation // Сборник материалов X Всерос. на-уч.-техн. конф. с междунар. участием. 2019. С. 498-502.
11. Горщар Р.С., Таран В.Н. Алгоритмические подходы для средств аналитики результатов тестирования систем дистанционного обучения // Системы компьютерной математики и их приложения. 2019. № 20-2. С. 180-185.
References:
1. Govorushchenko T.A. The process of retesting in the process of software expertise // Systems Research and Information Technology. 2011. No. 1. P. 71-86.
2. GOST R ISO / IEC 15026-2002 Information technology (IT). Integrity levels of systems and software. Introduction. 2003-07-01. Moscow: IPC Publishing House of Standards, 2002. 19 p.
3. Monitoring of complex infrastructure facilities / D.A. Gura, Yu.V. Dubenko, P.Yu. Buchatsky, I.G. Mark-ovsky, N.I. Khusht // The Bulletin of the Adyghe State University. Ser.: Natural-Mathematical and Technical Sciences. 2019. No. 4 (251). Р. 74-80. URL: http://vestnik.adygnet.ru
4. Kulikov S.S. Software Testing. Basic course. Minsk: Chetyre Chetverti, 2017. 312 p.
5. Polevshchikov I.S. Automated control system for software testing during industrial development // Re-shenie. 2018. Vol. 1. P. 191-193.
6. Polevshchikov I.S., Fayzrakhmanov R.A. Automated control of testing software systems using neural networks // Engineering Journal of Don. 2018. No. 4 (51). P. 94-104.
7. Shcherbina I.O., Taran V.N. Automated software testing methods // Education in the digital age: a collection of articles based on the materials of the international scient. and pract. conference of teachers, students, postgraduates, doctoral students and interested persons. Simferopol, 2019. P. 186-190.
8. Gerasimov A.Yu. Directed dynamic symbolic execution of programs to confirm errors in programs // Programming. 2018. No. 5. P. 31-42.
9. Orekhov F.K. The limits of applicability of the KISS principle in the practice of molecular spectral diagnostics in the qualimetry of food products and nutrients // Rational Nutrition, Nutritional Supplements and Biostimulants. 2016. No. 3. P. 41-43.
10. Shcherbina I.O., Taran V.N. Testing Processes Automation // Collection of materials of the 10th Russian scientific and technical conference with international participation. 2019. P. 498-502.
11. Gorshchar R.S., Taran V.N. Algorithmic Approaches for Analytical Tools for Testing Results of Distance Learning Systems // Systems of Computer Mathematics and Their Applications. 2019. No. 20-2. P. 180-185.
