Сегодня у нас на повестке дня опять теория тестирование по обсудим цели, этапы, виды тестирования. А начнём мы как обычно с плана занятия. Что сегодня у нас будет?
Сегодня повторим, что такое тестирование, обсудим основные этапы тестирования по более поверхностно, поскольку это будет всё-таки ещё дополнительно будем обсуждать на следующих занятиях. А дальше обсудим, какие у нас в принципе тестирования есть. Также поговорим о классификации тестирования, ну и более подробно про виды тестирования в целом.
А давайте начнём с того, что опять-таки вспомним, что такое тестирование. Тестирование - это у нас как раз как раз-таки проверка программного обеспечения на соответствие требованиям с целью повышения качества продуктов. А цель тестирования - это представление, гарантии того, что продукт работает как задумано.
Также мы добавляем уверенность в качестве продукта. Одной из наших целей - это обнаружение исправление дефектов до выпуска продукта. Также мы оптимизируем затраты на исправление дефектов.
Мы с помощью тестирования сокращаем время разработчиков на исправление, соответственно, на разработку, а также снижаем риск сбоев и негативных отзывов после релиза. Это уже, конечно, больший плюс, наверное, для бизнеса, но тем не менее. Если хочешь получать эксклюзивный контент и быть в курсе новых видео, загляни ко мне на бусте.
Там я регулярно выкладываю новые ролики, которые не всегда выходят на YouTube. Также у нас есть закрытые чаты, где можно общаться, задавать вопросы и делиться идеями. Поддержи мой канал и стань частью нашего дружного сообщества.
Ссылка в описании. А так. Угу.
Идём дальше к основным этапам переходим. А первый этап - это у нас анализ требований. У нас тестирование всегда начинается с анализа требований, поскольку нам необходимо изучить, а как у нас работает программа.
Даже на этапе анализа требований мы уже можем какие-то предугать ошибки, которые у нас могут появиться в продукте, основываясь как раз-таки на своём опыте и читая внимательно требования. Про все атрибуты требований, как протестировать их, мы также поговорим на следующем занятии. Пока это такою тему немножко оставим.
А второй этап - это у нас планирование тестирования. Здесь мы будем полностью составлять план тестирования, что мы будем тестировать в каком объёме, в каких сроках, какие нам необходимы для этого ресурсы. А третий этап - это как раз-таки написание тестовой документации.
Опять же, мы здесь опираемся на требования, составляем наши тесткейсы, пишем, что мы будем тестировать, какими способами, применяем техники тестдийна. Тоже немножко наперёд забегаю, но тем не менее. А далее, следующий этап - это настройка тестовой среды.
Тут два варианта. Либо мы тестовую среду настраиваем сами, разворачиваем окружение, а, подготавливаем все тестовые данные, которые нам необходимы для проведения тестирования. Либо нам это могут подготовить либо разработчики, либо девопсы, тоже в зависимости от того, как это будет настроено в компании и на вашем непосредственном проекте.
Мм, следующий этап - это выполнение тестов. Тут мы непосредственно уже проходимся по написанной нами тестовой документации, проводим проверки, смотрим на работоспособность программы. Далее как раз-таки анализ результатов прогонов и подготовка отчётности.
А на данном этапе наша главная цель - это сделать такое небольшое ревью того, какие у нас были ошибки, были ли они вообще, подготовить отчёты о найденных ошибках и добавить их на доработку. И как раз-таки следующий, седьмой этап завершения тестирования. Здесь уже после исправления ошибок мы подводим резюме, готов ли продукт к выпуску для пользователя либо нет.
Самая главная цель - это подбить ревью готовности продукта. Так, переходим тогда к следующей такой нашей мини-теме - это принципы тестирования. А что в себя включают принципы тестирования?
То, на чём, в принципе, да, всё основывается. А одним из таких принципов это является невозможность протестировать весь продукт. Всё невозможно протестировать, поскольку у нас вдики есть какое-то ограничение на количество времени, а на то, что у нас очень много может быть сценариев, и мы просто физически не сможем их провести.
А, и как правило, это всё отбирается по приоритету либо по уже Ладно, извини, потеряла потеряла мысль, как отвлекли. А, в общем, мы, получается, выбираем тесты по приоритету, по договорённости заказчикам либо с командой. А дальше у нас второе - это тестирование показывает наличие ошибок, но не их отсутствие.
Что в себя это включает? То есть мы даже протестировав тесты и э если они у нас все пройдут на 100%, все будут зелёные, да, условно говоря, то это не значит, что ошибок в программе нет. Возможно, просто мы написали такие тест-кейсы, такие подготовили тестовые данные, которые просто не затрагивают функционал, в котором есть ошибки.
А либо просто есть какие-то так называемые-кейсы, да, либо обходные пути, которые мы просто пока ещё не нашли, и там могут быть баги. Вот следующее, это раннее тестирование, экономит ресурсы. Что тут включается?
Опять же, мы возвращаемся к этапу анализа требований. Если мы начнём тестировать на этапе анализа требований, а чем раньше мы их найдём, чем раньше мы эти ошибки предотвратим, тем, соответственно, меньше мы потратим и времени, и денег на то, чтобы пофиксить, соответственно, в сэкономим ресурс, да. А далее, скопление багов.
Здесь у нас говорится о том, что в большинство ошибок сосредоточено в небольших частях модулей. Что здесь? Чем меньше модуль, чем меньше мы его трогаем, потому что это кажется такое минорное, не обязательное либо очень лёгкое, тем больше вероятность, что там могут быть баги, потому что мы просто можем даже про это забывать, про эти части.
Мм, следующее - это парадокс пестицида. Тут такое тоже двоякое ощущение в том плане, что если мы будем постоянно проверять на тех, на одних и тех же наборах тестовых данных наши тесткейсы и чек-листы, то, соответственно, мы можем просто перестать находить баги, потому что система станет устойчива к нашим вводимым тестовым данных. М, далее, следующее.
Это у нас тестирование зависит от контекста. Тут данный принцип голасит о том, что у нас методы выбираются в зависимости от типа продукта и требований. А о чём это нам говорит?
О том, что мы должны подстраиваться под условия. Если, допустим, мы тестируем какое-то медицинское оборудование, да, медицинское программное обеспечение, мы должны сосредоточиться всё-таки больше на тестирование безопасности, на тестирование отказа устойчивости. Это мы сейчас тоже поговорим отдельно про виды тестирования.
Для чего? Для того, чтобы мы были уверены о том, что наше оборудование не даст сбой, поскольку в данном случае нам очень важно именно вот, допустим, эти два пункта, да? А если мы будем тестировать какие-то маркетплейсы, то мы будем больше времени уделять на тестирование, допустим, э регистрации, авторизации, там корзины, в общем, всё, что связано с покупками, всё, что приносит бизнесу деньги.
А далее, следующий пункт - это как раз-таки отсутствие ошибок, незачит готовность продукта. Мм, тут мы говорим о том, что мы должны учитывать не только функциональные требования, но ещё и нефункциональность, нефункциональные, потому что если мы допустим, протестировали весь функционал продукта и говорим о том, что да, он вот он супер-перкрутой, мы вообще ни одного багадим, но если им будет неудобно пользоваться, если у нас, э, либо производительность хромает, либо у нас, допустим, неудобно пользоваться в том плане, что э в том плане, что это будет просто неправильно настроенные кнопки, либо не так, как пользователь привык, там, допустим, кнопка, не знаю, покупки будет находиться где-нибудь вверху, либо добавление в корзины, а не внизу справа, как все привык. выли сейчас на большинстве маркетплейсов, это будет выводить пользователей в ступор, и мы просто будем терять клиентов.
А так давайте перейдём к следующей теме. Это как раз-таки классификация видов тестирования. Как мы можем видеть на всех наших, то есть фотографиях, их достаточно много.
А мы можем найти в разных источниках разную классификацию, разные картинки, разные подразделения на все эти типы виды и так далее. А я бы сказала, что одной из самых правильных классификаций здесь - это вот как раз-таки вот эта вот картинка сверху справа, поскольку, во-первых, в большинстве случаев мы можем встретить именно её. И как показывает практика, это, наверное, один из самых правильных распределений.
А, но я бы сказала так, что, э, что тестирование принято всё-таки делить на две большие группы. Это функциональное тестирование и нефункциональное тестирование. И в некоторых материалах ещё встречается разделение на третий тип - это тестирование, связанное с изменениями.
Оно же, в принципе, эксплуатационное тестирование. Если мы сейчас будем говорить вот, да, отдельно про каждый из видов тестирования, функциональное тестирование, подразумевает под собой проверка именно функционала системы, то, как программное обеспечение должно работать, как какие функции оно должно выполнять. То есть проверка того, что система работает так, как именно заявлена в требованиях.
Мм, давайте сначала, наверное, мы поговорим отдельно про функциональное тестирование, потом верёмся дальше к нефункциональному и так далее. Что в себя включает функциональное тестирование? Тут опять мы возвращаемся к классификации.
Мы можем функциональное тестирование разделить на эт здесь у меня представлены несколько примеров того, на какие классификации, какие виды тестирования мы выделяем. Допустим, мы можем выделить тестирование по способу выполнения. То есть это может быть ручное тестирование, когда мы проверяем только руками весь функционал.
А, автоматизированное тестирование, когда мы, соответственно, пишем тесты, выполняем с помощью специальных программ, скриптов, языков программирования и так далее. А полуавтоматизированное - это когда часть тестирования проводится вручную, часть с использованием автоматизации. Например, если забегать вперёд, мы об этом, конечно, тоже поговорим дальше.
А у нас есть тестирование апи с помощью постомана, да, мы тестируем backend. А мы можем не только написать какие-то проверки непосредственно для тестирования бэкэнда, но ещё запрограммировать, написать скрипты, чтобы у нас, допустим, они запускались сразу коллекции подряд, там несколько штук и выполнялись какие-то определённые действия уже после либо до скрип, либо до выполнения запроса, либо после выполнения запроса. Это считается тоже как полуавтомазированное тестирование.
А так следующий это по стадии тестирования. Я бы ещё назвала бы, наверное, просто по доступу к коду, потому что это может быть статическое тестирование, как раз-таки, когда мы анализируем документы, когда мы смотрим просто на сам продукт, допустим, тестируем дизайн, когда мы смотрим в код, если у нас есть, конечно, такая экспертиза, да, мы можем посмотреть код разработчика либо код написанных автотестов. А и динамическое тестирование - это когда уже проверка работы программы в действию.
С одной стороны, это, в принципе, если мы зайдём на любой сайт, начнём его тестировать, в некоторой степени это тоже будет динамическое тестирование. Либо когда мы будем запускать наши коллекции в Космоне, когда мы будем запускать, либо автоматизатор будет запускать автотесты, это тоже динамическое тестирование. Так, следующее.
По доступу к коду. Тут немножко как будто бы пересекается с предыдущей классификацией, но не совсем так. У нас есть тестирование по доступу в коду, соответственно, тестирование белого ящика, тестирование чёрного ящика и серого ящика.
Что нам говорит про тестирование белого ящика? Это когда мы имеем полный доступ к исходному коду, когда мы можем там залезть, посмотреть, что там разработчик написал, либо, возможно, даже вносить сами правки. А тестирование чёрного ящика - это когда я, как тестировщик, буду тестировать только пользовательский опыт, да, когда буду тестировать только фронт, только интерфейс без всего.
И тестирование серого ящика - это как раз-таки частичный доступ к коду либо к внутренней логике программы. Здесь мы можем не только тестировать как пользователь, но ещё, например, смотреть запросы через DEFTS либо через Postman, иметь доступ в базу данных. Это всё относится к тестированию серого ящика.
А также по уровню тестирования. Мм, в принципе, э, функциональное тестирование по уровню тестирования можно сказать о том, что это то же самое, что и пирамиды нашего тестирования, да? А тут есть такие виды, как модульная, когда мы проверяем отдельные компоненты кода.
А это чаще всего относят к разработчикам. Также он ещё называется юнит-тестинг, да. Разработчики очень часто пишут юнит-тесты, модульные тесты.
А по сути это будет тестирование без нашего участия, поскольку вы просто не запустите тесты, проверятся отдельные компоненты, отдельные классы и всё скажет, всё всё о'кей. можно там заливать, допустим, на ну на продакшн пользователем, либо же хотя бы просто перетекать вdф для нашего тестирования дальнейшего. А следующий уровень - это интеграционное тестирование как раз практики, когда мы тестируем либо взаимодействие между конкретными модулями, ну, модули между собой взаимодействую, либо когда у нас есть внешние интеграции, допустим, с системами оплаты, либо у нас есть какие-то интеграции с авторизацией.
К примеру, у нас не только авторизация по лобину и паролю либо по номеру телефона, но и, допустим, там через Google либо через Яндекс, ну, и прочие системы. А следующее - это у нас системное тестирование, когда мы проверяем работоспособность всей системы в целом. А это уже будет этап, допустим, перед релизом нашим на прод, когда мы будем проводить тестирование.
И приёмочное тестирование - это как раз-таки тестирование на соответствие требованиям заказчикам. Оно может проводиться как и на продакшене, когда мы будем проверять пользовательский путь, да, те же самые end тесты, а либо когда мы будем проверять, как вот здесь я тоже указала, допустим, уд тестирование. Что под собой подразумевает уд тестирование?
Это когда мы проводим на он также называется, как ещё препрод, когда мы проводим тестирование перед самим релизом, уже конкретно перед выдкой в том плане, что будем тестировать на соответствие требованиям заказчикам. Возможно, мы будем прямо заказчику предоставлять, показывать, как работает наша система. А и один из таких последних модулей классификаций, точнее, которые я здесь выделила - это по степени подготовности, подготовленности тестовой документации, я бы даже назвала, и, ну, самого человека-тестировщика.
Это может быть формальное тестирование, когда у нас есть чётко прописанная документация, чётко прописанные тесты, и мы идём конкретно по ним без шага влево, шага вправо, только конкретно по тесту. А есть хок тестирование. Это когда уже более свободное тестирование.
У нас не будет никакой ни подготовки, никаких ожидаемых результатов, ничего. Просто садишься и с нуля изучаешь всю систему, как она работает. И исследовательское тестирование.
Здесь у нас уже будет какая-то подготовленная тестовая документация, возможно, нами, возможно, другим тестировщикам, кем-то, кто был до вас на проекте. А мы будем выходить, мы будем проходить эти тесты и также во время нашего тестирования будем проходить по тестам, возможно их править, возможно писать новые. И получается, что у нас каждый последующий тест должен будет вытекать из предыдущего теста.
Вот м тут пока мы с функциональными, да, закончили. Их достаточно ещё будет много. У нас ещё позитивное тестирование, негативное тестирование.
Э, в общем, ещё очень-очень много видов. Я отдельно тоже ещё приложу информацию обо всём, что ещё есть. Так, давайте перейдём теперь к следующему.
Мм, нефункциональное тестирование. Нефункциональное тестирование - это как раз-таки проверка способа работы системы, свойств, которые не относятся к функциональности. То есть здесь мы как раз-таки можем проверять такие проводить такие виды тестирования, как тестирование, установки.
Соответственно, мы будем проверять способы установки приложений, его настройки, его удаления. Это уже больше будет касаться десктопных приложений, чем веб. А дальше следующий вид - это тестирование удобства использования.
Оно же тестинг, оно же UX UIUX тестирование. В принципе, как раз-таки мы здесь будем смотреть и оно у нас будет характеризовать тестирование м системы с точки зрения, э, с точки зрения конечного пользователя, насколько удобно пользоваться системой и приложением в целом. А следующее конфигурационное тестирование, когда мы проверяем работоспособность на разных браузерах, различных условиях, различных конфигурациях, тестирование локализации.
Здесь проверка языков, переводов, формада, соответственно, нормативным актам страны, что оно по себя подразумевает. Если, например, у нас возвращаемся опять к тем же маркетплейсом, моя любимая тема и примеры. А если, допустим, мы как - как франшиза, например, да, которая работает не только там, допустим, по России, но ещё в других разных странах, если мы говорим о том, что мы работаем, допустим, в азиатских странах, либо в странах, где у нас, к примеру, живут, не знаю, там, мусульмане, либо ещё кто-нибудь, а мы должны в своих вот этих маркетплейсах учитывать не только какие-то там переводы в нормативные акты и тд и тп, но ещё и менталитет, допустим, пользователей.
Если мы там говорим о мусульманских странах, у нас не должно быть там маркеплейсе продажи алкоголя, там, свинины и любых ещё запрещённых продуктов. Это тоже всё относится к тестированию локализации. Далее, следующий момент, тестирования производительности.
Как раз-таки вот тут вот будет набор видов тестирования, да, подвидов. Я бы даже сказала, сейчас чуть попозже тоже об этом поговорим. Как раз-таки оно будет у нас направлено на воссоздание пользовательских запросов и сравнение ожидаемых результатов с полученными показателями.
Мм, как правило, этот вид тестирования у нас автоматизирован, и, э, можно сказать даже о том, что это обычно занимаются отдельные люди, потому что это небольшая небольшое ответвление отдельное для развития тестировщика и тестирование безопасности. Как разтаки комплекс исследовательский исследований програмного обеспечения направлен на на тестирование, обнаружение и исправление дефектов связанно с сохранению пользовательских данных. Здесь мы должны проверять, что если у нас авторизация, то мы не передаём наши пользовательские данные, что их не так легко, их нельзя перехватить, что мы, э, при введении SQL-инъекций это один из видов тестирования.
Если мы будем делать, пытаться как-то какие-то делать атаки либо вот эти вотлии инъекции ввести, чтобы протестировать безопасность, то у нас будут в сохранности данные в базе данных, что мы не можем, что мы не не предоставляем злоумышленникам доступа к пользовательским данным. Вот. Давайте немножко ещё более подробно про тестирование как раз-таки производительности и безопасности.
М тестирование производительности ещё также относит нагрузочное тестирование - это когда мы оцениваем поведение системы при возрастании нагрузок нагрузки до определённого максимума и как она будет работать на вот этих вот максимумах на этом максимуме. А есть тестирование стабильности, как раз-таки проверка на длительном интервале времени и не на пиковой нагрузке. Что тут говорится о чём?
О том, что мы можем, допустим, у нас система выдерживает 500 пользователей одновременно. И вот мы будем проверять, э, на протяжении какого времени система будет стабильно работать, выдерживая вот это этих максимально 500 пользователей. То есть когда будет отправляться 500 запросов там в секунду, что она работает, например, там 8 часов стабильно.
Если нет, соответственно, нам придётся что-то там дорабатывать ещё. Вот. А есть у нас ещё сразу хотела сказать о том, что у нас есть тестирование ещё на отказ восстановление.
Оно, по сути чем-то мне напоминает всегда смесь вот и нагрузочного, и тестие серойно стабильности. В каком плане? В том плане, что если у нас система упадёт, она должна очень быстро, э, по сути подняться после снижения нагрузки.
И всегда мне казалось, что это должно быть прямо вот эти вот три вида вместе. Ну, может быть, кто-то со мной, конечно, поспорит. А вот дальше стресс-тестирование, качест работоспособность, приложение при нагрузках, превышающие пользовательские в несколько раз.
чем-то похоже на нагрузочное тестирование, но нагрузочное тестирование всё-таки будет по возрастающей идти, то есть увеличивается количество запросов на каком-то определённом интервале. А здесь при стресс-тестировании мы должны в какой-то определённый момент прямо максимум, а ещё возможно даже и больше максимума дать нагрузки на систему. И тогда можем сказать о том, что система прошла стресс-тестированием.
И осталось у нас одно, которое я ещё не озвучила - это объёмное тестирование. Здесь мы будем оценивать поведение программы при увеличения объёма данных в базе. Опять же, здесь можно, допустим, при нагрузке, если пользователей будет много, они будут отправлять много запросов, будет создаваться много сущностей в базе данных, у нас база не должна упасть.
Возможно, у нас есть несколько баз данных, да, к примеру, у нас должен быть какой-то балансировщик, который будет вовремя это распределять. И вот как раз-таки при объёмном тестировании мы всё это проверяем. И, э, ещё остался момент, который мы не проговорили, это про тестирование безопасности.
Вообще в целом, для чего оно нам необходимо? для проверки целостности приложения, да, когда у нас как раз-таки ограничения круг есть ограничения на на пользователей, есть ограничения на доступа к каким-то данным определённым определённым компонентам программы. Например, у нас есть роль администратора, есть роль обычного пользователя.
Мы должны проверять, что администратору доступен один функционал, обычным пользователем другой. Э доступность тут тоже, на самом деле, с одной стороны чем-то похожа, но разграничение в том плане, что, э, тут ещё больше идёт разграничения всё-таки на авторизованных пользователей и неавторизованных пользователей. И вот чем у нас будет критичнее данные, чем у нас больше будет завязано здесь логики, тем у нас должны быть жёстче и выше уровни доступа и конфиденциальность, сокрытие определённых ресурсов или информации.
Ну, как будто бы я всё это проговорила в одном. Вот. Но тем не менее.
Так. И у нас остался э последний, наверное, последнее разделение - это как раз-таки эксплуатационное тестирование. Оно же тестирование, которое у нас связано с изменениями.
Тут сразу проговорю, что везде и всегда, ну, мы тоже можем говорить о том, что регрессионное, санитарное, дымовое тестирование, оно относится к функциональному тестированию. И по сути эксплуатационное тестирование, оно и относится к функциональному тестированию, просто его в некоторых ресурсах, в большинстве случаев, а, подразделяют на три группы. Вот что себе предостав предоставляет регрессионное тестирование.
Это как раз-таки тестирование, когда мы проверяем систему на э на то, что она будет работать так же, как и раньше, при внесении новых изменений. Но мы тут будем проверять полностью всю систему после любых изменений. А на него очень многие его путают, точнее, с дымовым тестированием.
Но тут немножечко есть различия в том плане, что при дымовом тестировании мы проверяем только критически важный функционал после внесения изменений. То есть, если, опять же, возвращаюсь к тому же маркетплейсу, если у нас есть, э, функционал, любой функционал в маркетплейсе, и мы должны провести смог, домовое тестирование, то мы будем проверять критически важный функционал. Допустим, для маркетплейса это может быть опять же та же регистрация, авторизация, каталог товаров, да, корзина и всё, что связано с оформлением и оплатой.
Вот это будет наш критически важный функционал. Мы будем проверять при домовом тестировании, при регрессионном тестировании мы же будем проверять весь функционал. То есть не только вот эти вот части системы, которые я назвала, ну ещё, например, там карточку, товары смотреть, фильтры смотреть, как это всё работает, а как заказы, как проходит, точнее, статусы заказов, когда он только получен, когда доставлен.
То есть полностью всю систему. А санитарное тестирование. При санитарном тестировании мы проверяем, что определённые части системы работают после исправления багов, минорных багов и внесения минорных изменений.
То есть мы должны проверить более детально компоненты системы и подготовить уже как раз-таки к, допустим, дымовому тестированию, потому что санитарное тестирование, оно по сути проводится м мы, конечно, тоже это будем потом дальше об этом говорить. Как правило, допустим, вот у меня происходит на проекте, у нас когда разрабатывается какая-то функциональность, она разрабатывается на отдельном, э, в отдельной ветке, да, так называется, на отдельном окружении. И после разработки мы, по сути, проводим вот это санитарное тестирование, когда мы тестируем функциональность изолированно от других от других там нововведений, да, от других новых функций и в целом вообще просто фокусируемся именно на неё.
После того, когда мы провели вот это вот санитарное тестирование, когда мы проверили одну функциональность, мы можем говорить о том, что да, этот функционал готов к тому, чтобы его катили дальше, чтобы его переводили, допустим, в следующий шаг. Следующий шаг - это будет проведение, допустим, дымового тестирования на тестовом окружении. После того, как когда мы проведём на тестовом окружении дымовое тестирование, у нас собирается уже регресс, и мы будем готовы проводить регресс уже непосредственно на продакшене, точнее, подготовиться к выходке на продакшене.
Если хочешь получать эксклюзивный контент и быть в курсе новых видео, загляни ко мне на бусте. Там я регулярно выкладываю новые ролики, которые не всегда выходят на YouTube. Также у нас есть закрытые чаты, где можно общаться, задавать вопросы и делиться идеями.
Поддержи мой канал и стань частью нашего дружного сообщества. Ссылка в описании.
