Итак, вы решили заняться тестированием ПО. Прекрасный выбор! Первый шаг к выбору (или смене) профессии уже сделан. Логичным вторым шагом было бы изучение теоретической части – без которой в любом деле никуда. Не имеет значения, техническое у вас образование или гуманитарное, есть у вас опыт работы, или вы студент – начинать нужно с получения теоретических знаний. Сегодня мы предлагаем вам узнать, какие виды тестирования программного обеспечения существуют.

Существует несколько подходов к классификации видов тестирования ПО. Рассмотрим самые распространенные.

1. Виды тестирования по целям

Согласно с тем, какие цели вы преследуете, тестируя то или иное приложение или программу, тестирование бывает:

• Функциональное;
• Нефункциональное.

Функциональное тестирование направлено на проверку того, какие функции программного продукта реализованы, и того, насколько верно они реализованы.

Нефункциональное – проверяет корректность работы нефункциональных требований. Этот вид тестирования скорее проверяет КАК программный продукт работает и включает в себя следующие виды:

• Тестирование производительности – проверяет как программный продукт работает под определенной нагрузкой. Включает в себя тестирование: > Нагрузочное – определяет, как программа работает под ожидаемой нагрузкой.

  > Стрессовое – определяет работоспособность программного продукта при максимальной нагрузке.

  > Тестирование стабильности – проверяет, выдержит ли программный продукт длительную нагрузку.

  > Конфигурационное – определяет, как программный продукт будет работать в условиях смены конфигурации (платформы, драйверов, компьютеров).

• Тестирование пользовательского интерфейса – определяет удобство пользовательского интерфейса (кнопки, цвета, выравнивание и т.д.).
• Тестирование удобства использования – проверяет, удобен ли программный продукт в использовании.
• Тестирование защищенности – определяет, насколько безопасно использование программного продукта, т.е. защищен ли программный продукт от атак хакеров, несанкционированного доступа к данным и т.д.
• Инсталляционное тестирование – проверяет, не возникает ли проблем при установке, удалении, а также обновлении программного продукта.
• Тестирование совместимости – тестирование работы программного продукта в определенном окружении.
• Тестирование надежности – проверяет работу приложения при длительной средней ожидаемой нагрузке.
• Тестирование локализации – тестирование локализованной версии программного продукта (языковой и культурный аспекты).

2. По степени автоматизации

В зависимости от того, используют ли тестировщики дополнительные программные средства для тестирования приложений или программ, тестирование бывает:

• Ручное – тестирование программного продукта без использования дополнительных программных средств, т.е. тестирование «вручную».
• Автоматизированное – тестирование программного продукта с использованием программных средств (более детально в описании ).

3. По позитивности сценария

По позитивности сценария тестирование бывает:

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

4. По доступу к коду программного продукта

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

• Тестирование «белого ящика» – тестирование программного продукта с доступом к коду.
• Тестирование «черного ящика» – тестирование без доступа к коду продукта.
• Тестирование «серого ящика» – тестирование, основанное на ограниченном знании внутренней структуры программного продукта. Часто говорят, что это смесь тестирования «белого ящика» и «черного ящика», но это в корне неверно. В данном случае тестировщик не работает с кодом программного продукта, но он знаком с внутренней структурой программы или приложения и взаимодействием между компонентами.

5. По уровню

По уровню тестирование бывает:

• Модульное / юнит-тестирование – проверка корректной работы отдельных единиц системы программного продукта. Этот вид тестирования могут выполнять сами разработчики.
• Интеграционное тестирование – проверка взаимодействия между несколькими единицами программного продукта.
• Системное – проверка работы всей системы на соответствие заявленным требованиям к программному продукту.

6. По исполнителю

Наверняка, вы слышали об альфа- и бета-тестировании. А поучаствовать в одном из них можно даже не будучи тестировщиком. Итак, по исполнителю тестирование делится на:

• Альфа-тестирование – тестирование программного продукта на поздней стадии разработки. Проводится разработчиками или тестировщиками.
• Бета-тестирование – тестирование программного продукта перед выходом на рынок силами обычных людей – добровольцев, которым передается предварительная версия продукта (бета-версия). Их отзывы собираются, анализируются и учитываются при внесении правок в продукт.

7. По формальности

По формальности тестирование бывает:

• Тестирование по тестам – тестирование по предварительно написанным тест-кейсам.
• Исследовательское тестирование – одновременная разработка тестов и их исполнение.
• Свободное тестирование – тестирование без разработки тестов, без документации. Основывается на интуиции и опыте тестировщика.

8. По важности

По степени важности тестируемых функций тестирование делится на:

• Дымное тестирование – проверка самой важной функциональности программного продукта.
• Тестирование критического пути – проверка функциональности, используемой типичными пользователями в повседневной деятельности.
• Расширенное тестирование – проверка всей заявленной функциональности.

Виды тестирования и подходы к классификации тестирования отличаются от автора к автору. Не существует единственного правильного варианта.

Надеемся, что данная статья поможет вам ориентироваться в самом начале вашего пути в тестировании программного обеспечения.

Тестирование (testing) программного обеспечения (ПО) - это процесс исследования ПО с целью выявления ошибок и определения соответствия между реальным и ожидаемым поведением ПО, осуществляемый на основе набора тестов, выбранных определённым образом. В более широком смысле, тестирование ПО - это техника контроля качества программного продукта, включающая в себя проектирование тестов, выполнение тестирования и анализ полученных результатов.

Очень часто современные программные продукты разрабатываются в сжатые сроки и при ограниченных бюджетах проектов. Программирование сегодня перешло из разряда искусства в разряд ремесел для многих миллионов специалистов. Но, к сожалению, в такой спешке разработчики зачастую игнорируют необходимость обеспечения защищённости своих продуктов, подвергая тем самым пользователей неоправданному риску. Контроль качества (тестирование) считается важным в процессе разработки ПО, потому что обеспечивает безопасность, надёжность, удобство создаваемого продукта. В настоящее время существует великое множество подходов и методик к решению задачи тестирования ПО, но эффективное тестирование сложных программных систем - процесс творческий, не сводящийся к следованию строгим и чётким правилам.

Уровни тестирования

Модульное тестирование - это процесс исследования ПО, при котором тестируется минимально возможный компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

• Википедия. Модульное тестирование .
• Модульное тестирование кода Visual C# в приложениях для Магазина Windows .

Интеграционное тестирование - это процесс исследования ПО, при котором тестируется интерфейсы между компонентами или подсистемами.

• Википедия. Интеграционное тестирование.

Системное тестирование - это процесс исследования ПО, при котором тестируется интегрированная система на её соответствие требованиям заказчика. Альфа и Бета тестирование относятся к подкатегориям системного тестирования.

Классификация видов тестирования

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

По объекту тестирования

Функциональное тестирование (functional testing) - тестирование ПО, направленное на проверку реализуемости функциональных требований. При функциональном тестировании проверяется способность ПО правильно решать задачи, необходимые пользователям.

• Википедия. Функциональное тестирование .
• StackOverflow. Unit tests vs Functional Testing .

Тестирование производительности (performance testing) - тестирование ПО, позволяющее осуществлять оценку быстродействия программного продукта при определённой нагрузке. Тест производительности выполняется до и после проведения оптимизации с целью выявить изменения в производительности. Если оптимизация не удается, и производительность снижается, то программист может отказаться от неудачной оптимизации. В случае повышения производительности величину этого повышения можно сравнить с ожидаемыми результатами, чтобы убедиться в успешности оптимизации. Задачей теста производительности является выявление фактов повышения и понижения производительности, чтобы можно было избежать неудачных модернизаций.

• Википедия. Тестирование производительности .

Нагрузочное тестирование (load testing) - тестирование ПО, позволяющее осуществлять оценку быстродействия программного продукта при плановых, повышенных и пиковых нагрузках. Осуществление нагрузочного тестирования перед вводом системы в промышленную эксплуатацию позволяет избегать неожиданных потерь в производительности через полгода - год, когда система будет заполнена данными.

• Википедия. Нагрузочное тестирование .

Стресс-тестирование (stress testing) - тестирование ПО, которое оценивает надёжность и устойчивость системы в условиях превышения пределов нормального функционирования. Это проверка программы в таких стрессовых ситуациях как наличие большого объёма входных параметров, нехватка дискового пространства или маломощный процессор.

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

• Википедия. Стресс-тестирование программного обеспечения .

Тестирование стабильности (stability/endurance/soak testing) - тестирование ПО, при котором проверяется работоспособность ПО при длительном тестировании со среднем уровнем нагрузки.

Тестирование безопасности (security testing) - тестирование ПО, которое проверяет фактическую реакцию защитных механизмов, встроенных в систему на проникновение злоумышленников.

• Википедия. Тестирование безопасности .
• Очир Абушинов: Особенности тестирования безопасности ПО .

Тестирование совместимости (compatibility testing) - тестирование ПО, которое проверяет работоспособность ПО в определенном окружении.

По знанию системы

Тестирование чёрного ящика (black box) - тестирование ПО, при котором тестировщик имеет доступ к ПО только через интерфейсы заказчика, либо через внешние интерфейсы, позволяющие другому компьютеру или процессу подключиться к системе для тестирования. Этот подход до сих пор является самым распространенным в повседневной практике, но у него есть целый ряд недостатков. Например, некоторые ошибки возникают достаточно редко и потому их трудно найти и воспроизвести.

• Википедия. Тестирование по стратегии чёрного ящика .

Тестирование белого ящика (white box) - тестирование ПО, при котором тестировщик имеет доступ к исходному коду програмы и может писать код, связанный с библиотеками тестируемого ПО. К тестированию белого ящика относят методики: чтения программ, формальные просмотры программ, инспекции. Этот метод позволяет заглянуть внутрь "чёрного ящика" и сосредоточиться на внутренней информации, которая и определяет поведение программы. Основной трудностью является сложность отслеживания вычислений времени выполнения. При тестировании программы происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей. Даже для средних по сложности программ число таких путей может достигать десятки тысяч.

• Википедия. Стратегия тестирования по принципу "Белого ящика" .

По времени проведения тестирования

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

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

Регрессионное тестирование (regression testing) - тестирование ПО, при котором проводится проверка ранее найденных ошибок, а также проверка основной функциональности. Проводится, как правило, на каждой новой версии программного продукта. Регрессивное тестирование является наиболее важной фазой тестирования непосредственно перед окончанием работ над продуктом, так как непосредственно перед релизом продукта крайне необходимо проверить не только основную функциональность, но и то, что ни одна из ранее найденных ошибок не повторяется в финальной версии. Являясь неотъемлемой частью функционального тестирования, регрессионное тестирование позволяет гарантировать, что изменения, связанные с устранением дефектов, не оказали негативного воздействия на остальные функциональные области приложения.

• Википедия. Регрессивное тестирование .

Дымовое тестирование (smoke testing) - тестирование ПО, при котором выполняется набор тестов, после которого можно сказать, что программный продукт запускается. Если ошибок при запуске не происходит, то дымовой тест считается пройденным. Если программа не прошла дымовой тест, то её отправляют на доработку. Дело в том, что разработчики пишут отдельные компоненты одного приложения, но когда эти компоненты объединяют, нередко получается так, что совместно они работать не могут, следовательно, нет смысла тестировать продукт в целом.

• Википедия. Smoke test .

По степени автоматизации

Ручное тестирование (manual testing) - тестирование при котором не используются программные средства для выполнения тестов и проверки результатов выполнения.

• Тестирование: Ручное или Автоматизированное ?

Автоматизированное тестирование (automated testing) - тестирование при котором используются программные средства для выполнения тестов и проверки результатов выполнения. Автоматизированное тестирование, несомненно, приносит пользу и экономит время и ресурсы компании.

В процессе разработки часто бывает так, что новая версия с исправленными ошибками выпускается каждый день, а иногда, и несколько раз в день. Дымовое тестирование прежде всего должно быть автоматизировано, потому что сразу после сборки новой версии программы нам необходимо в кратчайшие сроки убедиться в том, что программа запускается. Автоматический тест справится с подобной задачей за считанные секунды, и сборку можно будет считать успешной. Если же этим будет заниматься человек, то времени на проверку будет уходить гораздо больше. Таким образом, автоматизация дымового тестирования - это неплохая экономия времени отдела тестирования.

Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них: HP LoadRunner, HP QuickTest Professional, HP Quality Center, .

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

