Обработка результатов тестирования.
Руководство по проведению теста.
Для правильного проведения тестирования необходимо строго соблюдать инструкции, контролировать время выполнения субтестов (с помощью секундомера), не помогать испытуемым при выполнении заданий.
При групповом тестировании должны участвовать два экспериментатора. Один из них зачитывает инструкции и следит за временем тестирования, другой наблюдает за учащимися, предупреждая нарушение ими инструкций.
Время проведения субтестов.
| Субтест | Число заданий в субтесте | Время выполнения, мин |
| 1. Осведомленность 1 | ||
| 2. Осведомленность 2 | ||
| 3. Аналогии | ||
| 4. Классификации | ||
| 5. Обобщения | ||
| 6. Числовые ряды |
Перед проведением тестирования экспериментатор объясняет его цель и создает у испытуемых соответствующий настрой. Для этого он обращается к ним со следующими словами:
«Сейчас вам будут предложены задания, которые предназначены для того, чтобы выявить умения рассуждать, сравнивать предметы и явления окружающего мира, находить в них общее и различное. Эти задания отличаются от того, что вам приходится выполнять на уроках.
Для выполнения заданий понадобятся ручка и бланки, которые мы вам раздадим. Вы будете выполнять разные наборы заданий. Перед предъявлением каждого набора дается описание этого типа заданий и на примерах объясняется способ их решения.
На выполнение каждого набора заданий отводится ограниченное время. Начинать и заканчивать работу надо будет по нашей команде. Все задания следует решать строго по порядку. Не задерживайтесь слишком долго на одном задании. Старайтесь работать быстро и без ошибок!».
После прочтения этой инструкции экспериментатор раздает тестовые тетради и просит заполнить в них графы, в которые вносятся такие сведения: фамилия и имя учащегося, дата проведения эксперимента, класс и номер школы, где он учится. Проконтролировав правильность заполнения этих граф, экспериментатор предлагает учащимся отложить в сторону ручки и внимательно его выслушать. Затем он зачитывает инструкцию и разбирает примеры первого субтеста, далее спрашивает, есть ли вопросы. Чтобы условия тестирования были всегда одинаковыми, при ответах на вопросы экспериментатору следует просто вновь зачитать соответствующее место текста инструкции. После этого дается указание перевернуть страницу и начинать выполнять задания. При этом экспериментатор незаметно включает секундомер (чтобы не фиксировать на этом внимание и не создавать у них чувства напряженности).
По истечении времени, отведенного на выполнение первого субтеста, экспериментатор решительно прерывает работу испытуемых словом «стоп», предлагая им положить ручки, и начинает читать инструкцию к следующему субтесту.
В ходе проведения тестирования необходимо контролировать, правильно ли испытуемые переворачивают страницы и выполняют другие требования экспериментатора.
Обработка результатов тестирования.
Производится количественная и качественная обработка результатов. Возможен групповой и индивидуальный анализ данных.
Количественная обработка:
1) индивидуальные показатели по каждому набору заданий (за исключением субтеста 5) — балл по тесту и субтесту — выводятся путем подсчета количества правильно выполненных заданий. Пример: если испытуемый А в субтесте 3 правильно решил 13 заданий, то его балл по этому субтесту будет равен 13;
2) результаты субтеста 5 оцениваются в зависимости от качества обобщения 2 баллами, 1 баллом и 0. Для обработки следует использовать таблицы примерных ответов, даваемых в заданиях на обобщение. Ответы, оцениваемые 2 баллами, приведены в таблице достаточно полно. Только приведенные ответы, а также их синонимические замены можно оценивать 2 баллами.
Перечень ответов, оцениваемых 1 баллом, является менее полным, так как здесь у испытуемых гораздо больше возможностей для выбора. После логического анализа 1 баллом можно оценить ответы, отличающиеся от приведенных в таблице.
При этом следует иметь в виду, что 1 балл получают ответы, представляющие собой более широкие, по сравнению с правильными, категориальные обобщения, а также правильные, но наиболее узкие, чем необходимо, частные обобщения.
Неправильные ответы оцениваются 0. Примеры таких ответов приводятся в таблицах.
Максимальное количество баллов, которое может получить учащийся при выполнении субтеста 5, равно 38. Это число соответствует стопроцентному выполнению этого субтеста;
3) индивидуальным показателем выполнения теста в целом является сумма баллов, полученных при сложении результатов решения всех субтестов.
Позамыслу полный состав теста принимается за норматив умственного развития. С ним сравнивается число заданий, выполненных данным учащимся. Устанавливается процент выполнения заданий, и это определяет количественную сторону работы испытуемого. Имеется разработанная схема представления количественных результатов ШТУРа. (Психологическая коррекция умственного развития учащихся /Под ред. К.М.Гуревича, И.В.Дубровиной. — М, 1990. — С. 33-35; 115-117);
4) если предлагается сравнение групп испытуемых между собой, то групповыми показателями по каждому субтесту могут служить значения среднего арифметического.
Для анализа групповых данных относительно их близости к социально-психологическому нормативу, условно рассматриваемому как стопроцентное выполнение каждого субтеста, все испытуемые подразделяются по результатам тестирования на 5 подгрупп:
— первая — наиболее успешные — 10%;
— вторая — близкие к успешным — 20%;
— третья — средние по успешности — 40%;
— четвертая — малоуспешные — 20%; 1
Для каждой из подгрупп подсчитывается средний процент правильно выполненных заданий. Строится система координат, где по оси абсцисс идут номера подгрупп, по оси ординат — процент выполненных каждой из них заданий. После нанесения соответствующих точек вычерчивается график, отражающий приближение каждой из подгрупп к социально-психологическому нормативу.
Такой же вид обработки проводится и по результатам всего теста в целом. Полученные при этом графики позволяют дать наглядное сравнение успешности выполнения ШТУРа учащимися как одного, так и разных классов;
5) установлено, что с возрастом от 6 к 8-му классу увеличивается разрыв в умственном развитии между лучшими учащимися одной и той же выборки, лучшая часть учащихся быстрее (с возрастом) приближается к требованиям социально-психологического норматива, в то время как слабо выполняющие тест практически остаются на том же уровне. Этот факт должен учитываться школьными психологами: не следует ожидать, что отставание пройдет само собой; напротив, отставание может усилиться. Поэтому следовало бы интенсивнее заниматься с отстающими по тесту учащимися для скорейшего преодоления пробелов их умственного развития;
6) при анализе результатов отдельного учащегося глобальные оценки умственного развития типа «лучше», «хуже», «выше», «ниже», основанные на подсчете баллов, полученных им при выполнении теста, и в сравнении с группой (или нормой) мало что дают для понимания своеобразия умственного развития. Однако в качестве первого шага для получения самого общего впечатления об ученике можно рекомендовать подсчитать его общий балл. При этом следует иметь в виду, что общие баллы шестиклассника ниже 30, семиклассника ниже 40, восьми- девятиклассника ниже 45 рассматриваются как очень низкие и свидетельствуют о низком умственном развитии. Об относительно высоком умственном развитии говорят общие баллы выше 75 у шестиклассника, 90-у семиклассника и 100 — у восьмиклассника.
Ясно, что общий балл по тесту может объединить неодинаковые вклады каждого субтеста. Поэтому следующий этап анализа — выяснение количества баллов, полученных учащимися по каждому субтесту.
Количественная характеристика умственного развития учащихся подлежит дополнительно качественной, в которой дается психологическая интерпретация выполненных и невыполненных заданий.
Качественная обработка:
1) групповой анализ результатов субтестов 1 и 2 должен вскрыть уровень осведомленности учащихся в понятиях, относящихся к двум информационным сферам (общественно-политической и научно-культурной). Для этого следует подсчитать процентное выполнение соответствующих заданий по группе в целом;
2) качественный анализ субтестов 1 и 2 может идти по пути выявления критериальных заданий, т.е. тех заданий, в которых обнаруживаются наиболее резкие различия между сравниваемыми группами или подгруппами наиболее и наименее успешных внутри групп.
Таким образом, качественный анализ групповых результатов первых двух субтестов позволит дать характеристику группе учащихся в отношении наиболее и наименее освоенных понятий общего и основополагающего характера, которые способствуют расширению кругозора, формированию миропонимания.
По таким характеристикам возможно сравнение групп учащихся, отличающихся по условиям своего развития;
3) анализ качественной стороны субтеста 3 «Аналогии» проводится по следующим направлениям:
— выявление наиболее и наименее усвоенных областей содержания теста;
— выявление самого отработанного (легкого) и наиболее трудного типов логических связей из следующих заложенных в тест: вид — род, часть -целое, причина — следствие, порядок следования, противоположность, функциональные отношения; :
— выявление типичных ошибок при установлении логических связей;
характер типичных ошибок не только отразит предпочитаемые логические операции, но и поможет выявить недостатки, возможную односторонность, ограниченность в усвоении информации; так, например, имеются данные, что учащиеся 6-8 классов часто стремятся подбирать к предъявленному понятию такие, которые отражают его свойства и функции; гораздо реже в ответах встречаются понятия, имеющие более отдаленные или более глубокие связи с заданным; этот факт может свидетельствовать о тенденции к изучению характеристик отдельных объектов и явлений и о меньшем внимании к связям между предметами и явлениями.
Если имеются две или больше групп учащихся, то по каждому из названных показателей возможно их сравнение;
4) анализ качественной стороны субтеста 4 «Классификации» проводится по следующим направлениям:
— выявление наиболее и наименее усвоенных областей содержания теста;
— выявление типа заданий — с конкретными или абстрактными понятиями, который провоцирует большое количество ошибок;
5) анализ качественной стороны субтеста 5 «Обобщения» проводится по следующим направлениям:
— определение характера типичных обобщений — по конкретному, видовому, категориальным признакам;
— выявление типичных ошибок, а также содержания и характера понятий (абстрактные или конкретные), провоцируя эти ошибки;
6) индивидуальный качественный анализ проводится по той же схеме, что и групповой: — на основании результатов выполнения каждого субтеста и сравнения их между собой можно заключить, каким логическим действием учащийся владеет лучше, а каким хуже; какая из областей умственного развития — осведомленность в некоторых общих понятиях или сформированность операциональной стороны мышления — представлена у данного учащегося лучше, а какая хуже:
— по каждому субтесту можно установить, какая из областей содержания теста усвоена лучше, а какая хуже;
— каков характер типичных ошибок в каждом из субтестов;
7) предпочтительное выполнение заданий с определенным содержанием во всех субтестах, использующих понятия научно-учебных циклов, может свидетельствовать о преобладающих склонностях учащегося. Прямо делать вывод об определенной склонности нельзя, так как следует учитывать предшествующую подготовку учащегося, полученную вне школы, влияние педагога, участие его в факультативах и пр. Но, тем не менее, ШТУР создает возможность для анализа индивидуальных результатов по научно-учебным циклам. ;
Количественный и качественный анализ результатов ШТУРа дает возможность с разных сторон оценивать умственное развитие как отдельного ученика, так и группы учащихся. На основании замеченных недостатков в умственном развитии можно наметить конкретную схему коррекционной работы по их устранению.
В пособии для школьных психологов авторов К.М.Гуревича, М.К.Акимовой, Е.М.Борисовой и др. приведены основные принципы построения коррекционной программы, экспериментальная проверка коррекционных программ и процедура проведения коррекционных занятий, а также наборы заданий ШТУРа формы А и Б.
Источник
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
- Для проверки соответствия требованиям.
- Для обнаружение проблем на более ранних этапах разработки и предотвращение повышения стоимости продукта.
- Обнаружение вариантов использования, которые не были предусмотрены при разработке. А также взгляд на продукт со стороны пользователя.
- Повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Принципы тестирования
- Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия. - Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи). - Принцип 3 — Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше. - Принцип 4 — Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей. - Принцип 5 — Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты. - Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
- Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.
Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
- проверка готовности ПО к релизу;
- проверка соответствия требований и качества данного проекта.
QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.
К задачам обеспечения качества относятся:
- проверка технических характеристик и требований к ПО;
- оценка рисков;
- планирование задач для улучшения качества продукции;
- подготовка документации, тестового окружения и данных;
- тестирование;
- анализ результатов тестирования, а также составление отчетов и других документов.
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
- Проектная документация — включает в себя всё, что относится к проекту в целом.
- Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.
Этапы тестирования:
- Анализ продукта
- Работа с требованиями
- Разработка стратегии тестирования и планирование процедур контроля качества
- Создание тестовой документации
- Тестирование прототипа
- Основное тестирование
- Стабилизация
- Эксплуатация
Стадии разработки ПО — этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широкого круга пользователей.
Программный продукт проходит следующие стадии:
- анализ требований к проекту;
- проектирование;
- реализация;
- тестирование продукта;
- внедрение и поддержка.
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
- Корректность — точное описание разрабатываемого функционала.
- Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
- Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
- Недвусмысленность — требование должно содержать однозначные формулировки.
- Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
- Атомарность — требование нельзя разбить на отдельные части без потери деталей.
- Модифицируемость — в каждое требование можно внести изменение.
- Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.
Дефект (bug) — отклонение фактического результата от ожидаемого.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
- Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
- Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
- Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
- Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
- Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
- Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
- Вложения (Attachments) — скриншоты, видео или лог-файлы.
- Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
- Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
- Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
- Окружение (Environment) – окружение, на котором воспроизвелся баг.
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
- Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. - Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование. - Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза. - Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве. - Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком
Градация Приоритета дефекта (Priority):
- P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее. - P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения. - P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.
Существует шесть базовых типов задач:
- Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
- Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
- История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
- Задача (task) — техническая задача, которую делает один из членов команды.
- Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
- Баг (bug) — задача, которая описывает ошибку в системе.
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
- Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
- Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
- Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
- Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
- Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
- Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
- Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
- Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
- Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
- Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
- Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
- Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
- Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
- Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
- Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
- Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
- Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
- Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
- Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
- Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
- Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
- Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
- Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
- Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
- Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
- Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
- Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
- Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
- тестирование, основанное на анализе внутренней структуры компонента или системы;
- тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
- Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.
Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
- тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
- тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
- Что необходимо протестировать?
- Как будет проводиться тестирование?
- Когда будет проводиться тестирование?
- Критерии начала тестирования.
- Критерии окончания тестирования.
Основные пункты тест плана:
- Идентификатор тест плана (Test plan identifier);
- Введение (Introduction);
- Объект тестирования (Test items);
- Функции, которые будут протестированы (Features to be tested;)
- Функции, которые не будут протестированы (Features not to be tested);
- Тестовые подходы (Approach);
- Критерии прохождения тестирования (Item pass/fail criteria);
- Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
- Результаты тестирования (Test deliverables);
- Задачи тестирования (Testing tasks);
- Ресурсы системы (Environmental needs);
- Обязанности (Responsibilities);
- Роли и ответственность (Staffing and training needs);
- Расписание (Schedule);
- Оценка рисков (Risks and contingencies);
- Согласования (Approvals).
Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
- Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
- Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
- Ожидаемый результат (Expected result) — что по факту должны получить.
Источник
