Оптимизация процесса тестирования по С с использованием эвристического анализа тестового покрытия кода (1187409), страница 6
Текст из файла (страница 6)
Итогополучим примерно 1915 запусков. Заметим, что тестирование происходитв рабочее время, а также то, что каждый третий коммит посвященисправлению ошибок предыдущего коммита. Команда располагает 4серверами для параллельного запуска тестов. Учтем, что работапроизводится по системе TDD, описанной ранее, что уменьшаетвероятность внесения изменений в ранее протестированные и слитыечасти проекта.Как указывалось ранее, мы не можем просто аппроксимировать временаработы ci-задач, так как система изменялась.
Поэтому рассчитаемфункциональную зависимость времени работы тестов от объема кода. Дляязыка python хорошей практикой для написания тестов являетсяиспользование setUp и tearDown методов, которые ответственны засоздание и уничтожение тестового окружения. Для каждого тестазапускается соответствующая ему пара.
Однако, несмотря на это,статистически время работы тестов растет линейно - а именно по 4секунды на коммит. Подсчитаем общее потраченное на тестированиевремя:1915844844∫4 x = 3232520 секунд≃897 часов0Итого, имеем следующие данные для оценки исследуемого алгоритмаоптимизации:ВероятностьОбщее времяЧасов в день наЭффективные41ошибкитестированиятестированиекоммиты36%897 часов3.156 из 98.3 Применение оптимизацииТеперь рассмотрим тот же проект, но с учетом оптимизации. Ограничимвремя работы тестов 20 минутами. Подобное ограничение достигается засчет большого количества тестов, покрывающих от 45% кода. Более того,в ходе исследования выяснилось, что количество тестов, покрывающихменее 40% кода, пренебрежимо мало.
Пока общее время работы тестов невыходит за рамки ограничения, очевидно, никаких отличий не будет.Далее будем запускать только оптимальные тесты в рабочее время, анакопившиеся коммиты - ночью. Запуская меньше тестов, мы повышаемрискупуститьошибку,однако повышаем количество “целевых”изменений кода, не связанных с исправлением ошибок.
Освободившеесявремя позволяет команде внести 12 коммитов. Вероятность проваланочного теста близка к 100%. Однако в этом случае все ошибки могутбыть исправлены одним коммитом.428.4 РезультатыВероятностьошибкиОбщее времятестированияЧасов в день натестированиеЭффективныекоммиты52%282 часа1 час10-11 из 12На рисунках выше показаны последовательно затраты на тестирование иколичество эффективных коммитов в зависимости от времени приодинаковыхусловияхразработки.Краснымцветомобозначеназависимость для неоптимального, а зеленым - для оптимального случая.Как видно из исследования, эффективность работы команды вырослапочти в два раза, а нагрузка на тестовые сервера упала в 4.
Однако данный43случай не является критическим - ci все еще работает, а тесты проходят заадекватное время. В случае, если проблемы с длительностью тестовогоцикла куда более значимы, выгода от использования возрастает. Однако,если цикл тестирования занимает больше одной ночи, необходимоизменение рабочего процесса команды и синхронизация его с цикломполного тестирования. В такой ситуации эффект от восстановленияпроцесса непрерывной интеграции будет первостепенно важным.449. ВыводРезультатом этого исследования является алгоритм, а также наработки поего непосредственной реализации, способный серьезно упростить иускорить процесс разработки программного обеспечения, а такжевосстановить процесс непрерывной интеграции для объемных проектов.На примере существующего репозитория, для которого рассмотренныепроблемы были актуальны, показаны преимущества использованияразработанного метода тестирования по сравнению с классическойсхемой.
Произведена оценка эффективности и связанных с применениемметода рисков. Были выявлены недостатки первоначальной идеи,определены ограничения применения выработанного решения. Однако,наиболее важным результатом работы можно считать то, что в очереднойраз было подтверждено, что идеального со всех сторон решения проблемыне существует.
Невозможно, в конечном итоге, получить качественныйпродукт, если в ходе разработки приоритизировать решение одних важныхпроблем над другими.4510. Список литературы1. Ron Patton. Software Testing2. Гленфорд Майерс, Том Баджетт, Кори Сандлер. Искусствотестирования программ, 3-е издание3. Бейзер Б. Тестирование чёрного ящика. Технологиифункционального тестирования программного обеспечения и систем4. McConnell, Steve. Code Complete (2nd ed.)5.
Dustin, Elfriede. Effective Software Testing6. Kolawa, Adam; Huizinga, Dorota. Automated Defect Prevention: BestPractices in Software Management7. Kaner, Cem. "Exploratory Testing"8. Bach, James. "Risk and Requirements-Based Testing"9. Bullseye Testing Technology. "Intermediate Coverage Goals"10.Python Documentation11.Xie, Tao. "Towards a Framework for Differential Unit Testing ofObject-Oriented Programs"12.Robert Mecklenburg. Managing projects with gnu make third edition13.Hayhurst, Kelly; Veerhusen, Dan; Chilenski, John; Rierson, Leanna. "APractical Tutorial on Modified Condition/ Decision Coverage"14.Fowler, Martin.
"Continuous Integration"15.Using the GNU Compiler Collection16.https://www.froglogic.com/coco/17.https://www.gnu.org/software/diffutils/18.https://jenkins.io/19.http://git-scm.com20.ГОСТ Р ИСО/МЭК 25010-201521.https://www.tiobe.com/tiobe-index/4622.Kellerer, Hans, Pferschy, Ulrich, Pisinger, David; Knapsack Problems47.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
