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

Классификация по принципам работы с приложением

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

Тестирование на основе опыта тестировщика, сценариев, чек-листов

• Исследовательское
• Свободное(интуитивное)

Классификация по степени вмешательства в работу приложения

Инвазивное тестирование (Intrusive testing)

Тестирование, выполнение которого может повлиять на функционирование приложения в силу работы инструментов тестирования (например, будут искажены показатели производительности) или в силу вмешательства (level of intrusion) в сам код приложения (например, для анализа работы приложения было добавлено дополнительное протоколирование, включён вывод отладочной информации и т.д.)

Некоторые источники рассматривают инвазивное тестирование как форму негативного или даже стрессового тестирования.

Неинвазивное тестирование (Nonintrusive testing)

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

Классификация по техникам автоматизации:

Тестирование под управлением данными ( Data-driven testing)

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

Тестирование под управлением ключевыми словами (Keyword-driven testing)

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

Тестирование под управлением поведением (Behavior-driven testing)

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

Классификация на основе(знания) источников ошибок

Тестирование предугадыванием ошибок (Error guessing)

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

Может комбинироваться с техникой т.н. «ошибкоориентированного» тестирования (failure-directed testing), в котором новые тесты строятся на основе информации о ранее обнаруженных в приложении проблемах.

Эвристическая оценка (Heuristic evaluation)

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

Мутационное тестирование (Mutation testing)

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

Может комбинироваться со следующим в этом списке видом тестирования (тестированием добавлением ошибок).

Тестирование добавлением ошибок (Error seeding)

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

Может комбинироваться с предыдущим в этом списке видом тестирования (мутационным тестированием).

Классификация на основе выбора входных данных или спецификаций

Тестирование на основе классов эквивалентности (Equivalence partitioning)

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

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

Тестирование на основе граничных условий (Boundary value analysis)

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

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

Доменное тестирование (Domain analysis, Domain testing)

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

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

Попарное тестирование (Pairwise testing)

Техника тестирования, в которой тест-кейсы строятся по принципу проверки пар значений параметров (переменных) вместо того, чтобы пытаться проверить все возможные комбинации всех значений всех параметров. Эта техника является частным случаем N-комбинационного тестирования (n-wise testing) и позволяет существенно сократить трудозатраты на тестирование (а иногда и вовсе сделать возможным тестирование в случае, когда количество «всех комбинаций всех значений всех параметров» измеряется миллиардами).

Попарное тестирование (pairwise testing) — это НЕ парное тестирование (pair testing)!

Тестирование на основе ортогональных массивов (Orthogonal array testing)

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

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

Тестирование в процессе разработки (Development testing)

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

Операционное тестирование

Тестирование на основе кода (Code based testing)

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

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

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

• Тестирование по потоку данных (Data-flow testing) Семейство техник тестирования, основанных на выборе отдельных путей из потока управления с целью исследования событий, связанных с изменением состояния переменных.

• Тестирование по диаграмме или таблице состояний (State transition testing) Техника тестирования, в которой тест-кейсы разрабатываются для проверки переходов приложения из одного состояния в другое. Состояния могут быть описаны диаграммой состояний (state diagram) или таблицей состояний (state table).

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

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

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

Тестирование на основе структур кода (Structure-based techniques)

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

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

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

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

• Тестирование на основе комбинаций условий(Multiple condition testing) Техника тестирования (по методу белого ящика), в которой проверяется выполнение сложных (составных) условий.

• Тестирование на основе отдельных условий, порождающих ветвление («решающих условий») (Modified condition decision coverage testing) Техника тестирования (по методу белого ящика), в которой проверяется выполнение таких отдельных условий в составе сложных условий, которые в одиночку определяют результат вычисления всего сложного условия.

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

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

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

Тестирование на основе (моделей) поведения приложения (Application behavior/model-based testing)

Тестирование по таблице принятия решений (Decision table testing)

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

Тестирование по диаграмме или таблице состояний

Тестирование по спецификациям (Specification-based testing, black box testing)

Тестирование по моделям поведения приложения (Model-based testing)

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

Тестирование на основе вариантов использования (Use case testing)

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

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

В случае если методология разработки проекта подразумевает использование пользовательских историй, этот вид тестирования может быть заменён тестированием на основе пользовательских историй (user story testing).

Параллельное тестирование (Parallel testing)

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

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

Тестирование на основе случайных данных (Random testing)

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

A/B-тестирование (A/B testing, Split testing)

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

Тестирование на основе дерева классификаций(Classification tree method)

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

Тестирование на основе синтаксиса (Syntax testing)

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

Комбинаторные техники или комбинаторное тестирование (Combinatorial testing)

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

Существуют следующие комбинаторные техники:

• Тестирование всех комбинаций (All combinations testing) тестирование всех воз- можных комбинаций всех значений всех тестовых данных (например, всех параметров функции).

• Попарное тестирование

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

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

Тестирование по графу причинно-следственных связей (Cause-effect graphing)

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

Тестирование по потоку данных (Data-flow testing)

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

Эти техники позволяют обнаружить такие ситуации, как:

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

Здесь придётся немного погрузиться в теорию. Над переменной в общем случае может выполняться несколько действий (покажем на примере переменной x):

• объявление (declaration): int x;
• определение (definition, d-use): x = 99;
• использование в вычислениях (computation use, c-use): z = x + 1;
• использование в условиях (predicate use, p-use): if (x > 17) { ... }; - удаление (kill, k-use): x = null;

Теперь можно рассмотреть техники тестирования на основе потока данных.

• Проверка использования всех объявлений (All-definitions testing) Тестовым набором проверяется, что для каждой переменной существует путь от её определения к её использованию в вычислениях или условиях.

• Проверка всех вычислений на основе всех объявлений (All-c-uses testing) Тестовым набором проверяется, что для каждой переменной существует путь от каждого её определения к её использованию в вычислениях.

• Проверка всех ветвлений на основе всех объявлений (All-p-uses testing) Тестовым набором проверяется, что для каждой переменной существует путь от каждого её определения к её использованию в условиях.

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

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