CC BY
86
ИНФОРМАТИКА, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И УПРАВЛЕНИЕ INFORMATION TECHNOLOGY, COMPUTER SCIENCE, AND MANAGEMENT
УДК 004.415.532
Метод выбора между ручным и автоматизированным тестированием, основанный на свойствах программного продукта
Е. Ю. Галимова1, А. Н. Коваленко2
12 Высшая школа печати и медиатехнологий Санкт-Петербургского государственного университета промышленных технологий и дизайна, г. Санкт-Петербург, Российская Федерация
Method of selecting between manual and automated testing based on the software product features * E. Y. Galimova1, A. N. Kovalenko2**
1,2 Higher School of Printing Arts and Media Technologies, St. Petersburg State University of Technology and Design, St. Petersburg, Russian Federation
The work objective is to develop and investigate a method of choosing between manual and automated testing of the software product (SP). The proposed method principle consists in the organization of the interaction routines between testers and programmers who have completed the coding and unit testing process. A special questionnaire of 20 points which is filled in by a programmer is offered. Thus, the obtained, processed and analyzed answers make assertions about features of the prospective software product performance valuable for a tester. As a result, a general connection between the properties that determine the software utility and the testing method is specified. When functionality and (or) the reliability checking is requested, it is recommended to use the mixed testing - both manual and automated. When usability and (or) maintainability checking is requested, it is recommended to use the manual testing. When productivity and (or) portability checking is requested, it is recommended to use the automated testing. The methods are aimed at improving the testing quality on the basis of GOST RISO/IEC 9126-93.
DOI 10.12737/22160
Целью данной работы является создание и исследование метода выбора между ручным и автоматизированным тестированием программного продукта (ПП). Суть предлагаемого метода состоит в организации процедуры взаимодействия тестировщиков с программистами, которые завершили процесс написания программного кода и провели модульное тестирование. Предложен специальный вопросник из 20 пунктов, который заполняется программистом. Полученные таким образом, обработанные и проанализированные ответы позволяют судить о важных для работы тестировщика особенностях функционирования будущего программного продукта. В результате установлена общая связь свойств, определяющих полезность программного продукта, с методом тестирования. Если требуется проверка функциональных возможностей и (или) надежности, рекомендуется применять смешанное тестирование — ручное и автоматизированное. Если требуется проверка практичности и (или) сопровождаемости, рекомендуется применять ручное тестирование. Если требуется проверка эффективности и (или) мобильности, рекомендуется применять автоматизированное тестирование. Методика направлена на улучшение качества тестирования и основана на ГОСТ РИСО/МЭК 9126-93.
Ключевые слова: ручное тестирование ПП, автоматизиро- Keywords: manual software testing, automated software testing, ванное тестирование ПП, полуавтоматизированное тестиро- semi-automated software testing, selection method. вание ПП, метод выбора.
g Введение. Процесс разработки программного продукта (ПП) рассматривается как каскадная модель, работа в
3 которой предполагает последовательное выполнение следующих этапов: анализ требований, проектирование, реали-
сл
g зация, тестирование, внедрение, поддержка [1]. Данная модель обладает высокой степенью формализации, что делает ее применимой при управлении большими проектами. Она предназначена для использования на второй стадии тести-•д рования, которая проводится в группах профессиональных тестировщиков по завершении работы программистов. В gg приведенном виде постановка задачи в научной литературе не встречается.
В основе работы — предложения по организации взаимодействия программистов и тестировщиков. Данное л взаимодействие предлагается базировать на специальном простом вопроснике. С ним работают программисты, а затем ответы дополняют тестировщики.
*Работа выполнена в рамках инициативной НИР.
134 E-mail: Galim81@mail.ru, akovalenko@uprint.spb.ru
***The research is done within the frame of the independent R&D.
В действующих стандартах [2] описаны характеристики, определяющие полезность ПП для конечных пользователей:
1) функциональные возможности (атрибуты: пригодность, правильность, способность к взаимодействию, согласованность, защищенность);
2) надежность (атрибуты: стабильность, устойчивость к ошибке, восстанавливаемость);
3) практичность (атрибуты: понятность, обучаемость, простота использования);
4) эффективность (атрибуты: характер изменения во времени, характер изменения ресурсов);
5) сопровождаемость (атрибуты: анализируемость, изменяемость, устойчивость, тестируемость);
6) мобильность (атрибуты: адаптируемость, простота внедрения, соответствие, взаимозаменяемость).
Перечисленные свойства ПП важны во многих отношениях, в частности, они влияют на выбор плана
тестирования.
Основная часть
Опросный лист для разработчиков ПП
При поступлении ПП на тестирование предлагается получать ответы от программистов и системных аналитиков на приведенные ниже вопросы 1-20. Каждый вопрос отражает определенный набор свойств ПП. Если дан утвердительный ответ, указанные выше свойства предполагается проверять в предстоящей итерации тестирования. После вопроса указаны свойства из приведенного выше набора характеристик полезности ПП.
1. Обладает ли ПП функционалом для выполнения повторяющихся действий? Свойства: функциональные возможности, надежность, эффективность.
2. Часто ли будут выходить новые версии ПП? Свойства: эффективность, мобильность.
3. Достаточно ли форм с полями для ввода данных? Свойства: функциональные возможности, эффективность.
4. Предъявляются ли высокие требования к производительности? Свойства: функциональные возможности, надежность, эффективность.
5. Предусмотрены ли переходы с одной платформы (конфигурации аппаратных средств) на другую при работе с ПП? Свойства: надежность, эффективность.
6. Предполагается ли эксплуатация ПП при максимальной нагрузке? Свойства: надежность, эффективность.
7. Много ли ■еЬ-ссылок в ПП? Свойства: функциональные возможности, надежность.
8. Предусмотрены ли операции, выполняемые вручную? Свойства: практичность, сопровождаемость.
9. Планируется ли проверка эргономичности ПП? Свойства: функциональные возможности, сопровождае-
мость.
10. Будут ли регулярно проверяться корректность установки, обновления и удаления ПП? Свойства: практич-
<о
ность, сопровождаемость. К
щ
11. Важна ли простота и быстрота восприятия выходных данных? Планируется ли проверка удобочитаемости « формата выходных данных? Свойства: практичность, сопровождаемость. и
12. Много ли сторонних управляющих элементов использовалось при разработке? Свойства: практичность, ^
сопровождаемость. ^
к
13. Необходимо ли оценивать способность восстановления системы после сбоя? Свойства: функциональные се
^
возможности, надежность. §
т-п-г ^
14. Много ли в ПП графических объектов? Свойства: функциональные возможности, практичность.
15. Много ли в ПП функционала, который предполагает печать документов на принтере? Свойства: функцио- ^ нальные возможности, надежность, сопровождаемость. щ
16. Должно ли тестирование пройти в сжатые сроки? Свойства: сопровождаемость. ч
17. Планируется ли проводить функциональное тестирование? Свойства: функциональные возможности. ^
18. Предполагается ли создавать наборы входных тестовых данных заново перед каждой итерацией тестиро- § вания? Свойства: надежность, функциональные возможности. р
19. Будет ли проводиться тестирование на некорректных входных данных? Свойства: функциональные воз- щ можности, надежность.
20. Использовались ли при разработке ПП сложные логические структуры (ветвления, циклы)? Свойства: §
Й
надежность. Л
Работа с результатами опроса о1
Результаты опроса разработчиков ПП поступают в отдел тестирования для анализа. Порядок вопросов не случаен. Положительный ответ на любой из первых семи вопросов говорит в пользу автоматизации тестирования; в поль- К зу ручного — положительные ответы на вопросы с 8 по 16; в пользу смешанного тестирования — положительные ответы на вопросы с 17 по 20. 135
Обсудим эти вопросы.
Стандартный инструмент автоматизации тестирования способен записывать, а потом воспроизводить последовательности действий тестировщика. Затем программное средство автоматизации сравнивает полученный результат с эталоном. Если сравнение успешное, то тест считается пройденным. В противном случае сообщается, что в тесте допущена ошибка. Одним из стандартных инструментов автоматизации тестирования является программное обеспечение Selenium. Его важное преимущество — наличие драйверов под все распространенные платформы, включая мобильные, а также широкий спектр функциональных возможностей [3, 4]. Но Selenium не решает вопросы, поставленные в данной статье.
1. Если в ПП много функционала для выполнения повторяющихся действий, в тестовом наборе будет много однотипных тестов. Автоматизированное тестирование позволяет существенно сократить время выполнения повторяющихся тестов (например, тесты могут выполняться в круглосуточном режиме). ПП, в которых есть функционал для многократного выполнения однотипных действий, лучше всего поддается автоматизации, поэтому данный фактор — первый в списке.
2. Каждая новая версия ПП должна проходить цикл регрессионного тестирования. Полностью проверяется весь функционал, то есть повторно выполняются старые тесты. Разработанный для более ранних версий набор автоматических тестов с актуальными изменениями может применяться в новой версии ПП. Это позволяет экономить ресурсы при подготовке тестовых наборов. Из вышесказанного следует, что автоматизация эффективна при регрессионном тестировании (второе место в списке).
3. Визитная карточка ПП — пользовательский интерфейс, поэтому его проверка производится практически при каждой тестовой итерации. Тестирование пользовательского интерфейса, если работа с ПП требует ввода в специальные поля большого количества данных, становится рутинным процессом для тестировщика. Одни и те же действия с небольшими вариациями выполняются много раз. Негативную роль может сыграть человеческий фактор — от однообразной работы внимание тестировщика притупляется. Именно такие тесты легко автоматизируются. Итак, вопрос об особенностях интерфейса ПП — третий в списке.
4. Одна из важных характеристик ПП — производительность, ее уровень и стабильность. Тестирование производительности обычно подразумевает поэтапное увеличение нагрузки — увеличивается частота выполнения операций и (или) количество пользователей. На каждом уровне нагрузки измеряются системные показатели (ожидание процессорами ввода-вывода, очереди на использование процессора, очереди на использование диска и т. д.). Такие показатели обычно считываются с помощью специальных программных средств, то есть с использованием автоматизации, поэтому вопрос о тестировании производительности занял четвертое место.
5. Конфигурация рабочей станции зависит от особенностей ее функциональных частей, характера связей между ними и от требований решаемых задач [5]. Предполагается, что у конечных пользователей ПП будут различные конфигурации рабочих станций. Этим объясняется важность конфигурационного тестирования. Различные конфигурации часто встречаются в известных распределенных системах [6]. Набор возможных конфигураций велик, на каждой из них прогоняются однотипные тесты. Таким образом, автоматизация конфигурационного тестирования помогает экономить значительные ресурсы и занимает пятое место в списке.
6. Во многих случаях для ПП важна устойчивость работы при чрезмерных нагрузках на систему (банковское ПО, навигационное ПО). Возникает необходимость проводить нагрузочное тестирование. Удобно имитировать максимальные нагрузки с использованием специальных инструментов автоматизации (шестое место).
7. На сегодняшний день многие ПП имеют web-интерфейс (кроссплатформенный по своей природе). Он менее ресурсоемкий, и его использование позволяет не устанавливать на рабочую станцию вспомогательное ПО. Зачастую web-интерфейс одного ПП обладает объемным функционалом. Ручное тестирование может занять много времени, а сократить его помогает автоматизация, поэтому вопросы, касающиеся интернет-приложений, включены в блок
g автоматизации и занимают здесь последнее, седьмое место.
d Следует отметить, что в современных условиях ручное тестирование не теряет актуальности [7]. И следую-
д щий блок объединяет вопросы (с 8-го по 16-й) именно о ручном тестировании. Чем больше количество положитель--§ ных ответов в этой части вопросника, тем большая доля ручного тестирования необходима.
г;^ 8. Если функционал предполагает ручные операции во время работы ПП (например, загрузка диска, подклю-
д
"й чение дополнительного оборудования), то необходимо участие тестировщика в процессе выполнения проверок. Соот-.> ветственно, вопрос о функционале ПП поставлен в данном блоке на первое место.
¡¿, 9. Удобство (эргономичность) подразумевает свойства ПП, влияющие на параметры применения и их инди-
J3 видуальную оценку потенциальными пользователями [8]. Высокая эргономичность ПП позволяет быстрее решать задачи, входящие в функционал, поэтому данный вопрос занимает второе место в блоке.
10. Корректность установки важна, так как хотя бы один раз каждый ПП проходит процесс установки (третье 136 место в блоке).
11. Удобочитаемость — это, в первую очередь, простота восприятия информации. За рубежом разработаны специальные формулы для расчета удобочитаемости. Например, для текстов на английском языке активно используется формула Флэша — Кинкайда [9]:
Удобочитаемость = 206,835 - 1,015 х (всего слов/всего предложений) -- 84,6 х (всего слогов/всего слов).
Из представленной формулы видно, что наиболее удобочитаемы тексты с довольно короткими словами и предложениями.
Некоторое представление об удобочитаемости дает так называемый индекс туманности Ганнинга. Точнее, он показывает примерный возраст, с которого можно понимать данный текст. Первоначально разработанная для английского языка, формула Ганнинга, соответствующим образом модифицированная, иногда применяется и для русскоязычных текстов. Важным параметром данного индекса является удельное число многосложных слов (как правило, в русском языке считаются многосложными слова с количеством слогов более четырех). Очевидно, что чем больше в тексте многосложных слов, тем он труднее для восприятия. Однако следует отметить, что на сегодняшний день нет общепризнанных подходов для определения удобочитаемости русскоязычных текстов. Во многих случаях приходится полагаться на экспертную оценку, не поддающуюся автоматизации. Удобочитаемость выходных данных обеспечивает комфорт в работе конечных пользователей, что напрямую влияет на массовость распространения ПП и его востребованность. Данный вопрос поставлен на четвертое место в блоке.
12. Количество сторонних управляющих элементов, используемых при разработке, напрямую влияет на выбор подхода тестирования. Известно поведение на выходе сторонних управляющих элементов, но не известна их внутренняя структура. Если есть документация на каждый управляющий элемент, возможно применение автоматизированного тестирования. В противном случае рекомендуется сосредоточиться на разработке ручных проверок, которые «нацелят» данные элементы на выполнение нужных в процессе тестирования действий (пятое место в блоке).
13. Если цель тестирования — проверить обеспечение сохранности данных, то могут активно использоваться ручные операции: прекратить подачу электропитания, внести вручную ошибочные значения в таблицы баз данных, закрыть ПП на компьютере в момент выполнения им синхронизации данных (с сетевыми папками, мобильными устройствами, совместно используемым ПО). Данный вопрос находится в блоке на шестом месте.
14. В ряде случаев необходимо протестировать Graphical user interface (GUI) — графический интерфейс пользователя, элементы которого (кнопки, меню, иконки) выполнены в виде графических изображений. Такое тестирование направлено на проверку:
— внешнего вида и форм взаимодействия с пользователями;
— доступа к внутренней функциональности IIII через элементы интерфейса.
Ручное тестирование предпочтительнее, так как тестировщик оценивает интерфейс не по формальным признакам, а следовательно, сможет найти больше дефектов. Поддержка ручных тестов GUI менее затратная в финансо- § вом плане. Хотя автоматизация не исключается, так как повышает скорость и объемы выполняемых. Данный фактор занимает седьмое место в блоке. {§
15. Тестирование качества печати требует экспертной оценки, поэтому автоматизация здесь невозможна. В j^1
данном случае функционал IIII довольно узок, и вопрос занимаем в списке восьмое место. ^
к
16. Если сроки тестирования ограничены, то оптимальным выбором будет автоматизация процесса. Ручные се
операции имеют смысл только в случае, если данный IIII поступил на тестирование впервые (то есть это не регресси- g
л
онное тестирование). Таким образом, данный вопрос занимает в блоке последнее, девятое, место. jg
Третий блок включает вопросы (с 17-го по 20-й), выявляющие необходимость смешанного тестирования. ¡^
17. Функциональное тестирование — самое сложное и объемное, поэтому уместна как ручная, так и автома- щ тизированная проверка, в зависимости от оцениваемого функционала (первое место в блоке). ч
18. Для некоторых ММ приходится заново создавать наборы входных тестовых данных перед каждой итера- ^ цией тестирования. Например, тестирование пользовательских аккаунтов на форуме. !ри несоблюдении пользовате- § лем правил форума его аккаунт может быть заблокирован. Вместо заблокированных аккаунтов придется создавать ^ новые для следующей итерации тестирования. Непосредственно ввод данных о новом пользователе в поля можно ав- д томатизировать, однако подтверждение регистрации переходом из электронного письма по ссылке придется делать
w
вручную. Таким образом, требуется смешанное тестирование. Вопрос занимает второе место в блоке. К
19. Тестирование на некорректных входных данных может проводиться и вручную, и с применением автома- ^ тизации. Данный вопрос касается небольшой группы тестов, поэтому он на третьем месте. q1
20. Для тестирования логики необходим доступ к программному коду. Обычно сложность вызывает тестирование циклов. Рекомендуется разработать стратегию выделения маршрутов тестирования с указанием количества ите- К раций циклов. В результате происходит приведение ИЛ к ациклическому типу. Далее тестирование отдельных моду-
лей автоматизируется, остальные проверяются вручную. Доля автоматических и ручных тестов варьируется в зависимости от индивидуальных особенностей ПП, поэтому вопрос поставлен на четвертое место в блоке.
Опросник с бинарными ответами (да — 1, нет — 0) передается в отдел тестирования, и ведущий тестировщик расставляет веса вопросов. Для мотивированного отличия и упрощения обработки рекомендуется набор весов {0,25; 0,5; 0,75; 1}. Вес будет мало различаться для ПП, принадлежащих одному классу программ, что позволит составлять и запоминать сценарии тестирования для типичных случаев. Уже с таким набором информации тестировщик может приступать к составлению плана тестирования, в котором он более обоснованно будет выбирать способ тестирования: автоматизированный, ручной, смешанный.
Процесс может быть формализован и далее — переходом к постановке и решению многокритериальной задачи [10].
Выводы. Свойства, определяющие полезность ПП, связаны с методом тестирования. Если требуется проверка функциональных возможностей и (или) надежности, рекомендуется применять смешанное (ручное и автоматизированное) тестирование. Если требуется проверка практичности и (или) сопровождаемости, рекомендуется применять ручное тестирование. Если требуется проверка эффективности и (или) мобильности, рекомендуется применять автоматизированное тестирование.
Предложенная в данной работе методика дает возможность инженеру-тестировщику принять решение о выборе подхода к тестированию ПП. В основе метода лежат характеристики ПП, имеющие статус стандарта. Предложенная методика подходит как для десктопных, так и для веб-приложений. После небольших уточнений в списке вопросов, она может быть применена и для тестирования мобильных приложений.
Библиографический список
1. Roebuck, K. System Development Life Cycle (SDLC). High-impact Strategies — What You Need to Know: Definitions, Adoptions, Impact, Benefits, Maturity, Vendors / K. Roebuck. — Brisbane : Emereo Pty Limited, 2011. — 530 p.
2. ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению / Госстандарт России. — Москва : Изд-во стандартов, 2004. — 9 с.
3. Галимова, Е. Ю. Анализ алгоритма принятия решения об автоматизации тестирования программного продукта с применением свободного программного обеспечения Selenium / Е. Ю. Галимова // Теория и практика применения свободного программного обеспечения : сб. тр. Рос. молодеж. конф. с эл-тами науч. школы. — Магнитогорск : Изд-во Магнитогорского гос. техн. ун-та им. Г. И. Носова, 2016. — 223 с.
4. Gundecha, U. Selenium Testing Tools Cookbook / U. Gundecha. — Birmingham : Pack Publishing, 2012. — 309 p.
5. ГОСТ 15971-90. Системы обработки информации. Термины и определения / Гос. комитет СССР по управлению качеством продукции и стандартам. — Москва : Изд-во стандартов, 1991. — 13 с.
6. Галимова, Е. Ю. Автоматизация тестирования распределенных информационных систем / Е. Ю. Галимова // Информационные технологии и их применение : сб. тезисов докладов IV Всерос. интернет-конференции. — Иркутск : МГЛУ ЕАЛИ, 2016. — 210 с.
7. Галимова, Е. Ю. Преимущества ручного подхода к тестированию программного обеспечения / Е. Ю. Галимова // Наука в исследованиях молодых : мат-лы III Междунар. науч. форума студентов, магистрантов, аспирантов. — Новосибирск : Сибпринт, 2013. — 180 с.
8. ГОСТ 28806-90. Качество программных средств. Термины и определения / Гос. комитет СССР по управлению качеством продукции и стандартам. — Москва : Изд-во стандартов, 1991. — 8 с.
9. Кошелева, Д. Л. Определение уровня языковой сложности текстов для изучающих польский язык как иностранный : выпускная квалификац. работа / Д. Л. Кошелева — Москва : Высшая школа экономики, 2015. — 73 с.
10. Галимова, Е. Ю. Применение алгоритма многокритериальной оптимизации при выборе между ручным и автоматизированным тестированием / Е. Ю. Галимова, А. Н. Коваленко // Молодежь. Наука. Инновации : сб. докладов 63-й Междунар. молодеж. науч.-техн. конф. — Владивосток : Изд-во Мор. гос. ун-та, 2015. — Т. 1. — 356 с.
References
1. Roebuck, K. System Development Life Cycle (SDLC). High-impact Strategies — What You Need to Know: Def-r^ initions, Adoptions, Impact, Benefits, Maturity, Vendors. Brisbane: Emereo Pty Limited, 2011, 530 p.
2. GOST R ISO/MEK 9126-93. Informatsionnaya tekhnologiya. Otsenka pro-grammnoy produktsii. Kharakteristiki j> kachestva i rukovodstva po ikh primeneniyu. [State Committee for the Russian Federation for Standardization and Metrology. ^ GOST R ISO/MEK 9126-93. Information technology. Software product evaluation. Quality characteristics and guidelines £ for their use.] Moscow: Izdatel'stvo standartov, 2004, 9 p. (in Russian).
3. Galimova, E.Y. Analiz algoritma prinyatiya resheniya ob avtomatizatsii testirovaniya programmnogo produkta s primeneniem svobodnogo programmnogo obespecheniya Selenium. [Analysis of decision algorithm on test automation using Selenium free software.] Teoriya i praktika primeneniya svobodnogo programmnogo obespecheniya : sb. tr. Ros. molodezh.
13o
й о
T3
konf. s el-tami nauch. shkoly. [Theory and practice of free software: Coll.of papers. Russian Youth Conf. with elements of sci. school.] Magnitogorsk: Nosov Magnitogorsk State Technical University Press, 2016, 223 p. (in Russian).
4. Gundecha, U. Selenium Testing Tools Cookbook. Birmingham: Pack Publishing, 2012, 309 p.
5. GOST 15971-90. Sistemy obrabotki informatsii. Terminy i opredeleniya. [GOST 15971-90. Information processing systems. Terms and definitions.] USSR State Committee on product Quality Control and Standards. Moscow: Izdatel'stvo standartov, 1991, 13 p. (in Russian).
6. Galimova, E.Y. Avtomatizatsiya testirovaniya raspredelennykh informatsionnykh system. [Test automation of distributed information systems.] Informatsionnye tekhnologii i ikh primenenie: sb. tezisov dokladov IV Vseros. internet-konferentsii. [Information technologies and their application: coll.of abstr.and reports IV All-Russian Internet Conference.] Irkutsk: MGLU EALI, 2016, 210 p. (in Russian).
7. Galimova, E.Y. Preimushchestva ruchnogo podkhoda k testirovaniyu programmnogo obespecheniya. [Advantages of manual approach to software testing.] Nauka v issledovaniyakh molodykh: mat-ly III Mezhdunar. nauch. foruma studentov, magistrantov, aspirantov.[Science in research of the young: Proc. III Int. Sci. Forum of students, graduate students and postgraduates.] Novosibirsk: Sibprint, 2013, 180 p. (in Russian).
8. GOST 28806-90. Kachestvo programmnykh sredstv. Terminy i opredeleniya. [GOST 28806-90. Software quality. Terms and definitions.] USSR State Committee on product Quality Control and Standards. Moscow: Izdatel'stvo standartov, 1991, 8 p. (in Russian).
9. Kosheleva, D.L. Opredelenie urovnya yazykovoy slozhnosti tekstov dlya izuchayushchikh pol'skiy yazyk kak in-ostrannyy: vypusknaya kvalifikats. rabota. [Determining the linguistic complexity level of texts for learners of Polish as a foreign language.] Moscow: Higher School of Economics, 2015, 73 p. (in Russian).
10. Galimova, E.Y., Kovalenko, A.N. Primenenie algoritma mnogokriterial'noy optimizatsii pri vybore mezhdu ruch-nym i avtomatizirovannym testirovaniem. [Application of multi-criteria optimization algorithm in selecting between manual and automated testing.] Molodezh'. Nauka. Innovatsii: sb. dokladov 63-y Mezhdunar. molodezh. nauch.-tekhn. konf. [The Youth. Science. Innovations: Coll. of reports 63rd Int. Youth Sci.-Tech. Conf.] Vladivostok: Meritime State University Press, 2015, vol. 1, 356 p. (in Russian).
Поступила в редакцию 21.06.2016 Сдана в редакцию 22.06.2016 Запланирована в номер 30.09.2016
Received 21.06.2016 Submitted 22.06.2016 Scheduled in the issue 30.09.2016
(U К X <u 4 и
Л
С
^
к
ей И
к
X
*
(U
н «
ей X Л
ч
(U
н К
ч о К
Е 3 и
<й и к
<3
о, о
X
S
