Методика выбора автоматизированного, ручного и смешанного способа тестирования программного продукта, основанная на критериях качества
 Скачать 410.11 Kb.
|
|
Известия ТулГУ. Технические науки. 2019. Вып. 7 248 УДК 004.415.53 МЕТОДИКА ВЫБОРА АВТОМАТИЗИРОВАННОГО, РУЧНОГО И СМЕШАННОГО СПОСОБА ТЕСТИРОВАНИЯ ПРОГРАММНОГО ПРОДУКТА, ОСНОВАННАЯ НА КРИТЕРИЯХ КАЧЕСТВА Е.Ю. Галимова Предлагается алгоритм выбора метода тестирования, базирующийся на ка- чественных характеристиках программного продукта и учитывающий мнения и опыт разработчиков и тестировщиков. Ключевые слова: тестирование программного обеспечения, ручное тестиро- вание, автоматизированное тестирование, качество программного обеспечения, ме- тод выбора. Понятие качества в наши дни рассматривается в первую очередь в контексте двух систем: TQM (всеобщий менеджмент качества) и ISO 9000 (система качества). В данной статье в основном рассматриваются стан- дарты ISO 9000, по причине того, что они являются государственными в России. Качество программного продукта – многогранное понятие. Его можно рассматривать с философской позиции как то, что возможно распо- знать, но трудно определить (трансцедентальная трактовка). Качество с точки зрения пользователя – это соответствие продукта его назначению. Для производителя – это соответствие спецификации. Качество можно охарактеризовать как внутренние свойства продукта в совокупности. Оценка качества также может проводиться на основе стоимости готового изделия [1]. Для соблюдения качества важна слаженная организация всего про- цесса производства продукта, то есть система качества. В этом контексте организация рассматривается как совокупность управляемых процессов. Вариации характеристик производимого продукта есть результат выпол- нения данных процессов [2]. Создание программного обеспечения есть длительный, трудоёмкий, сложный процесс, поэтому важно разработать эффективные методы для обеспечения качества программных продуктов. В данной статье обсуждается процесс тестирования десктопного программного продукта в рамках каскадной модели жизненного цикла программного обеспечения как способ повышения качества. Разрабатыва- ется метод выбора подхода к тестированию на основе качественных харак- теристик программного продукта. Каскадная модель жизненного цикла программного обеспечения имеет ряд достоинств [3]. Она широко известна заказчикам, разработчикам и пользователем программного продукта; характеризуется стабильностью требований. Процесс создания программного продукта (ПП) разбивается на этапы. Переход к следующему этапу происходит только после полного завершения текущего. Поэтапность модели делает её простой и удобной в Системный анализ, управление и обработка информации 249 применении. Каскадная модель предпочтительна, когда требования к каче- ству имеют приоритетное значение по сравнению с затратами и времен- ными рамками проекта. Дымовое (приёмочное) тестирование. Тестирование играет важ- ную роль в процессе оценки качества современных ПП, ориентированных на разные сферы нашей жизни: коммерческое программное обеспечение, программные комплексы для военных систем, программное обеспечение для тяжёлой и лёгкой промышленности, научное программное обеспече- ние. Для научных областей, основанных на вычислениях, наиболее важна инженерия программного обеспечения [4], которая включает в себя тести- рование как одну из главных составляющих [5]. Идёт постоянное увеличе- ние объёмов обрабатываемых данных [6], в том числе и в облачных храни- лищах [7], важно обеспечивать их высокое качество. Существует мнение, что ручные тестовые проверки подходят для негативного тестирования, то есть тестирования, направленного на кри- тику проекта [8]. Однако в ручную можно проводить и позитивное, под- держивающее проект тестирование. Например, дымовое (приёмочное) тес- тирование. Суть дымового (smoke) тестирования состоит в экономии вре- менных затрат. Полное приёмочное (acceptance) тестирование требует дос- таточно много времени, если есть ограничение по срокам, например, нуж- но бегло проверить приложение за один день, следует применять дымовое тестирование. Рис . 1. Место smoke-тестирования в процессе выпуска релиза программного продукта Тестирование новых сборок ПП называется регрессивным тестиро- ванием. В ходе такого тестирования следует избегать избыточности тестов [9], поскольку ограниченность ресурсов, выделяемых под тестирование, является распространённой проблемой [10]. Удобнее всего проводить smoke-тестирование, сформировав список функций по техническому зада- нию. Оценка времени выполнения тестовых наборов важна для планиро- вания процесса тестирования и выбора приоритетных проверок [11]. Далее можно высчитать общее время первичного тестирования (T) по формуле: t f Т ⋅ = , где f – количество основных функций ПП; t – усреднённое время про- хождения тестовой проверки. Известия ТулГУ. Технические науки. 2019. Вып. 7 250 Усредненное время прохождения тестовой проверки можно высчи- тать по следующему алгоритму. Сформировать базовую группу тестов по одному тесту из каждого базового множества. Пример деления на множе- ства: инсталляционные тесты, тестирование меню, тестирование кнопок, тестирование отображения элементов и данных на основном фрейме. Из каждой такой группы берется по одному тесту и формируется базовое множество G. Время выполнения группы проверок G делится на количе- ство проверок. Таким образом получаем значение t При отсутствии технического задания предлагается вычислять об- щее время первичного тестирования с использованием метрики К - коли- чества объектов главной формы ПП, таких как кнопки, пункты меню, ос- новная табличная форма и так далее: t K T ⋅ + = ) 4 ( Величина в коэффициенте ) 4 ( + K есть сумма следующих парамет- ров: тестовая проверка инсталляции + тестовая проверка запуска про- граммного продукта + тестовая проверка выхода из приложения + тестовая проверка деинсталляции. Выбор способа тестирования программного продукта. Жизнен- ный цикл любого ПП условно можно разделить на четыре стадии: подго- товка, разработка, тестирование, внедрение и сопровождение; среди кото- рых тестирование и сопровождение являются наиболее затратными [12]. На этапе подготовки создается описание продукта, разрабатываются биз- нес-план, список учитываемых рисков, план разработки ПП и план прие- мо-сдаточных работ. Далее на этапе разработки создается исполняемая ар- хитектура приложения, то есть работающий ПП, в котором реализован ба- зовый набор функций. Третий этап – тестирование, которое проводится подразделением внутри компании-разработчика, сторонней организацией или с помощью краудсорсинга [13]. Для каждого нового ПП разрабатыва- ется тестовый план, в котором описываются подходы и методы тестирова- ния, затраты на проведение тестирования. Шаблон тест-плана подробно обсуждался в работе [14]. ПП может являться частью продуктовой линейки, то есть набора программных объектов, собранных вместе для решения определённых задач [15]. В таком случае проводится мероприятия по тестированию интеграции ПП, проверке корректности межпродуктовых взаимодействий, разрабатываются стратегии создания оптимального количества тестов [16, 17, 18]. Для дальнейшей оценки ре- зультатов тестирования удобно определять приоритетность тестовых наборов с помощью различных методов: базирующихся на метрике покры- тия кода, на оценке вероятности ошибок, на логике UML [19]. При любом подходе к оценке основными характеристиками хорошего теста являются эффективность, то есть способность обнаружить дефект; приемлемая сто- имость отладки, выполнения тестового примера и анализа полученных результатов; способность теста эволюционировать, то есть оценка усилий, которые потребуются для перенастройки теста при каждом изме- нении ПП [20]. Системный анализ, управление и обработка информации 251 На этапе внедрения создается окончательная версия ПП, инструк- ции по установке и настройке и вспомогательные материалы для конечных пользователей. При составлении тест-плана предлагается использовать ме- тод выбора между ручным, автоматизированным и смешанным тестирова- нием. В наши дни идёт развитие автоматизации, но ручные тесты не тоже активно используются. Автоматизация – это дорогостоящий и длительный процесс. В короткосрочной перспективе менее затратной является техника создания сценариев путём записи и последующего воспроизведения, так как для них требуется меньше времени и менее квалифицированные спе- циалисты. Сценарии, созданные методом программирования, более ресур- созатратны [21]. Они начинают окупаться приблизительно после третьего релиза. Однако, автоматизация позволяет освободить тестировщиков от выполнения большого количества однотипных тестов [22], больше вре- мени можно выделять на исследовательское тестирование [23, 24]. При составлении тест-плана предлагается использовать метод вы- бора между ручным, автоматизированным и смешанным тестированием, основанный на модели качества ПП, описанной в ISO 9126. В России о ха- рактеристиках качества программного обеспечения разработан ГОСТ Р ИСО/МЭК 9126-93. Модель качества состоит из шести критериев качества, каждый из которых включает ряд подхарактеристик (рис.2): 1. Функциональные возможности (критерии, которые характери- зуют наличие тех или иных функций в ПП, наличие у функций опреде- лённого набора свойств). 2. Надёжность (критерии, которые характеризуют способность ПП поддерживать заявленный уровень производительности в указанных усло- виях в течение определённого периода времени). 3. Практичность (критерии оценки усилий, необходимых для ис- пользования ПП; критерии формирования индивидуальных оценок за- явленной группой пользователей). 4. Эффективность (критерии, характеризующие взаимосвязь между уровнем производительности ПП и количеством используемых ресурсов). 5. Сопровождаемость (критерии, характеризующие затраты на про- ведение специфических модификаций программного продукта). 6. Мобильность (критерии, которые характеризуют способность ПП быть установленным в разном программном окружении, на разных опера- ционных системах). Для улучшения взаимодействия групп программистов и тести- ровщиков на этапе передачи ПП в тестирование предлагается ряд вопросов (критериев), ответы на которые должны поступать на тестирование вместе с передаваемым ПП. Эти ответы для ухода от большой работы в группе программистов должны быть краткими (в самом простом виде – «да/нет») и даваться ведущими специалистами этой группы, предпочтительно – ар- хитектором программного продукта (системным аналитиком). Они, путём диалога с программистами, могут уточняться после процедуры просмотра Известия ТулГУ. Технические науки. 2019. Вып. 7 252 списка спецификаций ведущими тестировщиками. На основе полученных ответов в группе тестирования принимается решение о ручном, автомати- зированном или смешанном виде тестирования ПП или его модулей (ча- стей). Рис . 2. Критерии качества программного обеспечения Группе программистов предлагается список из вопросов, осно- ванных на качественных свойствах ПП. Вопросы подробно обсуждаются в работе [25]. Из ответов «да» и «нет» формируется множество ) , , , ( 2 1 k β β β = β K . Значение i β , k i , , 2 , 1 K = есть единица или ноль. Тести- ровщики дают экспертные оценки ) , , , ( 2 1 k α α α = α K каждому ответу. Два типа экспертных оценок помогают принять наиболее эффективное ре- шение о выборе способа тестирования. Веса k α α α , , , 2 1 K рекомендуется назначать из множества [0, ¼, ½, ¾, 1]. В первой группе вопросов оценка единица есть удобство применения автоматизации тестирования; оценка ¾ - весьма удобно; оценка ½ - не очень удобно; оценка ¼ - удобство под большим сомнением; оценка ноль – совсем не удобно. Во второй группе вопросов в пользу удобства ручного тестирования назначается оценка ноль; оценка ¼ - весьма удобно; оценка ½ - не очень удобно; оценка ¾ - удобство под большим сомнением; оценка единица – совсем не удобно. Третья группа вопросов посвящена выбору смешанного подхода к тести- рованию. Принцип расстановки значений такой же, как для автоматизиро- ванного. Далее производится замена весов ноль и единица на ¼ и ¾ соот- ветственно. Таким образом получаем множество значений k k b b b , , , , , , 2 1 2 1 K K → β β β Для композиционного подхода заменяем k k a a a , , , , , 2 1 2 1 K K → α α α Системный анализ, управление и обработка информации 253 Нормирование по группе для весов первой части вопросов: 1 k a i i α = , для 1 , , 1 k i K = Для весов второй группы вопросов, направленной в пользу ручного тестирования: 2 ) 1 ( k a i i − α = , для 2 1 , , 1 k k i K + = Для третьей группы вопросов, ориентированной на смешанное тес- тирование: ) ( ) 2 1 ( 2 1 k k k a i i − − − α = , для k k i , , 1 2 K + = Далее вычисляется групповая свёртка k k b a b a b a P ⋅ + + ⋅ + ⋅ = K 2 2 1 1 Полученное значение Pнаходится в интервале от -1до 1 включи- тельно. Математическое ожидание данной свёртки равно нулю, следова- тельно, положительные значения Pговорят в пользу автоматизации тести- рования, отрицательные – в пользу ручного тестирования. Для большей обоснованности полученного результата границы отодвигаются от нуля. Выбраны значения Р 1 = 0.2и Р 2 = – 0.2. Если Р ≥ Р 1 , выдаётся рекоменда- ция об автоматизированном подходе к тестированию ПП. Если Р≤ Р 2 , вы- даётся рекомендация о ручном подходе к тестированию. Если Р 2 < Р < Р 1 , предлагается дополнительно привлечь экспертные оценки. Данная ме- тодика программно реализована (рис. 3). Рис . 3 Программная реализация методики Заключение. Как следует из представленного материала, задача повышения качества особо актуальна в современном мире. Общий объём выпуска ПП быстро растёт. Для заказчиков и конечных пользователей ПП встал вопрос выбора наиболее надёжных отечественных поставщиков, Известия ТулГУ. Технические науки. 2019. Вып. 7 254 способных создать в разумные сроки ПП высокого качества. Предложен- ная методика основана на межпрофессиональных взаимодействиях IT- специалистов, которые делают экспертные оценки качественных характе- ристик данного ПП. На основе полученных оценок с применением матема- тической свёртки выбирается наиболее эффективный для конкретного ПП подход к тестированию. Путём видоизменения ряда вопросов в опросном листе для программистов данный метод можно применять также для мо- бильных и веб-приложений. Список литературы 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 Thüm, 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 predic- tion: 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. Системный анализ, управление и обработка информации 255 13. Shikai Guo, Rong Chen, Hui Li, Jian Gao, Yaqing Liu. Crowdsourced Web Application Testing Under Real-Time Constraints. Interna- tional Journal of Software Engineering and Knowledge Engineering, 2018. Vol. 28. Issue 06. P. 751-779. 14. Галимова Е.Ю. Пример разработки тестового плана на базе шаблона RUP, VI Ежегодная международная научно-практическая конфе- ренция "Перспективы развития информационных технологий", 2011. C. 97- 103. 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 Compu- ting 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 Algo- rithm with Constraints Support. International Journal of Advanced Computer Science and Applications, 2019. Vol. 10. No. 1. P. 605-610. 17. Johansen M.F., Haugen Ø., Fleurey F. Properties Of Realistic Fea- ture Models Make Combinatorial Testing Of Product Lines Feasible // Model Driven Engineering Languages and Systems. 14 th International Conference, MODELS 2011 Wellington, New Zealand. Proceedings. Springer, 2011. P. 638- 652. 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 Mod- els // International Journal of Software Engineering and Knowledge Engineer- ing, 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 Pro- cesses in Software Engineering and Extreme Programming – Proceedings of 18 th 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. Известия ТулГУ. Технические науки. 2019. Вып. 7 256 ГалимоваЕкатеринаЮрьевна, ассистент, galim81@mail.ru,Россия, Санкт- Петербург,Санкт-Петербургский государственный университета промышленных технологий и дизайна METHODS OF SELECTION AN AUTOMATED, MANUAL AND SEMI-AUTOMATED 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 software product and taking into account the opinions and experience of developers and test- ers is proposed. Key words: software testing, manual testing, automated testing, software quality, se- lection method. GalimovaEkaterinaYuryevna, assistant, galim81@mail.ru, Russia, Saint- Petersburg, Saint-Petersburg State University of Industrial Technologies and Design УДК 674.815 ТЕРМОДИНАМИЧЕСКИЕ СВОЙСТВА ПРОПИТОЧНЫХ МЕЛАМИНОКАРБАМИДОФОРМАЛЬДЕГИДНЫХ ОЛИГОМЕРОВ М.Ю. Екимова В статье изложены исследования термодинамических свойств модифициро- ванных меламинокарбамидоформальдегидных олигомеров, полученных бесщелочным катализом. Определены зависимости термодинамических параметров меламинокар- бамидоформальдегидных олигомеров от количества меламина и количества эти- ленгликоля. Ключевые слова: меламинокарбамидоформальдегидные олигомеры, бесщелоч- ной катализ, модификатор-катализатор, термодинамические свойства. Пропитанные декоративные бумаги по объёму применения зани- мают первое место среди видов облицовки древесных плит. В качестве пропиточных составов используют меламиноформальдегидные. Меламиноформальдегидные олигомеры, используемые для пропит- ки бумаг, должны обладать хорошей пенетрационной способностью, кото- рая зависит от молекулярной массы и равномерности её распределения по поверхности бумаги при пропитки. Пропиточные олигомеры, применяе- мые для облицовывания в настоящее время, не всегда обладают данными качествами, что приводит к ухудшению качества готовой продукции. Раз- работанные меламинокарбамидоформальдегидные олигомеры, модифици- рованные солями полифункциональных кислот, обладают хорошей пене- трационной способностью в течении всего времени хранения [5]. |