перечислите виды тестирования по доступу к коду приложения
Виды тестирования по доступу к коду
Мы, как тестировщики, при тестировании продукта можем иметь доступ к его коду или не иметь. Почему оба подхода до сих пор существуют? Разве тестирование с доступом к коду не эффективнее? Может существует золотая середина? Давайте разбираться.
В терминологии тестирования фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли тестировщик доступ к исходному коду тестируемого ПО или нет.
Черный ящик
Разработка тестов методом черного ящика (black box test design technique) — процедура создания и/или выбора тестовых сценариев, основанная на анализе функциональной или нефункциональной спецификации компонента или системы без знания внутренней структуры. (ISTQB)
Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит.
Основной посыл такого тестирования в том, что мы не знаем, как устроена тестируемая система. Имеется ввиду изнутри. При таком тестировании тестировщик очень похож на обычного пользователя: тест анализ и исследование продукта он проводит опираясь на ТЗ (техническое задание), спецификации и прочую документацию, которая описывает этот продукт.
Получается, что идеи для тестирования идут от предполагаемых паттернов (pattern — образец) поведения пользователей. Поэтому такой подход еще называют поведенческим.
Пример. Заходим в приложение вызова такси и видим возможность привязать карту для автоматической оплаты. Начинаем думать как пользователь:
— Что, если привязать заблокированную карту?
— А если забыть/неверно указать срок действия карты?
— Долларовая карта привяжется?
— А может можно после вызова такси и подачи машины быстро отвязать ее до списания оплаты… Что тогда будет? Спишутся средства? Или водителю придет уведомление, что оплата изменилась с безналичной на наличную?
По сути, мы тестируем и строим предположения на основе того, что видим и рисуем себе в голове. То есть мы только предполагаем, что элементы должны работать таким образом и на основании этого подбираем тесты, но точно не уверены, что это именно так.
Либо открываем спецификацию и смотрим, как система должна работать. Потом запускаем продукт и сверяем его с тем, что указано в спецификации.
Таким образом, мы не имеем представления о структуре и внутреннем устройстве системы. Нужно концентрироваться на том, что программа делает, а не на том, как она это делает.
Белый ящик
Разработка тестов методом белого ящика (white-box test design technique): Процедура разработки или выбора тестовых сценариев на основании анализа внутренней структуры компонента или системы. (ISTQB)
Белый ящик является полной противоположностью черному ящику. При тестировании черного ящика, нам необходимо запускать программу и смотреть, что она делает. А в белом этого не требуется. Достаточно смотреть на код программы.
Основной посыл этого типа тестирования — нам известны все детали реализации тестируемой программы.
Тестирование методом белого ящика (прозрачного, открытого, стеклянного ящика, основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации – обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы, за пределы ее внешних интерфейсов.
Профессиональные тестировщики, которые тестируют методами белого ящика, имеют большую экспертизу в программировании, так как должны уметь читать код и находить в нем проблемы.
Серый ящик. Отдельный вид или миф?
Его основной посыл в том, что нам известны только некоторые особенности реализации тестируемой системы.
То есть, внутреннее устройство программы нам известно лишь частично. Предполагается, например, доступ к внутренней структуре и алгоритмам работы ПО для написания максимально эффективных тест-кейсов, но само тестирование проводится с помощью техники черного ящика, то есть, с позиции пользователя.
Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.
Кто-то говорит, что этот вид тестирования — это симбиоз белого и черного ящика. Кто-то противопоставляет его белому и черному, опираясь на то, что внутренняя структура тестируемого объекта изначально известна частично и выясняется по мере исследования.
ISTQB относит тестирование методами белого и черного ящика к методам проектирования тестов. Поэтому, ни о каком «среднем» или «промежуточном» методе в этом случае конечно и речи быть не может. Мы либо разрабатываем тесты, зная код, либо не зная его. То есть в классификации ISTQB такого вида тестирования не существует.
Думаю, что на собеседовании это явно стоит упомянуть.
Почему все ящики эффективны?
Методы белого и черного ящика не являются конкурирующими или взаимоисключающими. Наоборот, они гармонично дополняют друг друга, компенсируя имеющиеся недостатки.
Параллельное использование черного и белого ящиков увеличивает покрытие возможных сценариев:
То есть у каждого из методов тестирования свои неоспоримые плюсы, которые помогают выпустить качественный продукт.
_______
Напомню, что для каждого ящика тестирования есть свой набор техник тест-дизайна. Ведь это не просто виды тестирования, а методы проектирования тестов. Почитать об этих техниках можно тут https://vk.com/@zapiskisedogotestera-obzor-tehnik-test-dizaina
Есть вопросы по тестированию? Задавай тут.
Если что, то я всегда на связи✌
говориМ о тестировании
простым языком
Виды тестирования по доступу к коду
Почему оба подхода до сих пор существуют? Разве тестирование с доступом к коду не эффективнее? Может существует золотая середина? Давайте разбираться.
В терминологии тестирования фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли тестировщик доступ к исходному коду тестируемого ПО или нет.
Черный ящик
Разработка тестов методом черного ящика (black box test design technique) — процедура создания и/или выбора тестовых сценариев, основанная на анализе функциональной или нефункциональной спецификации компонента или системы без знания внутренней структуры. (ISTQB)
Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит.
Основной посыл такого тестирования в том, что мы не знаем, как устроена тестируемая система. Имеется ввиду изнутри. При таком тестировании тестировщик очень похож на обычного пользователя: тест анализ и исследование продукта он проводит опираясь на ТЗ (техническое задание), спецификации и прочую документацию, которая описывает этот продукт.
Получается, что идеи для тестирования идут от предполагаемых паттернов (pattern — образец) поведения пользователей. Поэтому такой подход еще называют поведенческим.
Пример. Заходим в приложение вызова такси и видим возможность привязать карту для автоматической оплаты. Начинаем думать как пользователь:
— Что, если привязать заблокированную карту?
— А если забыть/неверно указать срок действия карты?
— Долларовая карта привяжется?
— А может можно после вызова такси и подачи машины быстро отвязать ее до списания оплаты… Что тогда будет? Спишутся средства? Или водителю придет уведомление, что оплата изменилась с безналичной на наличную?
По сути, мы тестируем и строим предположения на основе того, что видим и рисуем себе в голове. То есть мы только предполагаем, что элементы должны работать таким образом и на основании этого подбираем тесты, но точно не уверены, что это именно так.
Либо открываем спецификацию и смотрим, как система должна работать. Потом запускаем продукт и сверяем его с тем, что указано в спецификации.
Таким образом, мы не имеем представления о структуре и внутреннем устройстве системы. Нужно концентрироваться на том, что программа делает, а не на том, как она это делает.
Белый ящик
Разработка тестов методом белого ящика (white-box test design technique): Процедура разработки или выбора тестовых сценариев на основании анализа внутренней структуры компонента или системы. (ISTQB)
Белый ящик является полной противоположностью черному ящику. При тестировании черного ящика, нам необходимо запускать программу и смотреть, что она делает. А в белом этого не требуется. Достаточно смотреть на код программы.
Основной посыл этого типа тестирования — нам известны все детали реализации тестируемой программы.
Тестирование методом белого ящика (прозрачного, открытого, стеклянного ящика, основанное на коде или структурное тестирование) – метод тестирования программного обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации – обязательны для этой техники. Тестирование белого ящика – углубление во внутреннее устройство системы, за пределы ее внешних интерфейсов.
Профессиональные тестировщики, которые тестируют методами белого ящика, имеют большую экспертизу в программировании, так как должны уметь читать код и находить в нем проблемы.
Серый ящик. Отдельный вид или миф?
Его основной посыл в том, что нам известны только некоторые особенности реализации тестируемой системы.
То есть, внутреннее устройство программы нам известно лишь частично. Предполагается, например, доступ к внутренней структуре и алгоритмам работы ПО для написания максимально эффективных тест-кейсов, но само тестирование проводится с помощью техники черного ящика, то есть, с позиции пользователя.
Эту технику тестирования также называют методом полупрозрачного ящика: что-то мы видим, а что-то – нет.
Кто-то говорит, что этот вид тестирования — это симбиоз белого и черного ящика. Кто-то противопоставляет его белому и черному, опираясь на то, что внутренняя структура тестируемого объекта изначально известна частично и выясняется по мере исследования.
ISTQB относит тестирование методами белого и черного ящика к методам проектирования тестов. Поэтому, ни о каком «среднем» или «промежуточном» методе в этом случае конечно и речи быть не может. Мы либо разрабатываем тесты, зная код, либо не зная его. То есть в классификации ISTQB такого вида тестирования не существует.
Думаю, что на собеседовании это явно стоит упомянуть.
Почему все ящики эффективны?
Методы белого и черного ящика не являются конкурирующими или взаимоисключающими. Наоборот, они гармонично дополняют друг друга, компенсируя имеющиеся недостатки.
Параллельное использование черного и белого ящиков увеличивает покрытие возможных сценариев:
То есть у каждого из методов тестирования свои неоспоримые плюсы, которые помогают выпустить качественный продукт.
Виды тестирования ПО (в картинках)
В книге Growing Object-Oriented Software, Guided by Tests, мы описали различные виды тестов, которые мы используем при проектировании ПО и показали, как хорошо они сочетаются с архитектурным стилем Порты и Адаптеры (Ports and Adapters by Alistair Cockburn).
В Портах и Адапттерах центральное место приложения занимает доменная модель, не имеющая точек соприкосновения ни с какими частями инфраструктуры, будь то БД, очереди, UI, и т.д. Но модель содержит интерфейсы, которые определяют ее взаимоотношения с внешним миром в терминах домена. Cockburn называет эти интерфейсы портами. Эти интерфейсы реализуются в соответствующих объектах, осуществляющих взаимодействие с внешним миром — Cockburn назвал их адаптерами. В распределенных системах разные процессы, каждый со своей доменной моделью, взаимодействюут между собой с помощью портов и адаптеров.
На диаграмме выше, большой круг — это процесс, маленькие(внутри него) — объекты. Домен располагается в центре процесса. Инфраструктурные модули(на рисунке это подписанные сектора), через которые процесс взаимодействует с внешним миром, облепляют доменный «круг». Модули-адаптеры, отображающие концепции домена на технические реализации находятся между ними.
Ниже я попытаюсь объяснить, как различные уровни тестирования вписываются в Порты и Адаптеры.
Модульные тесты
Модульные тесты тестируют отдельные объекты, или их небольшие группы внутри одного процесса. Например, при Test-Driven Development, мы пишем модульные тесты, результаты выполнения которых влияют на тестируемый код — мы редактируем его, когда он не проходит какие-то тест кейсы.
Интеграционные тесты
Термин «интеграционные тесты» может применяться ко многим видам тестирования. В нашей книге мы использовали его, чтобы обозначить тесты для какой-то абстаркции из нашего кода, которая реализуется с помощью сторонних пакетов. Здесь мы хотим затестить, что наша реализация абстракции корректно интегрируется со сторонним кодом: убедиться что мы не сделали неверных предположений о том, как она работает и просто не спотыкается о какие-то неучтенные нами ошибки. Однако, мы не можем взять и прямо исправить найденные этими тестами ошибки, т.к доступа к тестируемому(стороннему) коду у нас нет.
Приемочные тесты
Приемочные тесты — это тесты, ориентированные на пользователя, они тестируют доменную логику всей сестемы, и демонстрируют, что она действительно работает так, как ожидается.
Порты и Адаптеры позволяют запускать приемочные тесты прямо для доменного слоя, т.к он полностью изолирован от технической инфраструктуры и реального мира. Приемочные тесты могут взаимодействовать с моделью через интерфейсы портов. Такие тесты будут чертовски быстрыми. Также их легко изолировать друг от друга, т.к они не сохраняют состояние модели(в базы или очереди, к примеру).
Приемочные тесты для распределенной системы могут инициализировать домены разных процессов в общей памяти и ссылаться друг на друга с помощью реализаций интерфейсов их портов, что позволит каждому конкретному тесту не выходить за границы своего процесса.
Системные тесты
Системные тесты, тестируют систему целиком, управляя ей, через открытые порты. Они также тестируют сборку, развертывание и загрузку системы. Написание системных тестов на ранних этапах разработки, гарантирует что система всегда будет готова для деплоя по мере своего развития.
Однако такие тесты дико тормозные + реальные условия, в которых они запускаются (параллелизм, асинхронность, необходимость сохранения данных) здорово усложняют написание читабельных тестов, изолированных друг от друга.
Классификация видов тестирования
Вы решили дать новый виток своей карьере и попробовать силы в QA? Это отличная идея! И начать своё знакомство с тестированием ПО стоит с основ.
Поиск багов в программных продуктах отличается в зависимости от конечной цели. Алгоритм выявления дефектов сайта при переводе страницы на иностранный язык и определении предельной нагрузки будет отличаться методами, инструментами и привлекаемыми к процессу специалистами.
Многие тестировщики со временем приобретают специализацию, но обучение неизменно начинается с базовых знаний и навыков. Итак, чтобы вам было проще разобраться во всём многообразии QA-областей, мы расскажем о ключевых видах тестирования.
1. Цель
Каждый программный продукт должен выполнять одну или несколько ключевых задач. От приложения с гео-картами мы ожидаем точной ориентации в пространстве, от сайта интернет-магазина ― корректного поиска товаров по заданным параметрам и т. д. Но те же программные продукты мы можем протестировать и с точки зрения дизайна.
Таким образом, анализ ПО с позиции его ключевых или вспомогательных функций определяет тип тестирования:
Функциональное тестирование направлено на проверку того, какие функции ПО реализованы, и того, насколько верно они реализованы.
Нефункциональное – проверка корректности работы нефункциональных требований. Оценивается, КАК программный продукт работает. Эта проверка включает в себя следующие виды:
2. Степень автоматизации
В зависимости от того, используют ли тестировщики дополнительные программные средства для тестирования приложений или программ, тестирование бывает:
Каждый из подходов имеет свои преимущества и недостатки. Ручное тестирование проще освоить, оно широко применяется на проектах всех типов, но мануальные проверки отличаются монотонностью. А вот написание тестов даёт больше возможностей для творческой реализации, но автоматизация требует базовых навыков программирования.
Подробнее о плюсах и минусах этих типов тестирования мы рассказали в нашей статье.
3. Позитивность сценария
Этот подход определяет поведение системы в привычных и экстремальных условиях.
Эти типы тестирования нередко проводятся параллельно. Ведь работая над некоторой функциональностью, тестировщику проще оценить её поведение и в стандартных, и в нестандартных условиях.
4. Доступ к коду программного продукта
В процессе тестирования инженер может работать с ПО, не обращаясь к его коду, а может определить правильность работы, взглянув на код. По доступу к коду программного продукта тестирование делится на:
Проверка программного продукта по каждому из сценариев требует достаточно глубоких знаний. К примеру, об особенностях тестирования «чёрного ящика» в своей книге подробно рассказал Борис Бейзер. Это фундаментальная работа, с которой полезно ознакомиться каждому на старте работы в QA. Об этой и других полезных книгах мы рассказали в статье.
5. Уровень
Этот пункт определяет объект тестирования.
Переход на каждую новую ступень – движение от микроуровня к макро. Это важный этап тестирования, ведь безошибочно написанные модули могут просто не работать вместе.
Узнать больше об особенностях каждого из уровней тестирования вы сможете на базовом курсе Академии, а закрепить навыки – на продвинутом курсе.
6. Исполнитель
От объекта тестирования движемся к его субъекту. Вы могли слышать об альфа- и бета-тестировании. А поучаствовать в одном из них можно, даже не будучи тестировщиком. Итак, по исполнителю тестирование делится на:
7. Формальность
Этот пункт определяет подготовленность тестировщика перед началом проверки.
Начинающие тестировщики редко работают на свободном уровне. А вот опытные QA-специалисты могут позволить себе проверку без дополнительной подготовки. Мастерство растёт со временем, как и оплата труда тестировщика. О том, сколько получают инженеры, читайте в нашем блоге.
8. Важность
QA-область очень многообразна. Помимо отличий в технологии оценки качества, тип тестирования может отличаться индустрией или видом программного продукта. К примеру, начинающий тестировщик может выбрать для себя специализацию:
Надеемся, с этой статьёй вам будет проще ориентироваться в самом начале пути в тестировании программного обеспечения. А что ещё поможет на старте карьеры? Обучение на курсе QA Academy. Записывайтесь прямо сейчас!
Что такое тестирование программ и зачем оно нужно
Оказывается, 75% времени при создании программ уходит вовсе не на программирование. Разбираемся, чем же занимаются тестировщики.
Вероятно, ни одну вещь в мире нельзя сделать без ошибок, и программы не исключение. Допустим, вы написали код и не видите в нём явных багов. Как узнать, что будет при реальном использовании: поведёт ли себя программа так, как от неё ожидают?
Почему тестирование — это так важно
Вот типичные программные баги:
Прежде чем новая версия компьютерной программы, сайта или мобильного приложения попадает к пользователю, она должна пройти через руки инженеров-тестировщиков. Они ищут места в коде, где программа работает не так, как задумано. Чтобы найти как можно больше ошибок, тестировщики моделируют разные ситуации, которые могут возникнуть при использовании приложения.
Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.
Профессия Тестировщик
Вы научитесь тестировать сайты, мобильные приложения и другое ПО. Узнаете, как устроена работа IT-компаний, и сможете понять, как вы хотите развиваться в профессии. Гарантированно получите работу. Уже джуниоры очень востребованы рынком, а наш курс позволит достичь middle-уровня.
Какие виды тестирования существуют
Пользователи непредсказуемы. Они могут делать не только то, что предусмотрено программой, но и то, что ею категорически не предусмотрено. Тестировщик должен проверить все возможные и невозможные сценарии их поведения и убедиться, что программа продолжает работать.
Вообще, у тестирования есть философия, которая строится на том, что в любой программе по определению есть ошибки и найти их все невозможно. А если вы почему-то не нашли ошибку, значит, просто плохо искали. Удачный тест для тестировщика — тот, при котором нашли баг. А если всё нормально работало, значит, тест неудачный и свою задачу не выполняет.
Ошибки возникают не только при кодировании, но и при проектировании системы, и даже на этапе разработки технического задания. Поэтому и тестируют код не только в самом конце работы, а на разных этапах.
Есть несколько видов тестирования:
Что тестируют на разных этапах разработки
Есть несколько уровней тестирования. Их проводят в разное время:
В зависимости от этапа разработки перед тестировщиками стоят разные цели:
Не бывает идеального тестирования: в принципе невозможно доказать, что программа работает правильно при любых условиях. Но тестировщики могут найти и уточнить, в каких условиях она работает неправильно.
Как обычно проходит тестирование
Как правило, тестировщики начинают работать с программой сразу после начала проекта:
После выхода каждой новой сборки программы сначала делают дымовое тестирование — проверяют, что приложение запускается и выполняет основные функции. Если всё в порядке, программу передают на дальнейшее тестирование. Если нет — сразу возвращают на доработку.
Следующий этап — регрессионное тестирование. Тестировщики ищут баги в новых участках кода и в тех местах, где исправляли ранее найденные ошибки.
После этого программу проверяют в разных уровнях: испытывают её функциональность, производительность, работу с окружением. Это можно делать вручную или с помощью автоматических тестов-кейсов.
Автоматизированное тестирование облегчает проверку и экономит время. Лучше всего это работает в сложных приложениях с большой функциональностью.
Когда есть результат, инженеры-тестировщики готовят отчёт по тестированию и отправляют его разработчикам, чтобы те исправили найденные баги. Так происходит от версии к версии, пока результаты не будут удовлетворять критериям, описанным в тест-плане.
Кто всё это делает: немного о профессии
Если проект большой, над ним работает целая команда: одни тестировщики готовят тесты, другие проверяют их полноту и логику, третьи занимаются непосредственно тестированием. Над небольшими задачами может работать один специалист, причём удалённо.
Тестировщики — среди самых востребованных сейчас специалистов-айтишников. Появляется множество новых программ, и каждой из них нужен контроль качества. QA-специалистов нанимают крупные компании-разработчики ПО, они могут стать фрилансерами и работать сразу на несколько фирм.
Как показывает статистика работных сайтов, на рынке не хватает разработчиков автотестов, а специалистов ручного тестирования достаточно. Средняя зарплата тестировщика в Москве больше 120 тысяч рублей, а по регионам —
примерно 55–60.
На скриншотах ниже — данные с HeadHunter. В сентябре 2020 года там было 3000 открытых вакансий тестировщика.