В жизни любого серьезного проекта всегда уделяется большое внимание и много времени тестированию. Процесс тестированию может продолжаться несколько часов, а может занять и целые недели, все зависит от размеров вашего проекта. Существует множество вариантов тестирования вашего решения. В Visual Studio 2010 появился новый способ тестрования, позволяющий с легкостью находить недоработки в графическом интерфейсе.
На очереди практические советы по построению тестопригодного кода и примеры применения изложенных знаний на реальных проектах.
P. S. Отдельное спасибо taxigy за корректуру русского перевода.
Я думаю, что баги можно разделить на три базовые категории:
Логические. Логические баги наиболее популярны и часто встречающиеся. Это ваши if'ы, циклы и другая подобная логика в коде. (Мысли: это работает неверно).
Баги взаимодействия. Баг взаимодействия — когда два разных объекта неправильно взаимодействуют между собой. Например, выход одного объекта является не тем, что ожидает следующий объект в цепочке. (Мысли: данные к месту назначения пришли испорченными).
Баги отображения. Баг отображения — когда вывод (обычно некоторый пользовательский интерфейс, UI) отображается некорректно. Ключевой момент — в том, что это человек определяет, что есть правильно, а что — нет. (Мысли: это «выглядит» неправильно)
Перевод был сделан как ответ на некоторые комментарии к переводу Настройка IDE для автоматического запуска тестов. Прочитав статью и посмотрев наглядные примеры, вы сможете прочувствовать разницу между разнообразными видами тестов, что, в свою очередь, поможет вам грамотно составлять тесты и не перемешивать их в одной куче. Каждый тест хорош в нужном месте и в нужное время!
— mazurov
Вы порой слышите о маленьких/средних/больших/модульных/интеграционных/функциональных/сценарных тестах, но сколько из нас знают что это означает? В данной статье мой взгляд на виды тестов.
Когда я программирую, то сначала пишу тесты. Частый ручной прогон тестов может превратиться в утомительное занятие.
Опишу обычный сценарий разработки кода:
Ваши тесты «зеленые» и вы приступили к рефакторингу, который на ваш взгляд простой и безопасный. После этого вы запустили тесты и увидели, что что-то сломалось. Но перед этим вы уже сделали десять маленьких изменений и не знаете какое из них поломало программу. Решение заключалось в более частом запуске тестов (после каждого изменения), но вы забывали сделать это.
Нашёл симпатичный мультик про IBM Rational Quality Manager (под хабракатом). Впрочем, мультик не специфичен для данного конкретного инструмента, всё рассказанное и показанное с равным успехом можно применить и к любому другому инструменту управления тестированием. Мульт не технический, можно показывать его начальству с целью объяснения того, что это за инструменты такие и зачем они нужны.
Наверняка многие слышали анекдоты про китайцев. Кто не слышал — приведу пару типичных примеров:
Китайский противотанковый взвод численностью 3000 чел. состоит из 3 отделений по 1000 чел. Задача отделения — разобрать танк противника на части, пока он не выстрелил.
или вот такой:
Сегодня в провинции Шаньдунь сдана в эксплуатацию новая мощная электростанция. Принцип действия: три миллиона китайцев бегают по эбонитовому полу в шерстяных носках.
Однако, сказка ложь, да в ней намёк. Некоторое время тому назад мне попались на глаза две интересные заметки:
Сформирована программа выступлений на конференции SQA Days 2009, которая пройдет 23-24 апреля 2009 г. в Санкт-Петербурге.
Конференция обещает быть весьма насыщенной. В первый день будет три трека докладов, во второй день мастер-классы и круглые столы. Программа первого дня сформирована полностью, во второй день ещё могут быть некоторые изменения в расписании, а также пока уточняются списки участников-экспертов на круглых столах.
Для начала, давайте разберемся, что же такое Behavior Driven Development(в дальнейшем BDD) и чем данная техника отличается от Test-Driven Development(в дальнейшем TDD)
Разрабо́тка че́рез тести́рование (англ. test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (англ. test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.
17 ноября 2008г. Минске в образовательном центре IBB прошла 4-я Международная конференция специалистов в области обеспечения качества программного обеспечения SQA Days. Конференция была посвящена вопросам, связанным с тестированием и обеспечением качества программного обеспечения: функциональному тестированию, тестированию производительности, автоматизации тестирования и инструментальным средствам, конфигурационному тестированию, тестированию usability и защищенности, статическим методам обеспечения качества и другим сферам интересов QA-специалистов. Радует то, что в 2009 году организаторы планируют провести ещё несколько конференций для QA специалистов.
Каждый разработчик знает, что писать тесты это правильно, часть разработчиков знает это на своем опыте, другая из книг тех программистов, которые знают это на личном опыте и умеют продавать свои книги. Писать книги я не умею, да и опыта мало, но поделиться некоторыми аспектами использования unit тестов я могу. Ниже, я постараюсь поменьше упоминать прописные истины, но побольше оригинальных мыслей. Все размышления не привязаны к какому либо языку или фреймворку, поэтому эта статья может быть полезна широкой аудитории разработчиков.
Простой, но внезапный вопрос чуть не поставил в тупик: «Почему тестировать должны тестировщики, а не аналитики, разработчики или пользователи?» Попытаюсь быстренько обосновать, но, скорее всего, потребуется помощь со стороны, такие формулировки требуют многостороннего анализа и освещения, и, несмотря на многолетнее владение темой, может потребоваться время на обдумывание.
Сегодня как-то малозаметно прошёл праздник — день тестировщика, а между тем эти люди не менее важны в нашем деле, чем программисты и дизайнеры. Именно от них зачастую зависит финальное качество новых продуктов.
Поздравляю всех тестировщиков и других служителей культа QA с профессиональным праздником!
P.S.: По этой ссылке можно прочитать почему этот день именно 9 сентября и почему ошибки называют багами.
Дисклаймер. Данная статья не является претензией на объективность, а отражает только мое сугубо личное мнение. Также прошу обратить внимание на то, что мое мнение не является статичным и может меняться. Статья написана только для того, чтобы не отвечать много раз на одни и те же вопросы, а просто дать ссылку.
Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).
27 мая 2008 года в Москве прошла третья международная конференция SQA Days 2008, в которой участвовали более 200 специалистов по тестированию и обеспечению качества программных систем, а также другие заинтересованные лица. Конференция посвящалась вопросам, связанным с тестированием и обеспечением качества веб-приложений.
Компания Agitar Software предлагает довольно любопытную метрику для оценки качества программного кода. Формула с недвусмысленным названием CRAP позволяет оценить, воскликнет ли разработчик «Oh crap!» узнав, что за код ему выпало счастье поддерживать.
Уважаемые коллеги тестировщики (и приближенные к ним люди). Какие фреймворки вы используете для тестирования (data-driven, model-driven, point-and-click, )? Какими инструментами автоматизированного тестирования пользуетесь и чем обусловлен выбор? Используете ли вы open-source решения?
Некоторое время назад на форуме сообщества it4business был поднят вопрос: Какого эксперта в области тестирования с мировым уровнем вы бы хотели пригласить для проведения семинара или тренинга.
Ответов было не так уж много и как-то это все затихло.
Но я задался целью найти в сети ресурсы тех экспертов, имена которых были затронуты в обсуждении и некоторых других, которых я считаю таковыми.
Все ресурсы конечно на английском языке. На всех ресурсах можно найти большое количество статей, зачастую шаблоны и презентации.