Пример тест кейса на русском
Dating > Пример тест кейса на русском
Download links: → Пример тест кейса на русском → Пример тест кейса на русском
Такжеблок был опущен под кнопку «Добавить в корзину». Не следует забывать, что решение тест кейса особенно комплексного требует значительных затрат времени, как и обработка их итогов мы упоминали об этом выше. Тестирование: Длительность эксперимента — 2 недели. If youʼre not sure about how to enable cookies, please refer to our. Поправим тест-кейс по всем замечаниям. А тест-кейс - это в некотором роде инструкция. Your browser may also contain add-ons that send automated requests to our search engine. Профессиональная компетентность — уровень развития профессиональных качеств кандидата или сотрудника, необходимых для решения профессиональных задач, либо участия в проектах Предприятия в определённой роли, которые формируют комплексный подход к осуществлению профессиональной деятельности, непосредственно влияют на взаимодействие с коллегами и клиентами, соблюдение правил и норм, установленных на Предприятии. Можно ли подставлять во все 4 поля негативные данные одновременно по идеи валидация должна выскочить на каждом поле отдельно? Тест-кейсы копипастятся друг от друга, и часто в них остаются неактуальные части из исходного кейса, которые забыли изменить.
Тест-кейс — это проверка. Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть. Тест-кейс — это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик. Набор тест-кейсов называется тестовым набором test suite. Иногда этот набор некорректно называют тест-планом. Тест-план — это именно план: когда, что, зачем, какими ресурсами. Его удобно использовать для одинакового понимания, о какой проверке идет речь например, дать ссылку в баге. Должно помещаться в твиттер и быть понятным! Если предварительных шагов нет, то секция не заполняется. Тестовый стенд, на котором проверяются доработки перед выкладкой в PROD он же production, окружение для пользователей находится по другому адресу — www. Приводится здесь, чтобы показать ошибки в написании тест-кейсов. На сайте можно заводить карточки обслуживаемых зданий и карточки их жильцов. Создание жильца без ФИО. Преимущества и недостатки тест-кейсов Преимущества: тест-кейсы можно доверить выполнять новичку или призванному на помощь коллеге из другого отдела, который ничегошеньки о проекте не знает. Дополнительных вопросов с его стороны будет по минимуму — все и так должно быть понятно! Попробуйте написать хотя бы три тест-кейса на один функционал и сразу увидите эту проблему. Тест-кейсы копипастятся друг от друга, и часто в них остаются неактуальные части из исходного кейса, которые забыли изменить. Чтобы упростить этот процесс, могут быть использованы тест-кейсы с одним сценарием выполнения, но несколькими входными параметрами и разными ожидаемыми результатами. Фактически мы получаем мини чек-листы с предварительными шагами. См также: — перевод статьи John Andrews о преимуществах тест-кейсов. Примеры оформления несколько ожидаемых результатов Рассматриваем все тот же абстрактный сайт www. Несколько вариантов вводимых данных Для этого варианта тест-кейса запись в виде таблички: данные — результат — наше всё! Результаты для нескольких шагов из кейса Другой вариант записи тест-кейса с несколькими ожидаемыми результатами — когда результаты пишутся на разные пункты шагов выполнения проверки, то есть на разные этапы сценария. Создание жильца с худым полным ФИО. Вход в систему успешно осуществлен. Открыта главная страница сайта. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Здесь надо тестировать очень аккуратно и тщательно. Время, потраченное на создание и поддержку тест-кейсов никогда не окупится. Познакомьтесь со своей системой и потом уже решайте, что подходит именно для нее — творческие чек-листы, формальные тест-кейсы или микс из этих подходов. Стандартные ошибки при оформлении тест-кейсов Читать теорию - одно, делать на практике - другое. Ожидаемый результат — карточка создана. Попробуйте, не смотря ответ, сами найти проблемные зоны в этом тест-кейсе. А потом проверите себя Разберем ошибки кейса 01. Абстрактное название На первый взгляд название хорошее, короткое и понятное — мы ведь правда создаем жильца. Если мы теперь создадим еще пяток тест-кейсов на ввод некорректных ФИО, то у них будет точно такое же название. В итоге новый тестировщик, получив задание проверить кейс «Создание жильца», обнаружит в системе два десятка проверок с таким названием и впадет в ступор, какой выбирать? По названию тест-кейса тестировщик, знающий проект, должен понять, что надо делать, не заглядывая в шаги. PROD В данном примере идет ссылка на PROD. Никогда нельзя проводить тестирование на PROD-е! Исключение составляет дымовой тест, проводящийся после обновления PROD-системы. Тестовый набор для этого создается отдельно и тщательно выверяется. ВСЕ остальное тестирование проводится ТОЛЬКО на тестовом стенде. В описании тест-кейсов и багов должны быть ссылки только на тестовый сервер. Иначе попросим коллегу с другого проекта помочь нам с тестированием, а он пойдет на PROD и... Нет ссылки на сайт Написан URL, но не кликабельный. Нужно выделить, скопировать, открыть новую страницу, вставить... Гораздо лучше было бы просто нажать на него! Если кнопка в новой версии программы переедет в другое место, то придется вносить исправление и в тест-кейс. Чем меньше в документации зависимость от UI user interface, пользовательский интерфейс , тем лучше. Если вместо кнопки сделают ссылку или человек просто Enter нажмет, то суть шага не изменится: мы же в данном кейсе не логин проверяем, а создание жильца. Увидев этот пункт, я пойду искать кого-нибудь, кто в курсе, есть ли тестовый пользователь с такими правами и какие у него логин и пароль. Тест-кейсы составляются тогда, когда нужно, чтобы любой человек со стороны, не знающий проекта, мог присоединиться и помочь, выполнить тест-кейсы. Не задавая коллегам при этом дополнительные вопросы. Тест-кейс я должна уметь выполнять, впервые увидев проект, там должна быть ВСЯ нужная мне информация. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт. Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять? Поправим тест-кейс по всем замечаниям. Создание жильца с корректными ФИО. Уже хорошо, но можно ли еще улучшить этот тест-кейс? Сейчас снова попробуйте, не смотря ответ, найти проблемные зоны в этом тест-кейсе. А потом проверите себя Итак, ошибки кейса 02: 1. Таких слов надо избегать. Позитивных проверок можно придумать хоть сто. Но чем-то они будут различаться. «Создание жильца, у которого нет отчества», — это тоже кейс с корректным ФИО. Только из такого названия сразу ясно, про что кейс. А разделение кейсов на смысловые группы негативные тесты, позитивные тесты, тесты на особые случаи сделайте в системе управления тест-кейсами через флаги или отдельные наборы тестов. Нет нужной информации Зайти на сайт www. Как мне туда попасть? Создание жильца с полным ФИО. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть. Определения из книг по тестированию Ron Patton. Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software. Тест-кейсы перечисляют конкретные вещи, которые будут протестированы, и описывают детальные шаги, которые необходимо выполнить для проверки программного обеспечения. The purpose of the test case specification is to specify in detail each test case listed in the test design specification. Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. На этом, пожалуй, все PS - Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению! Абстрактные названия тесткейсов - настоящая головная боль, которую я часто сам себе устраиваю... Как мне туда попасть? Это практически пример из моей жизни, когда на лицо не недостаток информации, а ввод в заблуждение. Зайти на сайт www. По опыту скажу, если бы я увидел пустую форму и не знал бы что ввести - через 10 секунд я был бы уже у автора тест-кейса.... Тогда не нужно объяснять, что это просто пример, а не новый сайт для тестировщиков. Повелительное наклонение больше подходит для инструкций. А тест-кейс - это в некотором роде инструкция. Обьясните пожалуйста, если Вам не трудно. После прочтения возникают непонятки. Баг Репорт - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. В него входит айди, самари, северити, приоритет, статус, шаги по воспроизведению, ожидаемый и фактические результаты, атачмент. Тест кейс — это самая маленькая часть тест документации, это ситуация которая проверяет конкретно взятое условие из требований. В него входит:айди, самари, степс, ожидаемый и фактический результат, статус Как я понимаю, мы берем спецификацию и проверяем например поле для ввода с помощью тест кейса, находим баг и заносим его в баг репорт, правильно? Появился еще один интересный вопрос: 1. Я исполнил тест кейс и нашел баг 2. Занес его в баг-репорт 3. Программист его исправил и теперь мне как тестировщику надо провести регресивное тестирование этого бага. Дальше возникает вопрос: Мне нужно проводить повторное тестирование по шагам из тест-кейса или из баг-репорта? Или шаги в них получается должны быть одинаковыми? Айди тест кейса и баг репорта должны быть одинаковыми? Такой вопрос - какой должен быть тест кейс для фильтра значений? Например - в поле ввода пользователь вводит строку и на выходе должны быть все те значения, в которых есть эта строка. По идее у нас две тестовых ситуации - строка, которая входит в какое-либо значение и мы проверяем что это значение верное, и негативный тест где строка не входит и тогда значений будет ноль. Но нужно ли проверять на разные типы данных? Или на разное количество выходных данных? Сколько тогда должно быть тест кейсов? Убираем чекбоксы - уменьшается параметр и наоборот. Сколько в этом случае должно быть проверок? Отметить все чекбоксы и убирать по одному и проверять параметр, а потом убрать все чекбоксы и добавлять по одному параметру? Крайних значений тут нет, а по комбинаторике возможных комбинаций может быть очень много. Не очень поняла по поводу других классов эквивалентности. То есть на примере выше: если ввести такую строку, при которой будет один результат, то он и выведется... Или вы имеете в виду тестировать границы количества результатов? Сколько может вывестись максимум, сколько минимум, чуть выше, чуть ниже? По поводу чекбоксов - вопрос взялся из попытки обучения протестировать интерфейс. Например в интернет магазине можно просто ввести название предмета, а можно при этом в чекбоксах отметить нужные параметры. Соответственно количество результатов уменьшится. Но как тестировать подобное? Отметок-чекбоксов может быть много... Каждую тестировать по отдельности? Анонимный Ольга, вопрос по тестированию регистрации, помогите разобраться, пожалуйста. Пишу тест-кейс, хочу проверить регистрацию с именем на кирилице, на латинице. Когда в реальности этот кейс начнут выполнять живые люди, то его сможет пройти только первый человек, второму не зарегистрироваться под указанным логином и с указанной почтой, они будут заняты первым прошедшим кейс. Предполагаю, что нужно придумать некую формулу, которая будет отличаться номером выполняющего кейс, например, для первого логин login1 почта login1 ya. А как на практике тестируется форма регистрации? Добрый день Подскажите,нужно протестировать форму отправки сообщения из 4-х полей: Имя, Ном. Набор позитивных и негативных данных для каждого поля составлен. Номер тел:позитивные: 1 10 цифр; негативные: 1 пустое значение; 2 длина меньше мин. Тест-кейс позитивный: Название: Тест отправки сообщения Функция: Контакт-Вопросы Шаги 1. Заполнить поля формы: «Имя»: Ия «Номер телефона»: 0502621058 «Еmail»: 7cncncncncncncnccnnccncncncncncccnccncncnc. Нажать кнопку «Отправить» ОР: - страница «Ваш запрос успешно отправлен» открыта негативный тест кейс: Название: Тест отправки сообщения Функция: Контакт-Вопросы Шаги: 1. Заполнить поля форы: «Имя»: р «Номер телефона»: 050987654 «Еmail»: fjjfjfjfjfjfjfjfjfjfjjfjfjfjodododododooddoododododoofufusuusususususu «Примечание»: ркркркрармаомщшаопрпоппалплпопопопопоопопоопопопоопопоопопопопоопопопоопопопопоопопопоппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппопопопопопоппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппппрапарараааааа ОР: - поля заполнены - кнопка «Отправить» активна 3. Нажать кнопку «Отправить» ОР: - Валидационное сообщение со всеми ошибками выведено на экран: - «Поле «Имя» обязательное для заполнения» - «Поле «Номер телефона» обязательное для заполнения» - «Поле «Email» обязательное для заполнения» - «В поле «Примечание» мах длина поля — 255 символов» Вопросы: 1. Заранее спасибо большое за ответ. Как назвать позитивные тест кейсы их будет несколько ,если значения подставлены в каждое из 4-х полей, а не в одно. Можно ли подставлять во все 4 поля негативные данные одновременно по идеи валидация должна выскочить на каждом поле отдельно? Валидация выскочит когда будут введены данные или когда будет нажать кнопка отправить? Можно написать один тест-кейс с ОР на каждый шаг, а можно 5. Но, если вы пишщите ОР на каждый шаг, пишите внятно — сделайте табличку. Так, чтобы результат был напротив шага. Можно сделать один базовый позитивный тест, а потом рассматривать каждое поле в отдельности. Запихивать вот эту строку в название тест-кейса не стоит Нечитаемо получится. Вообще я бы сделала чек-лист, у вас точно просят тест-кейсы? Если сгруппировать негативные проверки — как вы узнаете, какая из них сработала? Может, работает только 1 из 3, но вы проверили все три разом, увидели ошибку и успокоились : Но вообще я не за этим заглянуло. Относительно форм в команде возникла полемика. Другие считают что поля формы следует описывать в тест-кейсе, то есть это и есть наш кейс, где мы проверяем что форма такая как мы хотели. Что вы думаете на этот счет? Потому что как принято на проекте, так и делаем. Я за то, чтобы были чек-листы + тест-кейсы только на сложные случаи. Тогда и проблем таких не будет, пару раз проще название кнопки написать, чем выносить отдельно, ибо бессмысленно становится.
Last updated
