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

После успешной авторизации пользователь должен увидеть сообщение «Всё окей». В случае неудачной авторизации пользователь должен увидеть сообщение «Извини, не в этот раз».

Комментарии к спеку:

· не указано в спеке до 20 символов в поле ввода электронной почты и пароля: включительно или нет? (я взял не включительно, то есть максимум 19 символов);

· не указано минимально допустимое количество символов в поле ввода электронной почты и пароля (создал тест-кейс для тестирования пустых полей ввода);

· не указано какие символы допустимы в пароле;

· не указано название сайта (я принял его за «example.ru»);

· не указаны координаты расположения формы авторизации на веб-странице;

· при необходимости можно дополнить тест-комплект тест-кейсами на проверку клавиш «Backspace» и «Escape».

Среда выполнения: Google Chrome 41.0.2272.101 m.

Тестируемый компонент: Авторизация на сайте

Источник

Test Suite — удобный инструмент автоматического тестирования

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

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

Чтобы сделать выбор в сторону автоматизации, следует разобраться в ее плюсах и минусах.

Преимущества, которые дает тестировщику автоматизация:

Автоматизация тестирования с помощью RPA

Роботизация бизнес-процессов (RPA) интенсивно развивается и, в силу сходства бизнес задач и подходов, может быть полезной в автоматизации тестирования и разработки. При том, что по миру сейчас процент покрытия автоматизированным тестированием в среднем не больше 30%, применение гибких и простых инструментов, таких как RPA, может помочь его поднять до приемлемых величин (считается, что хорошим процентом покрытия для автоматизации тестирования является 60-70%).

Частые изменения экосистемы приложения

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

Современные решения, такие как UiPath RPA позволяют частично эту проблему снять за счет применения “умного” захвата элементов UI, понимающего, что внешний вид приложения или структура может, в определенных пределах, меняться; и репозитория объектов, который позволяет централизованно управлять таксономией UI элементов.

Недостаточно знаний бизнеса

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

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

Отсутствие тестовых данных и сред

Это большая проблема: для того чтобы сделать хороший тест нужно иметь реальные данные. В свою очередь для этого нужно работать с живой системой, в которой ничего нельзя менять. Нельзя в действующем электронном магазине купить товаров на 100 тысяч, так как собьется вся статистика. Теоретически у тестировщика для работы должен быть тестовый магазин-двойник с теми же самыми данными, но, к сожалению, реализовать подобное очень сложно и, зачастую, непосильно дорого. Для банковских систем эта проблема еще более актуальна и в этой сфере еще меньше реальных тестовых данных.

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

Наличие user friendly инструментов автоматизации

Инструмент для автоматизации тестирования должен быть гибким и легким в освоении, это снижает порог вхождения и позволяет большему количеству сотрудников создавать тесты. Платформа UiPath дружественна к пользователю и наличие онлайн академии, форума, telegram-сообщества в России и т.д. позволяет быстро обучаться. Освоение инструментария UiPath до уровня, необходимого для создания хороших кейсов, намного проще, чем обучение хардкорным вещам типа Selenium. При этом для тех, кто уже уверенно владеет подобными инструментами, изучение UiPath не составит никакой сложности.

На рынке сегодня существует потребность в инструменте, который облегчил бы тестировщикам и инженерам по автоматизации работу с вышеупомянутыми пробелами. Решение Test Suite призвано сделать тестирование и его автоматизацию интуитивно понятными и простыми в обслуживании, так, чтобы у компаний не было больших расходов.

Преимущества Test Suite

Один инструмент для RPA и автоматизации тестирования

Платформа UiPath многофункциональна, совмещает в себе возможности для роботизации и автоматизации тестирования. Это позволяет обмениваться артефактами автоматизации, созданными во всей организации. Кроме того, в рамках тестового пространства платформа способна интегрироваться и работать более чем со 190 технологиями, что значительно облегчает ее внедрение.

Замена устаревших систем на современные

