- Главная
- Информатика
- Классификация по уровню детализации приложения (по уровню тестирования)
Содержание
- 2. Системное тестирование (system testing) направлено на проверку всего приложения как единого целого, собранного из частей, проверенных
- 5. Классификация по (убыванию) степени важности тестируемых функций (по уровню функционального тестирования) В некоторых источниках эту разновидность
- 6. Дымовое тестирование проводится после выхода нового билда, чтобы определить общий уровень качества приложения и принять решение
- 8. Тестирование критического пути (critical path test) направлено на исследование функциональности, используемой типичными пользователями в типичной повседневной
- 10. Расширенное тестирование (extended test) направлено на исследование всей заявленной в требованиях функциональности — даже той, которая
- 12. Классификация по принципам работы с приложением Позитивное тестирование (positive testing) направлено на исследование приложения в
- 13. Классификация по природе приложения Данный вид классификации является искусственным, поскольку «внутри» речь будет идти об одних
- 14. Классификация по фокусировке на уровне архитектуры приложения Данный вид классификации, как и предыдущий, также является искусственным
- 15. Классификация по привлечению конечных пользователей Все три перечисленных ниже вида тестирования относятся к операционному тестированию.
- 16. Классификация по степени формализации Тестирование на основе тест-кейсов (scripted testing, test case based test-ing) — формализованный
- 17. Классификация по целям и задачам Позитивное тестирование. Негативное тестирование. Функциональное тестирование (functional testing)
- 18. тестирование проверяет множество сценариев и аспектов работы инсталлятора в таких ситуациях, как: o новая среда исполнения,
- 19. Повторное тестирование (re-testing, confirmation testing) — выполнение тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения устранения
- 20. o Производственное приёмочное тестирование (factory acceptance testing) — выполняемое проектной командой исследование полноты и качества реализации
- 21. Тестирование доступности (accessibility testing) — тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными
- 22. Тестирование локализации (localization testing) — тестирование, направленное на проверку корректности и качества адаптации продукта к использованию
- 24. Скачать презентацию
Системное тестирование (system testing) направлено на проверку всего приложения как единого
С классификацией по уровню детализации приложения связан интересный печальный факт: если предыдущая стадия обнаружила проблемы, то на следую- щей стадии эти проблемы точно нанесут удар по качеству; если же предыдущая стадия не обнаружила проблем, это ещё никоим образом не защищает нас от про- блем на следующей стадии.
Для лучшего запоминания степень детализации в модульном, интеграцион- ном и системном тестировании показана схематично на рисунке 2.3.d.
Классификация по (убыванию) степени важности тестируемых функций (по уровню функционального тестирования)
Классификация по (убыванию) степени важности тестируемых функций (по уровню функционального тестирования)
В некоторых источниках эту разновидность классификации также называют «по глубине тестирования».
Дымовое тестирование (smoke test, intake test, build verification test) направлено на проверку самой главной, самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной саму идею использования приложения (или иного объекта, подвергаемого дымовому тестированию).
Дымовое тестирование проводится после выхода нового билда, чтобы определить общий уровень
Дымовое тестирование проводится после выхода нового билда, чтобы определить общий уровень
Очень часто можно услышать вопрос о том, чем «smoke test» отличается от «sanity test». В глоссарии ISTQB сказано просто: «sanity test: See smoke test». Но некоторые авторы утверждают, что разница есть и может быть выражена следующей схемой (рисунок 2.3.f):
Тестирование критического пути (critical path test) направлено на исследование функциональности, используемой
Расширенное тестирование (extended test) направлено на исследование всей заявленной в требованиях
Расширенное тестирование (extended test) направлено на исследование всей заявленной в требованиях
Ещё одним направлением исследования в рамках данного тестирования являются нетипичные, маловероятные, экзотические случаи и сценарии использования функций и свойств приложения, затронутых на предыдущих уровнях. Пороговое значение метрики успешного прохождения расширенного тестирования существенно ниже, чем в тестировании критического пути (иногда можно увидеть даже значения в диапазоне 30–50 %, т.к. подавляющее большинство найденных здесь дефектов не представляет угрозы для успешного использования приложения большинством пользователей).
Классификация по принципам работы с приложением
Позитивное тестирование (positive testing) направлено
Классификация по принципам работы с приложением
Позитивное тестирование (positive testing) направлено
Негативное тестирование (negative testing, invalid testing) — направлено на исследование работы приложения в ситуациях, когда с ним выполняются (некорректные) операции и/или используются данные, потенциально приводящие к ошибкам (классика жанра — деление на ноль). Поскольку в реальной жизни таких ситуаций значительно больше (пользователи допускают ошибки, злоумышленники осознанно «ломают» приложение, в среде работы приложения возникают проблемы и т.д.), негативных тест-кейсов оказывается значительно больше, чем позитивных (иногда — в разы или даже на порядки). В отличие от позитивных негативные тест-кейсы не стоит объединять, т.к. подобное решение может привести к неверной трактовке поведения приложения и пропуску (необнаружению) дефектов.
Классификация по природе приложения
Данный вид классификации является искусственным, поскольку «внутри»
Классификация по природе приложения
Данный вид классификации является искусственным, поскольку «внутри»
Тестирование веб-приложений (web-applications testing) сопряжено с интенсивной деятельностью в области тестирования совместимости (в особенности — кроссбраузерного тестирования), тестирования производительности, автоматизации тестирования с использованием широкого спектра инструментальных средств.
Тестирование мобильных приложений (mobile applications testing) также требует повышенного внимания к тестированию совместимости, оптимизации производительности (в том числе клиентской части с точки зрения снижения энергопотребления), автоматизации тестирования с применением эмуляторов мобильных устройств.
Тестирование настольных приложений (desktop applications testing) является самым классическим среди всех перечисленных в данной классификации, и его особенности зависят от предметной области приложения, нюансов архитектуры, ключевых показателей качества и т.д.
Классификация по фокусировке на уровне архитектуры приложения
Данный вид классификации, как и
Классификация по фокусировке на уровне архитектуры приложения
Данный вид классификации, как и
Тестирование уровня представления (presentation tier testing) сконцентрировано на той части приложения, которая отвечает за взаимодействие с «внешним миром» (как пользователями, так и другими приложениями). Здесь исследуются вопросы удобства использования, скорости отклика интерфейса, совместимости с браузерами, корректности работы интерфейсов.
Тестирование уровня бизнес-логики (business logic tier testing) отвечает за проверку основного набора функций приложения и строится на базе ключевых требований к приложению, бизнес-правил и общей проверки функциональности.
Тестирование уровня данных (data tier testing) сконцентрировано на той части приложения, которая отвечает за хранение и некоторую обработку данных (чаще всего — в базе данных или ином хранилище). Здесь особый интерес представляет тестирование данных, проверка соблюдения бизнес-правил, тестирование производительности.
Классификация по привлечению конечных пользователей
Все три перечисленных ниже вида тестирования относятся
Классификация по привлечению конечных пользователей
Все три перечисленных ниже вида тестирования относятся
Альфа-тестирование (alpha testing) выполняется внутри организации-разработчика с возможным частичным привлечением конечных пользователей. Может являться формой внутреннего приёмочного тестирования{82}. В некоторых источниках отмечается, что это тестирование должно проводиться без привлечения команды разработчиков, но другие источники не выдвигают такого требования. Суть этого вида вкратце: продукт уже можно периодически показывать внешним пользователям, но он ещё достаточно «сырой», потому основное тестирование выполняется организацией-разработчиком.
Бета-тестирование (beta testing) выполняется вне организации-разработчика с активным привлечением конечных пользователей/заказчиков. Может являться формой внешнего приёмочного тестирования. Суть этого вида вкратце: продукт уже можно открыто показывать внешним пользователям, он уже достаточно стабилен, но проблемы всё ещё могут быть, и для их выявления нужна обратная связь от реальных пользователей.
Гамма-тестирование (gamma testing) — финальная стадия тестирования перед выпуском продукта, направленная на исправление незначительных дефектов, обнаруженных в бета-тестировании. Как правило, также выполняется с максимальным привлечением конечных пользователей/заказчиков. Может являться формой внешнего приёмочного тестирования{82}. Суть этого вида вкратце: продукт уже почти готов, и сейчас обратная связь от реальных пользователей используется для устранения последних недоработок.
Классификация по степени формализации
Тестирование на основе тест-кейсов (scripted testing, test
Классификация по степени формализации
Тестирование на основе тест-кейсов (scripted testing, test
Исследовательское тестирование (exploratory testing) — частично формализованный подход, в рамках которого тестировщик выполняет работу с приложением по выбранному сценарию, который, в свою очередь, дорабатывается в процессе выполнения с целью более полного исследования приложения. Ключевым фактором успеха при выполнении исследовательского тестирования является именно работа по сценарию, а не выполнение разрозненных бездумных операций. Существует даже специальный сценарный подход, называемый сессионным тестированием (session-based test-ing). В качестве альтернативы сценариям при выборе действий с приложением иногда могут использоваться чек-листы, и тогда этот вид тестирования называют тестированием на основе чек-листов (checklist-based testing).
Свободное (интуитивное) тестирование (ad hoc testing) — полностью неформализованный подход, в котором не предполагается использования ни тест-кейсов, ни чек-листов, ни сценариев — тестировщик полностью опирается на свой профессионализм и интуицию (experience-based testing) для спонтанного выполнения с приложением действий, которые, как он считает, могут обнаружить ошибку. Этот вид тестирования используется редко и исключительно как дополнение к полностью или частично формализованному тестированию в случаях, когда для исследования некоторого аспекта поведения приложения (пока?) нет тест-кейсов.
Классификация по целям и задачам
Позитивное тестирование.
Негативное тестирование.
Классификация по целям и задачам
Позитивное тестирование.
Негативное тестирование.
Функциональное тестирование (functional testing) — вид тестирования, направленный на проверку корректности работы функциональности приложения (корректность реализации функциональных требований). Часто функциональное тестирование ассоциируют с тестированием по методу чёрного ящика, однако и по методу белого ящика вполне можно проверять корректность реализации функциональности.
Нефункциональное тестирование (non-functional testing) — вид тестирования, направленный на проверку нефункциональных особенностей приложения (корректность реализации нефункциональных требований), таких как удобство использования, совместимость, производительность, безопасность и т.д.
Инсталляционное тестирование (installation testing, installability testing) — тестирование, направленное на выявление дефектов, влияющих на протекание стадии инсталляции (установки) приложения.
тестирование проверяет множество сценариев и аспектов работы инсталлятора в таких ситуациях,
тестирование проверяет множество сценариев и аспектов работы инсталлятора в таких ситуациях,
o новая среда исполнения, в которой приложение ранее не было инсталлировано;
o обновление существующей версии («апгрейд»);
o изменение текущей версии на более старую («даунгрейд»);
o повторная установка приложения с целью устранения возникших проблем («переинсталляция»);
o повторный запуск инсталляции после ошибки, приведшей к невозможности продолжения инсталляции;
o удаление приложения;
o установка нового приложения из семейства приложений;
o автоматическая инсталляция без участия пользователя.
Регрессионное тестирование (regression testing) — тестирование, направленное на проверку того факта, что в ранее работоспособной функциональности не появились ошибки, вызванные изменениями в приложении или среде его функционирования. Фредерик Брукс в своей книге «Мифический человеко-месяц» писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50 %) влечёт появление новой». Потому регрессионное тестирование является неотъемлемым инструментом обеспечения качества и активно используется практически в любом проекте.
Повторное тестирование (re-testing, confirmation testing) — выполнение тест-кейсов, которые ранее обнаружили
Повторное тестирование (re-testing, confirmation testing) — выполнение тест-кейсов, которые ранее обнаружили
Приёмочное тестирование (acceptance testing) — формализованное тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика и вынесения решения о том, принимает ли заказчик работу у исполнителя (проектной команды). Можно выделить следующие подвиды приёмочного тестирования (хотя упоминают их крайне редко, ограничиваясь в основном общим термином «приёмочное тестирование»):
o Производственное приёмочное тестирование (factory acceptance testing) — выполняемое проектной командой
o Производственное приёмочное тестирование (factory acceptance testing) — выполняемое проектной командой
o Операционное приёмочное тестирование (operational acceptance testing, production acceptance testing) — операционное тестирование, выполняемое с точки зрения выполнения инсталляции, потребления приложением ресурсов, совместимости с программной и аппаратной платформой и т.д.
o Итоговое приёмочное тестирование (site acceptance testing) — тестирование конечными пользователями (представителями заказчика) приложения в реальных условиях эксплуатации с целью вынесения решения о том, требует ли приложение доработок или может быть принято в эксплуатацию в текущем виде.
Операционное тестирование (operational testing) — тестирование, проводимое в реальной или приближенной к реальной операционной среде (operational environment), включающей операционную систему, системы управления базами данных, серверы приложений, веб-серверы, аппаратное обеспечение и т.д.
Тестирование удобства использования (usability testing) — тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом (understandability176, learnability177, op-erability178), а также на то, насколько ему нравится использовать продукт (attractiveness179). И это не оговорка — очень часто успех продукта зависит именно от эмоций, которые он вызывает у пользователей. Для эффективного проведения этого вида тестирования требуется реализовать достаточно серьёзные исследования с привлечением конечных пользователей, проведением маркетинговых исследований и т.д.
Тестирование доступности (accessibility testing) — тестирование, направленное на исследование пригодности продукта
Тестирование доступности (accessibility testing) — тестирование, направленное на исследование пригодности продукта
Тестирование интерфейса (interface testing) — тестирование, направленное на проверку интерфейсов приложения или его компонентов. По определению ISTQB-глоссария этот вид тестирования относится к интеграционному тестированию, и это вполне справедливо для таких его вариаций как тестирование интерфейса прикладного программирования (API testing) и интерфейса командной строки (CLI testing), хотя последнее может выступать и как разновидность тестирования пользовательского интерфейса, если через командную строку с приложением взаимодействует пользователь, а не другое приложение. Однако многие источники предлагают включить в состав тестирования интерфейса и тестирование непосредственно интерфейса пользователя (GUI testing).
Тестирование безопасности (security testing) — тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям, права на доступ к которым у злоумышленника нет.
Тестирование интернационализации (internationalization testing, i18n testing, globalization testing, localizability testing) — тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей. Этот вид тестирования не подразумевает проверки качества соответствующей адаптации (этим занимается тестирование локализации, см. следующий пункт), оно сфокусировано именно на проверке возможности такой адаптации (например: что будет, если открыть файл с иероглифом в имени; как будет работать интерфейс, если всё перевести на японский; может ли приложение искать данные в тексте на корейском и т.д.)
Тестирование локализации (localization testing) — тестирование, направленное на проверку корректности и
Тестирование локализации (localization testing) — тестирование, направленное на проверку корректности и
Тестирование совместимости (compatibility testing, interoperability testing) — тестирование, направленное на проверку способности приложения работать в указанном окружении. Здесь, например, может проверяться:
o Совместимость с аппаратной платформой, операционной системой и сетевой инфраструктурой (конфигурационное тестирование, configuration testing).