Область применения тестирования: Основные положения тестирования / Хабр

Основные положения тестирования / Хабр

Области применения, цели и задачи тестирования ПО разнообразны, поэтому тестирование оценивается и объясняется по-разному. Иногда и самим тестировщикам бывает сложно объяснить, что такое тестирование ПО ‘as is’. Возникает путаница.

Для распутывания этой путаницы Алексей Баранцев (практик, тренер и консалтер в тестировании ПО; выходец из Института системного программирования Российской академии наук) предваряет свои тренинги по тестированию вводным видео про основные положения тестирования.

Мне кажется, что в этом докладе лектор смог наиболее адекватно и взвешенно объяснить «что такое тестирование» с точки зрения ученого и программиста. Странно, что этот текст еще не появлялся на хабре.

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

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

Уважаемые коллеги,

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

Тестирование не разработка,

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

Тем не менее, тестирование — это не деятельность по разработке программного обеспечения.

Тестирование не анализ,

и не деятельность по сбору и анализу требований.

Хотя, в процессе тестирования иногда приходится уточнять требования, а иногда приходится их анализировать. Но эта деятельность не основная, скорее, это приходится делать просто по необходимости.

Тестирование не управление,

несмотря на то, что во многих организациях есть такая роль, как «тест-менеджер». Конечно же, тестировщиками надо управлять. Но само по себе тестирование управлением не является.

Тестирование не техписательство,

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

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

Деятельность значима только тогда, когда она востребована, то есть тестировщики должны что-то производить «на экспорт». Что они делают «на экспорт»?

Дефекты, описания дефектов, или отчеты о тестировании? Частично это правда.

Но это не вся правда.

Главная деятельность тестировщиков

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

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

Но эта вещь очень значимая, и, наверное, единственная наиболее значимая составляющая деятельности тестировщиков.

Существует наука — «теория систем». В ней определяется такое понятие как «обратная связь».

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

И та, и другая разновидности обратной связи равноценно важны.

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

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

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

К слову, отсюда и произрастает понимание того, что тестировщики не отвечают за качество. Они помогают тем, кто за него отвечает.

Синонимы термина «тестирование»

С точки зрения того, что тестирование — это предоставление отрицательной обратной связи, всемирно известная аббревиатура QA (англ. Quality Assurance — Обеспечение качества) синонимом термина «тестирование» уж совершенно точно НЕ является.

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

А вот «контроль качества» — Quality Control, можно считать в широком смысле синонимом для термина «тестирование», потому что контроль качества это и есть предоставление обратной связи в самых разных ее разновидностях, на самых разных этапах программного проекта.

Иногда тестирование подразумевается как некоторая отдельная форма контроля качества.

Путаница приходит из истории развития тестирования. В разное время под термином «тестирование» подразумевались различные действия, которые можно разделить на 2 больших класса: внешние и внутренние.

Внешние определения

Определения, которые в разное время дали Майерс, Бейзер, Канер, описывают тестирование как раз с точки зрения его ВНЕШНЕЙ значимости. То есть, с их точки зрения, тестирование — это деятельность, которая предназначена ДЛЯ чего-то, а не состоит из чего-то. Все три этих определения можно обобщить как предоставление отрицательной обратной связи.

Внутренние определения

Это определения, которые приведены в стандарт терминологии, используемой в программной инженерии, например, в стандарт де-факто, который называется SWEBOK.

Такие определения конструктивно объясняют, ЧТО представляет из себя деятельность по тестированию, но не дают ни малейшего представления о том, ДЛЯ ЧЕГО нужно тестирование, для чего потом будут использоваться все полученные результаты проверки соответствия между реальным поведением программы и ее ожидаемым поведением.

Итак,

тестирование — это

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

Отсюда и далее будем считать это рабочим определением «тестирования».

Общая схема тестирования примерно следующая:

1. Тестировщик на входе получает программу и/или требования.
2. Он с ними что-то делает, наблюдает за работой программы в определенных, искуственно созданных им ситуациях.
3. На выходе он получает информацию о соответствиях и несоответствиях.
4. Далее эта информация используется для того, чтобы улучшить уже существующую программу. Либо для того, чтобы изменить требования к еще только разрабатываемой программе.

Что такое тест

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

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