В любой большой экосистеме предприятия или организации функционирует большое количество разных приложений. Совершенно обычна ситуация, когда рядом работают приложения, выпущенные в 90-м году и в 2020, веб-сайты на разных движках и мобильные приложения на разных технологиях. Проблема «зоопарка систем» при тестировании заключается в том, что определенный инструмент подходит для тестирования одного-трех приложений, но не всех сразу. Есть приложения, которые хорошо тестируют веб-сайты и совсем не умеют работать с «толстым» клиентом. Test Suite позволяет создавать единую экосистему и эффективно тестировать ПО различных категорий и версий. В Test Suite можно одновременно тестировать мобильное приложение и веб-ресурсы и не переключаться между большим количеством разных окон.

Минимальные знания программирования

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

Оркестровка корпоративного уровня

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

Test Suite хорошо интегрируется с CI/CD, в нем есть готовые коннекторы к большинству основных платформ issue tracking, плагины к Jira и SAP Solution Manager.

Простота создания и обслуживания

Решение для тестирования UiPath демонстрирует не только простоту использования, но и снижает затраты на техническое обслуживание. Некоторые из клиентов UiPath уже сообщили о двукратном увеличении тестового покрытия с помощью Test Suite.

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

Источник

Сценарии для тестирования Login формы

Хотелось бы узнать, а какие ещё сценарии, можно придумать для тестирование Login формы на рисунке

кроме таких что первыми идут в голову:

Проверить заполение обязательных полей.
Ввод корректного логина и корректного пароля.
Проверка на ‘Remember me on this computer’.
Ввод корректного логина и некорректного пароля
Ввод некорректного логина и корректного пароля
Ввод некорректного логина и некорректного пароля

Прикрепленные файлы

Хотелось бы узнать, а какие ещё сценарии, можно придумать для тестирование Login формы на рисунке

кроме таких что первыми идут в голову:

Проверить заполение обязательных полей.
Ввод корректного логина и корректного пароля.
Проверка на ‘Remember me on this computer’.
Ввод корректного логина и некорректного пароля
Ввод некорректного логина и корректного пароля
Ввод некорректного логина и некорректного пароля

Есть ли ограничение на длину (логина, пароля) при регистрации?

Есть ли ограничения на допустимые символы (в пароле, имени) при регистрации?

Классный сценарий, но юзать это будут америкосы так что ни о какой кириллице и т.п речи и не может быть

Это ввод несуществующего пользователя типа есть пользователь root c паролем 1111, а мы пытаемся зайти под rot (которого нет в базе) с паролем 1111

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

Что будет при попытке залогиниться с использованием имени/пароля недавно удаленного пользователя?
.

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

.
А вообщем спасибо =) некоторые мысли в голову пришли

Вот еще на подумать.

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

А зачем гонять трафик когда в запросе очевидные невалидные данные?
А правда, что ваша фамилия drop table students? (судя по всему это веб-приложение)
А если это веб, то.
Вообще, странный топик. Нагуглить тестов не составляет никакого труда, это одна из распространенных задач на собеседованиях
например http://www.allinterv. swers/6392.html

Действительно это веб-приложение.

Был бы я тоже гуру, я б тоже посчитал такой пост странным. Я думал что эта тема с бородой и 100% должна была б быть в этом, но к сожалению я не нашёл.
Как Вы сказали что это одна из распростаненных задач на собеседованиях, ну может так оно и есть (меня на собеседованиях про это не спрашивали), но не только для собеседованиях,
но и на реальных проектах.

Я гуглил по ‘тестирование Login form’, но в очередной раз убедился что по таким вопросам лучше искать в англоязычных сайтах.

А сценарии нужны для написание тест кейсов.

Я понимаю что случаев можно придумать очень много, но не будет же QA целый день тестировать именно login форму

Был бы я тоже гуру, я б тоже посчитал такой пост странным. Я думал что эта тема с бородой и 100% должна была б быть в этом, но к сожалению я не нашёл.

Я гуглил по ‘тестирование Login form’, но в очередной раз убедился что по таким вопросам лучше искать в англоязычных сайтах.

Я понимаю что случаев можно придумать очень много, но не будет же QA целый день тестировать именно login форму

Напишите 1000 (вроде бы) сообщений на форуме и станете гуру. Обычно тут не бывает подобных тем, т.к. форум существует не для обмена тест-кейсами.

гуглить лучше на английском языке, например login test cases

Будет и два, и три дня тестировать, столько, сколько нужно.

Был я на одном проекте таком на котором было 5000 тест кейсов, их филлипинцы писали, они же были заказчиками или посредниками, так вот мы по этим тест кейсам они находили максимум 2-3 незначительных бага, наша команда находила 20-30 багов

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

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

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

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.

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

Вот вот и я об этом, что нужно выбирать что тестировать.

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

Был я на одном проекте таком на котором было 5000 тест кейсов, их филлипинцы писали, они же были заказчиками или посредниками, так вот мы по этим тест кейсам они находили максимум 2-3 незначительных бага, наша команда находила 20-30 багов

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

Источник

Гибкая система тестирования и сбора метрик программ на примере LLVM test-suite

Введение

Большинство разработчиков однозначно слышали о довольно значимых open-source разработках таких, как система LLVM и компилятор clang. Однако LLVM сейчас не только непосредственно сама система для создания компиляторов, но уже и большая экосистема, включающая в себя множество проектов для решения различных задач, возникающих в процессе любого этапа создания компилятора (обычно у каждого такого проекта существует свой отдельный репозиторий). Часть инфраструктуры естественно включает в себя средства для тестирования и бенчмаркинга, т.к. при разработке компилятора его эффективность является очень важным показателем. Одним из таких отдельных проектов тестовой инфраструктуры LLVM является test-suite (официальная документация).

LLVM test-suite

При первом беглом взгляде на репозиторий test-suite кажется, что это просто набор бенчмарков на C/C++, но это не совсем так. Помимо исходного кода программ, на которых будут производиться измерения производительности, test-suite включает гибкую инфраструктуру для их построения, запуска и сбора метрик. По умолчанию он собирает следующие метрики: время компиляции, время исполнения, время линковки, размер кода (по секциям).

Test-suite естественно полезен при тестировании и бенчмаркинге компиляторов, но также он может быть использован для некоторых других исследовательских задач, где необходима некоторая база кода на C/C++. Те, кто когда-то предпринимал попытки сделать что-то в области анализа данных, думаю, сталкивались с проблемой недостатка и разрозненности исходных данных. А test-suite хоть и не состоит из огромного количества приложений, но имеет унифицированный механизм сбора данных. Добавлять собственные приложения в набор, собирать метрики, необходимые именно Вашей задаче, очень просто. Поэтому, на мой взгляд, test-suite (помимо основной задачи тестирования и бенчмаркинга) — хороший вариант для базового проекта, на основе которого можно строить свой сбор данных для задач, где нужно анализировать некоторые особенности программного кода или некоторые характеристики программ.

Структура LLVM test-suite

Структура простая и понятная.

Принцип работы

Как видно за всю работу по описанию сборки, запуска и сбора метрик отвечают CMake и специальный формат lit-тестов.

Если рассматривать очень абстрактно, понятно, что процесс бенчмаркинга с помощью это системы выглядит просто и весьма предсказуемо:

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

1. Построение тестовых приложений.

В качестве билд-системы используется ставший уже фактически стандартом для программ на C/C++ CMake. CMake производит конфигурацию проекта и генерирует в зависимости от предпочтений пользователя файлы make, ninja и т.д. для непосредственного построения.
Однако в test-suite CMake генерирует не только правила, как собрать приложения, но и производит конфигурацию самих тестов.

Но так как данный файл генерируется автоматически, то именно в файле CMake для бенчмарка описывается: как получить объектные файлы, как их собрать в приложение, а потом еще и что с этим приложением нужно делать.

Для лучшего понимания поведения по умолчанию и того, как же это описывается, рассмотрим пример некоторого CMakeLists.txt

Флаги могут устанавливаться в зависимости от платформы, в test-suite cmake modules входит файл DetectArchitecture, который определяет целевую платформу, на которой запускаются бенчмарки, поэтому просто можно использовать уже собранные данные. Также доступны и другие данные: операционная система, порядок байтов и т.д.

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

Есть 2 базовых макроса llvm_multisource и llvm_singlesource, которых для большинства тривиальных случаев хватает.

Если Вас это устраивает, это просто замечательно, Вам хватит одной дополнительной строчки (вызова llvm_multisource или llvm_singlesource), чтобы запустить приложение и получить следующие метрики: размер кода (по секциям), время компиляции, время линковки, время исполнения.

Но, естественно, редко бывает все так гладко. Вам может потребоваться изменить одну или несколько стадий. И это возможно тоже с помощью простых действий. Единственное, нужно помнить, что, если переопределяете некоторую стадию, нужно описать и все остальные (даже если алгоритм их работы по умолчанию устраивает, что, конечно, немного огорчает).

В API существуют макросы для описания действий на каждой стадии.

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

Что может понадобиться в секции запуска? Самый предсказуемый случай – приложение принимает некоторые аргументы, входные файлы. Для этого есть макрос llvm_test_run, который принимает только аргументы запуска приложения (без имени исполняемого файла) в качестве параметров.

Для изменения действий на этапе проверки корректности используется макрос llvm_test_verify, который принимает любые команды в качестве параметров. Конечно, для проверки корректности лучше использовать инструменты, включенные в папку tools. Они предоставляют неплохие возможности для сравнения сгенерированного выхода с ожидаемым (существует отдельная обработка для сравнения вещественных чисел с некоторой погрешностью и т.п.). Но можно где-то и просто проверить, что приложение завершилось успешно и т.д.

А что, если есть необходимость собирать некоторые дополнительные метрики? Для этого существует макрос llvm_test_metric.

Например, для dhrystone можно получить специфичную для него метрику.

Конечно, если нужно собрать для всех тестов дополнительные метрики данный способ несколько неудобен. Нужно либо добавлять вызов llvm_test_metric в высокоуровневые макросы, предоставляемые интерфейсом, либо можно использовать TEST_SUITE_RUN_UNDER (переменную CMake) и специфичный скрипт для сбора метрик. Переменная TEST_SUITE_RUN_UNDER довольна полезна, и может быть использована, например, для запуска на симуляторах и т.п. По сути в нее записывается команда, которая примет на вход приложение с его аргументами.

В итоге же получаем некоторый CMakeLists.txt вида

Интеграция не требует дополнительных усилий, если приложение уже собирается с помощью CMake, то в CMakeList.txt в test-suite можно включить уже существующий CMake для сборки и дописать несколько простых вызовов макросов.

В результате своей работы CMake сгенерировал специальный тестовый файл по заданному описанию. Но как этот файл выполняется?

lit всегда использует некоторый конфигурационный файл lit.cfg, который, соответственно, существует и в test-suite. В данном конфигурационном файле указываются различные настройки для запуска тестов, в том числе задается формат исполняемых тестов. Test-suite использует свой формат, который находится в папке litsupport.

Данный формат описан в виде класса теста, унаследованного от стандартного lit-теста и переопределяющий основной метод интерфейса execute. Также важными компонентами litsupport является класс с описанием плана выполнения теста TestPlan, который хранит все команды, которые должны быть выполнены на разных стадиях и знает порядок стадий. Для предоставления необходимой гибкости в архитектуру также внесены модули, которые должны предоставлять метод mutatePlan, внутри которого они могут изменять план тестирования, как раз и внося описание сбора нужных метрик, добавляя дополнительные команды для измерения времени к запуску приложения и т.д. За счет подобного решения архитектура хорошо расширяется.

Примерная схема работы test-suite теста (за исключением деталей в виде классов TestContext, различных конфигураций lit и самих тестов и т.д.) представлена ниже.

Lit вызывает выполнение указанного в конфигурационном файле типа теста. TestSuiteTest парсит сгенерированный CMake тестовый файл, получая описание основных стадий. Затем вызываются все найденные модули для изменения текущего плана тестирования, запуск инструментируется. Потом полученные тестовый план исполняется: выполняются по порядку стадии подготовки, запуска, проверки корректности. При наличии необходимости может быть выполнено профилирование (добавляемое одним из модулей, если при конфигурации устанавливалась переменная, показывающая необходимость профилирования). Следующим шагом собираются метрики, функции для сбора которых были добавлены стандартными модулями в поле metric_collectors в TestPlan, а затем происходит сбор дополнительных метрик, описанных пользователем в CMake.

3. Запуск test-suite

Запуск test-suite возможен двумя способами:

Результаты от разных запусков можно сравнить и без LNT (хотя данный фреймворк предоставляет большие возможности для анализа информации с помощью разных инструментов, но он нуждается в отдельном обзоре), воспользовавшись скриптом, входящим в test-suite

Источник