что такое тестирование в программировании
Вводная статья по тестированию: F.A.Q. новичка
Тестирование программного продукта — один из важнейших этапов в процессе его разработки. Незнание основных терминов и понятий может усложнить работу тестировщика. Мы решили собрать самые распространенные вопросы по тестированию ПО, чтобы помочь тем, кто только начинает свой путь в профессии или просто интересуется сферой IT. Некоторые из них касаются теории тестирования, другие — практики, третьи — документации в тестировании.
Благодарим за помощь в подготовке материала «Аплана. Корпоративный университет» и в частности его преподавателей: Александра Бегларяна («Базовый курс тестирования и тест-дизайна») и Екатерину Дрюпину (курс «Ручное функциональное тестирование»).
Что такое тестирование программного обеспечения (ПО)?
Согласно «Руководству к своду знаний по программной инженерии» (IEEE, SWEBOK, 2004), тестирование — это проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.
Согласно «Стандартному глоссарию терминов, используемых в тестировании программного обеспечения» (ISTQB), тестирование — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и определения дефектов.
В разных источниках, скажем, в книгах, статьях, можно встретить большое количество определений понятия «тестирование». Разные специалисты пытались объяснить его как можно точнее, придумывая все новые и новые формулировки. Например, одна из самых простых: тестирование — это сравнение фактического результата с ожидаемым. А еще — одна из техник контроля качества, включающая планирование работ (Test Management), проектирование тестов (Test Design), выполнение тестирования (Test Execution) и анализ полученных результатов (Test Analysis). Это исследование программы с целью обнаружения ошибок; возможный способ оценки качества программного обеспечения в терминах найденных дефектов, исполненных тестов и протестированных систем и т.д.
Какие есть виды тестирования?
Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы:
Тестирование можно классифицировать…
По критерию запуска программы:
По объекту тестирования:
По степени автоматизации:
По времени проведения тестирования:
По степени подготовленности:
По признаку позитивности сценариев:
Есть еще более сложные и полные классификации. К примеру, вот такой вариант использует один из преподавателей «Аплана. Корпоративный университет» на своем курсе:
Можно ли выделить наиболее востребованные виды тестирования?
Опыт показывает, что наиболее востребованы ручное функциональное тестирование, автоматизированное функциональное тестирование и нагрузочное тестирование.
Ручное функциональное тестирование (РФТ) — это тестирование вручную, то есть без использования каких-либо автоматизированных средств. В этом случае инженер по тестированию берет на себя роль конечного пользователя и, в соответствии с тестовым сценарием, проверяет ПО или систему. Его задача — выявить поведение, отличное от ожидаемого конечным пользователем.
Ручное тестирование применяется в регрессионном (тестирование изменений), интеграционном (связь с другими системами) и при тестировании нового функционала.
Автоматизированное функциональное тестирование (АФТ) — процесс верификации программного обеспечения, при котором основные функции и шаги теста выполняются автоматически при помощи инструментов для автоматизированного тестирования. Для этого сначала разрабатывают ручные тесты, затем их автоматизируют — тесты выполняются программой-роботом, без привлечения ручных тестировщиков. АФТ может являться частью регрессионного тестирования и входить в комплексное.
Нагрузочное тестирование (НТ) позволяет определить, как и с какой скоростью программа работает под определенной нагрузкой. Нагрузочное тестирование рекомендуется проводить при выпуске нового программного обеспечения, доработке эксплуатируемого ПО и при изменении конфигурации стендов.
Есть ли какие-то базовые принципы тестирования?
Вот семь основных из них:
Как понять, когда нужно начинать тестирование?
Чем раньше обнаружен дефект, тем дешевле обходится его исправление, поэтому начинать тестирование нужно как можно раньше. Например, статическое тестирование (до фактического получения ПО) делает проще динамическую стадию. На ранних стадиях проще изменить тест-дизайн и т.д.
Что такое баги?
Баг (bug) или дефект — это отклонение фактического результата от ожидаемого, изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Баги находят на этапе тестирования, затем нужна отладка (дебаггинг), которую выполняет разработчик. Отладка (debugging) — процесс поиска, анализа и устранения причин отказов в программном обеспечении. После отладки исправление требует новой проверки тестировщиком.
Какие инструменты инженер по тестированию обычно использует в своей работе?
Тестировщик самостоятельно определяет скорость работы, при которой он наиболее внимателен и эффективен. Как специалист, он должен уметь проводить ревизию своих активностей для выявления возможности ускорения действий.
Базовые инструменты тестировщика:
Как можно оценить качество ПО?
Оценка программного обеспечения производится согласно международному стандарту ISO 9126. ПО будет качественным, если можно обеспечить его функциональность, надежность, удобство использования, удобство сопровождения, производительность и переносимость. Чем больше атрибутов качества можно реализовать или поддержать (для производительности — это соответствие стандартам, временная эффективность и эффективность использования ресурсов и т.д.), тем выше будет качество ПО. У атрибутов есть и численные показатели — метрики, которые позволяют измерять прогресс в достижении качества.
Что такое тест-план и что в нем должно быть написано?
Тест-план — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Как и в случае с тестированием, в профессиональной литературе можно встретить и другие определения тест-плана. Одно из самых коротких: тест-план — это документ, обобщающий и координирующий тестирование. А одно из самых длинных: тест-план — это документ, описывающий масштаб, подход, ресурсы и график тестирования, в котором определены тестовые элементы, отдельные части функционала, тестовые задания, специалисты, которые будут проводить конкретные тесты, и любые риски, требующие дополнительного планирования.
Основные разделы тест-плана:
Что такое тест-дизайн и зачем он нужен?
Тест-дизайн — одна из наиболее творческих деятельностей в IT. Это этап процесса тестирования ПО, на котором, в соответствии с определенными ранее критериями качества и целями тестирования, проектируются и создаются тестовые случаи (тест-кейсы).
Что является результатом работы инженера по тестированию?
Для большинства тестировщиков основной продукт работы — отчет о проделанных испытаниях в разрезе общего количества пройденных тестовых сценариев с их результатами, а также список открытых дефектов с указанием их критичности.
Есть ли какие-то книги, которые могут быть полезны новичку в тестировании?
Рекомендуем к прочтению следующие книги:
Что такое тестирование программ и зачем оно нужно
Оказывается, 75% времени при создании программ уходит вовсе не на программирование. Разбираемся, чем же занимаются тестировщики.
Вероятно, ни одну вещь в мире нельзя сделать без ошибок, и программы не исключение. Допустим, вы написали код и не видите в нём явных багов. Как узнать, что будет при реальном использовании: поведёт ли себя программа так, как от неё ожидают?
Почему тестирование — это так важно
Вот типичные программные баги:
Прежде чем новая версия компьютерной программы, сайта или мобильного приложения попадает к пользователю, она должна пройти через руки инженеров-тестировщиков. Они ищут места в коде, где программа работает не так, как задумано. Чтобы найти как можно больше ошибок, тестировщики моделируют разные ситуации, которые могут возникнуть при использовании приложения.
Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.
Профессия Тестировщик
Вы научитесь тестировать сайты, мобильные приложения и другое ПО. Узнаете, как устроена работа IT-компаний, и сможете понять, как вы хотите развиваться в профессии. Гарантированно получите работу. Уже джуниоры очень востребованы рынком, а наш курс позволит достичь middle-уровня.
Какие виды тестирования существуют
Пользователи непредсказуемы. Они могут делать не только то, что предусмотрено программой, но и то, что ею категорически не предусмотрено. Тестировщик должен проверить все возможные и невозможные сценарии их поведения и убедиться, что программа продолжает работать.
Вообще, у тестирования есть философия, которая строится на том, что в любой программе по определению есть ошибки и найти их все невозможно. А если вы почему-то не нашли ошибку, значит, просто плохо искали. Удачный тест для тестировщика — тот, при котором нашли баг. А если всё нормально работало, значит, тест неудачный и свою задачу не выполняет.
Ошибки возникают не только при кодировании, но и при проектировании системы, и даже на этапе разработки технического задания. Поэтому и тестируют код не только в самом конце работы, а на разных этапах.
Есть несколько видов тестирования:
Что тестируют на разных этапах разработки
Есть несколько уровней тестирования. Их проводят в разное время:
В зависимости от этапа разработки перед тестировщиками стоят разные цели:
Не бывает идеального тестирования: в принципе невозможно доказать, что программа работает правильно при любых условиях. Но тестировщики могут найти и уточнить, в каких условиях она работает неправильно.
Как обычно проходит тестирование
Как правило, тестировщики начинают работать с программой сразу после начала проекта:
После выхода каждой новой сборки программы сначала делают дымовое тестирование — проверяют, что приложение запускается и выполняет основные функции. Если всё в порядке, программу передают на дальнейшее тестирование. Если нет — сразу возвращают на доработку.
Следующий этап — регрессионное тестирование. Тестировщики ищут баги в новых участках кода и в тех местах, где исправляли ранее найденные ошибки.
После этого программу проверяют в разных уровнях: испытывают её функциональность, производительность, работу с окружением. Это можно делать вручную или с помощью автоматических тестов-кейсов.
Автоматизированное тестирование облегчает проверку и экономит время. Лучше всего это работает в сложных приложениях с большой функциональностью.
Когда есть результат, инженеры-тестировщики готовят отчёт по тестированию и отправляют его разработчикам, чтобы те исправили найденные баги. Так происходит от версии к версии, пока результаты не будут удовлетворять критериям, описанным в тест-плане.
Кто всё это делает: немного о профессии
Если проект большой, над ним работает целая команда: одни тестировщики готовят тесты, другие проверяют их полноту и логику, третьи занимаются непосредственно тестированием. Над небольшими задачами может работать один специалист, причём удалённо.
Тестировщики — среди самых востребованных сейчас специалистов-айтишников. Появляется множество новых программ, и каждой из них нужен контроль качества. QA-специалистов нанимают крупные компании-разработчики ПО, они могут стать фрилансерами и работать сразу на несколько фирм.
Как показывает статистика работных сайтов, на рынке не хватает разработчиков автотестов, а специалистов ручного тестирования достаточно. Средняя зарплата тестировщика в Москве больше 120 тысяч рублей, а по регионам —
примерно 55–60.
На скриншотах ниже — данные с HeadHunter. В сентябре 2020 года там было 3000 открытых вакансий тестировщика.
Виды тестирования и подходы к их применению
Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.
Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию, которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection. Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость — в конструктор, в свойство или в метод.
Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.
По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.
Интеграционное тестирование
Интеграционное тестирование, на мой взгляд, наиболее сложное для понимания. Есть определение — это тестирование взаимодействия нескольких классов, выполняющих вместе какую-то работу. Однако как по такому определению тестировать не понятно. Можно, конечно, отталкиваться от других видов тестирования. Но это чревато.
Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.
Подходить же к интеграционному тестированию как к более детализированному системному тоже не получается. В этом случае наоборот тестов будет мало для проверки всех используемых в программе взаимодействий. Системное тестирование слишком высокоуровневое.
Идея простая. У нас есть входные данные, и мы знаем как программа должна отработать на них. Запишем эти знания в текстовый файл. Это будет спецификация к тестовым данным, в которой записано, какие результаты ожидаются от программы. Тестирование же будет определять соответствие спецификации и того, что действительно находит программа.
| Проиллюстрирую на примере. Программа конвертирует один формат документа в другой. Конвертирование хитрое и с кучей математических расчетов. Заказчик передал набор типичных документов, которые ему требуется конвертировать. Для каждого такого документа мы напишем спецификацию, где запишем всякие промежуточные результаты, до которых дойдет наша программа при конвертировании.
1) Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами: $SectionNames = Введение, Текст статьи, Заключение, Литература 2) Другой пример. При конвертировании нужно разбивать геометрические фигуры на примитивы. Разбиение считается удачным, если в сумме все примитивы полностью покрывают оригинальную фигуру. Из присланных документов выберем различные фигуры и для них напишем свои спецификации. Факт покрываемости фигуры примитивами можно отразить так: $IsCoverable = true |
Понятно, что для проверки подобных спецификаций потребуется движок, который бы считывал спецификации и проверял их соответствие поведению программы. Я такой движок написал и остался доволен данным подходом. Скоро выложу движок в Open Source. (UPD: Выложил)
Данный вид тестирования является интеграционным, так как при проверке вызывается код взаимодействия нескольких классов. Причем важен только результат взаимодействия, а не детали и порядок вызовов. Поэтому на тесты не влияет рефакторинг кода. Не происходит избыточного или недостаточного тестирования — тестируются только те взаимодействия, которые встречаются при обработке реальных данных. Сами тесты легко поддерживать, так как спецификация хорошо читается и ее просто изменять в соответствии с новыми требованиями.
Системное тестирование
Системное — это тестирование программы в целом. Для небольших проектов это, как правило, ручное тестирование — запустил, пощелкал, убедился, что (не) работает. Можно автоматизировать. К автоматизации есть два подхода.
Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.
Способы тестирования программного обеспечения
Всем привет! Уже на следующей неделе мы запускаем новый поток по курсу «Автоматизация веб-тестирования». Этому и будет посвящен сегодняшний материал.
В этой статье рассматриваются различные способы тестирования программного обеспечения, такие как модульное тестирование (unit testing), интеграционное тестирование (integration testing), функциональное тестирование (functional testing), приемочное тестирование (acceptance testing) и т.д.
Есть множество разных типов тестов, которые вы можете применить, чтобы убедиться, что изменения в вашем коде работают по сценарию. Не все типы тестирования идентичны, хотя здесь мы рассмотрим, насколько основные практики тестирования отличаются друг от друга.
Тестирование: ручное или автоматизированное?
Сначала надо понять различия между ручными и автоматизированными тестами. Ручное тестирование проводится непосредственно человеком, который нажимает на кнопочки в приложении или взаимодействует с программным обеспечением или API с необходимым инструментарием. Это достаточно затратно, так как это требует от тестировщика установки среды разработки и выполнения тестов вручную. Имеет место вероятность ошибки за счет человеческого фактора, например опечатки или пропуска шагов в тестовом сценарии.
Автоматизированные тесты, с другой стороны, производятся машиной, которая запускает тестовый сценарий, который был написан заранее. Такие тесты могут сильно варьироваться в зависимости от сложности, начиная от проверки одного единственного метода в классе до отработки последовательности сложных действий в UI, чтобы убедиться в правильности работы. Такой способ считается более надежным, однако его работоспособность все еще зависит от того насколько скрипт для тестирования был хорошо написан.
Автоматизированные тесты – это ключевой компонент непрерывной интеграции (Continuous Integration) и непрерывной доставки (continuous delivery), а также хороший способ масштабировать ваш QA процесс во время добавления нового функционала для вашего приложения. Однако в ручном тестировании все равно есть своя ценность. Поэтому в статье мы обязательно поговорим об исследовательском тестировании (exploratory testing).
Различные типы тестов
Модульные тесты считаются низкоуровневыми, близкими к исходному коду вашего приложения. Они нацелены на тестирование отдельных методов и функций внутри классов, тестирование компонентов и модулей, используемых вашей программой. Модульные тесты в целом не требуют особых затрат на автоматизацию и могут отрабатывать крайне быстро, если задействовать сервер непрерывной интеграции (continuous integration server).
Интеграционные тесты проверяют хорошо ли работают вместе сервисы и модули, используемые вашим приложением. Например, они могут тестировать интеграцию с базой данных или удостоверяться, что микросервисы правильно взаимодействуют друг с другом. Эти тесты запускаются с бОльшими затратами, поскольку им необходимо, чтобы много частей приложения работало одновременно.
Функциональные тесты основываются на требованиях бизнеса к приложению. Они лишь проверяют выходные данные после произведенного действия и не проверяют промежуточные состояния системы во время воспроизведения действия.
Иногда между интеграционными тестами и функциональными тестами возникают противоречия, т.к. они оба запрашивают множество компонентов, взаимодействующих друг с другом. Разница состоит в том, что интеграционные тесты могут просто удостовериться, что доступ к базе данных имеется, тогда как функциональный тест захочет получить из базы данных определенное значение, чтобы проверить одно из требований к конечному продукту.
Сквозные тесты (End-to-end tests)
Сквозное тестирование имитирует поведение пользователя при взаимодействии с программным обеспечением. Он проверяет насколько точно различные пользователи следуют предполагаемому сценарию работы приложения и могут быть достаточно простыми, допустим, выглядеть как загрузка веб-страницы или вход на сайт или в более сложном случае – подтверждение e-mail адреса, онлайн платежи и т.д.
Сквозные тесты крайне полезные, но производить их затратно, а еще их может быть сложно автоматизировать. Рекомендуется проводить несколько сквозных тестов, но все же полагаться больше на низкоуровневое тестирование (модульные и интеграционные тесты), чтобы иметь возможность быстро распознать серьезные изменения.
Приемочные тесты – это формальные тесты, которые проводятся, чтобы удостовериться, что система отвечает бизнес-запросам. Они требуют, чтобы приложение запускалось и работало, и имитируют действия пользователя. Приемочное тестирование может пойти дальше и измерить производительность системы и отклонить последние изменения, если конечные цели разработки не были достигнуты.
Тесты на производительности проверяют поведение системы, когда она находится под существенной нагрузкой. Эти тесты нефункциональные и могут принимать разную форму, чтобы проверить надежность, стабильность и доступность платформы. Например, это может быть наблюдение за временем отклика при выполнении большого количества запросов или наблюдение за тем, как система ведет себя при взаимодействии с большими данными.
Тесты производительности по своей природе проводить достаточно затратно, но они могут помочь вам понять, какие внешние факторы могут уронить вашу систему.
Дымовое тестирование (Smoke testing)
Дымовые тесты – это базовые тесты, которые проверяют базовый функционал приложения. Они отрабатывают достаточно быстро и их цель дать понять, что основные функции системы работают как надо и не более того. Такое тестирование направлено на выявление явных ошибок.
Дымовые тесты могут оказаться полезными сразу после сборки нового билда для проверки на то, можете ли вы запустить более дорогостоящие тесты, или сразу после развёртывания, чтобы убедиться, что приложение работает нормально в новой среде.
Как автоматизировать тесты
Тестировщик может проводить все тесты, указанные выше, вручную, но это будет крайне затратно и непродуктивно. Поскольку люди имеют ограниченную возможность производить большое количество действий с повторениями при этом все еще проводя тестирование надежно. Однако машина может с легкостью воспроизводить эти же действия и проверить, допустим, что комбинация логин/пароль будет работать и в сотый раз без каких-либо нареканий.
Если ваши тесты могут запускаться с помощью скриптов из терминала, вы можете автоматизировать их, использовав сервер непрерывной интеграции по типу Bamboo или же облачного сервера Bitbucket Pipelines. Эти инструменты будут мониторить ваши репозитории и исполнять наборы тестов, как только новые изменения будут запушены в основной репозиторий.
Если вы новичок в вопросах тестирования, обратитесь к нашему руководству по непрерывной интеграции, чтобы создать свой первый набор тестов.
Чем больше функций и улучшений добавляется в ваш код, тем больше возрастает потребность в тестировании, поскольку на каждом этапе вам необходимо убеждаться, что система работает корректно. Также это понадобится каждый раз, когда вы исправляете баг, поскольку было бы не лишним убедиться, что он не вернется снова после нескольких релизов. Автоматизация – это ключ к тому, чтобы это стало возможным; написание тестов рано или поздно станет частью вашей практики разработчика.
Вопрос заключается в том, надо ли вообще в таком случае проводить ручное тестирование? Короткий ответ – да, и оно должно быть сфокусировано на том, что называется «исследовательское тестирование» (exploratory testing), которое помогает выявить неочевидные ошибки.
Сессия исследовательского тестирования не должна превышать двух часов и должна иметь четко ограниченную область действия, чтобы помочь тестировщикам сосредоточиться на определенной области программного обеспечения. После информирования всех тестировщиков о границах проведения тестирования, на их усмотрения остаются действия, которые они будут предпринимать, чтобы проверить, как поведет себя система. Такое тестирование является дорогостоящим по своей природе, но очень полезно для выявления проблем с пользовательским интерфейсом или проверки работоспособности сложных рабочих процессов для пользователей. Такое тестирование важно проводить всякий раз, когда в приложение добавляется кардинально новая функция, чтобы понять, как она поведет себя в пограничных условиях.
Заметка о тестировании
Перед тем, как закончить эту статью, я хочу поговорить о цели тестирования. С одной стороны, очень важно удостовериться, что пользователи смогут использовать ваше приложение («Я не могу войти в систему», «Я не могу сохранить данные» и т.п.), но с другой стороны не менее важно проверить, что ваша система не ломается при вводе неверных данных или неожиданных действиях. Вам нужно предвидеть, что произойдет, когда пользователь сделает опечатку, попытается сохранить неполную форму или использует неправильный API. Вам нужно проверить, сможет ли кто-то из пользователей легко скомпрометировать данные, получить доступ к тому или иному ресурсу, к которому у него не должно быть доступа. Хороший набор тестов должен попытаться сломать ваше приложение и помочь понять предел его возможностей.
И, наконец, тесты – это тоже код! Так что не забывайте о них во время code review, поскольку они могут быть последним этапом перед выпуском продукта на потребительский рынок.
По устоявшейся традиции ждем ваши комментарии и приглашаем всех на день открытых дверей, который уже 18 марта проведет наш преподаватель — ведущий автоматизатор в тестировании в Group-IB — Михаил Самойлов.