Comments 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 составляет именно список затронутых тестов, объём покрытия тестами кода он не считает.
Sign up to leave a comment.
Как тестировать только то, что нужно