Функциональное тестирование

Как эффективно протестировать чатбот

barancev@gmail.com (Administrator) — Tue, 16 Jan 2024 20:00:00 +0000

Автор: Сумиа Мухерджи (Soumya Mukherjee)
Оригинал статьи: Tea-Time With Testers, #02/2021
Перевод: Ольга Алифанова

Хоть и немногие в это верят, QA всегда было отдельной специальностью: этот безусловный факт только подтверждается с годами. Даже самые лучшие разработчики не способны тестировать – они или забывают про критические сценарии, или оставляют интеграционное тестирование тестировщикам. QA – неотъемлемое требование для продукта, оно поддерживает все процессы и борется за качество. Во всем мире QA специализировано, и дабы это доказать, посмотрим, сколько проблем вызовет проверка, что чатбот хорошо работает: это требует глубокого понимания работы чатбота, его внутренней кухни, инструментария, алгоритмов, а также генерации сценариев, чтобы все это проверить.

Когда что-то пошло не так: что расскажут экраны тестировщику

barancev@gmail.com (Administrator) — Tue, 11 Jul 2023 07:46:13 +0000

Оригинал статьи размещен в блоге компании "Россельхозбанк"
Автор: Демидова Наталия

Привет! Мы тестировщики платформы «Свое Родное» от Россельхозбанка. В статье расскажем о нашем проекте, как проводят релизы и регрессы, а также затронем актуальную тему работы приложений — обработку ошибок, а именно ошибку «Что-то пошло не так», которая встречается повсеместно.

JMeter как инструмент для автоматизации функционального тестирования

barancev@gmail.com (Administrator) — Tue, 04 Jul 2023 10:05:30 +0000

Авторы: Алексей Чичук, Владислав Литвинов, Анастасия Стрижеченко
Оригинал статьи размещен в блоге компании «Точка» на сайте Хабр

Привет, мы Алексей Чичук, Анастасия Стрижеченко и Владислав Литвинов — тестировщики из банка Точка.

И сегодня мы расскажем, как и почему мы используем JMeter для функционального тестирования.

Как разобраться с плавающими багами

barancev@gmail.com (Administrator) — Sun, 17 Apr 2022 20:00:00 +0000

Автор: Никола Линдгрен (Nicola Lindgren)
Оригинал статьи
Перевод: Ольга Алифанова

Плавающие баги раздражают не только тестировщиков, но и остальную команду. Возможно, вам повезло, и вы поймали такой баг до того, как он дошел до бета-тестировщиков – или же вы пытаетесь разобраться, что тут, черт возьми, произошло, потому что пользователи сообщили о баге, но вы не можете его воспроизвести.

Ниже – ряд идей, как быть с плавающими багами.

SQA Days-24: функциональное тестирование

barancev@gmail.com (Administrator) — Sun, 20 Jan 2019 20:00:00 +0000

Публикуем подборку докладов с конференции SQA Days 24, посвященную функциональному тестированию.

Интеграционное тестирование: основано на реальных событиях – Любовь Копылова, Lamoda (Москва).
Testing in production – Гойко Адзич (Gojko Adzic), Neuri Consulting LLP (Лондон).
Техника ABCD: от создания модели до проектирования тестов – Евгений Клименко, TDNA (Запорожье).
Анализ использования ресурсов приложениями в ОС Windows – Василий Буров, Quest Software (Санкт-Петербург).

Серьезность и приоритет дефекта: в чем различие?

barancev@gmail.com (Administrator) — Thu, 01 Nov 2018 20:00:00 +0000

Автор: Андрей Петров

Оригинальная публикация

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

Самодельные аддоны к браузерам на службе тестировщика

barancev@gmail.com (Administrator) — Wed, 30 May 2018 10:13:44 +0000

Оригинальная публикация

Аддоны к браузерам вряд ли пригодятся в автоматизации тестирования web-систем, но при ручном тестировании они могут оказаться полезны. К примеру, можно заполнять элементы на выбранной странице, исходя из своих условий и входных данных. Ниже рассмотрено создание такого аддона для Firefox и Chrome без претензий на красоту кода.

Задача: разработать аддон для Firefox и расширение для Chrome со следующей функциональностью:

