В машиностроении и его различных разделах приемочное тестирование — это испытание, проводимое с целью определить, выполняются ли требования спецификации или контракта . Это может включать химические испытания , физические испытания или испытания производительности . [1]
В системном проектировании это может включать в себя тестирование системы методом «черного ящика» (например, части программного обеспечения , большого количества изготовленных механических деталей или партий химической продукции) перед ее доставкой. [2]
При тестировании программного обеспечения ISTQB определяет приемочное тестирование как:
Формальное тестирование в отношении потребностей, требований и бизнес-процессов пользователя, проводимое с целью определить, удовлетворяет ли система критериям приемки [3] , и дать возможность пользователю, клиентам или другому уполномоченному лицу определить, следует ли принимать систему.
— Стандартный словарь терминов, используемых при тестировании программного обеспечения [4] : 2
Некоторыми формами приемочного тестирования являются приемочное тестирование пользователя (UAT), тестирование конечного пользователя, эксплуатационное приемочное тестирование (OAT), разработка на основе приемочных испытаний (ATDD) и полевое (приемочное) тестирование. Критерии приемки — это критерии, которым система или компонент должны удовлетворять, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом. [5]
Тестирование — это набор действий, проводимых для облегчения обнаружения и/или оценки свойств одного или нескольких тестируемых объектов. [6] Каждый отдельный тест, известный как тестовый пример, выполняет набор заранее определенных тестовых действий, разработанных для управления выполнением элемента тестирования для достижения целей тестирования; включая правильную реализацию, выявление ошибок, проверку качества и другие важные детали. [6] Тестовая среда обычно проектируется так, чтобы быть идентичной или максимально приближенной к ожидаемой производственной среде. Оно включает в себя все средства, аппаратное обеспечение, программное обеспечение, встроенное ПО, процедуры и/или документацию, предназначенные или используемые для проведения тестирования программного обеспечения. [6]
Тестовые сценарии UAT и OAT идеально разрабатываются в сотрудничестве с бизнес-клиентами, бизнес-аналитиками, тестировщиками и разработчиками. Важно, чтобы эти тесты включали как тесты бизнес-логики, так и условия операционной среды. Бизнес-клиенты (владельцы продукта) являются основными заинтересованными сторонами этих тестов. Поскольку условия испытаний успешно соответствуют критериям приемки, заинтересованные стороны могут быть уверены, что разработка идет в правильном направлении. [7]
Набор приемочных тестов может потребоваться выполнить несколько раз, поскольку не все тестовые примеры могут быть выполнены за одну итерацию тестирования. [8]
Набор приемочных тестов запускается с использованием заранее определенных процедур приемочных испытаний, которые указывают тестировщикам, какие данные использовать, пошаговые процессы, которым следует следовать, и ожидаемый результат после выполнения. Фактические результаты сохраняются для сравнения с ожидаемыми результатами. [8] Если фактические результаты соответствуют ожидаемым результатам для каждого тестового примера, тестовый пример считается пройденным. Если количество непроходящих тестовых случаев не превышает заранее установленный порог проекта, набор тестов считается пройденным. В противном случае система может быть либо отклонена, либо принята на условиях, предварительно согласованных между спонсором и производителем.
Ожидаемый результат успешного выполнения теста:
Цель состоит в том, чтобы обеспечить уверенность в том, что разработанный продукт отвечает как функциональным, так и нефункциональным требованиям. Целью проведения приемочного тестирования является то, что после его завершения и при условии соблюдения критериев приемки ожидается, что спонсоры подпишут разработку/улучшение продукта как удовлетворяющее определенным требованиям (ранее согласованным между бизнесом и поставщиком/разработчиком продукта). .
Приемочное тестирование пользователя (UAT) представляет собой процесс проверки того, что решение работает для пользователя. [9] Это не тестирование системы (проверка того, что программное обеспечение не дает сбоев и соответствует документированным требованиям), а, скорее, гарантия того, что решение будет работать для пользователя (т.е. проверка того, что пользователь принимает решение); производители программного обеспечения часто называют это «бета-тестированием».
Это тестирование должно проводиться предполагаемым конечным пользователем или профильным экспертом (SME), предпочтительно владельцем или клиентом тестируемого решения, и предоставлять краткое изложение результатов для подтверждения, которое можно будет продолжить после испытания или проверки. При разработке программного обеспечения UAT как один из заключительных этапов проекта часто происходит до того, как клиент или заказчик примет новую систему. Пользователи системы проводят тесты в соответствии с тем, что происходит в реальных сценариях. [10]
Важно, чтобы материалы, передаваемые тестировщику, были аналогичны материалам, которые будут иметься у конечного пользователя. Тестировщикам следует предоставить сценарии из реальной жизни, такие как три наиболее распространенные или сложные задачи, которые будут выполнять пользователи, которых они представляют. [11]
UAT выступает в качестве окончательной проверки требуемой бизнес-функциональности и правильного функционирования системы, имитируя реальные условия от имени клиента-плательщика или конкретного крупного клиента. Если программное обеспечение работает должным образом и без проблем при обычном использовании, можно разумно экстраполировать тот же уровень стабильности в рабочей среде. [12]
Пользовательские тесты, обычно выполняемые клиентами или конечными пользователями, обычно не фокусируются на выявлении простых косметических проблем, таких как орфографические ошибки, или на дефектах , таких как сбои программного обеспечения ; тестировщики и разработчики выявляют и устраняют эти проблемы на более ранних этапах модульного тестирования , интеграционного тестирования и тестирования системы.
UAT следует выполнять в соответствии с тестовыми сценариями. [13] [14] Сценарии тестирования обычно отличаются от сценариев системного или функционального тестирования тем, что они представляют собой путешествие «игрока» или «пользователя». Широкий характер сценария тестирования гарантирует, что основное внимание будет сосредоточено на пути, а не на технических или специфичных для системы деталях, избегая пошаговых этапов тестирования, позволяющих учитывать различия в поведении пользователей. Сценарии тестирования можно разбить на логические «дни», в которые обычно меняется действующее лицо (игрок/клиент/оператор) или система (бэк-офис, внешний интерфейс). [15]
В промышленности обычным UAT является заводское приемочное испытание (FAT). Это испытание проводится перед установкой оборудования. В большинстве случаев тестировщики проверяют не только соответствие оборудования техническим характеристикам, но и его полную работоспособность. FAT обычно включает проверку комплектности, проверку на соответствие контрактным требованиям, подтверждение функциональности (путем моделирования или обычного функционального испытания) и окончательную проверку. [16] Результаты этих испытаний дают клиентам уверенность в том, как система будет работать в производственной среде. Также могут существовать юридические или договорные требования для принятия системы.
Оперативное приемочное тестирование (ОАТ) используется для проведения эксплуатационной готовности (предварительного выпуска) продукта, услуги или системы в рамках системы менеджмента качества . OAT — это распространенный тип нефункционального тестирования программного обеспечения , используемый в основном в проектах разработки и сопровождения программного обеспечения . Этот тип тестирования фокусируется на оперативной готовности системы к поддержке и/или к тому, чтобы стать частью производственной среды. [17]
Приемочное тестирование — это термин, используемый в методологиях гибкой разработки программного обеспечения , особенно в экстремальном программировании , и относится к функциональному тестированию пользовательской истории командой разработчиков программного обеспечения на этапе реализации. [18]
Заказчик указывает сценарии для проверки правильности реализации пользовательской истории. История может иметь одно или несколько приемочных тестов, независимо от того, что необходимо для обеспечения работоспособности функциональности. Приемочные испытания — это системные испытания «черного ящика». Каждое приемочное испытание представляет собой некоторый ожидаемый результат от системы. Заказчики несут ответственность за проверку правильности приемочных испытаний и анализ результатов тестов, чтобы решить, какие неудавшиеся тесты имеют наивысший приоритет. Приемочные тесты также используются в качестве регрессионных тестов перед выпуском продукта. Пользовательская история не считается завершенной, пока она не пройдет приемочные испытания. Это означает, что для каждой итерации необходимо создавать новые приемочные тесты, иначе команда разработчиков сообщит о нулевом прогрессе. [19]
Типичные типы приемочных испытаний включают следующие:
По мнению Института управления проектами , критерии приемки — это «набор условий, которые необходимо выполнить, прежде чем результаты будут приняты». [25] Требования, содержащиеся в критериях приемки для данного компонента системы, обычно очень подробны. [26]
{{cite journal}}
: Требуется цитировать журнал |journal=
( помощь ){{cite book}}
: CS1 maint: отсутствует местоположение издателя ( ссылка )