Непрерывная регрессия

Стандартный

Захотелось поговорить о регрессионном тестировании. Как к этому делу подходить. Вначале о том, что же с моей точки зрения представляет собой регрессионное тестирование (РТ). РТ — это тестирование, направленное на проверку того, что объект тестирования со временем не регрессирует по какому-то показателю качества. Т.е. в общем случае к РТ может относиться любой вид тестирования (функциональное, производительности, юзабилити и пр.). Но чаще всего речь идет о регрессионном функциональном тестировании, т.к. функциональность — наиболее важный показатель. Как следует из определения РТ, это некий набор тестов, который выполняется с некоторой периодичностью. И тут возникают следующие вопросы:

  1. Как часто надо выполнять данные тесты?
  2. Какие именно тесты необходимо включить в набор РТ?

Собственно, на эти вопросы я и постараюсь ответить. В общем-то, они возникают по одной простой причине — не хватает времени. Т.е. при большом желании и наличии времени, можно было бы на каждой версии выполнять все тесты. Но, во-первых, это долго, нудно и неинтересно, а во-вторых, не эффективно, это время можно потратить с большей пользой :) По поводу первого вопроса, в книге С. Канера «Тестирование ПО» дается один дельный совет: выполнять тесты не на каждой версии, а каждые несколько версий. Это заметно снизит нагрузку на тестирование. Т.к. совет хороший, предлагаю им воспользоваться :) Остается второй вопрос. Даже выполняя тесты с периодом больше одной версии, все их выполнять скорее всего не получится. По этому желательно уменьшить их количество до приемлимого. Но тут есть опасность того, что выбранный набор окажется недостаточным, и будут пропущены дефекты. Можно выполнять тесты, с наивысшим приоритетом, но тогда есть вероятность, что до наименее приоритетных тестов дело вообще не дойдет. Используя совет С. Канера, я решил проблему РТ следующим образом.

  1. Разные тесты имеют разный приоритет, но выполнять нужно их все. Период выполнения (в количестве версий) для таких тестов может различаться. Для одних он составит 2-5 версий, для других — 10-20. Период можно подбирать для каждого теста индивидуально.
  2. Таким образом, тесты получили новый атрибут — период выполнения. Я его называю просто «регрессия». Это число, равное количеству версий, через которое нужно повторить тест. Другими словами, это некий интервал доверия теста. Если «регрессия» теста равна 5, то это означает, что после выполнения, результату теста можно будет доверять еще на протяжении 5 версий.
  3. После истечения «интервала доверия», результат теста считается невалидным. И выполнение теста нужно повторить.

Такая система дает возможность выполнять все тесты (с различными приоритетами), но с разным интервалом. Рассмотрим такой пример. У нас имеется 100 тестов. По значению «регресси» тесты разделены на следующие группы:

  • 25 тестов со значением «регрессия» = 5.
  • 30 тестов со значением «регрессия» = 10.
  • 30 тестов со значением «регрессия» = 20.
  • 15 тестов со значением «регрессия» = 50 (возможно, они будут выполнены только один раз за весь проект, сюда можно отнести тесты из разряда «исследовательских»).

До этого момента тесты не выполнялись. Допустим, время, необходимое на выполнение у всех тестов одинаковое, версии выходят у нас с равным интервалом и за этот интервал может выполняться 15 тестов. Теперь вышла версия 1.0. Начинается выполнение тестов. Получаем такую картину:

  • Версия 1.0. Выполнены 15 тестов из группы «5».
  • Версия 1.1. Еще выполнено 10 тестов из группы «5» и 5 тестов из группы «10».
  • Версия 1.2. Выполнено еще 15 тестов из группы «10».
  • Версия 1.3. Выполнено 10 тестов из группы «10» и 5 тестов из группы «20».
  • Версия 1.4. Выполнено 15 тестов из группы «20».
  • Версия 1.5. Выполнено 10 тестов из группы «20» и 5 тестов из группы «50».
  • Версия 1.6. Тесты, из группы «5» стали невалидными. Результатам этих тестов теперь нельзя доверять. Их выполнение начинается сначала (т.к. это более приоритетные тесты). Выполнено 15 тестов из группы «5».
  • Версия 1.7. Выполнены оставшиеся 10 тестов из группы «5» и 5 тестов из группы «50», т.к. остальные тесты пока еще находятся в своих «интервалах доверия».
  • Версия 1.8. Выполнены оставшиеся 5 тестов из группы «50». На данном этапе результаты всех выполненных тестов еще валидны. Освободившееся время можно потратить по своему усмотрению: можно продолжить выполнение тестов с наиболее «старых», можно заняться «свободным» тестированием, настройкой стендов и т.д.

