Комментарии 4
Ну теперь такое надо для плюсов
Пора забыть уже за новые плюшки под плюсы пишут нехотя и очень редко. Вот обсуждение этой темы с предыдущей темы http://habrahabr.ru/company/microsoft/blog/198028/#comment_6884780
А так ждем решарпер с поддержкой плюсов.
А так ждем решарпер с поддержкой плюсов.
Исправьте, пока не набежали граммар-наци: «тестировать наше приложение согласно плана». Должно быть «тестировать согласно (чему?) плану».
Несколько комментариев по сути статьи:
1. Анализ Test Impact есть и в tfs 2010 / visual studio 2010. Чем конкретно отличается реализация его в 2013 — точно сказать не могу. Лично я пользовался этой фичей именно в 2010, замечания ниже просьба рассматривать в том же контексте.
2. Очевидный минус данной технологии в том, что для её корректной работы ручные тесты нужно делать строго по описанному сценарию. Любое отклонение от шагов приводит к собиранию лишних данных. Как-либо отредактировать собранные данные тестировщик не может, всё работает только автоматически.
3. Приложение для сбора данных также определяется автоматически. К счастью, можно указать фильтр по именам сборок, данные для которых собирать не надо.
4. Информация для анализа начинает собираться только для .Net-приложений, запущенных ПОСЛЕ старта серии тестов. Если сначала запустить приложение, а потом уже запустить серию тестов, информация собираться не будет. Вкупе с п.2 необходимость запускать приложение заранее приводит к сбору лишней информации.
5. «если проводить тесты от билда к билду, то благодаря анализу информации Code Coverage ручных тестов и ее сохранению для каждого пройденного тестового плана, мы можем четко предсказать то какой тест сломался, а какие тесты вообще не затронуты» — как раз Code Coverage ручных тестов, к сожалению, посчитать нельзя. Нельзя узнать, какой процент когда покрывают ручные тесты. Анализ Test Impact составляет именно список затронутых тестов, объём покрытия тестами кода он не считает.
1. Анализ Test Impact есть и в tfs 2010 / visual studio 2010. Чем конкретно отличается реализация его в 2013 — точно сказать не могу. Лично я пользовался этой фичей именно в 2010, замечания ниже просьба рассматривать в том же контексте.
2. Очевидный минус данной технологии в том, что для её корректной работы ручные тесты нужно делать строго по описанному сценарию. Любое отклонение от шагов приводит к собиранию лишних данных. Как-либо отредактировать собранные данные тестировщик не может, всё работает только автоматически.
3. Приложение для сбора данных также определяется автоматически. К счастью, можно указать фильтр по именам сборок, данные для которых собирать не надо.
4. Информация для анализа начинает собираться только для .Net-приложений, запущенных ПОСЛЕ старта серии тестов. Если сначала запустить приложение, а потом уже запустить серию тестов, информация собираться не будет. Вкупе с п.2 необходимость запускать приложение заранее приводит к сбору лишней информации.
5. «если проводить тесты от билда к билду, то благодаря анализу информации Code Coverage ручных тестов и ее сохранению для каждого пройденного тестового плана, мы можем четко предсказать то какой тест сломался, а какие тесты вообще не затронуты» — как раз Code Coverage ручных тестов, к сожалению, посчитать нельзя. Нельзя узнать, какой процент когда покрывают ручные тесты. Анализ Test Impact составляет именно список затронутых тестов, объём покрытия тестами кода он не считает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как тестировать только то, что нужно