Как стать автором
Обновить

Комментарии 13

"… В команде, занимающейся разработкой серверной облачной инфраструктуры на облачной платформе Microsoft Azure"

А для чего конкретно используется Azure?
Мы размещаем наши сервисы в Azure, потому что это удобно)
Относительно простой деплой сервисов, удобная инфраструктура для горизонтального масштабирования, встроенные средства диагностики и много-много всего)
Может вам будет полезной вот такая ссылочка на open-source: github.com/allure-framework/allure-mstest-adapter Это набор инструментов для того, чтобы сгенерировать Allure отчет по TRX файлам.
Спасибо)
Посмотрю обязательно.
На самом деле я не вижу ничего сложного в написании парсера TRX файлов. Это же обычный XML с результатами тестов. Для простого отчета по результату прогона тестов действительно возможно достаточно любого парсера.
Но, TFS база, откуда мы вытаскиваем результаты тест кейсов хранит очень много полезной информации — в частности это история прогона (по этой истории можно предположительно понять какой именно чекин сломал тест). Также при необходимости туда можно записывать intelliTrace и другую отладочную информацию, которая иногда требуется для поиска проблемы.
Парсер XML написать несложно. Сложнее написать хороший отчет. :)
Тестировщики должны быть нацелены на разрушение в первую очередь

Спорное утверждение. Зависит от того какие это тестировщики. Как по мне, так в первую очередь проверять надо, что всё работает в соответствии со спецификациями, а что не покрыто спецификациями, работает как минимум предсказуемо, а дальше уже ломать, крушить, заводить тикеты.
Спецификация это очень общее понятие. Здесь все зависит от методологии. Стоимость исправления ошибок в спецификации (или в любой другой документации) велика по сравнение с банальными ошибками в коде.
По своему опыту могу сказать, что тестировщики, как минимум, должны критически относится к документации, а не принимать ее как есть.
Если мы говорим о спецификации интерфейсов (low level design), то следует проверять ее на соответствие бизнес спецификации и так далее. Есть даже такой отдельный вид тестирования как статическое, задача которого не только проверять качество кода, но и документацию.
Спасибо за интересную статью. Используете ли вы Fuzzy тесты? Что о них думаете?
У нас строго типизированное публичное апи, которое и так фильтрует практически весь «мусор».
Специально ни каких Fuzzy фреймворков мы не используем, но всегда пишем отдельные тесты проверяющие корректную обработку «не правильных входных данных».
Опять же все зависит от системы.
Года 3 назад читал книгу, «Исследование уязвимостей методом грубой силы» (вроде такое название), так там приводили примеры уязвимостей системы, которая написана на C или каком то подобном языке- и что при определенных входных данных в системе возникало переполнение буфера, которое открывало злоумышленнику возможность исполнения произвольного кода.

в общем мое мнение- тесты на обработку некорректных данных, исключительных ситуаций (как минимум описанных в спецификации интерфейсов) должны быть включены в регресс.
А скажите пожалуйста, какую литературу по тестам от MSTest стоит почитать? а то у меня имеется достаточно не мелкого объема приложение, но в списке тестов до сих пор висит один штатный тест и я не знаю, как к нему подойти дальше и понимаю что без тестирования уже сложно :(
Кроме MsTest есть еще множетсво xUnit фреймворков. И все они очень похожи) Начните с моей любимой книги «Art of unit testing». Книга универсальная и читается очень легко). А по MsTest есть куча документации в msdn.
Ну хочется реальных примеров, если честно, как под десктопные/современно-универсальные так и под MS MVC
Если честно я не занимаюсь тестированием десктопных или веб приложений. Я же правильно понял, что вы имели ввиду их? Просто на базе MVC можно реализовывать простые REST API сервисы)
Если я прав, то вам надо прочитать:
habrahabr.ru/post/97012/
msdn.microsoft.com/en-us/library/dd286726.aspx
msdn.microsoft.com/en-us/library/dd286681(v=vs.100).aspx

После этого у вас появится представление как реализовывать CodedUI тесты на базе MS Test.
Там все довольно просто — записываете некоторую последовательность действий и проверок, а фреймворк сам генерирует код. Я рекомендую его использовать только в качестве примера, т.к. этот автосгенеренный код мягко говоря вообще не поддерживаемый.
Но на базе CodedUI фреймворка, можно писать вполне хорошие тесты. В идеале, разработчики UI интерфейса также должны согласовывать изменения своих компонент с разработчиками UI тестов — это обеспечит надежность самих тестов. К сожалению это не всегда выполнимо. Особенно в тех случаях когда тесты и код разрабатываются разными командами или компаниями. В результате, иногда, я знаю сам лично несколько примеров, стоимости поддержки UI автотестов может стать очень высокой и от них придется отказываться.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий