Тест метод: Метод тестов — Студопедия

Метод тестов — Студопедия

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

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

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

Одна из самых первых попыток разработать тесты была сделана Ф. Гальтоном (1822-1911). Тесты и статические методы, предложенные Ф. Гальтоном, в дальнейшем получили применение для решения практических вопросов жизни и послужили началом создания прикладной психологии, получившей название «психотехника». Этот термин вошел в лексикон ученых после публикации статьи Д. Кеттелла (1860-1944). «Психология, – пишет в этой статье Кеттелл, – не сможет стать прочной и точной, как физические науки, если не будет базироваться на эксперименте и измерении. Шаг в этом направлении может быть сделан путем применения серии умственных тестов к большому числу людей. Результаты могут иметь значительную научную ценность в открытии постоянства психических процессов, их взаимозависимости и измерений в различных обстоятельствах».

В 1905 г. французский психолог А. Бине создал один из первых психологических тестов – тест для оценки интеллекта.

Впоследствии различными учеными создаются целые серии тестов. Их направленность на оперативное решение практических задач обусловила быстрое и широкое распространение психологических тестов. Например, Г. Мюнстерберг (1863-1916) предложил тесты для профессионального отбора, которые создавались следующим образом: первоначально они проверялись на группе рабочих, достигших лучших результатов, а затем им подвергались вновь принимаемые на работу.

В период Первой мировой войны использование психологических тестов приобрело массовый характер. Так, в США военные власти обратились к крупнейшим психологам страны Э. Торндайку (1874-1949), Р. Йерксу (1876-1956) и Г. Уипплу (1878-1976) с предложением возглавить решение проблемы применения психологии в военном деле. Американская психологическая ассоциация и университеты быстро развернули работу в этом направлении.

Разработка тестов как психологического метода осуществлялась и в России. Развитие данного направления в отечественной психологии того времени связано с именами А. Ф. Лазурского (1874-1917), Г. И. Россолимо (1860-1928), В. М. Бехтерева (1857-1927), а также П. Ф. Лесгафта (1837-1909).

Особенно заметный вклад в разработку тестовых методов был внесен Г. И. Россолимо. Для диагностики индивидуальных психических свойств он разработал методику их количественной оценки, дающую целостное представление о личности. Методика позволяла оценить 11 психических процессов, которые, в свою очередь, разбивались на пять групп: внимание, восприимчивость, воля, запоминание, ассоциативные процессы (воображение и мышление).

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

Существуют различные варианты тестов: тест-опросник, тест-задание, проективные тесты.

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование. Фундаментальная теория / Хабр

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

Ниже основы основ для повторения перед собеседованием для Trainee and Junior: определение тестирования, качество, верификация / валидация, цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix, test case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию, принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.

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

Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [Quality management and quality assurance]

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа[IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

Также можно встретить иную интерпритацию:

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

Validation — ’is this the right specification?’.

Verification — ’is the system correct to specification?’.

Цели тестирования

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

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

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

Этапы тестирования:

1. Анализ продукта

2. Работа с требованиями

3. Разработка стратегии тестирования

и планирование процедур контроля качества

4. Создание тестовой документации

5. Тестирование прототипа

6. Основное тестирование

7. Стабилизация

8. Эксплуатация

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

Отвечает на вопросы:

Что надо тестировать?

Что будете тестировать?

Как будете тестировать?

Когда будете тестировать?

Критерии начала тестирования.

Критерии окончания тестирования.

Основные пункты тест плана

В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план:

a) Test plan identifier;

b) Introduction;

c) Test items;

d) Features to be tested;

e) Features not to be tested;

f) Approach;

g) Item pass/fail criteria;

h) Suspension criteria and resumption requirements;

i) Test deliverables;

j) Testing tasks;

k) Environmental needs;

l) Responsibilities;

m) Staffing and training needs;

n) Schedule;

o) Risks and contingencies;

p) Approvals.

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

Роли, ответственные за тест дизайн:

• Тест аналитик — определяет «ЧТО тестировать?»

• Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

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

• Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

• Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — это «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

• Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тестировщик будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

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

• Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей — получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол — мужской или женский; возраст — до 25, от 25 до 60, более 60; наличие детей — да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:

А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

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

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

Матрица соответствия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

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

Пример:

Action Expected Result Test Result

(passed/failed/blocked)

Open page «login» Login page is opened Passed

Каждый тест кейс должен иметь 3 части:

PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.

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

PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

Виды Тестовых Сценариев:

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

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

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

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

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

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

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

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

В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

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

Шапка

Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Проект (Project) Название тестируемого проекта

Компонент приложения (Component) Название части или функции тестируемого продукта

Номер версии (Version) Версия на которой была найдена ошибка

Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:

• S1 Блокирующий (Blocker)

• S2 Критический (Critical)

• S3 Значительный (Major)

• S4 Незначительный (Minor)

• S5 Тривиальный (Trivial)

Приоритет (Priority) Приоритет дефекта:

• P1 Высокий (High)

• P2 Средний (Medium)

• P3 Низкий (Low)

Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта

Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы

Окружение

ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.

…

Описание

Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению

Ожидаемый результат (Expected Result) Ожидаемый правильный результат

Дополнения

Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Severity vs Priority

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

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

Severity выставляется тестировщиком

Priority – менеджером, тимлидом или заказчиком

Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)

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

S2 Критическая (Critical)

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