Разработчик тестов занимается тем, что он из огромного потенциально бесконечного набора тестов выбирает некоторый ограниченный набор.

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

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

2.И, во-вторых, он наблюдает за поведением программы и сравнивает то, что он видит с тем, что ожидается.

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

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

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• пользовательский,
• графический,
• текстовый,
• консольный,
• и речевой.

Используя все эти интерфейсы, тестировщик:

• каким-то образом создает искусственные ситуации,
• и проверяет в этих ситуациях как программа себя ведет.

Вот это и есть тестирование.

Другие классификации видов тестирования

Чаще всего используется разбиение на три уровня, это

1. модульное тестирование,
2. интеграционное тестирование,
3. системное тестирование.

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

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

Иногда используются также некоторые другие термины, такие, как «компонентное тестирование», но я предпочитаю выделять именно эти три, по причине того, что технологическое разделение на модульное и системное тестирование не имеет большого смысла. На разных уровнях могут использоваться одни и те же инструменты, одни и те же техники. Разделение условно.

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

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

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

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

Комбинируем:

То есть, можно говорить о модульном тестировании функциональности.

Можно говорить о системном тестировании функциональности.

Можно говорить о модульном тестировании, например, эффективности.

Можно говорить о системном тестировании эффективности.

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

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

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

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

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

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

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

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

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

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

Так вот, исходя из классификации по целям, модульное тестирование у нас оказывается в левом нижнем квадранте, а все остальные квадранты — это системное тестирование.

Спасибо за внимание.

Дополнительно

• Полная расшифровка текста со всеми картинками. Рассказывается о тестировании методом черного и белого ящика, о шести аспектах качества верхнего уровня (функциональность, надежность, практичность, эффективность, сопровождаемость, переносимость), о критериях полноты тестирования.
• Видео-версия доклада: тут (ее можно и смотреть, и скачать как .wmv).
• Если интересно: проводится распродажа записей вебинаров Баранцева.

Область применения психологического тестирования — МегаЛекции

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

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

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

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

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

В нейрофизиологии проводятся нейропсихологические исследования взаимодействия мозговых патологий с поведением человека. Установлено влияние возраста на поведенческие эффекты, к которым приводит поражение мозга.

№3. Основные понятия психодиагностики: психологическая диагностика, психологический диагноз, прогноз, психологические методы и методики.

1. Основные понятия психодиагностики: психологическая диагностика, психологический диагноз, прогноз, психологические методы и методики.

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

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

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

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

По Выготскому эффективность прогноза зависит от умения глубоко понять внутреннюю логику процесса развития и на основе прошлого и настоящего наметить путь развития.

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

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

Психологическийдиагноз — этоописаниеиндивидуальныхособенностейпсихики конкретного человека (илисоциально-психологическихособенностейконкретнойсоциальнойгруппы).

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

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

Под структурированностью психологического диагноза понимается приведение разнообразных параметров психического состояния человека в определенную систему: они группируются по уровню значимости, по родственности происхождения, по возможным линиям причинного взаимовлияния. Взаимоотношения различных параметров в структурированном диагнозе специалисты отображают в форме ДИАГНОСТОГРАММ.

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

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

Понимание уровня общности заданных в методике диагностических категорий необходимо, в частности, для обоснованного выбора глубины прогноза по результатам диагностики. Более обобщенные диагностические свойства обладают более «широким ПОЛЕМ ПРОГНОЗА» (в психометрике это также называется «областью валидности» теста). Но важно учитывать, что при увеличении «ширины» поля прогноза точность прогноза, как правило, снижается.

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

№4. Методологические основы психологической диагностики: комплексный метод изучения и диагностики психического развития, структурно-системный метод изучения и диагностики психического развития, показатели общего психического развития.

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

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

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

3) Показателей психического развития.

а) показатели общего псих развития (базовые) – развитие ведущей направленности, развитие структуры деятельности, развитие психологических механизмов сознания;

б) показатели умственного развития – действия с особым абстрактно-обобщенным содержанием, использование средств замещающих реальное предметное действие, выполнение действия во внутреннем плане;

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

№5. Выбор и применение психодиагностических методов и методик. Требования, предъявляемые к пользователям психодиагностических методик.

1. Выбор и применение психодиагностических методов и методик. Требования, предъявляемые к пользователям психодиагностических методик.

