Основы тестирования программного обеспечения.

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

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

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

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

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

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

- Проверить на соответствие требованиям;

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

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

- повышение лояльности к компании и её продуктам.

В интернете можно найти 7 принципов, но можно выделить 4 основных.

- Тестирование демонстрирует наличие дефектов, а не их отсутствие;

- исчерпывающее тестирование недостижимо;

- раннее тестирование сохраняет время и деньги;

- парадокс пестицида.

- Анализ продукта;

- работа с требованиями;

- разработка стратегии тестирования и планирование процедур контроля качества;

- создание тестовой документации;

- тестирование прототипа;

- основное тестирование;

- стабилизация;

- эксплуатация.

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

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

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

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

- внедрение и поддержка

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

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

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

Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

Ручное тестирование.

Автоматизированное тестирование.

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

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

Дымовое тестирование (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) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.

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

Автор книги "A Practitioner’s Guide to Software Test Design", Lee Copeland, выделяет следующие техники тест-дизайна:

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

2. Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.

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

4. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

5. Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.

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

7. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

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

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

- тестирование, основанное на анализе внутренней структуры компонента или системы;

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

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

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

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

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

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

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

Тест план (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) — что по факту должны получить.

Заголовок (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?

Подробное описание (Description) — более широкое описание дефекта (указывается опционально).

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

Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения (может совпадать с темой отчета о дефекте).

Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.

Вложения (Attachments) — скриншоты, видео или лог-файлы.

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

Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.

Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.

Окружение (Environment) – окружение, на котором воспроизвелся баг.

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