S3 Значительная (Major)

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

S4 Незначительная (Minor)

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

S5 Тривиальная (Trivial)

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

Градация Приоритета дефекта (Priority)
P1 Высокий (High)

Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)

Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)

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

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

1. Модульное тестирование (Unit Testing)

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

2. Интеграционное тестирование (Integration Testing)

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

3. Системное тестирование (System Testing)

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

4. Операционное тестирование (Release Testing).

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

5. Приемочное тестирование (Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

• определения удовлетворяет ли система приемочным критериям;

• вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

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

• Функциональное тестирование (Functional testing)

• Тестирование пользовательского интерфейса (GUI Testing)

• Тестирование безопасности (Security and Access Control Testing)

• Тестирование взаимодействия (Interoperability Testing)

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

• Все виды тестирования производительности:

o нагрузочное тестирование (Performance and Load Testing)

o стрессовое тестирование (Stress Testing)

o тестирование стабильности или надежности (Stability / Reliability Testing)

o объемное тестирование (Volume Testing)

• Тестирование установки (Installation testing)

• Тестирование удобства пользования (Usability Testing)

• Тестирование на отказ и восстановление (Failover and Recovery Testing)

• Конфигурационное тестирование (Configuration Testing)

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

• Дымовое тестирование (Smoke Testing)
• Регрессионное тестирование (Regression Testing)
• Повторное тестирование (Re-testing)
• Тестирование сборки (Build Verification Test)
• Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям — размер, шрифт, цвет, consistent behavior.

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

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

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

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

Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

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

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

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

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

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

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

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

В чем разница между regression testing и re-testing?

Re-testing — проверяется исправление багов

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

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

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

Подходы к интеграционному тестированию:
• Снизу вверх (Bottom Up Integration)

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

Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.
• Большой взрыв («Big Bang» Integration)

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

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

Принцип 1 – Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)

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

Принцип 2 – Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)

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

Принцип 3 – Раннее тестирование (Early testing)

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

Принцип 4 – Скопление дефектов (Defects clustering)

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

Принцип 5 – Парадокс пестицида (Pesticide paradox)

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

или системы, и найти как можно больше дефектов.

Принцип 6 – Тестирование зависит от контекста (Testing is concept depending)

Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.
Принцип 7 – Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)

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

Cтатическое и динамическое тестирование

Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестированию относится тестирования спецификации и прочей документации.

Исследовательское / ad-hoc тестирование

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

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

Требования – это спецификация (описание) того, что должно быть реализовано.

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

Требования к требованиям:

• Корректность

• Недвусмысленность

• Полнота набора требований

• Непротиворечивость набора требований

• Проверяемость (тестопригодность)

• Трассируемость

• Понимаемость

Жизненный цикл бага

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

Программный продукт проходит следующие стадии:

• анализ требований к проекту;

• проектирование;

• реализация;

• тестирование продукта;

• внедрение и поддержка.

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

Жизненный цикл разработки ПО:

• Пре-альфа

• Альфа

• Бета

• Релиз-кандидат

• Релиз

• Пост-релиз

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

QA/QC/Test Engineer

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.

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

Источники: www.protesting.ru, bugscatcher.net, qalight.com.ua, thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, bugsclock.blogspot.com, www.zeelabs.com, devopswiki.net, hvorostovoz.blogspot.com.

Ресурсы рекомендованные в комментах Sofiya Novachenko: istqbexamcertification.com www.testingexcellence.com

Метод тестов.

Слово «тест» означает испытание, проверка, диагностическая методика.

Тестирование и тестология — диагносцирование и диагностика.

Слово тест у нас ассоциировалось с методикой Бине-Симона и Стенфорд-Бине.

Специфические особенности теста.

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

1. Количественных психоиндивидуальных различий. Л.Кронбах — тесты предназначены описывать индивидуальные психологические различия с помощью количественной шкалы. Штерн в 1911 году описывал требования к тестам. С помощью тестовых оценок происходит ранжирование людей.
2. Тест представляет собой набор заданий, которые испытуемые должны выполнять по жестко-определенной инструкции, строго детерминирующей поведение. Инструкция жестко задает поведение испытуемого.
3. Выполнение тестов оценивается по критерию правильности. За правильно выполненное задание начисляются баллы.
4. Стимульный материал теста должен восприниматься всеми испытуемыми одинаково.

Какие бывают тесты?

Критерии классификации тестов:

1. цель тестирования
2. содержание
3. форма тестирования.

1. По цели различают тесты:

• тесты для отбора
• тесты для распределения
• тесты для классификации

2. По содержанию:

• тесты общих способностей:
  • тесты интеллекта
  • тесты креативные

• тесты специальных способностей
• тесты личности
• тесты достижений
• критериально-ориентированные тесты

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

Критериально-ориентированные тесты — это новый вид тестов, появились в 60-е годы 20 века.

Устанавливается соответствие испытуемого некоторому определенному критерию (соответствуют ли они внешне заданному критерию).

3. По форме тесты бывают — индивидуальные и групповые:

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

Проективные методы.

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

Специфические особенности методик.

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

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

Термин «проекция» впервые применен Лоренсом Франком для обозначения группы методик в 1939 году.

Он описал основные принципы проективной диагностики.

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

В начале 20 века Фрейд использует «проекцию» в другом смысле — символический перенос во вне — внутреннего мира человека. Наблюдая процесс экстериоризации тревожности, страха.

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

Группы проективных методик.

Впервые выделены Франком.

I. Конститутивные методики (методики структурирования).

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

Например:

• методика чернильных пятен Роршаха.
• тест трехмерной апперцепции (у нас не используется)

Создан — американцами в 1947 году. Стимульный материал — 28 стандартных объемных разной формы предметов.

Два этапа обследования:

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

II. Конструктивные методики (методики конструирования).

• В них требуется из определенных деталей создать осмысленное целое, что-то собрать, что осуществляется в соответствии с собственным опытом, вкусом, личностными особенностями.
• По отдельным фрагментам рассказа создать весь рассказ. Пример: в 1939 году — тест Мира (Ловенфейд). Стимульный материал: 232 модели разных объектов, которые распределены по 15 категориям (животные, люди…). Модели небольшие, из дерева или металла, имеют яркую окраску. Испытуемый должен создать свой малый мир (время не ограничивается).

В качестве критерия оценки используется:

1. количество людей
2. количество категорий
3. какие модели выбраны первыми
4. оценивается занятое пространство, учитываются формы конструкции
5. большую информацию дает наблюдение за деятельностью испытуемого.

В зависимости от подходов (практический, эстетический, логический…) оценивают тип личности, ее направленности.

Составь картину-историю (в 1947 году Шнейдман).

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

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

III. Интерпретативные методики

Нужно истолковать что-либо: ситуации, истории.

1. ТАТ — тематический апперцептивный тест
2. Методика рисуночной фрустрации Розенцвейга
3. Методика Сонди (1939 года), 48 стандартных карточек с портретами психически больных людей по 8-ми заболеваниям:
   • садизм
   • эпилепсия
   • истерия
   • кататония
   • шизофрения
   • депрессия
   • мания
   • гомосексуализм

Они разделены на 6 серий, каждый раз 8 портретов по одному на заболевание.

Надо выбрать по два наиболее понравившихся и два наименее (каждую серию повторяли 6 раз).

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

Выбор портретов определялся потребностями у испытуемого, отсутствие выбора — удовлетворенность потребности.

Негативные выборы — подавленные, вытесненные потребности; позитивные выборы — признаваемые потребности.

Генетический детерминизм — существование родового бессознательного.

IV. Катактические методики

Осуществление игровой деятельности в особо организованных условиях.

Пример: психодрама. Разработана Джекобом Морено в 1946 году. В виде импровизированного театрального представления, в котором участвуют специально подготовленные лица — вспомогательные «Я», которые создают специальные стимульные условия.

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

Катарсис — эффективное отреагирование.

Методика тест кукол (у нас не используется).

Вольтман, Гауорт — 50-е годы 20 века. Предназначен для детей до 10 лет, стимульный материал — куклы.

Разыграть с куклами различные сцены, в которых он участвует в социуме (соперничество с братьями, сестрами…)

V. Экспрессивные методики.

Рисование на свободную или заданную тему.

«Дом-дерево-человек», «Несуществующее животное», «Кинетический рисунок семьи».

Миокинетическая методика Мира и Лопеца — в 1940 году, состоит из 7 субтестов, в каждом используется таблица, где начерчены линии разной конфигурации. Параллели, кружки, лестницы, цепи, зигзаги…

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

Главные показатели оценивают длину линии и характер их отклонения (при обведении вслепую).

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

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

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

VI. Импрессивные методики.

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

Цветовая методика Люшера (создана в 1948 году), стимульный материал — вырезанные квадраты определенного размера разных цветов. Всего 73 квадрата, 25 разных цветов и оттенков (чаще неполный — 8 квадратов, 4 основных цвета: синий, зеленый, красный и желтый; 4 дополнительный цвета: фиолетовый, коричневый, черный и серый).

На белом фоне выкладываются все 8 квадратов, надо выбрать наиболее приятный по цвету квадрат, по отношению к оставшимся.

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

Первые 2 цвета явно предпочитаемые, 3 и 4 цвет тоже предпочитаемые, 5 и 6 — нейтральные цвета, 7 и 8 — вызывающие антипатию цвета.

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

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

Крайне важное значение приобретают оттенки цветов.

VII. Аддитивные методики.

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

Опросники.

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

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

1. Опросники похожи на проективные методики, так как не оцениваются ответы по критерию правильности. Баллы начисляются за совпадение с ключом, а не за правильность.
2. Опросники похожи на тесты: четкая инструкция, которая детерминирует способ выполнения задания, желательно ясное содержание вопросов или утверждений.
3. Опросники — разновидность самонаблюдения, косвенной самооценки.

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

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

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

Выделяются:

• опросники-анкеты — для получения информации об испытуемом, не имеющая личностного характера (биографические данные, для оценки особенностей когнитивной сферы).
• личностные опросники — дают информацию о личности:
  1. типологические, которые позволяют выяснить степень совпадения личности испытуемого с тем или иным типом личности.
  2. опросники отдельных черт личности — для диагностики отдельных черт характера:
     • многофакторные (о многих чертах), например Кеттела (14-, 12-, 16-тифакторные)
     • однофакторные
     • двухфакторные

  3. опросники мотивации
  4. опросники интересов
  5. опросники ценностей
  6. опросники установок

В 50-е годы отрицалась возможность использования личностных опросников.

В 60-е годы — начинают использовать.

К 60-70-м годам начинают переводить известные зарубежные опросники (применяют без проверки надежности).

80-е годы — проверка на надежность и валидность на наших испытуемых.

80-90е годы — появление отечественных опросников в большом количестве.

Основные проблемы, связанные с опросниками:

I. Конструирование

В психодиагностике создано очень много опросников. Они просты в использовании. Но эта простота имеет оборотную сторону — их сложно конструировать.

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

Содержание вопросов по возможности беспристрастное и социально нейтральное.

Каждый вопрос должен содержать одну мысль. Должен давать информацию о той характеристике, которую должен диагносцировать психолог.

При составлении вопросов количество ответов «да» должно быть приблизительно таким же, как количество ответов «нет», за которые начисляются баллы.

По форме вопросы:

• закрытые — имеют варианты ответов
• открытые — не имеют вариантов ответов, испытуемый сам формулирует ответ. Сложно интерпретировать.

Три типа закрытых вопросов:

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

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

II. Интерпретация

Проблема интерпретации результатов.

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

Людям свойственно давать социально-желательные ответы, представлять себя в более выгодном свете.

Это может быть бессознательная тенденция.

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

Иногда связано — с нежеланием принять свою ограниченность в чем-то. Стремление к защите собственного «Я». Стремление привлечь к себе внимание, получить помощь со стороны окружающих. Стремление сознательно исказить информацию о себе.

Приемы выявления достоверности ответов:

1. использование дублирующих вопросов (формулируются несколько вопросов 4-5, в разной форме обращены к одному содержанию). Если испытуемый отвечает противоречиво, то эта информация не должна рассматриваться
2. Контрольные шкалы. Четыре типа контрольных шкал существуют, все они присутствуют в минесотском многоаспектном личностном опроснике (MMPI)

Методы тестирования как оптимальный вариант контроля Текст научной статьи по специальности «Психологические науки»

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

Полученные результаты позволили констатировать статистически значимое изменение (в сторону развития и совершенствования) умений межкультурной интерпретации рекламных текстов на русском и

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

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

УДК 811.111

МЕТОДЫ ТЕСТИРОВАНИЯ КАК ОПТИМАЛЬНЫЙ ВАРИАНТ КОНТРОЛЯ

л

Т.П.Ефремова1

Национальный исследовательский Иркутский государственный технический университет, 664074, г. Иркутск, ул. Лермонтова, 83.

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

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

TESTING METHODS AS AN OPTIMAL CONTROL OPTION T.P. Efremova

National Research Irkutsk State Technical University, 83, Lermontov St., Irkutsk, 664074.

Recently, there is a growing interest to the pedagogical testing as the most objective method to assess the quality of education. The paper considers the development stages of testing. It allows to optimize the educational process significantly as well as improve the training quality of future specialists. Moreover it provides an opportunity to proceed to the creation of modern systems of adaptive learning and control. 15 sources.

Key words: psychological tests; examination; testing methods; abilities; control; intelligence level; methods to study mental development; standardization of testing; age norms; success rate.

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

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

которая была создана для отбора чиновников и охватывала весьма широкий спектр от умения писать до поведения в быту. Свидетельством использования испытаний тестового характера служат рукописи, в которых излагаются основы религиознофилософского учения чань-буддизма (5-6 в. н.э.). Учителя чань-буддизма в качестве одного из методов обучения и проверки знаний использовали загадки, вопросы, парадоксы, параллельно создавая ситуации психологического стресса. Отвечать ученики должны были сразу, без размышлений. Как указывает Н.В. Абаев, чань-ские парадоксальные загадки использовались в качестве тестов на определенный «чаньский» код мышления. В зависимости от того, как тестируемый отвечал на эти загадки, опытный наставник определял, на ка-

1 Ефремова Татьяна Петровна, старший преподаватель кафедры иностранных языков для гуманитарных специальностей, тел.: (3952) 405297;e-mail: [email protected]

Efremova Tatiana, Senior Lecturer of the Department of Foreign Languages for the Humanities, tel.: (3952) 405297; e-mail: [email protected]

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

Примеры использования различных методов, напоминающих тесты, можно найти в истории Древнего Египта и Древней Греции. Так, в Древнем Египте тот, кто посвящался в жрецы, должен был выдержать проверку на то, что в настоящее время называется профессиональной пригодностью. Начальным элементом системы отбора являлась оценка внешнего вида кандидата и беседа, в ходе которой оценивалось умение говорить и уровень образованности. Затем следовали испытания угрозой смерти, огнем и водой, а также проверка умений трудиться; на заключительном этапе — испытание красивой женщиной. Известно, что эту систему испытаний успешно прошел и Пифагор. А когда он вернулся после учебы в Грецию, то создал свою школу, в которую принимал только после серии испытаний. В Древней Греции испытания использовались для оценки физического совершенства и искусства мыслить и рассуждать. Платон придавал большое значение природным задаткам, которые не только отличают людей друг от друга, но и влияют на их способности к тому или иному делу. «Люди рождаются не слишком похожими друг на друга, их природа различна, да и способности к тому или иному делу также. Поэтому можно сделать все в большем количестве, лучше и легче, если выполнять одну какую-нибудь работу соответственно своим природным задаткам». Им была предложена серия испытаний военных способностей, которые проводили при отборе воинов в описанном им идеальном государстве. Можно сказать, что перечень этих испытаний — это первое систематическое описание тестов способностей. Таким образом, идея, отдельные методы проверки способностей людей использовались тысячелетия назад. Если понятие «тест» определять как испытания такого рода, то можно сказать, что тесты зародились давно и применялись для решения задач, выдвинутых социальной практикой в сфере отбора, обучения и определения людей на различные должности в зависимости от степени их пригодности. Следовательно, можно говорить о раннем историческом периоде возникновения тестов.

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

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

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

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

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

