CC BY
57
УДК 004.415.53
МЕТОДИКА ВЫБОРА АВТОМАТИЗИРОВАННОГО, РУЧНОГО И СМЕШАННОГО СПОСОБА ТЕСТИРОВАНИЯ ПРОГРАММНОГО ПРОДУКТА, ОСНОВАННАЯ НА КРИТЕРИЯХ КАЧЕСТВА
Е.Ю. Галимова
Предлагается алгоритм выбора метода тестирования, базирующийся на качественных характеристиках программного продукта и учитывающий мнения и опыт разработчиков и тестировщиков.
Ключевые слова: тестирование программного обеспечения, ручное тестирование, автоматизированное тестирование, качество программного обеспечения, метод выбора.
Понятие качества в наши дни рассматривается в первую очередь в контексте двух систем: TQM (всеобщий менеджмент качества) и ISO 9000 (система качества). В данной статье в основном рассматриваются стандарты ISO 9000, по причине того, что они являются государственными в России. Качество программного продукта - многогранное понятие. Его можно рассматривать с философской позиции как то, что возможно распознать, но трудно определить (трансцедентальная трактовка). Качество с точки зрения пользователя - это соответствие продукта его назначению. Для производителя - это соответствие спецификации. Качество можно охарактеризовать как внутренние свойства продукта в совокупности. Оценка качества также может проводиться на основе стоимости готового изделия [1].
Для соблюдения качества важна слаженная организация всего процесса производства продукта, то есть система качества. В этом контексте организация рассматривается как совокупность управляемых процессов. Вариации характеристик производимого продукта есть результат выполнения данных процессов [2]. Создание программного обеспечения есть длительный, трудоёмкий, сложный процесс, поэтому важно разработать эффективные методы для обеспечения качества программных продуктов.
В данной статье обсуждается процесс тестирования десктопного программного продукта в рамках каскадной модели жизненного цикла программного обеспечения как способ повышения качества. Разрабатывается метод выбора подхода к тестированию на основе качественных характеристик программного продукта.
Каскадная модель жизненного цикла программного обеспечения имеет ряд достоинств [3]. Она широко известна заказчикам, разработчикам и пользователем программного продукта; характеризуется стабильностью требований. Процесс создания программного продукта (1111) разбивается на этапы. Переход к следующему этапу происходит только после полного завершения текущего. Поэтапность модели делает её простой и удобной в
применении. Каскадная модель предпочтительна, когда требования к качеству имеют приоритетное значение по сравнению с затратами и временными рамками проекта.
Дымовое (приёмочное) тестирование. Тестирование играет важную роль в процессе оценки качества современных ПП, ориентированных на разные сферы нашей жизни: коммерческое программное обеспечение, программные комплексы для военных систем, программное обеспечение для тяжёлой и лёгкой промышленности, научное программное обеспечение. Для научных областей, основанных на вычислениях, наиболее важна инженерия программного обеспечения [4], которая включает в себя тестирование как одну из главных составляющих [5]. Идёт постоянное увеличение объёмов обрабатываемых данных [6], в том числе и в облачных хранилищах [7], важно обеспечивать их высокое качество.
Существует мнение, что ручные тестовые проверки подходят для негативного тестирования, то есть тестирования, направленного на критику проекта [8]. Однако в ручную можно проводить и позитивное, поддерживающее проект тестирование. Например, дымовое (приёмочное) тестирование. Суть дымового (smoke) тестирования состоит в экономии временных затрат. Полное приёмочное (acceptance) тестирование требует достаточно много времени, если есть ограничение по срокам, например, нужно бегло проверить приложение за один день, следует применять дымовое тестирование.
fail
fail
Рис. 1. Место Бтвке-тестирования в процессе выпуска релиза
программного продукта
Тестирование новых сборок ПП называется регрессивным тестированием. В ходе такого тестирования следует избегать избыточности тестов [9], поскольку ограниченность ресурсов, выделяемых под тестирование, является распространённой проблемой [10]. Удобнее всего проводить Бтоке-тестирование, сформировав список функций по техническому заданию. Оценка времени выполнения тестовых наборов важна для планирования процесса тестирования и выбора приоритетных проверок [11]. Далее можно высчитать общее время первичного тестирования (Т) по формуле:
Т = / ■ г,
где / - количество основных функций ПП; г - усреднённое время прохождения тестовой проверки.
Усредненное время прохождения тестовой проверки можно высчитать по следующему алгоритму. Сформировать базовую группу тестов по одному тесту из каждого базового множества. Пример деления на множества: инсталляционные тесты, тестирование меню, тестирование кнопок, тестирование отображения элементов и данных на основном фрейме. Из каждой такой группы берется по одному тесту и формируется базовое множество О. Время выполнения группы проверок О делится на количество проверок. Таким образом получаем значение г.
При отсутствии технического задания предлагается вычислять общее время первичного тестирования с использованием метрики К - количества объектов главной формы ПП, таких как кнопки, пункты меню, основная табличная форма и так далее:
Т = (к + 4) • г.
Величина в коэффициенте (К + 4) есть сумма следующих параметров: тестовая проверка инсталляции + тестовая проверка запуска программного продукта + тестовая проверка выхода из приложения + тестовая проверка деинсталляции.
Выбор способа тестирования программного продукта. Жизненный цикл любого ПП условно можно разделить на четыре стадии: подготовка, разработка, тестирование, внедрение и сопровождение; среди которых тестирование и сопровождение являются наиболее затратными [12]. На этапе подготовки создается описание продукта, разрабатываются бизнес-план, список учитываемых рисков, план разработки ПП и план приемо-сдаточных работ. Далее на этапе разработки создается исполняемая архитектура приложения, то есть работающий ПП, в котором реализован базовый набор функций. Третий этап - тестирование, которое проводится подразделением внутри компании-разработчика, сторонней организацией или с помощью краудсорсинга [13]. Для каждого нового ПП разрабатывается тестовый план, в котором описываются подходы и методы тестирования, затраты на проведение тестирования. Шаблон тест-плана подробно обсуждался в работе [14]. ПП может являться частью продуктовой линейки, то есть набора программных объектов, собранных вместе для решения определённых задач [15]. В таком случае проводится мероприятия по тестированию интеграции ПП, проверке корректности межпродуктовых взаимодействий, разрабатываются стратегии создания оптимального количества тестов [16, 17, 18]. Для дальнейшей оценки результатов тестирования удобно определять приоритетность тестовых наборов с помощью различных методов: базирующихся на метрике покрытия кода, на оценке вероятности ошибок, на логике ЦМЪ [19]. При любом подходе к оценке основными характеристиками хорошего теста являются эффективность, то есть способность обнаружить дефект; приемлемая стоимость отладки, выполнения тестового примера и анализа полученных результатов; способность теста эволюционировать, то есть оценка усилий, которые потребуются для перенастройки теста при каждом изменении ПП [20].
На этапе внедрения создается окончательная версия ПП, инструкции по установке и настройке и вспомогательные материалы для конечных пользователей. При составлении тест-плана предлагается использовать метод выбора между ручным, автоматизированным и смешанным тестированием. В наши дни идёт развитие автоматизации, но ручные тесты не тоже активно используются. Автоматизация - это дорогостоящий и длительный процесс. В короткосрочной перспективе менее затратной является техника создания сценариев путём записи и последующего воспроизведения, так как для них требуется меньше времени и менее квалифицированные специалисты. Сценарии, созданные методом программирования, более ресурсозатраты [21]. Они начинают окупаться приблизительно после третьего релиза. Однако, автоматизация позволяет освободить тестировщиков от выполнения большого количества однотипных тестов [22], больше времени можно выделять на исследовательское тестирование [23, 24].
При составлении тест-плана предлагается использовать метод выбора между ручным, автоматизированным и смешанным тестированием, основанный на модели качества ПП, описанной в ISO 9126. В России о характеристиках качества программного обеспечения разработан ГОСТ Р ИСО/МЭК 9126-93. Модель качества состоит из шести критериев качества, каждый из которых включает ряд подхарактеристик (рис.2):
1. Функциональные возможности (критерии, которые характеризуют наличие тех или иных функций в ПП, наличие у функций определённого набора свойств).
2. Надёжность (критерии, которые характеризуют способность ПП поддерживать заявленный уровень производительности в указанных условиях в течение определённого периода времени).
3. Практичность (критерии оценки усилий, необходимых для использования ПП; критерии формирования индивидуальных оценок заявленной группой пользователей).
4. Эффективность (критерии, характеризующие взаимосвязь между уровнем производительности ПП и количеством используемых ресурсов).
5. Сопровождаемость (критерии, характеризующие затраты на проведение специфических модификаций программного продукта).
6. Мобильность (критерии, которые характеризуют способность ПП быть установленным в разном программном окружении, на разных операционных системах).
Для улучшения взаимодействия групп программистов и тести-ровщиков на этапе передачи ПП в тестирование предлагается ряд вопросов (критериев), ответы на которые должны поступать на тестирование вместе с передаваемым ПП. Эти ответы для ухода от большой работы в группе программистов должны быть краткими (в самом простом виде - «да/нет») и даваться ведущими специалистами этой группы, предпочтительно - архитектором программного продукта (системным аналитиком). Они, путём диалога с программистами, могут уточняться после процедуры просмотра
списка спецификаций ведущими тестировщиками. На основе полученных ответов в группе тестирования принимается решение о ручном, автоматизированном или смешанном виде тестирования 1111 или его модулей (частей).
Функциональные возможности пригодность правильность
способность к взаимодействию согласованность
заядащенн о сгть
Надежность стабильность
Критерии качества ПО
Пр актичн о сть понятность
устроичивость к спи: оке восстанавливаемость
поучаемо сть
простота использования
Эффективность
характер изменения во времени характер изменения ресурсов
Сопрововдаемость анализируемо сть изменяемость
устойчивость тестируемость
Мобильность адаптируемо сть простота внедрения соответствие взаимозаменяемость
Рис. 2. Критерии качества программного обеспечения
Группе программистов предлагается список из вопросов, основанных на качественных свойствах ПП. Вопросы подробно обсуждаются в работе [25]. Из ответов «да» и «нет» формируется множество Р = (Р^,Р2, — ,Ьк). Значение Р/, / = 1,2,к,к есть единица или ноль. Тести-ровщики дают экспертные оценки а = (01 а 2, к, а к) каждому ответу. Два типа экспертных оценок помогают принять наиболее эффективное решение о выборе способа тестирования. Веса 01, а 2, к, а к рекомендуется назначать из множества [0, %, У, 3Л, 1]. В первой группе вопросов оценка единица есть удобство применения автоматизации тестирования; оценка % - весьма удобно; оценка У - не очень удобно; оценка У* - удобство под большим сомнением; оценка ноль - совсем не удобно. Во второй группе вопросов в пользу удобства ручного тестирования назначается оценка ноль; оценка У* - весьма удобно; оценка У - не очень удобно; оценка % -удобство под большим сомнением; оценка единица - совсем не удобно. Третья группа вопросов посвящена выбору смешанного подхода к тестированию. Принцип расстановки значений такой же, как для автоматизированного.
Далее производится замена весов ноль и единица на У* и % соответственно. Таким образом получаем множество значений
Р1,р2,к,Рк ® КЬ,-,Ьк.
Для композиционного подхода заменяем
01, а 2,—а к ® ^1, а2,-, ак.
Нормирование по группе для весов первой части вопросов:
аI = —, для I = 1,к,к\. к1
Для весов второй группы вопросов, направленной в пользу ручного тестирования:
(а_ 1) -71 7
а = ^--, для I = к\ + 1,к, .
к2
Для третьей группы вопросов, ориентированной на смешанное тестирование:
(«/ - 2
аг- =-2—, для I = ^2 + 1,...,к .
(к - к1 - к2)
Далее вычисляется групповая свёртка
Р = а1 ■ Ъ + а.2 ■ ¿2 + к + % • Ьк.
Полученное значение Р находится в интервале от -1 до 1 включительно. Математическое ожидание данной свёртки равно нулю, следовательно, положительные значения Р говорят в пользу автоматизации тестирования, отрицательные - в пользу ручного тестирования. Для большей обоснованности полученного результата границы отодвигаются от нуля. Выбраны значения Р\ = 0.2 и Р2 = - 0.2. Если Р >Р1, выдаётся рекомендация об автоматизированном подходе к тестированию ПП. Если Р < Р2, выдаётся рекомендация о ручном подходе к тестированию. Если Р2 < Р < Р1, предлагается дополнительно привлечь экспертные оценки. Данная методика программно реализована (рис. 3).
Выберите значение веса X
Предъявляются ли высокие требования к производительности?
Да
Выберите вес
ГО Г М4 Г 1/2 (* 3/4 Г 1
Продолжить
Рис. 3 Программная реализация методики
Заключение. Как следует из представленного материала, задача повышения качества особо актуальна в современном мире. Общий объём выпуска ПП быстро растёт. Для заказчиков и конечных пользователей ПП встал вопрос выбора наиболее надёжных отечественных поставщиков,
253
способных создать в разумные сроки 1111 высокого качества. Предложенная методика основана на межпрофессиональных взаимодействиях IT-специалистов, которые делают экспертные оценки качественных характеристик данного 1111. На основе полученных оценок с применением математической свёртки выбирается наиболее эффективный для конкретного ПП подход к тестированию. Путём видоизменения ряда вопросов в опросном листе для программистов данный метод можно применять также для мобильных и веб-приложений.
Список литературы
1. Kitchenham B., Pfleeger S. L. Software Quality: The Elusive Target // IEEE Software, January 1996. P. 12-21.
2. Визгунов А.Н. О реализации принципов процессного подхода в рамках системы управления качеством // Сборник научных трудов 4-й Международной научно-технической конференции (21-22 апреля 2016 года). Курск: ЗАО «Университетская книга», 2016. С. 86 - 88.
3. Соммервилл Иан. Инженерия программного обеспечения, 6-е издание: пер. с англ. М.: Издательский дом «Вильямс», 2002. С. 23.
4. Alden K., Read M. Scientific software needs quality control // Nature, No. 502 (7472), 2013. P. 448.
5. Журавлёва Е.Ю. Развитие и поддержка современных систем научного программного обеспечения // Региональная информатика и информационная безопасность. Сборник трудов. Выпуск 5/ СПОИСУ. СПб., 2018. С. 38-41.
6. Li Cai, Yangyong Zhu The Challenges of Data Quality and Data Quality Assessment in the Big Data Era. Data Science Journal, 2015. Vol. 14, No. 2. P. 1-10.
7. Changjiang Jia, Yan Cai, Yuen Tak Yu, T.h. Tse 5W+1H pattern: A perspective of systematic mapping studies and a case study on cloud software testing. Journal of Systems and Software, 2016. No. 116. P. 206-219.
8. Джез Хамбл, Дэвид Фарли. Непрерывное развёртывание ПО: автоматизация процессов сборки, тестирования и внедрения новых версий программ: пер. с англ. М.: ООО «И.Д. Вильямс», 2016. С. 105.
9. Sacha Lity, Manuel Nieke, Thomas Thum, Ina Schaefer : Retest test selection for product-line regression testing of variants and versions of variants. Journal of Systems and Software, No.147, January 2019. Pp 46-63.
10. Peng Xiao, Bin Liu, Shihai Wang Feedback-based integrated prediction: Defect prediction based on feedback from software testing process. Journal of Systems and Software, 2018. No.143. P. 159-171.
11. Sahar Tahvili, Wasif Afzal, Markus Bohlin, Sharvathul Hasan Ameerjan A tool for execution time estimation of manual test cases. Journal of Systems and Software, 2018. No.146. P. 26-41.
12. Каннер С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. К.: Издательство «ДиаСофт», 2011. С. 56.
13. Shikai Guo, Rong Chen, Hui Li, Jian Gao, Yaqing Liu. Crowdsourced Web Application Testing Under Real-Time Constraints. International Journal of Software Engineering and Knowledge Engineering, 2018. Vol. 28. Issue 06. P. 751-779.
14. Галимова Е.Ю. Пример разработки тестового плана на базе шаблона RUP, VI Ежегодная международная научно-практическая конференция "Перспективы развития информационных технологий", 2011. C. 97103.
15. Thüm T., Apel S., Kästner C., Schaefer I., Saake G. A Classification And Survey of Analysis Strategies For Software Product Lines // ACM Computing Surveys (CSUR), 2014. Vol. 47. P. 6.
16. AbdulRahman A. Alsewari, Muhammad N. Kabir, Kamal Z. Zamli. Software Product Line Test List Generation based on Harmony Search Algorithm with Constraints Support. International Journal of Advanced Computer Science and Applications, 2019. Vol. 10. No. 1. P. 605-610.
17. Johansen M.F., Haugen 0., Fleurey F. Properties Of Realistic Feature Models Make Combinatorial Testing Of Product Lines Feasible // Model Driven Engineering Languages and Systems. 14th International Conference, MODELS 2011 Wellington, New Zealand. Proceedings. Springer, 2011. P. 638652.
18. Yu L., Duan F., Lei Y., Kacker R.N., Kuhn D.R. Combinatorial Test Generation For Software Product Lines Using Minimum Invalid Tuples // in High-Assurance Systems Engineering (HASE), 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering, 2014. P. 65-72.
19. Tianning Zhang, Xingqi Wang, Dan Wei, Jinglong Fang. Test Case Prioritization Technique Based on Error Probability and Severity of UML Models // International Journal of Software Engineering and Knowledge Engineering, 2018. Vol. 28. Issue 06. P. 831-844.
20. Fewster M., Graham D. Software test automation. Effective use of test execution tools. Addison-Wesley, 1999. P. 4.
21. Milad Hanna, Amal Elsayed Aboutabl, Mostafa-Sami M. Mostafa Automated Software Testing Frameworks: A Review. International Journal of Computer Applications, 2018. Vol. 179. No.46. P. 22-28.
22. Криспин Л., Грегори Дж. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд.: пер. с англ. М.: ООО «И. Д. Вильямс», 2016. С. 252.
23. Ahmad Nauman Ghazi, Ratna Pranathi Garigapati, Kai Petersen. Checklists to Support Test Charter Design in Exploratory Testing. Agile Processes in Software Engineering and Extreme Programming - Proceedings of 18th International Conference, 2017. P. 1-7.
24. James A. Whittaker. Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design. Addison-Wesley. 2010. P. 21-32.
25. Галимова Е.Ю., Коваленко А.Н. Метод выбора между ручным и автоматизированным тестированием, основанный на свойствах программного продукта // Вестник Донского государственного технического университета, 216. № 4. С. 134-140.
Галимова Екатерина Юрьевна, ассистент, galim81@mail.ru, Россия, Санкт-Петербург, Санкт-Петербургский государственный университета промышленных технологий и дизайна
METHODS OF SELECTION AN A UTOMA TED, MANUAL AND SEMI-A UTOMA TED METHOD OF TESTING A SOFTWARE PRODUCT BASED ON QUALITY CRITERIA
E.Y. Galimova
An algorithm for choosing a testing method based on the quality characteristics of a so ftware product and taking into account the opinions and experience of developers and testers is proposed.
Key words: software testing, manual testing, automated testing, software quality, selection method.
Galimova Ekaterina Yuryevna, assistant, galim8lamail. ru, Russia, Saint-Petersburg, Saint-Petersburg State University of Industrial Technologies and Design
УДК 674.815
ТЕРМОДИНАМИЧЕСКИЕ СВОЙСТВА ПРОПИТОЧНЫХ МЕЛАМИНОКАРБАМИДОФОРМАЛЬДЕГИДНЫХ ОЛИГОМЕРОВ
М.Ю. Екимова
В статье изложены исследования термодинамических свойств модифицированных меламинокарбамидоформальдегидных олигомеров, полученных бесщелочным катализом. Определены зависимости термодинамических параметров меламинокар-бамидоформальдегидных олигомеров от количества меламина и количества эти-ленгликоля.
Ключевые слова: меламинокарбамидоформальдегидные олигомеры, бесщелочной катализ, модификатор-катализатор, термодинамические свойства.
Пропитанные декоративные бумаги по объёму применения занимают первое место среди видов облицовки древесных плит. В качестве пропиточных составов используют меламиноформальдегидные.
Меламиноформальдегидные олигомеры, используемые для пропитки бумаг, должны обладать хорошей пенетрационной способностью, которая зависит от молекулярной массы и равномерности её распределения по поверхности бумаги при пропитки. Пропиточные олигомеры, применяемые для облицовывания в настоящее время, не всегда обладают данными качествами, что приводит к ухудшению качества готовой продукции. Разработанные меламинокарбамидоформальдегидные олигомеры, модифицированные солями полифункциональных кислот, обладают хорошей пене-трационной способностью в течении всего времени хранения [5].
256