• Тестирование: Ручное или Автоматизированное ?

Динамический и статический анализ кода

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

Динамический анализ кода (runtime analysis) - способ анализа программы непосредственно при ее выполнении. При динамическом анализе проблемы в исходном коде находятся по мере их возникновения. Процесс анализа можно разбить на несколько этапов - подготовка исходных данных, проведение тестового запуска программы, сбор необходимых параметров и анализ полученных данных.

Андерклокинг - снижение частоты работы оборудования.

Баг (дефект) - недостаток компонента или системы, который может привести к отказу определенной функциональности.

Приоритет багов - важность той или иной ошибки в ПО:

• Trivial — косметическая малозаметная проблема.
• Minor — очевидная, незначительная проблема.
• Major — значительная проблема.
• Critical — проблема, нарушающая работу c ключевыми функциями ПО.
• Blocker — проблема, нарушающая функционирование ПО.

Баг-репорт - документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Валидация - определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

Верификация - процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа.

Спецификация - детальное описание того, как должно работать ПО.

Система отслеживания ошибок (англ. bug tracking system ) — программа учета и/или контроля багов:

• Atlassian JIRA
• Bugzilla
• YouTrack
• Redmine

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

Обеспечение качества (Quality Assurance, QA) - совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения

Отладка (англ.Debugging ) — процесс, позволяющий получить программное обеспечение, функционирующее с требующимися характеристиками в заданной области входных данных.

Ошибка (англ.Error ) – действие, которое порождает неправильный результат.

Сбой (англ.Failure ) – несоответствие фактического результата работы компонента или системы ожидаемому результату.

Классификация по типу тестирования:
Мобильное тестирование — тестирование мобильных приложений.
Консольное тестирование — тестирование приложений предназначенных для консолей.
Web-тестирование (Браузерное тестирование) — тестирование браузерных приложений.

Классификация по запуску кода на исполнение:
Статическое тестирование (англ.Static testing ) - тестирование без запуска кода на исполнение.
Динамическое тестирование (англ. Dynamic testing ) - тестирование с запуском кода на исполнение.

Классификация по доступу к коду и архитектуре ПО:
Черный ящик (англ. Black box ) — тестировщику не известно как устроена тестируемая система.
Белый ящик (англ. White box ) — тестировщику известно все детали реализации тестируемой системы.
Серый ящик (англ. Grey box ) — тестировщику известно только некоторые особенности устройства тестируемой системы.

Классификация по степени автоматизации:
Ручное тестирование (англ. Manual testing ) — тестирование ПО будучи его пользователем.
Автоматизированное тестирование (англ. Automated testing ) — тестирование ПО при помощи специальных программ.

Классификация по принципу работы с приложением:
Позитивное тестирование (англ. Positive testing ) — тестирование ПО на то, как оно должно работать.
Негативное тестирование (англ. Negative testing ) — тестирование ПО на то, как оно не должно работать.

Классификация по уровню детализации приложения:
Интеграционное тестирование — тестирование взаимодействия и связей нескольких компонентов приложения.
Системное тестирование — это тестирование всего приложения от начала и до конца.
Модульное тестирование — тестирование на уровне отдельного функционального компонента приложения.