Первым ученым, который употребил в литературе термин «интеллектуальный тест», был американский

психолог Дж. М. Кеттэлл. Этот термин приобрел широкую известность после статьи Кеттэлла «Интеллектуальные тесты и измерения», опубликованной в журнале «Mind» в 1890 году, в которой автор описал серию тестов для определения интеллектуального уровня студентов колледжей. Вслед за Гальтоном Кеттэлл утверждает, что применение серии тестов к большому числу индивидов даст возможность открыть закономерности психологических процессов и тем самым приведет к преобразованию психологии в точную науку. Вместе с тем он высказывает мысль о том, что научная и практическая ценность тестов возрастет, если условия их проведения будут однообразными. Кроме этого, Кеттэлл выдвигает еще ряд требований, которым должно соответствовать тестирование: ограничение времени тестирования; отсутствие зрителей в лабораториях, где проводится тестирование; единообразие инструкций для испытуемых, четкое понимание задач деятельности. Так, вслед за В.Вундтом Кеттэлл доказал необходимость стандартизации тестов с целью возможности сравнения их результатов.

Метод тестов начинают применять и другие американские лаборатории, вследствие чего возникает необходимость в организации специальных координационных центров по его использованию. В 1895-1896 гг. в США были созданы два национальных комитета, призванных объединить усилия тестологов и придать общее направление тестологическим работам. А. Бине и В. Генри критически оценили исследования Ф. Гальтона и Дж. Кеттэлла по измерению уровня умственного развития. Указывалось, в частности, что предлагаемые ими тесты ориентированы, прежде всего, на элементарные психические процессы, а следовательно, неадекватно измеряют высшие психические функции, лежащие в основе интеллекта.

Исследования, проводимые в это же время в Европе, были направлены на изучение более сложных психических функций. Большинство тестов, действующих на рубеже XIX-XX веков, имело специфическую сенсорную направленность, в них выделялись исключительно простейшие, единичные и узко выраженные функции. Ни в одном из этих исследований не было системы работы с тестами, кроме того, в них не учитывались возрастные нормы испытуемых, не было сопоставлений результатов тестирования с успеваемостью обучающихся. Период до начала XX века можно назвать подготовительным этапом на пути создания собственно психологического тестирования. Дальнейшая разработка тестирования связана с именем А. Бине, создателем самой популярной для своего времени серии тестов. Можно сказать, что почти все дальнейшие конструкции интеллектуальных тестов так или иначе связаны с работами Бине. Эксперименты, проведенные под руководством Бине в школе, возникли под давлением требований жизни. Необходимо было диагностировать степень умственного развития детей, поскольку претворение в жизнь закона об обязательном всеобщем обучении выявило значительные индивидуальные различия, которые или осложняли процесс обучения, или делали его невозможным. Однако задача диагностики степеней ум-

ственной отсталости с помощью тестов того времени еще не была решена. Первая редакция шкалы умственного развития была разработана А.Бине и Т.Симоном в 1905 году с целью выявления умственно неполноценных детей, не способных к обучению в обычной школе. Шкала состояла из 30 тестов-заданий, расположенных по мере возрастания трудностей, так что вероятность успешного выполнения увеличивалась с хронологическим возрастом. Уровень трудности определялся на основе выборки из 50 нормальных детей в возрасте от 3 до 11 лет и небольшого числа детей, отстающих в развитии. Обследуемые с различными видами слабоумия не справлялись с заданиями выше определенного уровня сложности. На этой основе и проводилась дифференциация. Созданный тест рассматривался как вспомогательный инструмент изучения интеллекта, общий же показатель интеллекта не рассчитывался. Была значительно расширена выборка стандартизации. Авторы поставили перед собой более широкую задачу: кроме дифференциации детей на нормальных и слабоумных, выделить разные уровни развития нормальных детей. Тесты-задания группировались по возрастным уровням. Для каждого возраста предполагалось не меньше 5-7 заданий, причем Бине отмечал, что важно не столько содержание тестов, сколько их многочисленность. По мнению

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

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

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

ственного возраста на хронологический. Этот показатель он и назвал интеллектуальным коэффициентом. Заслугой А. Бине, В. Генри и Т.Симона являются выдвинутые ими важнейшие принципы измерения интеллекта, которые положены в основу современных тестов. Шкалы Бине-Симона привлекли внимание многих психологов, были переведены на многие языки и широко использовались в начале века. Шкала Бине-Симона получила широкое распространение и в СССР в 20-30-е годы; ее усовершенствовала A.M. Шуберт. В настоящее время шкалы Бине-Симона являются одними из самых удачных и наиболее адекватно измеряют интеллектуальное развитие детей. Их дальнейшее развитие было осуществлено в работах американского исследователя Л. Термена. Л. Терменом была разработана шкала Станфорд-Бине, представляющая собой модификацию шкалы Бине-Симона: было добавлено более трети новых заданий, переделан ряд старых. Фактически уже первая редакция шкалы Станфорд-Бине — это новый тест. Тесты, включенные в батарею Станфорд-Бине, группируются по возрастным уровням. В батарею тестов включены задания, которые направлены на исследование широкого диапазона способностей, от элементарного манипулирования до абстрактного рассуждения.

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

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

По применению шкал Станфорд-Бине накоплен огромный опыт; по широте использования эта методика занимает одно из ведущих мест среди тестов интеллекта. В 1915 году Р. Иеркесом была создана серия тестов, отличающихся от тестов Бине системой подсчета. Вместо возрастных долей (по Бине) испытуемый получает за каждый правильно решенный тест известное количество баллов. По определению М.С. Бернштейна, «эти американские ревизии Бине представляли значительные удобства, как в отношении проведения, так и в отношении подсчета результатов теста. В конечном счете, количество полученных испытуемым баллов переводилось по приложенным стандартам в коэффициент одаренности или успешности». В эти же годы появляются первые стандартизированные педагогические тесты по различным дисциплинам: тесты К. Стоуна на проверку арифметики, Б. Бекингема на проверку правописания. Направленность тестологии на быстрое решение практических задач способствовала ее широкому распространению.

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

тесты «Альфа» явились прототипом групповых словесных тестов, тесты «Бета» — прототипом групповых бессловесных тестов. С помощью этих тестов выявлялись умения и навыки, то есть тот наличный статус, который сложился к моменту испытания.

Основные принципы, использованные при составлении групповых тестов, легли в основу методологии тестирования, были систематизированы Бернштейном и сведены к следующему: 1.Принцип ограничения времени. Время было рассчитано таким образом, чтобы только около 5% испытуемых могли выполнить

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

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

1.Абаев Н.В. Архаичные формы религиозной теории и практики в чаньбуддизме // Буддизм и средневековая культура народов Центральной Азии. Новосибирск: Наука, 1980.

2.Аванесов B.C. Композиция тестовых заданий. М.: Адепт, 1998.

3. Аллахвердиева Д.Т. Опыт применения тестов для дидактической экспертизы обучения //Высшее образование в России. 1993. №2.С. 102-104.

4. Василейский С.М. Основной комплекс тестов. Нижний Новгород, 1928.

5. Василейский С.М. Комментарий и инструкции к постановке испытаний по «Основному комплексу тестов». Нижний Новгород, 1929.

6. Воронцов А.Б. Некоторые подходы к вопросу контроля и оценки деятельности учащихся //Начальная школа. 1999.

7. Гайда В.Ф., Захаров В.П. Психологическое тестирование. Л.: Изд-во Ленингр. ун-та, 1982.

8. Гулидов И.Н., Шатун А.П. Методика конструирования те-

стов. М.:Форум Инфра-М, 2003.

9. Дружинин В.Н. Экспериментальная психология. СПб. Питер, 2003.

10. Кабардин Ф.В., Земляков А.Н. Тестирование знаний, умений и навыков учащихся //Советская педагогика. 1991. №12. С.27-32.

11. Кальней В.А, Шишов Е. Технология мониторинга качества обучения в системе «учитель-ученик». М.: Педагогическое общество России, 1999.

12. Корсак К.О. О качестве систем педагогических измерений //Народное образование. 2002. №24. С.126-128.

13. Костылев Ф.В. Учить по-новому: Нужны ли оценки-баллы. М.: Гуманит. изд. центр ВЛАДОС, 2000.

14. Майоров А.Н. Теория и практика создания тестов для образования. М.: Интеллект-центр, 2001.

15. Макарова Т.Д. и др. Итоговое тестирование. Дидактика 2000. М.: Педагогическое общество России, 1999.

УДК 341.231.4

К ВОПРОСУ О СООТНОШЕНИИ НОРМ МЕЖДУНАРОДНОГО ПРАВА И КОНСТИТУЦИИ РОССИЙСКОЙ ФЕДЕРАЦИИ, РЕГУЛИРУЮЩИХ ОГРАНИЧЕНИЕ ПРАВ ЧЕЛОВЕКА В ХОДЕ ОПЕРАТИВНО-РОЗЫСКНОЙ ДЕЯТЕЛЬНОСТИ

А.А.Журавков1

Красноярский государственный аграрный университет, 660049, г. Красноярск, пр. Мира, 90.

Рассматривается вопрос о целесообразности установления в рамках национального законодательства дополнительных ограничений правомочий правоохранительных органов с целью защиты прав человека по сравнению с теми, что установлены в рамках международного законодательства. Рассмотрение вопроса производится на основании сравнительного анализа положений ст. 8 Конвенции от 4 ноября 1950 года «О защите прав человека и основных свобод», ст. 23, 25 Конституции Российской Федерации, ч. 2, 3 ст.8 Федерального закона «Об оперативно-розыскной деятельности».

Ключевые слова: международные соглашения; национальное законодательство; оперативно-розыскная деятельность; ограничение прав человека.

ON THE CORRELATION PROBLEM OF THE STANDARDS OF INTERNATIONAL LAW AND THE CONSTITUTION OF THE RUSSIAN FEDERATION REGULATING THE RESTRICTIONS OF HUMAN RIGHTS DURING THE OPERATIONAL-SEARCHING ACTIVITIES A.A. Zhuravkov

Krasnoyarsk State Agricultural University, 90, Mir Av., Krasnoyarsk, 660049.

