CC BY
48
УДК 65.011.56: 065.006.004
СТАНДАРТИЗАЦИЯ ТРЕБОВАНИЙ К ТЕСТИРОВАНИЮ ПРИЛОЖЕНИЙ КОНЕЧНЫХ ПОЛЬЗОВАТЕЛЕЙ
© 2016
Яницкая Татьяна Сергеевна, кандидат технических наук, доцент кафедры «Информационный и электронный сервис» Гудков Антон Андреевич, студент 4 курса факультета «Информационный и электронный сервис» Поволжский государственный университет сервиса (445017, Россия, Тольятти, улица Гагарина, дом 4, e-mail: [email protected])
Аннотация. Под стандартизацией в статье понимается процесс по установлению правил для какого-либо вида деятельности, с целью их многократного использования в дальнейшем. В современном информатизированном обществе вопрос применения жестких правил для взаимодействия с IT-инструментарием, является актуальным, так как, только придерживаясь определенных требований, можно гарантировать минимум рисков информационной безопасности. В настоящее время одним из основных источников возникающих угроз IT-безопасности являются конечные пользователи. Под конечными пользователями авторами статьи понимаются внешние пользователи программных продуктов, по заказу которых эти продукты были разработаны. Особенностью деятельности «конечных пользователей» является то, что они используют результатную информацию, сформированную для них программным продуктом. Неграмотно построенные запросы на получение информации, отсутствие специальных знаний или выявление со стороны конечных пользователей попыток «настроить» систему, пробуя открывать любые файлы, не имея понятия, для чего они предназначены - это один из распространенных наборов ошибок, приводящих к довольно печальным последствиям. Поэтому при разработке приложений для конечных пользователей разработчик программных продуктов должен предусмотреть все попытки создания некорректных ситуаций, которые могут возникнуть после сдачи высокотехнологичного продукта в эксплуатацию заказчику. В этом случае процесс внутреннего тестирования на всех стадиях разработки поможет выявить критические точки возникновения ошибок. В предлагаемой широкому кругу читателей статье раскрыты особенности стандартизации требований, сформулированных в современных нормативных документах, на которые опираются разработчики приложений. Поскольку удовлетворенность потребителя готовым продуктом в условиях рыночной экономики является одним из важных конкурентных преимуществ, то актуальность рассматриваемых в статье вопросов несомненна.
Ключевые слова: стандарты, стандартизация, разработка приложений пользователя, конечные пользователи, процедура тестирования, контроль качества тестирования, QA-специалист.
STANDARDIZATION OF TESTING REQUIREMENTS FOR END-USER APPLICATION
© 2016
Ianitckaia Tatiyana Sergeevna, candidate of technical sciences, associate professor of the department
«Information-Technical Service» Gudkov Anton Andreevich, fourth year student of the faculty «Information-Technical Service»
Volga Region State University of Service (445617, Russia, Togliatti, st.Gagarina, 4, e-mail: [email protected])
Abstract. By standardizing the article refers to the process for the establishment of rules for any kind of activity, for the purpose of reuse in the future. In today's computerized society question the application of strict rules for interacting with the IT - tool is relevant, since it is only adhering to certain requirements, we can guarantee a minimum of information security risks. Currently, one of the main sources of emerging It threats - security is end users. Under the end-users by the authors refers to external users of software products, in order that these products been developed. A feature of the activities of «end-users» is that they use a results-based information generated for their software. Illiterate built requests for information, the lack of expertise or identifying end-user attempts to «tune» the system, trying to open any file, not having a clue what they are - this is one of the most common sets of errors, leading to a rather sad consequences. Therefore, when developing applications for end users, software developer should provide all attempts to create incorrect situations that may arise after the date of commissioning of high-tech product to the customer. In this case, the process of internal testing at all stages of development will help identify critical points of error. In the present article a wider audience, especially disclosed standardization requirements set forth in the current regulations, which are based on the application developers. Since customer satisfaction is a finished product in a market economy is one of the most important competitive advantages, the relevance of the issues addressed in the article is beyond doubt.
Keywords: standards, standardization, development of user applications, end users, testing procedures, quality control testing, QA - specialist.
Постановка проблемы в общем виде и ее связь с важными научными и практическими задачами.
Важными приоритетами развития страны являются направления дальнейшей информатизации и интеллектуализации труда. Это нашло отражение в таких нормативных документах, как Концепция долгосрочного социально-экономического развития Российской Федерации на период до 2020 года [1], Распоряжение Правительства РФ от 20 октября 2010 г. N 1815-р «О государственной программе Российской Федерации «Информационное общество (2011 - 2020 годы)» [2], Указ Президента Российской Федерации от 7 мая 2012 г. № 596 «О долгосрочной государственной экономической политике»» [3] и другие.
Развитие информатизации привело к смене направлений производственной деятельности. Все больше рассматриваются ^-компании, которые занимаются внедрением информационных технологий и систем в промышленность, а также и в другие сферы деятельно-
сти. Ярким примером этого могут служить нормативные документы в области информационной безопасности страны [4], а также ФЗ «О персональных данных»[5] и ФЗ «Об информации, информатизации и защите информации» [6].
Необходимость внедрения основных идей и концепций, обозначенных в вышеописанных документах, приводят к широкому распространению деятельности различных компаний интеллектуального труда по разработке и внедрению программных продуктов собственного производства. Здесь, на наш взгляд, основную методологическую базу составляют документы стандартов [7-9], выполнение которых является обязательным. В связи с чем, актуальными являются вопросы стандартизации как деятельности персонала по продвижению требований стандартов в различные процессы жизненного цикла программного продукта, разрабатываемого ^-компаниями по Заказу потребителей и для нужд потребителей.
В этом случае Заказчик, он же потребитель конечной продукции, может быть отнесен к категории «конечный пользователь». Особую ценность для конечного пользователя принимают процессы оценки надежности программного обеспечения систем обработки информации [10], например, реализованные при тестировании [11] или при оценке качества и соответствия разрабатываемого программного обеспечения QA-специалистом на всех стадиях жизненного цикла изделия [12].
Уровень выполняемого тестирования отражает и уровень знаний специалиста-тестировщика. Если при проведении тестирования специалист-тестировщик использует методологию RUP, то процесс тестирования проводится по всем фазам жизненного цикла изделия, где также оценивается и качество разрабатываемых версий программного продукта. В процессе тестирования он выполняет поиск и документирование дефектов качества, проверку функционирования готового изделия в соответствии с требованиями частного технического задания (ЧТЗ), проверку качества соответствия выполненных требований. Здесь под качеством соответствия понимается документационное сопровождение приложения для конечного пользователя, в котором описан инструктивный материал для него, необходимый при взаимодействии с программным продуктом. Вопросы тестирования, таким образом, являются непременным атрибутом процесса разработки и внедрения любого программного продукта.
Существуют разные подходы к тестированию, суть которых отражена в действующих ГОСТ.
Проблема исследования состоит в поиске и обосновании набора минимального количества методик, в которых определены обязательные требования к тестированию приложений конечных пользователей.
Анализ последних исследований и публикаций, в которых рассматривались аспекты этой проблемы, показал, что существует достаточно много научных работ, в которых рассматриваются подходы к выполняемым этапам тестирования или имеющемуся инструментарию тестировщика 13-15]. Например, анализ требований ГОСТ, показал, что основными требованиями стандартов на оценку качества программных продуктов является оценка восьми базовых характеристик [13], тестирование которых раскрыто для мобильных устройств более подробно в [14] и [15]. Также, описание процесса тестирования отражено в трудах [16-17], нормативном документе [18].
Формирование целей статьи (постановка задания).
Исходя из вышеизложенного, основной целью статьи является ознакомление широкого круга заинтересованных лиц c особенностями стандартизации предъявляемых требований к тестированию приложений конечных пользователей, позволяющих разработать методику выполнения процедуры тестирования QA-специалистом результатов интеллектуального труда и получать обратную связь с конечными пользователями, положительную или отрицательную, в зависимости от качества полученных результатов.
Изложение основного материала исследования с полным обоснованием полученных научных результатов.
С точки зрения стандартизации, пользовательский интерфейс можно рассматривать как совокупность правил, методов и средств, обеспечивающих реализацию взаимодействия пользователя с программным продуктом и его внутренней программной средой [15].
Обычно интерфейс пользователя определяет язык и знания конечного пользователя, а также язык сообщений, отражающихся на экране дисплея компьютера.
Тестирование является одним из важных этапов оценки завершенности программного продукта. Можно сказать, что при положительном заключении результатов тестирования, следует естественное окончания процесса разработки программного продукта.
В соответствии со стандартом SWEBOK, под тести-
рованием понимается «проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранных определенных образом» [1, с.12].
В базовом стандарте ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств [2], нет понятия «тестирование», а есть только определение «тестируемость» и «тестовое покрытие». Отсюда следует, что проводя процесс тестирования и опираясь на базовые понятия стандарта по оценке качества [3] следует оценивать такие показатели программного продукта как надежность, эффективность, устойчивость, мобильность, адаптируемость.
С точки зрения руководителя проекта, тестирование, как обязательная процедура, сопровождающая весь процесс разработки программного изделия, начиная с постановки задачи и заканчивая сдачей готового продукта заказчику, представляет собой интеллектуальную деятельность, направленную на поиск отрицательной или положительной обратной связи, позволяющей оценить, насколько точно соответствует разрабатываемый программный продукт своему функциональному назначению.
На рисунке 1 показана модель тестирования, представляемая руководителем проекта в общем виде.
Модель тестирования процесса изготовления программного продукта
Рисунок 1 - Модель тестирования программного изделия
На выходе получаются документы, на основании которых появляется возможность оценки так называемой «обратной связи». Тестировщик показывает результаты того, что достигли разработчики программного кода и внешних форм приложения, как они соответствуют требованиям частного технического задания (ЧТЗ) и требованиям Заказчика, предъявляемых к функционалу. В данном случае можно считать, что тестировщик оценивает качество результата деятельности IT-компании по отдельно взятому проекту и корректирует процесс дальнейшей разработки программного продукта.
Что касается тестирования программного продукта, согласно методологии RUP, то разработчики ПО сами тестируют на различных фазах разработки собственный продукт интеллектуального труда. Тесты автоматизированы, они описываются с помощью библиотеки jUnit.
Описать тест можно с помощью цепочки тестирования взаимосвязанных методов, например, авторизованный пользователь имеет права создавать комментарии. Комментарий - имеется в виду в программном продукте создавать обратную связь.
Рассмотрим План тестирования:
1. Авторизовать пользователя с логин/пароль;
2. С помощью полученного токена авторизации вызвать функцию создания комментария.
В данном случае, ожидаемый результат - комментарий создан, и автор созданного комментария - авторизованный пользователь.
Нагрузочное тестирование осуществляется с помощью средства тестирования SOAP и Rest Services -SoapUI.
Для этого достаточно подготовить данные для запроса, и указать сколько одновременных подключений нужно производить и в течение какого времени. Для из-
мерения нагрузки на приложение используется jProfiler. С его помощью определяются узкие места кода, которые выявляются после нагрузочного тестирования.
В таблице 1 отражен фрагмент процесса тестирования: общий подход.
Таблица 1 - Выполнение процесса тестирования при подготовке программного продукта к сдаче в эксплуатацию (фрагмент)
Виды тестирования Инструментальные средства Комментарии
Модульное тестирование jUnit. FrameWork. поддерживающий технологию TDD (test-driven development). Позволяет либо подтвердить, либо опровергнуть корректность программного кода
Нагрузочное тестирование SoapUI Позволяет эмулировать множественные запросы в течении заданного времени
Тесты производительности jProfiler Позволяет определить узкие места программного кода при нагрузочном тестировании.
циями. При работе могут быть обнаружены проблемные места не только в программном продукте, но и в требованиях спецификации. QA (Quality Assurance -специалист по качеству) специалист, который в реальных компаниях занимается улучшением процесса разработки программного обеспечения.
управление качеством
контроль качества
тестирование
ЧТЗ
ПП
Тесты пишет сам разработчик, либо ведущий разработчик. Модульные тесты запускаются автоматически при сборке проекта. Нагрузочное тестирование и тесты производительности выполняются приблизительно 1-2 раза в месяц.
Тестирование для оценки готовности программного продукта выполняет тестировщик. Каждая бизнес-функция имеет свои критерии приемки. Тестировщик должен проверить соответствует ли реализация этим критериям. Для оценки соответствия требуется обязательное наличие ЧТЗ.
На рисунке 2 показана диаграмма работ, связанных с выполнением процесса тестирования QA-специалистом.
Рисунок 3
Под управлением качества в данном случае понимается обеспечение качества программного продукта, и, в случае выполнения отклонений от требований ЧТЗ, принятие решений по внесению корректирующих действий, снижающих негативное влияние на качество приложения для конечного пользователя.
Как пример рассмотрим процесс оценки надежности программного продукта для конечного пользователя, представленного в виде информационной системы.
Рассмотрим план испытаний с восстановлением отказавших элементов типа [Ы,В,Т]. Для этого плана момент наблюдаемых отказов образуют пуассоновский поток с интенсивностью L=lN.
В плане типа [Ы,В,Т] мы наблюдаем пуассоновский поток отказов с интенсивностью в течение времени Т. Пусть ^Т) - число наблюдаемых отказов, которое произошли в моменты 11, ..., 1 ^Т) .
Рассмотрим более подробно ситуацию тестирования надежности работы в - версии программного продукта.
В течение 200 часов общего времени работы было зафиксировано 5 отказов в определенные моменты времени. Испытания проводились по плану [N=100, В, Т=200] [18].
Отказы произошли в моменты
t
Рисунок 2 - Диаграмма работ в процессе тестирования
В целом, процесс тестирования может быть связан с контролем качества выполнения работ, в соответствии с ЧТЗ и обеспечением качества, под которым понимается процесс поддержания постоянного уровня качества программного продукта.
С точки зрения вложенности процессов друг в друга, все работы взаимосвязаны и находятся на разных уровнях соподчиненности друг другу.
На рисунке 3 покажем взаимосвязь процессов выявления несоответствий QA-тестировщиком.
На рисунке отражено, что оценка Приложения для пользователя с точки зрения тестировщика является сложным многоступенчатым процессом, суть которого в управлении качеством готового программного продукта (1111). Самое «близкое» - это оценка соответствия требованиям ЧТЗ, а затем - более расширенное тестирование, контроль качества тех параметров, которые являются ключевыми для оцениваемого ЧТЗ, и управление качеством в случае выявленного несоответствия. Специалист по тестированию сталкивается с нестандартными ситуа-
= 51, t2 = 78, t-6 = 110, =135, t5 Общее число отказов ¿1 (200) = 5 •
По формуле (1) находим, что
5
180
2 =
100■200 ивнос d (T )
= 2,5'10"
(1)
Интенсивность пуассоновского потока вычислим по формуле:
Я = dT±. (2)
N *T F(t)=1 - exp(-l t ), где
p = 2, е = 2,7.
Пусть F(t)=1 - exp(-lt ) =
(3)
) = 1 - в
-Xtp
Тогда: Я =
5
d (T )
N *T 100*200
= 0,00025 = 2,5*10-
Произведем необходимые расчеты и построим график. Все расчеты отражены ниже в таблицах.
4
N 100
Т = 100
11 = 0
= 1
Ь = 51
Ь = 78
й = 110
ь = 13}
= 180
Ии)-1 -2.5*10 4'02 =0
»1-й -, 7-2.5*1(Г4*12 = 0 0002
=0,779
г-М- , ■ •!<!К* -0,950
вд- , -- . -шНч1,5 -0989
вм- , -'И! Я# -0,99?
1 г«
0 0
1 0,0002
50 0,5
7! 0,"9
110 0,95
155 0,989
180 0,999
F(t)= ехр(-1 *Р ) = 1 - е
Постоим график (рисунок 4).
Ряд1 Ряд2
-0,2
Рисунок 4 - График оценки надежности работы приложения для конечного пользователя
Из рисунка видно, что с увеличением времени испытаний вероятность безотказной работы (наработка до первого отказа) возрастает, а вероятность отказа падает.
Достаточной статистикой является число ^Т) отказов, прошедших за время испытаний, а сами моменты отказов 11, ..., М(Т) никакой дополнительной информации о параметре 1 не содержат.
Выводы исследования и перспективы дальнейших изысканий данного направления.
Проведенные исследования позволили выявить методику тестирования приложений конечных пользователей и составить правила их проведения для специ-алистов-тестировщиков. Наличие этих правил позволят разработать в будущем стандарт предприятия, что важно для современной 1Т-компании. После сбора информации необходимо собрать статистику отклонений. Ее
анализ позволит увидеть проблемные участки в работе программного продукта. Анализ статистики, полученной в разных релизах программного продукта, позволит выявить устойчивую проблему, при ее наличии [20-22].
Конечно, нельзя не отметить, что для специалиста по тестированию основным документом является спецификация. Все показатели оценки работы программного продукта должны основываться на требованиях именно этого документа. Не менее важным является необходимость создания предпосылок в организации качественного процесса разработки ПО. Для эффективной работы здесь необходимы знания в различных областях: проектирование, моделирование, программирование и т.д.
Таким образом, мы рассмотрели основные подходы, связанные с процессом организации работы рА-инженера, тестирования программного обеспечения и оценки показателей надежности работы программного продукта при нагрузочном тестировании.
СПИСОК ЛИТЕРАТУРЫ:
1. Концепция долгосрочного социально-экономического развития Российской Федерации на период до 2020 года (З.З.Развитие образования) - [Электронный ресурс]. Источник: http://www.smo1in.ru/odv/reference-source/2008-03.htm
2. Распоряжение Правительства РФ от 20 октября 2010 г. N 1815-р «О государственной программе Российской Федерации «Информационное общество (2011 - 2020 годы)» - [Электронный ресурс]. Источник: http://base.garant.ru/199708/
3. Указ Президента Российской Федерации от 7 мая 2012 г. № 596 «О долгосрочной государственной экономической политике»» - [Электронный ресурс]. Источник: http://www.krem1in.ru/news/15232
4. Доктрина информационной безопасности Российской Федерации» (утв. Президентом РФ 09.09.2000 № Пр-1895) и Указ Президента РФ от 12.05.2009 № 537 «О Стратегии национальной безопасности Российской Федерации до 2020 года»
5. Федеральный закон Российской Федерации от 27.07.2006 г. № 152-ФЗ (ред. от 23.07.2013 г.) «О пер -сональных данных» // Справочно-правовая информационная система «Консультант+».
6. ФЗ «Об информации, информационных технологиях и защите информации» [Электронный ресурс]. - Режим доступа: http://base.consu1tant.rU/cons/cgi/oniine. cgi?req=doc; Дата обращения: 30.11.16.
7. Руководство к Своду Знаний по Программной Инженерии. SWEBOK, 2004, с.1-2. Источник доступа: http://www.swebok.org.
8. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. Источник доступа: http://docs.cntd.ru/document/ gostr-iso-mek-12207-2010
9. ГОСТ Р ИСО/МЭК 9126:1993 Информационные технологии. Оценка программных продуктов. Характеристики качества и руководящие положения по их применению. Источник доступа: http://www.vniims. ru/0091ab/docs/9126_93.pdf
10. Корнеев Н.В., Башлыкова А.А. Современные алгоритмы и модели оценки надежности программного обеспечения систем обработки информации / Человеческий капитал. 2011. № 11. С. 168.
11. Данилова М.С. Тестирование программного обеспечения и составление проектной документации // Информационные технологии. Радиоэлектроника. Телекоммуникации 1ТЯТ - 2015. Тольятти, 2015. ч.1. с.220-224
12. Гудков А. А. Стандартизация деятельности 1Т-компаний: необходимость и реальность [Текст] / А. А. Гудков // Инновационные технологии в науке и образовании : материалы IV Междунар. науч.-практ. конф. (Чебоксары, 18 дек. 2015 г.) / редкол.: О. Н. Широков [и др.]. — Чебоксары: ЦНС «Интерактив плюс», 2015. —
№ 4 (4). — С. 281-284. — ISSN 2413-3981
13. ГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов. М.: Статинформ, 2015.-29 с.
14. Гленфорд Майерс, Том Баджетт, Кори Сан-длер. Искусство тестирования программ, 3-е издание=The Art of Software Testing, 3rd Edition. — М.: «Диалектика», 2012. — 272 с. — ISBN 978-5-8459-1796-6.
15. Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М.: «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series). — 1000 экз. — ISBN 978-5-8459-1625-9.
16. Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс. Практический объектно - ориентированный анализ и проектирование, 2е издание. - Пер. с англ. -СПб: Символ Плюс, 2007. - 624 с., ил.
17. Якобсон, А. Унифицированный процесс разработки программного обеспечения [Текст] / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб. : Питер, 2002. - 496 с.
18. ГОСТ Р 27.403- 2009. Планы испытаний для контроля вероятности безотказной работы
19. Яницкая, Т. С. Разработка системы менеджмента качества для предприятий малого и среднего бизнеса с использованием методов структурного анализа [Текст] / Т. С. Яницкая // Проблемы машиностроения и автоматизации. - 2012. - № 2. - С. 8-13.
20. Яницкая, Т. С. Разработка методов структурного анализа и моделирования при разработке систем управления качеством [Текст] / Т. С. Яницкая // Школа унив. науки: парадигма развития. - 2010. - № 1 (1), Т. II. - C. 317-322.
21. Яницкая, Т. С. Управление ИТ-процессами как неотъемлемая часть системы менеджмента качества [Текст] / Т. С. Яницкая, Е. Ю. Малышева, С. М. Бобровский // Вестн. ПВГУС. Сер. «Экономика». - 2011. - Вып. 3 (17). - С. 138-143.
22. Яницкая, Т. С. Инжиниринговая платформа RUP и особенности ее внедрения в деятельность IT-компаний [Текст] / Т. С. Яницкая, А.А. Гудков Вопросы технических наук: новые подходы в решении актуальных проблем, сборник научных трудов по итогам международной научно-практической конференциит // Изд.: Инновационный центр развития образования и науки, 2016 г.
