что такое тестовый набор
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Что такое тестовый набор
При наличии обоснованного набора требований коллектив тестирования должен спланировать тесты, которые соответствующим образом могут проверить эти требования. Обратите внимание, что проверка соответствия программного обеспечения требованиям может выполняться по-разному в зависимости от типа требований. Например, тестирование функциональности и производительности программного обеспечения может выполняться с помощью автоматизированных процедур тестирования, а соответствие требованиям конфигурации, например, выключение системы хоста должно выполняться вручную.
Поскольку часто невозможно проверить все требования, или это не входит в ваши обязанности, то важно сосредоточить усилия на проверке наиболее значимых требований для текущих заданий. Выбор таких требований осуществляется на основе баланса стоимости, риска и необходимости проверки требования. Обычно проверяется только то, с чем работают в текущей итерации.
При всей важности собственно требований для определения тестов, они не являются единственным источником информации. Во многих случаях опора только на требования не будет достаточной для формирования тестов. Тестовые наборы должны также учитывать риски, ограничения, технологии, запросы на изменение (изъяны), ошибки и пр.
За дополнительной информацией по разработке идей для тестов обратитесь к разделу Концепции: идеи тестов.
Создание тестового набора важно по нескольким причинам.
Будет полезным, однако, принять во внимание следующие соображения, касающиеся тестовых наборов:
Тестовые наборы часто создаются на основе типа теста или требования для теста и могут заметно отличаться друг от друга. Эмпирические правила для выделения тестовых наборов сводятся к следующему:
Создание тестового набора на основе вариантов использования
Примеры потоков для варианта использования
Для каждого из возможных путей варианта использования на этой диаграмме можно выделить различные сценарии варианта использования. Ниже описаны эти сценарии, включая и альтернативные потоки, начиная с основного потока.
| Сценарий 1 | Основной поток | |||
|---|---|---|---|---|
| Сценарий 2 | Основной поток | Альтернативный поток 1 | ||
| Сценарий 3 | Основной поток | Альтернативный поток 1 | Альтернативный поток 2 | |
| Сценарий 4 | Основной поток | Альтернативный поток 3 | ||
| Сценарий 5 | Основной поток | Альтернативный поток 3 | Альтернативный поток 1 | |
| Сценарий 6 | Основной поток | Альтернативный поток 3 | Альтернативный поток 1 | Альтернативный поток 2 |
| Сценарий 7 | Основной поток | Альтернативный поток 4 | ||
| Сценарий 8 | Основной поток | Альтернативный поток 3 | Альтернативный поток 4 |
Примечание: Для простоты в сценариях 5, 6 и 8 показано только одно выполнение цикла, относящегося к альтернативному потоку 3.
Создание тестовых наборов для сценариев выполняется благодаря указанию условия, из-за которого начинается выполнение этого сценария варианта использования.
Например, для варианта использования на рисунке альтернативный поток 3 соответствует следующему условию:
«Это поток реализуется, если на шаге 2, «Введите сумму», указана сумма, превышающая остаток на счете клиента. Система показывает предупреждение и возвращается к шагу 2 основного потока «Введите сумму», предлагая клиенту повторно ввести сумму.»
На основании этой информации можно выделить тестовые наборы, необходимые для выполнения альтернативного потока 3:
После того, как выделены тестовые наборы, необходимо убедиться, что они будут выполнены в точности и дадут необходимые результаты, а также устранить повторяющиеся и избыточные тестовые наборы. Дополнительные сведения приведены в разделе Концепции: список идей тестов. См. также раздел Определение данных тестов для тестового набора.
Эти тестовые наборы составляют лишь часть тестовых наборов, требуемых для проверки варианта использования получения наличных в этой итерации. Далее перечислены прочие тестовые наборы:
В будущих итерациях, в которых будут реализованы прочие потоки, потребуются также следующие тестовые наборы:
Для идентификации функциональных тестовых наборов выполните следующее:
За дополнительной информацией обратитесь к разделу Определение данных тестов для тестового набора.
Создание тестового набора на основе вспомогательных спецификаций
Не все требования для целевого объекта тестирования будут отражены в артефактах функциональных требований, таких как спецификация варианта использования. Нефункциональные требования, например, относящиеся к производительности, защите и правам доступа или конфигурации, задают дополнительные особенности целевого объекта и часто фиксируются отдельно от функциональных требований. Вспомогательная спецификация является одним из основных источников для создания тестовых наборов для таких дополнительных требований.
Далее перечислены рекомендации, относящиеся к созданию дополнительных тестовых наборов:
Создание тестового набора для тестирования производительности
Основным источником для тестовых наборов, относящихся к производительности, являются вспомогательные спецификации, в которых указаны нефункциональные требования. См. Рабочий продукт: вспомогательные спецификации. При создании тестовых наборов для тестирования производительности придерживайтесь следующих рекомендаций:
Поимо указанных критериев производительности выделите особые условия, которые влияют на время отклика, а именно:
Тестовые наборы для тестов производительности могут также быть выражены в табличной форме, подобно той, что использовалась для функциональных тестов.
За дополнительной информацией обратитесь к разделу Определение данных тестов для тестового набора.
Ниже приведены примеры различных типов тестов производительности:
Для тестирования нагрузки:
Выполнение транзакции выдачи денег
(V означает, что устройство работает правильно)
Создание тестового набора для тестирования конфигурации
В распределенных системах может поддерживаться много допустимых сочетаний программного обеспечения и аппаратного обеспечения. В ходе тестирования должна быть проверена работа целевого объекта тестирования в различных конфигурациях, в разных операционных системах, браузерах, на разных процессорах. Кроме того, при тестировании требуется проверить работоспособность различных сочетаний компонентов, например, не конфликтуют ли версии DLL, устанавливаемые приложением с версиями этих же DLL, с которыми работает другое приложение.
Для того чтобы создать тестовые наборы для конфигурации, придерживайтесь следующих рекомендаций:
Создание тестового набора для тестирования установки
В ходе тестирования установки проверяется, что установка целевого объекта тестирования выполняется правильно во всех возможных сценариях установки. Сценариями могут быть первая установка целевого объекта тестирования или установка его новой версии в систему, где уже есть старая версия. Также необходимо проверить, будет ли программа установки целевого объекта тестирования работать правильно при возникновении неполадок, например, при нехватке места на диске.
Тестовые наборы должны отражать сценарии установки для программного обеспечения, а именно:
Программы установки для клиент-серверных систем содержат специальные тестовые наборы. В отличие от систем, устанавливаемых на один компьютер, программа установки содержит часть сервера и часть клиента. Поэтому при тестировании необходимо проверить установку всех компонентов целевого объекта тестирования, включая клиент, промежуточные компоненты и сервер.
Создание тестового набора для прочих нефункциональных тестов
В идеале все требования для создания тестовых наборов должны быть отражены в модели вариантов использования, проектной модели и вспомогательных спецификациях. Однако часто приходится обращаться еще и к приведенным здесь материалам.
В большинстве случаев эти тестовые наборы создаются на основе или посредством объединения уже имеющихся тестовых наборов.
Создание тестового набора для тестирования приемки продукта
Создание тестовых наборов для рабочих продуктов программного обеспечения фактически уже описано выше. В зависимости от того, насколько формально должна выполняться приемка продукта, тестовые наборы могут быть полным комплектом уже указанных выше тестовых наборов или их частью. В любом случае перед началом тестирования должны быть согласованы тестовые наборы и критерии приемки продукта.
Оценка рабочих продуктов, отличных от программного обеспечения, в значительной степени зависит от того, какой это рабочий продукт. Обратитесь к рекомендациям и справочным таблицам каждого из рабочих продуктов, отличных от программного обеспечения, за информацией о том, каким образом выполняется их оценка.
Создание проверочных тестовых наборов для регрессионного тестирования
В регрессионном тестировании сравниваются две версии целевого объекта тестирования с целью поиска различий как потенциальных неполадок. При этом предполагается, что более поздняя версия должна работать не хуже прежней, и проверяется, не возникли ли неполадки в результате изменений.
В идеале в последующих итерациях желательно использовать все тестовые наборы с предыдущей итерации. Ниже приведены рекомендации, которые помогают определить и реализовать тестовые наборы, которые повышают ценность регрессионного тестирования, и в то же время снизить расходы на его обеспечение:
Определение данных тестов для тестового набора
После обсуждения и согласования выбора тестовых наборов для них необходимо определить тестовые данные (например, в таблице реализации тестового набора) и создать артефакты тестовых данных.
Работа с тестовыми данными описана в документе Рекомендация: тестовые данные.
© Copyright IBM Corp. 1987, 2006. Все права защищены..
В чем разница между наборами данных тестирования и проверки?
Дата публикации 2017-07-14
Набор данных проверки отличается от набора тестовых данных, который также удерживается от обучения модели, но вместо этого используется, чтобы дать объективную оценку мастерства окончательно настроенной модели при сравнении или выборе между конечными моделями.
Прикладное машинное обучение приводит к путанице в том, что такое набор данных проверки и чем он отличается от набора тестовых данных.
В этом посте вы найдете четкие определения для наборов данных для обучения, тестирования и проверки, а также способы их использования в собственных проектах машинного обучения.
Прочитав этот пост, вы узнаете:
Обзор учебника
Этот урок разделен на 4 части; они есть:
Что такое набор данных проверки экспертами?
Я считаю полезным видеть, как именно наборы данных описываются практиками и экспертами.
В этом разделе мы рассмотрим, как определяются наборы данных для обучения, тестирования и проверки и как они различаются в соответствии с некоторыми основными текстами и ссылками на машинное обучение.
Как правило, термин «проверочный набор»Используется взаимозаменяемо с термином«тестовый набор»И относится к образцу набора данных, удерживаемому от обучения модели.
Оценка умения модели на наборе обучающих данных приведет к смещенной оценке. Следовательно, модель оценивается на протяженной выборке, чтобы дать объективную оценку навыка модели. Обычно это называется разделенным подходом к оценке алгоритма.
Мы видим взаимозаменяемость непосредственно в превосходном тексте Куна и Джонсона «Прикладное прогнозное моделирование». В этом примере они ясно указывают на то, что окончательная оценка модели должна быть выполнена на протяженном наборе данных, который не использовался ранее, ни для обучения модели, ни для настройки параметров модели.
В идеале модель должна оцениваться на образцах, которые не использовались для построения или точной настройки модели, чтобы они обеспечивали беспристрастное ощущение эффективности модели. Когда имеется большой объем данных, можно выбрать набор выборок для оценки окончательной модели. Набор данных «обучение» является общим термином для образцов, используемых для создания модели, а набор данных «тест» или «проверка» используется для оценки производительности.
Возможно, традиционно набор данных, используемый для оценки окончательной производительности модели, называется «набор тестов». Рассел и Норвиг в своих оригинальных учебниках по искусству искусственного интеллекта подтверждают важность разделения набора тестов. Они ссылаются на использование информации из тестового набора в любом случае как «подглядывание». Они предлагают полностью заблокировать тестовый набор, пока не будет завершена вся настройка модели.
— Стюарт Рассел и Питер Норвиг, стр. 709,Искусственный интеллект: современный подход, 2009 (3-е издание)
Важно отметить, что Рассел и Норвиг комментируют, что обучающий набор данных, используемый для подгонки модели, может быть дополнительно разбит на обучающий набор и набор проверки, и что именно этот поднабор обучающего набора данных, называемый набором проверки, может использоваться для получения ранняя оценка мастерства модели.
Если набор тестов заблокирован, но вы все еще хотите измерить производительность на невидимых данных как способ выбора хорошей гипотезы, то разделите имеющиеся данные (без набора тестов) на обучающий набор и набор проверки.
— Стюарт Рассел и Питер Норвиг, стр. 709,Искусственный интеллект: современный подход, 2009 (3-е издание)
Это определение набора валидации подтверждается другими основополагающими текстами в данной области. Хорошим (и более старым) примером является глоссарий терминов в книге Рипли «Распознавание образов и нейронные сети». В частности, наборы обучения, проверки и тестирования определяются следующим образом:
— Учебный набор: набор примеров, используемых для обучения, то есть для соответствия параметрам классификатора.
— Набор проверки: набор примеров, используемых для настройки параметров классификатора, например, для выбора количества скрытых единиц в нейронной сети.
— Тестовый набор: набор примеров, используемых только для оценки эффективности полностью определенного классификатора.
Это рекомендуемые определения и использование терминов.
Хорошим примером того, что эти определения являются каноническими, является их повторение в известном FAQ по нейронной сети. В дополнение к повторению определений глоссария Рипли, он продолжает обсуждать распространенное неправильное использование терминов «набор тестов» и «набор валидации» в прикладном машинном обучении.
Литература по машинному обучению часто меняет значение наборов «валидация» и «тест». Это самый вопиющий пример терминологической путаницы, которая пронизывает исследования в области искусственного интеллекта.
Важным моментом является то, что тестовый набор по стандартному определению в литературе NN [нейронная сеть] никогда не используется для выбора между двумя или более сетями, так что ошибка в тестовом наборе обеспечивает объективную оценку ошибки обобщения ( при условии, что набор тестов является репрезентативным для населения и т. д.).
Знаете ли вы какие-либо другие четкие определения или использования этих терминов, например, цитаты в статьях или учебнике?
Пожалуйста, дайте мне знать в комментариях ниже.
Определения поездных, проверочных и тестовых наборов данных
Чтобы повторить выводы исследования вышеупомянутых экспертов, в этом разделе представлены однозначные определения трех терминов.
Мы можем сделать этот бетон с помощью эскиза псевдокода:
Ниже приведены некоторые дополнительные уточняющие примечания:
Эти определения вам понятны для вашего варианта использования?
Если нет, пожалуйста, задавайте вопросы ниже.
Набор данных проверки недостаточно
Существуют и другие способы расчета непредвзятой (или прогрессивно более предвзятой в случае набора данных проверки) оценки навыка модели на невидимых данных.
Одним из популярных примеров является использование перекрестной проверки в k-кратном порядке для настройки гиперпараметров модели вместо отдельного набора данных проверки.
В своей книге Кун и Джонсон имеют раздел под названием «Рекомендации по разделению данных», в котором они устанавливают ограничения на использование единственного «набора тестов» (или набора проверки):
Как обсуждалось ранее, существует серьезное техническое обоснование для одного, независимого набора тестов:
— Тестовый набор представляет собой единственную оценку модели и имеет ограниченную способность характеризовать неопределенность в результатах.
— Пропорционально большие тестовые наборы делят данные таким образом, чтобы увеличить смещение в оценках производительности.
— С небольшими размерами выборки:
— Модель может нуждаться во всех возможных точках данных для адекватного определения значений модели.
— Неопределенность тестового набора может быть значительно большей, чтобы разные тестовые наборы могли давать очень разные результаты.
— Методы передискретизации могут дать разумные прогнозы того, насколько хорошо модель будет работать на будущих выборках.
Далее они дают рекомендации для небольших размеров выборки с использованием 10-кратной перекрестной проверки в целом из-за желательного низкого смещения и дисперсионных свойств оценки производительности. Они рекомендуют метод начальной загрузки в случае сравнения производительности модели из-за низкой дисперсии в оценке производительности.
Для больших размеров выборки они снова рекомендуют подход к 10-кратной перекрестной проверке, в целом.
Валидация и тестовые наборы данных исчезают
Скорее всего, вы не увидите ссылок на наборы обучающих, проверочных и тестовых данных в современном прикладном машинном обучении.
Ссылка на «набор данных проверки» исчезает, если практикующий врач выбирает настройку гиперпараметров модели, используя перекрестную проверку в k-кратном размере с набором обучающих данных.
Мы можем сделать этот бетон с помощью эскиза псевдокода следующим образом:
Ссылка на «тестовый набор данных» также может исчезнуть, если перекрестная проверка гиперпараметров модели с использованием обучающего набора данных вложена в более широкую перекрестную проверку модели.
В конечном счете, все, что вам осталось, это образец данных из домена, который мы можем по праву продолжать называть учебным набором данных.
Дальнейшее чтение
Этот раздел предоставляет больше ресурсов по этой теме, если вы хотите углубиться.
Знаете ли вы какие-либо другие полезные ресурсы по этой теме? Позвольте мне знать в комментариях ниже.
Резюме
В этом руководстве вы обнаружили, что в терминах «набор данных проверки» и «набор данных тестирования» возникает много путаницы, а также в том, как правильно перемещаться по этим терминам при оценке навыков ваших собственных моделей машинного обучения.
В частности, вы узнали:
У вас есть вопросы?
Задайте свои вопросы в комментариях ниже, и я сделаю все возможное, чтобы ответить.