The article deals with the question of the advisability to introduce into national legislation additional restrictions on the warrants of law-enforcement bodies in order to protect human rights in comparison with those that are established under the international law. The consideration of the problem is based on a comparative analysis of the provisions of Art. 8 of the Convention from 4 November 1950 «On the Protection of Human Rights and Fundamental Freedoms», Art. 23, 25 of

1Журавков Александр Анатольевич, аспирант, магистр юриспруденции, тел.: (391) 2747349, e-mail: [email protected] Zhuravkov Alexander, Postgraduate, Master of Law, tel.: (391) 2747349, e-mail: [email protected]

Виды тестирования и подходы к их применению / Хабр

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

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

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

Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.

Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию, которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection. Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость — в конструктор, в свойство или в метод.

Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.

По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.

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

Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.

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

Хорошая статья по интеграционному тестированию мне попалась лишь однажды — Scenario Driven Tests. Прочтя ее и книгу Ayende по DSL DSLs in Boo, Domain-Specific Languages in .NET у меня появилась идея как все-таки устроить интеграционное тестирование.

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

Понятно, что для проверки подобных спецификаций потребуется движок, который бы считывал спецификации и проверял их соответствие поведению программы. Я такой движок написал и остался доволен данным подходом. Скоро выложу движок в Open Source. (UPD: Выложил)

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

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

Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.

Второй подход — использовать специальные инструменты для записи действий пользователя. То есть в итоге запускается сама программа, но щелканье по кнопкам осуществляется автоматически. Для .NET примером такого инструмента является White библиотека. Поддерживаются WinForms, WPF и еще несколько GUI платформ. Правило такое — на каждый use case пишется по скрипту, который описывает действия пользователя. Если все use case покрыты и тесты проходят, то можно сдавать систему заказчику. Акт сдачи-приемки должен подписать.

Способы тестирования программного обеспечения / Блог компании OTUS. Онлайн-образование / Хабр

Всем привет! Уже на следующей неделе мы запускаем новый поток по курсу «Автоматизация веб-тестирования». Этому и будет посвящен сегодняшний материал.

В этой статье рассматриваются различные способы тестирования программного обеспечения, такие как модульное тестирование (unit testing), интеграционное тестирование (integration testing), функциональное тестирование (functional testing), приемочное тестирование (acceptance testing) и т.д.

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

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

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

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

Автоматизированные тесты – это ключевой компонент непрерывной интеграции (Continuous Integration) и непрерывной доставки (continuous delivery), а также хороший способ масштабировать ваш QA процесс во время добавления нового функционала для вашего приложения. Однако в ручном тестировании все равно есть своя ценность. Поэтому в статье мы обязательно поговорим об исследовательском тестировании (exploratory testing).

Различные типы тестов

Модульные тесты

Модульные тесты считаются низкоуровневыми, близкими к исходному коду вашего приложения. Они нацелены на тестирование отдельных методов и функций внутри классов, тестирование компонентов и модулей, используемых вашей программой. Модульные тесты в целом не требуют особых затрат на автоматизацию и могут отрабатывать крайне быстро, если задействовать сервер непрерывной интеграции (continuous integration server).

Интеграционные тесты

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

Функциональные тесты

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

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

Сквозные тесты (End-to-end tests)

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

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

Приемочное тестирование

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

Тесты производительности

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

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

Дымовое тестирование (Smoke testing)

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

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

Как автоматизировать тесты

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

Для автоматизации тестирования, вам для начала придется написать их на каком-то из языков программирования с использованием фреймворка для тестирования, который подойдет для вашего приложения. PHPUnit , Mocha, RSpec – это примеры фреймворков для тестирования, которые вы можете использовать для PHP, Javascript и Ruby, соответственно. В них есть множество возможностей для каждого языка, поэтому вам стоит немного позаниматься исследованием самостоятельно и проконсультироваться с сообществами разработчиков, чтобы понять, какой фреймворк подойдет вам лучше всего.

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

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

Исследовательское тестирование

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

Вопрос заключается в том, надо ли вообще в таком случае проводить ручное тестирование? Короткий ответ – да, и оно должно быть сфокусировано на том, что называется «исследовательское тестирование» (exploratory testing), которое помогает выявить неочевидные ошибки.

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

Заметка о тестировании

Перед тем, как закончить эту статью, я хочу поговорить о цели тестирования. С одной стороны, очень важно удостовериться, что пользователи смогут использовать ваше приложение («Я не могу войти в систему», «Я не могу сохранить данные» и т.п.), но с другой стороны не менее важно проверить, что ваша система не ломается при вводе неверных данных или неожиданных действиях. Вам нужно предвидеть, что произойдет, когда пользователь сделает опечатку, попытается сохранить неполную форму или использует неправильный API. Вам нужно проверить, сможет ли кто-то из пользователей легко скомпрометировать данные, получить доступ к тому или иному ресурсу, к которому у него не должно быть доступа. Хороший набор тестов должен попытаться сломать ваше приложение и помочь понять предел его возможностей.

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

По устоявшейся традиции ждем ваши комментарии и приглашаем всех на день открытых дверей, который уже 18 марта проведет наш преподаватель — ведущий автоматизатор в тестировании в Group-IB — Михаил Самойлов.

4. Тестирование (метод тестов)

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

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

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

1)
информирование испытуемого о целях
проведения тестирования;

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

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

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

5)
предупреждение распространения
полученной в результате тестирования
психодиагностической информации,
обеспечение ее конфиденциальности;

6)
ознакомление испытуемого с результатами
тестирования, сообщение ему или
ответственному лицу соответствующей
информации с учетом принципа «Не
навреди!»; в этом случае возникает
необходимость решения серии этических
и нравственных задач;

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

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

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

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

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

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

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

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

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

свойство.
Применяются разные способы проверки
надежности тестов.

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

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

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

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

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

5.
Изучение
продуктов деятельности

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

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

Методологии тестирования программного обеспечения

Написано Кирстен Эберсолд

Функциональное и нефункциональное тестирование

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

• Единичные испытания
• Интеграционное тестирование
• Системное тестирование
• Приемочные испытания

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

• Тестирование производительности
• Тестирование безопасности
• Юзабилити-тестирование
• Тестирование совместимости

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

Модульное тестирование

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

Начать переключение влево и автоматизировать сейчас с TestLeft

Интеграционное тестирование

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

Системное тестирование

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

Приемочные испытания

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

Тестирование производительности

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

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

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

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

1. Целостность
2. Конфиденциальность
3. Аутентификация
4. Авторизация
5. Наличие
6. Отсутствие отказа от авторства

Юзабилити-тестирование

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

Тест на совместимость

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

Тестирование с помощью TestComplete

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

,

c # — Модульное тестирование Microsoft. Можно ли пропустить тест из тела метода тестирования?

Переполнение стека

1. Товары

2. Клиенты
3. Случаи использования

1. Переполнение стека
   Общественные вопросы и ответы

2. Команды
   Частные вопросы и ответы для вашей команды

3. предприятие
   Частные вопросы и ответы для вашего предприятия

4. работы
   Программирование и связанные с ним возможности технической карьеры

5. Талант
   Нанять технических талантов

6. реклама
   Обратитесь к разработчикам по всему миру

,

java — Имя пользовательского метода тестирования в отчетах TestNG

Переполнение стека

1. Товары

2. Клиенты
3. Случаи использования

1. Переполнение стека
   Общественные вопросы и ответы

2. Команды
   Частные вопросы и ответы для вашей команды

3. предприятие
   Частные вопросы и ответы для вашего предприятия

4. работы
   Программирование и связанные с ним возможности технической карьеры

5. Талант
   Нанять технических талантов

6. реклама
   Обратитесь к разработчикам по всему миру

,

26,3. unittest — Фреймворк для модульного тестирования — документация Python 3.4.10

(Если вы уже знакомы с основными концепциями тестирования, вы можете
для перехода к список методов assert .)

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

Для этого unittest поддерживает некоторые важные концепции в
объектно-ориентированный способ:

испытательный стенд

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

тестовый пример

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

набор тестов

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

тестовый бегун

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

См. Также

Модуль doctest

Еще один модуль поддержки тестирования с совсем другим вкусом.

Простое тестирование Smalltalk: с шаблонами

Оригинальная статья Кента Бека о тестировании фреймворков с использованием общего шаблона
с помощью unittest.

Нос и пы.тест

Сторонние фреймворки unittest с облегченным синтаксисом для написания
тесты. Например, assert func (10) == 42.

Таксономия средств тестирования Python

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

Тестирование в списке рассылки Python

Специальная группа для обсуждения тестирования и инструментов тестирования,
в Python.

Скрипт Tools / unittestgui / unittestgui.py в дистрибутиве исходного кода Python
инструмент с графическим интерфейсом для обнаружения и выполнения тестов. Это сделано в основном для простоты использования.
для новичков в модульном тестировании. Для производственных сред это
рекомендуется, чтобы тесты проводились с помощью системы непрерывной интеграции, такой как
Buildbot, Дженкинс
или Хадсон.

26.3.1. Базовый пример

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

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

 импортный unittest

класс TestStringMethods (unittest.TestCase):

  def test_upper (сам):
      self.assertEqual ('foo'.upper (),' FOO ')

  def test_isupper (сам):
      self.assertTrue ( 'Foo'.ISUPPER ())
      self.assertFalse ( 'Foo'.isupper ())

  def test_split (сам):
      s = 'привет, мир'
      self.assertEqual (s.split (), ['привет', 'мир'])
      # проверяем, что s.split не работает, если разделитель не является строкой
      с self.assertRaises (TypeError):
          ДЕЛЕНИЕ (2)

если __name__ == '__main__':
    unittest.main ()
 

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

Суть каждого теста — это вызов assertEqual () для проверки наличия
ожидаемый результат; assertTrue () или assertFalse ()
для проверки состояния; или assertRaises (), чтобы убедиться, что
возникает конкретное исключение. Эти методы используются вместо
оператор assert, чтобы исполнитель теста мог собрать все результаты теста
и составим отчет.

Методы setUp () и tearDown () позволяют
для определения инструкций, которые будут выполняться до и после каждого метода тестирования.
Более подробно они описаны в разделе Код организационного тестирования .

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

 ...
-------------------------------------------------- --------------------
Выполнить 3 теста за 0,000 с

хорошо
 

Передача опции -v в ваш тестовый сценарий проинструктирует unittest.main ()
чтобы включить более высокий уровень детализации и получить следующий результат:

 test_isupper (__main__.TestStringMethods) ... хорошо
test_split (__main __. TestStringMethods) ... хорошо
test_upper (__main __. TestStringMethods) ... хорошо

-------------------------------------------------- --------------------
   

.