Классификация по целям и задачам:
Функциональное тестирование - проверка корректности работы функциональности приложения.
Нефункциональное тестирование - проверка нефункциональных особенностей приложения (удобство использования, совместимость, производительность, безопасность).
Инсталляционное тестирование - проверка протекания стадии инсталляции (установки) приложения.
Регрессионное тестирование - проверка на наличие багов, вызванных изменениями в приложении.
Повторное тестирование - выполнение тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения устранения дефектов.
Приёмочное тестирование - тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика
Тестирование удобства использования - тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом, а также на то, насколько ему нравится использовать продукт.
Тестирование доступности - тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными возможностями
Тестирование интерфейса - тестирование, направленное на проверку интерфейсов приложения или его компонентов.
Тестирование безопасности - тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям
Тестирование интернационализации - тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей.
Тестирование локализации - тестирование, направленное на проверку корректности и качества адаптации продукта к использованию на том или ином языке с учётом национальных и культурных особенностей.
Тестирование совместимости - тестирование, направленное на проверку способности приложения работать в указанном окружении (браузер, мобильное ус-во и т.д.).
Тестирование данных и баз данных - тестирование, направленное на исследование таких характеристик данных, как полнота, непротиворечивость, целостность, структурированность и т.д.
Тестирование использования ресурсов - совокупность видов тестирования, проверяющих эффективность использования приложением доступных ему ресурсов и зависимость результатов работы приложения от количества доступных ему ресурсов.
Сравнительное тестирование - тестирование, направленное на сравнительный анализ преимуществ и недостатков разрабатываемого продукта по отношению к его основным конкурентам.
Демонстрационное тестирование - формальный процесс демонстрации заказчику продукта с целью подтверждения, что продукт соответствует всем заявленным требованиям.
Избыточное тестирование - тестирование приложения со всеми возможными комбинациями всех возможных входных данных во всех возможных условиях выполнения.
Тестирование надёжности - тестирование способности приложения выполнять свои функции в заданных условиях.
Тестирование восстанавливаемости - тестирование способности приложения восстанавливать свои функции и заданный уровень производительности, а также восстанавливать данные в случае возникновения критической ситуации.
Тестирование отказоустойчивости - тестирование, заключающееся в эмуляции или реальном создании критических ситуаций с целью проверки способности приложения задействовать механизмы, предотвращающие нарушение работоспособности, производительности и повреждения данных.
Тестирование производительности - исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке.
Нагрузочное тестирование - исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов/
Тестирование масштабируемости - исследование способности приложения увеличивать показатели производительности в соответствии с увеличением количества доступных приложению ресурсов.
Объёмное тестирование - исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.
Стрессовое тестирование - исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень.
Конкурентное тестирование - исследование поведения приложения в ситуации, когда ему приходится обрабатывать большое количество одновременно поступающих запросов, что вызывает конкуренцию между запросами за ресурсы (базу данных, память, канал передачи данных, дисковую подсистему и т.д.)
Фокус-тест (англ. Focus test ) — тестирование, проводимое с целью получения первичной реакции игроков. Необходимо для оценки удобства использования и того, как продукт принимается целевой аудиторией или сторонними людьми.

Failure - сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX (англ. User eXperience — опыт пользователя ) - ощущение, испытываемое пользователем во время использования цифрового продукта.

UI (англ. User Interface — пользовательский интерфейс ) - это инструмент, позволяющий осуществлять взаимодействие «пользователь - приложение».

Анализ граничных значений (англ. Boundary Value Analysis - BVA ). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Дымовое тестирование (англ. Smoke test ) — короткий цикл тестов для подтверждения, что после сборки кода (нового или исправленного) приложение стартует и выполняет основные функции.

Исследовательское (ad-hoc) тестирование - это разработка и выполнения тестов в одно и то же время, что является противоположностью сценарного подхода.

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

Матрица соответствия требований (англ. Traceability matrix ) - это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

Операционное тестирование (англ. Release Testing ). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес модели системы.

Предугадывание ошибки (англ. Error Guessing - EG ). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (англ. Cause/Effect - CE ). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие).

Санитарное тестирование - это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям.

Серьезность (англ. Severity ) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

Стадии разработки ПО - это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей.

Пре-альфа (англ. Pre-alpha ) — начальная стадия разработки. Период времени со старта разработки до выхода стадии Альфа. Также так называются программы, прошедшие стадию разработки, для первичной оценки функциональных возможностей в действии.

Альфа-тестирование (англ. Alpha testing ) - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

Бета-тестирование (англ. Beta testing ) - интенсивное использование почти готовой версии продукта с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю.

Релиз-кандидат или RC (англ. Release candidate ), Пре-релиз, иногда «гамма-версия» - стадия-кандидат на то, чтобы стать стабильной.

Релиз или RTM (англ. Release to manufacturing — промышленное издание ) - издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM (англ. Post-release to manufacturing ) - издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

Таблица принятия решений (англ. Decision table ) - инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте.

Тест-дизайн (англ. Test design ) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

