Jump to content

Тестовый пример

В разработке программного обеспечения тестовый пример — это спецификация входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов, которые определяют один тест, который должен быть выполнен для достижения конкретной цели тестирования программного обеспечения , например, для проверки определенного пути программы или для проверки. соответствие конкретному требованию. [1] Тестовые случаи лежат в основе тестирования, которое носит методический, а не бессистемный характер. батарею тестовых примеров Для обеспечения желаемого покрытия тестируемого программного обеспечения можно создать . Формально определенные тестовые сценарии позволяют повторно запускать одни и те же тесты для последовательных версий программного обеспечения, что позволяет проводить эффективное и последовательное регрессионное тестирование . [2]

Формальные тестовые примеры

[ редактировать ]

Чтобы полностью проверить соответствие всем требованиям приложения, для каждого требования должно быть как минимум два тестовых примера: один положительный тест и один отрицательный тест. [3] Если требование имеет подтребования, каждое подтребование должно иметь как минимум два тестовых примера. Отслеживание связи между требованием и тестом часто осуществляется с помощью матрицы прослеживаемости . Письменные тестовые примеры должны включать описание тестируемой функциональности и подготовку, необходимую для проведения теста.

Формальный письменный тестовый пример характеризуется известными входными данными и ожидаемым результатом, который рассчитывается до выполнения теста. [4] Известные входные данные должны проверять предварительное условие , а ожидаемые выходные данные должны проверять постусловие .

Неформальные тестовые случаи

[ редактировать ]

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

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

Типичный формат письменного тестового примера

[ редактировать ]

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

Дополнительная информация, которая может быть включена: [7]

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

Более крупные тестовые примеры могут также содержать обязательные состояния или шаги, а также описания. [7]

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

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

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

Наборы тестов часто также содержат [8]

  • Итог теста
  • Конфигурация

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

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

Приемочные тесты , в которых используется разновидность письменного тестового примера, обычно выполняются группой конечных пользователей или клиентов системы, чтобы убедиться, что разработанная система соответствует указанным требованиям или контракту. [9] [10] Пользовательские приемочные тесты различаются включением « счастливого пути» или положительных тестовых случаев и почти полным исключением отрицательных тестовых случаев. [11]

См. также

[ редактировать ]
  1. ^ Системная и программная инженерия -- Словарь . ISO/IEC/IEEE 24765:2010(Е). 01 декабря 2010 г. стр. 1–418. дои : 10.1109/IEESTD.2010.5733835 . ISBN  978-0-7381-6205-8 .
  2. ^ Канер, Джем (май 2003 г.). «Что такое хороший тестовый пример?» (PDF) . ЗВЕЗДА Востока : 2.
  3. ^ «Написание правил тестирования для проверки требований заинтересованных сторон» . StickyMinds .
  4. ^ Бейзер, Борис (22 мая 1995 г.). Тестирование черного ящика . Нью-Йорк: Уайли. п. 3 . ISBN  9780471120940 .
  5. ^ «Введение в тестирование сценариев» (PDF) . Джем Канер . Проверено 7 мая 2009 г.
  6. ^ Криспин, Лиза; Грегори, Джанет (2009). Agile-тестирование: Практическое руководство для тестировщиков и Agile-команд . Аддисон-Уэсли . стр. 192 –5. ISBN  978-81-317-3068-3 .
  7. ^ Jump up to: а б Лю, Хуан (2014). «Равновесие процесса принятия решений на финансовом рынке» . Международная конференция по вычислительной науке и вычислительному интеллекту , 2014 г. стр. 113–121. дои : 10.1109/CSCI.2014.104 . ISBN  9781605951676 . S2CID   15204091 . Проверено 22 октября 2019 г.
  8. ^ Канер, Джем; Фальк, Джек; Нгуен, Хунг К. (1993). Тестирование компьютерного программного обеспечения (2-е изд.). Бостон: Thomson Computer Press. п. 123–4 . ISBN  1-85032-847-1 .
  9. ^ Хэмблинг, Брайан; ван Гетем, Полина (2013). Приемочное тестирование пользователей: пошаговое руководство . BCS Learning & Development Limited. ISBN  9781780171678 .
  10. ^ Блэк, Рекс (август 2009 г.). Управление процессом тестирования: практические инструменты и методы управления тестированием оборудования и программного обеспечения . Хобокен, Нью-Джерси: Уайли. ISBN  978-0-470-40415-7 .
  11. ^ Цимперман, Роб (2006). Определение UAT: Руководство по практическому приемочному тестированию для пользователей . Пирсон Образование. стр. Глава 2. ISBN  9780132702621 .
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: b27d8a645664beba22b4c3f550802496__1700679900
URL1:https://arc.ask3.ru/arc/aa/b2/96/b27d8a645664beba22b4c3f550802496.html
Заголовок, (Title) документа по адресу, URL1:
Test case - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)