1. В тулбаре появляется кнопка (иконка).
2. При нажатии на эту кнопку анализируется URL активной страницы (вкладки). Если URL – один из заранее заданных URLs, то при нажатии на кнопку тулбара скрипт берет пару “пользователь-пароль” из опций в зависимости от URL и заполняет поля ввода логина и пароля на странице. Далее скрипт нажимает кнопку логина.

Особенности тестирования «черного ящика»

barancev@gmail.com (Administrator) — Thu, 23 Nov 2017 20:00:00 +0000

Автор: Ольга Панина

Оригинальная публикация: http://quality-lab.ru/key-principles-of-black-box-testing/

В предыдущей статье мы рассмотрели особенности тестирования «серого ящика» по сравнению с «белым» и «черным». Давайте сегодня подробнее остановимся на «черном ящике» и выясним, где и когда его используют, а также какие у него достоинства и недостатки.

Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.

Что такое «черный ящик» согласно терминологии ISTQB?

Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство.

15 инструментов для тестирования API

barancev@gmail.com (Administrator) — Thu, 16 Nov 2017 14:35:06 +0000

Автор: Джо Колантонио (Joe Colantonio)

Оригинал статьи: https://techbeacon.com/5-top-open-source-api-testing-tools-how-choose

https://www.joecolantonio.com/2017/05/16/12-open-source-api-testing-tools-rest-soap-services/

Перевод: Ольга Алифанова

Сдвиг влево, происходящий благодаря таким процессам, как непрерывная интеграция и непрерывные релизы, приводит к растущей необходимости быстрой обратной связи от тестировщиков.

Проблема интерфейсных тестов в том, что они довольно медленные, и поэтому они – не лучший вариант, когда нужно быстро дать разработчикам знать, сломал ли их код новый билд. API-тесты куда быстрее и более надежны.

Прежде чем рассматривать инструменты тестирования API, давайте убедимся, что мы одинаково понимаем, что это вообще такое.

Эвристики функционального тестирования: системный взгляд

barancev@gmail.com (Administrator) — Tue, 04 Oct 2016 12:15:27 +0000

Автор: Джорис Меерц (Joris Meerts), Testing References

Оригинал статьи: http://www.testingreferences.com/docs/Functional_Testing_Heuristics.pdf

Перевод: Ольга Алифанова

Использование техник тестирования, основанных на спецификации, для покрытия путей через программу или функцию – это очень заманчивая для функционального тестирования идея. Не менее заманчиво предположить, что раз эти пути или комбинации покрыты – функциональное тестирование более или менее завершено. Моя цель – показать при помощи описанных ниже эвристик, что функциональное тестирование может – и, возможно, должно – смотреть на вещи шире, учитывая не только то, что явно прописано в требованиях или дизайн-макете. Я уверен, что при помощи этих эвристик и точек зрения можно выявить приличное количество функциональных аспектов системы.

Список основан на моем личном опыте тестирования программных продуктов. Я также благодарен Джеймсу Баху за эвристику SFDPOT, и Элизабет Хендриксон, Джеймсу Линдси и Дейлу Эмери, как создателям чит-листа эвристик тестирования.

Исследовательское тестирование. Инструкция пользователя

barancev@gmail.com (Administrator) — Mon, 20 Jun 2016 08:22:05 +0000

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

Представляем доклад Глеба Рыбалко.

Популярность техник тестирования основанных на опыте набирает популярность с каждым годом. Скорее всего, Вы уже не найдете ни одного профессионала по тестированию и обеспечению качества, которому были бы не знакомы термины exploratory & ad hoc. Об этих видах тестирования пишутся книжки. Популярность этого направления уже дошла до того, что такое тестирование было включено в некоторые американские стандарты и предписания. Естественным образом такая ситуация отражается и на клиентах. Все чаще и чаще клиент сам приходит к Вам с инициативой внедрения исследовательского или ad hoc тестирования. И первое, что в таком случае хочется ответить это: «Да, да, конечно. Это нам поможет. Это же последние веяния. Давайте попробуем… «Но всегда ли исследовательское тестирование помогает?

Я дам несколько практических советов, которые помогут использовать данный вид тестирования на практике. Мы поговорим о следующих вещах:

