Как сделать сценарий тестирования

Обновлено: 04.07.2024

Тестирование программного обеспечения - сценарии использования

• Основные элементы тестовых случаев
• Метод разработки тестового примера
  • Метод проектирования на основе спроса
  • Класс эквивалентности
  • Граничное значение
  • Диаграмма причин и следствий
  • Ортогональное расположение
  • Дизайн сцены
  • Неправильное предположение

  Основные элементы тестовых случаев

  Концепция регрессионного тестирования: Тестовый пример - это набор коллекций, предоставляемых тестируемой системе с целью реализации теста.Этот набор коллекций содержит такие элементы, как тестовая среда, этапы работы, тестовые данные и ожидаемые результаты.(Хорошим тестовым примером является то, что человек, не знакомый с бизнесом, может быстро протестировать в соответствии с вариантом использования)

  Критерии оценки тестовых случаев:

  Преимущества тестовых примеров

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

  Методика разработки тестового примера

  Дизайн на основе спроса
  RBT - это метод тестирования, основанный на требованиях, который сделает тестирование более эффективным, поскольку фокусируется на основной причине проблем с качеством, а именно спрос 。

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

  Конкретный метод проектирования

  Класс эквивалентности

  Идея: концентрация входных данных бесконечна и не может быть покрыта

  • Согласно требованиям, вход (в особых случаях будет рассматриваться выход) делится на несколько классов эквивалентности, и из классов эквивалентности выбирается тестовый пример.Если тестовый пример проходит тест, эквивалентный класс, представленный тестом, считается пройденным. Итак, вы можете использоватьМеньше тестовых примеров для достижения максимально возможного многофункционального покрытия, решая проблему неполного охвата。
    • Эффективный класс эквивалентности：Набор разумных и значимых входных данных для спецификации программы, Используйте эффективный класс эквивалентности, чтобы проверить, реализуются ли функции и характеристики, указанные в спецификации.
    • Недопустимый класс эквивалентности: согласно спецификации требования коллекция, не соответствующая требованию.

    Граничное значение

    Метод анализа граничных значений: Метод тестирования черного ящика для проверки граничного значения ввода и вывода , Метод анализа граничных значенийВ качестве дополнения к методу разделения классов эквивалентности, В данном случае его тестовый примерГраница из класса эквивалентности。
    eg:

    Диаграмма причин и следствий

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

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

      Ортогональное расположение

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

      • На практике это не распространено, научные эксперименты важнее, На практике мы посмотрим на код или представим возможный код для сокращения случаев использования. 。

      Дизайн сцены

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

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

      Неправильное предположение

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

      Действительность тестовых случаев

      Детализация и оценка тестовых случаев

      Гранулярность: относится к уровню детализации написания тестового примера.
      Основные соображения могут относиться к следующему:

      • Требования к качеству продукции
      • Требования к проекту для вариантов использования
      • Достаточное время и ресурсы для тестирования
        Но каким бы упрощенным ни был вариант использования, его нельзя опускать.

      Оценка тестовых случаев

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

      • Экспертная оценка
      • Проверка пользователя
      • Обзор команды проекта

      Случай интервью

      
      

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

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

      В этой статье описывается дизайн тестовых случаев и важность различных частей.

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

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

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

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

      Запись тестовых примеров

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

      • Тестовый кейс должен иметь ожидаемый результат.
        В нашем тестовом случае ожидаемым результатом было бы успешное вход в систему.
        Если мы не предопределим ожидаемые результаты, мы можем пропустить небольшие различия в расчетах. Результаты могут выглядеть хорошо, но на самом деле они ошибочны. Например, если мы рассчитаем зарплату, могут быть только незначительные различия. Если мы заранее определим ожидаемый результат, то увидим отклонения в тесте. Предположим, создатель тестового примера покинул организацию, и теперь нам нужно запустить тестовый пример. Тогда это помогает, если контрольный пример задокументирован.
      • Тестовый случай может иметь Предварительные условия, например, определенные значения в базе данных, которые должны присутствовать заранее. Для этого теста, имя пользователя / пароль должны быть введены заранее.
      • Тестовый набор также может включать в себя условия после завершения теста, которые применяются после его завершения. Для этого тестового случая было бы условием публикации, что дата и время входа в систему хранятся в базе данных. Нам также необходимо сохранить статус входа в систему, чтобы работать с приложением.
      • Во время выполнения контрольного примера мы документируем результаты, полученные в столбце фактических результатов.

      Проектирование тестовых примеров

      Формат для теста входа в систему содержит следующий формат:

      1. Идентификатор теста
      2. Часть тестового сценария.
      3. Тестовые шаги должны быть выполнены.
      4. Тестовые данные.
      5. Ожидаемые результаты.
      6. Актуальные результаты.
      7. Результат теста (успешный или нет).

      При подготовке тестового примера нам нужна следующая информация:

      Лучшие практики для хороших тестовых случаев

      1. Контрольные примеры должны быть простыми и прозрачными

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

      Используйте напористый язык, например, перейдите на домашнюю страницу, введите информацию, щелкните по ней и так далее. Это упрощает понимание этапов тестирования и ускоряет выполнение тестов.

      2. Создайте контрольные примеры с учетом конечного пользователя

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

      3. Избегайте повторения тестовых случаев

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

      4. Не оставляйте доставленное приложение

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

      5. Обеспечить покрытие 100%

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

      6. Контрольные примеры должны быть идентифицируемыми

      Назовите идентификатор тестового примера, чтобы мы могли легко его идентифицировать. Это полезно для отладки или определения требования на более позднем этапе.

      7. Повторяемость и автономность

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

      8. Обзор коллегиального обзора

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

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

      11.1. Тест-планы

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

      На основании тест-требований составляются тест-планы - программы испытаний (проверки, тестирования) программной реализации системы. В отличие от тест-требований в тест-плане описываются конкретные способы проверки функциональности системы, т.е. то, как должна проверяться функциональность. Как правило, тест-план состоит из отдельных тестовых примеров, каждый из которых проверяет некоторую функцию или набор функций системы. Для каждого тестового примера однозначно определяется критерий успешного прохождения ( pass/fail criteria ), при помощи которого можно судить - соответствует ли поведение системы заданному в требованиях или нет (Рис 11.1).

      
      

      Критерием качества тест-плана является покрытие (выполнение) всех требований к проверке правильности функционирования программной реализации. Желательной характеристикой тест-плана является проверка исполнения всех веток схемы программной реализации.

      Структура тест-плана может соответствовать структуре тест-требований или следовать логике внешнего поведения системы. Каждый пункт тест-плана описывает, как производится проверка правильности функционирования программной реализации, и содержит:

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

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

      11.1.2. Возможные формы подготовки тест-планов

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

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

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

      11.1.3. Сценарии

      Представление сценариев, удобное для ручного тестирования - тест-план в виде текстового документа, в котором каждый тестовый пример представляет один раздел. Для каждого тестового примера в этот документ записывается следующая информация:

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

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

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

      Степень приемлемости здесь будет зависеть от терпеливости тестировщика, и обеспечить повторяемость тестирования будет затруднительно. Более удачной формой описания той же самой ожидаемой реакции будет

      Ниже приведен пример описания тестового примера в виде сценария, предназначенного для ручного тестирования :

      Как можно видеть, такая форма представления действительно неудобна для автоматизации тестирования и предназначена исключительно для ручного тестирования . Иногда такие тест-планы совмещают с отчетами о проведении тестирования, добавляя в таблицу описания сценария третью и четвертые колонки - "Реальный результат" и "Соответствует", в который заносятся реальная реакция системы и указание на совпадение/несовпадение результатов соответственно. В конце описания каждого тестового примера добавляется графа "Пройден/не пройден", в которую заносится информация о том, пройден ли тестовый пример в целом. В конце всего тест-плана, совмещенного с отчетом, помещается графа "Тестовых примеров пройдено/всего", в которую заносится число пройденных тестовых примеров и общее их число.

      Сценарии тестирования для автоматического тестирования часто описывают на том или ином языке программирования. Например, методы в тестирующих классах Microsoft Visual Studio Team Edition представляют собой именно пошаговые описания действий, которые необходимо выполнить тестовому окружению для проведения тестирования. Возможна и более близкая к естественному языку форма подготовки тестовых примеров. Например, при тестировании логической функции с уровнем покрытия MC/DC и описании тестовых примеров на одном из диалектов Visual Basic Script возможно записать сценарий тест-плана в такой форме:

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

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

      
      

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

      
      

      
      

      Антон Ульяненков, аналитик Playtestix

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

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

      Чтобы обеспечить качественный сбор наблюдений и отзывов пользователей об игре, супервайзер должен выполнять такие функции:

      Хорошо знать игру и четко понимать цели и задачи пользовательского тестирования; понимать, какой инструментарий проекта какие задачи решает. Расписанное “разделение труда” между методиками сбора фидбека на выходе дает более качественную информацию. Например, в анкете мы спрашиваем, какой режим игры понравился игроку больше всего, и получаем на выходе количественную оценку предпочтений. Наблюдение за игровой сессией поможет нам увидеть, как часто игрок играл в тот или иной режим, насколько он был успешен в каждом из них. В интервью мы просим игрока озвучить мотивы, по которым он выбрал тот или иной режим в качестве более привлекательного.

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

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

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

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

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

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

      Читайте также:

        
      • Как сделать перегородку в туалете
        
      • Как сделать коктейль в ананасе
        
      • Как сделать русский язык в portal reloaded
        
      • Как сделать тонкие и толстые вопросы
        
      • Как сделать коту глаза