Перейти к содержимому

Фотография

Можно ли померить Code Coverage ручных тестов?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 3

#1 igor.lyubin

igor.lyubin

    Новый участник

  • Members
  • Pip
  • 24 сообщений
  • ФИО:igor lyubin
  • Город:Moscow


Отправлено 01 октября 2010 - 11:06

Добрый день.

У нас возник интересный вопрос.
Известно, что для unit-тестов можно измерять покрытие кода (code coverage).

Можно ли измерить code coverage для ручных тестов? Для функциональных автотестов?

Что для этого нужно сделать? Собирать какие-то специальные инструментальные билды?
Как это измеряется, с помощью каких инструментов?

Для меня интерес представляет виндовое приложение написнное на C# (.Net, WPF).
Что здесь можно придумать?

Заранее, спасибо.
  • 0

#2 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 01 октября 2010 - 11:33

Можно ли измерить code coverage для ручных тестов? Для функциональных автотестов?


MS говорит, что можно
http://msdn.microsof...y/ms182616.aspx
  • 0

#3 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 01 октября 2010 - 13:07

Добрый день.

У нас возник интересный вопрос.
Известно, что для unit-тестов можно измерять покрытие кода (code coverage).

Можно ли измерить code coverage для ручных тестов? Для функциональных автотестов?

Что для этого нужно сделать? Собирать какие-то специальные инструментальные билды?
Как это измеряется, с помощью каких инструментов?

Для меня интерес представляет виндовое приложение написнное на C# (.Net, WPF).
Что здесь можно придумать?

Заранее, спасибо.

А в чем сомнения?

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

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

Ваши действия
1) Найти инструмент для подсчета покрытия для вашего типа приложения.Никогда не делал ничего подобного для Си-решетки. Например, нашел тул - http://ncover.sourceforge.net/ - изучайте как он работает.
2) Сделать инструментированный билд, если инструмент поддерживает статический тип
или
2) Запустить специальным образом для динамического режима
3) Тестировать как ни в чем не бывало
4) Сделать отчет по полученным данным

ИЛИ
1) 2) Если ваши разработчики считают покрытие, то придти к ним и попросить сборку на которой они это делают и узнать каким инструментом пользуются и как
3) 4) - те же самые
  • 0
Regards,
Alexey

#4 saveug

saveug

    Новый участник

  • Members
  • Pip
  • 33 сообщений
  • ФИО:Савицкий Евгений

Отправлено 03 октября 2010 - 11:33

Добрый день.

У нас возник интересный вопрос.
Известно, что для unit-тестов можно измерять покрытие кода (code coverage).

Можно ли измерить code coverage для ручных тестов? Для функциональных автотестов?

Что для этого нужно сделать? Собирать какие-то специальные инструментальные билды?
Как это измеряется, с помощью каких инструментов?

Для меня интерес представляет виндовое приложение написнное на C# (.Net, WPF).
Что здесь можно придумать?

Заранее, спасибо.


Хочу обратить Ваше внимание вот на какой аспект. Покрытие кода unit-тестами поддается измерению не столько из-за технических возможностей, сколько из-за самой природы тестов: каждый тест (с массой тестовых случаев) пишется на конкретный класс или даже метод (покрывает их). То есть, по сути Вы тестируете различные варианты использования того или иного метода, а наличие теста - это некое мерило покрытия.

Функциональное тестирование проверяет конкретные варианты использования, в которых тот или иной метод может вызываться только по одной ветке логики, либо не вызываться вообще. То есть у Вас не остается шансов определить: есть покрытие или нет, должно оно быть или нет. Причина простая - слишком сложные и неоднозначные связи между функциональными тестами и исходным кодом.

В любом случае, всегда остается открытым вопрос качества этого покрытия, даже в unit-тестировании. Многие так и продолжают измерять покрытие просто для галочки, не рекомендую вам этого делать, поскольку потратите время ни на что.

Если уж и говорить о покрытии в функциональном тестировании, то чаще всего измеряют покрытие вариантов использования (историй пользователей). В данном случае берем число реализованных историй, смотрим трассировку их до функциональных тестов и запуски тестов. Пробелы в этой цепочке и показывают степень покрытия. Я, например, в своих проектах так и делаю, а трассу помогает отслеживать DEVPROM.
  • 0


Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных