4-software_engineering_testing (1133544), страница 3
Текст из файла (страница 3)
Тестирование программного обеспечения.2.2.1 Приѐмочное тестирование (Acceptance/qualification testing)Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно втом случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, каксторона “принимающая” программную систему, или специфицированы типовые задачи, успешнаяпроверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика.Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них.2.2.2 Установочное тестирование (Installation testing)Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляциисистемы в целевом окружении.2.2.3 Альфа- и бета-тестирование (Alpha and beta testing)Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадииальфа (внутреннее пробное использование) и бета (пробное использование с привлечениемотобранных внешних пользователей) версий.
Отчеты об ошибках, поступающие от пользователейэтих версий продукта, обрабатываются в соответствии с определенными процедурами,включающими подтверждающие тесты (любого уровня), проводимые специалистами группыразработки.Данный вид тестирования не может быть заранее спланирован.2.2.4 Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctnesstesting)Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы,предъявляемым к ней требованиям, описанным на уровне спецификации поведенческиххарактеристик.2.2.5 Достижение и оценка надежности (Reliability achievement and evaluation)Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежностипрограммных систем.
Случайно генерируемые сценарии тестирования могут применяться длястатистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигатьсяпри использовании моделей повышения надежности. Эти вопросы затрагиваются и в тематическомфрагменте 4.1.4 “Life test, reliability evaluation”.2.2.6 Регрессионное тестирование (Regression testing)Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of SoftwareEngineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент дляпроверки сделанных модификаций не должно приводить к непредусмотренным эффектам”.
Напрактике это означает, что если система успешно проходила тесты до внесения модификаций, онадолжна их проходит и после внесения таковых. Основная проблема регрессионного тестированиязаключается в поиске компромисса между имеющимеся ресурсами и необходимостью проведениятаких тестов по мере внесения каждого изменения.
В определенной степени, задача состоит в том,чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводитьрегрессионные тесты.2.2.7 Тестирование производительности (Performance testing)Специализированные тесты проверки удовлетворения специфических требований, предъявляемых кпараметрам производительности. Существует особый подвид таких тестов, когда делается попыткадостижения количественных пределов, обусловленных характеристиками самой системы и ееоперационного окружения.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия. Тестирование программного обеспечения.2.2.8 Нагрузочное тестирование (Stress testing)Необходимо понимать отличия между рассмотренным выше тестированием производительности сцелью достижения ее реальных (достижимых) возможностей производительности и выполнениемпрограммной системы c повышением нагрузки, вплоть до достижения запланированныххарактеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузкисистемы.2.2.9 Сравнительное тестирование (Back-to-back testing)Единичный набор тестов, позволяющих сравнить две версии системы.2.2.10 Восстановительные тесты (Recovery testing)Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы(disaster), влияющей на функционирование операционной среды, в которой выполняется система.2.2.11 Конфигурационное тестирование (Configuration testing)В случаях, если программное обеспечение создается для использования различнымипользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения иработоспособности системы в различных конфигурациях.2.2.12 Тестирование удобства и простоты использования (Usability testing)Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая нетолько функциональную составляющую – саму систему, но и ее документацию; насколькоэффективно пользователь может выполнять задачи, автоматизация которых осуществляется сиспользованием данной системы; наконец, насколько хорошо система застрахована (с точки зренияпотенциальных сбоев) от ошибок пользователя.2.2.13 Разработка, управляемая тестированием (Test-driven development)По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки,жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующихспецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверкеудовлетворения требований программной системой.Иногда говорят о таком стиле разработки как о самостоятельной методологии – TDD.
Насколько этоверно, зависит от того, что именно понимать под методологией разработки. Скорее, с точки зренияавтора, это техника, практика или стиль организации работы, чем самостоятельная методология.В меньшей степени это относится к FDD – Feature-Driven Development (разработка на основефункциональных возможностей). TDD может естественно рассматриваться как составная часть XPили, как минимум Agile-методов. В свою очередь, FDD может рассматриваться как один из методовгибкой разработки.В чем отличие столь близких, на первый взгляд, подходов (и, кстати, соответствующихаббревиатур)? Причина – проста.
Тесты – инструмент достижения характеристик системы,удовлетворяющей заданным требованиям, то есть потребностям пользователей, а “возможности”(features) – практически сами (чаще – функциональные) требования, воплощенные (в идеальномслучае) в код.3. Техники тестирования (Test Techniques)3.1 Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuitionand experience)3.1.1 Специализированное тестирование (Ad hoc testing)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия.
Тестирование программного обеспечения.Возможно, наиболее широко практикуемая техника. Тесты основываются на опыте, интуиции изнаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий. Данныйвид тестирования может быть полезен для идентификации тех тестов, которые не охватываютсярассматривавшимеся выше более формализованными техниками.3.1.2 Исследовательское тестирование (Exploratory testing)Такое тестирование определяется как одновременное обучение, проектирование теста и егоисполнение. Данный вид тестирования заранее не определяется в плане тестирования и такие тестысоздаются, выполняются и модифицируются динамически, по мере необходимости.
Эффективностьисследовательских тестов напрямую зависит от знаний инженера, формируемых на основеповедения тестируемого продукта в процессе проведения тестирования, степени знакомства сприложением, платформой, типами возможных сбоев и дефектов, рисками, ассоциированными сконкретным продуктом и т.п.3.2 Техники, базирующиеся на спецификации (Specification-based techniques)3.2.1 Эквивалентное разделение <приложения> (Equivalence partitioning)Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентныхклассов, которые считаются эквивалентными с точки зрения рассматриваемых связей ихарактеристик <спецификации>.
Репрезентативный набор тестов (иногда – только один тест)формируется из тестов эквивалентных классов (или наборов классов).3.2.2 Анализ граничных значений (Boundary-value analysis)Тесты строятся с ориентацией на использование тех величин, которые определяют предельныехарактеристики тестируемой системы. Расширением этой техники являются тесты оценкиживучести (robustness testing) системы, проводимые с величинами, выходящими за рамкиспецифицированных пределов значений.3.2.3 Таблицы принятия решений (Decision table)Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве“входов”) и действиями (могут рассматриваться как “выходы”).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