Тест-план (англ. Test Plan ) - это документ, описывающий весь объем работ по тестированию, а также оценки рисков с вариантами их разрешения.

Тестирование взаимодействия (англ. Interoperability Testing ) - это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами.

Тестирование сборки (англ. Build Verification Test ) - тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования.

Тестирование пользовательского интерфейса (англ. UI Testing ) - тестирование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения.

Тестовый случай (англ. Test Case ) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Чек-лист (англ. Check list ) - это документ, описывающий что должно быть протестировано.

Эквивалентное Разделение (англ. Equivalence Partitioning - EP ). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.

Z-конфликт (англ. Z-fighting ) — наложение текстур друг на друга.

Оверклокинг (англ. Overclocking ) — процесс увеличения частоты (и напряжения) компонента компьютера сверх штатных режимов с целью увеличения скорости его работы.

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

1. Функциональные
2. Нефункциональные
3. Связанные с изменениями

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования : компонентном или модульном (Component/Unit testing) , интеграционном (Integration testing) , системном (System testing) и приемочном (Acceptance testing) . Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов:

Нефункциональные виды тестирования

Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены основные виды нефункциональных тестов:

• Все виды тестирования производительности :
  • нагрузочное тестирование (Performance and Load Testing)
  • стрессовое тестирование (Stress Testing)
  • тестирование стабильности или надежности (Stability / Reliability Testing)
  • объемное тестирование (Volume Testing)
• Тестирование на отказ и восстановление (Failover and Recovery Testing)

Связанные с изменениями виды тестирования

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

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

На рис. 12 представлено простое задание, взятое из Теста механической понятливости Беннета на техническое понимание. Испытуемого просят ответить на вопрос, кто из изображенных рабочих испытывает большую нагрузку и внести в бланк ответа соответствующую букву-А или В. Если испытуемый считает, что нагрузки равны, то он должен внести в бланк букву С. (рис. 12).

Рис. 12. Кто из рабочих испытывает большую нагрузку?

Данные тесты направлены на выявление знаний, опыта, накопленного испытуемым.

Рассмотрим некоторые задания на понимание пространственных взаимоотношений.

1. Тест механической понятливости Беннета

Стимульный материал представлен 70 несложными физико-техническими заданиями, большая часть которых представлена в виде рисунков. После текста вопроса (рисунка) следует три варианта ответа на него, причем только один из них является правильным. Испытуемому необходимо выбрать и указать правильный ответ, написав на отдельном листе номер задания и номер избранного ответа. Методика относится к так называемым тестам скорости. На общее выполнение всех заданий отводится 25 мин.

Допускается выполнение заданий в любой последовательности. Процедура подсчета получен-ных результатов достаточно проста и заключается в начислении 1-го балла за каждое правильно выполненное задание. Перевод в стандартные шкалы не производится, интерпретация осуществля-ется в соответствии с нормами, полученными на конкретной выборке испытуемых (рис. 13 а, б)

Задачи к тесту Беннета

Рис.13а. Задание 1

I. Если левая шестерня поворачивается в указанном стрелкой направлении, то в каком направлении будет поворачиваться правая шестерня?

3. Не знаю.

Рис. 13б. Задание 2

II. Какая гусеница должна двигаться быстрее, чтобы трактор поворачивался в указанном стрелкой направлении?

1. Гусеница А.

2. Гусеница В.

3. Не знаю.

2. Задачи на выявление особенностей технического воображения.

Задача 1. Дан чертеж, на котором изображена фигура: а) фасад (главный вид) и б) вид сверху. Необходимо начертить третий вид – сбоку, а затем дать общий вид (рис. 14).

Рис. 14. Чертеж фигуры

Примечание. Данная деталь имеет два варианта решения. Ответ дан в приложении №7.

Задача 2. Данная деталь состоит их двух частей. Со всех сторон виден разрез в виде «ласточкиного хвоста». Как ее можно разделить? (Имеется два варианта ответа) (рис. 15).

Рис. 15. Общий вид детали

Ответ дан в приложении № 8.

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

Задача 3. На представленных рисунках не все кирпичи видны. Подсчитайте, сколько кирпичей в каждом блоке (рис. 16).

Рис. 16. Фрагменты кирпичной кладки

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