Тестирование программ: виды, этапы, принципы

Почему важно тестировать программы

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

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

Какие виды тестирования существуют

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

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

1. Статическим и динамическим. В первом случае тестировщик анализирует программное обеспечение без его непосредственного выполнения, т. е. не включая. Он вычитывает исходный код вручную или с помощью специальных инструментов, чтобы оценить качество реализации заявленных функций. Во втором случае анализ проводится на работающей системе. Программа запускается на реальном или виртуальном процессоре, и инженер исследует ее фактическое поведение.
2. Функциональным и нефункциональнымФункциональным и нефункциональным. Как следует из названия, тесты нацелены на проверку функциональности и проверку исполнения требований, не относящихся к функциональной части, соответственно. При тестировании функционала определяют, способна ли программа выполнять действия и решать задачи, которые задает пользователь. Обычно речь идет о задокументированных возможностях, но инженер-тестировщик может реализовать и неожиданные сценарии взаимодействия. Нефункциональный подход включает в себя множество подвидов в зависимости от объекта анализа: тестирование производительности, надежности, безопасности, стресс-тест на нагрузку, UX-тестирование и др.
3. Альфа- и бета-. Классификация по исполнителям и времени проведения исследования. Альфа-тестирование проходит на ранней стадии разработки, и в нем участвуют штатные специалисты организации-разработчика. Иногда допускается привлечение конечных пользователей. Бета-тестирование подразумевает под собой выпуск почти готового продукта для ограниченного числа будущих пользователей. Данный вид преследует цель собрать обратную связь от клиентов и при необходимости внести изменения в работу ПО.
4. Позитивным и негативным. Тестировщик может использовать для испытания приложения корректные (позитивные) сценарии или некорректные (негативные). Первый вариант предусматривает введение правильных данных, воспроизведение реальных схем поведения, т. е. проверку работоспособности в нормальных условиях. При втором варианте инженер предпринимает неадекватные шаги взаимодействия, отправляет неправильные запросы и пр. Другими словами, проверяет программу на устойчивость в нестандартных ситуациях.

Что тестируют на разных этапах разработки

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

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

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

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

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

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

Всего их семь, и они являются общим руководством для QA-специалистов (Quality Assurance — обеспечение качества). Итак, тестировщик должен знать и понимать, что:

1. Тестирование показывает наличие дефектов, но не гарантирует их отсутствие. Проводя тесты, вы снижаете вероятность наличия ошибок в ПО, однако не можете доказать, что их нет. Проще говоря, если инженер не обнаружил дефекта, это не означает, что он отсутствует.
2. Исчерпывающее тестирование невозможно. Нельзя протестировать программу «на всё». Ввести все возможные комбинации входных данных и предусмотреть каждое развитие событий, способное привести к сбою, — это физически неосуществимая задача.
3. Чем раньше проводится тест, тем проще и дешевле исправить обнаруженный дефект. Запускать проверку следует уже на начальных этапах разработки, чтобы не пришлось перелопачивать весь код для устранения ошибки.Раннее тестирование экономит деньги и время.
4. Большинство дефектов скапливается в ограниченном количестве модулей. Принцип носит название «Кластеризация дефектов» и наглядно демонстрирует закон Парето: 80% проблем содержатся в 20% кода.
5. Существует парадокс пестицида, суть которого заключается в постепенном снижении эффективности от повторения одних и тех же действий. Раз за разом применяя одинаковые тестовые сценарии, рано или поздно вы перестанете обнаруживать новые баги.
6. Контекст важен. Выбор методологий и инструментов, с помощью которых будет проверяться программа, осуществляется с учетом ее предназначения и предъявленных к ней требований. Тестирование зависит от контекста.
7. Дефекты — это не только технические ошибки, но и проблемы в юзабилити, вопросы к практической ценности продукта. Заблуждение об отсутствии ошибок приводит к негативным последствиям. Если во время тестов не обнаружились баги, это еще не значит, что программа готова к релизу.

Помимо следования этим принципам, нелишним будет соблюдать на практике и следующие рекомендации:

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

Заключение

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

Автор: Макхост