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

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

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

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

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

• Принцип 1 — Тестирование демонстрирует наличие дефектов.
  Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
• Принцип 2 — Исчерпывающее тестирование невозможно.
  Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
• Принцип 3 — Раннее тестирование.
  Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
• Принцип 4 — Скопление дефектов.
  Большая часть дефектов находится в ограниченном количестве модулей.
• Принцип 5 — Парадокс пестицида.
  Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
• Принцип 6 — Тестирование зависит от контекста. Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
• Принцип 7 — Заблуждение об отсутствии ошибок. Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

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

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Эксплуатация

Требования

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

Атрибуты требований:

1. Корректность — точное описание разрабатываемого функционала.
2. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
4. Недвусмысленность — требование должно содержать однозначные формулировки.
5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.
8. Модифицируемость — в каждое требование можно внести изменение.
9. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

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

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

1. Классификация по запуску кода на исполнение:
   Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
   Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
   
2. Классификация по доступу к коду и архитектуре:
   Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
   Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
   Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
   
3. Классификация по уровню детализации приложения:
   Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
   Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
   Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
   Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
   
4. Классификация по степени автоматизации:Ручное тестирование.
   Автоматизированное тестирование.
   
5. Классификация по принципам работы с приложением Позитивное тестирование — тестирование, при котором используются только корректные данные.
   Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
   
6. Классификация по уровню функционального тестирования: Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
   Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
   Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
   
7. Классификация в зависимости от исполнителей: Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации разработчика с возможным частичным привлечением конечных пользователей.
   Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
   
8. Классификация в зависимости от целей тестирования: Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения. Регрессионное

Регрессионное тестирование (regression 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) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

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

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

Эквивалентное разбиение

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

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

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.

Граничные значения

Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с  вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.

Таблица принятия решений

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

Какие возможны сценарии:
1.       Правильный логин и правильный пароль.
2.       Правильный логин, неправильный пароль.
3.       Неправильный логин, правильный пароль.
4.       Неправильный логин, неправильный пароль.

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

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.

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

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

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

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

Для попарного тестирования существуют уже готовые сервисы один из таких : https://pairwise.teremokgames.com

Методы тестирования

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

Согласно ISTQB, тестирование белого ящика — это:

• тестирование, основанное на анализе внутренней структуры компонента или системы;
• тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
• Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

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

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

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

• Что необходимо протестировать?
• Как будет проводиться тестирование?
• Когда будет проводиться тестирование?
• Критерии начала тестирования.
• Критерии окончания тестирования.

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

1. Идентификатор тест плана (Test plan identifier);
2. Введение (Introduction);
3. Объект тестирования (Test items);
4. Функции, которые будут протестированы (Features to be tested;)
5. Функции, которые не будут протестированы (Features not to be tested);
6. Тестовые подходы (Approach);
7. Критерии прохождения тестирования (Item pass/fail criteria);
8. Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
9. Результаты тестирования (Test deliverables);
10. Задачи тестирования (Testing tasks);
11. Ресурсы системы (Environmental needs);
12. Обязанности (Responsibilities);
13. Роли и ответственность (Staffing and training needs);
14. Расписание (Schedule);
15. Оценка рисков (Risks and contingencies);
16. Согласования (Approvals).

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

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

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

Атрибуты тест кейса:

• Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
• Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
• Ожидаемый результат (Expected result) — что по факту должны получить.

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