Как определить цели данного вида тестирования на проекте
Как идентифицировать нужных людей, для команды «исследователей»
Какие тестовые артефакты действительно помогают в исследовательском тестировании
Какие метрики работают и чем они помогают команде

{iframe width="560" height="315" frameborder="0" allowfullscreen}https://www.youtube.com/embed/dYYlOK4evso{/iframe}

Обсудить в форуме

Николай Алименков: TDD c помощью функциональных тестов на WebDriver

barancev@gmail.com (Administrator) — Tue, 21 Feb 2012 12:03:03 +0000

По традиции, мы публикуем лучшие, по мнению участников, выступления с наших онлайн-конференций. Сегодня мы предлагаем ознакомиться с докладом "диверсанта", пришедшего на нашу конференцию Auto ConfeT&QA 2012 "с той стороны баррикад" -- более разработчика, чем тестировщика, Николая Алименкова. Не секрет, что разработчики тоже пишут тесты, для себя, и даже придумали специальный подход к разработке, направляемый тестами - TDD (Test-Driven Development). Николай предложил перенести эту идею с уровня модульного тестирования на уровень разработки пользовательского интерфейса. Насколько удачно это получилось -- судите сами.

Алексей Баранцев: Кроссбраузерное тестирование

barancev@gmail.com (Administrator) — Mon, 20 Feb 2012 05:46:14 +0000

Несколько дней назад завершилась онлайн-конференция Auto ConfeT&QA 2012, чуть меньше месяца остается до следующей конференции -- Chief ConfeT&QA 2012.

А тем временем мы предлагаем посмотреть рассказ Алексея Баранцева о кроссбраузерном тестировании с прошлогодней "конфетки" -- конференции ConfeT&QA 2011. Вы узнаете, где именно в работе браузеров существуют различия, почему недостаточно проверять соответствие стандартам, где взять различные версии браузеров, что следует варьировать при выполнении тестов помимо версии браузера, какими онлайн-сервисами можно пользоваться для тестирования в разных браузерах. Если вы специализируетесь на тестировании веб-приложений -- уделите полчаса своего внимания для повышения квалификации, это стоит потраченного времени.

Игорь Любин: Тестирование компонентов без пользовательского интерфейса

barancev@gmail.com (Administrator) — Wed, 09 Feb 2011 10:05:47 +0000

Продолжаем публикацию слайдкастов выступлений с прошедшей конференции SQA Days 8, на очереди рассказ Игоря Любина "Тестирование компонентов без пользовательского интерфейса".

Кстати, в начале своего выступления Игорь немного рассказал о своём родном городе Казани, где пройдёт следующая конференция SQA Days 9.

Видеозапись лекций Виктора Кулямина "Тестирование на основе моделей"

barancev@gmail.com (Administrator) — Wed, 05 May 2010 06:56:04 +0000

25 апреля 2010 года в Клубе Computer Science при Петербургском отделении Математического института РАН выступил Виктор Кулямин (ИСП РАН) с мини-курсом "Тестирование на основе моделей" (3 лекции по примерно 90 минут). В этих лекциях речь шла о том, что такое вообще тестирование на основе моделей, почему оно достаточно перспективно как подход к контролю качества современного сложного ПО, какие основные виды моделей используются в тестировании и какими методами можно эффективно строить тесты на их основе.

"Мне лично очень понравилась активность аудитории," - сказал Виктор, - "большое количество вопросов и замечаний, как во время лекций, так и после, еще почти час я отвечал на вопросы слушателей. Это при том, что люди пришли на лекции в воскресный день, потратив его практически полностью".

Слайды, сопровождавшие этот мини-курс, доступны на сайте Клуба Computer Science, кроме того опубликованы видеозаписи выступления Виктора:

Видео 1-й лекции
Видео 2-й лекции
Видео 3-й лекции

За ссылки на видеозаписи мы благодарим Михаила Елычева, который присутствовал на этих лекциях и поделился своими впечатлениями на сайте сообщества тестировщиков Санкт-Петербурга.

Эссе о валидации данных

barancev@ispras.ru (Баранцев Алексей) — Sat, 17 Oct 2009 11:15:13 +0000