Методика определяется исходя из целей и задач диагностики.

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

Методики должны быть из проверенных источников.

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

Рекомендуемые страницы:

Воспользуйтесь поиском по сайту:

Области применения тестов — Студопедия

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

Тест — проба, испытание (перевод).

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

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

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

Метод социометрии называют иногда тестом, тк он позволяет определить состояние коллектива.

Концепция тестирования лежит в основе всех тестах, но прилагается по-разному.

Общие предпосылки:

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

· Между внешней (поведенческой) чертой и внутренним свойством личности существует однозначная причинная зависимость: наблюдаемое действие или реакция человека порождены определенным личностным свойством и только им. [тест на ложь].

· Измеряемые тестами черты или характеристики и соответственно получаемые результаты распределены среди большой совокупности людей достаточно равномерно. Это означает, что тест должен оценивать не только конкретного человека, но и применим к большой совокупности людей. Последнее требование отражается в понятии норма теста. Под ней понимается средний уровень развития большой совокупности людей, похожих на данного испытуемого по ряду социально демографических характеристик. График показывает нормальное распределение и границы нормы, которые могут меняться. Норма подвижна и она задается. Кем — зависит от задач. Она может быть задана управленцами, этически и тп. Может задаваться эмпирически. Без системы задания и оценки нормы тест становится бесполезной процедурой.

Характеристики тестов:

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

· Норма теста. Под нормой понимается распределение респондентов на кривой, которая отражает его выполнение большой группой респондентов. Как правило, по существующим опытным нормам эта группа должна быть не менее тысячи респондентов. Иногда 2000+ респондентов. Эта кривая имеет, как правило, вид нормального распределения. Середина этой кривой отражает ту норму, которая характерная для данной социальной совокупности. Ее принимают как основу нормы. Норма теста отражает его репрезентативность, или свойство выборочной совокупности людей представлять генеральную совокупность.

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

· Надежность — эта характеристика теста отражает степень точности и постоянства, с которой измеряется та или иная характеристика, а также меру его погрешности. Точность проверяется либо повтором того же теста через какое-то время. Второй способ — проверка по идентичному или аналогичному тесту. Это требует огромной работы по созданию идентичных тестов. Но нужно подобрать, чтобы идентичный тест был бы с таким же распределением. Надежность теста оеделыется, как правило, коэффициентами от 0 до 1. Есть некие конвенциональные соглашения, когда считается, что надежность теста в 0,9 — это блестяще. До 0,8 результаты считаются хорошими. Результат 0,7 считается приемлемым (адекватным). Если ниже — его рекомендуется использовать как дополнительный метод и очень ограничено.

· Научность теста всегда связана с его базированнотью, свызанностью, с той или иной теорией.

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

Области применения и разновидности тестов — Мегаобучалка

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

¹ Что касается ясных и убедительных иллюстраций потенциальных вкладов психологических тестов с примерами из реальной жизни, см. Dahlstrom (1993b).

Глава 1. Природа и назначение психологических тестов

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

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

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

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

Часть 1. Функции и истоки психологического тестирования

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

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

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

Область применения психологического тестирования.

Нужна помощь в написании работы?

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

Поможем написать любую работу на аналогичную
тему

Получить выполненную работу или консультацию специалиста по вашему
учебному проекту

Узнать стоимость

Поделись с друзьями

Немного о простом. Тест-дизайн. Часть 1 / Хабр

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

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

Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.

Почему?

Потому что тестировщики ничего не делают, им не нужны знания. Тестировать может каждый!

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

Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете??? (ответы можете оставить в комментариях) Ну да ладно, продолжим:)

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

Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите довольное лицо Заказчика (ну или продукт овнера) качество задачи после внедрения.

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

И в этом цикле статей поговорим об этом.

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

Выглядит это так:

• Зачем нам нужны техники тест-дизайна?
• Чтобы правильно определить проверки для тестирования.
• А используете ли Вы их в работе?
• В явном виде нет, мы сами определяем то, что нужно проверить.

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

Ответ прост.

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

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

Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это использовать эти правила всегда и везде 🙂 уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!

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

• Анализ требований и рисков тестирования
• Определение проверок для тестирования
• Формализация проверок в виде тестовых сценариев
• Приоритезация проверок
• Определение подходов к тестированию

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

Итак, начнем.

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

Это классы эквивалентности и граничные значения.

Что же такой классы эквивалентности?

Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.

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

Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.

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

Рассмотрим пример:

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

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Мы определяем 2 основных класса – это позитивные и негативные сценарии.

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

Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +

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

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

Итого мы имеем.

• Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть любыми из данного диапазона класса)
• Негативные проверки: 0, 3, -1, А и т.д.

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

Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.

• Первый уровень – проверка элементов системы (например, полей, чекбоксов, кнопок и т.д.)
• Второй уровень – проверка логики работы системы при комбинации данных в элементах системы
• Третий уровень – проверка бизнес- процесса системы и логики работы программы.

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

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

Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.

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

Вроде все просто!

Вернемся к нашему примеру ранее.

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

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Что же здесь будет границей?

Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так 🙂

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

Поэтому, помимо граничного значения мы используем для тестирования дополнительно 2 значения, значение перед границей и значение после границы.

В итоге мы имеем:

Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.

Также, у нас есть негативный класс, это от 0 до 18. Поэтому тут мы тоже должны использовать для тестирования граничные значения: -1, 0, 1, 17,18

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

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.

Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).

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

Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).

Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.

Техники тест-дизайна 1-го уровня достаточно просты и понятны. Я думаю, вы скажете, да это легко, но зачем досконально проверять каждый элемент. И будете правы!..

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

Что ж, слишком легко??? Сейчас начнем разбирать более сложные техники, готовьтесь.

Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.

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

Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.

Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.

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

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

Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.

Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.

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

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

Давайте рассмотрим на примере функциональности дистанционного оформления карты в банке.

Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:

• ФИО
• Дата рождения
• Мобильный телефон
• Серия номер паспорта
• Электронная почта,
• а также 2 чек-бокса.

Наша задача, используя техники первого уровня определить перечень классов эквивалентности, которые может принимать программа.

Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.

Итак,

Поле ФИО может принимать значения (классы):

• ФИО на русском
• Невалидное значение
• Пустое значение

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

Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

• Валидное значение
• Невалидное значение
• Пустое значение

Т.к. электронная почта необязательно, то данное поле имеет 2 значения:

• Валидное значение
• Невалидное значение

Чек-боксы обычно имеют всего 2 состояния – Y или N.

Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!

Магия, не думаю:)

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

Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:

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

Таким образом мы получаем 9 тестов с конкретными классами эквивалентности, которые мы можем вводить для проверки работы вариативности данных для формы. Классы мы можем заполнять конкретными значениями, которым мы получаем с вами используя 1 уровень техник тест-дизайна.

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

Надеюсь было полезно!

Тестирование

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

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

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

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

Ссылки:

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

Ссылки:

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

Ссылки:

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

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

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

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

Ссылки:

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

Ссылки:

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

Ссылки:

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

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

Ссылки:

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

Ссылки:

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

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

Ссылки:

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

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

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

Ссылки:

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

Ссылки:

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

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

Ссылки:

Альфа тестирование.

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

Ссылки:

Википедия. Бета-тестирование.

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

Ссылки:

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

Ссылки:

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

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

Ссылки:

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

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

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

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

Ссылки:

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

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

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

Ссылки:

Статический анализ кода (static analysis) — анализ программы, производимый без реального выполнения исследуемых программ. Статический анализ кода позволяет обнаружить дефекты в исходном коде до того, как код будет готов для запуска.

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

Ссылки:

Библиографический список

• Википедия. Тестирование программного обеспечения.
• Тестирование программных средств.
• Процесс, который алмазы точит.
• Брауде Э. «Технология разработки программного обеспечения». — СПб.: Питер, 2004. — 655 с., ISBN 5-94723-663-X, 0-47132-208-3
• Винниченко «Автоматизация процессов тестирования». — СПб.: Питер, 2004. — 655 с., ISBN: 5-469-00798-7.
• Канер «Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений». Изд-во ДиаСофтр, 2001. — 544 с., ISBN 966-7393-87-9, 1-85032-847-1.
• Элфрид Дастин, Джефф Рэшка, Джон Пол «Автоматизация тестирования программного обеспечения». Изд-во М.: ЛОРИ. — 590 стр., ISBN: 5-85582-186-2.

Область тестирования

| test IO Academy

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

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

Тестовая среда

Перво-наперво — URL-адрес, указанный в разделе Access в верхней части страницы обзора теста, определяет, какой веб-сайт или приложение следует протестировать. Любые другие веб-сайты или приложения не тестируются (если иное не указано в описании теста). Дополнительные сведения см. В разделе «Среда тестирования».

Вы можете увидеть информацию о доступе только после запуска теста (обратите внимание на обратный отсчет вверху).

Функции

Каждый тест содержит по крайней мере одну из так называемых функций .Функция может описывать область продукта, например целевая страница, страница обзора продукта или страница сведений о продукте в интернет-магазине, она может описывать такой процесс, как процесс оформления заказа на веб-сайте или в приложении, или даже может быть определенной функциональностью, которую следует протестировать. Например:

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

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

Типы и уровни серьезности ошибок

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

Если тип / серьезность ошибки не указан там, вы не сможете выбрать ее в форма ошибки, и, таким образом, выходит за рамки .Например. если в таблице выплат не указан тип ошибки Visual , вы не можете сообщать о визуальных ошибках.

Инструкции по тестированию

Инструкции по тестированию отображаются под разделом Access и состоят из трех разделов:

• Цель этого теста : Этот раздел обычно охватывает общую цель теста. Часто упоминается, на чем следует сосредоточиться, например новая функция, которая скоро будет выпущена.
• Вне области : Здесь конкретно указано, что не должно проходить тестирование.На действующих веб-сайтах вы часто можете не выполнять заказы в конце процесса оформления заказа, или некоторые области веб-сайта или приложения могут быть еще не готовы. Обязательно придерживайтесь этой информации — игнорирование их может иметь большие последствия.
• Дополнительные требования : Если есть что-то еще, на что следует обратить внимание, информация будет предоставлена ​​в этом разделе. Это может быть информация, касающаяся всего теста, учетных данных для учетных записей пользователей, фиктивной платежной информации и т. Д.

Вложения

В редких случаях может быть предоставлено одно или несколько вложений. Обычно это электронные таблицы Microsoft Excel или файлы PDF, предоставляемые клиентом напрямую.

Запрошенные устройства

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

Если места для запрошенного устройства заняты, вы можете присоединиться к тесту с другим устройством. На странице «Отправить сообщение об ошибке» вы можете проверить, с каким устройством вы участвуете в тесте.

Информация для чата

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

Вне объема означает, что что-то не подлежит тестированию.Обратите внимание, что следующие моменты всегда выходят за рамки (если иное не указано в описании теста):

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

Проблемы установки

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

• URL-адрес, указанный в разделе тестовой среды теста, неверен (404).
• Доступ к тестовой среде возможен только с учетными данными, но они не указаны или данные не работают.
• Невозможно загрузить или установить приложение.
• Клиент предоставил учетные данные для входа в учетные записи пользователей, но они не работают.
• Ссылка в промежуточной среде перенаправляет на их действующий веб-сайт.Ссылка не была обновлена ​​для указания на промежуточную среду во время настройки тестовой среды.
• Требования к устройству для испытания, например: перечислите iOS 9, но тестируемое приложение можно установить только на iOS 10 и выше.

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

Предоставление такой информации помогает нам улучшить настройки будущих тестов.

Почему информация иногда бывает непоследовательной?

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

.

What is, How to Create (with Example)

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing
    • Database Testing
    • Database Testing
    • Назад
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад

    ALPHA

    • 000
    • 0007 Центр контроля качества
    • SoapUI
    • Управление тестированием
    • TestLink

• SAP

  • • Назад
    • ABAP
    • APO
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • QMO
    • QM4
    • Заработная плата
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • Учебники SAP
  • 8

  Apache

  • AngularJS
  • ASP.Net
  • C
  • C #
  • C ++
  • CodeIgniter
  • СУБД
  • JavaScript
  • Назад
  • Java
  • JSP
  • Kotlin
  • Linux
  • Linux
  • Kotlin
  • Linux

  js

  • Perl
  • Назад
  • PHP
  • PL / SQL
  • PostgreSQL
  • Python
  • ReactJS
  • Ruby & Rails
  • Scala
  • SQL

  000

  0004 SQL

  • UML
  • VB.Net
  • VBScript
  • Веб-службы
  • WPF