что такое тестовый прогон

TestRail: как сначала подумать, а потом протестировать

Надеюсь, многие из вас знают, что в тестировании тоже есть документация. И вести ее можно по-олдскульному, в xls-файлах да в папочках или же, как настоящие джедаи, использовать специализированный инструмент.
Вот об одном из таких инструментов под названием TestRail, который мы недавно внедрили у себя в TestLab², я и хочу сегодня рассказать. Инструмент оказался настолько удачным, что молчать сил не было и я решил наконец-то сделать что-то полезное для общества.

Для всех проектов, которые мы тестируем, всегда обязательно пишется тестовая документация, от небольшого чеклиста до развесистого test suite с кросс-ссылками и сотнями кейсов. От идеи хранить документацию в локальных файлах отказались сразу и напрочь, это неудобно и просто непрофессионально. Пробовали «универсальное» решение, wiki (DokuWiki), но она не прижилась. Тут сложно сказать почему, пожалуй, дело привычки, и можно было бы «насадить добро палками», но тут подвернулся TestRail и понеслась.

Установка и системные требования

Два варианта: типичный LAMP или «IIS+SQLServer+FastCGI/PHP». Также потребуется ionCube и cURL, но это не редкость. Работает достаточно быстро, а после включения gzip через mod_deflate стало вообще пулей летать.

Основные возможности

Многопользовательская многопроектная система для ведения тестовой документации и учета результатов выполнения тестов. В продукте предусмотрено место для всех: для тест-менеджеров, которых больше интересует «когда будет» и «сколько багов», для простых тестировщиков, которым удобно отчитываться о пройденных кейсах, для аналитиков, которые смогут вгрызаться в самые дебри и выяснять чего ж оно всё так хреновов чем соль.

Как выглядит рабочий процесс

Сравнение с конкурентами

Личные впечатления

Для нас система оказалась практически идеальной и в плане минимально необходимого набора фич, и в плане удобства ежедневного использования. Мы занимаемся аутсорс-тестированием и ведем достаточно много небольших проектов, что отлично ложится в лицензионную политику вендора: лимит ограничивает только количество активных пользователей системы, поэтому мы деактивируем клиентские эккаунты по окончании проектов.
Из недостатков стоит отметить два: в текущей версии TestRail не поддерживает Unicode что означает, что вести документацию на русском/украинском языке в текущей версии без хаков невозможно. Но соответсвующий feature request уже заявлен, должны скоро добавить. Для нашей команды это непринципиально потому, что пока все проекты, достойные попадания в TestRail, ведутся на английском языке.
Вторая проблема — это отсутсвтие какого-то wysiwyg-редактора во всех text edit-полях. Это радует инженеров, но регулярно смущает заказчиков.

Резюме

Если вы ведете тестовую документацию по большому проекту, или уже теряетесь в тоннах doc- и xls-файлов с кейсами — вам стоит обратить внимание на TestRail. Это продукт, который не нужен всем и каждому, но если вы занимаетесь тестированием профессионально, то запомните это название, возможно, TestRail пригодится вам в следующем проекте.

Если будет интересно — я готов развивать тему различных тулов для тестирования и, к примеру, внимательно изучить ту же Testopia, чтобы рассказать вам о ней. Пишите в комменты.

*Умеющие гуглить могут найти в интернетах купоны на скидки.

Источник

Запускает тест

Что такое пробный тест?

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

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

Ключевые выводы

Понимание теста прогонов

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

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

Типы прогонов тестов

Тест прогонов – это сокращенная версия полного названия: тест прогонов Вальда – Вулфовица, названный так в честь математиков Абрахама Вальда и Якоба Вулфовица. Тест Вальда-Вольфовица – это непараметрический статистический тест, который означает, что анализируемые данные не должны соответствовать определенным допущениям или параметрам. Тест Вальда-Вольфовица можно использовать для проверки гипотезы о том, что переменные в строке данных взаимно независимы.

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

Преимущества пробного теста

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

Два действенных способа, которыми трейдеры могут использовать пробный тест, включают:

Источник

TestRail — тестовые прогоны

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

Добавить тестовый прогон

Чтобы добавить тестовый прогон на вкладке «Тестовые прогоны и результаты», необходимо выполнить следующие шаги

Перейти на вкладку «Тестовые прогоны и результаты»

Нажмите кнопку «Добавить тестовый прогон» в разных местах, как показано на скриншоте ниже

Перейти на вкладку «Тестовые прогоны и результаты»

Нажмите кнопку «Добавить тестовый прогон» в разных местах, как показано на скриншоте ниже

Откроется страница «Добавить тестовый прогон», где пользователь должен ввести Имя, Веха, Назначено, Описание, как показано на скриншоте ниже.

Откроется страница «Добавить тестовый прогон», где пользователь должен ввести Имя, Веха, Назначено, Описание, как показано на скриншоте ниже.

Теперь выберите тестовые случаи — есть 2 варианта

Включить все тестовые наборы — выберите этот параметр, чтобы включить все тестовые наборы в этот тестовый прогон. Если в репозиторий добавляются новые тестовые примеры, они также автоматически включаются в этот прогон.

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

Когда пользователь выбирает второй вариант, выполните следующие дополнительные действия

Нажмите на изменение выбора, как показано на скриншоте ниже

Теперь выберите тестовые случаи — есть 2 варианта

Включить все тестовые наборы — выберите этот параметр, чтобы включить все тестовые наборы в этот тестовый прогон. Если в репозиторий добавляются новые тестовые примеры, они также автоматически включаются в этот прогон.

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

Когда пользователь выбирает второй вариант, выполните следующие дополнительные действия

Нажмите на изменение выбора, как показано на скриншоте ниже

Откроется мастер выбора вариантов со всеми доступными тестами. Пользователь может выбрать весь раздел или конкретные тестовые примеры из каждого раздела, как показано на скриншоте ниже, и нажать OK, чтобы сделать выбор.

Откроется мастер выбора вариантов со всеми доступными тестами. Пользователь может выбрать весь раздел или конкретные тестовые примеры из каждого раздела, как показано на скриншоте ниже, и нажать OK, чтобы сделать выбор.

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

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

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

Тестовый забег

TestRail поддерживает следующие 5 статусов тестовых случаев

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

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

Неудачно — тестовый случай помечается как Неудачный, если один из указанных шагов теста приводит к ошибке или если ожидаемый результат отличается от фактического результата теста.

Повторное тестирование. Если тест необходимо повторить, отметьте его как «Повторное тестирование». Например, если тест изначально провалился и разработчик устранил проблему, разработчик может пометить его для повторного тестирования.

Заблокировано — состояние Заблокировано используется, чтобы указать, что тест не может быть выполнен в настоящее время из-за некоторой внешней зависимости (например, ошибка, которую необходимо исправить, прежде чем завершить тестирование).

Как только тестовый запуск завершен для тестового примера, статус тестового примера изменяется как один из вышеупомянутых. Снимок экрана показывает, как изменить статус теста после запуска

Теперь открывается мастер добавления результатов, в котором добавляются результаты и комментарии в качестве артефактов. Пользователь также может записать истекшее время, нажав на ссылку «Пуск» в поле «Истекшее время».

Источник

Тестовые прогоны и обработка признаков ошибок. Базовые проверки системы и процедура тестового прогона

Страницы работы

Фрагмент текста работы

5. Тестовые прогоны и обработка признаков ошибок

В данной главе описаны процедуры тестовых прогонов операций CPM1, функций самодиагностики и обработка признаков ошибок для идентификации и исправления аппаратных и программных ошибок, которые могут произойти при работе ПЛК.

5.1 Базовые проверки системы и процедура тестового прогона

5.1.1 Базовые проверки системы

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

Питание и подключение входов/выходов

Клеммы надежно зажаты?

Между наконечниками или проводами нет замыкания?

Все кабеля правильно подключены и закреплены?

5.1.2 Процедура тестового прогона CPM1

1. Подключение питания

a) проверьте напряжение питания и подключения клеммника CPM1.

b) проверьте напряжение питания и подключения клеммника устройств входа/выхода.

c) включите питание и проверьте, чтобы горел индикатор POWER.

d) Используйте программатор для установления CPM1 в режим PROGRAM.

2. Проверка подключения входов/выходов