В комментариях к заметке "Можно ли делить на 0,01 ?" я обещал написать отдельный пост, посвященный валидации данных, которые приложения получают извне -- от пользователя, от других программ, из файлов и т.д. Кроме того, не так давно эта тема вновь ненадолго возникла в обсуждении заметки "Проверка экранных форм". Так что, видимо, пришло время обсудить этот вопрос в деталях.

Мы рассмотрим три вопроса -- 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок.

Тестирование Установки (Installation Testing)

barancev@gmail.com (Administrator) — Wed, 22 Jul 2009 13:07:27 +0000

Авторы: Алексей Булат, Василий Касимов, Владимир Антонов, Алексей Лянгузов
Особая благодарность за помощь в работе над материалом Сергею Вороновичу и Андрею Осипенко
Информация получена: Из блога Про Тестинг (статья Тестирование Инсталляций (Installation Software Testing) и сайта ProTesting.ru (раздел Тестирование Установки (Installation Testing))

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

В настоящий момент наиболее распространена установка ПО при помощи инсталляторов (специальных программ, которые сами по себе так же требуют надлежащего тестирования, описание которого рассмотрено ниже в разделе "Особенности тестирования инсталляторов.").

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

В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого, зачастую, пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии, в случае неудачи. Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя - это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

Именно такой комплексный подход с написанием планов, пошаговой проверкой установки и отката инсталляции, полноправно можно назвать тестированием установки или Installation Testing.

Анатомия инструментов функционального тестирования

barancev@ispras.ru (Баранцев Алексей) — Sat, 04 Jul 2009 15:41:29 +0000

Поскольку видеозапись докладов на конференции SQA Days 2008 Minsk получилась не очень удачной (на ней не видно слайдов), я в конце концов решил переделать свой доклад в формат слайдкаста (то есть презентации с наложенным звуком).

QTP: Реализация GUI слоя при помощи классов

barancev@gmail.com (Administrator) — Tue, 12 May 2009 16:14:18 +0000

Автор: Meir Bar-Tal
Перевод: Сергей Талалаев (SQAdotBY)
Оригинальная статья: Implementing a GUI Layer with Classes

В продолжении темы сотрудничества с уважаемым ресурсом AdvancedQTP.com и с любезного разрешения автора, хотел бы представить перевод очень интересной статьи с данного сайта.

Описанный подход заслуживает права на детальное изучение и применим не только в рамках QTP, но и в любом другом средстве автоматического тестирования.
Автором проведена серьезная работа с целью поиска оптимального варианта реализации тестового фреймворка с точки зрения минимизации издержек на его поддержку.

QTP: Универсальный класс для работы с данными

barancev@gmail.com (Administrator) — Thu, 16 Apr 2009 13:58:34 +0000

Автор: Сергей Талалаев
Оригинальная публикация: QTP: Универсальный класс для работы с данными

Влияние мирового кризиса к сожалению сказалось и на моей персоне и мне потребовалось срочно и по возможности глубоко изучить новый для себя фреймворк - Quick Test Professional. И душа рвется поведать о результатах, которые надеюсь буду полезны не только мне одному.

Двойное название статьи как-бы говорит о том, что материала накопилось достаточно для небольшой серии статей и если силы и желание не иссякнут еще на первой статье, то есть шанс увидеть продолжение ...

Проблемы тестирования 64-битных приложений

barancev@gmail.com (Administrator) — Thu, 19 Mar 2009 06:36:38 +0000

Автор: Статья написана членами коллектива ООО «Системы программной верификации» или в соавторстве с ними.

Оригинальная публикация

В статье рассмотрен ряд вопросов связанных с тестированием 64-битного программного обеспечения. Обозначены сложности, с которыми может столкнуться разработчик ресурсоемких 64-битных приложений, и пути их преодоления.

Тестирование параллельных программ

barancev@gmail.com (Administrator) — Thu, 19 Mar 2009 05:55:58 +0000

Автор: Статья написана членами коллектива ООО «Системы программной верификации» или в соавторстве с ними.

Оригинальная публикация

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

Гейзенбаг (англ. Heisenbug) - термин, используемый в программировании для описания программной ошибки, которая исчезает или меняет свои свойства при попытке её обнаружения [2]. Данное название является игрой слов и происходит от физического термина «Принцип неопределённости Гейзенберга», который на бытовом уровне понимается как изменение наблюдаемого объекта в результате самого факта наблюдения, происходящее в квантовой механике. В русской терминологии более часто используется термин «плавающая ошибка». Примером могут являться ошибки, которые проявляются в окончательном варианте программы (“релизе”), однако не видны в режиме отладки, или ошибки синхронизации в многопоточном приложении.

Таким образом, задача параллельного тестирования во многом сводится к проблеме создания инструментов диагностики, минимально влияющих на поведение программы или создающих необходимые условия для ее проявления. Поэтому посмотрим на классические методологии тестирования под новым углом.

Фоновое модульное тестирование: новый виток развития интеграции модульных тестов и сред разработки

barancev@gmail.com (Administrator) — Wed, 11 Feb 2009 10:24:34 +0000

Автор: Джон Смарт (John Smart)

Оригинальная публикация: Background Unit Testing: New evolutions in unit testing and IDE integration

Об авторе: Джон Смарт -- ведущий консультант компании Wakaleo Consulting, специализирующейся в области Enterprise Java, Web Development и Open Source technologies. В настоящее время он проживает в Веллингтоне, Новая Зеландия. Джон широко известен в Java-сообществе благодаря многочисленным публикациям, кроме того, он является автором Java Power Tools.

Одна из самых последних инноваций в модульном тестировании – идея непрерывного тестирования, то есть выполнение модульных тестов сразу же после того, как вы изменили что-то в исходном коде – то есть, как только вы сохраняете сделанные изменения на диск, нужные модульные тесты выполняются в фоновом режиме. Это позволяет избежать ситуаций, когда разработчик либо забыл, либо по какой-то другой причине не выполнил нужные тесты, в результате чего в репозиторий попадает код, на котором эти тесты завершаются неуспешно. Разумеется, главная сложность заключается в том, чтобы определить, какие же тесты следует выполнить, когда изменился тот или иной фрагмент исходного кода, поскольку выполнять полный комплект тестов может быть слишком долго, чтобы делать это после каждого изменения кода. Нужно выделить ровно те тесты, на результат выполнения которых в наибольшей степени могут оказать влияние сделанные изменения. Я уверен, что через пару лет это станет стандартной встроенной функциональностью во всех средах разработки.

А пока этого не случилось, вы можете воспользоваться вспомогательными инструментами.

Тестирование web-приложений с помощью Ruby

barancev@gmail.com (Administrator) — Fri, 31 Oct 2008 14:19:55 +0000

Автор: Александр Симаков

Оригинальная публикация

Тестирование web-приложений является неотъемлемой частью процесса их разработки. Существуют различные уровни тестирования, вот некоторые из них:

модульное тестирование;
интеграционное тестирование;
системное тестирование;
приемочное тестирование.

В рамках модульного тестирования проверяются минимально возможные компоненты, например, отдельные классы или функции. Интеграционное тестирование предназначено для проверки связи между компонентами. Задачей системного тестирования является проверка как функциональных, так и не функциональных требований к системе в целом. Приемочное тестирование проверяет поведение системы на предмет удовлетворения требований заказчика.

В этой статье рассказывается о высокоуровневой методике тестирования web-приложений которую можно использовать как для приемочного так и для системного тестирования. Ключевую роль при этом играет Ruby-библиотека Watir (Web Application Testing In Ruby). Библиотека Watir позволяет запрограммировать действия браузера Internet Explorer на языке Ruby. Таким образом можно автоматизировать значительную часть ручной работы тестеров по заполнению форм, переходу по ссылкам, проверке User-Stories т.д.

Тестирование в свете Экстремального Программирования. Часть 1. Практика использования

barancev@gmail.com (Administrator) — Mon, 29 Sep 2008 15:05:44 +0000

Авторы: Сардарян Рубен, Новичков Александр
Материал предоставлен компанией CMconsult

Данная статья посвящена достаточно интересному направлению в индустрии разработки и тестирования программного обеспечения, а именно экстремальному программированию. Про общие идеологические принципы ХР писалось много и очень много, поэтому мы сразу решили не описывать то, что и так уже есть — основу ХР. Данная статья — это практика использования.

Статья состоит из двух частей:

Практика использования;
Экстремальное программирование в IBM Rational Unified Process.