Пример, конечно, примитивный, но суть идеи отражать должен. Из него видно, что с версии 1.6 началось регрессионное тестирование, которое оказывается «размазано» по версиям. Получается непрерывный процесс и в то же время уникальный набор тестов относительно версии. С одной стороны, это позволяет внести разнообразие в работу тестировщика, а с другой периодически проверять все аспекты работы программы. Со временем, можно подобрать желаемые значения «регрессии» для всех тестов. Например, для тех тестов, которые уже давно выполняются с положительным результатом, значение можно увеличить. Для тех, которые продолжают выявлять ошибки интервал можно уменьшить. Появляется четкий и понятный инструмент регулирования нагрузки на тестирование.

Кроме того, появляется еще один «бонус». Для каждой версии можно узнать количество тестов, которое необходимо выполнить, чтобы все тесты на ней стали валидными. Зная трудоемкость каждого теста, можно вычислить общие трудозатраты, на получение протестированной версии. Что дает возможность более четко прогнозировать выпуск версии.

К описанной схеме, естественно, не относятся тесты тех частей, которые изменялись/правились/добавлялись в последней версии. Они выполняются в первую очередь. Для остальных же тестов эта схема вполне себя оправдывает.

Реклама

Непрерывная регрессия: 5 комментариев

  1. Идея интересная, мне понравилось. Реально можно получить инструмент для регулировки объема выполняемых за итерацию (цикл) тестов.
    Если я тебя правильно поняла, схема примерно следующая: разрабатываем тесты — расставляем значения «регрессии» — тестируем (в цикле).
    Отсюда возникают вопросы:
    — как в эту схему вписывается разработка новых тестов? Последний абзац)) Мне кажется, над этим стоит подумать, ибо если в какой-то момент начнется массовая переработка всех тестов, то схема полетит к чертям и мы вернемся к тому, с чего начали — времени на тестирование не хватает катастрофически.
    — как документировать? Я понимаю, что это не слишком сложно, но вопрос требует ответа. Нужно документировать так, чтобы в любой момент времени, глянув в «док», можно было бы сказать, во-первых, что сейчас тестировать, во-вторых, какие тесты еще актуальны, а какие уже нет. Как-то так.

    Это даже не вопросы, это что-то типа пожелания. Мне нравится идея регулирования количества выполняемых тестов. Развивай!

  2. Хорошие вопросы. Попробую на них ответить).
    1.1 Добавляя новые тесты, во-первых, их можно сразу выполнять и документировать результаты, во-вторых, изначально выставлять маленькое значение «регрессии». Можно даже сделать ее равной 1. А через некоторое время увеличить.
    1.2 По поводу «если в какой-то момент начнется массовая переработка всех тестов, то схема полетит к чертям». Смотря с чем связана эта переработка. Если с тем, что функционал «массово» изменился, то тут уж ничего не поделаешь. Раз все менялось, тестировать надо все. Но и тут схема может помочь, выставляя значение «регрессии», желательно учитывать приоритет тестов. В этом случае в первую очередь будут выполнены наиболее приоритетные тесты. Если перерабатывается просто формат тестов, то тут ничего страшного не случится, т.к. суть тестов не изменится.
    2. С документацией дейститвельно надо было бы привести пример. Я эту проблему у себя решил. Список тестов хранится в т.н. checklist’е. В котором указываются все атрибуты теста, в т.ч. и «регрессия». Также в checklist’е содержится результат выполнения теста, с фиксированием версии, на которой был выполнен тест. Так вот, чтобы понять что тестировать, можно сравнить разницу текущей версии и версии из результата теста со значением поля «регрессия» и сделать соответствующий вывод. Для удобства, я написал приложение, которое умеет это делать и отмечает все «невалидные» тесты в checklist’е. Т.е. теперь работа по тестирование выглядит следующим образом:
    — Тестировщик выбирает себе checklist (для удобства, для каждого компонента системы имеется свой отдельный).
    — Потом он запускает приложение, обрабатывает выбранный checklist (помечая в нем тесты, которые необходимо выполнить на текущей версии).
    — Открывает обработанный checklist и выполняет те тесты, которые были отмечены.
    Т.е. думать особо уже не нужно :)

  3. Интересный подход.
    А скажите, в каком виде вы храните тесты/результаты и как определяете выборку на каждый билд?
    В смысле используете какое-то решения для автоматического назначения тестов на билд или же вручную отбираете? А если тестов будет 500? 1000?

  4. 1. Тесты хранятся в excel-таблицах. Для каждого компонента системы создается отдельный файл. Это похоже на достаточно подробный checklist.
    2. Результаты заносятся в excel. Если тест прошел — указывается версия, на который он был выполнен; если не прошел — номер бага, который был занесен по этому поводу.
    3. Для отбора тестов написано hta-приложение. На входе у него excel-файлы + текущая версия (которую нужно протестировать). На выходе — тот же excel-файл, где отмечены цветом те тесты, которые надо выполнить + Summary report, где указывается общая статистика тестов.

  5. Мы тоже юзаем Excel для хранения тест кейсов, но в данный момент кейсов стало очень много, а времени на прогон мало — ищу решение для оптимизации.
    Спасибо за ответ и за статью.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s