a) В режиме CPM1 PROGRAM проверьте подключение выходов, принудительно включая и выключая выходные биты.

Подробности см. 4.3.22.

b) Проверьте подключение входов с помощью входных индикаторов или просмотра с программатора.

a) Используйте программатор для установки CPM1 в режим RUN или MONITOR и проверьте, горит ли индикатор RUN.

b) Проверьте последовательность операций путем принудительной установки/сброса битов и т. д.

Исправьте обнаруженные ошибки.

5. Сохранение программы

a) Используйте программатор для записи программы на дискету

b) Выведите на принтер бумажный экземпляр.

Подробности об использовании программатора и SSS см. гл. 4

5.1.3 Предосторожности при обращении с памятью FLASH

Для защиты памяти FLASH соблюдайте следующие меры предосторожности.

Данные изменения будут потеряны, если они не записаны в память FLASH и питание отключилось более, чем на 20 дней (при 25 0 С), поскольку конденсатор поддержки ОЗУ разряжается.

Данные изменения можно сохранить путем переключения CPM1 в режим RUN или MONITOR или включения CPM1 вскоре после сделанных изменений.

3. Если одна из трех следующих операций выполняется в режиме MONITOR или RUN, CPM1 увеличит время цикла до 600 мс и прерывания будут запрещены, пока программа или установочные параметры переписываются.

· Программа изменяется он-лайновыми опрециями.

Сообщение об ошибке SСAN TIME OVER (превышено время цикла) при данных операциях не появляется. При он-лайновых операциях они могут оказать влияние на время реакции на вход.

5.2 Цикл CPM1

Общий алгоритм работы СPM1 показан на схеме. Инициализаци CPM1 вызывается при включении питания. Если ошибок не обнаружено, последовательно (циклически) выполняеются операции диспетчеризации, исполнения программы, обновления входов/выходов и обслуживания периферийных устройств. Среднее время цикла можно наблюдать с программатора.

Процессы инициализации включают очистку областей IR, SR, и AR, установку системных таймеров и проверка блоков входов/выходов.

5.3 Функции самодиагностики

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

5.3.1 Нефатальные ошибки

Работа ПЛК и отработка программы продолжается после появления одного или нескольких признаков таких ошибок. Хотя работа ПЛК продолжается, причину неисправности нужно выявить и устранить как можно быстрее.

При появлении такой неисправности индикаторы POWER (СЕТЬ) и RUN (РАБОТА

Источник

Прочесть большую статью — сложно… Тестировать сложный продукт – легко

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

Лирическое вступление

Что такое петербургская осень? Дожди, Розенбаум, меланхолия… Разве всё?! Нет, ещё это новый учебный год, который во многих регионах нашей страны начался именно с Дневник.ру. За лето мы успели достичь определенных успехов: число пользователей проекта перевалило отметку в 7 000 000, мы стали единственной российской компанией, вошедшей в список «World Economic Forum Technology Pioneers 2014», а Республика Северная Осетия-Алания полностью перешла на электронные журналы с Дневник.ру. На этом лирическое вступление окончим и перейдем к сути данного поста.

Вступление по теме

В современной IT индустрии многие до сих пор удивляются: «зачем вообще нужен отдельный тестовый отдел?». Как один из участников тестовой команды нашего проекта, ответственно заявляю: это ошибочное мнение. Организовать отдел QA – дело нелегкое, но оно того стоит.
В этом случае для себя надо четко понимать:
— что считать критерием качества?
— какие метрики использовать?
— с помощью какого инструментария проводить тестирование?
— как строить взаимодействие с разработчиками/аналитиками и т.д.

По большому счету изобретать велосипед не стоит – данные практики описаны на миллионах интернет-страниц, успешно применяются во многих корпорациях, чей опыт можно перенять. Однако не нужно забывать простую истину – везде есть своя специфика. Например, в Дневник.ру это сильно-связанные между собой компоненты и CI (Continuous Integration), а попросту – высокий уровень интеграции связанных областей. Как лучше тестировать в этом случае?
Начнем с простого: любая информация никогда не сможет на 100% автоматически «всплывать» в вашей (бесспорно, очень умной) голове. QA-шникам в первую очередь необходимо запоминать и в дальнейшем прогонять тестовые сценарии, которые проверяются от релиза к релизу – «а не сломалось ли что?». Как мы все знаем – регрессионное тестирование. Но сейчас не об этом, про виды – welcome to protesting.ru (хороший, кстати говоря, ресурс).

Так вот, для написания и хранения тест-кейсов («Тест-кейс — артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части») можно использовать массу инструментов: Excel, блокнот, google-docs, листы бумаги, в конце концов. Но разве это эффективно и удобно? Для одного человека – может быть. Для команды, где статус проекта «надо было знать уже вчера» – определенно нет.

Подготовительные работы

Суммируя всё вышесказанное, требования к тулу были такими:

Итак, что рассматривали:

PS: предупреждая вопросы – HP Quality Center мы не рассматривали, потому что 1) неоправданно дорого 2) не очень он и «приветливый», особенно к тем, кто никогда не работал с тест-тулами, а писать свой – ресурсные затраты и нехватка времени…

