CC BY
19Оптимизация временных затрат тестирования программного продукта с применением технологии Git
Иванников Дмитрий Владимирович
студент 1 курса аспирантуры кафедры УИТС ФГБОУ ВО МГТУ «СТАНКИН» г. Москва, Россия, ivannikov.dmitry.v@gmail.com Копий Анна Александровна
студентка 2 курса магистратуры кафедры УИТС ФГБОУ ВО МГТУ «СТАНКИН» г. Москва, Россия, ncopiy@ya.ru
АННОТАЦИЯ_
Введение: Целью настоящей работы является уменьшение времени жизни недостатка программы с помощью автоматизированного тестирования. Тестирование является неотъемлемой частью разработки программного продукта. Сам процесс тестирования состоит не только из поиска дефектов в разрабатываемой системе, но также из их учета. Учет ошибок — это процесс фиксации этапов жизненного цикла дефекта от возникновения до полной его ликвидации. Данный процесс хорошо поддается формализации и автоматизации. Авторами данной работы предлагается декомпозировать процесс учета ошибок на отдельные его составляющие. Декомпозиция процесса учета ошибок показывает, что от финального решения о выборе ответственного за недостаток в системе зависит скорость исправления найденной ошибки. Выбор ответственного является исключительно важной стадией исправления дефекта в системе, поскольку исправление ошибки является единственной частью в жизненном цикле найденного дефекта, которая не поддается автоматизации. Следовательно, некорректный выбор ответственного может сильно увеличивать время исправления ошибки. Для решения данной проблемы предлагается использовать технологии системы контроля версий Git. Данная система была создана для отслеживания и фиксации изменений в процессе разработки программного обеспечения. В настоящей работе предлагается выявлять авторов дефектного кода с помощью функционала системы Git и использовать эту информацию для более таргетированного выбора ответственного за существующий недостаток в программе. В совокупности с автоматизированными тестами данное решение приносит увеличение скорости исправления недостатка в системе, что позитивно сказывается как на качестве продукта, так и на скорости разработки.
КЛЮЧЕВЫЕ СЛОВА: построение процесса тестирования; разработка программного продукта; системы контроля версий; тестирование программного продукта; git.
Введение
Назначение тестирования - это в первую очередь поиск ошибок [1]. Ошибки - это не соответствие ожидаемому поведению программы. Отсюда следует вывод, что перед разработкой любого программного продукта необходимо документально зафиксировать его ожидаемое поведение. Такие документы принято называть постановкой программного обеспечения [2]. Данные документы является ключевыми для отдела тестирования, так как на их основе создаются тест-кейсы - списки действий, каждое из которых проверяет определенную часть спецификации проекта [3].
Таким образом, компания обеспечивает полный цикл разработки программного продукта, включающий в себя: определение потребностей пользователей, постановка задачи, разработка функционала, тестирование, исправление ошибок, предоставление конечным пользователям нового функционала [4]. Перечисленные этапы имеют циклический характер, поскольку разработка программного продукта ведется итеративно. Этап тестирования заключается не только в поиске ошибок, но и в дополнении существующих тест-кейсов, тесном взаимодействии с управляющим проекта и командой разработчиков и, что самое важное, учете ошибок. Учёт ошибок - это довольно ресурсоемкий процесс, который в среднем может отнимать до половины всего времени выделенному отделу на одну итерацию тестирования [5].
Целью настоящей работы является разработка программного решения для уменьшения необходимого времени на учет ошибок.
Организация базового процесса тестирования программного продукта
Зачастую малые компании обходятся без отдела тестирования [6]. Действительно, на первых итерациях разработки, реализация минимального жизнеспособного продукта требует небольшого количества тест-кейсов [7]. Необходимое время на их проверку также невелико, что позволяет разработчикам самостоятельно проверять функционал приложения. Однако это становится экономически неэффективным в случае, если время, необходимое на тестирование, занимает полноценный рабочий день разработчика. В таком случае отдел разработки дополняют отделом тестирования, обеспечивая тем самым более качественную проверку конечного продукта [8].
Следующим этапом развития тестирования в рамках компании является автоматизация тестирования, которая освобождает отдел тестирования от ручного прохода тест-кейсов в пользу использования автоматических инструментов тестирования [9].
Автоматизированное тестирование
Автоматизированное тестирование позволяет анализировать корректность работы программного кода и сообщать об ошибках в случае их возникновения. Любое несоответствие ожидаемому поведению программы расценивается как некорректное.
Критической ошибкой считается выход системы из строя [10]. Как правило, такие ошибки обуславливаются возникновением необработанных исключительных ситуаций в исходном коде программы [11].
Во время прохождения автоматических тестов подобные ошибки сохраняются в виде отчетов, а отчеты передаются отделу разработки для исправления функционала ПО.
Данный процесс является довольно ресурсоемким, поскольку предполагает проведение анализа ошибок с последующим составлением отчета о причинах возникновения дефекта и описанием последовательности действий для его воспроизведения [12, 13]. Отчет об ошибке направляется к одному из разработчиков ПО для последующего анализа и исправления дефекта. Процесс формирования отчета ложится на плечи тестировщика и, как следствие, времени на написание новых тест-кейсов и их автоматизацию становится меньше.
Анализ временных затрат при проведении процесса тестирования
Ранее описанный жизненный цикл ошибок в программном продукте позволяет сказать, что время, необходимое на обработку ошибки от момента ее возникновения до момента полного устранения недостатка вычисляется по формуле:
Tdlt = N * (Tatr + Trp + Tdpp)
где:
• Tdlt - время жизни дефекта в ПО
• N - количество итераций, требуемых для полного устранения недостатка
• Tatr - время выполнения автоматических тестов
• Trp - время подготовки отчета об ошибке
• Tdpp - время анализа программистом причин возникновения недостатка, выявления методов его исправления, а также время на исправление
Данные метрики можно разделить на две группы: поддающиеся автоматизации и не поддающиеся автоматизации.
К первой группе относятся следующие метрики: Tatr, поскольку является изначально автоматизированным процессом; Trp, поскольку возможно реализовать систему автоматического учета ошибок с составлением отчетов [14].
Вторая же группа включает в себя как минимум один параметр, предполагающий непосредственное участие человека: Tdpp. Данное время зависит не только от компетенций исполнителя, но и от уровня вовлеченности в настоящий проект [15]. В случае если разработчик был ранее не знаком с работой модуля, где обнаружился недостаток, это время будет больше, чем время, необходимое более вовлеченному разработчику. Следовательно, уменьшение этого времени может быть достигнуто в двух случаях:
1. При увеличении уровня вовлеченности разработчиков во все модули разрабатываемой системы,
2. При более таргетированном выборе ответственного за ошибку.
3.
Средство учёта ошибок с применением технологии Git
Критические ошибки зачастую сопровождаются отладочной информацией - трассировкой стека (stack trace), которая представляет собой последовательный набор активных кадров стека в момент возникновения исключительной ситуации и совокупной информацией о возникшей проблеме (рис. 1) [16].
Traceback (most recent call last) :
File 1 'main.py", line 8, in <mQdule>
calculate^, 7)
calculate = <function calculate at 0x7fccl867clfS>
e - ZeroDivisionError('division bv zero')
File 1 '/honie/a/Worksoace/oaaer/f ile2. i ._", line 7, in calculate
res. .append(division(i, n - i))
i
n -
res - [0.0, B.16666666666666666, 0. Л, 0.75, 1.3333333333333333, 2.5, 6.B]
rng = IS
File 1 14, line 2, in division
return x / у
x -
V = В
ZeroDivisionError: division by zero
Рис. 1. Stack trace исключительной ситуации в программе на языке программирования Python
Во время работы над ошибкой, разработчик анализирует трассировку и локализирует место возникновения исключительной ситуации для последующего ее исправления. Как уже
было сказано ранее, время на исправление дефекта может вырасти в случае, если разработчик не сталкивался ранее с данным участком кода и нуждается в дополнительном времени на исследование исходного кода ПО. Однако по необработанной трассировке кода невозможно понять, кто является автором того кода, который спровоцировал возникновение ошибки.
Каждый стековый кадр трассировки, можно отнести либо к программному участку исполняемой программы, либо к вызову компонент внешних зависимостей [17]. Для стековых кадров исполняемой программы можно выявить дополнительную информацию о текущем участке кода с помощью инструментов системы контроля версий Git.
Система контроля версий Git изначально предназначена для последовательной фиксации изменений в коде в рамках разработки ПО [18]. Каждое выделенное изменение обладает рядом характеристик [19]:
• дата изменения
• автор изменения (имя, email)
• shal ревизии
• комментарий автора
Данные характеристики можно включить в перечень локальных аргументов в стековом кадре (рис. 2).
Traceback Cmost recent call last): File "main.py", line 9, in <module> calculateilS, 7)
calculate = <function calculate at Sx7f19el7ef28Q> e = ZeroDivisionErrort'division by zero') File "/home/a/'i4orkspace/paper/file2. py". line 7, in calculate res.append(division(i, г - i)) blame = ■{
'пате': 'First Programmer1, "message1: "Fix division',
1commit_with_branch_or_first_tag' : 10.1.5 ', ■date': '2020-05-07102:17:07+03:00'
>
i = 7 n = 7
res = [0.0, 0.Ii6666666i66i6666, 0.4, 0.75, 1.3333333333333333, 2.5, 6.0] rng = 10
File "/home/a/'i'lorkspace/paper/filel. py". line 2, in division return x / у blame = ■{
'пате': 'Second Programmer', "message1: 'Add calculate method', 'commit_with_branch_or_first_tag': '0.1.Э', 'date': '2020-04-08T22:14:12+03:001
>
X = 7 V = 0
ZeroDivisionError: division by zero
Рис. 2. Расширенный stack trace исключительной ситуации в программе на языке программирования Python.
Анализ временных затрат при проведении тестирования с применением разработанной методики
Предложенное решение позволяет при возникновении исключительной ситуации раскрыть отделу тестирования информацию об авторах кода в кадрах трассировки, что позволяет адресовать отчеты об ошибках более таргетированно. Как следствие, уменьшается единственное не поддающееся автоматизации время - Tdpp.
Автоматическое назначение автора дефектного кода ответственным за его исправление можно организовать и в случае использования автоматизированных агрегаторов ошибок.
Концепция более таргетированного выбора ответственного может быть использована и для увеличения уровня вовлеченности разработчиков во все модули разрабатываемой системы. Для обеспечения роста уровня вовлеченности можно назначать ответственным любого разработчика, кроме автора текущего кода. Разработчики ранее не знакомые с данным участком кода будут изучать его работу в процессе исправления ошибки. Таким образом, их представление о внутренних процессах данного ПО будет расти, а время, необходимое на исправление недостатка, в будущем будет уменьшаться.
Показателем успешного внедрения данного решения является отсутствие трассировок, для которых можно было бы найти разработчика, который не являлся бы автором кода в кадрах трассировке. В таком случае, любому из разработчиков не требуется время на изучение логики кода с дефектом.
Заключение
Предложенное решение может быть использовано для уменьшения времени, необходимого на анализ программистом причин возникновения недостатка в системе, выявление методов его исправления и исправление недостатка системы. При этом настоящее решение может быть применено как для практики назначения ответственным за недостаток в коде автора этого кода, так и для увеличения уровня вовлеченности разработчиков в проект.
Актуальность внедрения решения обуславливается тем, что оно позволяет уменьшить время единственного этапа жизненного цикла критической ошибки в системе, которое зависит непосредственно от человека.
Литература
1. Khan M. E. Different forms of software testing techniques for finding errors //International Journal of Computer Science Issues (IJCSI). 2010. Т. 7. №. 3. С. 24.
2. Jebreen I., Wellington R. Understanding requirements engineering practices for packaged software implementation //2013 IEEE 4th International Conference on Software Engineering and Service Science. IEEE, 2013. С. 229-234.
3. Rothermel G. et al. Test case prioritization: An empirical study //Proceedings IEEE International Conference on Software Maintenance-1999 (ICSM'99).'Software Maintenance for Business Change'(Cat. No. 99CB36360). IEEE, 1999. С. 179-188.
4. Alting L. Life cycle engineering and design //Cirp Annals. 1995. Т. 44. №. 2. С. 569-580.
5. Fiaz A. S., Devi N., Aarthi S. Bug Tracking and Reporting System //arXiv preprint arXiv:1309.1232. 2013.
6. Karlstrom D., Runeson P., Norden S. A minimal test practice framework for emerging software o r-ganizations //Software Testing, Verification and Reliability. 2005. Т. 15. №. 3. С. 145-166.
7. Racolta-Paina N. D., Andries A. M. Identifying entrepreneurship readiness for the application of the Lean Startup practices in the service industry-Case study Romania //Ecoforum Journal. 2017. Т. 6. №. 3.
8. Ramler R., Wolfmaier K. Economic perspectives in test automation: balancing automated and manual testing with opportunity cost //Proceedings of the 2006 international workshop on Automation of software test. 2006. С. 85-91.
9. Leitner A. et al. Reconciling manual and automated testing: The autotest experience //2007 40th Annual Hawaii International Conference on System Sciences (HICSS'07). IEEE, 2007. С. 261a-261a.
10. Qing-Biao L. I. U. et al. System and method for rapidly diagnosing bugs of system software : заяв. пат. 11943985 США. 2009.
11. Cristian F. Exception handling and software fault tolerance //Reliable Computer Systems. Springer, Berlin, Heidelberg, 1985. С. 154-172.
12. Hooimeijer P., Weimer W. Modeling bug report quality //Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering. 2007. С. 34-43.
13. McKeeman W. M. Differential testing for software //Digital Technical Journal. 1998. Т. 10. №. 1. С. 100-107.
14. Lenarduzzi V. et al. Prioritizing corrective maintenance activities for android applications: An industrial case study on android crash reports //International Conference on Software Quality. Springer, Cham, 2018. С. 133-143.
15. Gregory A. et al. Effects of a professional development program on behavioral engagement of students in middle and high school //Psychology in the Schools. 2014. Т. 51. №. 2. С. 143-163.
16. Schroter A. et al. Do stack traces help developers fix bugs? //2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). IEEE, 2010. С. 118-121.
17. Lee G. L. et al. Benchmarking the Stack Trace Analysis Tool for BlueGene/L //PARCO. 2007. С. 621-628.
18. Chacon S., Straub B. Pro git. Apress, 2014.
19. Fry T. et al. A Dataset and an Approach for Identity Resolution of 38 Million Author IDs extracted from 2B Git Commits //arXiv preprint arXiv:2003.08349. 2020.
SOFTWARE PRODUCT TESTING TIME OPTIMIZATION WITH GIT TECHNOLOGY USAGE
Dmitry V. Ivannikov
Moscow, Russia, ivannikov.dmitry.v@gmail.com Anna A. Copiy
Moscow, Russia, ncopiy@ya.ru
ABSTRACT
Introduction: The purpose of this scientific work is to reduce the lifetime of a program defect by using automated testing. Testing is an integral part of software product development. The testing process itself consists not only of the search for defects in the developed system, but also of their tracking. Error tracking is the process of recording the stages of a defect's life cycle from occurrence to its complete elimination. This process can be formalized and automated well. The authors of this paper suggest decomposing the error tracking process into its individual components. The decomposition of the error tracking process shows that the errors liquidation speed depends on the final decision on the choice of the person responsible for the shortcomings in the system. The choice of the person responsible is an extremely important stage in correcting a defect in the system, because error correction is the only part in the defect life cycle that cannot be automated. Therefore, the incorrect choice of the responsible person can greatly increase the time of correction of the error. To solve this problem, it is proposed to use the technology of the Git version control system. This system was created to track and record changes in the software development process. This paper proposes to identify the authors of the defective code using the functionality of the Git system and use this information for a more targeted selection of the person responsible for the existing defect in the program. Together with automated tests, this solution brings an increase in the defect liquidation speed, which positively affects both the quality of the product and the speed of development.
Keywords: building a testing process; software product development; version control systems; software product testing; git.
REFERENCES
1. Khan M. E. Different forms of software testing techniques for finding errors.International Journal of Computer Science Issues (IJCSI). 2010. T. 7. №. 3. 24 p.
2. Jebreen I., Wellington R. Understanding requirements engineering practices for packaged software implementation. 2013 IEEE 4th International Conference on Software Engineering and Service Science. IEEE, 2013. Pp. 229-234.
3. Rothermel G. et al. Test case prioritization: An empirical study. Proceedings IEEE International Conference on Software Maintenance-1999 (ICSM'99).'Software Maintenance for Business Change'(Cat. No. 99CB36360). IEEE, 1999. Pp. 179-188.
4. Alting L. Life cycle engineering and design. Cirp Annals. 1995. T. 44. №. 2. Pp. 569-580.
5. Fiaz A. S., Devi N., Aarthi S. Bug Tracking and Reporting System. arXiv preprint arXiv:1309.1232. 2013.
6. Karlstrom D., Runeson P., Nordén S. A minimal test practice framework for emerging software organizations. Software Testing, Verification and Reliability. 2005. T. 15. №. 3. Pp. 145-166.
7. Racolta-Paina N. D., Andries A. M. Identifying entrepreneurship readiness for the application of the Lean Startup practices in the service industry-Case study Romania. Ecoforum Journal. 2017. T. 6. №. 3.
8. Ramler R., Wolfmaier K. Economic perspectives in test automation: balancing automated and manual testing with opportunity cost. Proceedings of the 2006 international workshop on Automation of software test. 2006. Pp. 85-91.
9. Leitner A. et al. Reconciling manual and automated testing: The autotest experience. 2007 40th Annual Hawaii International Conference on System Sciences (HICSS'07). IEEE, 2007. Pp. 261a-261a.
10. Qing-Biao L. I. U. et al. System and method for rapidly diagnosing bugs of system software : 11943985 USA. 2009.
11. Cristian F. Exception handling and software fault tolerance. Reliable Computer Systems. Springer, Berlin, Heidelberg, 1985. Pp. 154-172.
12. Hooimeijer P., Weimer W. Modeling bug report quality. Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering. 2007. Pp. 34-43.
13. McKeeman W. M. Differential testing for software. Digital Technical Journal. 1998. T. 10. №. 1. Pp. 100-107.
14. Lenarduzzi V. et al. Prioritizing corrective maintenance activities for android applications: An industrial case study on android crash reports. International Conference on Software Quality. Springer, Cham, 2018. Pp. 133-143.
15. Gregory A. et al. Effects of a professional development program on behavioral engagement of students in middle and high school. Psychology in the Schools. 2014. T. 51. №. 2. Pp. 143-163.
16. Schroter A. et al. Do stack traces help developers fix bugs? 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). IEEE, 2010. Pp. 118-121.
17. Lee G. L. et al. Benchmarking the Stack Trace Analysis Tool for BlueGene/L . PARCO. 2007. Pp. 621-628.
18. Chacon S., Straub B. Pro git. Apress, 2014.
19. Fry T. et al. A Dataset and an Approach for Identity Resolution of 38 Million Author IDs extracted from 2B Git Commits. arXiv preprint arXiv:2003.08349. 2020.
