Сообщений в теме: 6

[tutik]

Существуют ли теоретические метрики, позволяющие описать:
1. Преимущества автоматизации по сравнению с ручным тестированием;
2. Необходимость автоматизации того или иного модуля: коэффициенты сложности автоматизации определенных блоков - по набору уже существующих скриптов;
3. Результаты автоматизации vs ручного тестирования, используя БД логов и т.д.;
4. В общем все то, что позволить управлять процессом автоматизации.


Необходимы цифры и графики :)....


Буду благодарен любому ответу.

[Mike]

Попробую предложить.

t_dev_a = Время, необходимое для автоматизации cкрипта

t_exec_m = Время исполнения ручного скрипта

n_unattended = среднее количество прогронов автоматизированного скрипта до очередного изменения интерфейса (ведущего к необходимости частично или полностью переписывать скрипт)

t_refactoring_a = Время, необходимое для отладки скрипта после "среднестатистического" изменения интерфейса (включая время на необходимое документирование)

t_avg_testplanchange_m = Время, необходимое для изменения ручного скрипта после "среднестатистического" изменения спецификации

k_regression = Число прогонов теста без изменения поведения системы к общему количеству прогонов (cчитаем, что изменения затронут как ручные, так и автоматические тесты)

Пусть N_total - полное количество прогонов скрипта (ручного или автоматизированного) за определённый (достаточно большой), планируемое на всё время разработки/поддержки системы.


T_manual_total = N_total*(t_exec_m) + N_total*k_regression * t_avg_testplanchange_m

T_automated_total = t_dev_a + N_total*k_regression * t_refactoring_a

Тогда критерий того, что скрипт стОит автоматизировать - T_automated_total<T_manual_total

Допущения:
- Время исполнения автоматического скрипта не учитывается, если оно >~ T_exec_m*10, надо менять формулу
- N_total достаточно большое, по-крайней мере, >~10 иначе критерии не годятся
- Временем, необходимым на запуск автоматизированного скрипта принебрегаем
- Время, необходимое на обработку результатов автоматизированного теста равно времени на обработку результатов ручного прогона
- Автоматизируем уже готовый ручной скрипт
- качество ручного и автоматизированного тестирования одинаковое и не зависит от времени (неправда почти всегда ;) )

[Mike]

Да, понятное время, все вопросы о стоимости тестирования не учитвыаются также. (То есть, тул он тоже денег стоит, зарплата тестеров отличается, при автоматизации могут понадобиться дополнительные машины, их надо администриролвать,...)

[tutik]

Немного измененная структура:
1. Заюзал n_unattended и с его помощью высчитал k_regression: 1-1/n_unattended, соответственно k_regression - процент выполненных тесткейсов без изменений;
2. Добавил t_exec_a (среднее время выполнения скрипта), чтобы учесть преимущества запуска скриптов в параллельном режиме (если скрипт позволяет) и соответственно учесть недостатки если автоматом дольше;
3. Получилось:
T_manual_total = N_total*(t_exec_m) + N_total*(1 - k_regression)* t_avg_testplanchange_m
T_automated_total = t_dev_a + N_total*(t_exec_a/t_exec_m)(1 - k_regression) * t_refactoring_a

Картинка в общем получилась неплохой практически для всех скриптов:)

[Mike]

Не понял, зачем в формуле для T_automated_total нужно (t_exec_a/t_exec_m) - что это соотнощение выражает? Ведь t_exec_m - время выполнения ручного скрипта, и непонятно, каким боком оно используется при вычислении времени, необходимого на автоматизацию? Что касается t_exec_a, то я его не стал включать по понятным причинам - так как скрипты обычно гоняются ночью (либо на машине без монитора днём). В общем, как мне представляется, надо учитывать только время, необходимое на запуск скриптов и время, необходимое на анализ результатов (включая время, необходимое на воспроизведение потенциальных багов (то есть ошибок выполнения скрипта)).

[astik]

Grubyi nabrosok,zatraty na avtomatizaziju okupajutsja esli testiruemoe prilozhenie progonjaetsja bolee 5-7 raz v god. Eto tak toporom, nu a esli na kalkuljatore, to sm. vyshe ;)

[tutik]

1. (t_exec_a/t_exec_m) - это своеобразный коэффициент, который соответственно должен учитывать разницу во времени выполнения тесткейса, н-р: человек покрывает тесткейс за 5 рабочих дней (40 часов), тот же скрипт в последовательном режиме отработает за 24-28 часа, в параллельном за 6-8, отсюда выходит еще один плюс к автоматизации, который желательно учесть. И наоборот если человек проходит кейс за 1 час, а скрипт за 3 часа, то это уже идет в "минус".

Конечно, это уже не будет "T_automated_total" в этом понимании слова, это уже скорректированное время. Возможно, будет тогда правильнее написать:
N_automated = T_automated*(t_exec_a/t_exec_m), хотя причем тогда здесь t_dev_a???

При этом можно вводить дополнительные поправочные коэффициенты, чтобы учесть другие факторы (в том числе и занятость ресурсов: виртуальные машины, сервера или workstation'ы)

Почему для меня это время вообще важно: поскольку человек не может покрывать большие (foundation) testcases на каждом билде на каждой конфигурации, при этом возможна потеря функциональности, в тоже время скрипты работают по 24 часа в сутки на разных машинах, покрывая КАЖДЫЙ билд и любую конфигурацию. Это, можно сказать, один из главных козырей автоматизации.:)