Постараюсь уложиться в пару-тройку основных тезисов:

Microsoft Test Lab

Zephyr

Test Link

Testia Tarantula

Test Rail

На мой взгляд – один из самых легких, но в то же время очень масштабных существующих тулов. Главный плюс – кастомизация возможна практически во всём. Начиная от дизайна, заканчивая логикой. Прямая интеграция с JIRA. Эффективное занесение тест-кейсов и разбиение их по нужным сьютам. Как один из минусов – до недавнего времени у Test Rail была слабо реализована система отчетности: скудные результаты по тест-ранам, отсутствие кастомизации репортов и т.д. Однако Gurock & Co взялись за это дело и к 3-ей версии инструмента ребята сделали работу над ошибками. Отчетность заиграла новыми красками: хочешь – отчет по майлстоуну, хочешь – только по дефектам, хочешь – настроим регулярный е-мейл с посылкой отчета по тестированию строго определенного функционала и т.д. Молодцы! Итог – данный тул удовлетворял всем (!) моим требованиям, перечисленным немного выше.

Итого: наш выбор – внедрение Test Rail. Собственно говоря, что такое Test Rail?

• Это эффективное управление тест-кейсами, планами и тестовыми циклами (создание/хранение/редактирование тестовых сценариев, управление тестовыми планами, запуск тестовых циклов, занесение результатов тестирования)
• Это значительное повышение качества тестирования (четкое описание тестовых сценариев, их ревью, соотношение с требованиями, разделение на области — всё это позволяет оценить как полноту покрытия тестами функционала, так и является необходимым материалом для всей проектной команды)
• Это получение тестовых результатов в реальном времени (создание отчетов по совершенно разным критериям: Defect Summary, Comparison for Cases, тестовые результаты по проектам/компонентам/майлстоунам и т.д.)
• Это легкая организация и удобное отслеживание загрузки отдела тестирования (возможности для полной кастомизации «рабочего dashboard», а также удобное получение статуса работы QA отдела)

Внедрение

1. Поставили ТестРейл на виртуалку Windows Server 2008 R2 с базой MSSQL
2. Настроили AD аутентификацию
3. Настроили полноценную связь с JIRA

[connection]
address=http://jira/***
user=%jira_user%
password=%jira_password%

Ура. Теперь у каждого пользователя есть возможность в My Settings выставить логин/пароль от JIRA.

Далее в JIRA_Rest прописываем как связь непосредственно с установленной JIRA, так и впоследствии связи всех существующих у Вас JIRA fields: будь то основные поля, или кастомные (welcome to: docs.gurock.com/testrail-integration/tools-jira-rest).

Связи с основными полями (пример):
[push.fields]
summary=on
project=on
issuetype=on
component=on
assignee=on
priority=on
affects_version=on
fix_version=off
estimate=off
labels=off
environment=off
description=on

Связи с кастомными полями (пример):
[push.fields]
customfield_XXXXX=on

[push.field.customfield_XXXXX]
label=Customer
size=compact
type=dropdown
required=true

Как итог – при заведении бага можно смело воспользоваться инструментарием Test Rail, и при этом не тратить время на переход в соседнее окно с JIRA. Плюс ли? Вы знаете, при прогоне больших тестовых циклов и выставлении результатов тестирования – это несомненный плюс, так как те самые десятки секунд финально складываются в драгоценные минуты и просто-напросто удобство работы, что немаловажно.
И ещё: При генерации тестового репорта обычно мы выводим после результатов список известных дефектов, которые блокируют прохождение тест-кейса. Так вот, представьте себе такой список, и при наведении курсора на дефект в этом отчете всплывает попап с JIRA информацией о тикете – Summary, Description и т.д. Просто гениально! Всё сделано за вас.

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

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

Немного поподробнее: создаем тестовый сьют. Затем внутри него имеем возможность добавлять как секции, так и тест-кейсы внутри этих секций. Мы имеем возможность, не переходя к внутренней сущности кейса, составить шаблоны (= чек-лист/тест-план), вводя только Summary и нажимая Enter после ввода. Выглядит это так:

Это поле можно исправить на No, только написав сам тест-кейс в форме редактирования (необходимо просто поставить галочку «Only Title» = No).

Любые кастомные поля, которые Вы вводите, можно также вынести на дашборд как и все остальные, выбрав их в отображаемых колонках (нажатие «таблички» на основной странице написания тест-кейсов в строке с перечислением названий полей: ID, Title an so on).

5. Все внутренние поля тест-кейса также кастомизируемы

В изначальной конфигурации Test Rail представлен классический и безусловно необходимый набор внутренних полей тестового сценария: ID, Приоритет, Начальные Условия, Вид, Шаги, Ожидаемый Результат, Ссылка на требования или задачу Implementation в JIRA и т.д. Вы имеете право добавить любое поле и настроить его как вы хотите: будь то string, checkbox, dropdown – не важно. Всё в Ваших руках и головах! Что сделали мы:

— Добавили поле Data for test-case, в котором для теста из одного класса эквивалентности просто-напросто перечисляем какие-либо данные, с которыми тест должен быть выполнен. Это может быть все что угодно: начиная от ролей выполняющего, заканчивая перечислением строк ввода.

— Добавили поля ID Auto и Auto. ID Auto – уникальный ID для авто-теста. Auto – чекбокс Yes/No, который показывает автоматизирован ли тест-кейс или нет.

Сделано это для того, чтобы в дальнейшем при настраивании Test Rail для автоматизации можно было сразу использовать эти параметры для запуска необходимых авто-тестов и генерации по ним нужного отчета (http://www.gurock.com/testrail/tour/5/ — Automated tests and API).

6. Для любого test run можно выбрать абсолютно любой набор тест-кейсов

Test Rail позволяет создавать тестовые циклы по любым критериям. Это очень важная особенность инструмента, так как зачастую необходимо прогнать строго определенные сценарии (выбранные по приоритетам, по майлстоунам, по названию, по части названия, да как угодно на самом деле – все зависит от поставленных целей). Так вот, при назначении Test Run мы имеем возможность выбрать «свой» сьют по фильтру. Общий вид таков:

А вот, допустим, выбираем по названию, которое «равно или содержит что-то»:

При всем этом тестовый сьют может быть выбран для прогона полностью.

7. Настраиваемая репортинговая система

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

Заключение

Чек-листы, ad-hoc тестинг – это хорошо, однако, без четких процедур зачастую у продукта выявляются слабые места, которые со временем усиливаются и тянут компанию вниз. Имея как набор тест-кейсов, так и матрицу покрытия (хотя бы покомпонентно) – этого можно избежать.

Я перечислил далеко не все возможности TestRail и привел в пример лишь несколько вариантов его использования. Тем не менее, очевидно, что такая гибкая кастомизируемость позволит многим настроить данный инструмент под свой процесс разработки. Кроме прочего, тул позволяет совершенно прозрачно наблюдать за QA отделом, что, во-первых, избавляет всех от недосказанности «а что же они тестируют», а, во-вторых, налаживает четкое взаимодействие между командами и даёт понимание «зачем и как тестировать».

Выбирайте свой тул, тестируйте, контролируйте процесс! Удачи во всех начинаниях!

Автор статьи: Василий Петухов, руководитель отдела анализа и управления качеством Дневник.ру

Источник