Тестирование это метод

Тестирование это метод

Достоинства и недостатки метода тестов

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

Классификация:

1) по предмету тестирования:

а) интеллектуальные — позволяют измерить степень развития умственных способностей.

б) личностные — измерительные неинтеллектуальные проявления личности (эмоции, мотивы, свойства личности и т.п.)

2) По форме процедуры обследования:

а) Индивидуальные тесты

б) Групповые тесты

3) По характеру тестового материала:

а) бланковые тесты — тестирование в форме различных бланков;

б) аппаратурные тесты — используются компы, аудио и видео техника и т.п.

4) По особенностям использования тестов:

а) вербальные (словарные тесты)

б) практические (мануальные) — манипуляции предметами (составить фигуру и т.п.)

Характеристики психологических тестов

— Валидность – соответствие результатов теста той характеристике, для измерения которой он предназначен.

— Надёжность – свойство теста давать при повторном измерении близкие результаты. Надёжность как внутренняя согласованность – направленность всех элементов тестовой щкалы на измерение одного качества.

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

ДОСТОИНСТВА:

1. Стандартизация условий и результатов. Тестовые методики относительно независимы от квалификации исполнителя.

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

3. Количественный дифференцированный характер оценки. Дробность шкалы и стандартизованность теста позволяют рассматривать его как «измерительный инструмент», дающий количественную оценку измеряемым свойствам.

4. Оптимальная трудность. Профессионально сделанный тест состоит из заданий оптимальной трудности.

5. Надежность. тест охватывает основные разделы учебной тестируемой области знаний или проявления какого-то умения или способности.

6. Справедливость. Ее следует понимать как защищенность от предвзятости экзаменатора.

7. Возможность компьютеризации. Компьютеризация – это мощный инструмент обеспечения информационной безопасности (достоверности диагностики).

НЕДОСТАТКИ:

1) опасность «слепых» (автоматических) ошибок .

2) опасность профанации. Внешняя легкость проведения тестов привлекает людей, не желающих серьезно знакомиться с психодиагностикой

3) потеря индивидуального подхода, стрессогенность Тест предназначен для всех. Довольно вероятна возможность упустить уникальную индивидуальность нестандартного человека (тем более ребенка). Это чувствуют сами испытуемые, и это их нервирует – особенно в ситуации аттестационного тестирования, У людей с пониженной стрессо устойчивостью возникает даже определенное нарушение саморегуляции –они начинают волноваться и ошибаться в элементарных для себя вопросах

4) потеря индивидуального подхода, репродуктивность. Тесты знаний апеллируют прежде всего к стандартному применению готовых знаний;

5) отсутствие возможности раскрыть индивидуальность при наличии стандартных, заданных ответов

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

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

23. Проективные тестовые методики. Общая характеристика.

Проективные методики основаны на выявлении проекции по результатам эксперимента с последующим их анализом.

Особенности:

1. Особенностями стимульного материала;

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

2. Особенностями поставленной перед респондентом задачи;

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

3. Особенностями обработки и интерпретации результатов.

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

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

Для более точного исследования данные, полученные с помощью проективных методик, следует соотносить с данными, полученными с помощью других методов.

Классификация проективных методик (по Л.Франку)

1. Конститутивные. Требуется структурирование и оформление стимула; придание ему смысла.

Тест Роршаха; Словесный тест ассоциаций (Гальтон); тест «Словарь» (исследование индивидуального тезауруса, кругозора).

2. Конструктивные.

Создание из оформленных деталей осмысленного целого.

Тест Мира (232 модели предметов, распр. по 15 категориям (дома, деревья, животные и др. Необходимо создать «свой мир»). М. Ловенфельд. Сценотест (как игра в куклы).

3. Интерпретативные (интерпретационные). Необходимо истолковать какую-либо ситуацию, событие. ТАТ и его модификации.

4. Катартические. Психодрама.

5. Рефрактивные. Речь, почерк.

Далее – не по Франку.

6. Экспрессивные. Рисование на свободную или заданную тему.

7. Импрессивные. Предпочтение стимулов. Люшер, Сонди.

7. Аддитивные Завершение рассказа, ситуации, истории. Розенцвейг; Рука; Системный тест семьи Т.Геринга; Незаконченные предложения и их модификации.

Практические методы обучения

К практическим методам относят письменные упражнения — выполнение заданий по различным предметам. В ходе упражнений учащиеся применяют на практике полученные теоретические знания.

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

Вторую группу практических методов составляют лаб. опыты и практикумы.

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

Эти задания могут носить учебно-тренировочный характер. К ним относятся все работы в учебных мастерских по отработке умений работать с бумагой, картоном, деревом, металлом, материалом, пользоваться различными инструмента­ми, управлять станками и механизмами.

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

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

Во время использова­ния практических методов применяются приемы:

— постановки задания,

— планирования его выполнения,

— управления процессом выполнения,

— оперативного стимулирования,

— регулирования и контроля,

— анализа итогов практической работы,

— выявления причин недостатков,

— корригирования обучения для полного достижения цели.

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

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

Индуктивные и дедуктивные методы обучения

Индуктивные и дедуктивные методы обучения имеют важную особенность — способность раскры­вать логику движения содержания учебного материала.

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

И н д у к т и в н ы й м е т о д ( от частного к общему)

При использовании индуктивного метода обучения деятельность учителя и учащихся протекает следующим образом:

Преподаватель

1-й вариант

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

2-й вариант

Ставит перед учащимися проблемные задания, требую­щие самостоятельных рассуж­дений от частных положений к более общим, к выводам и обобщениям

Учащиеся

1-й вариант

Усваивают вначале частные факты, затем делают выводы и обобщения учебного характера

2-й вариант

Самостоятельно размышля­ют над фактами и делают доступные выводы и обобщения.

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

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

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

Д е д у к т и в н ы й м е т о д (от общего к частному)

При использовании дедуктивного метода деятельность учителя и учеников носит следующий характер:

Преподаватель

Вначале сообщает общее положение, формулу, закон, а затем постепенно начинает вы­водить частные случаи, более конкретные задачи

Учащиеся

Воспринимают общие поло­жения, формулы, законы, а затем усваивают следствия, вытекающие из них

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

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

Как видно из характеристики деятельности преподавателя и учеников, при использовании дедуктивного или индуктивного методов обучения применяются ранее описанные словесные, наглядные и практические методы, а также репродуктивные или проблемно-поисковые методы, но при этом содержание учебного материала раскрывается определенным логическим образом — индуктивно или дедуктивно.

Поэтому можно говорить:

— об индуктивно или дедуктивно построенной беседе,

— о репродуктив­но или поисково построенной практической работе,

— о проблемно и дедуктивно построенном рассказе и т. д.

Здесь мы еще раз убеждаемся в том, что “метод обучения” — понятие многоаспектное.

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

Организация и проведение тестовых испытаний

⇐ ПредыдущаяСтр 2 из 45

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

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

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

Наиболее благоприятное время для проведения тестирования – с 9 до 12 часов дня. Не рекомендуется проводить тестирование после занятий физической культурой и после значительной умственной нагрузки.

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

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

Во время работы студентов над тестом необходимо:

— проверить правильность заполнения исходных данных в бланке ответов;

— проследить за тем, чтобы учащиеся не делали пометок на тест-билете;

— исключить разговоры и общение учащихся;

— вовремя отвечать на вопросы, при этом ответы не должны служить подсказкой (т. е. допускаются лишь вопросы по оформлению ответа).

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

— владеет методологией тестирования;

— коммуникабелен, эмоционально уравновешен, тактичен;

— понимает цели и задачи тестирования.

Date: 2015-06-11; view: 552; Нарушение авторских прав

Понравилась страница? Лайкни для друзей:

QA (aнгл. Quality assurance — обеспечение качества) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания.
Баг (англ. Bug — насекомое) — ошибка в ПО из-за которой программа не выдает пользователю ожидаемый конечный результат.
Система отслеживания ошибок (англ. bug tracking system) — программа учета и/или контроля багов:

  • Atlassian JIRA
  • Bugzilla
  • YouTrack
  • Redmine
  • etc.

Приоритет багов (англ. Bug priority) — важность той или иной ошибки в ПО:

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

Тестирование — процесс по выявлению багов:

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

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

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

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

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

Классификация по целям и задачам:
Функциональное тестирование — проверка корректности работы функциональности приложения
Нефункциональное тестирование — проверка нефункциональных особенностей приложения (удобство использования, совместимость, производительность, безопасность).
Инсталляционное тестирование — проверка протекания стадии инсталляции (установки) приложения.
Регрессионное тестирование — проверка на наличие багов, вызванных изменениями в приложении.
Повторное тестирование — выполнение тест-кейсов, которые ранее обнаружили дефекты, с целью подтверждения устранения дефектов.
Приёмочное тестирование — тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика
Тестирование удобства использования — тестирование, направленное на исследование того, насколько конечному пользователю понятно, как работать с продуктом, а также на то, насколько ему нравится использовать продукт.
Тестирование доступности — тестирование, направленное на исследование пригодности продукта к использованию людьми с ограниченными возможностями
Тестирование интерфейса — тестирование, направленное на проверку интерфейсов приложения или его компонентов.
Тестирование безопасности — тестирование, направленное на проверку способности приложения противостоять злонамеренным попыткам получения доступа к данным или функциям
Тестирование интернационализации — тестирование, направленное на проверку готовности продукта к работе с использованием различных языков и с учётом различных национальных и культурных особенностей.
Тестирование локализации — тестирование, направленное на проверку корректности и качества адаптации продукта к использованию на том или ином языке с учётом национальных и культурных особенностей.
Тестирование совместимости — тестирование, направленное на проверку способности приложения работать в указанном окружении (браузер, мобильное ус-во и т.д.).
Тестирование данных и баз данных — тестирование, направленное на исследование таких характеристик данных, как полнота, непротиворечивость, целостность, структурированность и т.д.
Тестирование использования ресурсов — совокупность видов тестирования, проверяющих эффективность использования приложением доступных ему ресурсов и зависимость результатов работы приложения от количества доступных ему ресурсов.
Сравнительное тестирование — тестирование, направленное на сравнительный анализ преимуществ и недостатков разрабатываемого продукта по отношению к его основным конкурентам.
Демонстрационное тестирование — формальный процесс демонстрации заказчику продукта с целью подтверждения, что продукт соответствует всем заявленным требованиям.
Избыточное тестирование — тестирование приложения со всеми возможными комбинациями всех возможных входных данных во всех возможных условиях выполнения.
Тестирование надёжности — тестирование способности приложения выполнять свои функции в заданных условиях
Тестирование восстанавливаемости — тестирование способности приложения восстанавливать свои функции и заданный уровень производительности, а также восстанавливать данные в случае возникновения критической ситуации.
Тестирование отказоустойчивости — тестирование, заключающееся в эмуляции или реальном создании критических ситуаций с целью проверки способности приложения задействовать механизмы, предотвращающие нарушение работоспособности, производительности и повреждения данных.
Тестирование производительности — исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке.
Нагрузочное тестирование — исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов
Тестирование масштабируемости — исследование способности приложения увеличивать показатели производительности в соответствии с увеличением количества доступных приложению ресурсов.
Объёмное тестирование — исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.
Стрессовое тестирование — исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень.
Конкурентное тестирование — исследование поведения приложения в ситуации, когда ему приходится обрабатывать большое количество одновременно поступающих запросов, что вызывает конкуренцию между запросами за ресурсы (базу данных, память, канал передачи данных, дисковую подсистему и т.д.)
Фокус-тест (англ. Focus test) — тестирование, проводимое с целью получения первичной реакции игроков. Необходимо для оценки удобства использования и того, как продукт принимается целевой аудиторией или сторонними людьми.
Error — ошибка пользователя, то есть он пытается использовать программу иным способом.
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.
UX (англ. User eXperience — опыт пользователя) — ощущение, испытываемое пользователем во время использования цифрового продукта
UI (англ. User Interface — пользовательский интерфейс) — это инструмент, позволяющий осуществлять взаимодействие «пользователь — приложение».
Анализ Граничных Значений (англ. Boundary Value Analysis — BVA). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Баг Репорт (англ. Bug Report — отчет об ошибке) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Валидация (англ. validation — проверка) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.
Верификация (англ. verification — подтверждение) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа.
Дымовое тестирование (англ. 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), Пре-релиз или Pre, иногда «гамма-версия» — стадия-кандидат на то, чтобы стать стабильной.
Релиз или 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) — процесс увеличения частоты (и напряжения) компонента компьютера сверх штатных режимов с целью увеличения скорости его работы.
Андерклокинг (англ. Underclocking) — противоположный оверклокингу процесс для снижения частоты компонентов компьютера с целью уменьшения выделения тепла, шума и нестабильности.

Определения тестирования

В разное время и в различных источниках тестированию давались различные определения, в том числе:

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

История

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

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

В начале 1970-х годов тестирование программного обеспечения обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы программного обеспечения». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования программного обеспечения. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приёмо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в программах, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки программного обеспечения.

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

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

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

> Стандарты, относящиеся к тестированию

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

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

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

  • Функциональное тестирование
  • Тестирование производительности
    • Нагрузочное тестирование
    • Стресс-тестирование
    • Тестирование стабильности
  • Конфигурационное тестирование
  • Юзабилити-тестирование
  • Тестирование безопасности
  • Тестирование локализации
  • Тестирование совместимости

По знанию внутреннего строения системы

  • Тестирование чёрного ящика
  • Тестирование белого ящика
  • Тестирование серого ящика

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

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

По степени изолированности

  • Тестирование компонентов
  • Интеграционное тестирование
  • Системное тестирование

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

  • Альфа-тестирование
    • Дымовое тестирование (англ. smoke testing)
    • Тестирование новой функции (new feature testing)
    • Подтверждающее тестирование
    • Регрессионное тестирование
    • Приёмочное тестирование
  • Бета-тестирование

По признаку позитивности сценариев

  • Позитивное тестирование
  • Негативное тестирование

По степени подготовленности к тестированию

  • Тестирование по документации (формальное тестирование)
  • Интуитивное тестирование (англ. ad hoc testing)

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

  • Тестирование компонентов — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто тестирование компонентов осуществляется разработчиками программного обеспечения.
  • Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
  • Системное тестирование — тестируется интегрированная система на её соответствие требованиям.
    • Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программа.
    • Бета-тестирование — в некоторых случаях выполняется распространение предварительной версии (в случае проприетарного программного обеспечения иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

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

Тестирование «белого ящика», «чёрного ящика» и «серого ящика»

В зависимости от доступа разработчика тестов к исходному коду тестируемой программы различают «тестирование (по стратегии) белого ящика» и «тестирование (по стратегии) чёрного ящика».

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

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

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

Покрытие кода

Основная статья: Покрытие кода

Покрытие кода показывает процент исходного кода программы, который был выполнен («покрыт») в процессе тестирования. По способам измерения выделяют покрытие операторов, покрытие условий, покрытие путей, покрытие функций и др.

> См. также

  • Разработка через тестирование
  • Система отслеживания ошибок
  • Аутсорсинг тестирования программного обеспечения
  • Внесение неисправностей

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *